Re: Effective ways to deal with DDoS attacks?

[Richard A Steenbergen <ras () e-gerbil net>]

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 () 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)