Network Security — Firewalls, WAF, MITM & DDoS

You don't need to be a security specialist to pass a backend interview, but you are expected to know where each of these four controls sits in the stack and what it does and doesn't protect against — that breadth-over-depth understanding is exactly what gets probed. The recurring theme: each control operates at a specific layer, sees a specific slice of traffic, and stopping one class of attack says nothing about another.

What Is Network Security?

Network security is the set of tools that keep a service's traffic safe from being blocked, spied on, or abused. Four terms come up constantly, each guarding a different door:

• Firewall — a gatekeeper that decides which connections are even allowed to reach a server, based on address and port.
• WAF (Web Application Firewall) — a filter that reads the actual content of a web request and blocks malicious-looking ones.
• MITM (Man-in-the-Middle) — an attack where someone secretly intercepts traffic between two parties.
• DDoS (Distributed Denial of Service) — flooding a service with so much traffic from so many sources that real users can't get through.

Where This Is Used

• Every bank and shopping app relies on HTTPS/TLS so a stranger on public Wi-Fi can't read your card details — that's defense against MITM.
• Cloudflare and AWS Shield sit in front of major websites specifically to absorb DDoS floods before they reach the origin servers.
• A company's cloud security group, blocking every port except 443, is a firewall rule in action.
• Login pages on sites like Gmail use WAF-style filtering to catch attempts to inject malicious code through the username field.

A Day-to-Day Example

Picture an office building. The firewall is the security guard at the front door checking ID badges before anyone gets in. The WAF is a second guard who actually reads the contents of any package before it's allowed upstairs. A MITM attack is someone secretly steaming open your mail, reading it, and resealing it before it reaches you. A DDoS attack is a crowd of impostors flooding the lobby so real employees can't get through the door at all.

Deep Dive: Firewall vs WAF — What Each One Actually Sees

Layer 7 (Application):  HTTP request:
                         POST /login HTTP/1.1
                         Host: app.example.com
                         Content-Type: application/x-www-form-urlencoded

                         username=admin' OR '1'='1&password=x
                         ▲
                         WAF inspects THIS — sees the actual payload,
                         recognizes the SQL injection pattern, blocks it.

Layer 3/4 (Network/Transport):  src=203.0.113.7:51423 dst=10.0.0.5:443 proto=TCP SYN
                         ▲
                         Firewall inspects THIS — sees only IP/port/protocol,
                         has zero visibility into the HTTP payload above,
                         so it has no way to know this connection carries
                         a SQL injection attempt at all.

A firewall rule like "allow TCP 443 from anywhere, deny TCP 5432 from the internet" operates purely on connection metadata — it's a decision about whether a connection is even allowed to exist, made before any application data is inspected. A WAF sits logically in front of (or beside) the application and parses the actual HTTP request content against rule sets, commonly OWASP Core Rule Set patterns, to catch things like SQL injection, XSS payloads, and path traversal attempts that a firewall structurally cannot see, because by the time you're looking at those patterns you're already deep inside what a firewall treats as an opaque encrypted/application payload.

Deep Dive: How TLS Actually Defeats MITM

Normal:        Client ---(encrypted, cert validated)--- Server

MITM attempt:  Client ---???--- Attacker ---???--- Server
               Attacker needs the client to accept a certificate for
               example.com that the attacker controls the private key for.
               Without a valid CA-signed cert for that exact hostname,
               the client's TLS stack detects the mismatch and the
               handshake fails loudly (browser cert warning / connection
               refused) — it does NOT silently downgrade to plaintext.

This is why TLS is the primary defense against MITM specifically: certificate validation forces the attacker to either present an untrusted certificate (which fails visibly) or actually compromise a trusted CA / trick the client into trusting a rogue root (rare, high-effort, and the class of attack certificate transparency logs and HSTS/certificate pinning exist to catch). An attacker on an unsecured public Wi-Fi network can see and even alter the encrypted bytes flowing past, but without the private key for a valid certificate they can't decrypt them or forge a convincing response.

Deep Dive: DDoS — Attack Types and Where Each Defense Lives

• Volumetric — raw bandwidth exhaustion (e.g. a UDP or DNS amplification flood). Defended by CDN/edge absorption spreading traffic across a huge distributed footprint, far from your actual origin infrastructure.
• Protocol — exhausting connection-handling state rather than bandwidth, classically a SYN flood: the attacker sends TCP SYN packets and never completes the handshake, filling the server's half-open-connection table. Defended by SYN cookies, connection-table tuning, and upstream scrubbing.
• Application-layer — traffic that looks like legitimate HTTP requests (real handshakes, real sessions) but at volume designed to exhaust application resources — CPU-heavy endpoints, database connections. This is the hardest to distinguish from a real traffic spike, since it mimics real usage; defended by rate limiting per client/IP/API key, WAF anomaly detection, and autoscaling to absorb legitimate load spikes while rate limiting catches abusive patterns.

The layering matters because no single control covers all three: a CDN absorbs volumetric traffic before it ever reaches your network, but it won't stop an application-layer flood using valid-looking requests against an expensive endpoint — that needs rate limiting and anomaly detection closer to the application itself.

Key Pointers

• A firewall filters traffic by IP, port, and protocol, operating mainly at L3/L4 (network/transport) — it decides whether a packet or connection is allowed to reach a host at all.
• A Web Application Firewall (WAF) sits at L7 (application layer) in front of web apps and APIs, inspecting actual HTTP request content to block patterns like SQL injection and XSS that a plain firewall can't see, often using OWASP-based rule sets.
• A Man-in-the-Middle (MITM) attack intercepts traffic between two parties, potentially reading or altering it in transit — e.g. over unsecured Wi-Fi, or via DNS/ARP spoofing.
• TLS prevents MITM from reading or tampering with traffic because the client cryptographically verifies the server's certificate chain and derives an encrypted channel the attacker can't decrypt or silently modify without detection.
• DDoS attacks flood a target with traffic from many sources to exhaust bandwidth, connection state, or application resources. Common types: volumetric (saturating bandwidth), protocol (e.g. SYN floods exhausting connection tables), and application-layer (HTTP floods that mimic real traffic).
• Mitigation is layered: rate limiting per client/IP/API key, scrubbing centers that filter malicious traffic before it reaches origin, and CDN edge absorption that spreads and caches load far from origin infrastructure.

How It Works

1. A firewall evaluates each packet or connection against rules (allowed IPs, ports, protocols) before it reaches the host — the basic perimeter control.
2. A WAF sits logically alongside or behind the firewall but in front of the application, parsing HTTP requests and blocking those matching malicious signatures or anomaly rules.
3. In a MITM attempt, the attacker positions itself on the network path — compromised Wi-Fi, ARP spoofing, DNS spoofing — and tries to intercept traffic between client and server.
4. TLS's certificate validation step detects an attacker presenting an untrusted or mismatched certificate, causing the client to abort the connection rather than silently trust it.
5. For DDoS, defenses layer together: a CDN/edge absorbs and caches most traffic, rate limiting throttles abusive clients, and scrubbing centers analyze and drop malicious packets before they ever reach origin, leaving only clean traffic to hit the backend.

Try It Yourself

# List local firewall rules (macOS packet filter)
sudo pfctl -s rules

# Check which ports are actually listening/reachable on a host
nmap -Pn -p 1-1000 example.com

# Verify a site's TLS certificate is valid and matches its hostname
# (a mismatch/expired cert here is exactly what stops a silent MITM)
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -subject -issuer -dates

# Inspect response headers a WAF/CDN typically adds (Cloudflare, AWS WAF, etc.
# often stamp identifying headers or a challenge page on suspicious traffic)
curl -I https://example.com

# Simulate a basic rate-limit check by firing repeated requests and watching
# for 429s and a Retry-After header
for i in {1..20}; do curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/ping; done

Interview Q&A

Q: Why can't a firewall alone stop a SQL injection attack?

A: A firewall makes allow/deny decisions based on IP address, port, and protocol — it never looks inside the HTTP payload. A SQL injection attempt is just the string ' OR '1'='1 sitting inside a normal-looking POST body on an allowed port (443) from an allowed protocol (HTTPS) — from the firewall's vantage point that's indistinguishable from any other legitimate request. Catching it requires something that actually parses application-layer content, which is exactly what a WAF is for.

Q: Does HTTPS fully protect against a man-in-the-middle attack?

A: It defeats the common case — passive eavesdropping and straightforward interception — because the attacker can't present a valid certificate for your domain without controlling a trusted CA or having compromised the private key. It's not an absolute guarantee: a client that's been tricked into trusting a malicious root certificate (e.g. via installed malware or a compromised corporate MDM profile) can still be MITM'd even over "valid" HTTPS, since validation succeeds against that rogue trusted root. That's an edge case worth naming, but the baseline answer is yes, properly validated TLS is the primary and highly effective defense.

Q: Your service is getting hit by what looks like a DDoS. Does adding rate limiting solve it?

A: It helps against smaller or single-source floods and is cheap to add, but a genuinely distributed attack — thousands of source IPs — can route around per-IP rate limiting almost entirely, since each individual source stays under the threshold. Real mitigation for volumetric attacks needs to happen further upstream, at a CDN or scrubbing-center layer with far more absorption capacity than your own infrastructure, with rate limiting as one layer among several rather than the whole defense.

Q: What's the difference between a protocol-layer and an application-layer DDoS attack, and why does it matter which one you're facing?

A: A protocol-layer attack (like a SYN flood) exploits the connection-establishment mechanism itself, exhausting a resource like the OS's connection table without needing valid application-level traffic at all — defended with SYN cookies and infrastructure-level tuning. An application-layer attack sends fully valid, completed HTTP requests, just at a volume or pattern designed to exhaust expensive backend resources (a heavy search endpoint, a database-hitting query) — it looks like real traffic, so it needs behavior-based detection (rate limiting, anomaly detection, WAF rules) rather than connection-level defenses, since the connections themselves are entirely legitimate.

System Design Tie-in

These four controls typically get drawn together as layered perimeter defense in any "design a public-facing service at scale" prompt: CDN/edge at the outermost layer (absorbs volumetric traffic, caches static content, terminates TLS), WAF next (blocks malicious request patterns before they reach application servers), then a firewall/security-group layer controlling which ports and IP ranges can even reach your infrastructure (e.g. database ports should never be reachable from the public internet at all), then rate limiting at the API gateway or application layer for abuse and application-layer DDoS. Expect a direct question like "how would you protect a login endpoint from brute-forcing" — the answer combines several of these: rate limiting per IP/account, a WAF rule for suspicious patterns, and account lockout/CAPTCHA as an application-level control none of the network-layer tools can provide on their own.

Trade-offs

Firewalls can't stop application-layer attacks like SQL injection or XSS because they don't inspect payload content — that's exactly what a WAF adds, at the cost of extra latency and occasional false positives on legitimate traffic. Rate limiting is the cheapest DDoS defense but can be overwhelmed by a large, distributed botnet; scrubbing and CDN absorption cost more but scale against genuinely volumetric attacks. The interview gotcha worth stating explicitly: HTTPS/TLS defeats passive eavesdropping and most active MITM tampering, but it does nothing against DDoS, and a firewall does nothing against a MITM attack — these are separate threats handled by separate, non-overlapping controls.