TCP was never designed with adversaries in mind. The three-way handshake — SYN, SYN-ACK, ACK — is fundamental to reliable communication, but it creates a vulnerability: a server must allocate state for each half-open connection before the client acknowledges. SYN floods exploit exactly this.
How a SYN Flood Works
The attacker sends a flood of TCP SYN packets with spoofed source IPs. The server responds to each with a SYN-ACK and waits for the final ACK — which never comes because the source address is fake. The server's connection state table fills up. Legitimate connections are refused. Service is down.
- Requires no bandwidth amplification — 100Mbps of SYN traffic can take down a server handling gigabits of normal load.
- Spoofed IPs make blacklisting ineffective at the server level.
- Attack tools generate millions of unique fake source IPs per second.
Mitigation Techniques
- SYN cookies: server encodes state into the sequence number, removing the need to store half-open connections.
- Rate limiting SYN packets at the scrubbing proxy before they reach your servers.
- Connection state table sizing — not a fix, just delay.
- Akarguard's proxy absorbs the SYN flood entirely — your origin never sees a half-open connection.
Why DNS-based protection wins here
Because Akarguard sits in front of your origin as a reverse proxy, SYN floods are absorbed at the scrubbing layer. Your server's TCP stack never processes a single spoofed SYN.