SYN flood detection lies to you on a SYN-cookie kernel
Why SYN Flood Detection Can Mislead You When SYN Cookies Are Enabled
Every system administrator has seen it.
A monitoring graph suddenly spikes.
Someone opens Grafana.
Another person runs:
netstat -ant | grep SYN_RECVThe numbers look surprisingly low.
Meanwhile the firewall is reporting hundreds of thousands of incoming SYN packets every second.
Someone inevitably asks:
“If we’re under attack, why aren’t there thousands of connections waiting in SYN_RECV?”
The answer is simple.
Because the kernel changed the rules.
Understanding that change can save you from chasing the wrong problem.
First, how a normal TCP handshake works
A TCP connection normally follows three steps.
Client Server
SYN ------------------>
<-------------- SYN + ACK
ACK ------------------>After receiving the initial SYN, the server allocates memory.
It creates a request socket.
That connection now waits in the SYN backlog until the final ACK arrives.
During this stage you’ll usually see the connection in the SYN_RECV state.
This is exactly what most monitoring tools count.
The problem during a SYN flood
A SYN flood abuses this behaviour.
Instead of completing the handshake, an attacker sends enormous numbers of SYN packets and never responds with the final ACK.
Every SYN consumes space in the backlog.
Eventually the queue fills.
Once that happens, legitimate users begin experiencing connection failures.
Historically this was enough to exhaust server memory.
Enter SYN cookies
Linux has supported SYN cookies for many years.
Instead of immediately allocating memory for every incoming SYN, the kernel can encode enough information into the sequence number of the SYN-ACK packet.
If the client later returns with a valid ACK, the kernel reconstructs the connection at that point.
Until then…
No request socket exists.
No backlog entry exists.
No memory has been consumed for that connection.
From the server’s perspective, nothing is waiting.
What changes inside the kernel
Without SYN cookies:
Incoming SYN
│
▼
Allocate request socket
│
▼
Store in SYN backlog
│
▼
Wait for ACKWith SYN cookies enabled:
Incoming SYN
│
▼
Generate SYN cookie
│
▼
Send SYN-ACK
│
▼
Wait without allocating state
│
▼
ACK received?
│
Yes ─┘
▼
Create socketThe important difference is that the kernel postpones allocating connection state.
That is the entire purpose of SYN cookies.
Why monitoring becomes misleading
Many monitoring tools assume every incoming SYN creates a half-open connection.
That assumption is no longer true once SYN cookies are active.
For example:
ss -ant state syn-recvor
netstat -antmay report only a handful of connections.
Meanwhile the network interface is processing hundreds of thousands of SYN packets every second.
Nothing is broken.
The kernel simply isn’t creating request sockets for those packets.
The attack is still happening.
Your monitoring method is observing the wrong thing.
What you should monitor instead
When SYN cookies are enabled, packet rates become more useful than connection counts.
Useful indicators include:
- Incoming SYN packet rate
- SYN/ACK transmission rate
- Interface packet counters
- Firewall counters
- Drops reported by NIC statistics
- CPU utilisation in the networking stack
- SoftIRQ activity
- Connection success rate for legitimate clients
These measurements reflect actual workload more accurately than counting half-open sockets.
Linux even tells you when this happens
If the SYN backlog becomes overwhelmed, Linux may log messages similar to:
Possible SYN flooding on port 443. Sending cookies.This message indicates the kernel has switched to SYN cookie handling for that listener.
From this point onward, interpreting SYN_RECV counts requires additional context.
A small number of half-open connections no longer means there is no attack.
It only means the kernel is handling new connection attempts differently.
Are SYN cookies always enabled?
Not necessarily.
You can check the current setting:
sysctl net.ipv4.tcp_syncookiesTypical values are:
| Value | Meaning |
|---|---|
| 0 | Disabled |
| 1 | Enable SYN cookies when needed |
| 2 | Always send SYN cookies |
Most Linux distributions use 1, allowing the kernel to enable SYN cookies only when it detects SYN backlog pressure.
There are trade-offs
SYN cookies are an excellent defence mechanism, but they are not completely free.
Because no request socket exists before the final ACK, certain TCP options cannot always be negotiated in exactly the same way as during a normal handshake.
Modern Linux kernels preserve many commonly used options, but SYN cookies remain a defensive fallback rather than the preferred operating mode for normal traffic.
The goal is survivability during an attack, not perfect optimisation.
A real-world example
Imagine a web server receiving:
- 400,000 SYN packets per second
- SYN cookies enabled
- Only 30 connections visible in
SYN_RECV
At first glance the numbers appear inconsistent.
They’re not.
Those 400,000 SYN packets never became request sockets.
The kernel responded with SYN cookies and waited.
Only clients that completed the handshake caused memory to be allocated.
The server remained responsive precisely because the backlog never filled with half-open connections.
The takeaway
One of the easiest mistakes during incident response is assuming every SYN packet becomes a half-open connection.
That assumption only holds during a normal TCP handshake.
Once SYN cookies become active, the kernel deliberately stops behaving that way.
If your monitoring strategy still relies on counting SYN_RECV sockets, you’re looking at only a small part of the picture.
The attack hasn’t disappeared.
The kernel has simply changed how it protects itself.
Understanding that distinction makes diagnosing network attacks significantly easier.
References
- RFC 4987 — TCP SYN Flooding Attacks and Common Mitigations
- RFC 793 — Transmission Control Protocol
- RFC 6528 — Defending Against Sequence Number Attacks
- Linux kernel documentation (
Documentation/networking) man 7 tcp