DOS attack tracing

Scott Weeks surfer at mauigateway.com
Tue May 10 11:05:00 UTC 2005




On Tue, 10 May 2005, Kim Onnel wrote:

: 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.


Yep, those are some of the things I meant by:

: > 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






: 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
: >
: >
:
:




More information about the NANOG mailing list