TCP SYN Flood

What it exhausts

Half-open connection slots. A server that receives a SYN allocates a record and waits for the third packet of the handshake; a flood of SYNs from addresses that never answer fills that table with records for connections that will never exist RFC 4987.

Nothing about this requires volume. This is the family that most reliably surprises people who sized their defence in gigabits, and it is why bandwidth alone is an incomplete specification RFC 4732.

How it differs from similar attacks

An ACK flood attacks the same class of device but by a different route: rather than creating state, it forces lookups for sessions that do not exist. A connection flood completes the handshake and then holds the connection open, which passes the proof a SYN defence demands. A volumetric UDP flood consumes bandwidth and leaves the connection table untouched.

The practical consequence is that the correct answer differs in each case, which is why the first five minutes of the incident runbook are spent identifying which resource is at its ceiling rather than reaching for a fix.

Observable telemetry

• SYN rate rising while handshake completion rate stays flat.
• Half-open connection count climbing toward its configured ceiling.
• Source addresses with no prior history and no return traffic.
• On Linux, the TCPReqQFullDrop and related counters moving, and SYN cookie counters engaging.
• Established connection count not rising in proportion to SYNs — the giveaway.

Common false positives

A genuine traffic surge from a marketing campaign or a mobile app release produces a step change in SYN rate too. The distinguishing feature is that legitimate surges complete their handshakes. A defence tuned on SYN rate alone will block a successful launch; one tuned on completion ratio will not.

Retransmissions from a lossy path also inflate SYN counts without malice, which matters for services with substantial mobile traffic.

Mitigation by layer

Upstream — rarely necessary, because the volume is usually small. Where the flood is also volumetric, the upstream instruments apply as they would to any volume.

Network edge — a stateless device that validates the handshake before anything stateful sees it. This is the designed answer, described in SYN proxy and SYN cookies.

Host — SYN cookies as the fallback that engages when the flood reaches the server anyway, plus backlog and timeout tuning covered in the Linux server hardening guide.

Application — nothing to do here. The attack never becomes a request.

Operational pitfalls

Raising the backlog is not a fix. A larger table takes longer to fill and fills anyway, while consuming more memory. It buys minutes, which is worth having and is not a defence.

Blocking source addresses achieves little, because the sources are usually forged. This is the practical consequence of the ingress filtering gap rather than a property of the attack.

Cookies engaging silently. Most kernels enable them as a threshold-triggered fallback, so the first sign is a performance complaint rather than an alert. Monitor the counter.

Safe validation

Against your own infrastructure, with written authorisation, using a controlled generator, as the testing page sets out. What to measure: half-open occupancy on every stateful device in the path — not only the one under test — and connection success rate for legitimate clients throughout.

Sources