SYN flood ban script

[bad_brain]

as promised, here is the little bash script I wrote during the attack against suck-o:

Code: Select all

#!/bin/bash
netstat -tn |grep SYN | grep 62.75.148.170:80 > syn.txt
sed 's/tcp        0      0 62.75.148.170:80        /route add -host /g' syn.txt > output1
sed 's/:.*/ reject/g' output1 > output2
chmod 777 output2
./output2
rm syn.txt
rm output*

ok, so what is it doing?
in line 1 the output of netstat -tn is filtered so only connections in SYN_RECV state are captured, that output is filtered again so only connections that are in SYN_RECV state AND to port 80 of the server are written to a file (syn.txt).
in line 2 the text strings at the beginning of each line of the netstat output are replaced with "route add -host "
in line 3 the strings at the end of each line (beginning at the : after the IP) of the netstat output are replaced with " reject"
the rest of the code makes the output file executable, runs it, and cleans up the directory when done.

step by step:

- output of netstat -tn |grep SYN | grep 62.75.148.170:80

Code: Select all

tcp   0   62.75.148.170:80  192.0.0.1:2329    SYN_RECV
tcp   0   62.75.148.170:80  192.0.0.2:2329    SYN_RECV
tcp   0   62.75.148.170:80  192.0.0.3:2329    SYN_RECV

replacement #1:

Code: Select all

route add -host 192.0.0.1:2329    SYN_RECV
route add -host 192.0.0.2:2329    SYN_RECV
route add -host 192.0.0.3:2329    SYN_RECV

replacement #2:

Code: Select all

route add -host 192.0.0.1 reject
route add -host 192.0.0.2 reject
route add -host 192.0.0.3 reject

WARNING
this script is only for emergency use!
there is a chance of collateral damage (banning innocent users), but when a SYN flood is running the danger is not too big because regular users don't really have a chance to connect anyway, also regular connections in a SYN_RECV state are pretty rare. sure, every connection starts with it, but the state usually only lasts a split second, so even on well frequented servers catching a connection in that state via netstat is like winning in a lottery because the chances are very low.
different in a SYN flood attack: the attacking bots send a SYN request, but instead of establishing a connection after the server sent a SYN_ACK back they drop the connection so the server leaves the connection open waiting for reply until it times out....and this occupies the connections until the max. clients setting is reached and no regular users can connect anymore.

don't copy&paste the script, it will not work because some whitespaces are missing, get it here.

P.S. of course you will have to edit the IPs in line 1 and 2, if another service than http is attacked you will also have to edit the port numbers.

[DNR]

And you explained that nicely! Glad you are in charge of security around here...



DNR

[MariaLara]

And you explained that nicely! Glad you are in charge of security around here...

Me too.
He is great. I would have been lost so many times with out his guidance.

Might I suggest also grep -i -E "SYN_RECV|FIN_WAIT2"

[Polynomial]

If you're using iptables, you can use this to automate the procedure:

Code: Select all

iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 25 -j DROP

More than 25 SYN packets from one IP in any 60 second period to port 80 automatically puts that IP into a blackhole list. I have something similar to that on our firewall at work. For safety you should always set up a cron to filter your iptables rules for whitelist IPs and remove any bans that match, otherwise an attacker could spoof their source address as that of one of your known-safe machines and have it put into your ban table. I also have a second cron that emails me every time a new IP address is placed into the bans list.

[J9NF]

Polynomial -- I like. Does it work well against UDP-based attacks?

[bad_brain]

never...really, never use iptables against DDoS attacks. the only exception might be really small botnets up to 100 or so.
why? because every new request will have to process the whole chain, which causes a horrible overhead and i/o-waits....which will have the same effect of a DDoS, but will not be caught by such thing as the maxClients setting for Apache, so it's even worse than the actual DDoS because it'll affect the whole system.

years ago I made exactly that experience, so when you're not having the luxury of a hardware firewall in front of your server blocking through the kernel routing table is the much better way....