Search any port number. Instant service identification, security risk level, and scanning commands for 2,758 ports.
The encyclopedia indexes all standard TCP and UDP ports (1-65535) with focus on the ones that actually matter for security — service name, protocol (TCP/UDP/both), category (web, database, remote access, email, file sharing, etc.), risk classification (Critical / High / Medium / Low), and common attack patterns. The grid above shows ports with detailed annotations; generic filler ports without notable security context are omitted from the visible grid but searchable via the lookup field.
Risk classification methodology. Risk reflects how often the port appears in real attack scenarios and how severe the impact of compromise is. Critical (RDP/3389, SMB/445, exposed databases): historically wormable, frequent severe vulnerabilities, high-value access if compromised. High (SSH/22, MS-SQL/1433, MongoDB/27017): significant attack surface, common credential brute force, often misconfigured. Medium (FTP/21, Telnet/23): bad security practices baked in but lower base rate of exploitation today. Low (HTTPS/443 properly configured, IMAP/993): hardened modern services on this port. Risk is contextual — a properly-configured service on any port is lower risk than an unpatched legacy version of the same service.
Search and filter. Type a port number in the search box for instant lookup against the encyclopedia. Use the category filter chips to narrow by service type (databases, web, remote access). The 30 chips at the top show the most-searched ports for fast access. Each port card links through to /ports/N/ for the full per-port detail page with attack scenarios, hardening guidance, and historical CVE patterns.
Coverage and what is NOT included. The encyclopedia covers IANA-registered services and historically-significant ports (including legacy protocols like Telnet that should not be running anywhere in 2026 but still appear on legacy systems). It does not include ephemeral port range (49152-65535 dynamic client connections) since those are not service-specific. It does not cover application-layer protocols on top of HTTP (REST APIs, gRPC, GraphQL) because those run over HTTPS/443 and are not port-distinguishable. For application-protocol identification, you need DPI tools, not port lookup.
After running an initial port scan against a target with the Port Scanner or nmap, look up each open port in the encyclopedia. The risk classification tells you which to investigate first; the common-attacks notes give you the starting point for testing each service. Cuts hours off recon by surfacing the highest-impact attack surfaces immediately.
When evaluating a SaaS vendor or assessing third-party risk, run nmap (or use Shodan / Censys) against their public IPs and look up the open ports here. A vendor exposing database ports directly to the internet is signalling something serious about their security maturity. The encyclopedia\'s risk classifications help you triage findings into critical-conversation-needed vs acceptable-risk categories.
For teaching network security concepts, the encyclopedia provides ready-made examples for each port — what runs on it, what attacks target it, why it matters. Useful for building out lesson plans without re-researching every protocol from scratch. Particularly the Critical/High categorised ports come with attack-pattern annotations that make for concrete classroom examples.
During an incident, you have logs showing connections to specific ports on internal systems. Look up unfamiliar ports here to quickly identify what service was likely the target — is this normal application traffic or something investigation-worthy? Speeds up the triage step where you decide which alerts deserve deep-dive investigation vs noise.
Build your default firewall block-list from the Critical and High categories. Database ports, RDP, SMB, anything in the High category exposed to public internet — block by default, allow only with explicit business justification. The encyclopedia gives you the principled list to start from rather than reactive blocking after each incident.
Moving SSH from 22 to 22222 reduces opportunistic scanner traffic but does not stop targeted attacks — modern scanners check all ports anyway. Port change is operational hygiene (cleaner logs), not security. For real SSH security, use key auth, disable password auth, restrict source IPs.
Blocking port 80 does not block a service that also listens on 8080, 8000, or 443. Real port-blocking requires comprehensive firewall rules covering all the ports a service might use, not just the canonical one. Check what is actually listening (ss/netstat on Linux) before assuming a block is comprehensive.
Most port scans default to TCP. UDP services (DNS/53, DHCP/67, NTP/123, SNMP/161) get missed. UDP-based attacks (DNS amplification, NTP amplification) historically produced massive DDoS campaigns. Always scan both TCP and UDP for security assessments; do not assume "no TCP findings" means "secure".
Open port = service is reachable. Whether the service is vulnerable depends on the service version, configuration, authentication, and known CVEs. The encyclopedia tells you which ports are high-risk attack surfaces; vulnerability scanning (Nessus, OpenVAS) tells you whether the specific instance is currently vulnerable.
Anyone can run any service on any port. A service responding on port 443 might not be HTTPS — could be a custom protocol, malware C2, or anything else. Banner-grabbing and protocol detection (nmap -sV) tells you what is actually running, not what should be running based on port assignment.
Strict firewall policies that block "all ports above 1024" break outbound connections because client connections use ephemeral ports (49152-65535) for return traffic. Stateful firewalls handle this automatically; pure stateless allow-list policies need explicit ephemeral-range rules. Test connectivity after policy changes to catch this.