Effective ways to deal with DDoS attacks?

LeBlanc, Jason Jml at ebay.com
Thu May 2 16:41:33 UTC 2002


I guess the 'filter box' can be a number of different things, based on your
needs and preferences.  At first glance CloudShield seems pretty beefy, am
reading more as we speak.

Yes, Juniper can be convinced to add things, we've asked for a few.  ;)
Part of the problem with asking for new things on an ASIC, takes time.
Anything they add in their code to help filter will likely not be done in
hardware, meaning potential impact.  I know some people need to filter on
their routers for various reasons, but my thoughts are to minimize this.  A
router that is working hard at just forwarding packets doesn't need to extra
overhead of looking deep into packet headers to figure out what to do with
packets.  Juniper is better at this, as are some Cisco products, but the GSR
is a crappy packet filter if you put enough traffic through it.  Yes certain
linecards are better than others, but the newer they are the more buggy they
are, and we're talking HW here, so bug fixes will be awhile.

The caveat to all this is obvious, these are big links and big routers, only
applies to high traffic networks..as that is the only place the expense is
justified.  uRPF, however, works on (almost) any CEF capable Cisco router.

Some may have already seen this, worth a look if not.  

http://www.cisco.com/warp/public/707/newsflash.html

There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco).  I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type.  Impact should be minimal, as it simply
does a lookup in the CEF table, if the route isn't there it discards.  Keep
in mind this is NOT a filter, so the impact is much less, it is simply a CEF
lookup, much more efficient than a filter.  This will get rid of a HUGE
percentage of spoofed packets that hit your network, and would also work
pretty well if you are the source of an attack.  There is some debate as to
whether you must not have ANY RFC1918 space for this to work.  We're trying
to find this out (not a priority), if I get info I'll post.



-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net]
Sent: Thursday, May 02, 2002 9:23 AM
To: LeBlanc, Jason
Cc: 'Pete Kruckenberg'; nanog at merit.edu
Subject: Re: Effective ways to deal with DDoS attacks?


On Thu, May 02, 2002 at 08:54:05AM -0700, LeBlanc, Jason wrote:
> 
> uRPF and Radware DoShield, one DoShield per link btw edge router and core
> router.  Use IDS (yes there is a way to capture all your traffic and
> anaylyze it, regardless of bandwidth, no it isn't one box) to identify a
> signature, build a filter, config filter on DoShield, up to ~200Mb/s per
> DoShield of filtering with zero impact to legit traffic.  Scale
horizontally
> (add more links each with a DoShield on it) based on your ingress traffic.
> 
> I've seen many suggestions on this list, this is the only thing that works
> for huge (100Mb/s+) attacks.  eBay is likely the biggest target on the
net,
> this works for us 90% of the time.  Is the HW expensive?  Yes. (~$35k per
> DoShield I think)  It works, it scales.  

You might want to take a look at CloudShield (www.cloudshield.com), they 
have what can only be described as a pretty impressive looking box for 
this kind of stuff.

> There is no way a Cisco router can handle filtering attacks past a
> certain point, nor is it capable of even filtering on some patterns in
> attack packets.  Juniper is better, but still lacks some filtering
> capabilities. Your router is a router, not a packet filter, give up
> trying to make it do this until someone builds this into an ASIC on the
> router.

Thats what the IP2 does, match bytes in the headers and come back with a 
thumbs down or a thumbs up and a destination interface. It's really not 
that much harder to match the bytes for a dest port against a compiled 
ruleset and decide yes or no then it is to match the dest address against 
a forwarding table and decide which nexthop.

They CAN filter on anything in the headers, it's just a matter of
convincing them that the specific filter you want is something they should
add to their software language and microcode. I'm sure as a core router
vendor they must hear every feature request imaginable and not know which
ones to follow up on. If anyone from Juniper is listening, I can tell you
4 things to add which will stop all existing packet kiddie tools in their
tracks. But then again, I'd rather just have a language for bitmatching at
any offset. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)



More information about the NANOG mailing list