Block SYN Flood Attacks with iptables (2026)

An SYN flood attack overwhelms a server by sending a barrage of TCP SYN (synchronization) requests, exhausting its resources for handling legitimate connections.

Let’s see iptables in action. Imagine a web server on 192.168.1.100 listening on port 80. An attacker, say from 203.0.113.50, starts hammering it with SYN packets.

# On the server (192.168.1.100), observe incoming SYN packets
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0' -n

# On the attacker machine, simulate a flood (DON'T RUN THIS ON A REAL NETWORK!)
# hping3 -S --flood -p 80 192.168.1.100

You’d see a massive amount of SYN packets from the attacker’s IP, but very few corresponding ACK packets, indicating the server is trying to complete handshakes that never finish.

iptables can act as a firewall to mitigate this. The core idea is to limit the rate at which new SYN connections are accepted.

Common Causes and Fixes for SYN Floods

The most direct cause is simply an overwhelming volume of SYN packets. Your server’s TCP/IP stack has a backlog queue for half-open connections. When this queue fills up, legitimate SYN packets are dropped.

Rate Limiting New SYN Connections:
- Diagnosis: Observe high CPU usage and a full syn_received state in netstat -anp | grep SYN_RECV.
- Fix: Use the iptables limit module.
```
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
```
- Why it works: The first rule allows a maximum of 1 new SYN packet per second (--limit 1/s) after an initial burst of 3 (--limit-burst 3). The second rule drops any subsequent SYN packets that exceed this rate, preventing the backlog queue from filling.
SYN Cookies (Kernel Level):
- Diagnosis: Even with rate limiting, a sustained, high-volume attack can still be problematic.
- Fix: Enable SYN cookies in the kernel.
```
sysctl -w net.ipv4.tcp_syncookies=1
```
  Add net.ipv4.tcp_syncookies = 1 to /etc/sysctl.conf for persistence.
- Why it works: When the SYN backlog queue is full, the kernel doesn’t allocate resources for the connection. Instead, it sends back a specially crafted SYN-ACK packet (a "cookie") containing encoded information about the connection. Only when a valid ACK packet (with the correct cookie) arrives does the kernel allocate resources and establish the connection. This effectively shifts the burden from the server’s memory to the attacker’s network bandwidth.
Dropping SYN packets from specific suspicious IPs (if identifiable):
- Diagnosis: If you can identify a single source IP or a small range of IPs responsible for the majority of the flood.
- Fix:
```
iptables -A INPUT -s 203.0.113.50 -p tcp --syn -j DROP
```
- Why it works: This is a blunt instrument. It directly blocks all SYN packets from a known malicious source, freeing up resources. This is most effective against unsophisticated attacks that don’t use spoofed IPs.
Rejecting SYN packets to closed ports:
- Diagnosis: Attacker might be targeting ports not in use, trying to elicit RST packets which consume some resources.
- Fix:
```
iptables -A INPUT -p tcp --syn -j REJECT --reject-with tcp-reset
```
- Why it works: For any incoming SYN packet, iptables will send back a TCP RST (reset) packet. This immediately tells the sender the connection is refused. While this consumes a tiny amount of CPU and bandwidth for the RST, it’s often less resource-intensive than letting the SYN sit in the backlog queue for a timeout. This is more of a "clean-up" rule.
Increasing the TCP SYN backlog queue size:
- Diagnosis: You’re seeing SYN_RECV states and legitimate users are complaining about connection failures, but you want to allow more concurrent half-open connections before SYN cookies kick in.
- Fix:
```
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
```
  Add net.ipv4.tcp_max_syn_backlog = 4096 to /etc/sysctl.conf for persistence.
- Why it works: This increases the number of half-open connections the kernel can hold in its queue before it starts dropping new SYN requests or resorting to SYN cookies. The default is often 1024. Increasing this value can absorb smaller, short-lived bursts of SYN traffic.
Setting a stricter TCP connection timeout:
- Diagnosis: The system is slow to reclaim resources from timed-out, half-open connections.
- Fix:
```
sysctl -w net.ipv4.tcp_synack_retries=3
```
  Add net.ipv4.tcp_synack_retries = 3 to /etc/sysctl.conf for persistence.
- Why it works: This reduces the number of times the server retransmits a SYN-ACK before giving up. A lower number means resources are freed up faster from connections that will never complete. The default is typically 5.

After implementing rate limiting and enabling SYN cookies, you’ll likely encounter issues with legitimate traffic if your rate limiting is too aggressive, or you’ll need to tune the limit-burst parameter further.