Fwd: [Snort-users] Snort on span port

Charles Heselton charles.heselton at ...11827...
Sat Aug 14 13:36:06 EDT 2004


A solution presented by one of my network engineers.


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


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 at ...11827...] 
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




More information about the Snort-users mailing list