SYN cookies
Bots send thousands of SYNs with forged source addresses. Without a defence, each SYN takes a slot in the half-open queue: connections waiting for their final ACK. Once the queue is full, real users are turned away.
With SYN cookies on, the server stores nothing for a new SYN. It hashes the addresses, ports, a coarse clock and a secret into its starting sequence number, the cookie, and sends it in the SYN-ACK. The queue stays empty.
A real client answers the SYN-ACK. Its ACK carries the cookie plus one. The server hashes the same details again; they match, so only now does it build the connection. Forged sources never send that ACK.
Rate limiting
Some bots complete real handshakes from their own addresses, so cookies let them in. A rate limiter counts new connections from each source address and drops anything above a limit, here 20 per second.
No reflectors, no forgery
Reflection uses an open resolver: a DNS server that answers anyone. A small query forged to come from the server gets a much bigger answer, and the resolver sends that answer to the server.
Its operator closes it: the resolver now answers only its own users on 192.0.2.0/24 and refuses everyone else. Queries from outside get no big answer, so there is nothing left to reflect.
The bots' internet provider knows their line uses only 198.51.100.0/24. Its edge router drops any packet leaving that line with another source address: forged SYNs and forged DNS queries alike. This is source address validation, BCP 38.
Absorb the flood
Some floods are bigger than the server's whole internet link, and no filter at the server helps once that pipe is full. So the server's addresses are announced from a scrubbing centre instead, and all traffic goes there first.
The scrubbing centre drops the attack: SYNs that never finish a handshake, DNS answers nobody asked for, and sources over their limit. It forwards only the clean traffic to the server through a private tunnel.
Large networks go further with anycast: the same address is announced from many sites around the world. Each bot's packets reach its nearest site, so the flood is split into small pieces each site can absorb.
The real user's request reaches the nearest site, passes the filters and the rate limit, and the server answers. The flood failed because each layer removed one trick. Defence in depth means using them together.
The packets, step by step
;; step 1/11 · flood ;; attacker → server TCP 203.0.113.77:40001 → 203.0.113.10:443 flags SYN (forged source) TCP 192.0.2.140:52210 → 203.0.113.10:443 flags SYN (forged source) TCP 198.51.100.200:33876 → 203.0.113.10:443 flags SYN (forged source) … server: SYN-RECEIVED × 4 queue full (4 slots, illustrative) the SYN-ACKs go to the forged addresses; no final ACK ever comes back each slot is held until the server gives up on it (RFC 4987 §2.2)
Illustrative numbers: a 4-slot half-open queue (real ones are far larger), a limit of 20 new connections per second, and a cookie of 7341092; real cookies look random. 203.0.113.10, 192.0.2.7, 192.0.2.53 and 198.51.100.0/24 are RFC 5737 documentation addresses; the server and user are the same pair as in the TCP and HTTPS lessons.