Real world Anti-DDOS attack practice.

Fri Mar 23 02:05:59 UTC 2001

On Fri, Mar 23, 2001 at 08:21:30AM +0800, Yu Ning wrote:
> 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 ?

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.