Quick answer
A SYN flood is a denial-of-service attack that abuses the way TCP opens a connection. The attacker sends a stream of SYN packets — the first step of the handshake — but never sends the final acknowledgement, so the server keeps each half-finished connection in memory waiting for a reply that never arrives. The connection table fills up, and genuine visitors are refused because there is no room left to accept them. It needs very little bandwidth, which is what makes it attractive to attackers and easy to miss on a traffic graph.
The handshake it abuses
Every TCP connection starts with three packets. The client sends SYN ("I want to connect"), the server replies SYN-ACK ("go ahead") and reserves memory for the connection, and the client answers ACK ("connected"). Only then does data flow.
The vulnerability is in the middle step: the server commits resources after the first packet, before it has any proof the client is real. A SYN flood simply never sends the third packet.
normal: flood:
client → SYN attacker → SYN
server → SYN-ACK (waits) server → SYN-ACK (waits…)
client → ACK (nothing ever comes back)
→ connected → slot held until timeout
one slot, briefly thousands of slots, ~60s eachWhy so little traffic does so much damage
A SYN packet is tiny — around 60 bytes. A few thousand per second is a rounding error on a gigabit link, so bandwidth graphs stay flat while the server is already refusing connections.
What runs out is not bandwidth but state. Each half-open connection occupies an entry in the backlog queue and is held for the SYN-ACK timeout, typically tens of seconds. A default backlog of a few hundred entries is exhausted in well under a second of sustained flooding.
Spoofed sources make blocking useless
Because the attacker never needs to receive the SYN-ACK, the source address in the SYN packet can be anything at all. Attackers randomise it, so each packet appears to come from a different host.
That defeats address-based blocking twice over: there is no small set of addresses to ban, and any address you do ban probably belongs to an innocent third party whose address was forged. Worse, the victim's SYN-ACK replies are sent to those forged addresses, so the attack sprays unwanted traffic at bystanders too.
SYN cookies: the actual fix
The standard defence inverts the problem. Instead of allocating memory when the SYN arrives, the server encodes the connection state into the sequence number it sends back in the SYN-ACK — a cryptographic value derived from the connection details, called a SYN cookie.
No state is stored. If the client is real it returns the ACK, the server verifies the cookie mathematically, and only then builds the connection. If the client never replies, nothing was ever allocated and nothing needs cleaning up. The attack stops costing the server anything.
- SYN cookies — the primary defence, standard in modern Linux kernels
- A larger backlog queue buys time but does not solve it alone
- Shorter SYN-ACK timeouts free slots faster, at some cost to slow clients
- Per-source connection limits help only against unspoofed attacks
- Upstream filtering, because a large enough flood still saturates the link itself
How to tell you are being hit
That fourth row is the one that misleads people most. Because the connections never complete, nothing reaches the web server, so the access log shows a *drop* in traffic while the site is unreachable.
| Signal | What you would see |
|---|---|
| Half-open connections | Large and growing count in SYN_RECV state |
| Bandwidth | Normal — the giveaway that it is not volumetric |
| Source addresses | Huge variety, often no repeats at all |
| Application logs | Quiet: the requests never complete a handshake |
| User reports | Timeouts and connection refused, not slow pages |
Frequently asked questions
Last updated