DDoS — Attacks and Mitigation

A DDoS — distributed denial of service — attack overwhelms a target with traffic from many sources at once, so the defender can't simply block one address. The attacks split cleanly by which layer they exhaust. Volumetric attacks saturate the pipe with sheer bandwidth, measured in hundreds of gigabits or terabits per second. Protocol attacks exhaust connection state — a SYN flood fills the half-open connection table without ever sending enough bytes to fill the link. Application-layer attacks send small numbers of expensive L7 requests that each cost the server far more to answer than they cost to send.

The defining property of DDoS is that you cannot out-provision a large botnet. A million compromised devices generate more traffic than any single origin server's link can absorb, so defense never means "buy a bigger server." It means absorbing the flood across distributed capacity, filtering the junk before it reaches the origin, or dispersing it so no single point sees the whole attack — and which of those works depends entirely on which layer the attack hits.

Attack Categories

Volumetric attacks are the brute-force kind: flood the target with more bits per second than its link can carry, and legitimate traffic queues behind the junk and drops. The attacker doesn't need to reach your server — saturating the upstream link is enough, which is why your own firewall can't stop a volumetric attack that already filled the pipe in front of it.

Protocol attacks target finite state rather than bandwidth. A SYN flood sends a torrent of TCP SYN packets with spoofed sources and never completes the handshake, filling the half-open connection table so legitimate SYNs find no slot. Application-layer attacks go higher still: a flood of HTTP requests that each trigger an expensive database query or a cache miss, so a few thousand requests per second — trivial bandwidth — bring the server to its knees because each one is costly to serve.

Amplification and Reflection

The largest volumetric attacks use amplification: the attacker sends small requests to public servers with the victim's address forged as the source, and those servers send much larger replies to the victim. The attacker spends a little bandwidth and the victim absorbs a lot. The multiplier is the amplification factor — the ratio of reply size to request size — and some protocols are catastrophic here.

DNS open resolvers amplify roughly 50x; NTP's monlist command around 557x; and memcached, exposed on UDP, has reached factors over 50,000x — the 2018 attacks that broke 1.7 Tbps. All of it depends on UDP source spoofing, because UDP is connectionless and the reflecting server has no way to verify the source address before replying. Running any of these services open to the internet makes you an unwitting weapon in someone else's attack.

# the amplification math: tiny spoofed request, huge reflected reply
# attacker -> open resolver:  60-byte query, src forged as victim
dig ANY example.com @open-resolver
# open resolver -> victim:    ~3000-byte answer  (≈ 50x amplification)
# memcached UDP can exceed 50,000x — a few Gbps of requests => Tbps at the victim

Mitigation Layers

Volumetric and protocol attacks are absorbed by capacity and dispersion that you almost never own yourself. Anycast announces the same address from dozens of locations, so an attack's traffic is split across every site that advertises the prefix instead of converging on one — a botnet hitting an anycast address spreads itself thin across the whole network's aggregate capacity. Scrubbing centers sit upstream with terabits of headroom, pull your traffic through, drop the attack, and forward the clean remainder.

Closer to the host, SYN cookies defeat SYN floods by encoding the connection state into the sequence number itself, so the server allocates no table entry until the handshake completes — there is nothing to exhaust. Rate limiting caps requests per source, but it is weak against spoofing and large botnets where each source sends little. These local defenses help against modest attacks and buy time, but they can't absorb a multi-hundred-gigabit flood that has already saturated the link.

Application-Layer Defense

Application-layer attacks are the hardest to filter precisely because the requests look legitimate. A flood of valid-looking HTTP GETs is, packet for packet, indistinguishable from real traffic — the attack lives in the cost of serving them, not in malformed packets a filter can spot. Bandwidth defense does nothing here; you need request intelligence.

A WAF inspects requests at L7 and blocks patterns — known bad signatures, abusive request rates per session, suspicious paths. Challenge mechanisms (a JavaScript proof-of-work or a CAPTCHA) force each client to do work or prove it's a browser, which a cheap bot can't afford at scale while a real user barely notices. The hard part is tuning: too aggressive and you block real users, too loose and the expensive requests still land.