Overview #

In this experiment I run a SYN Flood — a kind of DoS (Denial of Service) attack — in a virtual lab.

From the attacker (Kali Linux), I use the hping3 tool to send a flood of SYN packets at a deliberately vulnerable target (Metasploitable2).

The aim is to develop a hands-on understanding of TCP's three-way handshake, how a resource-exhaustion attack abuses it, and how attack volume relates to server processing capacity.# 1. What is a SYN Flood?

A SYN Flood abuses the TCP connection-establishment process — the three-way handshake.

The attacker fires SYN packets — the first packet of the handshake — at the server in bulk. The server politely responds with SYN/ACK and waits for the attacker's final ACK. The attacker, by design, never sends one.

That leaves the server with a pile of "waiting for ACK" half-open connections (in SYN_RECV state). When the resources (the connection queue) tracking these half-open connections are exhausted, the server can no longer accept new legitimate connections — service denied.

2. Building the environment #

Set both VMs to "Host-only" or "Bridged" so they share a network segment.

• Attacker: Kali Linux (IP: 192.168.2.175)
• Victim (web server): Metasploitable2 (IP: 192.168.2.177)
• Attack tool: hping3

Victim setup (Metasploitable2) #

Metasploitable2 ships with Apache running by default.

It's preloaded with deliberately vulnerable configurations, outdated software versions, and vulnerable applications — designed for learning and practicing penetration-testing techniques.

1. **1. Disable SYN Cookies (for the experiment):** Linux has a built-in SYN-Flood resilience feature called "SYN Cookies." Check whether it's on, and if so, turn it off — that'll make the experiment's effects clearer. (`1` = enabled, `0` = disabled.) ``` # Check current setting sysctl net.ipv4.tcp_syncookies

# Disable (makes the attack land harder)
sudo sysctl -w net.ipv4.tcp_syncookies=0

```

2. 2. Show a resource monitor (optional): Watching CPU and network load with top or vmstat makes the impact of the attack much more visible.

3. Running and observing the attack #

On the attacker side (Kali Linux), open Wireshark to observe packets and a terminal to launch the attack. In Wireshark, apply a filter like ip.addr == 192.168.2.177.

Launch the attack #

First, run a single hping3 process at maximum speed using the --flood option.

This experiment uses our real source IP — no spoofing — because we're just experimenting. SYN Flood doesn't depend on receiving responses, so in real attacks the source IP is generally spoofed at this point to bypass firewalls and complicate log analysis.

# -S (SYN flag), -p 80 (port 80), --flood (max-speed transmission)
sudo hping3 -S -p 80 --flood 192.168.2.177

Result #

Wireshark fills up with a torrent of SYN packets, and Metasploitable2's resource monitor shows CPU and network usage climbing.

Run the following on Metasploitable2 to count TCP connections currently in `SYN_RECV` state:

# How many half-open (ACK-pending) connections do we have right now?
netstat -nat | grep SYN_RECV | wc -l

The count rises noticeably above its baseline (no attack) value.

However, when I opened http://192.168.2.177 from the host browser, the page still loaded — with some lag, but it loaded.

Why didn't the attack take it down? #

Looking at the Wireshark capture again carefully —

After Kali sends a SYN to Metasploitable2, Metasploitable2 returns a SYN/ACK as expected (step 2 of the three-way handshake). That part is fine. But then Kali sends back an RST.

The likely reason: `hping3` crafts packets in a non-standard way, so the kernel has no record of the connection on its own books. When the SYN/ACK arrives, the kernel sees an "unsolicited" reply and automatically returns an RST to say "this conversation isn't valid." That ends each half-open connection on Metasploitable2 quickly, the SYN queue stays clear, and the server keeps serving.

So I block Kali from sending RSTs back:

sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP
# -A OUTPUT: append a rule to the OUTPUT (outbound) chain
# -p tcp: targeting TCP
# --tcp-flags RST RST: matches packets with the RST flag set
# -j DROP: drop matching packets (don't send them)

Re-running the attack #

Checking SYN_RECV again — it pegs at 256, the default maximum length of Metasploitable2's SYN queue, and stays there: nothing is being consumed.

And now, opening the site from the host browser — **Metasploitable2 returns nothing at all, and we eventually time out.** When you're done, undo the rule like so (just change `-A` to `-D`):

sudo iptables -D OUTPUT -p tcp --tcp-flags RST RST -j DROP

4. Discussion and defenses #

This experiment makes one thing very clear: whether SYN Flood succeeds depends heavily on the attacker's own OS kernel behavior.

Just running hping3 isn't enough — the OS auto-replies with RSTs, the server's SYN queue never fills, and the attack fizzles. Only after using iptables to suppress those automatic replies does the attack actually exhaust the server's resources.

Threats and risks #

• Service downtime: legitimate users can't reach the service — lost business, eroded trust.
• Financial damage: when running on cloud infrastructure (AWS, GCP, and the like), the flood traffic counts as data-transfer billing. A sustained attack can produce eye-watering invoices.

Defense #

SYN Flood is old, but it's still effective.

For server / network operators:

52. Enable SYN Cookies: the most basic defense. Setting net.ipv4.tcp_syncookies = 1 at the OS level prevents the SYN queue from overflowing.
53. Firewall / IPS: detect abnormal SYN-packet rates from a single source IP, apply rate limiting (cap connections per time window), or block the offending address.
54. DDoS protection services: practical and powerful at scale. AWS Shield, Cloudflare, Akamai, and similar services scrub attack traffic across very large network capacity and forward only the legitimate portion to your servers.