Real world Anti-DDOS attack practice.
Hi nanog, I'm sorry if I raise a cliché topic, but I've searched the nanog archive and get no satisfied answer. The question is quite simple, what's the best practice if my downstream customer report a heavy DDOS attack (icmp based, not source addr. spoofing)? Yes, to filter out the packet via ACL, but the impact on oc3/48 link with ACL packet filtering sounds to be a nightmare. If there is any effective practice to prevent my engineer from patching the router here and there via packet ACL ? Yes again via dCAR to rate-limiting the icmp traffic, but as soon as you mention the packet-filtering method, it seems as if my router is in smoke. Then I wonder what my US counterpart do to beat DDOS attack to their customer? Best real world practice ? How about tier-1 like UUNet ? thanks for any input. -------------------------------------------- (Mr.) Yu Ning, Chief Engineer ChinaNET Sr. Support & New Service Dev. Data Communication Bureau, China Telecom Beijing, P.R.China +86-10-62072357/62072354 --------------------------------------------
On Fri, Mar 23, 2001 at 08:21:30AM +0800, Yu Ning wrote:
There's no permanent solution for this problem... 1. I'd replace Ciscos or add Junipers to your network. With or without filters/policers - no problems pushing *any* traffic regardless of pps-rate from one interface to another, & logging it. 2. Ask your customer to place all potential DoS-targets - ircd, shell servers, etc. into separate /24 block, and advertise it as /24. If you place it inside /21 or shorter you will suffer when your bgp sessions start flapping. 3. See what peers/transits of yours are OK, i.e. not bitching when you constantly call in asking to filter or trace the attack back to its source over their network. Make list of good, not-so-good, and bad peers/transits. Ask them to produce their policies on what they can and can't do in case you're getting DoSed. (Some will have 24h filtering policies, others will place filters for as long as the attack is in progress for as long as it's not taking their network down, in some cases you might get blackholed with or without your permissions as "they are protecting their network resources", and so on). Ask them to rate-limit icmp. uRPF on their end... so that all those RFC1918 and out of bgp-tables dDoS attacks will be null0'ed before reaching your network, your customers. 4. Create bgp communities, to advertise that dedicated /24 differently when the attack is in progress, there is no point calling clueless peer or transit if they are unable or refuse to trace/shutdown the attack on their end, you'd only be wasting *your time*. Instead if it's coming from your transit connection - set /24 route as no-export. Monitor inbounds, if it's clearly coming from their direct customers and not from their peers' customers stop advertising that /24 all together over to that peer. If you have 25+ more peers you will need to create some sort of interface, script, whatever to make all these changes on the fly. And of course connect to as many peering points as you possibly can, otherwise that /24-block might end up "disconnected" for hours, days, weeks, and even months... -Basil, speaking only for myself.
thank you for sharing hard learned knowledge. let me know when I bother you. Why would I ever order an AMI line? James ----- Original Message ----- From: "Basil Kruglov" <basil@cifnet.com> To: <nanog@merit.edu> Sent: Thursday, March 22, 2001 9:05 PM Subject: Re: Real world Anti-DDOS attack practice. On Fri, Mar 23, 2001 at 08:21:30AM +0800, Yu Ning wrote: packet
There's no permanent solution for this problem... 1. I'd replace Ciscos or add Junipers to your network. With or without filters/policers - no problems pushing *any* traffic regardless of pps-rate from one interface to another, & logging it. 2. Ask your customer to place all potential DoS-targets - ircd, shell servers, etc. into separate /24 block, and advertise it as /24. If you place it inside /21 or shorter you will suffer when your bgp sessions start flapping. 3. See what peers/transits of yours are OK, i.e. not bitching when you constantly call in asking to filter or trace the attack back to its source over their network. Make list of good, not-so-good, and bad peers/transits. Ask them to produce their policies on what they can and can't do in case you're getting DoSed. (Some will have 24h filtering policies, others will place filters for as long as the attack is in progress for as long as it's not taking their network down, in some cases you might get blackholed with or without your permissions as "they are protecting their network resources", and so on). Ask them to rate-limit icmp. uRPF on their end... so that all those RFC1918 and out of bgp-tables dDoS attacks will be null0'ed before reaching your network, your customers. 4. Create bgp communities, to advertise that dedicated /24 differently when the attack is in progress, there is no point calling clueless peer or transit if they are unable or refuse to trace/shutdown the attack on their end, you'd only be wasting *your time*. Instead if it's coming from your transit connection - set /24 route as no-export. Monitor inbounds, if it's clearly coming from their direct customers and not from their peers' customers stop advertising that /24 all together over to that peer. If you have 25+ more peers you will need to create some sort of interface, script, whatever to make all these changes on the fly. And of course connect to as many peering points as you possibly can, otherwise that /24-block might end up "disconnected" for hours, days, weeks, and even months... -Basil, speaking only for myself.
You're an idiot! ----- Original Message ----- From: "James M. Shuler III" <jshuler@cfl.rr.com> To: <nanog@merit.edu> Sent: Thursday, March 22, 2001 9:16 PM Subject: Re: Real world Anti-DDOS attack practice. thank you for sharing hard learned knowledge. let me know when I bother you. Why would I ever order an AMI line? James ----- Original Message ----- From: "Basil Kruglov" <basil@cifnet.com> To: <nanog@merit.edu> Sent: Thursday, March 22, 2001 9:05 PM Subject: Re: Real world Anti-DDOS attack practice. On Fri, Mar 23, 2001 at 08:21:30AM +0800, Yu Ning wrote: packet
There's no permanent solution for this problem... 1. I'd replace Ciscos or add Junipers to your network. With or without filters/policers - no problems pushing *any* traffic regardless of pps-rate from one interface to another, & logging it. 2. Ask your customer to place all potential DoS-targets - ircd, shell servers, etc. into separate /24 block, and advertise it as /24. If you place it inside /21 or shorter you will suffer when your bgp sessions start flapping. 3. See what peers/transits of yours are OK, i.e. not bitching when you constantly call in asking to filter or trace the attack back to its source over their network. Make list of good, not-so-good, and bad peers/transits. Ask them to produce their policies on what they can and can't do in case you're getting DoSed. (Some will have 24h filtering policies, others will place filters for as long as the attack is in progress for as long as it's not taking their network down, in some cases you might get blackholed with or without your permissions as "they are protecting their network resources", and so on). Ask them to rate-limit icmp. uRPF on their end... so that all those RFC1918 and out of bgp-tables dDoS attacks will be null0'ed before reaching your network, your customers. 4. Create bgp communities, to advertise that dedicated /24 differently when the attack is in progress, there is no point calling clueless peer or transit if they are unable or refuse to trace/shutdown the attack on their end, you'd only be wasting *your time*. Instead if it's coming from your transit connection - set /24 route as no-export. Monitor inbounds, if it's clearly coming from their direct customers and not from their peers' customers stop advertising that /24 all together over to that peer. If you have 25+ more peers you will need to create some sort of interface, script, whatever to make all these changes on the fly. And of course connect to as many peering points as you possibly can, otherwise that /24-block might end up "disconnected" for hours, days, weeks, and even months... -Basil, speaking only for myself.
On Thu, 22 Mar 2001, Basil Kruglov wrote:
Good suggestions all, but as a short-term solution access lists work. A Cisco 7500 with an access list 30 pages long (literally -- I printed it out once) works on an OC48. Not sure how that would stand up to a couple truly massive floods, but it works fine under normal traffic and the average flooding any ISP gets. --Matthew Devney
On Fri, Mar 23, 2001 at 05:25:22AM -0800, mdevney@teamsphere.com wrote:
Yeah, but the challenge is getting an OC48 into a 7500. ;) And frankly, I've -never- seen a significant[0] access list perform well on an RSP4 at even OC3 level. Then again, the last time I tried such a thing I wouldn't touch CEF with a 10-foot pole. Maybe it's better now. -c [0] significant = longer than about 5 lines, even with 'permit tcp estab' as the first line
participants (5)
-
Basil Kruglov
-
Clayton Fiske
-
James M. Shuler III
-
mdevney@teamsphere.com
-
Yu Ning