[4235] in linux-net channel archive
Re: SYN floods
daemon@ATHENA.MIT.EDU (Eric Schenk)
Thu Aug 29 18:48:34 1996
To: linux-vger@wab-tis.rabobank.nl
cc: linux-net@vger.rutgers.edu
In-reply-to: Your message of "Wed, 28 Aug 1996 07:35:31 EDT."
<m0uviuC-0003lAC@sys3.pe1chl.ampr.org>
Date: Thu, 29 Aug 1996 14:47:47 -0400
From: "Eric Schenk" <schenk@cs.toronto.edu>
Rob Janssen reading Linux mailinglist <linux@pe1chl.ampr.org> writes:
>Using an existing host as the source does not work well, because the
>SYN ACK received by that host will cause it to send an RST reply (because
>it does not know about the connection) and the RST will remove the session
>in SYN_RCVD state. This basically reduces it to an attack like a PING
>flood, not one that fills the connection table.
This assumes that every address that has a name associated with
it has a running machine on the far end. This is not the case.
An attacker need only discover the identity of a machine that is down,
in order to make a SYN flood attack on your machine. Given the number
of names that are associated with machines that connect over dial
in lines, I expect this is not very difficult. A smart SYN flood attack
should appear exactly like a legitimate heavy demand on your machine,
except that none of the connections ever succeed.
Also, SYN floods are quite devistating on the current Linux
boxes (1.2.13 or 2.0.x). A SYN flood locks a port up for 23 minutes,
using only 10 or so packets. This is because we currently treat
the incoming connection timeout exactly the same way we treat
the timeout on resends for established connections. (In fact, we have
a buglett in our timeouts for established connections,
if we where doing our connection timeouts correctly,
this would lock up the port for 90 minutes.)
I've been checking through the RFC's and it appears that we can use a
seperate set of timeouts for the initial establishment of the connection,
as opposed to timeouts for estalbished connections. Currently we only use
a seperate timeout for connections initiated by the local box. Even then,
this timeout is perhaps a bit long, somewhere around the 13 minute mark
in 2.0.x. BSD uses a 75 second timeout for this, but this is perhaps
a bit short, especially for on-demand links over a busy phone line.
>Of course the difficult problem is 'how to determine that the SYN was
>from an existing host'...
>What could be tried is to delete the 'oldest' entry in SYN_RCVD state
>whenever a SYN is received and too many connections are in SYN_RCVD state,
>but probably that still will deny some service to legitimate users that
>happen to be on a slow link.
This is an interesting idea. I'm a bit concerned because it could make it
impossible for a user on a slow link to connect at all, but it might be
worth trying out, perhaps as an option that could be
turned on whenever an administrator suspects the machine
is under a SYN flood attack. In this case it might at least restore
partial service. Of course a "smart" SYN flooder who knows we are doing
this could just pace incoming SYN's at a rate sufficient to guarantee
that the any attempted connects get shoved out of the queue before
they get serviced. This might require as much traffic as PING flooder though,
so even though we haven't prevented the Denial of Service attack completely,
we make it expensive to carry out.
-- eric
