DOS attack tracing

Tue May 10 08:19:03 UTC 2005

1) Get 'Cisco guard' , too expensive ?
2) Get Arbor, Stealthflow, Esphion, too expensive ?
3) Use flow-tools, ntop, Silktools and open-source Netflow collectors
& analyzers
4) Apply Ingress/Egress Filtering : RFC 2827 , uRPF, Team cymru IOS template 
5) Monitor CPU/Netflow table size using SNMP
6) Request a blackholing BGP community from your upsream provider.

On 5/10/05, Scott Weeks <surfer at mauigateway.com> wrote:
> 
> On Mon, 9 May 2005, Steve Gibbard wrote:
> : 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.
> 
> Cool!  Good 'ol operations discussion...  :-)
> 
> I took things out of order from your email, but kept the context.
> 
> : www.stevegibbard.com/ddos-talk.htm
> 
> Nice paper.   However, you still say what I was saying, just in a
> different sort of way.  Instead of NTop and RRDTool/MRTG, you use Cricket.
> RRDTool/MRTG alerts you to the problem and NTop directs you to the source
> of the problem.  Once you get the procedure down pat, it can go pretty
> fast.
> 
> As far as puttimg something in front of the core router(s) (such as
> Riverhead), I assumed there was nothing there for Richard; just raw
> router interface(s) to the upstream and not enough budget to afford those
> nice-but-expensive boxes.  I was going to mention things like Riverhead or
> Packeteer later in the posts if appropriate.
> 
> : 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.
> 
> This is what I was getting at.  Engineering the network.  That's more
> than buying a Bigger Badder Router and Fatter Pipes(BBR&FP).  If your
> router is running at 35% during the normal peak traffic flow, you don't
> need a BBR&FP.  All you need to do is design the network (and train the
> monkeys, as randy terms it... :-) to deal with extraordinary peaks.
> 
> : 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.
> 
> Yes, but a BBR&FP isn't the way to deal with this unless you've got the
> big budget.  I know that a bigger hammer is better if you've got the
> money, but if you don't engineering finesse can work well.
> 
> scott
> 
>