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@e-gerbil.net] Sent: Thursday, May 02, 2002 9:23 AM To: LeBlanc, Jason Cc: 'Pete Kruckenberg'; nanog@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@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)