Re: DOS/Broadcast Storm analysis

[Mark Poepping <poepping () CMU EDU>]

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