All DDoS Definitions
DDoS Testing Definition

SYN Cookies

SYN cookies are a Layer 4 (transport) defensive control against SYN floods, one of the protections a thorough DDoS test is built to verify. Instead of allocating connection state when a SYN arrives, the server encodes the connection parameters into the initial sequence number of its own SYN-ACK, and reconstructs the state only if a valid ACK comes back. An unanswered SYN therefore costs no memory at all.

SYN cookies: no connection state until a valid ACK returns Without SYN cookies: the backlog fills SYN flood half-open, never ACKs SYN backlog half-open entry pins memory half-open entry pins memory half-open entry pins memory half-open entry pins memory full: legitimate SYNs dropped With SYN cookies: zero memory held SYN arrives spoofed or not encode state into the SYN-ACK ISN allocates 0 bytes no backlog entry valid ACK returns state rebuilt only then An unanswered SYN costs no memory at all. A test verifies tcp_syncookies is actually enabled and holds under a real flood, since an OS upgrade can silently reset it. BlackNeuron™
SYN cookies: the server encodes connection state in the SYN-ACK and holds no memory until a valid ACK returns

What the sequence number carries

A normal handshake reserves an entry in the SYN backlog the moment a SYN arrives and holds it until the ACK completes the connection. A SYN flood fills that table with half-open entries that never complete, and once it is full, legitimate SYNs are dropped.

SYN cookies take the table out of the equation. When the backlog would otherwise overflow, the kernel stops storing state and instead computes the initial sequence number of its SYN-ACK as a function of the connection itself: a slowly incrementing timestamp in the high bits, an index into a small table of common MSS values, and a keyed hash of the source and destination addresses and ports plus a server secret in the remaining bits.

The server then forgets everything. If an ACK returns, its acknowledgement number is the cookie plus one, so the server recomputes the hash, confirms it signed this exact four-tuple recently, and rebuilds the connection from scratch with no state ever having been held. A spoofed source never sends that ACK, so its attempt evaporates at zero cost.

This is where SYN cookies differ from a SYN proxy. The proxy is a separate inline device that shields the origin regardless of the origin's own tuning; SYN cookies are a technique the origin's own kernel applies to itself. Same handshake-validation idea, different place in the path.

The trade-off

Folding connection state into 32 bits means some of that state does not fit. The MSS is squeezed into a handful of table indices rather than an exact value, and TCP options negotiated in the SYN (window scaling, selective acknowledgement, and others) are not preserved unless timestamps are enabled to carry them, because the server discarded the SYN that announced them. On a high-latency or high-bandwidth path, losing window scaling can noticeably cap throughput.

That is why SYN cookies are engineered to engage only when the backlog is actually under pressure, rather than for every connection. Normal traffic keeps full option support, and the degraded path is reserved for the moment the alternative is dropping connections outright.

SYN cookies: state encoded in the SYN-ACK, no memory until the ACK incoming SYNs kernel + cookie no backlog entry held listening socket table stays clean valid ACK: connection rebuilt spoofed SYN: no ACK, costs nothing BlackNeuron™
Animated SYN cookies: legitimate clients that return a valid ACK have their connection rebuilt and are forwarded to the socket, while spoofed SYNs that never send an ACK are absorbed with no backlog entry held

What a DDoS test measures

SYN cookies are the control that turns backlog exhaustion from an outage into a non-event, so a test verifies they are genuinely enabled and effective under load rather than merely configured. The relevant knobs are net.ipv4.tcp_syncookies, tcp_max_syn_backlog, and somaxconn, and the test drives a real spoofed-SYN flood while confirming three things: the connection table stays clean, legitimate clients still complete handshakes during the flood, and throughput for those clients does not collapse from the option loss.

The finding that recurs is silent regression. A kernel or OS upgrade resets tcp_syncookies to a default the operator did not expect, and the protection a stack believes it has is quietly gone until an attack finds the gap. The mechanics of SYN floods and other L4 vectors are covered in Understanding DDoS Attack Vectors.