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
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
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 ?
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.