1. TCP/IP & the Request/Response Model, Through a Security Lens
Every connection you'll ever secure or attack rides on the same handshake. TCP opens a connection with a three-way handshake before a single byte of real data moves — understanding it is the difference between reading a packet capture and just staring at hex:
Client Server
|----------- SYN ----------------->| "I want to connect, my starting sequence number is X"
|<------- SYN-ACK ------------------| "OK, here's mine, and I acknowledge yours"
|----------- ACK ----------------->| "Acknowledged, connection is open"
| |
|========= data flows ============>| (only now does HTTP, TLS, etc. begin)
A few security-relevant consequences fall straight out of this: a SYN flood attack works by sending SYNs and never completing the handshake, exhausting the server's table of half-open connections — a classic denial-of-service technique defended against with SYN cookies and rate limiting. A port scan (Week 11) is largely just sending SYNs to many ports and reading which ones reply SYN-ACK (open) versus RST (closed) versus nothing (filtered).
Application HTTP, DNS, TLS # where XSS, SQLi, auth flaws live (Weeks 4-7)
Transport TCP, UDP # where SYN floods & port scanning happen
Network IP, routing # where IP spoofing & subnetting/segmentation live
Link Ethernet, ARP # where ARP spoofing / MITM on a LAN happens
You don't need the full seven-layer OSI model memorized to do security work — you need to know, for any given attack or control, which layer it operates at, because that tells you where the defense has to live too. A WAF (Week 6) can't stop an ARP spoofing attack; a switch's port security can't stop a SQL injection. Matching the defense to the layer is half the job.
TCP's handshake and acknowledgments make IP spoofing hard to exploit for anything but a flood — an attacker can't easily complete a handshake with a spoofed source address, since the SYN-ACK goes to the real owner of that address, not the attacker. UDP has no handshake at all, which is exactly why UDP-based protocols (DNS included) are the usual vehicle for spoofing and amplification attacks.
2. DNS: How Names Resolve, and How That Gets Abused
DNS turns a name into an address, and almost everything trusts it implicitly — which is exactly why attacking DNS is such high leverage. A normal lookup walks a chain of trust:
Browser -> Resolver (usually your ISP or 1.1.1.1/8.8.8.8)
Resolver -> Root server ("who handles .com?")
Resolver -> .com TLD server ("who handles example.com?")
Resolver -> example.com's authoritative server ("what's the A record for www?")
Resolver <- 93.184.216.34
Browser <- 93.184.216.34 # now the browser opens a TCP connection to THIS address
Every one of those hops is a place trust can be abused. DNS spoofing / cache
poisoning tricks a resolver into caching a fraudulent record, redirecting
everyone who queries it to an attacker-controlled address. Typosquatting
registers a look-alike domain (gaogle.com) and relies on a human, not the
protocol, being fooled. DNS tunneling smuggles data inside DNS
queries themselves — an exfiltration channel defenders often forget to monitor because
"it's just DNS."
$ dig example.com A +short
93.184.216.34
$ dig example.com MX +short # mail servers -- a common phishing/spoofing target
$ dig example.com TXT +short # often holds SPF/DKIM/DMARC anti-spoofing records
DNSSEC adds cryptographic signatures to DNS records so a resolver can verify a response genuinely came from the authoritative source and wasn't tampered with in transit — the integrity leg of the CIA triad (Week 1), applied specifically to name resolution. It's not universally deployed, which is exactly why DNS spoofing is still a live threat in 2026.
3. Firewalls & Network Segmentation into Trust Zones
A firewall's job is simple to state and easy to get wrong in practice: allow the traffic that should be allowed, and nothing else. The default posture that actually holds up is default-deny — block everything, then explicitly allow only what's needed — rather than default-allow with a growing blocklist that's always a step behind.
# Order matters -- rules are evaluated top to bottom, first match wins
ALLOW inbound tcp/443 from ANY to WebServer # public HTTPS
ALLOW inbound tcp/22 from AdminSubnet to WebServer # SSH, admins only
ALLOW inbound tcp/5432 from WebServer to DBServer # app -> db, nothing else
DENY inbound ANY from ANY to ANY # default-deny catch-all
Segmentation is the same idea applied to network topology rather than individual rules: split a flat network into zones (public-facing, application, database, admin) so that compromising one zone doesn't hand an attacker a straight path to every other zone. This is the trust-boundary thinking from Week 1's DFD, applied to real network architecture.
Internet
|
[ DMZ / public subnet ] <- web server, load balancer
| (firewall: only 443 allowed through)
[ app subnet ] <- application servers, not internet-reachable
| (firewall: only the app port, from web servers only)
[ data subnet ] <- database, not internet-reachable, not app-server-reachable
except on its specific port
# A compromised web server can reach the app tier -- that's expected.
# A compromised web server can NOT reach the database directly -- that's the point.
Segmentation doesn't assume your web server will never be compromised — it assumes it eventually might be, and limits the blast radius when it happens. A single perimeter firewall around the whole network is one control; segmentation means an attacker who gets past it still has more locked doors ahead, not a flat network to roam.
4. VPNs: Encrypting Traffic Between Zones
A VPN does two related but distinct things: it encrypts traffic between two points, and it can extend a trust zone across an untrusted network — making a remote laptop behave, from the network's point of view, as if it's plugged into the internal LAN.
# Without a VPN, over public wifi:
Laptop --[plaintext or TLS per-app]--> Coffee-shop router --> Internet --> Company server
# With a VPN:
Laptop --[everything encrypted in one tunnel]--> VPN gateway --> Internal network
# ^ the coffee-shop router (and anyone on that wifi) sees only encrypted VPN traffic,
# not which internal services you're reaching or what's inside each request
This is why a corporate VPN historically doubled as network access control: connecting to it was what let a remote employee reach internal-only services in the first place, the same way being physically in the office would. The confidentiality-in-transit piece (encryption) and the network-access piece (reaching internal zones) are logically separate, even though one VPN connection often provides both at once.
A traditional VPN grants broad network access once connected — "on the VPN" often means "trusted like an internal device," full stop. Modern zero-trust architectures instead verify every single request on its own merits (identity, device posture, the specific resource) regardless of network location, precisely because "inside the VPN" turned out to be too coarse a trust boundary once one compromised laptop was enough to reach everything.
5. Capturing & Reading Traffic with Wireshark
Everything in Sections 1–4 is a model in your head until you've actually watched it happen on a wire. Wireshark captures every packet crossing a network interface and lets you inspect it down to the individual byte, layer by layer.
# Start a capture on your active interface (Wi-Fi/Ethernet), then visit any http:// site
# Useful display filters to type into the filter bar:
tcp.flags.syn == 1 # show only SYN packets -- watch the handshake happen
dns # show only DNS queries and responses
http # show only plaintext HTTP (not HTTPS -- that's encrypted)
ip.addr == 93.184.216.34 # show only traffic to/from one address
Follow a TCP stream (right-click a packet → Follow → TCP Stream) and Wireshark reassembles the whole conversation in order, which is exactly how a plaintext HTTP login form's username and password become visible as clear text to anyone who can see the traffic — the single most common demonstration of why HTTPS (Week 4) isn't optional for anything handling credentials.
Capturing your own traffic on your own machine, or traffic on a lab network you control, is fine and is exactly what this week's exercise does. Capturing traffic on a network you don't own or don't have explicit permission to monitor is a real legal line — the same authorization boundary Week 14 covers formally for penetration testing.
6. Hands-on Exercise
Capture real traffic, then design a segmented network on paper
Put Sections 1–5 to work on your own machine and on a hypothetical three-tier app.
Part 1 — Capture and read traffic:
- Install Wireshark, start a capture on your active network interface, and visit
http://neverssl.com(a site deliberately kept on plain HTTP for exactly this kind of exercise). - Filter to
tcp.flags.syn == 1and identify the SYN, SYN-ACK, and ACK of the handshake for that connection — note the sequence numbers and confirm they match Section 1's diagram. - Filter to
dnsand find the query/response pair that resolvedneverssl.comto an IP address — note the resolved address and confirm it matches where your HTTP request actually went. - Follow the HTTP request's TCP stream and locate the plaintext request/response — if the page has any form fields, note that anything submitted over plain HTTP would be visible exactly like this to anyone on the same network.
- Repeat the capture against an
https://site and confirm you can see the TCP handshake and TLS negotiation, but not the actual HTTP request/response content — write one sentence explaining why, in terms of Section 1's layers.
If your capture shows nothing, double-check you're capturing on the interface actually carrying your traffic (Wi-Fi vs. Ethernet), and that no VPN is active — a VPN encrypts everything into one tunnel, which is exactly Section 4's point, but it also means Wireshark on your local interface will only see encrypted VPN traffic, not the underlying requests.
Part 2 — Design a segmented network:
You're securing a simple app: a public web tier, an internal application tier, and a database — the same three-tier shape from Section 3.
- Draw the three tiers as separate network zones/subnets, following Section 3's diagram as a starting shape.
- Write a default-deny firewall rule set (in the style of Section 3's example) for each boundary between zones — be specific about ports and source/destination, not just "allow app traffic."
- Add a fourth zone: an admin/bastion subnet that's the only place SSH access to any tier is allowed from — no tier should accept SSH directly from the public internet.
- Walk through what happens if the web tier is fully compromised (an attacker has a shell on it): using your rule set, list exactly what the attacker can and can't reach next, and confirm the database isn't directly reachable.
- Add one VPN-relevant design decision: should the admin/bastion subnet be reachable only over VPN, or exposed with its own controls? Justify your choice in 2–3 sentences using Section 4's tradeoffs.
The "walk through a compromised web tier" step is the actual test of whether your segmentation works — if your rule set lets the web tier reach the database directly "just in case," that's the exact flat-network mistake Section 3 is warning against. Push back on your own first draft.
7. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
Why is a SYN flood effective specifically against TCP, and not something you'd typically see targeting UDP the same way?
Why is a SYN flood effective specifically against TCP, and not something you'd typically see targeting UDP the same way?
TCP requires the server to allocate state for every SYN it receives — a half-open connection sitting in a table waiting for the final ACK. Flooding SYNs exhausts that table. UDP has no handshake or connection state to exhaust in the same way, so a UDP-based attack (like a DNS amplification flood) works through a different mechanism entirely: overwhelming bandwidth or processing, not a connection-state table.
Q2
What does DNS cache poisoning actually change, and why does that make it so effective?
What does DNS cache poisoning actually change, and why does that make it so effective?
It tricks a resolver into caching a fraudulent record, so every subsequent lookup through that resolver returns the attacker's address instead of the real one — without touching the victim's browser, DNS settings, or the real authoritative server at all. It's effective because DNS is trusted implicitly by nearly everything, and a single poisoned resolver can redirect every client that queries it.
Q3
In a default-deny firewall rule set, what happens to traffic that doesn't match any explicit ALLOW rule?
In a default-deny firewall rule set, what happens to traffic that doesn't match any explicit ALLOW rule?
It's blocked, by the catch-all DENY rule at the end of the list. This is the entire point of default-deny: rather than trying to enumerate every bad thing to block (default-allow with a blocklist, always a step behind new threats), you enumerate the specific, known-good traffic and reject everything else by default.
Q4
A company's VPN grants full internal network access to any connected device. What's the modern criticism of this model, and what does zero trust do differently?
A company's VPN grants full internal network access to any connected device. What's the modern criticism of this model, and what does zero trust do differently?
"Connected to the VPN" is a coarse, all-or-nothing trust boundary — one compromised laptop on the VPN can potentially reach everything internal, the same broad access a legitimate employee has. Zero trust instead verifies every individual request against identity, device posture, and the specific resource being accessed, regardless of network location, rather than granting broad access just for being "inside."