[4192] in linux-net channel archive
Re: SYN floods
daemon@ATHENA.MIT.EDU (Racer X)
Tue Aug 27 01:45:40 1996
Date: Tue, 27 Aug 1996 00:07:53 -0400 (EDT)
From: Racer X <shagboy@wspice.com>
Reply-To: shagboy@bluesky.net
To: nelson@crynwr.com
cc: linux-net@vger.rutgers.edu
In-Reply-To: <19960825164348.16874.qmail@ns.crynwr.com>
On 25 Aug 1996 nelson@crynwr.com wrote:
> Sigh. We're talking about two different things here -- one is how to
> discover the source of excessive SYN attacks (which cannot be done
> without the cooperation of ISPs who don't already filter, so it's not
> likely to happen), and the other is how to deal with all these SYNs.
Let's forget about the first problem. There are too many routers, TCP
stacks, etc., that would have to be modified to allow one to discover the
actual source of the SYN packet. That's not going to happen anytime
before IPv6 comes around, which will hopefully solve these problems
anyway.
So, dealing with the SYN packets - Olaf and I suggested adding some code
to the kernel to provide hooks for detection of this kind of attack. The
actual detection and policy setting would not be done in the kernel, of
course.
> I guess Linux has a problem with sinners -- a religious OS! :)
I'm not sure if this is a barb aimed at Linux users, but I don't think
it's appropriate here. We're trying to offer solutions to this problem,
solutions that can be implemented NOW, without having to cajole national
ISP's and router manufacturers to go along. What have you offered?
> The problem is twofold: it uses up network bandwidth, just like an
> ICMP (ping) attack, but it also uses up kernel memory. You can turn
> off ICMP temporarily, which at least gives you some outgoing
> bandwidth, but you can't stop answering all SYNs, otherwise you deny
> ALL service.
Network bandwidth really hasn't been an issue here. Most of the time,
it's some kid spoofing from a 28.8 (at best) home Linux box. The kernel
problem is much, much more important.
> You HAVE TO answer ALL SYNs, so you HAVE TO fill up your outgoing
> bandwidth. The most serious problem is that you also have to keep the
> state implied by answering the SYN.
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).
What if I don't want to accept SYN's from a certain host? The firewalling
code pretty much lets me do this, right? So is that non-compliant? If I
want to be RFC-compliant, I can change my system to "RFC" mode. If I
want to watch out for SYN flood attacks, I'll take it out of "RFC" mode.
shag
Judd Bourgeois | When we are planning for posterity,
shagboy@bluesky.net | we ought to remember that virtue is
Finger for PGP key | not hereditary. Thomas Paine
