[26842] in North American Network Operators' Group
Re: New form of packet attack named Stream
daemon@ATHENA.MIT.EDU (Alex P. Rudnev)
Thu Jan 20 22:01:14 2000
Date: Fri, 21 Jan 2000 05:56:46 +0300 (MSK)
From: "Alex P. Rudnev" <alex@virgin.relcom.eu.net>
To: Vadim Antonov <avg@kotovnik.com>
Cc: jamie@exodus.net, nanog@merit.edu
In-Reply-To: <200001202213.OAA29641@kitty.kotovnik.com>
Message-ID: <Pine.SUN.4.10.10001210553140.10013-100000@virgin.relcom.eu.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
> > e-mail me asking for the code.
>
> Actually, you provided enough details, so any unix guy who knows
> his sockets can write the program in fifteen minutes.
>
> This type of attack was known for a long time (and there are even
> nastier variations using TCP header bits and fragments), and, unfortunately,
> there's no good defense against it.
There is one base rule - you (OS) MUST limit resources (CPU, MEMORY, buffers,
sockets, etc) catched by any SINGLE origin (IP address, program, service).
Such approach broke just any except a few DoS attacks - for example, if you try
to exhaust memory attaking single service, then (1) service can't catch all
memory because it's the SINGLE origin, and (2) one SRC address can't catch many
resources because it's SINGLE origin, and (3) you can't generate too many
different addresses in case of reverse-filtering.
> > The core routers areindeed vulnerable; is there any router
which > has an access list for restricting packet flow to the routing processor?
> (My knowledge of latest-and-greatest features from OFRV is somewhat outdated).
>
> A toyed with the idea of reverse-path verification coupled with
> some kind of super-squelch message; but so far all such schemes have
> holes in them. DoS attacks are a real scourge.
>
> --vadim
>
>
Aleksei Roudnev,
(+1 415) 585-3489 /San Francisco CA/
