RE: Effective ways to deal with DDoS attacks?
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. 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. Email me off list for more info. -----Original Message----- From: Pete Kruckenberg [mailto:pete@kruckenberg.com] Sent: Wednesday, May 01, 2002 4:18 PM To: nanog@merit.edu Subject: Effective ways to deal with DDoS attacks? There's been plenty of discussion about DDoS attacks, and my IDS system is darn good at identifying them. But what are effective methods for large service-provider networks (ie ones where a firewall at the front would not be possible) to deal with DDoS attacks? Current method of updating ACLs with the source and/or destination are slow and error-prone and hard to maintain (especially when the target of the attack is a site that users would like to access). A rather extensive survey of DDoS papers has not resulted in much on this topic. What processes and/or tools are large networks using to identify and limit the impact of DDoS attacks? Thanks. Pete.
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)
At 12:23 PM 02-05-02 -0400, Richard A Steenbergen wrote:
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.
Looking into the IP header is not enough. In order to filter DDOS packets one has to look into the payload as well. I don't think routers are suitable for that level of filtering (think advanced NBAR). Hank Consultant Riverhead Networks (formerly Wanwall Networks) www.riverhead.com
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)
On Thu, May 02, 2002 at 08:07:31PM +0200, Hank Nussbacher wrote:
At 12:23 PM 02-05-02 -0400, Richard A Steenbergen wrote:
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.
Looking into the IP header is not enough. In order to filter DDOS packets one has to look into the payload as well. I don't think routers are suitable for that level of filtering (think advanced NBAR).
I disagree. There are a world of things you can do when you look at the entire payload, from IDS to playing Big Brother. But stopping DDoS does not require it, in almost every case layer 3+4 headers is sufficient. -- 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)
RAS> Date: Thu, 2 May 2002 12:23:01 -0400 RAS> From: Richard A Steenbergen RAS> They CAN filter on anything in the headers, it's just a matter of RAS> convincing them that the specific filter you want is something they should RAS> add to their software language and microcode. I'm sure as a core router RAS> vendor they must hear every feature request imaginable and not know which RAS> ones to follow up on. If anyone from Juniper is listening, I can tell you RAS> 4 things to add which will stop all existing packet kiddie tools in their RAS> tracks. But then again, I'd rather just have a language for bitmatching at RAS> any offset. :) And it wouldn't be that hard to have something to compile rulesets into simply assembly, either: movb 0x12(1,%ecx),%al andb $0x34,%al xorb $0x14,%al jz some_destination Oversimplified, yes. But mask-then-test is one of the simpler apps to write. s/x86/chipofchoice/ and have fun. Juniper being based on FreeBSD/x86, perhaps some kernel hooks might be in order for those who wish to write their own code. -- Eddy Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
ED> Date: Fri, 3 May 2002 02:35:53 +0000 (GMT) ED> From: E.B. Dreger ED> Juniper being based on FreeBSD/x86, perhaps some kernel hooks ED> might be in order for those who wish to write their own code. And, were my head on straight, I'd have been thinking about the ASIC in the line card, _not_ the central CPU... /me needs sleep. -- Eddy Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
Do you mind sharing with us the 4 things that exists only in DoS packets ? Rubens Kuhl Jr. ----- Original Message -----
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. :)
participants (5)
-
E.B. Dreger -
Hank Nussbacher -
LeBlanc, Jason -
Richard A Steenbergen -
Rubens Kuhl Jr.