Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Real world Anti-DDOS attack practice.

  • From: James M. Shuler III
  • Date: Thu Mar 22 21:33:29 2001

You're an idiot!

----- Original Message -----
From: "James M. Shuler III" <>
To: <>
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?


----- Original Message -----
From: "Basil Kruglov" <>
To: <>
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:
> I'm sorry if I raise a clich¨¦ topic, but I've searched the nanog archive
> get no satisfied answer.
> The question is quite simple, what's the best practice if my downstream
> report a heavy DDOS attack (icmp based, not source addr.  spoofing)?  Yes,
> filter out the packet via ACL, but the impact on oc3/48 link with ACL
> 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
> 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
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
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,
that /24-block might end up "disconnected" for hours, days, weeks, and even

-Basil, speaking only for myself.

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.