Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Snort-users] Re: Snort on span port

0 views
Skip to first unread message

SN ORT

unread,
Aug 12, 2004, 4:00:13 PM8/12/04
to
Hey man don't be dis'ing my net engineers!

J/K.

Ok, so if I remember correctly, root-bridges are like
only for vlan trunking protocol and elections and
what-not of switches that will act as root bridges.
All they do is keep track of vlans. Not sure what this
has to do with port spanning/monitoring. Your
engineers should be spannig at the physical layer and
not the vlan layer. They should be spanning the
physical ports that the vlans are trunked on and
connected to each other. Nevermind the gibberish about
Cisco switches not keeping up with spanning...hogwash!
You assign vlans and trucks to ports, all the
engineers need to worry about are physically spannning
those ports to your ports.

IOW, let's say my trunk port is port one on one of the
switches. The port is either part of the backbone or
at least connects to the other switches. Now let's say
your IDS is connected to port two. All the engineer
has to do is get on the switch, go to port 2 and type
in "port monitor fa0/1" Then you'd be set!

Cheese!

Marc

> --__--__--
>
> Message: 1
> Date: Wed, 11 Aug 2004 00:01:41 -0700
> From: Charles Heselton <charles....@gmail.com>
> To: Ilango S Allikuzhi <ilangoa...@dtcc.com>
> Subject: Re: [Snort-users] Snort on span port
> Cc: "snort...@lists.sourceforge.net"
> <snort...@lists.sourceforge.net>
>
> ----- Original Message -----
> From: Ilango S Allikuzhi <ilangoa...@dtcc.com>
> Date: Thu, 5 Aug 2004 11:23:00 -0400
> Subject: [Snort-users] Snort on span port
> To: "snort...@lists.sourceforge.net"
> <snort...@lists.sourceforge.net>
>
>
> 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
>
> I work in an environment where all of our network
> traffic is captured
> through Cisco Switch Spanning, and I have never
> experienced a problem
> related to whichever switch might be the "root
> bridge" for the VLAN.
>
> However, I am not a network engineer by any means, I
> am an IDS
> engineer. So you may want to take what I say with a
> grain of salt.
> In my experience, "userland" VLANS are spanned to a
> "monitoring" trunk
> VLAN on an alternate switch port. The IDS either
> sits on that port,
> or (depending upon the capabilities of the switch)
> that port is then
> SPAN'd/RSPAN'd to another switch, which then locally
> SPANs the traffic
> to the IDS promiscuous interface. This whole
> configuration depends on
> your architecture, the capability of your switch
> infrastructure, and
> can vary accordingly.
>
> Somethings to consider are 1) how much traffic
> SHOULD be traversing
> the VLANS that you are monitoring on the one that is
> seeing less
> bandwidth? Is that typical or atypical? 2) How
> many VLANS are you
> dealing with? 3) What type of traffic do you
> actually see on the
> port with less bandwidth? It's really difficult to
> speak
> intelligently about your situation without knowing
> more about your
> architecture. If you would like to email me
> off-list to provide more
> detail about your infrastructure, I might be able to
> help more.
>
> Basically, I don't know anything about VACL's, but
> we've been able to
> accomplish most of the visibility that we need
> through the mixture of
> local SPAN sessions and RPSAN sessions (remote).
> You should be able
> to do the same (depending on the capabilities of
> your switches).
>
> --
> Charlie Heselton
> Network Security Engineer
>
>




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail


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

Michael J. Pelletier

unread,
Aug 13, 2004, 12:41:23 AM8/13/04
to

> Hey man don't be dis'ing my net engineers!

> J/K.

> Ok, so if I remember correctly, root-bridges are like only for vlan trunking
protocol and elections and what-not of switches that will act as root bridges.

Root Bridges are used for SPANNING TREE!. You can run VLAN trunks with SPANNING
TREE. With SPANNING TREE each bridge will calulate it's distance from the root
bridge to itself. This cost is used to determine the shortest past cost to the
root bridge. Although ROOT BRIDGES are used with SPANNING TREE and VLANS can
use SPANNING TREE ther are not the same.

> All they do is keep track of vlans.

Not true. Root bridges help determine path cost between bridges.

> Not sure what this has to do with port spanning/monitoring. Your engineers
should be spannig at the physical layer and not the vlan layer.

Actually you can do both if your IDS understands VLAN trunking.

> They should be spanning the physical ports that the vlans are trunked on and
connected to each other. Nevermind the gibberish about Cisco switches not
keeping up with spanning...hogwash!

Dude, Sorry but the Cisco 5500 series is known for this. Newer, ie 6500, etc are
much, much better. Ask any Cisco engineer or someone, like me, that has used
them for years. In private the Cisco Engineer will tell you.

> You assign vlans and trucks to ports, all the engineers need to worry about
are physically spannning those ports to your ports.

> IOW, let's say my trunk port is port one on one of the switches. The port is
either part of the backbone or at least connects to the other switches. Now
let's say your IDS is connected to port two. All the engineer has to do is get
on the switch, go to port 2 and type in "port monitor fa0/1" Then you'd be set!

Cheese!

Marc


/*******************************************/
UNIX is a very friendly OS. It is just picky
about who it makes friends with.
/*******************************************/

Disclaimer:
This electronic message, including any attachments, is confidential and intended solely for use of the intended recipient(s). This message may contain information that is privileged or otherwise protected from disclosure by applicable law. Any unauthorized disclosure, dissemination, use or reproduction is strictly prohibited. If you have received this message in error, please delete it and notify the sender immediately.

0 new messages