|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Real world Anti-DDOS attack practice.
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
|