SYN Flood is one of the oldest denial-of-service attacks, and it is still effective today. Here’s what happens under the hood…
A TCP connection is established with a three-way handshake: the client sends a SYN, the server responds with a SYN-ACK, and the client completes it with an ACK.
What’s interesting is that during this process, the server allocates memory for each half-open connection in a backlog queue.
In a SYN Flood, an attacker sends thousands of SYN packets but never completes the handshake. The server keeps waiting for ACKs that never arrive, and the backlog queue fills up. Once it is full, legitimate users can not connect anymore. Thus, a DoS attack.
What makes this attack effective is the ‘asymmetry’ - the attacker sends tiny packets with minimal effort, but the server has to allocate resources for each one. A single low-powered machine can overwhelm a much more powerful server.
Fun fact: SYN floods have taken down GitHub, Cloudflare, and several databases in the past. To defend against SYN flooding, we can:
- Cap the number of SYN packets from a single IP
- Drop packets from known malicious sources
- Or, the most effective, use SYN Cookies
With SYN cookies, the server does not store anything. Instead, it encodes all the necessary connection information (client IP, port, and a timestamp) into the initial sequence number of the SYN-ACK packet it sends back. This sequence number is cryptographically generated, so it cannot be forged.
SYN cookies make the handshake effectively stateless on the server side until it’s fully verified, so the server does not reserve any resources until it knows the client is real.
By the way, most modern operating systems have SYN cookie support built in. On Linux, we can enable it with net.ipv4.tcp_syncookies = 1.
If you are interested, the Wikipedia pages are pretty well written for understanding this, and as always, you can use your favorite LLM to dig deeper.