Common TCP and UDP Ports: Reference, Risks, and Use Cases

Common TCP and UDP Ports: Reference, Risks, and Use Cases

Ports are the entry points of networked services; they decide who can talk to what, and how. If you map ports to the right protocols and limit exposure, you reduce the blast radius of mistakes and make incident response faster.

In day-to-day operations, a small set of TCP and UDP ports carry most production traffic: web, name resolution, email, file sharing, databases, remote administration, VPN, and orchestration. Each has a conventional default, characteristic traffic patterns, and predictable failure modes when misconfigured.

Below we catalog widely used ports, note their defaults, typical risks, and concrete hardening steps. We keep explanations direct, call out differences between TCP and UDP, and emphasize controls like TLS, authentication, and source allow-lists.

Understanding Port Ranges and Defaults

There are three ranges: well-known/system (0–1023) for core services, registered/user (1024–49151) for common applications, and dynamic/private (49152–65535) used mostly for client-side ephemeral connections. Service defaults usually sit in the first two ranges, while clients pick a high ephemeral port automatically. Vendors can change listening ports, but the security posture—encryption, auth, and scoping—matters more than the number.

Web and Application Front Ends

80/TCP (HTTP): Cleartext web traffic. Keep it only to redirect to HTTPS and never serve sensitive content on it. Ensure redirects are strict and universal.

443/TCP (HTTPS): Encrypted web transport. Modern sites negotiate HTTP/2 and increasingly HTTP/3 (which rides over QUIC on UDP under the hood). Enforce HSTS, disable legacy TLS, prefer strong cipher suites, and terminate TLS at a hardened reverse proxy that only talks to private backends.

8080, 8443/TCP: Alternate HTTP/HTTPS ports often used by admin consoles and dev stacks. Treat them as production: require TLS, authentication, and IP allow-lists; never leave them publicly reachable by default.

DNS and Directory Services

53/UDP and 53/TCP (DNS): UDP handles typical queries; TCP is used for large responses and zone transfers. Do not run public open recursion on authoritative servers; restrict AXFR/IXFR to authorized secondaries and consider TSIG. Encrypted profiles include DoT on 853/TCP and DoH over 443/TCP; use DNSSEC validation where possible.

389/TCP (LDAP) and 636/TCP (LDAPS): Directory access. Prefer StartTLS or LDAPS for encryption, restrict binds to trusted subnets, and disable anonymous binds unless explicitly required for read-only scenarios.

Email Transport and Submission

25/TCP (SMTP MTA-to-MTA): Server-to-server relay. Keep it open only on systems that actually accept or relay mail. Enforce TLS where supported, and consider MTA-STS or DANE if your ecosystem supports them.

587/TCP (Submission) and 465/TCP (Implicit TLS Submission): Authenticated client submission belongs here, not on 25. Require authentication, enforce TLS, and rate-limit to slow down credential stuffing. Block outbound 25 from user subnets to deter malware-driven spam.

110/995 (POP3/POP3S) and 143/993 (IMAP/IMAPS): Client retrieval. Migrate users to the encrypted variants and disable cleartext access paths; prefer modern authentication.

File and Object Sharing

445/TCP (SMB) and 137–139/TCP/UDP (NetBIOS): Never expose to the open internet. Internally, disable SMBv1, enable signing (and encryption for sensitive shares), and segment file servers. Watch for lateral-movement patterns and unusual share enumeration.

20–21/TCP (FTP) and 69/UDP (TFTP): FTP sends credentials in clear unless you use FTPS; prefer SFTP (over SSH on 22/TCP) or HTTPS uploads. If FTP is unavoidable, use passive mode with a bounded data-port range and restrict by source IP. TFTP is unauthenticated by design—confine it to isolated provisioning networks only.

2049/TCP/UDP (NFS): Bind to trusted subnets, use export controls with least privilege, and put cross-network use behind a site-to-site VPN.

Remote Administration

22/TCP (SSH): Disable password logins, require keys plus MFA for admins, and funnel management through a bastion or VPN. Add connection rate limits and disable direct root login.

3389/TCP (RDP): A frequent initial access vector. Do not expose it publicly. Place it behind a VPN or identity-aware proxy, restrict by source IP, enable network level authentication, and patch aggressively.

23/TCP (Telnet): Legacy cleartext remote shell. Replace with SSH and yank any residual listeners.

Databases and Caches

3306/TCP (MySQL/MariaDB), 5432/TCP (PostgreSQL), 1433/TCP (SQL Server), 1521/TCP (Oracle): Bind to private interfaces, require TLS, and enforce firewall allow-lists. Don’t expose these to the internet; reach them through app tiers or private connectivity.

6379/TCP (Redis): Defaults to unauthenticated local-only in many builds—dangerous if bound to 0.0.0.0. Keep protected-mode on, require ACLs/passwords, enable TLS, and restrict to app subnets.

11211/TCP/UDP (Memcached): Disable UDP unless absolutely needed and bind only to loopback or private networks to avoid reflection attacks and data exposure.

27017/TCP (MongoDB): Historically found exposed with no auth. Bind privately, enable SCRAM with strong credentials, turn on TLS, and firewall tightly.

Containers and Orchestration

2375/TCP (Docker API, cleartext) and 2376/TCP (Docker API, TLS): Treat the remote API as root-equivalent on the host. Never expose 2375. If remote management is mandatory, use 2376 with mutual TLS and IP allow-lists; better, manage via SSH on localhost.

6443/TCP (Kubernetes API server) and 10250/TCP (Kubelet): Keep both off the public internet. Enforce RBAC, require mTLS, place control plane behind load balancers with restricted source ranges, and ensure node-port services or debug ports don’t accidentally expose internals.

VPN and Secure Tunnels

1194/UDP (OpenVPN), 500/UDP and 4500/UDP (IPsec IKE/NAT-T), 1701/UDP (L2TP), 51820/UDP (WireGuard): Patch concentrators, require MFA, and restrict by source IP where feasible. Some deployments move OpenVPN to 443/TCP to traverse strict egress; if you do, separate it cleanly from web workloads and monitor for confusion in logs.

Gaming and P2P

6881–6889/TCP/UDP (BitTorrent), 25565/TCP (Minecraft), 27015/UDP (Steam/Valve): Expect scanning and noisy traffic. Isolate from business networks, rate-limit where supported, and avoid exposing admin consoles or RCON publicly.

TCP vs. UDP: Security Implications

TCP tracks connection state and applies flow control; UDP is stateless and easier to spoof. UDP services are more prone to reflection/amplification if misconfigured, so add rate limiting, authentication where available, and edge filtering. For TCP services, protect against brute force, downgrade attempts, and verbose banners.

Testing and Monitoring

Inventory listeners regularly from both inside and outside. Confirm that port exposure matches intent and that encrypted variants are enforced. For DNS, verify TCP fallback and any encrypted profiles. For mail, test STARTTLS and authentication on submission ports. For containers and clusters, ensure management APIs aren’t reachable from untrusted networks and that RBAC is effective. Alert on any new listener bound to 0.0.0.0 and on denied hits to sensitive ports like 445, 3389, 2375, 6443, and 10250.

Quick Hardening Checklist

Common TCP and UDP Ports: Reference, Risks, and Use Cases (FAQ)

On Linux use “ss -tulpn” or “sudo lsof -i -P -n”; on Windows use “Get-NetTCPConnection” and map the PID with “Get-Process”; run with admin rights to see system listeners.

From a separate network, test the specific TCP or UDP port against your public address—first confirm the address via What Is My IP Address—and verify the server responds as expected.

Query authoritative records and verify A/AAAA, CNAME, MX, and relevant TXT entries with a simple DNS Lookup; confirm TTLs and that names resolve to the intended addresses only.

It reduces noise from generic scanners but isn’t a control by itself; always pair it with TLS, authentication, source allow-lists, and rate limits so discovery doesn’t equal compromise.

Remote admin (3389, 22 if passworded), management planes (2375/2376, 6443, 10250), file sharing (445), and unauth databases/caches (3306, 5432, 1433, 1521, 6379, 11211, 27017) routinely lead to full compromise when public.

Define exact host IPs or tight CIDR blocks and document them; when calculating ranges, use an IP Address Calculator so you don’t accidentally over-permit.

Yes; because UDP is stateless and easy to spoof, require authentication where possible, rate-limit queries, and restrict exposure to trusted sources to prevent reflection and abuse.

Permit authenticated submission on 587 and/or 465 to your provider, and block outbound 25 from user subnets to curb spam; MTAs that relay externally are the exception.