[4187] in linux-net channel archive
Re: SYN floods
daemon@ATHENA.MIT.EDU (Eric Schenk)
Sun Aug 25 13:46:34 1996
To: linux-net@vger.rutgers.edu
In-reply-to: Your message of "Sun, 25 Aug 1996 12:43:48 EDT."
<19960825164348.16874.qmail@ns.crynwr.com>
Date: Sun, 25 Aug 1996 13:36:25 -0400
From: "Eric Schenk" <schenk@cs.toronto.edu>
nelson@crynwr.com <nelson@crynwr.com> writes:
>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.
>
>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.
Just a small clarification. Actually, we don't answer all the SYN's.
Neither do any other TCP stacks that I know of. We only answer as
many fit in the backlog queue. Anything after that gets rejected
out of hand. This prevents DOS attacks that consume all the memory
on the victim's machine. On the other hand, you can still flood
the target with SYN's and use up all the slots in the backlog queue.
This results in a jammed TCP port that no one can get through to.
Even worse, the attacker can keep the port locked using only a
small amount of bandwidth. This makes attacks much less expensive
to launch in terms of the amount of resources needed, and the
attacks only impact heavily on the target machine, not on every
router between the attacker and the target. At least with some
other attack schemes the attacker must use up a large quanitity
of their own resources to launch the attack.
We could come up with heuristics that try and spot illegitimate
SYN's, but in the end the only thing that differentiates a clever
attacker from a legitimate attempt to connect is that the return
address is unreachable, and this is not sufficient to distinguish
an attack from a real connection, since real connection attempts
may have unreachable addresses due to transient networking failures.
Also, I'm not sure I'd want to see such heuristics as part of the kernel.
If we can figure out a way to deal with this in user space, then it
may be worth a try.
In the end, I don't see how Denial of Service attacks can be prevented.
All we can hope to do is to make the attacker tracable so they can be
held accountable. IPV6 should help with this somewhat.
-- eric
---------------------------------------------------------------------------
Eric Schenk www: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto
