Lesson Notes
Ports, Protocols, and Services
Module 2: Networking Basics. Pure theory—why ports matter (demultiplexing, IANA, sockets), common ports (FTP, SSH, HTTP/HTTPS, SMB, RDP, DNS, etc.), protocol–service binding and banners, HTTP vs HTTPS encryption deep dive, pentest enumeration to exploitation. Builds on TCP/IP and TLS.
Module 2: Ports, Protocols, and Services — Comprehensive Theoretical Guide
Module 2: Networking Basics. Pure theory (no labs or commands). For authorized cybersecurity pros: understand ports and services for recon, enumeration, and exploit targeting. Builds on TCP/IP, OSI layers, and TLS from Lesson 12. Includes HTTP/HTTPS deep dive with conceptual encryption flow.
1. Why Ports Matter: Demultiplexing Network Traffic
Ports are 16-bit numbers (0–65535) in the TCP or UDP header. They identify which service or application on a given IP address should receive the traffic. One host can run many services (web, SSH, database); the port tells the stack which process to hand the data to. Pentest value: port scanning reveals the attack surface—open 80/443 suggests web apps (injection, XSS, dir busting); open 22 suggests SSH (brute-force, key theft); open 445 suggests SMB (e.g. EternalBlue). IANA assigns well-known ports (0–1023), e.g. HTTP=80, HTTPS=443, SSH=22; registered ports (1024–49151) and dynamic/ephemeral (49152+) are used for other or short-lived connections. Threat model: every exposed service is a potential vector; a large share of breaches involve web applications (OWASP). Socket concept: a full endpoint is IP:Port (e.g. 192.168.1.10:80). Clients typically use ephemeral (high) source ports; servers listen on fixed well-known or registered ports.
2. Common Ports, Protocols, and Services (Pentest-Relevant)
TCP services (unless noted). 20/21 FTP: file transfer (control and data). Risks: anonymous login, plaintext credentials, bounce attacks. 22 SSH: secure shell and remote access. Risks: brute-force, key theft, weak algorithms (e.g. legacy MD5 HMAC). 23 Telnet: unencrypted remote shell; full plaintext—sniffable and MITM-prone. 25, 465, 587 SMTP/SMTPS: sending email. Risks: relay abuse, spoofing, historical RCE (e.g. Procmail). 53 DNS (TCP and UDP): name resolution. Risks: cache poisoning, amplification DDoS, zone transfer. 80 HTTP: web, unencrypted. Risks: XSS, SQLi, directory busting, vulnerable apps. 110, 143, 993 POP3/IMAP/IMAPS: retrieving email; plaintext creds if not SSL/TLS. 443 HTTPS: web over TLS. Risks: historical Heartbleed, weak ciphers, cert pinning bypass if misconfigured. 445 SMB: file and printer sharing (Windows). Risks: EternalBlue (MS17-010), NTLM relay. 3389 RDP: Remote Desktop. Risks: BlueKeep (CVE-2019-0708), brute-force. 5432 PostgreSQL, 6379 Redis: database services; default creds, SQLi via app, or unauth access (e.g. Redis). UDP-focused: 53 DNS, 161/162 SNMP (community string enum), 69 TFTP (no authentication).
3. Protocol–Service Binding and State Machines
TCP services are stateful: a handshake is required before data. A port scan (e.g. SYN to port 80) can elicit a response; version detection can then read a banner (e.g. "Apache 2.4.52") from the service. UDP services are stateless (fire-and-forget); scanning often means sending a probe and observing either an ICMP unreachable or an application response. Banner grabbing: many services respond with a version string (e.g. "SSH-2.0-OpenSSH_8.9"). That string is used for CVE lookup and exploit matching (e.g. OpenSSH below a version affected by regreSSHion). Service discovery flow in theory: (1) Resolve hostname via DNS (port 53) to get IP. (2) Port scan to find open ports. (3) Version detection to identify service and version. (4) Vulnerability matching to known exploits (e.g. CVE-2021-41773 for a specific HTTP server).
4. HTTP vs HTTPS: Encryption Deep Dive (Conceptual)
HTTP (port 80) is plaintext. Flow: client opens TCP to port 80, sends a request (e.g. GET / HTTP/1.1 or POST with form data), server responds with HTML or other content. Everything—headers, cookies, POST bodies (e.g. user=alice&pass=secret)—is visible to anyone on the path. A MITM can read and tamper with credentials and sessions. There is no encryption and no integrity protection. HTTPS (port 443) runs HTTP over TLS. The stack is TCP:443 plus the TLS record layer. After the TLS handshake, a symmetric key (e.g. AES) is used to encrypt application data. A conceptual "curl" view: with HTTP, a request like "user=alice&pass=secret" would appear in plaintext in a capture; with HTTPS, the same payload is inside TLS Application Data and appears as ciphertext—a MITM cannot read it. Handshake recap (from TLS theory): ClientHello (ciphers, SNI) over TCP:443; ServerHello and certificate; ECDHE key exchange → AES session key; then encrypted HTTP over TLS records. Key differences: HTTP has no encryption and high MITM risk (creds easily stolen); HTTPS uses TLS 1.2/1.3 (AEAD), low MITM risk with PFS, and integrity (e.g. HMAC/AEAD). For pentest: HTTP suggests dir fuzz, XSS, injection; HTTPS suggests SSL/TLS cipher enum, downgrade tests, and cert validation. Pitfalls: mixed content (HTTP assets on an HTTPS page), HSTS bypass (first visit or misconfig), and OCSP stapling or revocation checks.
5. Pentest Applications: Enumeration to Exploitation
Recon: port scan → identify open ports → version detection → match to known vulnerabilities (e.g. OpenSSH below a patched version → regreSSHion). Layered attacks: e.g. open 445 (SMB) → MS17-010 → compromise and lateral movement. HTTP/HTTPS chains: HTTP redirect or missing HSTS → phishing or downgrade; HTTPS with weak TLS → historical issues like BEAST (CBC) or cipher downgrade. Detection: unexpected open ports (e.g. 8080 proxy, 3389 RDP), or version mismatches (old server software). Evolution: HTTP/2 (multiplexing over one connection), HTTP/3 (QUIC over UDP with TLS built in). Pentest mindset: ports are doors. Map all listening ports, enumerate services and versions, match to CVEs and exploit only within authorized scope, then recommend hardening: firewall (close unnecessary ports), TLS 1.3 for all web and sensitive traffic, and WAF/application controls where appropriate.
Key Takeaway for Lesson 13
Ports (0–65535) demultiplex traffic to services on an IP host; well-known ports (e.g. 80, 443, 22) identify common protocols. Knowing common port–service bindings (FTP, SSH, HTTP, HTTPS, SMB, RDP, DNS, etc.) and their typical attacks supports recon and enumeration. TCP services are stateful and often reveal banners for version/CVE matching; UDP services are stateless and require different scan techniques. HTTP (80) is plaintext and high risk; HTTPS (443) encrypts with TLS so MITM sees ciphertext. In pentesting, map ports → services → versions → vulnerabilities, exploit ethically within scope, and recommend firewall rules, TLS 1.3, and application security. Next: hands-on Wireshark to spot unencrypted vs TLS traffic.