Fwd: Snort on span port

[Charles Heselton <charles.heselton () gmail com>]

A solution presented by one of my network engineers.


---------- Forwarded message ----------
From: Lohr, Corey R <corey.lohr () nmci-isf com>
Date: Thu, 12 Aug 2004 23:54:40 -0700
Subject: RE: [Snort-users] Snort on span port
To: "Garrett, Joshua" <joshua.garrett () nmci-isf com>, "Sheldon, Mike
E." <mike.sheldon () nmci-isf com>, Charles Heselton
<charles.heselton () gmail com>, "O'Sullivan, Richard"
<richard.o'sullivan () nmci-isf com>


Josh and Mike are right and it has nothing to do with root bridge
selection (tha. The 0.2 Mbps of traffic is switching overhead (bpdu,
hello frames/packets, dot1q/isl frames, and pagp if channeling is
configured). The following would fix the problem:
 
+++++         +++++  
+ sw1+ -----+ sw2+
+++++         +++++
     |                   |
     |                   |
+++++          +++++       ++++++
+ sw3+ -----+ sw4+-----+sniffer+
+++++          +++++       ++++++
 
Setup an rspan on sw1, sw2 and sw3 with source port(s) and vlan(s) to
destination switchport x on sw4.
 
Then configure sw4 with a regular span including all the source
switchports and vlan(s) coming from sw1, sw2 and sw3 to destination
switchport y on sw4.
 
VACLs are used for filter granularity once all span requirements have
been configured to cut down on layer 2 overhead.
 
-C


 
-----Original Message----- 
From: Garrett, Joshua 
Sent: Thu 8/12/2004 13:52 
To: Sheldon, Mike E.; Charles Heselton; O'Sullivan, Richard; Lohr, Corey R 
Cc: 
Subject: RE: [Snort-users] Snort on span port




He needs Manhunt.. or something kinda like it.... 2 RSPANs... uplinks
from redundant Inners/ Distros ensures you will always get your
intended data, regardless of which device (in a 2 device redundancy
configuration) is root.
 
R/
Josh G.

-----Original Message----- 
From: Sheldon, Mike E. 
Sent: Wed 8/11/2004 12:41 AM 
To: Charles Heselton; Garrett, Joshua; O'Sullivan, Richard; Lohr, Corey R 
Cc: 
Subject: RE: [Snort-users] Snort on span port


Geez, sounds like a good CCIE lab question....
While I haven't heard of this specific issue, I could see some
potential problems looking at it from a theoretical point of view. 
Here's the basic picture.  The root bridge (switch in this case) has
all of it's ports in a forwarding state by definition.  The secondary
root bridge and/or access switches would have some ports in a blocking
state to avoid bridge loops.  One question is how Cisco handles
shifting SPAN traffic when there's a bridge topology change?  In the
case of local SPAN, I would tend to guess that it doesn't shift
traffic at all since it's a statically mapped SPAN session.  RSPAN
sessions may be another matter.
 
Depending on which ports are carrying the SPAN traffic, which ports
are in a forwarding/blocking state, which ports the IDS interfaces are
connected to, and which switch a given packet hit prior to being
SPAN'd, it may be possible for a switch to forward a packet towards a
port that's in a blocking state.  We could determine if that's what
we're seeing by mapping out physical connections, SPAN mapping, and
then overlaying the spanning tree forwarding/blocking state of the
associated interfaces.  We could run some traffic from/to certain
points to verify that we see (or don't see) based on the theory.
 
Regards,
Mike
 

-----Original Message----- 
From: Charles Heselton [mailto:charles.heselton () gmail com] 
Sent: Wed 8/11/2004 12:04 AM 
To: Garrett, Joshua; O'Sullivan, Richard; Lohr, Corey R; Sheldon, Mike E. 
Cc: 
Subject: Fwd: [Snort-users] Snort on span port



Have you guys heard of anything like this?  (Root bridge has to be the
switch spanning the traffic.)  Is it true?

We are deploying SourceFire (snort network sensor) appliances to
capture traffic on a VLAN that spans 4 Cisco Catalyst 5500 switches
(Cat OS), connected on a trunk. I looked at the data, connecting to
the span port of each of the switches; these span ports are supposed
to be well configured by competent engineers and are in use for a long
time for network sniffing through NAI distributed network sniffer. I
am connecting the snort appliance in parallel with NAI sniffer using a
100 MB/s hub. I see less than 0.2 MB/s traffic on 3 of these switches
while I see over 2 MB/s sustained traffic when connected to the span
port of one of the switches. So i decided to connect the IDS to the
span port of this switch. I initially thought that I would see the
same traffic on all 4 switches as they are trunked and after this
exercise, I realized the entire traffic of the VLAN can be sniffed
only on one of the switch's span port. A network engineers clarified
that ONLY the root bridge on the VLAN would see all the traffic and
the root bridge could change after a re-election when the current root
goes down.

The question is how do I ensure that I always capture the entire VLAN
traffic, irrespective of which switch is the "root bridge".  Should I
have IDS sensors on the span port of all the switches in this kind of
scenario?  Is there any better solution?  I keep hearing of Cisco
terminology VACL to configure the port on which IDS sits? Is it better
than using span port ??  I would appreciate if some one shares their
experience dealing with this kind of situation.

Thanks,
Ilango


--
Charlie Heselton
Network Security Engineer



-- 
Charlie Heselton
Network Security Engineer


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users