Common Ports Cheat Sheet: Essential Ports Every Network Administrator Should Know

When a firewall blocks a login, a printer drops off the network, or a mail server stops relaying, the first question is often the same: which port is involved? That is where Ports, Protocols, Network Management, Security, Firewall Configuration knowledge pays off. If you know what is supposed to be listening, what should be blocked, and which service uses which port, troubleshooting gets faster and your firewall rules become much cleaner.

Primary Use	Fast-reference guide for common network services as of May 2026
Core Focus	Ports, Protocols, Network Management, Security, Firewall Configuration as of May 2026
Most Common Examples	22 SSH, 53 DNS, 80 HTTP, 123 NTP, 443 HTTPS, 445 SMB, 3389 RDP, 5432 PostgreSQL as of May 2026
Typical Users	Network Administrators, systems admins, SOC analysts, and incident responders as of May 2026
Key Tools	ss, netstat, lsof, nc, curl, packet capture tools as of May 2026
Security Value	Supports firewall rules, segmentation, exposure reviews, and service validation as of May 2026
Course Alignment	Strong fit with CompTIA N10-009 Network+ Training Course topics such as IPv6, DHCP, and switch troubleshooting as of May 2026

What a Network Port Is and Why It Matters

A network port is a numeric identifier that helps TCP and UDP deliver traffic to the correct application on a host. A server can run many services on one IP address, and the port number is what keeps SSH traffic separate from DNS, web traffic, or database queries.

In day-to-day administration, ports are not theory. They determine whether a client can connect, whether a firewall rule is valid, and whether a packet capture actually shows the service you think it does. The Network Administrator who understands ports can move from “the network is down” to “TCP 443 is blocked between the app subnet and the load balancer” in minutes.

Ports are usually grouped into three ranges:

• Well-known ports from 0 to 1023 are reserved for common services such as DNS, HTTP, and SSH.
• Registered ports from 1024 to 49151 are often used by vendor applications, database services, and management tools.
• Ephemeral ports are temporary client-side ports used for outbound sessions and return traffic.

This matters for service discovery, connectivity testing, and Access Control. If a service is listening on an unexpected port, it may be a configuration issue, a version difference, or a sign of shadow IT. The same is true when firewall policy allows the wrong destination or blocks a supporting port used by a secondary process.

“A port is not the service. It is the address the service listens on, and that distinction is why troubleshooting gets easier when you know both the protocol and the application.”

Common tools make port work practical. ss -tulpen shows listening sockets on Linux, netstat -ano still appears in many Windows workflows, lsof -i helps map processes to ports, and nc can test whether a destination is reachable. That combination is basic Network Management skill, not an advanced luxury.

For security professionals, the NIST guidance on service hardening and network boundary control reinforces the same idea: services should be explicitly allowed, not vaguely assumed. See NIST CSRC for control guidance and CIS Benchmarks for hardening references that often include port restrictions.

How Does a Port Cheat Sheet Work?

A port cheat sheet is a compact reference that maps port number, protocol, service name, and typical purpose so you can validate connectivity quickly. It is most useful when it is tied to your actual environment, not just a generic list copied from a textbook.

1. Identify the port number. Start with the exact numeric port from logs, packet captures, or a firewall deny entry.
2. Match the protocol. A service can behave very differently on TCP versus UDP, especially for DNS, NTP, and Syslog.
3. Confirm the service name. HTTP on 80, HTTPS on 443, and SSH on 22 are common defaults, but vendor products may move them.
4. Check the expected use. Administration, authentication, file transfer, or database access each imply different security expectations.
5. Validate against the environment. A port may be nonstandard in one site, cloud deployment, or appliance build.

This is why cheat sheets are valuable during Incident Response. A responder can look at an alert and immediately ask whether the destination port makes sense for the asset, whether the traffic is user-driven, and whether the rule belongs in a business application or in an administrator-only segment.

The same sheet helps during firewall audits and change reviews. If a ticket requests access to TCP 8443 for a web console, you can verify whether that is the approved port for the product and whether the exposure should be limited to a management VLAN. That is also where a Remote Access policy becomes operational, not just a document.

Port usage changes by vendor, product version, and deployment model. Microsoft SQL Server often uses 1433 by default, but named instances and cluster designs may require additional dynamic ports. For authoritative product guidance, use official documentation such as Microsoft Learn, AWS Documentation, and Cisco product docs rather than assuming the default always applies.

How admins actually use the sheet

In practice, the cheat sheet becomes a living control document. The better versions include labels such as “legacy,” “internet-facing,” or “admin only,” because those hints help reviewers understand risk at a glance.

• During an outage: verify whether the port should be open and whether the service is bound locally.
• During a firewall audit: check whether each rule maps to an approved business function.
• During a change review: confirm whether a new port opens a new attack surface or reuses an existing one.

For teams supporting the CompTIA N10-009 Network+ Training Course, this habit pairs naturally with DHCP, IPv6, and switch-failure troubleshooting. Port knowledge is what turns a vague connectivity complaint into a focused set of tests.

Essential Web and Remote Access Ports

HTTP on port 80 and HTTPS on port 443 are the foundation of web access and the most visible example of how ports shape access control. HTTP is plaintext, while HTTPS adds TLS encryption, server identity validation, and protection against packet sniffing on untrusted networks.

Port 443 is also the default for most browser-based administration interfaces. Storage consoles, virtualization platforms, firewalls, and network appliances commonly expose management over HTTPS because it is simpler to secure than custom client software. That convenience does not remove the need to restrict source IPs and log access.

SSH on port 22 provides secure remote shell access and is also used by tools such as SCP and SFTP for file transfer. It is one of the most important ports for Linux and network device administration. Exposure should be tightly controlled, especially across Internet-facing interfaces.

RDP on port 3389 is the standard remote desktop port for Windows systems. It is essential in many enterprise environments, but it is also a high-value target for brute-force attacks and lateral movement. If RDP must be reachable, use MFA, source restrictions, and a bastion host wherever possible.

Port	80, 443, 22, 3389
Typical Use	Web browsing, secure admin consoles, remote shell access, Windows remote desktop

Firewalls should treat these ports as business-critical but not automatically trusted. A web app on 443 may need access from the internet, while a switch management interface on 443 should usually be limited to a management subnet. That difference is the essence of practical Firewall Configuration.

For secure configuration guidance, official references from Microsoft Learn and the CIS Benchmarks are useful because they often spell out how management services should be restricted.

Common web and remote access patterns

• HTTPS-only admin portals: common for firewalls, storage, and cloud consoles.
• Custom secure ports: some vendors move management from 443 to 8443 or another nonstandard port.
• Bastion access: administrators reach SSH or RDP through a jump host instead of direct exposure.

File Transfer and Data Exchange Ports

FTP uses port 21 for control traffic and port 20 for data in active mode. That split makes it easy to understand but awkward to secure, because the separate control and data channels can complicate firewall rules and NAT behavior. In most modern environments, FTP is legacy unless a specific system still depends on it.

TFTP uses port 69 and is still common in device provisioning, PXE boot, and network equipment upgrades. It is lightweight and simple, but it has no authentication and little built-in security. That is why it belongs in tightly controlled provisioning networks, not general user subnets.

SFTP and SCP run over SSH rather than using separate FTP-style ports. They are preferred because they inherit SSH encryption and authentication. For most administrative workflows, that makes them the safer choice for file exchange, automation, and transfer of configuration backups.

SMB uses port 445 and, in older or compatibility scenarios, port 139. It supports Windows file sharing and printer access, and it is one of the most frequently monitored internal ports because it is heavily used in enterprise collaboration and also heavily abused by attackers during lateral movement.

NFS on port 2049 is common in Unix and Linux environments. Depending on the version and deployment, supporting services such as rpcbind or additional dynamic ports may also be involved, which is why validating the full path matters before you declare an NFS outage fixed.

Official vendor documentation is the right place to confirm protocol behavior and hardening options. When dealing with Microsoft file-sharing or Linux storage stacks, use Microsoft Learn or Red Hat documentation as appropriate. For secure baseline expectations, the CISA guidance ecosystem is also worth checking when you are deciding what should be exposed.

Email and Messaging Ports

SMTP is the mail transfer protocol and commonly uses port 25 for server-to-server relay, port 587 for message submission, and port 465 for implicit TLS submission in some environments. The distinction matters because users should normally submit mail with authentication, while relaying between mail servers follows different trust rules.

POP3 uses port 110, with port 995 for TLS-protected POP3S. It still appears in legacy mail environments, especially where clients download mail for offline use. In most modern deployments, it is less common than IMAP because it is less flexible for multi-device access.

IMAP uses port 143, with port 993 for IMAPS. It is common for modern mail clients because it keeps mail on the server and synchronizes across devices. That makes it easier for users, but it also means the server becomes more central to availability and retention policy.

Email ports are frequent trouble spots because security controls sit in the middle of the mail flow. Outbound filtering, spam controls, TLS negotiation, and authentication failures can all break delivery. A mail port can be “open” while still failing if the server refuses relay, the client lacks authentication, or the remote host rejects the sender reputation.

For mail security, use the official guidance from M3AAWG and your mail platform vendor. Those references help you align port exposure with TLS requirements, anti-spam policy, and authenticated submission.

What admins should check first

1. Confirm whether the issue is submission, relay, or delivery.
2. Check whether the correct port is being used for the expected TLS mode.
3. Verify authentication, SPF/DKIM/DMARC policy, and firewall egress rules.
4. Compare the mail server’s listener to the intended security policy.

Directory, Authentication, and Identity Ports

DNS uses port 53 over both TCP and UDP, and both protocols matter. UDP handles most routine queries because it is lightweight, while TCP is required for large responses, zone transfers, and some failure cases. If DNS breaks, everything else feels broken because name resolution underpins so many applications.

LDAP uses port 389, while LDAPS uses port 636. LDAP supports directory queries, group lookups, and application authentication, and LDAPS adds TLS protection. In many organizations, directory traffic is one of the most sensitive internal flows because it affects login, authorization, and user policy enforcement.

Kerberos uses port 88 and is central to domain authentication flows. When Kerberos fails, users may experience login delays, ticket errors, or fallback behavior that looks like an unrelated application problem. Time sync, DNS, and hostname consistency all affect whether Kerberos works properly.

RADIUS uses port 1812 for authentication and 1813 for accounting. It is common for network access control, VPN logins, Wi-Fi authentication, and privileged access systems. If RADIUS is unavailable, you can lose access to wired and wireless entry points at the same time.

These ports directly affect Network Management because they control who can log in and what resources they can reach. They also affect Security because a failure in identity services often looks like a general outage when it is actually a policy or port issue.

Identity traffic is infrastructure traffic. If DNS, Kerberos, LDAP, or RADIUS fails, the network may still be up while the business is effectively down.

For authoritative identity and access references, use IETF RFCs for protocol behavior and vendor documentation for product-specific port requirements. If you need policy context, NIST and ISC2® resources help frame why identity ports are a security boundary, not just a connectivity detail.

Infrastructure and Core Network Service Ports

DHCP uses ports 67 and 68, and it depends on broadcast traffic during client bootstrapping. That is why VLANs, relay agents, and switch configuration matter so much. A device that cannot get a lease often has a path problem, an ACL issue, or a relay configuration mismatch rather than a broken address server.

SNMP uses port 161 for polling and 162 for traps. It is still a standard way to monitor routers, switches, printers, and servers, even though modern platforms often supplement it with APIs and telemetry. SNMPv3 is the preferred secure version because it adds authentication and encryption options.

NTP uses port 123, and time drift causes more damage than many admins expect. If clocks are off, certificates can appear invalid, log correlation breaks, and authentication systems such as Kerberos may fail. Time is not a minor convenience; it is part of operational trust.

Syslog traditionally uses port 514, often over UDP, though TCP implementations are also common for reliability. Centralized logging depends on predictable log transport, and syslog exposure should be designed with network segmentation and log integrity in mind.

These services support observability and centralized management. They are usually not user-facing, which means they should be protected, documented, and validated against the organization’s approved source and destination ranges.

For technical baseline guidance, consult RFC documentation for protocol specifics and CIS Benchmarks for hardening advice around logging and time services.

Database and Application Backend Ports

MySQL commonly uses port 3306, PostgreSQL uses 5432, and Microsoft SQL Server commonly uses 1433. These ports are the backbone of many line-of-business applications, and they are usually restricted to application subnets rather than user networks.

Redis commonly uses port 6379, and MongoDB commonly uses port 27017. These services are often used as caches, queues, session stores, or document databases, which makes them highly sensitive to exposure. A database port should not be treated like a generic web port.

Direct internet exposure is a common mistake. Even when authentication is enabled, public database access increases brute-force risk, misconfiguration risk, and the chance that a future patch or credential leak becomes a major breach. Good hardening starts with network restriction and continues with strong authentication, encryption, and logging.

• Restrict by subnet: allow only the application servers that actually need the database.
• Use bastion access: force admin access through a controlled jump host.
• Separate replication paths: keep backup and cluster traffic documented and segmented.
• Check nondefault ports: clustered or managed deployments may use extra listener ports.

For vendor-specific validation, use the official database documentation. For broader database and container exposure guidance, the OWASP project is useful because it frames database access in terms of attack surface and least privilege.

Port restriction is part of Firewall Configuration, but it is also part of application architecture. A database that only needs access from one service should not be visible to every workstation “just in case.”

Collaboration, Voice, and Real-Time Communication Ports

SIP uses port 5060 for signaling and 5061 for TLS-protected signaling. It is the control plane for many VoIP systems, handling call setup, teardown, and session negotiation. If SIP is blocked, the call may never start even though the media path is otherwise fine.

RTP and RTCP usually use dynamic port ranges for media streams and quality monitoring. That is where firewall design becomes tricky. You are not just opening one port; you are allowing a negotiated range that may change by session, endpoint, or platform.

Many conferencing and chat platforms use additional ports that vary by vendor and deployment model. That is why voice and collaboration troubleshooting often starts with vendor documentation instead of generic port lists. What looks like a network issue may actually be a session-tracking issue, a NAT problem, or a signaling mismatch.

NAT traversal, SBCs or session border controllers, and port forwarding are common tools in voice environments. They exist because real-time media often has to cross firewalls, NAT boundaries, and segmented network zones without losing session state.

Real-time communication is usually won or lost on the signaling ports first and the media ports second.

For standards-based guidance, use IETF documents for SIP and RTP behavior, plus the vendor’s own deployment guide. That is the fastest way to determine which ports are static, which are negotiated, and which need special firewall handling.

Security, VPN, and Management Ports

IPsec typically relies on UDP 500 for IKE and UDP 4500 for NAT traversal. Those ports are critical for VPN establishment, especially where devices sit behind firewalls or home routers. If they are blocked, the tunnel may fail before encryption even starts.

OpenVPN commonly uses port 1194 and can operate over TCP or UDP. That flexibility is helpful, but the choice matters. UDP is often preferred for performance, while TCP can help in restrictive environments, though it may create less efficient tunneling behavior.

Management interfaces should be protected as if they were production assets, because they are. HTTPS-based consoles, SSH access, and VPN entry points are the doors through which administrators reach the rest of the environment. If those ports are exposed, they need logging, alerting, and review.

SSH tunneling and bastion hosts are common privileged access patterns. They reduce direct exposure, create a better audit trail, and support least privilege by limiting who can reach internal services. They also make it easier to apply zero-trust style segmentation, because access is granted to a workflow rather than to an entire subnet.

IDS/IPS, zero trust policies, and least privilege all change how you should think about ports. The question is not simply “is the port open?” The real question is “who can reach it, from where, for what reason, and is that access logged?”

For official guidance, use CISA resources for defensive posture and NIST for control mapping. Those references help justify why management ports deserve stronger restrictions than ordinary application traffic.

Ports Commonly Seen in Troubleshooting and Monitoring

Basic connectivity checks start with tools like nc, telnet, curl, a browser, and packet capture. These tools do different jobs. nc tells you whether a TCP port is reachable, curl validates HTTP or HTTPS behavior, and packet capture shows whether the traffic leaves the host and returns properly.

It is important to distinguish port open from service healthy. A port may accept a TCP handshake while the application behind it fails authentication, returns a 500 error, or cannot reach its database. That is why the right test depends on the symptom.

• Local listener check: confirms whether the service is bound to the expected interface and port.
• Remote reachability check: confirms the path through firewalls, routing, and ACLs.
• Application response check: confirms the service can actually do its job.

Common failure patterns include stateful firewall drops, incorrect service binding, DNS resolution problems, and ephemeral port exhaustion. If a port test fails from one subnet but not another, the problem may be segmentation rather than the application itself. If a service listens only on localhost, the network can be perfect and the application will still appear down.

Monitoring systems also depend on port awareness. They can alert on unexpected open ports, unapproved listeners, or service outages. That gives administrators an early warning when a system drifts from its approved configuration.

For technical validation, the Wireshark documentation and ss manual are useful references because they show how to inspect traffic and sockets in a way that supports real troubleshooting.

How to Read and Use a Port Cheat Sheet

A useful port cheat sheet shows the port number, protocol, service name, and typical use in a way that supports fast decision-making. If the sheet is too dense, people stop using it. If it is too vague, it does not help during an outage.

The best version is simple enough to print, bookmark, or add to an internal wiki. It should show common ports like 22 SSH, 53 DNS, 80 HTTP, 123 NTP, 443 HTTPS, 445 SMB, 3389 RDP, and 5432 PostgreSQL, then add notes such as “TCP only,” “UDP and TCP,” or “admin only.”

Port	22 SSH
Typical Label	Admin only, encrypted remote shell

Keep the reference aligned with local applications and policies. If your environment uses 8443 for a management console or 10443 for an internal portal, document that. If a vendor update changes the listener or adds a support process, update the sheet immediately.

Port usage varies by vendor, product version, and deployment model, so validation matters. That is why internal documentation should list the approved business owner and the environment name alongside the port. If the app team changes a listener, the network team should not have to rediscover it during an outage.

When Should You Use a Port Cheat Sheet?

You should use a port cheat sheet any time you need to verify expected connectivity, review a firewall change, or identify the service behind a log entry. It is a fast way to reduce guesswork and make troubleshooting repeatable.

Use it during incident response when you need to decide whether a flow is normal, suspicious, or blocked. Use it during firewall audits to prove that each open port has a documented business reason. Use it during change reviews to confirm that a new rule will not expose a management interface to the wrong network.

It is especially helpful for verifying Network Management and Security boundaries. A port list can show whether a service is supposed to be user-facing, internal only, or restricted to a backup subnet. That distinction is critical when teams are under pressure and want to “just open it up” to restore service.

Use the cheat sheet whenever troubleshooting spans DNS, DHCP, RDP, or database access. Those are the kinds of dependencies that make simple symptoms turn into complex outages. Port knowledge helps you narrow the search space quickly.

When Should You Not Use a Port Cheat Sheet?

You should not rely on a port cheat sheet alone when vendor documentation, packet capture, or host-level evidence is available. A cheat sheet gives the default answer, not always the correct one for a specific deployment.

Do not use it as a substitute for validating the live system. Some products negotiate dynamic ports, use alternate secure ports, or change behavior between versions. A printed reference is helpful, but a live listener check is better.

It is also the wrong tool when you need to understand a deeper protocol sequence. In those cases, use packet capture, logs, and official documentation. The cheat sheet is a map, not the territory.

Finally, do not assume that an open port is automatically a security problem or that a closed one is automatically safe. Risk depends on source restrictions, authentication, service hardening, and whether the port is exposed internally or to the internet.

Quick Reference Port Table

This is the kind of table a Network Administrator can keep in a wiki, print for a war room, or use as a first-pass checklist during a change window. It is intentionally concise and focused on the ports most people actually look up.

Port / Protocol	22 / TCP — SSH — secure remote shell, admin only
Port / Protocol	53 / TCP, UDP — DNS — name resolution and zone transfers
Port / Protocol	80 / TCP — HTTP — web traffic, legacy or redirect use
Port / Protocol	123 / UDP — NTP — time synchronization
Port / Protocol	443 / TCP — HTTPS — secure web access and admin consoles
Port / Protocol	445 / TCP — SMB — Windows file sharing and printer access
Port / Protocol	3389 / TCP — RDP — Windows remote desktop, high-risk if exposed
Port / Protocol	5432 / TCP — PostgreSQL — database access, usually restricted

Mark each entry with a practical risk label in your internal version. “Legacy,” “admin only,” and “internet-facing” are more useful than vague notes like “important.” If the port uses both TCP and UDP, say so clearly. If a vendor uses a secure alternative port, document that next to the default.

Best Practices for Managing Ports in Production

Good port management starts with documentation. List approved ports by application, environment, and business owner so nobody has to guess during a change or outage. If you cannot explain why a port is open, you probably should not leave it open.

Minimize exposed services and close unused ports by default. That applies to hosts, firewalls, load balancers, and cloud security groups. Layered defense works best when network firewalls, host firewalls, and segmentation all point in the same direction.

Change control matters because port problems often appear after a “small” firewall change. Validate after every update, test both directions where needed, and keep rollback plans ready. A good rollback plan is not just a document; it is a recovery path your team can execute under pressure.

Regular scanning, asset inventory reconciliation, and log review help you find drift. If a port opens without approval, fix the process that allowed it, not just the symptom. Unexpected listeners are frequently how forgotten services, misconfigured applications, and exposed admin tools get discovered.

• Document: approved ports, owners, and business justification.
• Restrict: source IPs, subnets, and user roles.
• Validate: after changes and after vendor updates.
• Monitor: unexpected listeners, deny logs, and service health.

For risk and control framing, NIST and CISA are strong references, while the BLS Occupational Outlook Handbook continues to show steady demand for network and systems roles that depend on this exact operational discipline as of May 2026.

Conclusion

Ports are foundational knowledge for daily network administration. They help you identify traffic, validate services, tighten Security, and make Firewall Configuration decisions that are based on facts instead of guesses.

A good cheat sheet saves time because it turns a broad problem into a narrow one. When you know that DNS uses 53, DHCP uses 67 and 68, HTTPS uses 443, and PostgreSQL uses 5432, you can test the right path, check the right listener, and ask the right owner the right question.

For teams working through the CompTIA N10-009 Network+ Training Course, this topic is especially practical because it reinforces real troubleshooting habits around IPv6, DHCP, switch failures, and service validation. That is the kind of knowledge you use on live networks, not just on exams.

Customize your reference for your own infrastructure, keep it aligned with approved services, and review it after every major application or firewall change. Then update it again when the environment changes, because ports do not stay useful if the sheet stays stale.

CompTIA® and Security+™ are trademarks of CompTIA, Inc.