Re: Real world Anti-DDOS attack practice.

[mdevney]

On Thu, 22 Mar 2001, Basil Kruglov 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... 
> 
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