Real world Anti-DDOS attack practice.
mdevney at teamsphere.com
mdevney at teamsphere.com
Fri Mar 23 13:25:22 UTC 2001
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
More information about the NANOG
mailing list