Bugtraq mailing list archives
Re: SYN Flooding [info]
From: perry () piermont com (Perry E. Metzger)
Date: Fri, 13 Sep 1996 16:11:48 -0400
Christopher Klaus writes:
Here are two methods of helping eliminate the problem. Some of the exploit code I have seen does not pick a random source port.
The people conducting attacks figured that one out pretty fast.
Another way to fix this is to set the kernel maximum number of half open connections allowed (SO_MAXCONN) to a higher number than the default value.
This helps, but isn't sufficient. The real fix in the Berkeley kernel is to us a more efficient infant connection queue than a simple linked list, and for the code to adaptively lower the timeout down after the size of the open connection queue passes a high watermark. Some experiments tend to indicate that with a fews simple fixes like these, most machines can actually sustain more packets than an attacker is likely to be able to throw at them. At that point, the real problem becomes raw denial of service to your internet connection itself, just as though someone was flooding you with pings or what have you.
We have a tool that will look for SYN packets that do not get followed with ACK and clean the half open connections by sending a RST packet.
Again, a big part of the problem is that in BSD you have to traverse a simple linked list to find the connections to kill them. With a hash table, you could handle the RSTs fast -- but then, the kernel wouldn't fall over when bombarded in the first place. Perry
Current thread:
- SYN Flooding [info] Christopher Klaus (Sep 13)
- Re: SYN Flooding [info] Perry E. Metzger (Sep 13)
- Re: SYN Flooding [info] Alan Cox (Sep 16)
- Re: SYN Flooding [info] Perry E. Metzger (Sep 16)
- Re: SYN Flooding [info] Alan Cox (Sep 16)
- Re: SYN Flooding [info] Alan Cox (Sep 16)
- Re: SYN Flooding [info] Perry E. Metzger (Sep 13)
- Re: SYN Flooding [info] Alan Cox (Sep 16)