[47331] in North American Network Operators' Group
Re: Effective ways to deal with DDoS attacks?
daemon@ATHENA.MIT.EDU (Richard A Steenbergen)
Thu May 2 12:23:33 2002
Date: Thu, 2 May 2002 12:23:01 -0400
From: Richard A Steenbergen <ras@e-gerbil.net>
To: "LeBlanc, Jason" <Jml@ebay.com>
Cc: 'Pete Kruckenberg' <pete@kruckenberg.com>, nanog@merit.edu
Message-ID: <20020502162301.GK523@overlord.e-gerbil.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <30AEDFDE01F54A4582E1F69E78860D759F6FF4@sjc-exm-18.corp.ebay.com>
Errors-To: owner-nanog-outgoing@merit.edu
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)
