Networking & Protocols

Amplification attacks and state exhaustion

Crux Amplification attacks exploit open third-party servers to multiply attacker bandwidth 50–1280x; state-exhaustion attacks fill TCP backlog tables to drop legitimate connections.

Your altitude — climbing toward senior

ZeroJuniorMiddleSenior

You are at middle altitude — in the sky

◷ 12 min

Your CDN is absorbing the attack, but the DDoS traffic is coming from legitimate DNS resolvers — not from the attacker’s IP at all. Blocking the resolvers blocks all DNS. The attacker sent one small query per resolver; each resolver responded to the victim with 50x more data. Welcome to amplification.

Amplification and reflection: the mechanism. An amplification attack exploits a stateless, UDP-based protocol on a third-party server. The attacker sends a small request with a forged source IP (the victim’s IP). The third-party server responds to the source IP — which is the victim — with a much larger response. The attacker does not need to receive anything; the third-party does all the work. The “amplification factor” is the ratio of response size to request size.

Protocol	Query size	Response size	Amplification
DNS (ANY record)	40 bytes	~1,700 bytes	42x
NTP (monlist)	40 bytes	468 bytes	12x (up to 556x)
Memcached (UDP)	50 bytes	51,200 bytes	1,024x

DNS amplification attack flow

Attacker sends DNS query, source IP = victim’s IP, dest = open resolver
Open resolver receives it and replies to source IP (victim) with large response
Victim receives unsolicited large responses from thousands of resolvers
Each attacker query costs 40 bytes; each victim hit is ~1,700 bytes
Result: 1 Gbps attacker bandwidth → 42 Gbps of attack on victim

HTTP/2 Rapid Reset (CVE-2023-44487). HTTP/2 allows multiple parallel streams. The Rapid Reset attack sends a stream and immediately cancels it — before the server sends any response. The server allocates memory and CPU for the request anyway. Sending and resetting thousands of streams per second exhausts the server at the CPU level, not the bandwidth level. A single small botnet (20,000 machines) generated 398 million requests per second against Google using this technique in 2023 — the highest request-rate DDoS on record at the time. The fix: HTTP/2 servers must rate-limit stream creation rate and treat high-reset-rate clients as attackers.

Attack statistics from the field

Requests/sec (HTTP/2 Rapid Reset): 398M
Largest DDoS (Dec 2025): 31.4 Tbps
Memcached amplification factor: 1,024x
Botnet machines (Rapid Reset attack): ~20K

Trace it

1/4

Trace a DNS amplification attack from attacker to victim.

Step 1 of 4

Step 1: what does the attacker send?

Locked

Step 2: what does the resolver do?

Locked

Step 3: what is the attacker's role after sending the query?

Locked

Step 4: why is this hard to defend?

State-exhaustion: SYN floods. The TCP three-way handshake requires the server to store state for every in-progress connection. The SYN flood sends millions of SYN packets with spoofed source IPs. For each SYN, the server allocates a slot in its SYN backlog and waits for the ACK that will never come (because the source IP is fake). When the backlog fills, the server drops new SYN packets — including those from legitimate clients. Default Linux SYN backlog: 128–512 slots; under attack it fills in milliseconds.

SYN cookies: trading memory for CPU. Linux SYN cookies (enabled by default since kernel 2.6) avoid storing backlog state. When the backlog would overflow, the server encodes the connection parameters (ISN) as a cookie derived from the source IP, port, and timestamp. No slot is allocated. If the client replies with a correct ACK, the server reconstructs the state from the cookie and completes the handshake. The cost: slightly higher CPU per new connection; the benefit: no memory exhaustion under flood conditions.

Quiz

In a DNS amplification attack, why does the attacker use a forged source IP?

Quiz

Why does SYN cookie defense trade memory for CPU?

Edge cases

ACK floods are the less-known cousin of SYN floods. The attacker sends millions of ACK packets to a port with no active connection. The kernel must respond with RST packets (there is no connection to acknowledge). Under heavy ACK flood, the RST rate can consume significant CPU. Defense: TCP RST rate limiting (limit RSTs per second per source IP) and firewall-level suppression — drop ACKs that do not match any existing connection in the conntrack table.

Recall before you leave

01
Why is amplification so much more cost-effective than a direct botnet flood?
02
What is the HTTP/2 Rapid Reset vulnerability and why does it bypass normal rate limiting?
03
How does SYN cookie defense eliminate SYN backlog exhaustion?

Recap

Amplification attacks exploit open UDP services (DNS, NTP, Memcached) that respond to spoofed queries — the attacker sends 40 bytes, the victim receives 1,700+ bytes per query, multiplied across thousands of resolvers. HTTP/2 Rapid Reset is the application-layer equivalent: 20,000 botnet machines generated 398M req/sec by exploiting stream cancellation. SYN floods exhaust server connection tables by sending millions of half-open connections using spoofed IPs; SYN cookies defend by encoding state in the TCP sequence number instead of storing it in memory. All three attacks share the same property: the attacker spends little, the defender pays much.

Connected lessons

builds on

DDoS: what it is and why it worksjunior

unlocks

deepens into

Defense-in-depth architecture and attack economicssenior

appears again in258

Continue the climb ↑Rate limiting: algorithms and architecture