Understanding SYN Floods
A SYN flood exploits the TCP three-way handshake by sending a massive volume of SYN packets with spoofed or randomized source IPs. Each SYN packet causes the target server to allocate resources for a half-open connection and send a SYN-ACK response. Because the source IP is spoofed, the SYN-ACK goes to a host that never initiated the connection, so the final ACK never arrives. The server's connection table fills up, and legitimate users cannot establish new connections.
SYN floods remain one of the most common DDoS attack types because they are simple to execute, effective against unprotected targets, and difficult to filter without stateful inspection or rate limiting. A modern server can handle tens of thousands of legitimate connections, but a SYN flood can generate millions of half-open connections per second, overwhelming even well-provisioned systems.
Emergency iptables Rules
The following iptables rules are designed for emergency use during an active SYN flood. They are not a permanent mitigation strategy. They are a stopgap to keep your server functional while you coordinate with your upstream provider for proper filtering.
Rule 1: Enable SYN Cookies
SYN cookies are a kernel-level defense that avoids allocating connection table entries for SYN requests. Instead, the server encodes the connection state in the SYN-ACK sequence number. Only when the client completes the handshake with a valid ACK is a full connection created.
# Enable SYN cookies (sysctl, not iptables, but critical) sysctl -w net.ipv4.tcp_syncookies=1 sysctl -w net.ipv4.tcp_max_syn_backlog=65536 sysctl -w net.ipv4.tcp_synack_retries=2
The tcp_syncookies parameter activates SYN cookies when the SYN backlog queue is full. Setting tcp_max_syn_backlog to 65536 increases the backlog to buy more time before cookies activate. Reducing tcp_synack_retries from the default 5 to 2 means the server gives up on half-open connections faster, freeing resources sooner.
Rule 2: Rate-Limit Incoming SYN Packets
# Limit new TCP connections to 100/second per source IP iptables -A INPUT -p tcp --syn -m connlimit \ --connlimit-above 20 --connlimit-mask 32 -j DROP # Global SYN rate limit: 500/second with burst of 200 iptables -A INPUT -p tcp --syn -m limit \ --limit 500/s --limit-burst 200 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP
The first rule limits any single source IP to 20 concurrent half-open connections. This is effective against SYN floods that reuse source IPs. The second and third rules implement a global rate limit: up to 500 new SYN packets per second are accepted, with a burst allowance of 200. Anything above that is dropped.
Adjust the rate limits based on your normal SYN rate. If your server normally handles 1,000 new connections per second, set the limit to 1,200/s to allow headroom. Flowtriq's dashboard shows your current SYN rate to help you pick the right number.
Rule 3: Drop Invalid Packets
# Drop packets that don't match any known connection iptables -A INPUT -m conntrack --ctstate INVALID -j DROP # Drop malformed TCP flag combinations iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP iptables -A INPUT -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
These rules catch malformed packets that are common in SYN floods generated by low-quality attack tools. Legitimate TCP traffic will never have all flags set simultaneously, or FIN and SYN set together, or SYN and RST set together. Dropping these packets reduces the load on the kernel's TCP stack without affecting real users.
Rule 4: Protect Specific Services
# Allow established connections first (fast path) iptables -I INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Rate-limit SYN to web ports specifically iptables -A INPUT -p tcp --dport 80 --syn -m limit \ --limit 200/s --limit-burst 100 -j ACCEPT iptables -A INPUT -p tcp --dport 443 --syn -m limit \ --limit 200/s --limit-burst 100 -j ACCEPT iptables -A INPUT -p tcp --dport 80 --syn -j DROP iptables -A INPUT -p tcp --dport 443 --syn -j DROP
The first rule is critical: it moves established connection matching to the top of the chain. Packets belonging to existing connections skip all the rate-limiting rules, which means your current users are not affected by the SYN rate limits. Only new connection attempts are throttled.
Kernel Tuning for SYN Floods
Beyond iptables rules, several kernel parameters can improve resilience during a SYN flood:
# Reduce TIME_WAIT socket duration sysctl -w net.ipv4.tcp_fin_timeout=15 # Increase the maximum number of tracked connections sysctl -w net.netfilter.nf_conntrack_max=1048576 # Increase the hash table size for connection tracking sysctl -w net.netfilter.nf_conntrack_buckets=262144 # Reduce the timeout for SYN_RECV state sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_recv=30
The nf_conntrack_max setting is particularly important when using iptables with conntrack. Each tracked connection consumes memory, and the default limit (typically 65536) can be exhausted during a flood, causing the kernel to drop legitimate packets. Setting it to 1 million provides ample room for both attack and legitimate traffic.
Memory impact: Each conntrack entry uses approximately 300 bytes of kernel memory. Setting nf_conntrack_max to 1,048,576 reserves about 300 MB of memory for connection tracking. Ensure your server has sufficient RAM before increasing this value.
When to Remove Emergency Rules
These rules are designed for emergency use. Once your upstream provider has activated mitigation (null-route, scrubbing, or BGP blackhole), you should remove the emergency rules to restore normal connection handling. Leaving aggressive rate limits in place can cause problems during legitimate traffic spikes.
# Remove all custom rules (restore defaults) iptables -F INPUT # Or save and restore from a known-good configuration iptables-restore < /etc/iptables/rules.v4.backup
Before applying emergency rules, always save your current iptables state so you can restore it cleanly after the incident.
How Flowtriq Helps
Flowtriq detects SYN floods within 1 second of onset by monitoring the SYN-to-established connection ratio. When the ratio deviates significantly from baseline (indicating that SYN packets are arriving without completing handshakes), a SYN flood alert fires with the attack's characteristics: source IP distribution, target ports, and packet rate.
The alert includes the specific iptables rules tailored to the attack pattern Flowtriq observed. Instead of applying generic rate limits, you get rules that match the actual attack signature, like rate-limiting traffic from the specific ASNs or port ranges the flood is using.
Flowtriq plans start at $9.99/mo per node. Start your free trial and get SYN flood detection that gives you the 20 minutes of lead time you need to implement mitigation.
Back to Blog