Re: Mitigating SYN flooding with Netfilter or net.ipv4.tcp_syncookies ?

From: Harald Skoglund (haraldms@hekta.stud.iet.hist.no)
Date: 02/01/02 

From: Harald Skoglund <haraldms@hekta.stud.iet.hist.no>
To: John Coke <jcoke@ibeam.com>
Date: Fri, 1 Feb 2002 06:49:10 +0100

On Wednesday 30. January 2002 06:47, John Coke wrote:
> I am deploying boxes into unfriendly networks and cannot count on firewall
> protection.

Always remember to check MAC-addresses in such networks.

The servers are linux 2.4 and I have wrapped them tightly in
> Netfilter (iptables). The only ***, if you will, is the protection
> against SYN flooding. I see 2 solutions and would like the forum's input.
> The first is using syncookies and the second is Netfilter's rate limiting.
> My impression is that syncookies require more overhead but would not drop
> legitimate traffic. OTOH, netfilter would have less overhead but may drop
> legitimate traffic when the threshold is triggered.

I'm not completely sure but i think syncookies is meant to block synflooding
from a large number of (spoofed?) ip's, and in that case is is ok, to not
allow legitimate traffic cause that is a full-scale attack. It will
however not affect fx. a port scan, (please correct me on this :)). For
example: if someone port scanned your server it might end up in reaching the
rate-limit and noone would be able to connect.

The soloution to is to use some of the 'experimental' patches to iptables,

http://www.netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO.html

The psd-module (port scan detector built of solar designers scanlogd). you
can do iptables -p tcp -m psd -j DROP, or how you feel like it. The results
that the person scanning will get is completely unreliable and wont really
return which ports are open, or not.
If you do rate limiting after this rule you will have much fewer syns to
worry about, I set up my firewall with psd as the first rule then a log rule
for SYNs as #2 . From a full nmap connect() scan, about 40 got past the psd
module, (the scan took 85 seconds to complete).

With those out of the way rate-limiting SYNs is much healthier. You can also
you the pool-patch for iptables with it userland program and add portscanning
ip's to a pool on the fly which then is checked higher up the chain and all
connections from that ip can be dropped, but i'll stop now before i drift to
far off topic ;) 

-- 

Harald Skoglund

Quantcast