System Design Masterclass · Module 28 · Extension of Week 2
Edge Security & DDoS Mitigation
Modules 08–11 built an edge that can serve five million fans; this one keeps it serving when some of the traffic is hostile. The attack taxonomy by layer, the defense stack from anycast to WAF to bot management, and the OTT-specific threats — credential stuffing and match-night extortion — that generic guides skip.
~2.5h study~1h exercise1 interactive simFast track ~65 min
Fast track — survived an attack already?
Compresses to ~65 min. The taxonomy collapses to the layer distinction; the defense-stack sim, L7/bot economics, and the OTT threat model stay mandatory.
§01 takeaway · 5 min
§02 sim, all three attacks · 15 min · MANDATORY
§03 L7 & bots, in full · 20 min · MANDATORY
§04 OTT threats, in full · 15 min · MANDATORY
STEP 01
The taxonomy: one distinction carries it
SKIM
Fast-track takeawayL3/4 volumetric attacks (UDP amplification/reflection off open resolvers and NTP, SYN floods, raw packet floods — hundreds of Gbps to Tbps) attack pipes and connection tables: no valid request ever forms, so the defense is capacity and filtering before your infrastructure — anycast dispersion and scrubbing. L7 application attacks (HTTP floods, cache-busting query storms, expensive-endpoint abuse, slowloris) send well-formed requests that are individually indistinguishable from users — small bandwidth, aimed at your compute, caches, and origin; defense is classification and cost-asymmetry at the edge. The distinction matters because every defense works at exactly one of the two: scrubbing can't read intent, and a WAF can't absorb a terabit. Mixed campaigns (volumetric smokescreen + quiet L7 spear) are standard — expect both at once.
STEP 02
The defense stack, layer by layer
MANDATORY
Launch each attack and watch where it should die. A defense stack is healthy when every attack is absorbed at the cheapest capable layer:
Where does the attack die?
Anycast network
attack disperses across every POP globally — no single pipe receives the sum (M11)
Scrubbing / packet filters
line-rate L3/4 filtering: drop amplification signatures, SYN cookies for handshake floods
CDN / edge cache
cacheable requests never reach origin (M10) — a cache hit is a free defense
WAF + bot mgmt + edge limits
classify L7: signatures, behavior, challenges, per-key rate limits (M14 at the edge)
Origin / services
admission control & priority shedding (M14) — the last line, protecting goodput
Anycast + scrubbing handle volume; cache + WAF handle intent; your origin should meet almost nothing raw.
Anycast is the volumetric foundation (M11's second job): one IP announced from 100+ POPs means an 800 Gbps flood arrives as ~8 Gbps per site — survivable arithmetic. This is why serious edges are anycast even ignoring latency, and why DIY single-region edges have a hard ceiling no firewall fixes.
Scrubbing: filtering infrastructure (in-line at the provider, or BGP-diverted "scrubbing centers" for on-prem estates) dropping malformed/amplification/flood traffic at line rate; SYN cookies answer handshake floods statelessly so connection tables can't be exhausted.
Protect the origin's address: all of this is bypassable if attackers learn your origin IPs — origin behind the CDN with allow-listed CDN ranges only, no DNS history leaks, separate IPs for mail/other services. The classic breach of this rule: an old A record pointing straight at origin, found in DNS archives.
STEP 03
L7 defense: classification and cost-asymmetry
MANDATORY
WAF: managed rule sets (OWASP-class: injection, traversal) + custom rules for your API shapes. Run new rules in count/observe mode first (M21's observe-then-enforce invariant) — the WAF that blocks a legitimate TV client's quirky header during a final is a self-inflicted incident. Treat WAF rules as code: versioned, reviewed, with false-positive dashboards.
Edge rate limiting is M14 moved to the cheapest layer: per-IP as the crude pre-auth floor, per-token/device once identified, per-ASN/fingerprint for distributed-but-lazy botnets, and cost-weighted (search and login weighted heavier). The goal is asymmetry: make each hostile request cost the attacker more (challenges, computational proofs) and you less (reject before deserialization).
Cache-busting is the L7 attack aimed at Module 10: random query strings force cache misses, converting your CDN from shield to funnel. Defenses are cache-key normalization (strip unknown params — M10 §02 was also a security control), strict allowed-param lists per route, and treating miss-ratio-per-client as a detection signal.
Bot management beyond CAPTCHAs: TLS/HTTP fingerprinting (JA3-class), behavioral signals (request pacing, header entropy, impossible navigation), device attestation on your own apps (you control the clients — a signed-integrity token from the app is stronger than any fingerprint), and tiered responses: allow → throttle → challenge → block. Silent throttling beats blocking for uncertain cases — blocked bots adapt immediately; slowed bots often don't notice.
Know your expensive endpoints: search, login, password-reset, anything fanning out (M02's ×N) — attackers find them by timing; you should find them first and give each a budget (M14) and a cheap pre-check.
STEP 04
The OTT threat model
MANDATORY
Credential stuffing is your #1 by volume: breached password lists replayed against login — distinguishable from users by per-IP/ASN failure rates, credential-set velocity, and fingerprint reuse. Defenses: edge limits on auth endpoints, breach-list checking at login, MFA/step-up on anomalies, and the M22 device flow keeping TVs out of the credential path entirely. Success metric: account-takeover rate, not blocked-request count.
Match-night extortion is the scenario to plan for: DDoS timed to kickoff, when your legitimate traffic is already a 5–20× spike (M25) — meaning your baseline anomaly detection is blind and your headroom is minimal. The event playbook (M10/M25) gets a security section: provider attack-readiness confirmed, WAF in strictest proven mode, an "under-attack" switch pre-configured (challenge-everything with your own apps exempt via attestation), and the decision tree for who flips it, pre-agreed — mid-match is not the time to invent policy (M13's pre-signed-decision principle, again).
Restream/leech detection at the edge: segment-request patterns that aren't players (no manifest rhythm, sequential bulk fetch, token reuse across ASNs) feed M23's watermark-and-takedown loop — edge logs are the sensor.
Attack traffic vs the herd: your hardest classification problem is that kickoff joins (M10's thundering herd) look like an HTTP flood. The differentiators you must build in advance: attested-client rate vs anonymous rate, token-bearing vs tokenless ratios, and per-endpoint mix — legitimate herds hit manifest+license in the product's rhythm; floods don't. If you can't split those on a dashboard today, you'll shed real fans during the real attack.
Staff expectationFraming edge security as capacity engineering against an adversarial load model — the same M02/M25 arithmetic with an attacker choosing the worst-case mix. The review questions: "what's our absorbable Gbps and rps by layer? which endpoint is cheapest for an attacker per unit of our cost? what does the under-attack mode degrade, and who owns the switch at minute 80 of a final?" Answering those from memory is the difference between a security posture and a security vendor invoice.
STEP 05
Exercise
MANDATORY
Fast trackStep 3 (~25 min): the herd-vs-flood dashboard design is the artifact your platform most likely lacks.
1
Build the asymmetry locally. nginx/Envoy edge in front of a Spring service: per-IP rate limits, an allowed-query-param cache key, and a lua/filter challenge for tokenless clients. Attack it with wrk using randomized query strings — measure origin RPS before/after normalization; that delta is §03 made visible.
2
SYN-cookie demo. Local netns lab: hping3 SYN flood a listener with cookies off (watch the accept queue die) vs net.ipv4.tcp_syncookies=1. Ten minutes, permanent intuition for stateless handshake defense.
3
Paper — the split dashboard. Design the kickoff herd-vs-flood dashboard: attested vs anonymous rates, token-bearing ratio, per-endpoint mix, miss-ratio per client class, auth-failure velocity. Then write the under-attack decision tree (trigger thresholds, who flips it, what degrades) as the security page of your event runbook.
4
Audit origin exposure. Check DNS history services for records leaking your origin IPs; verify origin firewalls accept only CDN/edge ranges; list every service resolving straight past the edge. Findings → tickets.
Self-check
Why can't a WAF stop a terabit attack, and why can't scrubbing stop a credential-stuffing run?
Wrong layers both ways: a WAF inspects application requests — at terabit scale the pipe and packet path saturate before HTTP parsing begins; volume must die in the network (anycast dispersion + line-rate filtering). Scrubbing sees packets, not intent — stuffing traffic is perfectly valid TLS+HTTP at modest volume; only L7 classification (failure velocity, fingerprints, breach-lists) can see it. One distinction, whole module.
An attacker appends ?v=<random> to segment URLs. Trace the damage chain and the two-line fix.
Every request is a unique cache key → 100% miss → the CDN forwards the full attack to origin, which was sized for 98% offload (M25) — a small L7 flood becomes an origin-scale event via cache-busting. Fix: strict cache-key normalization (only whitelisted params keyed, rest stripped) at the edge, plus miss-ratio-per-client alerting so the next variant is seen in minutes.
Your under-attack mode challenges all traffic — and your smart-TV apps can't solve CAPTCHAs. Resolve the design.
Exempt your own clients by proof, not by heuristics: app-attestation tokens (signed by platform integrity APIs / your SDK) let the edge pass attested traffic unchallenged while challenging anonymous browsers. This must be built and rolled out *before* the incident — attestation coverage across TV firmware generations takes quarters, which is why §04 calls it pre-work. Interim: token-bearing sessions exempt, tokenless challenged.
Kickoff at 21:00; traffic jumps 12× in 90 seconds. Attack or audience — walk your first three dashboard checks.
(1) Attested/token-bearing ratio: real fans carry your app attestation and auth tokens; floods are predominantly anonymous. (2) Endpoint mix and rhythm: players hit manifest→license→segments in the product's cadence; floods concentrate oddly (one endpoint, no manifests, cache-busting params). (3) Failure/miss signals: auth-failure velocity and per-client miss ratios spike under attack, stay flat under audience. The answer is usually "both" — which is why shedding order (M14) must protect token-bearing playback first while the edge challenges the anonymous remainder.