SYN Flood Attack | TCP State Exhaustion and L4 Defense

A SYN flood attack exploits the TCP connection establishment process by sending large volumes of TCP SYN packets without completing the handshake, filling the server’s connection table with half-open connections and preventing legitimate clients from establishing new connections. SYN floods are among the oldest and most common DDoS attack types, first documented in 1996 and still accounting for a significant share of attacks today.

Last updated: 2026-07-27

TL;DR: TCP requires a three-step handshake (SYN → SYN-ACK → ACK) before any data transfer. A SYN flood sends millions of SYN packets with spoofed source IPs; the server sends SYN-ACK responses that go unanswered, leaving connections in a half-open state until timeout. The connection table fills; new legitimate connections are rejected. SYN cookies solve this by encoding connection state into the SYN-ACK sequence number, requiring no server-side table entry until the handshake completes.

The TCP Three-Way Handshake

TCP (Transmission Control Protocol) establishes connections using a three-step handshake before data transfer:

Step 1: Client sends SYN
Client → Server: TCP SYN (seq=x)
[Server allocates entry in connection table (SYN_RCVD state)]

Step 2: Server responds with SYN-ACK
Server → Client: TCP SYN-ACK (seq=y, ack=x+1)
[Server waits for ACK; connection is "half-open"]

Step 3: Client completes with ACK
Client → Server: TCP ACK (seq=x+1, ack=y+1)
[Connection established; state moves to ESTABLISHED]

At Step 2, the server creates a Transmission Control Block (TCB) in memory—a data structure tracking connection state (sequence numbers, window size, buffers). This TCB exists before the connection is confirmed by the client’s ACK in Step 3. The period between SYN and ACK is the half-open state.

Resource cost of the TCB:

• Memory: 280 bytes per half-open connection (Linux kernel default)
• Queue limit: Default backlog of 128–1024 half-open connections per port (varies by OS and configuration)
• Timeout: SYN timeout is typically 60–75 seconds before the server gives up and frees the TCB

How SYN Flood Exploits This

An attacker sends millions of SYN packets to the target server, each with a different spoofed source IP address. For each SYN:

1. Server receives SYN and creates a TCB
2. Server sends SYN-ACK to the spoofed IP (which may not exist, or belongs to an unrelated host)
3. No ACK arrives (the spoofed source never receives or responds to SYN-ACK)
4. TCB remains in half-open state for 60–75 seconds

Normal traffic:
Client (real IP) ──SYN──▶ Server
Client (real IP) ◀──SYN-ACK── Server
Client (real IP) ──ACK──▶ Server ← Connection established

SYN flood:
Bot (spoofed IP: 198.51.100.1) ──SYN──▶ Server
198.51.100.1 ◀──SYN-ACK── Server (or dropped if IP doesn't exist)
[No ACK arrives - connection table entry stays open for 60 seconds]

Bot (spoofed IP: 198.51.100.2) ──SYN──▶ Server [another table entry]
Bot (spoofed IP: 198.51.100.3) ──SYN──▶ Server [another table entry]
... [millions more]

Result: Connection table full, legitimate clients cannot connect
Legitimate client ──SYN──▶ Server
Server: Connection refused (table full)

Attack Metrics

SYN floods remain one of the most common DDoS attack vectors because each spoofed packet can force a server or stateful device to reserve connection state until timeout.

SYN Cookies: The Primary Defense

SYN cookies, invented by D.J. Bernstein and Eric Schenk in 1996 and described in RFC 4987 (2007), solve the half-open state problem by encoding connection information into the SYN-ACK sequence number instead of allocating a TCB.

How SYN cookies work:

Step 1: Client sends SYN
Client → Server: TCP SYN (seq=x)
[Server does NOT allocate TCB]

Step 2: Server encodes connection state in SYN-ACK sequence number
Server computes: cookie = hash(src_ip, src_port, dst_ip, dst_port, timestamp)
Server → Client: TCP SYN-ACK (seq=cookie, ack=x+1)
[Server discards connection data—no table entry]

Step 3: Client completes handshake (if real)
Client → Server: TCP ACK (seq=x+1, ack=cookie+1)
Server verifies: ACK number - 1 = cookie → valid connection
Server → allocates TCB and establishes connection
[Spoofed IPs never send ACK—no table entry ever created]

The server allocates memory only after the ACK arrives and the cookie validates. Spoofed SYN packets trigger no persistent state on the server.

SYN cookies trade-off: When SYN cookies are active, the SYN-ACK does not include TCP options like window scaling and SACK (Selective Acknowledgment) because those cannot be encoded in the sequence number cookie. This slightly reduces connection quality for legitimate users. Modern implementations (Linux kernel 3.x+, FreeBSD 9+) minimize this impact.

Linux SYN cookie behavior:

• Automatically activates when the SYN backlog queue is full
• net.ipv4.tcp_syncookies = 1 enables always-on cookies
• net.ipv4.tcp_max_syn_backlog configures the backlog size before cookies activate

Additional Mitigation Techniques

TCP proxy is particularly effective: a reverse proxy or load balancer completes the TCP handshake with the client before establishing a connection to the backend server. Only validated connections (with completed ACK) reach the backend, which never sees half-open connections.

SYN Flood with HTTPS

When targeting HTTPS endpoints (port 443), SYN flood attacks also prevent TLS handshakes from starting. The impact is identical—connection table exhaustion—but additionally, any legitimate connection that does establish TCP must then complete a TLS handshake before any HTTP traffic flows.

Some advanced attacks combine SYN floods with TLS handshake exhaustion: completing TCP connections but immediately beginning expensive TLS renegotiations.

Historical Context

SYN flood was first documented in a CERT advisory in 1996 (CA-1996-21). It was the first major DDoS technique to gain widespread attention and drove the development of SYN cookies as a defense. Despite being nearly 30 years old, SYN flood remains prevalent because:

• Spoofing makes source IP blocking ineffective
• Low bandwidth required (a 1 Gbps link can saturate a default backlog)
• Many devices and embedded systems still lack SYN cookie support
• Attackers combine SYN flood with other attack vectors

Frequently Asked Questions

What is a SYN flood attack? A SYN flood attack sends millions of TCP SYN packets to a server without completing the three-way handshake. Each SYN causes the server to allocate a half-open connection entry that waits for an ACK that never arrives. The connection table fills and legitimate connections fail.

What is the TCP three-way handshake? The TCP three-way handshake is the connection establishment protocol: the client sends SYN, the server responds with SYN-ACK, and the client completes with ACK. After the ACK, the connection is established and data transfer can begin. SYN floods abort this process after the SYN-ACK step.

What are SYN cookies? SYN cookies are a defense mechanism that encodes TCP connection state into the sequence number of the SYN-ACK response, eliminating the need to store half-open connection state on the server. The server can validate a returning ACK by checking that the ACK number matches the expected cookie value, then allocates memory only for validated connections.

Why does SYN flood use spoofed IP addresses? Spoofed source IPs ensure that the SYN-ACK responses never reach the attacker’s machines (which would reply with RST, allowing the server to close the half-open connection). With spoofed IPs, SYN-ACK goes to random hosts that ignore it or to non-existent IPs, leaving the server’s half-open connections stuck.

Can a firewall stop a SYN flood? Stateful firewalls can apply SYN rate limiting per source IP, limiting the number of SYN packets accepted from any single source per second. This is effective when source IPs are not spoofed. For spoofed SYN floods, each packet has a different source IP and per-IP rate limiting is ineffective. Volume-based detection and SYN cookies at the server or upstream scrubbing are required.

How many SYN packets per second can cause a server to fail? The number depends on the server’s backlog queue size and SYN timeout. A server with a backlog of 1,024 and 60-second timeout can only hold 1,024/60 ≈ 17 new half-open connections per second before the table fills. Attackers easily exceed this rate. Servers with SYN cookies disabled and default settings can be overwhelmed by a few thousand SYN packets per second.

Does enabling SYN cookies affect performance for legitimate users? Slightly. When SYN cookies are active, TCP options like window scaling and SACK (Selective Acknowledgment) may not be negotiated for new connections, which can reduce throughput for high-latency connections. Modern Linux kernels include the TCP SACK option in the SYN-ACK even when SYN cookies are active, minimizing this impact. For most traffic, the performance difference is imperceptible.

What is the maximum scale of a SYN flood attack? SYN floods are limited by the attacker’s packet generation rate rather than bandwidth, since SYN packets are small (40–60 bytes). Large botnets can generate millions of SYN packets per second, which is enough to exhaust default backlog queues long before bandwidth is saturated.

How to Implement on Azion

Azion’s network edge handles TCP connection establishment, absorbing SYN floods before they reach your origin:

• DDoS Protection provides always-on SYN flood detection and mitigation at the edge; SYN packets are handled by Azion’s distributed network, not your origin
• Network Layer Protection applies network-level rules including SYN rate limiting and connection table protection
• Edge Firewall enables custom rules for connection-rate-based blocking
• WAAP provides comprehensive protection combining network and application layer defenses

Because Azion terminates TCP connections at the edge, your origin server’s connection table is never exposed to SYN flood traffic—only established, validated connections from Azion’s infrastructure reach your origin.

Related Resources

• What Is a DDoS Attack?
• DDoS Attack Types
• What Is DDoS Protection and Mitigation?
• Azion DDoS Protection
• Azion Network Layer Protection

Sources:

• CERT/CC. “Advisory CA-1996-21: TCP SYN Flooding and IP Spoofing Attacks.” September 1996.
• Bernstein, D.J. “SYN cookies.” 1996. cr.yp.to/syncookies.html
• IETF. “Transmission Control Protocol.” RFC 793. 1981.
• IETF. “Defending Against Sequence Number Attacks.” RFC 6528. 2012.
• IETF. “Defending Against SYN Flood DoS Attacks with SYN Cookies.” RFC 4987. 2007.
• CERT/CC. “Advisory CA-1996-21: TCP SYN Flooding and IP Spoofing Attacks.” September 1996.
• Linux Kernel Documentation. “TCP SYN Cookies.” kernel.org, 2024. 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.