[4541] in North American Network Operators' Group
Re: New Denial of Service Attack on Panix
daemon@ATHENA.MIT.EDU (Forrest W. Christian)
Wed Sep 18 01:00:23 1996
Date: Tue, 17 Sep 1996 22:55:07 -0600 (MDT)
From: "Forrest W. Christian" <forrestc@iMach.com>
To: Curtis Villamizar <curtis@ans.net>
cc: "Erik E. Fair" <fair@clock.org>, nanog@merit.edu, iepg@iepg.org
In-Reply-To: <199609180052.UAA08216@brookfield.ans.net>
On Tue, 17 Sep 1996, Curtis Villamizar wrote:
> In message <v03007814ae643a8d0173@[198.68.110.3]>, "Erik E. Fair" writes:
> > Your suggestion has two flaws:
> >
> > 1. missed SYN ACKs due to asymmetric routing.
>
> On the order of 1,000 pps worth?
The other option here is to log SYNS and ACK's (both going in the same
direction) - They will definately BOTH been seen at the same interface -
regardless of routing topology, unless you are talking about some form of
load balancing where packets are spewed down somewhat random paths.
This doesn't account for "null0" routes and attempted connections to down
machines, but.... What we're watching for is 1000 pps of excessive SYNS
with no ACKS. Even if you set the trigger level at 500 SYN/NO ACK per
sec, you'd catch an interface where you've got an excessive level of
these going on.
The real drawback, which I meant to mention in my original post (but
didn't) and has been mentioned by a cisco person here, is that this
requires going a little deeper into the packets than normal - For those
routers which switching is implemented in silicon, this might be a
problem. It also increases CPU load.
I also want to make it clear that in my opinion, where possible, EVERYONE
should be doing filtering on their customer-facing interfaces. (yes, all
my PPP customers have a filter which permits stuff from THEIR IP and only
THEIR IP.) However, in a situation where you have downstreams which are
running dynamic (BGP4) routing, filtering may not be practical. This
would provide an additional tool to determine if these attacks are
occuring, and to track them to the source.
-forrestc@imach.com
