Re: DOS/Broadcast Storm analysis

["Niedens, Travis" <Travis_Niedens () REDLANDS EDU>]

Along with this..

I personally am against unplugging physical hardware to resolve a DoS
attack.  If you know the source port of the user causing the issue, just
disable it.  Unplugging physical hardware (GBICs, Fiber, blades, etc.) can
ultimately just add to the issue.  I have seen situations in the past where
people pull out a blade and when they shove it back in it resets the whole
switch; this is not something I personally would want to explain to upper
management.  Another solution is to put QoS / Traffic Shaping on your
interfaces.  You can also configure broadcast storm prevention on many of
the switches on the market.  Ultimately, using the features in the devices
in conjunction with tools will give you a smoother experience.  

Just my $.02 

Travis Niedens
Network Manager
University of Redlands


-----Original Message-----
From: Mark Poepping [mailto:poepping () CMU EDU] 
Sent: Thursday, March 25, 2004 3:46 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] DOS/Broadcast Storm analysis

just to add to the unplug and chug suggestion...

If it's just one bad machine on the inside and a broadcast storm or
something, then a packet capture may rightly solve your problem (tcpdump on
any unix box is easiest imho).

if it's tougher, distributed or maybe on the outside, almost every router
has some kind of flow export mechanism (netflow or sflow), and there are
tools (flowscan is a popular example) to suck up flow records and produce
useful information.  This is a fairly easy ramp-up option, much less data
than packet capture, but very nearly the same amount of information.  

If you're not routing and it's not a broadcast thing, then you can also use
a port-mirror capability (that exists on most switches) and a packet capture
or a flow-based capture tool (like argus) to producer very similar (even
richer) diagnostic information.

If you are unfamiliar with this technology - the quick/dirty method is to
buy some consulting.  There's a lot of expertise on this stuff over at sdsc
and ucsd if you have contacts over there.
mark.

> -----Original Message-----
> From: The EDUCAUSE Security Discussion Group Listserv 
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Gary Flynn
> Sent: Thursday, March 25, 2004 3:08 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] DOS/Broadcast Storm analysis
>
> West, David F. wrote:
>
> > We appear to be having a DOS, Broadcast Storm or equivalent activity
> happening at a time frame every day for about 45 minutes. Same time 
> every day but we have no resources to analysis the traffic. Our 
> college is relatively small with only about 300 staff and 1500 
> students. Is there a low cost solution for monitoring and diagnosing a
switched IP environment?
> All buildings are home runned via fiber to our main network center.
> Suggestion for solutions are greatly appreciated since we have a very 
> limited staff to support the network here.
>
> Its difficult to say without a better idea of the symptoms you are 
> seeing but here are some general tips...
>
> Manual methods:
>
> 1. Starting with your core router, login and check interface
>     statistics, particularly packet rates and errors. Work out
>     from the troublesome interface through your switches until
>     you find the culprit. If its a major event, you might
>     simply be able to see it by monitoring the interface lights
>     at your fiber termination point.
>
> 2. Login to the system(s) being affected, monitor interface
>     statistics and connection logs, and trace back as in #1.
>     Use netstat on unix, performance monitor on windows.
>
> 3. Get a packet capture. You can use the free Network Monitor
>     that comes with Windows:
>     http://support.microsoft.com/default.aspx?scid=kb;en-us;812953
>     or the open source Ethereal tool on either Windows or linux.
>
>     Broadcast traffic will generally show up on all switch ports
>     connected to the same router interface. To collect other
>     traffic, you will have to learn how to create a span port on
>     your switch or have a tap so that you can sniff traffic on the
>     segment(s) of interest.
>
> Future automation:
>
> 1. Set up an SNMP managment station to poll interface
>     statistics from your switches and systems. Alert
>     accordingly according to thresholds above or below
>     a baseline. Free software abounds. Check out MRTG for
>     starters.
>
> --
> Gary Flynn
> Security Engineer - Technical Services James Madison University
>
> **********
> Participation and subscription information for this EDUCAUSE 
> Discussion Group discussion list can be found at
http://www.educause.edu/cg/.

**********
Participation and subscription information for this EDUCAUSE Discussion
Group discussion list can be found at http://www.educause.edu/cg/.

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/cg/.