How does a SYN flood work, and how do SYN cookies defend against it?
Show the answer
Say this first
The attacker sends a stream of TCP SYNs, usually from spoofed source addresses, and never completes the handshake. The server keeps a half-open entry for each SYN and sends a SYN-ACK that goes nowhere, so its queue of half-open connections fills and real clients are refused. With SYN cookies, once that queue is full the server stops storing anything for new SYNs. It encodes what it needs (a hash of the addresses, ports and a secret, a time counter and an MSS value) into the initial sequence number of its SYN-ACK. A real client's ACK carries that number plus one, the server verifies it, and only then creates the connection. Spoofed SYNs cost it no memory.
Go deeper
Server side
$ sysctl net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies = 1
$ ss -n state syn-recv | wc -lOn Linux the value 1 (the default) means cookies are used only when the SYN queue overflows. The cost: the cookie can only carry a few MSS values, and options such as window scaling and SACK survive only when TCP timestamps are on, because Linux hides them in the timestamp.
Network side
- SYN proxy or SYN cookies on the firewall: the firewall answers the SYN itself and only opens a connection to the server after the client completes the handshake. PAN-OS zone protection, FortiGate DoS policies and Cisco firewalls all offer a form of this, triggered at a SYN rate you set.
- Embryonic connection limits per server or per source.
- Upstream help when the flood is large enough to fill the link. SYN cookies protect state, not bandwidth.
Why spoofed sources
The attacker does not need the replies, spoofing hides it, and the SYN-ACKs land on innocent hosts as backscatter. Ingress filtering (BCP 38) at networks everywhere is what makes spoofing harder.
They will ask next
How can you tell a SYN flood from a busy server?
Many connections in SYN-RECV that never progress, mostly from addresses that never send anything else, and the kernel logging that it is sending cookies. A busy server has many ESTABLISHED connections instead.
What else attacks state besides SYN floods?
Full connection floods from real hosts (which pass SYN cookies), slow HTTP attacks that hold connections open, and floods aimed at a firewall's or load balancer's session table.
Traps
- Saying SYN cookies stop a DDoS. They protect the server's memory, not your internet link.