TCP SYN Flood & Mitigation
Walk through the TCP SYN Flood lifecycle with guided steps for SYN, SYN-ACK, ACK, backlog, and SYN cookies.
Continue with the guided workspace
Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.
A TCP SYN flood is a denial-of-service attack that abuses the three-way handshake: the attacker floods a server with SYN packets using spoofed source addresses, never completing the handshake, so the server allocates a half-open connection for each SYN until its backlog is exhausted and legitimate clients are refused. Defenses like SYN cookies and firewalls restore availability by making the handshake stateless or filtering the flood.
Mental Model
Think of the TCP handshake like a phone call. A normal call (handshake) consists of the caller saying “Hello” (SYN), the receiver saying “Hello, who is it?” (SYN-ACK), and the caller saying “It’s Alice” (ACK) before starting the conversation. In a SYN Flood, a caller makes thousands of calls, but as soon as the receiver says “Hello, who is it?”, the caller hangs up or stays silent. The receiver keeps holding the line (half-open connection in the backlog), waiting for a response. Eventually, the receiver runs out of physical phone lines (backlog exhaustion) and cannot pick up any calls from real friends.
For parameter-driven experiments, the TCP SYN Flood Simulator sandbox is also available.
Components and Why They Exist
Client Device
Represents legitimate users trying to establish a connection with the server. Initiates connection requests by sending a SYN packet and completing the 3-way handshake upon receiving SYN-ACK. In the demo, observe the client sending the final ACK to complete the handshake and open a secure socket.
Attacker (Botnet)
Simulates malicious actors launching a denial-of-service attack on the network endpoint. Floods the server with SYN packets using spoofed source IPs and ignores the server’s SYN-ACK replies. In the demo, observe how the attacker’s queries consume all available slots in the server’s backlog queue.
Firewall
Serves as a gatekeeper to inspect incoming traffic and drop suspected malicious network packets. Filters out traffic originating from blocked IPs or subnets, preventing them from reaching the backend server. In the demo, watch the firewall intercept and discard malicious requests when IP blocking is activated.
Server (OS Kernel & SYN Backlog)
The destination system running the operating system network stack to host connections. Manages incoming TCP handshake states in the SYN backlog and validates connections dynamically. In the demo, observe backlog queue exhaustion under attack, and notice how SYN cookies bypass backlog slot allocation.
Edge Cases and Misconceptions
- Spoofed IPs bypass simple firewalls: Because attackers spoof the source IP addresses of the
SYNpackets, a firewall cannot simply block a single IP. It must analyze traffic patterns or verify client responsiveness. - SYN Cookies are CPU-intensive but stateless: SYN cookies protect memory by preventing backlog table allocation. However, calculating the cryptographic hash (cookie) for every incoming packet consumes CPU cycles, transferring the bottleneck from memory to CPU if the packet flood is sufficiently massive.
- Backlog sizes are limited: System administrators can increase the size of the SYN backlog queue (
tcp_max_syn_backlogin Linux), but this only delays exhaustion. On a high-speed network link, a flood can exhaust even a large backlog in seconds.
Common Questions
What is a TCP SYN Flood attack?
A SYN Flood is a Denial-of-Service (DoS) attack where an attacker sends a high volume of TCP SYN requests with spoofed IPs. The attacker ignores the server's SYN-ACK responses, leaving half-open connections that consume all available slots in the server's SYN backlog queue.
How does connection exhaustion occur in TCP?
When a server receives a SYN packet, it allocates a slot in its backlog queue to track the half-open connection. If these slots are filled by malicious requests that never finish the handshake, the queue is exhausted, and the server drops incoming SYN requests from legitimate clients.
What are SYN Cookies and how do they work?
SYN Cookies are a stateless defense. Instead of allocating backlog memory when a SYN arrives, the server encodes connection parameters into the SYN-ACK's initial sequence number (the cookie). When the client responds with an ACK, the server validates the cookie mathematically, establishing the connection without using backlog slots during the intermediate state.
What are the limitations of SYN Cookies?
While SYN Cookies effectively prevent memory exhaustion, they disable optional TCP features like TCP window scaling and selective acknowledgments (SACK) unless carefully encoded, which can reduce performance for normal connections during high throughput.
How does Firewall IP Blocking protect against SYN Floods?
Firewall blocking drops traffic from suspected malicious subnets or IPs before they reach the application server. This protects the server's backlog queue, but requires accurate detection to avoid blocking legitimate user IPs (false positives).
What is the difference between the SYN backlog and the Accept backlog?
The SYN backlog stores half-open connections (SYN_RCVD state) that are still completing the 3-way handshake. The Accept backlog (or listen queue) stores fully established connections (ESTABLISHED state) waiting to be accepted by the application's accept() system call.
Why do attackers spoof source IP addresses in a SYN flood?
Spoofing serves two purposes: first, it hides the attacker's true identity, making simple IP blocking difficult. Second, it causes the server to send its SYN-ACK packets to the spoofed addresses (which either discard them or don't exist), ensuring that the final ACK is never sent to close the handshake.
How are connection parameters encoded in a SYN Cookie?
The server encodes the connection's MSS (Maximum Segment Size), a counter that increments every 64 seconds, and a cryptographic hash of the client IP, port, server IP, port, and counter into the 32-bit initial sequence number (ISN).
How does the server validate the SYN Cookie when the client's ACK arrives?
When the client returns the final ACK packet, its acknowledgment number is the server's initial sequence number plus 1. The server subtracts 1 from the acknowledgment number and recalculates the cryptographic hash using the packet's headers. If the hash matches, the server allocates a socket, even though it had no record of the initial SYN.