How i was saying in the last post i had some time to play along with Tarpit compiled in a 2.6 Kernel and also added Grsec to it.
The tests were kind of unconclusive but there are a few things to say about this.
First all the IPs dropped are not really dropped (main idea of Tarpit) but more to it the traffic is brought to a point where is almost blocked from/to that IP depending on the rules you put in place.
Running a tcpdump on a blocked IP you can still see traffic running in and out as the following shows:
18:53:18.767183 IP (tos 0x0, ttl 64, id 32845, offset 0, flags [DF], proto: TCP (6), length: 45) 192.168.1.4.33486 > 192.168.1.5.80: P, cksum 0x06ba (correct), 3164407303:3164407308(5) ack 3694666370 win 5840
18:53:18.768699 IP (tos 0x0, ttl 64, id 63393, offset 0, flags [DF], proto: TCP (6), length: 45) 192.168.1.4.33485 > 192.168.1.5.80: P, cksum 0xf39f (correct), 3166138789:3166138794(5) ack 3684616830 win 5840
18:53:18.775141 IP (tos 0x0, ttl 64, id 50404, offset 0, flags [DF], proto: TCP (6), length: 45) 192.168.1.4.33487 > 192.168.1.5.80: P, cksum 0x60d8 (correct), 3173597853:3173597858(5) ack 3683683304 win 5840
18:53:18.791165 IP (tos 0x0, ttl 64, id 19041, offset 0, flags [DF], proto: TCP (6), length: 45) 192.168.1.4.33488 > 192.168.1.5.80: P, cksum 0x2b94 (correct), 3162688544:3162688549(5) ack 3694147503 win 5840
18:53:18.795152 IP (tos 0x0, ttl 64, id 63128, offset 0, flags [DF], proto: TCP (6), length: 45) 192.168.1.4.33489 > 192.168.1.5.80: P, cksum 0x3b18 (correct), 3172233429:3172233434(5) ack 3696984760 win 5840
18:53:18.807836 IP (tos 0x0, ttl 64, id 11527, offset 0, flags [DF], proto: TCP (6), length: 45) 192.168.1.4.33491 > 192.168.1.5.80: P, cksum 0x7bf1 (correct), 3174607692:3174607697(5) ack 3688695744 win 5840
18:53:18.809304 IP (tos 0x0, ttl 64, id 11278, offset 0, flags [DF], proto: TCP (6), length: 45) 192.168.1.4.33490 > 192.168.1.5.80: P, cksum 0x70d5 (correct), 3168578115:3168578120(5) ack 3682669726 win 5840
In the tcpdump above 192.168.1.5 is the server which is attacked and 192.168.1.4 is one of the stations attacking the server on port 80.
All in one until this point everything is good. Why you ask?
Well firstly because the traffic form the attacker is actually tarpited and this does not count in the attack anymore and secondly because the requests are still received by the server but not resolved which causes the IP in question to not be able to re-buffer .
Now the second part regarding Tarpit was related to a so called bug and i am referring here to the attacker’s machine started to get overloaded and resources usage starting to spike.
From my tests this happens in a higher proportion if the attacker uses a Windows machine to run the attacks and indeed a spike in resources usage is being observed. On the other side if the attacker is based on a Unix like machine the spike is minimal.
Now all the tests until this point have been done from two OS’s which were considered the attackers one was a Windows XP machine running in VMware and the other a Ubuntu 8.04 .
Considering that one of the machines was based on VMware i have to consider the results like uncoclusive.
I still have to redo a few things and maybe run a few more tests on a different infrastructure but this is a bit harder to achieve because of a few implications.
Another way would be to actually jump and test this on a server that it is under attack. Until now i didn’t had much luck(which is not a bad thing) regarding the latest.
Ok, done talking at this point.
For anyone who wants to try this out like a test or on an attacked server please fell free and let me know how it goes.
For this reason i have uploaded the Tarpit patched Kernel and the patched IPtables here so that you can grab them and use if needed:
Kernel+Tarpit&GRsec patch can be downloaded Here
tar -zxvf linux-188.8.131.52-GT.tar.gz
ln -s linux-184.108.40.206 linux
make modules && make modules_install
The kernel was compiled in a way so that it would install on almost all 32bit servers.
If you want to make sure that your server will boot up even if the kernel crashes try and do the following instead of editing grub.conf (last 2 commands):
savedefault --default=0 --once
Either way you go a server reboot will be needed.
If the server is running an iptables version prior to 1.3.8 those should still have Tarpit support and no patch is needed but if iptables does not see “tarpit” as a matching string you may want to upgrade iptables.
For this purpose you can download the already patched IPtables 4.0 and install it:
tar -zxvf iptables-1.4.0-tarpit.tar.gz
make && make install
If you want to check the IPs that have more then an X number of connections open(on port 80 in case of a DDoS attack) automatic and also Tarpit those IPs you can use this Script which is a small “check&block” script write in bash.
In the end for anyone who are not clear how to use Tarpit with IPtables it is as simple as doing a DROP but instead of dropping the IP you will tarpit it:
iptables -I INPUT -s xxx.xxx.xxx.x -j TARPIT – this will tarpit the IP xxx.xxx.xxx.x
This should be all that would need to be done.
Note: Packages are distributed free and in no way i can be held responsible for any harm caused to your server by any of this packages.