Ports & Common Protocols — Explain ports and common protocols (TCP/UDP, DNS, DHCP, HTTP/S, SSH) and why they matter for security

The modern internet is built upon decades of protocol engineering, each layer addressing a specific communication challenge. In the earliest days of ARPANET, researchers needed a way for multiple applications on a single host to share a network connection simultaneously. The concept of a port number emerged as a logical addressing mechanism to multiplex traffic, allowing a single machine to host a web server, an email daemon, and a file transfer service all at once. Without ports, every host could only sustain a single network conversation at a time—a crippling limitation for general-purpose computing.

Protocols evolved in tandem with these addressing schemes. Early protocols like NCP (Network Control Protocol) were replaced by the more robust TCP/IP suite in 1983, a transition known as "flag day." As the internet grew from a research curiosity into critical infrastructure, each new protocol—DNS for name resolution, HTTP for the web, SSH for secure remote administration—introduced both capabilities and attack surfaces. Understanding the historical trajectory of these protocols illuminates why certain design decisions persist and where security vulnerabilities originate.

The recurring theme across these milestones is a tension between functionality and security. Each protocol was designed to solve a communication problem—often in a trusted academic environment—and security was bolted on afterward. This historical pattern is precisely why understanding ports and protocols is essential for any security professional: the attack surface of a networked system is directly proportional to the number of open ports and the security posture of the protocols behind them.

Before diving into individual protocols, it is critical to establish a precise vocabulary. A port is a 16-bit unsigned integer (ranging from 0 to 65,535) that serves as an endpoint identifier for network communication on a host. Combined with an IP address, a port forms a socket—a unique tuple that the operating system kernel uses to route incoming packets to the correct process. A protocol is a formal specification defining the syntax, semantics, and synchronization rules for data exchange between network entities. Protocols operate at various layers of the OSI or TCP/IP model, and a given port is typically associated with a specific application-layer protocol by convention.

The diagram above illustrates how the layered architecture of TCP/IP creates an abstraction hierarchy. At the top, application-layer protocols such as HTTP, DNS, and SSH define the semantics of communication—what data means and how it is structured. These protocols bind to well-known ports that the transport layer (TCP or UDP) uses to demultiplex incoming traffic. The critical security insight is that vulnerabilities can exist at any layer: a buffer overflow in an application on port 80 (Layer 7), a TCP sequence prediction attack (Layer 4), IP spoofing (Layer 3), or ARP poisoning (Layer 2). Effective security requires awareness of the entire stack, not just the application layer.

TCP Three-Way Handshake

TCP's reliability begins with its connection establishment procedure, the three-way handshake. The client sends a SYN segment with an initial sequence number (ISN), the server responds with a SYN-ACK containing its own ISN and an acknowledgment of the client's ISN + 1, and the client completes the handshake with an ACK. This mechanism synchronizes sequence numbers and establishes state on both endpoints. From a security perspective, the handshake is vulnerable to SYN flood attacks, where an attacker sends massive volumes of SYN segments with spoofed source addresses, exhausting the server's connection table. Mitigations include SYN cookies (RFC 4987), rate limiting, and firewall-based half-open connection tracking.

UDP Simplicity and Implications

UDP's minimal header—only 8 bytes comprising source port, destination port, length, and checksum—makes it exceptionally lightweight. There is no handshake, no connection state, and no retransmission logic. This design is ideal for DNS queries (where a single request-response pair suffices) and real-time media streams (where a late packet is worse than a lost one). However, the lack of a handshake makes UDP susceptible to amplification attacks. An attacker can spoof the victim's IP address in a DNS query to an open resolver; the resolver sends its (much larger) response to the victim. Amplification factors for DNS can exceed 50×, making UDP-based services a favorite vector for distributed denial-of-service (DDoS) attacks.

DNS Resolution Process

The Domain Name System translates human-readable domain names (e.g., example.com) into IP addresses through a distributed, hierarchical lookup. A client's stub resolver queries a recursive resolver, which in turn queries root name servers, TLD (top-level domain) servers, and authoritative name servers in sequence, caching results according to TTL (time-to-live) values. DNS typically uses UDP port 53 for standard queries but falls back to TCP port 53 for zone transfers and responses exceeding 512 bytes (or 4,096 bytes with EDNS0). Security threats include DNS cache poisoning (injecting fraudulent records into a resolver's cache), DNS tunneling (encoding arbitrary data in DNS queries to exfiltrate information), and DNS hijacking. DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records to verify authenticity.

DHCP Lease Process

The Dynamic Host Configuration Protocol automates IP address assignment through a four-step broadcast exchange known as DORA: Discover (client broadcasts on UDP port 67), Offer (server responds on UDP port 68), Request (client selects an offer), and Acknowledge (server confirms the lease). Because DHCP relies on broadcast and has no built-in authentication, it is vulnerable to rogue DHCP server attacks (an attacker provides malicious gateway/DNS settings) and DHCP starvation (exhausting the address pool with forged requests). DHCP snooping on managed switches mitigates these threats by filtering unauthorized DHCP responses.

Several critical observations emerge from the protocol table above. First, the distinction between encrypted and unencrypted protocols has profound security implications: any credentials or sensitive data sent over HTTP, Telnet, or FTP can be captured by a network sniffer in plaintext. This is why security best practice mandates HTTPS for all web traffic (not just login pages), SSH instead of Telnet, and SFTP or SCP instead of FTP. Second, protocols like DNS and DHCP, which are fundamental to network bootstrapping, have historically lacked encryption and authentication—making them attractive targets for man-in-the-middle and spoofing attacks.

HTTP vs. HTTPS — The TLS Layer

HTTPS is not a separate protocol but rather HTTP layered over Transport Layer Security (TLS). During the TLS handshake, the client and server negotiate a cipher suite, the server presents a digital certificate (validated against a trusted Certificate Authority chain), and a symmetric session key is derived using asymmetric key exchange (typically ECDHE). All subsequent HTTP traffic is encrypted, ensuring confidentiality, integrity, and server authentication. Modern browsers flag HTTP sites as "Not Secure," and organizations should enforce HTTPS via HTTP Strict Transport Security (HSTS) headers to prevent protocol downgrade attacks.

SSH — Secure Shell Architecture

SSH provides three core services: encrypted remote shell access, secure file transfer (SFTP/SCP), and port forwarding (tunneling). The protocol uses a client-server model on TCP port 22. During connection, SSH negotiates encryption algorithms, performs host key verification (protecting against man-in-the-middle attacks), and authenticates the user via password, public key, or certificate-based methods. Public key authentication is strongly preferred over passwords because it eliminates the risk of brute-force attacks against weak passwords. SSH's port forwarding capability also makes it a powerful tool for securely accessing services behind firewalls, though this same capability can be exploited for unauthorized tunneling.

Consider this scenario: you are a security analyst who has been asked to audit a newly provisioned Linux web server. You run an Nmap scan and discover the following open ports: 22 (SSH), 23 (Telnet), 25 (SMTP), 53 (DNS), 80 (HTTP), 443 (HTTPS), and 3306 (MySQL). Your task is to identify security risks and recommend remediation actions.

The foundational understanding of ports and protocols presented in this lesson connects directly to several advanced security domains. Network segmentation and zero-trust architectures extend the principle of least privilege from individual ports to entire network zones, requiring authentication and authorization for every connection regardless of source. Deep packet inspection (DPI) goes beyond port-based filtering to analyze the actual payload content, detecting anomalies like encrypted C2 (command-and-control) traffic disguised as HTTPS or DNS tunneling on port 53. Modern firewalls operate as application-layer gateways, classifying traffic by protocol behavior rather than port number alone.

An important forward-looking trend is the convergence of encrypted protocols onto a small number of ports—primarily TCP 443. HTTPS, HTTP/2, HTTP/3 (QUIC over UDP 443), DoH, and even some VPN protocols all use port 443, partly because firewalls rarely block it. This trend complicates traditional port-based security models and drives adoption of traffic analysis, behavioral detection, and endpoint-centric security models that operate independently of port numbers. Understanding this evolution is essential as you advance into courses on intrusion detection, incident response, and security architecture.