Ports, DNS & HTTP

The ports hackers memorize, how DNS resolves, and the anatomy of an HTTP request.

Medium 20 minportsdnshttp

You type a URL and press Enter. What happens? Before your browser renders a single pixel, a chain of protocols fires in sequence - port lookups, DNS resolution, TCP handshakes, and HTTP negotiation. This lesson walks through every link in that chain, and explains what each one looks like to an attacker doing reconnaissance.

Ethics First - Every Lesson, Every Time

All enumeration and interception techniques described here are for authorized testing, CTF competitions, and building defensive intuition. Never run these against systems you do not own or have explicit written permission to test.

Well-Known Ports

A port is a 16-bit number (0-65535). The well-known ports (0-1023) are assigned by IANA and represent the services every penetration tester memorizes. Finding one of these open is immediately actionable.

Port	Protocol	Service	Hacker notes
21	TCP	FTP	Often allows anonymous login; credentials in plaintext
22	TCP	SSH	Version banner leaks OS; brute-force or key misconfigs
23	TCP	Telnet	Plaintext - capture creds with a MITM; nearly extinct but still found on IoT
25	TCP	SMTP	Email relay; open relays enable spam/phishing pivot
53	TCP/UDP	DNS	Zone transfer (`axfr`) can dump entire subdomain list
80	TCP	HTTP	Plaintext web - intercept with Burp; find hidden paths
110	TCP	POP3	Plaintext email retrieval
143	TCP	IMAP	Plaintext email; brute-force credential target
443	TCP	HTTPS	TLS-wrapped HTTP; check cert for hostnames, SANs
445	TCP	SMB	EternalBlue (MS17-010), pass-the-hash, relay attacks
3306	TCP	MySQL	DB exposed to network? Check for weak/default creds
3389	TCP	RDP	BlueKeep (CVE-2019-0708); brute-force; screenshot login
5432	TCP	PostgreSQL	DB credential brute-force, potential RCE via COPY TO
6379	TCP	Redis	Often unauthenticated; write SSH keys or cron jobs
8080/8443	TCP	Alt HTTP/HTTPS	Dev/staging panels, Jenkins, Tomcat manager
27017	TCP	MongoDB	Often completely unauthenticated in default installs

The Ports Recon Workflow

nmap -sV -sC -p- against a target gives you version strings for every open port. Each service version feeds directly into searchsploit and NVD lookups. Port 6379 (Redis) unauthenticated and port 27017 (MongoDB) unauthenticated are still found on production systems with alarming frequency.

kali@vr4cs: ~

DNS: The Internet's Phone Book

DNS (Domain Name System) translates human-readable names like example.com into IP addresses. Without DNS, you'd have to memorize numeric IPs for every site.

How DNS Resolution Works

Your browser asks: "What is the IP for www.example.com?"
 
1. OS checks /etc/hosts (local override)
2. OS checks local DNS cache
3. OS queries the configured resolver (e.g., 8.8.8.8 - your ISP or a public resolver)
4. Resolver checks its own cache
5. If not cached: resolver performs RECURSIVE RESOLUTION:
   a. Query root nameservers (.) → "Who handles .com?"
   b. Query .com TLD nameservers → "Who handles example.com?"
   c. Query example.com authoritative nameservers → "What is www.example.com?"
6. Authoritative answer: 93.184.216.34
7. Resolver caches it (TTL-limited) and returns it to you
8. Your browser connects to 93.184.216.34:443

DNS Record Types

Record	Purpose	Example
A	IPv4 address for a hostname	`www.example.com → 93.184.216.34`
AAAA	IPv6 address for a hostname	`www.example.com → 2606:2800:220:1:248:1893:25c8:1946`
CNAME	Alias pointing to another hostname	`blog.example.com → example.ghost.io`
MX	Mail exchange servers (with priority)	`example.com MX 10 mail.example.com`
TXT	Arbitrary text - SPF, DKIM, verification tokens	`"v=spf1 include:_spf.google.com ~all"`
NS	Authoritative nameservers for a domain	`example.com NS ns1.example.com`
SOA	Start of Authority - zone metadata	Serial, refresh, retry, expire values
PTR	Reverse lookup: IP → hostname	`34.216.184.93.in-addr.arpa → www.example.com`
SRV	Service location (used by SIP, LDAP, etc.)	`_ldap._tcp.example.com SRV 0 5 389 dc1.example.com`

Hacker relevance: DNS records are a goldmine for passive recon. MX records reveal email providers (which may have their own attack surface). TXT records leak SPF/DKIM config and sometimes cloud verification tokens. NS records identify hosting infrastructure.

kali@vr4cs: ~

DNS Zone Transfers in the Wild

A zone transfer (AXFR) was designed to let secondary nameservers sync with the primary. When misconfigured to allow transfers from any IP, it dumps every DNS record for the domain in one query - hostnames, IPs, internal naming conventions, everything. This was extremely common in the early 2000s; it's rare now but still crops up on internal corporate DNS servers. It's always worth a quick test during recon.

HTTP: The Web's Protocol

HTTP (HyperText Transfer Protocol) is the application-layer protocol that powers the web. It's a request/response protocol - the client sends a request, the server returns a response.

HTTP Request Anatomy

GET /login HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9
Cookie: session=abc123def456; theme=dark
Connection: keep-alive

Key fields:

Method (GET): what action to perform (see table below)
Path (/login): the resource being requested
HTTP version (HTTP/1.1): the protocol version
Host: the target domain (critical for virtual hosting - one IP, many domains)
Cookie: session identifiers - the primary target for session hijacking
Content-Type + body: present in POST/PUT/PATCH requests with data

HTTP Methods

Method	Purpose	Attack relevance
GET	Retrieve a resource	Parameters in URL - visible in logs, no body
POST	Submit data to server	Form submissions, API calls - body carries payload
PUT	Replace a resource	If unauthenticated: arbitrary file upload
PATCH	Partially update a resource	IDOR targets when ID is in URL or body
DELETE	Remove a resource	IDOR - delete other users' data
OPTIONS	Query supported methods	Reveals what the server accepts
HEAD	Like GET but no body	Fingerprinting without downloading content

HTTP Response Anatomy

HTTP/1.1 200 OK
Date: Mon, 26 May 2025 10:00:00 GMT
Server: nginx/1.18.0
Content-Type: text/html; charset=UTF-8
Set-Cookie: session=xyz789; HttpOnly; Secure; SameSite=Strict
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'
Content-Length: 4523
 
<!DOCTYPE html>
<html>...

HTTP Status Codes

Code	Meaning	Attacker notes
200	OK	Resource exists and was returned
201	Created	Something was created (POST/PUT succeeded)
301/302	Redirect	Note the `Location:` header - redirect chains matter
400	Bad Request	Malformed input - useful for probing parsers
401	Unauthorized	Auth required; look for default creds
403	Forbidden	You're authenticated (or not) but access denied - try to bypass
404	Not Found	Resource doesn't exist at that path
405	Method Not Allowed	Try other HTTP methods
429	Too Many Requests	Rate limiting - slow down or rotate
500	Internal Server Error	Unhandled exception - often leaks stack traces
502	Bad Gateway	Backend is down or misconfigured
503	Service Unavailable	Useful target for DoS validation

403 is Not Always Final

A 403 Forbidden response is a starting point, not a dead end. Common bypasses: change the HTTP method, add X-Forwarded-For: 127.0.0.1, try path traversal variations (/admin/, //admin, /admin;/), or add headers like X-Original-URL: /admin. Misconfigured proxies and WAFs often respond differently based on these variations.

Cookies, Sessions, and Authentication State

HTTP is stateless - each request is independent. Cookies are how servers maintain the illusion of state.

1. User logs in → POST /login with credentials
2. Server verifies → creates a session ID in its database
3. Server responds with → Set-Cookie: session=s3cr3ttoken; HttpOnly; Secure
4. Browser stores the cookie
5. Every subsequent request → Cookie: session=s3cr3ttoken
6. Server looks up s3cr3ttoken in DB → "this is Alice, she has role=admin"

Cookie security flags:

HttpOnly: JavaScript cannot read the cookie - blocks XSS-based theft
Secure: cookie only sent over HTTPS - prevents interception on HTTP
SameSite=Strict: cookie not sent with cross-site requests - blocks CSRF
SameSite=Lax: sent with top-level navigation GET but not with cross-site AJAX
SameSite=None: sent with all cross-origin requests - requires Secure

Attacker implications: A session cookie missing HttpOnly is vulnerable to XSS-based theft. Missing Secure means it can be stolen on HTTP. Missing SameSite opens the door to CSRF. Reading response headers is recon - the flags tell you exactly what attack surface exists.

HTTPS and TLS

HTTPS is HTTP running over TLS (Transport Layer Security). TLS provides:

Encryption: data in transit is unreadable to observers
Authentication: the server's certificate proves its identity
Integrity: a MAC ensures data wasn't tampered with in transit

The TLS handshake happens before the HTTP request:

Client → ClientHello (TLS version, cipher suites, random)
Server → ServerHello (selected cipher, certificate, random)
Client → verifies certificate against trusted CA roots
Client → key exchange (creates session keys)
[Both sides derive the same symmetric session key]
Client → Finished
Server → Finished
[HTTP request/response flows encrypted]

Attacker relevance: The TLS certificate itself is intelligence - the Subject Alternative Names (SANs) list every hostname the cert covers, often revealing internal subdomains and staging environments. Tools like crt.sh query the public Certificate Transparency logs to enumerate every cert ever issued for a domain.

kali@vr4cs: ~

What Happens When You Type a URL and Press Enter

Here is the full sequence, layer by layer:

1. URL parsing Browser parses https://www.example.com/login?next=/dashboard into: scheme=https, host=www.example.com, path=/login, query=next=/dashboard.

2. DNS resolution OS checks /etc/hosts → local cache → configured DNS resolver → recursive resolution through root → .com TLD → authoritative nameserver for example.com → returns 93.184.216.34.

3. TCP handshake (port 443) OS performs the three-way handshake (SYN / SYN-ACK / ACK) with 93.184.216.34:443.

4. TLS handshake ClientHello → ServerHello + Certificate → key exchange → encrypted channel established. Browser verifies the cert chain to a trusted root CA.

5. HTTP request Browser sends the GET request over the encrypted TLS channel:

GET /login?next=/dashboard HTTP/1.1
Host: www.example.com
Cookie: theme=dark

6. Server processes the request Web server (nginx/Apache/Caddy) receives, routes to application. Application checks authentication, queries database if needed, generates HTML.

7. HTTP response Server sends the 200 OK with HTML body, headers including Set-Cookie if this is a new session.

8. Rendering Browser parses HTML, discovers additional resources (CSS, JS, images), triggers additional DNS lookups and HTTP requests for each.

9. Connection reuse / teardown HTTP/1.1 uses persistent connections (Connection: keep-alive) - the TCP connection stays open for subsequent requests. HTTP/2 multiplexes multiple requests over one connection. Eventually idle connections time out or are closed with FIN.

The Attacker's View of This Chain

Every step is an attack surface: DNS can be poisoned; the TLS cert reveals hostnames; the HTTP request carries session cookies; the response reveals server software versions; query parameters may be injection points; redirects may be open redirects; cookies may lack security flags. This is why understanding the full stack matters - exploitation is almost always at exactly one layer.

Key Takeaways

Memorize the critical ports: 22 (SSH), 80/443 (HTTP/S), 53 (DNS), 445 (SMB), 3306 (MySQL), 3389 (RDP), 6379 (Redis), 27017 (MongoDB).
DNS records are passive recon gold - especially TXT (SPF/DKIM), NS (hosting), and zone transfers (full subdomain list if misconfigured).
An HTTP request is: method + path + headers + optional body. A response is: status code + headers + body.
Cookie flags (HttpOnly, Secure, SameSite) directly determine XSS theft and CSRF vulnerability.
HTTPS/TLS encrypts the payload - but the certificate's SANs reveal hostnames through Certificate Transparency logs.
The "what happens when you type a URL" chain touches DNS, TCP, TLS, and HTTP in sequence - an attacker can target any layer.

TCP, UDP & the Handshake