What is a SYN Flood Attack?
Learn how SYN flood attacks exhaust server resources with half-open TCP connections, and how SYN cookies mitigate them.
Expected Interview Answer
A SYN flood is a denial-of-service attack that sends a large number of TCP SYN segments, often with spoofed source addresses, to exhaust a server's connection resources by leaving many half-open connections waiting in SYN_RECEIVED state that never complete the handshake.
Normally a server replies to a SYN with a SYN-ACK and waits for the final ACK to establish the connection, reserving a small amount of memory in its backlog queue for that pending connection. In a SYN flood, an attacker sends many SYNs, frequently with forged, unreachable source IP addresses, so the server's SYN-ACK replies go nowhere and the final ACK never arrives; each half-open entry sits in the backlog until it times out, and once the backlog fills up, the server can no longer accept legitimate new connections. The standard mitigation is SYN cookies, where the server encodes connection state into the initial sequence number of the SYN-ACK itself instead of storing it in memory, so it can reconstruct the connection from a valid final ACK without ever having held backlog state for a spoofed request. Additional mitigations include shortening the SYN_RECEIVED timeout, increasing backlog size, and filtering or rate-limiting SYNs upstream with firewalls or DDoS scrubbing services.
- Explains a classic resource-exhaustion denial-of-service pattern
- Motivates SYN cookies as a stateless defense
- Highlights why source IP spoofing amplifies the attack
- Connects to backlog queue and SYN_RECEIVED state tuning
AI Mentor Explanation
A SYN flood is like hundreds of fake booking requests flooding a stadium's ticket office, each claiming a seat but giving a fake pickup counter that will never come to collect the ticket. The office keeps a stack of pending reservations waiting for pickup, and once that stack fills with fake claims, real fans cannot reserve seats at all. Issuing tickets without pre-reserving a physical seat, and only confirming the seat once the fan actually shows up, is exactly the trick SYN cookies use to defeat this.
Step-by-Step Explanation
Step 1
Attacker sends SYNs
The attacker floods the target with SYN segments, often from spoofed, unreachable source IPs.
Step 2
Server replies and reserves state
The server sends SYN-ACK for each and reserves a half-open connection entry in its SYN_RECEIVED backlog.
Step 3
ACKs never arrive
Because sources are spoofed or unreachable, the final ACK never comes back, and entries sit until timeout.
Step 4
Backlog exhausted
Once the backlog fills with half-open entries, legitimate SYNs are dropped; SYN cookies or rate-limiting mitigate this.
What Interviewer Expects
- Explains half-open connections filling the SYN backlog
- Mentions source IP spoofing as part of the attack
- Describes SYN cookies as the primary stateless mitigation
- Names additional mitigations: backlog tuning, rate-limiting, firewalls
Common Mistakes
- Confusing a SYN flood with a generic volumetric DDoS at Layer 3/4
- Not knowing what SYN cookies actually encode or how they avoid storing state
- Thinking the attack requires completing the handshake
- Forgetting that spoofed source IPs are what prevent the attacker from receiving SYN-ACKs
Best Answer (HR Friendly)
“A SYN flood is an attack that spams a server with connection requests that are never finished, using fake return addresses so the server keeps waiting for a reply that will never come. Each of those half-finished requests ties up a small slot on the server, and enough of them can fill up all the available slots, blocking real users from connecting. Servers defend against this with a clever trick called SYN cookies, which lets them avoid reserving any space until a request is proven real.”
Code Example
# Check whether SYN cookies are enabled (1 = enabled)
sysctl net.ipv4.tcp_syncookies
# Enable SYN cookie protection
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Count connections stuck in SYN_RECV (a sign of an active SYN flood)
ss -n state syn-recv | wc -lFollow-up Questions
- How exactly do SYN cookies avoid storing per-connection state?
- Why does source IP spoofing make SYN floods harder to trace and block?
- How does a SYN flood differ from a UDP amplification attack?
- What role can upstream firewalls or scrubbing services play in mitigation?
MCQ Practice
1. What TCP state do half-open connections sit in during a SYN flood?
The server has sent SYN-ACK and is waiting for the final ACK, which places it in SYN_RECEIVED.
2. What is the primary stateless mitigation against SYN floods?
SYN cookies encode connection state in the SYN-ACK sequence number instead of storing it in memory.
3. Why do attackers commonly spoof source IPs in a SYN flood?
Spoofed sources ensure the SYN-ACK is never answered, keeping the half-open connection in the backlog until timeout.
Flash Cards
What is a SYN flood? — A DoS attack that exhausts server connection resources with many half-open TCP connections.
What state fills up? — The SYN_RECEIVED backlog queue.
Main mitigation? — SYN cookies, which avoid storing per-connection state until the ACK is verified.
Why spoof source IPs? — So the SYN-ACK reply is never answered, leaving the connection half-open until it times out.