[80696] in North American Network Operators' Group
Re: DOS attack tracing
daemon@ATHENA.MIT.EDU (Kim Onnel)
Tue May 10 04:19:41 2005
Date: Tue, 10 May 2005 10:19:03 +0200
From: Kim Onnel <karim.adel@gmail.com>
Reply-To: Kim Onnel <karim.adel@gmail.com>
To: Scott Weeks <surfer@mauigateway.com>
Cc: nanog@merit.edu
In-Reply-To: <20050509165047.L85445-100000@www.mauigateway.com>
Errors-To: owner-nanog@merit.edu
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 templat=
e=20
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@mauigateway.com> wrote:
>=20
> 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 route=
r.
> : >
> : > 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 th=
at
> : > it's a simple UDP flood. If your CPU usually runs at 35% you definit=
ely
> : > don't need a bigger router unless you're expecting a growth spurt. Y=
ou
> : > might want to put an RRDTool or MRTG graph on the CPU usage to be sur=
e.
> :
> : I'll disagree here.
>=20
> Cool! Good 'ol operations discussion... :-)
>=20
> I took things out of order from your email, but kept the context.
>=20
> : www.stevegibbard.com/ddos-talk.htm
>=20
> 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.
>=20
> 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 o=
r
> Packeteer later in the posts if appropriate.
>=20
> : When you're engineering a network, what you generally need to care abou=
t
> : 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 a=
ll
> : 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.
>=20
> 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.
>=20
> : Remember, the real goal in dealing with DOS attacks is to get to the po=
int
> : where you don't notice them, rather than just being able to explain why
> : your network is down.
>=20
> 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.
>=20
> scott
>=20
>
