Common TCP/UDP ports and the services that run on them — handy when reading firewall rules, building ACLs, or identifying unfamiliar traffic in a packet capture.

A port is a 16-bit number (0–65535) that lets a single host run many services without them stepping on each other. The OS hands incoming packets to the right process by looking at the destination port. IANA carves the range into three blocks: well-known (0–1023, the "system" ports — HTTP, SSH, DNS, etc.), registered (1024–49151, vendor-assigned for specific applications), and dynamic / ephemeral (49152–65535, used by clients for outgoing connections — though Linux defaults to a wider 32768–60999 range).

TCP and UDP have separate port spaces. SSH listens on 22/tcp, DHCP server runs on 67/udp — those don't conflict because they're on different protocols. When writing firewall rules or ACLs, always specify both the port and the protocol. Some services genuinely use both (DNS on 53/tcp and 53/udp; UDP for normal queries, TCP for zone transfers and large responses).

On Unix-like systems, binding a listener on a well-known port (under 1024) requires root or the CAP_NET_BIND_SERVICE capability. This is a security legacy from the BSD days — the assumption was that only privileged daemons should be able to claim "I am SSH" or "I am the mail server." Most modern setups work around this by binding the unprivileged process to a high port and using a reverse proxy, iptables redirect, or systemd socket activation to expose the well-known port.

Inside container networks and service meshes, "well-known" matters less — services usually advertise themselves on whatever port and rely on service discovery to find each other. But at the edges (north-south traffic crossing your firewall, or anything that talks to legacy systems), the well-known port assignments still drive most ACL design. If you see 514/udp hitting a syslog collector or 1812/udp hitting a RADIUS box, that's the protocol announcing itself.