[3348] in bugtraq
Re: SYN Flooding [info]
daemon@ATHENA.MIT.EDU (Perry E. Metzger)
Fri Sep 13 19:05:00 1996
Date: Fri, 13 Sep 1996 16:11:48 -0400
Reply-To: perry@piermont.com
From: "Perry E. Metzger" <perry@piermont.com>
X-To: Christopher Klaus <cklaus@iss.net>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In-Reply-To: Your message of "Fri, 13 Sep 1996 10:58:24 EDT."
<199609131458.KAA06507@phoenix.iss.net>
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
