[AusNOG] DDoS Attacks - Painful and Persistent.

[Roland Dobbins]

On Aug 10, 2009, at 1:55 PM, Nick Brown wrote:

> 1. iBGP interface between two routers - Unsure why this target was  
> selected, it is not visible in any traces the target would have  
> completed

Because by taking out a routing relationship, the attacker can  
potentially achieve a large impact for relatively little effort; he  
probably was using routeservers to see how many/which paths from which  
you were advertising various netblocks.  iACLs, GTSM, and CoPP are  
mitigating strategies.

> 2. Interface on our side on PTP link between us an an upstream  
> carrier - This can obviously be overcome by using private address  
> space between your carrier and yourself

Using private addresses for your links is a Really Bad Idea for many  
reasons, like breaking traceroute - again, iACLs, GTSM and CoPP are  
relevant the BCPs in this context.

> 3. Our website IP - this is on a server that does very little except  
> serve our website
> 4. Our website IP again, after the site was moved to an alternate IP  
> on the same box, in a separate subnet.

Again, monitoring of outbound/crossbound traffic should be performed,  
in order to ensure it doesn't appear to be compromised.

> We have no reason to believe that the attack is the result of either  
> compromised routers or our web server (We have gone over the  
> webserver with a fine comb) however at the same time are bracing  
> ourselves as we do somewhat expect that in the event the DDoS stops  
> permanently for whatever reason, we may see attacks and attempted  
> exploits of other sorts

 From where in the topology was the capture made?  Again, one doesn't  
typically see 8K packets outsize of IDCs with jumbo-frame support.  If  
you'll enable NetFlow on your edges, you'll be able to instantly  
traceback the traffic in order to see where it's originating.  It  
would be quite surprising to see 8K packets making it into your  
network from an upstream or peer.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton