What is a SYN flood?
A SYN flood is a DDoS attack that exhausts connection tables with a flood of unfinished TCP handshakes. How it works, why it hurts and how to stop it.
Last updated:
A SYN flood is one of the oldest and still most effective DDoS attacks. The attacker sends a barrage of TCP SYN packets, the first packet of a connection setup, and never finishes the sessions it starts. Every such packet forces the server to reserve a slot in its connection table and wait for a reply that never arrives. The attack is measured in packets per second rather than gigabits, which is why a link can look almost idle at the moment the service stops responding.
Where the attack breaks the three-way handshake
A normal TCP connection starts in three steps: the client sends SYN, the server replies SYN-ACK and reserves resources for that half-open connection, and the client confirms with ACK. The attacker stops after the first step. The server sends its SYN-ACK into the void and holds the table entry until a timer expires, typically tens of seconds. At a few hundred thousand such packets per second the table fills faster than entries drain, and genuine new connections start getting refused.
Source addresses in this attack are usually forged, and deliberately so. Spoofing random sources makes every packet look like a different connection, so simply counting connections per source IP does not catch the pattern. It also frustrates any response and hides where the attack came from.
Why it hurts more than the raw volume suggests
A SYN packet is tiny, so even a modest bandwidth budget produces an enormous packet count. The bottleneck is not the pipe, it is the state tables: on the server, the firewall, the load balancer and the edge router. A device with plenty of spare bandwidth can fall over because the memory holding connection state runs out. This is why SYN floods are often misdiagnosed as an application failure, since the traffic graphs show nothing dramatic.
Defending with SYN cookies and SYN proxy
- SYN cookies: the server allocates no memory when a SYN arrives and instead encodes what it needs in the SYN-ACK sequence number. State is created only when a valid ACK comes back, so there is nothing for the table to fill up with.
- SYN proxy: a device in front of the server completes the handshake itself and only opens a connection to the server once that succeeds. Traffic from sources that never answer goes no further.
- Rate limits on new connections per source: useful against simpler attacks, but they lose effectiveness quickly once sources are spoofed and distributed.
- Stateful filtering further upstream: packets outside any session context are dropped before they reach the equipment whose tables were the target.
Where the defence belongs
Protection wired in directly in front of a server only works while the link to that server has room. If the attack saturates the uplink or the edge device's tables, everything behind it stops responding regardless of configuration. That is why operators move the filtering upstream, to the provider's network edge, where there is capacity to absorb the attack traffic and drop it before it competes with real users.
Frequently asked questions
Can a SYN flood be told apart from a genuine traffic spike?
Yes, though not by volume alone. The telltale sign is the gap between SYN packets and completed handshakes: a real surge in popularity brings SYN, ACK and data transfer in normal proportion, while an attack leaves a mountain of half-open connections with no follow-up. The distribution of source addresses helps too, since attacks often spread evenly across the whole address space in a way natural traffic never does.
Are SYN cookies enough?
They protect the connection table, but not the link or the CPU that has to process every arriving packet. At larger volumes you need filtering further upstream, before the traffic reaches the server at all. Treat SYN cookies as a last line rather than the only one.