SYN flood

What a SYN flood is and how it works

A TCP connection starts with a three-way handshake: the client sends SYN, the server answers SYN-ACK and the client replies with ACK. After the first SYN the server keeps state for the half-open connection and waits for that last ACK. The kernel caps how many such entries a listening socket may hold. A SYN flood fills that backlog with requests that never finish, so new SYNs are ignored or replace older entries and real clients cannot connect.

RFC 4987 notes that the source addresses are often spoofed, so the SYN-ACKs go to hosts that never answer and the entries linger until a timer expires. It also stresses that the attack targets end-host resources, which need far fewer packets to exhaust than a bandwidth flood. That makes it a protocol attack rather than a volumetric one. Sent from many machines, for example a botnet, it becomes a DDoS attack.

How to spot a SYN flood and read the kernel settings

The evidence lives in the network stack, not in the web server log, because the handshake never completes. Run these on the affected host:

ss -Htan state syn-recv | wc -l
sudo journalctl -k | grep -i 'possible syn flooding'
nstat -az TcpExtTCPReqQFullDoCookies TcpExtTCPReqQFullDrop TcpExtListenOverflows
sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

In the kernel source the warning ends with "Sending cookies" or "Dropping request", and the matching counter rises: DoCookies when cookies are on, Drop when they are off. ListenOverflows is a separate problem, a full accept queue. The warning also fires under honest overload, and the ip-sysctl documentation says to tune tcp_max_syn_backlog, tcp_synack_retries and tcp_abort_on_overflow before blaming cookies. Compare the SYN-RECV count with your normal level: a handful is routine, a steadily growing number is not. For reference, tcp_synack_retries defaults to 5, about 31 seconds to the last retransmission, and tcp_max_syn_backlog has a minimum of 128 on low-memory machines and grows with memory.

Limits, trade-offs and common mistakes

SYN cookies keep no state: the information is encoded in the SYN-ACK sequence number. RFC 4987 lists the price. Some TCP options are lost (window scaling is disabled and SACK is limited), and if the final ACK is lost the application may never learn of the connection, which hurts protocols where the server speaks first, such as SMTP. The kernel documentation calls cookies a fallback and warns against using them to carry a legitimate connection rate.

Frequent mistakes follow from this:

• Blocking source addresses one by one: with spoofed sources the list is meaningless.
• Raising the backlog without limit: the RFC reports serious negative effects as it grows.
• Cutting tcp_synack_retries too far: a shorter timer can stop slow but legitimate handshakes.
• Forcing tcp_syncookies=2 everywhere: cookies are then generated for every SYN.

Where a SYN flood fits in your defence

On the host, the default tcp_syncookies=1 is a last line, not a plan. RFC 4987 also describes a firewall or proxy that completes the handshake before a connection reaches the protected host. That moves the problem away from your server, and it is what a CDN, a reverse proxy or your provider's filtering does for you. CISA advises contacting your provider early and considering a DoS protection service.

Keep the origin address private and allow only the proxy to reach it, as the DDoS protection guide explains, and use the firewall guide for per-address limits on application ports. For the scale of real attacks see the Cloudflare H1 2026 report breakdown. If a large outage is not an attack at all, the Yandex data center article shows how to tell.

Related terms: Protocol attack, DDoS attack, Botnet, Rate limiting, Firewall.