SYN Flood Attack | TCP State Exhaustion and L4 Defense

A SYN Flood attack is a form of DDoS that exploits the TCP connection establishment process to exhaust pending-state structures in the target server’s kernel, preventing legitimate connections from being accepted.

How does a SYN Flood attack work?

The three-way handshake and connection queues

The three-way handshake is the process that establishes any TCP connection. The client sends a TCP segment with the SYN flag set, signaling its desire to connect. The server responds with SYN-ACK and records the request as a pending connection, waiting for the client’s final ACK. Only after receiving that ACK is the connection promoted to the ESTABLISHED state and the application notified.

In Linux, there is an important conceptual distinction between two queues operating in this process:

1. SYN queue (incomplete connection queue): holds connection requests that received a SYN and are waiting for handshake completion with the final ACK. The net.ipv4.tcp_max_syn_backlog parameter is associated with pressure on this queue.
2. Accept queue (complete connection queue): holds connections that are already established and waiting for the application to call accept(). Its effective size is limited by whichever is smaller: the application’s listen(backlog) argument or net.core.somaxconn.

SYN Flood primarily pressures the SYN queue. In high-volume attacks, effects spread further: CPU, softirq, Netfilter conntrack, firewall capacity, and bandwidth can all be exhausted.

The internal details of these structures — names, sizes, and behaviors — vary by kernel version, Linux distribution, and applied configuration. The concepts described here reflect general behavior; always validate in your target environment.

The asymmetry that makes the attack efficient

The attacker sends TCP segments with the SYN flag set — encapsulated in IP packets, with variable size depending on TCP options negotiated and any encapsulation overhead. The cost to the attacker is minimal: send and forget.

For each received SYN, the kernel must allocate memory and timers associated with the handshake — internal structures whose implementation varies by kernel version, negotiated options, Netfilter/conntrack state, loaded modules, and active SYN Cookies policy. The server maintains these structures for the entire wait period for the final ACK.

With IP spoofing — source addresses fabricated by the attacker — the final ACK never arrives. Each request occupies the SYN queue until it expires. When the queue saturates, new SYNs are dropped and legitimate users begin receiving connection errors.

The attack in operation

The attacker sends a continuous stream of SYN packets with spoofed source addresses. The server responds to each SYN with a SYN-ACK directed to the spoofed IP, which never returns the ACK. The SYN queue saturates within seconds. TCP-dependent services — HTTP/S, SSH, databases, APIs — become inaccessible even with the server’s hardware operating normally.

The table below shows indicators that differentiate normal traffic from an ongoing SYN Flood. These values are initial examples; calibrate against your environment’s historical baseline before using them as alert thresholds.

Attack variations

Distributed SYN Flood via botnet

Instead of a single host with a spoofed IP, the attacker uses a botnet of compromised devices, each sending SYNs with its real IP. Source addresses are genuine, which limits the effectiveness of BCP38 as the sole defense. Detection requires behavioral analysis: timestamp patterns, volume per IP, and the absence of subsequent ACKs are the relevant indicators.

Reflected SYN-ACK Flood

The attacker sends SYNs with the victim’s IP as the source address to third-party public servers. Those servers respond with SYN-ACKs directed at the victim’s IP, which receives massive volumes of unsolicited SYN-ACKs. Unlike the classic SYN Flood — which exhausts the connection queues — SYN-ACK Flood exhausts bandwidth and forces processing of unsolicited packets. Mitigation requires stateful inspection to discard SYN-ACKs that don’t correspond to locally initiated connections.

ACK Flood

Floods the target with ACK packets for non-existent TCP connections. For each packet, the TCP stack must perform a state lookup and classify the packet. Depending on the TCP stack, local state, and firewall rules, invalid ACK packets may be silently dropped, classified as invalid, logged, or result in a TCP response in specific contexts. The primary effect is the cost of packet processing and the pressure on CPU and stateful devices — not necessarily RST generation.

SYN Flood as a distraction in intrusion campaigns

In some extortion and intrusion campaigns, DDoS attacks may be used as an operational distraction while other malicious activities are carried out in parallel — data exfiltration, internal API abuse, ransomware installation. Organizations without effective alert segmentation and event correlation are particularly vulnerable to this pattern.

The recommendation is to correlate DDoS alerts with other telemetry sources: EDR, SIEM, identity logs, API logs, and network telemetry. A SYN Flood isolated at the perimeter, combined with anomalous activity on internal systems, signals a coordinated campaign.

Layer 4 defense techniques

SYN Cookies — RFC 4987

The most effective technique against SYN Floods with spoofed IPs. Formally defined in RFC 4987, SYN Cookies reduce or eliminate the need to maintain pending handshake state before client validation.

Instead of allocating state structures for each received SYN, the server encodes verifiable information directly in the Initial Sequence Number (ISN) of the SYN-ACK, using a cryptographic hash: ISN = hash(src_ip, src_port, dst_ip, dst_port, timestamp, secret_key).

When the client responds with the ACK, the acknowledgment number must be ISN + 1. The server recalculates the hash and validates that the client genuinely received the SYN-ACK — confirming the source IP is real. Only then does it create the complete state necessary for the connection. Spoofed IPs never return the correct ACK and therefore never force memory allocation.

SYN Cookies are particularly effective against SYN Floods with spoofing, where the final ACK does not return to the target. They do not directly address botnet attacks using real IPs that complete the handshake — those cases require complementary techniques such as rate limiting per IP, behavioral detection, and concurrent connection limiting.

Limitations and trade-offs: the space available in the ISN (32 bits) limits how much information can be encoded. The handling of TCP options such as Window Scaling, SACK, and timestamps depends on the implementation and operating system version. Modern implementations may preserve some of these options in certain scenarios; others may not. Evaluate the behavior on your specific kernel and distribution before depending on that preservation.

SYN Cookies should be used as protection under pressure, not as a substitute for capacity planning, source filtering, and upstream mitigation.

Linux: net.ipv4.tcp_syncookies=1 normally enables SYN Cookies under pressure or when overflow is detected in the pending request queue — the exact threshold depends on the kernel version and configuration. Do not recommend permanent SYN Cookies (tcp_syncookies=2) as a standard production practice without first validating the impact on TCP options and performance in your specific environment.

BCP38 and uRPF — IP spoofing filtering at the source

BCP38 (RFC 2827) defines the source filtering policy that ISPs should implement to eliminate IP spoofing: packets leaving a customer network with source addresses that do not belong to the IP block allocated to that customer should be discarded at the provider’s edge router, before entering the internet.

Unicast Reverse Path Forwarding (uRPF), defined in RFC 3704, is one of the possible implementation techniques. The edge router checks each received packet against its routing table:

• Strict uRPF: requires that the return route to the source IP uses exactly the same interface through which the packet arrived. This may be unsuitable for asymmetric or multihomed topologies.
• Loose uRPF: verifies only the existence of a route to the source address, without requiring the same input interface. More compatible with asymmetric routing, but with less filtering capability against sophisticated spoofing.

BCP38 is a source filtering policy/practice; uRPF is only one of the ways to implement it. BCP38 adoption remains incomplete and uneven across networks and providers — which keeps IP spoofing available as a widely accessible vector.

Adjusting tcp_synack_retries and queue size

Reducing net.ipv4.tcp_synack_retries (default: 5) decreases the number of SYN-ACK retransmissions before abandoning the pending connection, reducing the time each request occupies the queue. The effective expiration time depends on the number of retransmissions, the backoff algorithm, the kernel version, and network conditions — there is no universal value in seconds.

Operational risk: reducing tcp_synack_retries excessively can harm legitimate users on mobile, congested, or high-loss networks with high latency. Test and validate in a representative environment before applying in production.

Increasing net.ipv4.tcp_max_syn_backlog expands the SYN queue capacity. Under moderate attacks, this delays saturation — but it is not a definitive solution for large-scale attacks. Use it in combination with SYN Cookies, upstream BCP38, and edge termination.

Stateful firewall with half-open connection limiting

Stateful firewalls track the state of each TCP connection and can drop SYNs that exceed thresholds per source IP, per subnet, or globally. The limitation is that on-premise firewalls have finite state capacity — high-volume attacks frequently saturate the firewall itself before saturating the target server.

Edge TCP termination — stateful proxy as structural defense

The most robust defense against SYN Flood is not protecting the origin server directly — it is preventing incomplete SYNs from reaching it. Distributed edge networks act as stateful proxies: they absorb the three-way handshake at their own data centers and forward to the origin server only fully established connections.

In this model, edge nodes receive SYNs, perform the TCP handshake with the client, and — after validating that the connection was successfully completed — open a new TCP connection between the edge and the origin server, transmitting only validated application traffic. Connections with spoofed IPs do not complete the handshake and therefore do not reach the origin.

Combined with Anycast routing, this architecture geographically distributes the attack volume: a high volume of SYNs directed at a single IP block is absorbed by the data centers closest to the source, each handling a fraction of the total volume. For details on the differences between this model and traditional BGP scrubbing centers, see the specific article.

SYN Flood vs. QUIC Flood — protocol stack comparison

The emergence of HTTP/3 over QUIC created a resource exhaustion vector that operates at fundamentally different layers and structures from SYN Flood. QUIC uses UDP as encapsulation, but it is a secure, multiplexed transport protocol that requires TLS 1.3. A QUIC implementation can consume CPU, buffers, state tables, and user-space resources — the exact cost depends on the implementation, Retry policy, rate limiting, parsing, and cryptographic operations involved.

The most important structural difference is state location: in SYN Flood, the exhausted resource is state structures in the kernel — managed directly by the operating system. In QUIC Flood, the exhausted resource is in the user-space of the QUIC library — which affects the application but does not directly compromise the OS kernel.

The QUIC Retry packet and address validation reduce exposure to spoofed sources, but do not eliminate attacks from botnets using real IPs. The requirement for QUIC Initial datagrams of at least 1,200 bytes may raise the cost of some attacks, but should not be treated as a countermeasure equivalent to SYN Cookies.

Telemetry, diagnosis, and detection

Linux TCP state verification commands

Note: local packet capture (tcpdump, wireshark) may be inadequate in high-PPS scenarios — the capture process itself can contribute to overload. Prefer kernel counters and flow analysis tools for production environments under attack.

# Summary of all socket states, including SYN_RECV count
ss -s

# List connections in SYN_RECV state with address details
ss -nt state syn-recv

# TCP kernel counters (includes ListenOverflows, SyncookiesSent, etc.)
nstat -az

# Kernel logs — queue overflow messages and SYN Cookies activation
journalctl -k
# or on systems without journald:
dmesg | grep -i "syn\|cookie\|overflow\|flood"

Do not use cat /proc/net/stat/nf_conntrack to measure SYN queue occupancy. That file measures the Netfilter connection tracking table — relevant for stateful firewalls, but it does not represent the pending handshake queue occupancy of a TCP listener.

There is not necessarily a simple, universal, direct metric for “SYN queue occupancy percentage per listener” available in all Linux environments. The correct approach is to correlate multiple indicators.

Relevant TCP counters via nstat -az

The counters below are particularly useful for detecting SYN Flood. Names and availability may vary by kernel version and distribution.

Telemetry metrics and anomaly indicators

The threshold values below are initial examples. Calibrate against your environment’s historical baseline before using them as operational thresholds.

For high-volume environments, supplement with NetFlow, IPFIX, or sFlow — which allow correlating SYN volume, SYN-ACK volume, valid final ACKs, and SYN-ACK retransmissions at scale without overloading the host.

Detecting reflected SYN-ACK Flood

Reflected SYN-ACK Flood is detected by the presence of inbound SYN-ACKs without a corresponding SYN in the local connection state. In stateful firewalls, these appear as “out-of-state” or “invalid state” packets. In flow analysis, it manifests as high-volume TCP traffic with SYN+ACK flags arriving from multiple source IPs, with no corresponding TCP sessions going out from the server.

Common mitigation mistakes and solutions

Frequently asked questions

What differentiates SYN Flood from UDP Flood or DNS Amplification? SYN Flood exploits the cost of maintaining pending connection state in the kernel. UDP Flood and DNS Amplification are primarily volumetric and saturate network bandwidth — the UDP stack maintains no handshake state per packet. They are attack types with distinct impact surfaces.

Do SYN Cookies completely eliminate SYN Flood risk? For SYN Floods with spoofed IPs, SYN Cookies are highly effective — they reduce the need to maintain state before client validation. For botnets with real IPs that complete the handshake, SYN Cookies do not directly help. Complementary techniques are needed: rate limiting per real IP, behavioral detection, and concurrent connection limiting per IP. SYN Cookies also do not replace capacity planning, source filtering, and upstream mitigation.

Why is a larger SYN queue not a definitive solution? Increasing net.ipv4.tcp_max_syn_backlog expands capacity, but an attacker with sufficient volume simply saturates the larger buffer. It is a containment measure, not a resolution. The structural solution is either reducing the need to allocate state before validation (SYN Cookies) or absorbing SYNs before they reach the server (edge termination).

Why are on-premise firewalls insufficient for large-scale attacks? Stateful firewalls maintain their own state table to track TCP connections. A high-volume attack can saturate the firewall’s state table before even saturating the origin server — and a saturated firewall drops traffic indiscriminately, including legitimate traffic. Additionally, traffic must reach the organization’s network before the firewall can act, potentially saturating the uplink in the process.

How does BCP38/uRPF reduce IP spoofing? BCP38 is a filtering policy implemented by ISPs: packets with source addresses that don’t belong to the allocated IP block are discarded at the customer edge router before entering the internet. uRPF is one possible implementation technique — in strict mode, it verifies that the return route uses the same ingress interface; in loose mode, it verifies only the existence of a route. BCP38 adoption remains incomplete and uneven across networks and providers, which keeps IP spoofing available as a vector.

What is the difference between SYN Flood and QUIC Flood in terms of defense? SYN Flood is mitigated by kernel controls (SYN Cookies, queue tuning, BCP38) and stateful TCP termination at the edge. QUIC Flood requires QUIC termination at the edge with TLS inspection, because all QUIC traffic is encrypted — legacy middleboxes that don’t terminate QUIC cannot inspect the packets. QUIC’s attack surface is in user-space (CPU and state in the QUIC implementation), not directly in the kernel (pending connection queues).

How to implement on Azion

Azion offers a distributed edge TCP termination architecture that can help reduce the impact of SYN Flood attacks:

1. Stateful TCP termination at the edge: Azion’s data centers are designed to absorb the three-way handshake locally. The origin server receives only fully established connections — connections with spoofed IPs do not complete the handshake and do not reach the origin.
2. Always-on DDoS Protection: Detects and helps mitigate SYN Floods automatically, without manual activation or BGP convergence delays.
3. Global Anycast network: With data centers distributed globally that announce the same IP block via BGP Anycast, high volumes of SYNs are distributed geographically across points closest to the source, reducing the concentration of impact.
4. Network Shield and L3/L4 filtering: Filters malformed TCP packets, unsolicited reflected SYN-ACKs, and anomalous SYN patterns at Layers 3 and 4, before any application processing.

Learn more in the Azion DDoS Protection documentation.