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.

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

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

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


You're an idiot!

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

Yeah, but the challenge is getting an OC48 into a 7500. :wink:

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.


[0] significant = longer than about 5 lines, even with 'permit tcp estab'
                  as the first line