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.
- Enable SYN cookies and tune your connection backlog at the origin and its firewall.
- Absorb the raw packet flood upstream — at your host or transit provider's network, which is where a stateless flood is actually stopped.
- Hide your origin IP behind a reverse proxy so a flood aimed at your server has no target to reach.
Where a reverse proxy helps — and where it doesn't
Hiding your origin behind Akarguard means a SYN flood pointed at your old server IP hits nothing. But this is origin-hiding, not L4 scrubbing: a volumetric flood against the proxy's own address is a network-capacity question for the upstream provider. Akarguard is a Layer 7 (application-layer) service, not a volumetric scrubber.