Common Ports & Protocols

Port Number Ranges

A port is a 16-bit number that identifies a service or a client-side conversation so multiple connections can share one IP address.

---

Ports You Must Memorize

Web & file transfer

Email

Network services & remote access

Exam trap: match plaintext protocols to their encrypted upgrades. Telnet (23) -> SSH (22); HTTP (80) -> HTTPS (443); FTP (21) -> SFTP (22) or FTPS (990); LDAP (389) -> LDAPS (636).

---

DNS - Port 53

DNS (Domain Name System) maps human names to IP addresses. It usually uses UDP for fast lookups and TCP for large responses or zone transfers.

Diagnostic move: if ping 8.8.8.8 succeeds but ping google.com fails, connectivity is fine and DNS is broken. Use nslookup to confirm and ipconfig /flushdns to clear stale records.

---

DHCP - Ports 67/68

DHCP (Dynamic Host Configuration Protocol) automates client configuration via the DORA exchange:

1. Discover - client broadcasts a request for an address.
2. Offer - a DHCP server proposes an available lease.
3. Request - client formally requests the offered address.
4. Acknowledge - server confirms and records the lease.

A DHCP scope delivers the IP address, subnet mask, default gateway, DNS servers, and a lease time. When DHCP fails, the client falls back to a 169.254.x.x APIPA address - a classic exam tell for "DHCP server is down."

---

FTP - Ports 20/21

FTP separates control from data. Port 21 carries commands and authentication; port 20 carries the file data in active mode.

• Active mode: the server opens the data connection back to the client - often blocked by client-side firewalls.
• Passive mode: the client opens both connections - firewall-friendly and the modern default.

Security note: plain FTP and Telnet send credentials in cleartext. Prefer SFTP (22) or FTPS (990) and SSH (22) instead.

---

TCP vs. UDP at the Port Level

A single port number can mean different services depending on whether it rides TCP or UDP, so the exam often pairs a port with a transport protocol. DNS is the classic example: it uses UDP 53 for ordinary lookups because a single small query and answer fit in one datagram with no handshake overhead, but it falls back to TCP 53 for responses larger than 512 bytes and for zone transfers between name servers. DHCP runs entirely over UDP (server 67, client 68) because the client has no address yet and must broadcast, which connectionless UDP supports and connection-oriented TCP cannot.

Most other services - HTTP, HTTPS, SSH, SMTP, RDP, and SMB - are TCP because they need reliable, ordered delivery.

Why Secure Variants Exist

Early internet protocols carried everything, including passwords, in plaintext. Anyone capturing traffic with a tool such as a packet sniffer could read Telnet sessions, FTP credentials, or POP3 mailboxes. The modern fix is a TLS-protected variant on its own port: HTTP became HTTPS on 443, IMAP became IMAPS on 993, POP3 became POP3S on 995, and LDAP became LDAPS on 636. Some protocols instead upgrade the existing port in place using STARTTLS, which is why authenticated mail submission uses port 587 - the connection opens in the clear, then negotiates encryption before any credentials are sent.

On the exam, when a question asks how to secure an existing plaintext service, the answer is almost always "switch to the encrypted variant on its dedicated port" rather than "hide the service" or "change the password."

A Port-Troubleshooting Scenario

A user can reach an internal web server by IP on port 80 but a new HTTPS site times out. Because plain HTTP works, Layer 3 connectivity and the route are fine; the failure is specific to port 443. The most common causes are a firewall rule blocking 443 inbound, a missing or expired TLS certificate on the server, or the service simply not listening on 443. Running netstat on the server reveals whether anything is bound to port 443, and checking the firewall rule set confirms whether 443 is permitted. This isolates the problem to the transport/application layers rather than the physical link.