DOS attack tracing

Tue May 10 02:07:43 UTC 2005

On Mon, 9 May 2005, Scott Weeks wrote:

> On Mon, 9 May 2005, Richard wrote:
>
> : type of routers. Our routers normally run at 35% CPU. What sucks is that the
> : traffic volume doesn't have to be very high to bring down the router.
>
> That's because it's the number of packets per time period that it can't
> handle, not the traffic level.  At this point it seems most likely that
> it's a simple UDP flood.  If your CPU usually runs at 35% you definitely
> don't need a bigger router unless you're expecting a growth spurt.  You
> might want to put an RRDTool or MRTG graph on the CPU usage to be sure.

I'll disagree here.

When you're engineering a network, what you generally need to care about 
is peak traffic, not average traffic.  While DOS attack traffic is 
presumably traffic you'd rather not have, it tends to be part of the 
environment.

This is somewhat of an arms race, and no router will protect you from all 
conceivable DOS attacks.  That said, designing your network around the 
size of attack you typically see (plus some room for growth) raises the 
bar, and turns attacks of the size you've designed for into non-events 
that you don't need to wake up in the middle of the night for.

Remember, the real goal in dealing with DOS attacks is to get to the point 
where you don't notice them, rather than just being able to explain why 
your network is down.

For those attacks that go beyond the capacity you can afford, being able 
to divert the traffic is a good thing.  The Riverhead system (now known as 
Cisco Guard, I think) does reasonably well at protecting networks 
downstream from it without being a big point of failure, but the network 
upstream from it still needs to be able to take the load.  And being 
better able to characterize the attack traffic may help you ask your 
upstreams to block it for you.  This can be done with some of the tools 
others have mentioned, including your router's flow cache *if your router 
hasn't already fallen over and died*.

A rather dated paper on my experiences dealing with this sort of thing is 
at http://www.stevegibbard.com/ddos-talk.htm.

-Steve