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 <[EMAIL PROTECTED]> 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 > >
