Security Incidents mailing list archives

Re: Stick DOS


From: Jose Nazario <jose () BIOCSERVER BIOC CWRU EDU>
Date: Thu, 8 Mar 2001 12:22:27 -0500

On Thu, 8 Mar 2001, Curley Mr Eric P wrote:

There has been word of a possible DOS that will be released on the
15th of this month that will have the capability of taking down
stateless firewalls. The DOS is called "Stick".  It is supposed to
send numerous malformed packets from spoofed sources.  Does anybody
out on the list have any information on how to prevent this from
happening or any information whatsoever on the DOS.  Any help would be
greatly appreciated.

hi curley

if it's anything like rape.c, it's main point of abuse is resource
exhaustion of the targets behind the firewall rape.c worked by flooding
the target with bogus ACK packets. host recives them, processes them (ie
checksums, strip framing, pass up, repeat until you get to passing it off
to an applications and ... oh wait, that was wasted effort, better get
cracking on the next one) ad naseum as resources are exhausted.

state tables rule. i love them. when done right they stop all manner of
things, not just SYN floods. i am of the belief that given the fact that
the code is out there in open source (cf OpenBSD's kernel, for example),
every kernel should include it.

on the firewalling end, good firewalls keep the state of connections in a
table and process according to those tables. this breaks a whole manner of
things, including 'stealth' scans and DoS's like the one you're
anticipating. IPF (*BSD) and Netfilter/IPtables (Linux 2.4) come to mind,
as does IPchains + SPF (Linux 2.2). several commercial firewalls also
manage using state tables, but none of their names come to mind right now,
sorry.

bear in mind it does need to be set up right. it's not a magic bullet.

____________________________
jose nazario                                                 jose () cwru edu
                     PGP: 89 B0 81 DA 5B FD 7E 00  99 C3 B2 CD 48 A0 07 80
                                       PGP key ID 0xFD37F4E5 (pgp.mit.edu)


Current thread: