[4226] in linux-net channel archive
Re: SYN floods
daemon@ATHENA.MIT.EDU (Rob Janssen reading Linux mailingl)
Thu Aug 29 03:08:22 1996
From: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
To: ecki@inka.de (Bernd Eckenfels)
Date: Wed, 28 Aug 1996 13:35:31 +0200 (MET DST)
Cc: submit-linux-dev-net@ratatosk.yggdrasil.com
In-Reply-To: <500abk$gj0@nz12.rz.uni-karlsruhe.de> from "Bernd Eckenfels" at Aug 28, 96 02:19:32 am
Reply-To: linux-vger@wab-tis.rabobank.nl
According to Bernd Eckenfels:
> : Okay. Who says we "have" to answer all SYN's? The RFC's? Very well, I'll
> : accept that for a truly compliant TCP stack, we have to answer them all. My
> : idea is not to turn this off and detect SYN floods in the kernel; it's just
> : to add the necessary hooks to implement a policy change on the fly (perhaps
> : with a userland daemon).
>
> Well, the Problem with this is, that the userlanfd daemon can do a lot of
> things, but it has no chance to keep your backlog from filling. Since you
> always want to accept connections from certain hosts and the attacker can
> always pick those hosts as the source of their spoofed syns.
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.
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.
Rob
--
+------------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | BBS: +31-302870036 (2300-0730 local) |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+
