How to Simulate and Mitigate DDoS Attacks on Linux with Docker and iptables

What is DDoS?

DDoS (Distributed Denial of Service) expands the classic DoS concept by using many compromised hosts to flood a target, exhausting bandwidth, system resources (CPU, memory, connection tables) or application resources, causing severe performance degradation.

Bandwidth exhaustion : network devices hit their maximum throughput, leading to congestion.

System resource exhaustion : CPU, memory, or kernel connection tables become saturated.

Application resource exhaustion : the application spends all its time handling bogus requests.

Case Preparation

Three Linux machines are required: an application host , an attacker host , and a client host . Install the following tools on each machine:

docker

sar

hping3

tcpdump

curl

Application Server

Start a simple Nginx container on the application host:

# docker run -itd --name=nginx --network=host nginx
# docker ps
CONTAINER ID   IMAGE   COMMAND               CREATED          STATUS          PORTS   NAMES
a8b3685d5eef   nginx   "/docker-entrypoint.…"   24 seconds ago   Up 21 seconds   nginx

Client

Verify the service works with curl:

# curl -s -w 'Http code: %{http_code}
Total time:%{time_total}s
' -o /dev/null http://172.31.88.139
Http code: 200
Total time:0.002437s

Normal response time is about 2 ms.

Attacker

Generate a SYN‑Flood from the attacker host using hping3:

# hping3 -S -p 80 -i u10 --flood 192.168.0.30
HPING 172.31.88.139 (eth0 172.31.88.139): S set, 40 headers + 0 data bytes

Impact Observation

After the flood starts, the client curl request times out:

# curl -s -w 'Http code: %{http_code}
Total time:%{time_total}s
' -o /dev/null http://172.31.88.139
Http code: 000
Total time:10.001s
curl: (28) Connection timed out after 10000 milliseconds

sar shows a huge packet‑per‑second rate while bandwidth remains low, indicating many tiny SYN packets (≈ 54 B each):

# sar -n DEV 1
IFACE   rxpck/s txpck/s rxkB/s txkB/s ...
eth0    22274.00 629.00 1174.64 37.78 ...

tcpdump captures the SYN packets:

# tcpdump -i eth0 -n tcp port 80
09:15:48.287047 IP 172.31.82.28.27095 > 172.31.88.139: Flags [S], seq 1288268370, win 512, length 0
...

The captured Flags [S] confirm a SYN‑Flood. A Wireshark screenshot (below) visualises the flood.

Understanding the Attack

Each SYN creates a half‑open (SYN‑RECEIVED) connection. The server replies with SYN‑ACK and waits for the final ACK. Because the connection table is limited, thousands of half‑open entries exhaust it, preventing legitimate connections.

netstat confirms many connections in SYN_RECV state:

# netstat -n -p | grep SYN_REC
tcp 0 0 172.31.88.139:80 172.31.82.28:12503 SYN_RECV -
...

Counting them yields 193 half‑open connections:

# netstat -n -p | grep SYN_REC | wc -l
193

Mitigation with iptables

Block the offending source IP:

# iptables -I INPUT -s 172.31.82.28 -p tcp -j REJECT

After the rule, curl succeeds again (≈ 1.5 s response).

# curl -w 'Http code: %{http_code}
Total time:%{time_total}s
' -o /dev/null --connect-timeout 10 http://172.31.88.139
Http code: 200
Total time:1.572171s

If the attacker randomises source IPs (e.g., --rand-source), the simple block no longer works. Rate‑limiting rules can help:

# iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT
# iptables -I INPUT -p tcp --dport 80 --syn -m recent --name SYN_FLOOD --update --seconds 60 --hitcount 10 -j REJECT

TCP Stack Optimisation

Increase the backlog for half‑open connections and reduce retry attempts:

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
# sysctl -w net.ipv4.tcp_synack_retries=1

Enable SYN cookies to avoid keeping half‑open state: # sysctl -w net.ipv4.tcp_syncookies=1 Persist these settings by adding them to /etc/sysctl.conf and reloading:

# cat /etc/sysctl.conf
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_synack_retries=1
net.ipv4.tcp_max_syn_backlog=1024
# sysctl -p

Conclusion

DDoS attacks overwhelm services with massive, often spoofed, requests, making full prevention impossible. However, by detecting SYN‑Flood patterns, filtering malicious packets with iptables, and tuning kernel TCP parameters, you can significantly reduce the impact on legitimate users.