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