Fighting syn floods with iptables
The tracker I admin seems to be undergoing a bit of a syn flood, and the tcp_syncookies tools weren’t helping. My ip_conntrack table was filling at 65536 connections, and the tracker just wasn’t talking to anyone as a result. Lots of packets falling out, lots of full tables. Not sure if it’s intentional or if it’s just a bunch of clients behaving badly… big fan of Hanlon’s Razor there though…
Detection: looked in /proc/net/ip_conntrack. Noticed that the connections listed were mostly SYN_SENT from some src, and “UNREPLIED” status. Many source ip’s. Verified that the tracker was functional (by temporarily firewalling off all inbound syn traffic to it except my own ip addy). Saw lots of packets getting dropped.
Mitigation attempt 1: tuned /proc/sys/net/ip_conntrack_max and /proc/sys/net/ipv4/netfilter/{many settings} in /etc/sysctl.conf, turning up maxes and turning down timeouts. This should more aggressively expire lost tcp connections. Also added a rule: iptables -t raw -A OUTPUT -p tcp --sport $TRACKER_PORT -j NOTRACK in an attempt to further lower the conntrack burden. Result: I no longer kept getting as many conntrack “table full” errors, but the tracker was still not talking to anyone.
Mitigation attempt 2: added two more firewall rules:
iptables -I INPUT 1 -p tcp --dport $TRACKER_PORT --syn -m hashlimit --hashlimit 10/min --hashlimit-burst 15 --hashlimit-name torrenthash --hashlimit-htable-size 2048 --hashlimit-htable-max 65536 --hashlimit-mode srcip -j ACCEPT
followed by
iptables -I INPUT 2 -p tcp --dport $TRACKER_PORT --syn -j DROP.
Result: the tracker appears to be talking again … I can see the web interface on it, and get peers on torrents hosted there without the help of DHT. It’s good times.
I imagine this technique could be used for quite a bit more than just protecting a tracker, so I suppose it’d be great to have it written down somewhere 