DDoS - Attack Classes, Amplification and Defence
- A DDoS attack exhausts one of three things: bandwidth (volumetric), connection state (protocol attacks such as a SYN flood) or application work (HTTP floods, Slowloris, Rapid Reset). Find which one is running out first.
- It works because the attacker's cost per request is far below the defender's cost to serve it. UDP reflection multiplies that gap: a small spoofed query makes a third party send a much larger reply to the victim, by roughly 28x to 54x for DNS and up to about 51,000x for memcached.
- You cannot patch your way out. Defence is capacity plus position: absorb at an anycast edge, filter early (scrubbing, RTBH, Flowspec), keep servers stateless under load (SYN cookies), and push application-layer checks to a CDN or WAF.
- Source addresses in a flood are usually forged or botnet-distributed, so blocking by IP fails. BCP 38 ingress filtering fixes spoofing at the source, but it only works where the sender's network deploys it.
- Rate limiting and load shedding are the origin's last layer, not the whole defence: a volumetric flood fills your link before your code runs.
This page is a defensive survey. It explains how each attack class works at the protocol level, how to recognise it, and what stops it. It gives no tooling, payloads or launch steps. Other attacks (spoofing, ARP, DNS poisoning, BGP) are catalogued on common network attacks, and the attacker positions are defined once on the threat model. A DDoS hits availability and nothing else.
Mental model
A flash mob packs the entrance of a shop. Nobody steals anything and nobody breaks a window, but real customers cannot get through the door. Reflection is the prank version: the pranker phones thousands of businesses, each time giving your shop's number as the callback and asking for a long catalogue to be read out. Every business then rings you with a long answer, and the pranker's own phone bill is tiny.
Where it breaks: a shop can lock the door and call the police; a server cannot tell a crowd member from a customer by looking at one request, and the "crowd" can number in the hundreds of thousands, each arriving from a different street.
A DDoS is resource exhaustion with an asymmetric cost, the same family as a fork bomb or an unbounded queue. Something finite (link bandwidth, a fixed-size backlog, a worker pool, a database connection limit) is consumed faster than it is released. It is not a bug you can fix in one release: the finite resource is the whole point, so the lever is where and how much capacity you have, not how clean your code is.
Where it breaks: a fork bomb comes from inside your trust boundary. A DDoS comes from outside, from sources you cannot authenticate, so the fix cannot be "kill the offending process".
How it works
Three classes, three resources
Ask one question first: what is running out?
| Class | Resource exhausted | Typical example | What mitigates it |
|---|---|---|---|
| Volumetric (L3/L4) | Link bandwidth, router packet rate | UDP reflection and amplification, UDP and ICMP floods | More capacity at an anycast edge, scrubbing, upstream filtering, RTBH |
| Protocol or state exhaustion (L3/L4) | Connection tables, SYN queue, firewall conntrack | SYN flood | SYN cookies, stateless filtering ahead of the stateful device, scrubbing |
| Application (L7) | CPU, worker threads, database, connection slots | HTTP floods, Slowloris, HTTP/2 Rapid Reset | CDN and WAF, challenges, per-client rate limits, header and idle timeouts |
Attacks combine classes. A volumetric flood can be a smokescreen while an L7 attack finishes the job, so a defence that handles one class is not enough.
Reflection and amplification
UDP has no handshake, so the source address in an IP header is whatever the sender writes. That is the property that makes reflection possible; why UDP is forgeable and TCP mostly is not is explained once on the attacks page. The attacker sends a small request to a public UDP service, the reflector, with the victim's address as the source. The reflector answers the victim, who never asked.
Amplification factor is bytes the victim receives divided by bytes the attacker sends. US-CERT's TA14-017A tabulates measured bandwidth amplification factors:
| Protocol | UDP port | Amplification factor | Source |
|---|---|---|---|
| DNS | 53 | 28 to 54 | TA14-017A |
NTP (monlist) | 123 | 556.9 | TA14-017A |
| CharGen | 19 | 358.8 | TA14-017A |
| QOTD | 17 | 140.3 | TA14-017A |
| SSDP | 1900 | 30.8 | TA14-017A |
| SNMPv2 | 161 | 6.3 | TA14-017A |
| memcached | 11211 | up to about 51,000 | Cloudflare, Memcrashed |
The worked example above is the DNS row: a 64-byte request and a 3,000-byte answer is 3000 / 64 = 46.9, inside the 28 to 54 band.
Why the factor matters for the attacker's budget. Bandwidth the victim sees equals attacker bandwidth times the factor. At 50x, 1 Gbps of forged queries becomes about 50 Gbps at the victim. Run it backwards for the largest case: GitHub's 1.35 Tbps in February 2018 (GitHub incident report) is 1.35e12 / 51,000 = 26.5 Mbps of attacker traffic if every reflector hit the peak factor. Real attacks sit below the peak factor, so the attacker needed more than that, but the order of magnitude is a home internet connection.
SYN flood
A TCP server allocates state when a SYN arrives: a slot in the SYN queue while it waits for the third packet of the handshake. TCP connection setup owns the mechanism. The attack sends SYNs from forged sources, so the SYN-ACKs go to addresses that never sent a SYN and no ACK ever comes back. Slots are released only when SYN-ACK retries expire, 63 seconds with default Linux retries.
The arithmetic shows the asymmetry. Take an illustrative SYN queue of 1,024 entries and the 63-second hold: to keep every slot occupied the attacker needs 1,024 / 63 = 16.3 SYNs per second, which is a few hundred bytes per second. The real queue size varies by system and sysctl settings, but the shape does not: the attacker's cost is packets per second, the defender's cost is a held slot per packet.
SYN cookies break that link. The server encodes what it would have stored into the SYN-ACK's initial sequence number, stores nothing, and rebuilds the connection only if a valid ACK returns. A spoofer never sees the SYN-ACK, so it cannot answer. The mechanism and its figure are in TCP connection, and the states you will see on a flooded host are in the TCP state machine. The attack and its mitigation menu are described in RFC 4987.
Deep dive
Source spoofing and BCP 38
Reflection needs two things to be possible: the attacker's network must let a packet leave carrying a source address that does not belong to it, and a reflector must answer an unauthenticated request. BCP 38, RFC 2827 fixes the first: an edge router drops packets whose source address could not legitimately come from that side. RFC 3704 (BCP 84) adds reverse-path checks for multihomed networks. The problem is the incentive: the network that deploys the filter protects strangers, not itself. CAIDA's Spoofer project publishes measurements of how many networks still permit spoofing; read the current figure there.
TCP floods (as opposed to reflection) can also use real botnet addresses, and then spoofing is irrelevant. That is why the defence stack cannot rest on BCP 38 alone.
Reflector protocols and the defender's side of them
The common reflectors are DNS, NTP, SSDP, memcached, CLDAP and CharGen. They share three traits: UDP, a reply larger than the request, and no source validation. The fixes belong to the operator of the reflector: do not run open resolvers, disable legacy features (monlist removal, UDP memcached off by default), apply response rate limiting, and use address validation in new protocols (QUIC caps unvalidated replies at 3x, see UDP). Modern DNS also refuses the classic abuse query: the ANY query now commonly returns a short refusal (RFC 8482), as the hands-on section shows.
Application layer (L7)
At L7 each request is a complete, valid-looking conversation, which is why IP counting does not separate attack from crowd.
- HTTP flood. Many ordinary requests for expensive pages (search, login, uncached URLs). It completes real TCP and TLS handshakes, so the sources are not spoofed; they are a botnet, and that is what makes them harder to block than reflection.
- Slowloris (Robert "RSnake" Hansen, 2009). The client opens many connections and sends the request headers very slowly, never finishing, so the server's connection or thread slots stay occupied by clients that use almost no bandwidth (Cloudflare explainer). Defences: a header read timeout, an idle timeout, a cap on connections per client, and an event-driven front end that does not dedicate a thread per connection.
- HTTP/2 Rapid Reset (CVE-2023-44487, disclosed 10 October 2023).
SETTINGS_MAX_CONCURRENT_STREAMSlimits how many streams a client may have open (RFC 9113, section 6.5.2). The client opens a stream withHEADERSand cancels it withRST_STREAMat once. A cancelled stream stops counting against the limit while the server may already have started work on the request, so one connection can generate requests far faster than the limit intends. The mechanism is told on HTTP/1.1 and HTTP/2; the denial-of-service considerations are in RFC 9113, section 10.5. Mitigation is server-side: track and limit cancelled streams per connection and close connections that cancel abusively (Google, NVD).
Telling an attack from a flash crowd
Check the boring causes first: a deploy, a cache purge, a slow database query, a marketing email, a front-page link. Then compare signals. A flash crowd tends to follow a content or time trigger, request URLs that real users would request, spread across normal user agents and plausible geographies, and complete sessions (cart, login) at a normal rate. An attack tends to show uniform requests, clients that never load subresources, odd TLS and header fingerprints, one URL or one expensive endpoint, or traffic at protocols you do not serve (UDP to a web server). No single signal is decisive; the cost of a wrong call is blocking real customers.
Mitigation stack
- Anycast absorption. Many sites announce the same prefix, so each attacker's traffic lands at its nearest site and the attack is split across the whole footprint instead of concentrating on one link. The mechanism is on global traffic steering and the operational argument in RFC 4786.
- CDN absorption. A CDN terminates connections near the user and serves cached content without touching the origin; see CDN. The origin must refuse traffic that does not come from the CDN, or the shield is bypassed.
- Scrubbing. Traffic to the victim prefix is diverted to a scrubbing centre that drops the attack flows and returns clean traffic.
- RTBH (remotely triggered black hole, RFC 3882, RFC 5635). The victim announces its own address with a blackhole signal (a standard community is defined in RFC 7999) and upstream routers drop all traffic to it, attack and legitimate. It saves the network and sacrifices the victim, so it is a last resort.
- Flowspec (RFC 8955). BGP distributes match-and-act rules (protocol, port, packet size, source prefix) so upstream routers drop or rate-limit only the attack pattern instead of the whole address.
- Application layer. Challenges (JavaScript or proof of work, CAPTCHA as a last resort), client fingerprints, and per-client or per-key rate limits. The token-bucket and sliding-window algorithms are owned by rate limiting and load shedding; this page does not repeat them. In one line: limit per key at the edge, shed low-priority work at the origin, and return
429withRetry-Afterso honest clients back off.
Diversion has two modes. On-demand: when an attack is detected the customer (or provider) starts announcing the prefix to the scrubbing network, which takes BGP convergence time to take effect. Always-on: traffic always flows through the provider and detection delay disappears at the price of a permanent detour. Clean traffic returns over a tunnel (commonly GRE, RFC 2784) or a private interconnect, because sending it back through the normal route would loop it into the scrubber again. Tunnels reduce the usable MTU; see MTU, MSS and fragmentation.
Textbook vs real world
| The textbook says | Production does | Why |
|---|---|---|
| A firewall stops DDoS | Puts stateless filtering and scrubbing ahead of the stateful devices | A stateful firewall keeps a table entry per flow, so the firewall's own state table is the bottleneck a flood targets |
| Buy more bandwidth | Uses an anycast network or a CDN with far more aggregate capacity than any one site | Reported attacks reach multiple Tbps, beyond a single site's uplinks |
| Block the attacking IPs | Filters on protocol, port and packet patterns, or challenges clients | Reflection sources are the innocent reflectors and TCP floods use forged or botnet addresses, so the address list is useless or harmful |
| Put a CAPTCHA on everything | Challenges only suspicious traffic, with silent checks first | CAPTCHAs cost real users time, hurt accessibility, and add a dependency |
| Autoscale to absorb it | Caps autoscaling and sheds load | Unbounded scaling turns an attack into a cost attack and still does not remove the saturated link |
| Rate limiting is DDoS protection | Treats rate limiting as the origin's last layer | A volumetric flood fills the link before any limiter on the server runs |
In production
- Google reported Rapid Reset peaking at 398 million requests per second in August 2023, and Cloudflare reported 201 million and AWS 155 million for the same campaign (each provider's own post: Google, Cloudflare, AWS).
- Cloudflare publishes quarterly DDoS threat reports with record sizes. Its Q4 2024 report described a 5.6 Tbps attack (Q4 2024 report). Records move quickly, so read the latest report rather than trusting a number frozen on a page.
- GitHub, February 2018. 1.35 Tbps of memcached reflection, mitigated by moving traffic through a scrubbing provider (GitHub's incident report).
- Dyn, 21 October 2016. A Mirai botnet attack on the managed DNS provider Dyn left many popular sites unreachable for users of affected resolvers (Dyn analysis). The lesson is dependency: your availability includes your DNS provider's.
- KrebsOnSecurity, September 2016. A record attack of about 620 Gbps, as reported by the site (Krebs).
- Managed protection is sold as services such as AWS Shield (Standard and Advanced tiers) and Google Cloud Armor, alongside CDN and scrubbing vendors. Where a cloud load balancer terminates traffic first, see cloud load balancers.
History and evolution
- 1999 The first distributed tools (trinoo, TFN) control many compromised hosts from a handler, analysed in Dittrich's trinoo analysis. A single source stops being the only shape of an attack.
- February 2000 Attacks on high-profile sites such as Yahoo and eBay take them offline and make DDoS a mainstream concern; defence is still ad hoc.
- 2000 BCP 38 (RFC 2827) is published to stop spoofed sources at the edge. Reflection later exploits the networks that did not deploy it.
- 2007 RFC 4987 documents SYN flooding and its mitigations, SYN cookies among them, after the attack had been known for over a decade.
- 2013 Spamhaus is hit by a DNS reflection attack that Cloudflare reports at about 300 Gbps (Cloudflare), showing open resolvers as a weapon.
- 2016 The Mirai botnet of compromised IoT devices produces record attacks, including Krebs and Dyn (Antonakakis et al., USENIX Security 2017). Insecure devices become the supply of attack capacity.
- 2018 Memcached amplification reaches 1.35 Tbps against GitHub; UDP memcached is switched off by default in later releases.
- 2023 HTTP/2 Rapid Reset (CVE-2023-44487) sets L7 request-rate records by exploiting a protocol feature rather than a bug in one product.
- Now Attacks are measured in multiple Tbps and tend to be short, so detection and automatic mitigation matter more than a human reacting. Live data: Cloudflare Radar.
- Next Abuse of HTTP/3 and QUIC features, larger IoT botnets, and AI-driven bots that imitate users and defeat simple challenges.
Hands-on
Only run these against your own hosts or public services you are allowed to query. First, how big is a DNS answer compared with the query? Ask a public resolver for the DNSSEC keys of a name, advertising a large buffer (output abbreviated):
The query was 40 bytes of DNS (12 header + 17 question for example.com DNSKEY IN + 11 EDNS option). 467 / 40 = 11.7, so even a polite lookup amplifies. Now the classic ANY query:
NOTIMP and 46 bytes: this resolver refuses ANY per RFC 8482, which removes the biggest cheap amplifier. Your resolver may answer differently. On a Linux server, check the SYN side:
tcp_syncookies = 1 means cookies only when the SYN queue overflows, and 2 means always (kernel ip-sysctl). A rising synrecv count in ss -s or a non-zero TcpExtSyncookiesSent means the SYN path is under pressure. To watch SYN arrivals on your own host (needs root; the syntax is the same on macOS and Linux), match packets with the SYN flag and no ACK:
A normal host shows SYNs as a trickle tied to real clients. A flood shows a steady stream from addresses that never follow up. ss and nstat are Linux tools; on macOS use netstat -an and netstat -s. Reading captures is covered on tcpdump and Wireshark and the socket tools on ss, nc, lsof and ip.
Gotchas
Interview questions
Show answer
A distributed denial of service attack exhausts a resource so legitimate users cannot be served. Volumetric attacks fill the network link with traffic (for example UDP reflection). Application-layer attacks send valid-looking requests (HTTP floods) that exhaust CPU, threads or the database at far lower bandwidth.
Follow-ups:
- Which is harder to filter? Application-layer, because each request looks valid and sources are real.
- Can one attack be both? Yes; a volumetric flood is often a smokescreen for an L7 attack.
Show answer
The attacker sends a small UDP request to a public service with the victim's address forged as the source, and the service sends a much larger reply to the victim. The factor is reply bytes over request bytes: DNS is roughly 28 to 54, NTP monlist about 557, and memcached reached about 51,000. A 64-byte query that draws a 3,000-byte reply is about 47x.
Follow-ups:
- Why UDP? No handshake, so a forged source is accepted. TCP needs the victim to complete a handshake it never started.
- Why DNS, NTP and memcached? Small request, large answer, public, no source validation.
- How do you stop it at the source? BCP 38 ingress filtering, closing open resolvers, disabling features like
monlist.
Show answer
Layer it. Put a CDN or anycast edge in front so volume is absorbed away from the origin, apply a WAF and challenges for L7 abuse, enforce per-key rate limits and shed low-priority work at the origin, make the origin accept traffic only from the edge, and cap autoscaling so the attack cannot become a cost attack.
Follow-ups:
- Where do rate limits belong? Per key at the edge and again at the origin; algorithms are on the rate-limiting page.
- What if the origin IP leaks? Attackers bypass the edge, so firewall the origin to the CDN's ranges or use authenticated origin pulls.
Show answer
An HTTP flood overwhelms the server with a high request rate. Slowloris uses very little bandwidth: it holds many connections open with incomplete headers until the server runs out of connection slots. Floods need rate limits and WAF rules; Slowloris needs header-read and idle timeouts, per-client connection caps, and an event-driven front end.
Follow-ups:
- Why does a low rate hurt? The scarce resource is concurrent connection slots, not bandwidth.
- What limits do you set? A short header timeout and an idle timeout on the front end.
Show answer
Rule out the internal causes first (deploy, cache, database). Then compare the traffic: a crowd follows a trigger, requests varied real URLs, shows normal client diversity and completes sessions. An attack shows uniform requests, one expensive endpoint, odd fingerprints, or protocols you do not serve. No single signal is decisive.
Follow-ups:
- What if you cannot tell? Rate limit and challenge gently, add capacity, and watch conversion; avoid hard blocks.
Show answer
A scrubbing centre is a high-capacity site that inspects traffic for a customer prefix, drops attack flows and forwards clean traffic. Traffic reaches it by BGP: the provider announces the customer's prefix so traffic is attracted to it, or DNS is pointed at a provider address. Clean traffic returns to the origin over a tunnel such as GRE or a private link.
Follow-ups:
- On-demand versus always-on? On-demand waits for BGP to converge after detection; always-on has no delay but a permanent detour.
- Why a tunnel back? The normal route leads back to the scrubber and would loop.
Show answer
RTBH signals upstream routers to drop all traffic to the victim address, attack and legitimate alike, so the victim is taken offline to protect the network. Flowspec distributes match rules (protocol, port, size, source) over BGP so upstream routers drop only the attack pattern and the service stays reachable.
Follow-ups:
- When is RTBH right? When the attack threatens shared infrastructure and the target address can be sacrificed.
- What limits Flowspec? It needs the upstream to accept your rules, and a bad rule drops good traffic.
Show answer
The client opens a stream with HEADERS and cancels it immediately with RST_STREAM. Cancelled streams stop counting against SETTINGS_MAX_CONCURRENT_STREAMS, so one connection can issue requests faster than the limit intended while the server may still do work. It is tracked as CVE-2023-44487. Mitigations are server-side limits on cancelled streams per connection and closing abusive connections.
Follow-ups:
- Why is it hard to rate limit? A few connections generate huge request rates, so per-connection and per-stream accounting is needed.
- Does HTTP/1.1 have it? No, it relies on multiplexing and stream cancellation in HTTP/2.
Fun facts
- A QUIC server may send at most three times the bytes it has received from an unvalidated address, a limit written into the protocol to keep it off the amplifier list (RFC 9000, section 8.1).
- Derived on this page: at the 51,000x ceiling, about 26.5 Mbps of attacker traffic would account for the 1.35 Tbps that hit GitHub.
- RFC 4987 on SYN flooding was published in 2007, but SYN cookies date to 1996 (Bernstein and Schenk), as described on TCP connection.
- Modern resolvers often answer
ANYwith a one-line refusal because of RFC 8482, which exists largely because of amplification.
Cheat sheet
- 28 to 54x - DNS amplification (TA14-017A)
- 556.9x - NTP
monlist(TA14-017A) - up to about 51,000x - memcached UDP (Cloudflare)
- 1.35 Tbps - GitHub, February 2018
- 398 / 201 / 155 million rps - Rapid Reset peaks reported by Google / Cloudflare / AWS
- 63 s - default SYN-ACK retry hold, so about 16 SYN/s fills 1,024 slots