🌊 04-01: TCP SYN Flooding¶

📌 Definition¶

SYN flooding is a Denial-of-Service (DoS) attack that abuses the TCP three-way handshake. Instead of legitimately completing connections, an attacker sends a massive number of SYN packets and deliberately never finishes the handshake — exhausting the server's ability to accept new, real connections.

👉 This isn't a bug in one specific piece of software — it's a structural weakness in how TCP was originally designed to track "in-progress" connections. If you haven't already, review 02-01: TCP Fundamentals & 3-Way Handshake for the full mechanics of the three-way handshake before continuing.

🧠 Quick Refresher: The Three-Way Handshake¶

Client                     Server
  │                           │
  │──────── SYN ─────────────▶│   "I'd like to connect (seq=X)"
  │                           │
  │◀─────── SYN-ACK ──────────│   "OK, here's my seq too (seq=Y, ack=X+1)"
  │                           │
  │──────── ACK ─────────────▶│   "Confirmed (ack=Y+1)" → connection ESTABLISHED
  │                           │

The moment the server sends SYN-ACK but hasn't yet received the final ACK, that connection is considered half-open. The server has to remember this half-open connection somewhere — in a data structure often called the backlog queue (or SYN queue) — while it waits for the client to finish.

💡 That memory reservation is exactly what SYN flooding attacks.

💥 How SYN Flooding Works¶

Step 1: Attacker sends a SYN, but with no intention of finishing¶

Attacker ──────── SYN (spoofed source IP) ───────▶ Server

Step 2: Server dutifully replies and reserves a slot¶

Attacker ◀─────── SYN-ACK ──────────────────────── Server
       (never sees this — spoofed source means the reply
        goes to some random/unreachable IP, not the attacker)

The server now has one half-open connection sitting in its backlog queue, waiting for an ACK that will never come.

Step 3: Repeat — thousands of times per second¶

Attacker: SYN, SYN, SYN, SYN, SYN, SYN, SYN, SYN, SYN, SYN ...
          (each with a different spoofed source IP/port)

Step 4: The backlog queue fills up¶

Every operating system enforces a limit on how many half-open connections it will track per listening port (e.g., Linux's net.ipv4.tcp_max_syn_backlog, commonly a few hundred by default). Once that queue is full:

Legitimate clients trying to connect get silently dropped or refused — their SYN packets arrive to find no room left in the queue.
The service looks down or unresponsive even though the machine itself may be perfectly healthy otherwise.

💥 This is a Denial-of-Service: not because data was stolen or altered, but because a legitimate resource (the ability to accept new connections) was exhausted.

🕵️ What This Looks Like in a Packet Capture¶

If you opened Wireshark during a SYN flood, the telltale signs are unmistakable:

An overwhelming volume of [SYN] packets, arriving extremely fast, often many per second from the same capture window.
Source IP addresses that look random, spoofed, or nonsensical — many won't correspond to real, reachable hosts at all (see 04-02: IP Spoofing in Attacks for exactly why attackers do this).
The server dutifully replying with [SYN, ACK] to each one — but no corresponding [ACK] ever completing the handshake.
If you check the server's connection table (netstat -nat on Linux), you'll see a huge number of connections stuck in the SYN_RECV state, rather than reaching ESTABLISHED.

# Count how many connections are stuck half-open on a given port
netstat -tna | grep SYN_RECV | wc -l

A healthy server might have a handful of SYN_RECV entries at any moment (normal handshake latency); hundreds or thousands sustained over time is a strong signal of an active SYN flood.

🖼️ Realistic Scenario¶

A small e-commerce site runs its checkout service on a single web server. An attacker wants to take the site offline during a big sale to sabotage a competitor. Using a simple script (often built with a tool like Scapy — see 03-02: Sniffing Tools (Scapy/tcpdump)), the attacker floods the server's port 443 with tens of thousands of spoofed SYN packets per second.

Within moments, the connection backlog queue is saturated with half-open junk connections. Real customers trying to check out find their browsers spinning or timing out — the server is too busy holding open (soon-to-expire) fake handshakes to accept their legitimate SYN packets. The site appears "down," support tickets flood in, and sales are lost — all without the attacker ever needing to breach any actual data or authentication.

🔧 Why the Attack Eventually "Heals" Itself (Without a Fix)¶

Half-open connections aren't held forever. If no ACK arrives, the server will retransmit the SYN-ACK a limited number of times (e.g., 5 retries by default on Linux, net.ipv4.tcp_synack_retries) before giving up and freeing that slot. But if the attacker keeps sending new SYNs faster than old entries time out, the queue simply never has room to breathe — a sustained flood keeps every slot perpetually occupied.

📌 Key Takeaways¶

SYN flooding is a Denial-of-Service attack that exploits the "half-open" state created between SYN and the final ACK of the TCP three-way handshake.
The attacker sends many SYN packets and never completes the handshake, filling the server's limited backlog/SYN queue.
Once the queue is full, legitimate clients cannot establish new connections — the service appears down.
Attackers almost always use spoofed source IPs, both to hide their identity and to prevent ever receiving (and having to respond to) the SYN-ACK.
In a packet capture, look for a flood of [SYN] packets from varied/implausible source IPs with no matching final [ACK], and many connections stuck in SYN_RECV.
The queue self-heals slowly through retransmission timeouts, but a sustained flood outpaces that recovery.
Defenses like SYN cookies and backlog tuning are covered in depth in 04-05: Mitigations (SYN Cookies & Randomization).