[Snort-users] Vlan Tagging Issue with Snort

Russ Combs rcombs at ...1935...
Tue Sep 14 10:00:13 EDT 2010


On Tue, Sep 14, 2010 at 9:38 AM, infosec posts <infosec.posts at ...11827...>wrote:

> Thanks for the tip, Russ; I went ahead and made this change.
>
> I realized this morning that the flow checks aren't working even with
> no BPF filters running on the snort process.  This leads me to believe
> that having vlan tags on only one half of the conversation breaks
> snort's stream5 preprocessor.  Is this a snort bug, or is there a
> configuration option I'm missing that can correct the problem?
>

Have you tried capturing a pcap for a single session to see what you have?

You can send that along if you want us to take a look at it.

>
> I've also searched briefly for a way to get debug-level information on
> what stream5 is doing, but haven't come up with anything yet...
>
>
>
> On Mon, Sep 13, 2010 at 5:44 PM, Russ Combs <rcombs at ...1935...> wrote:
> > Not sure what is causing the issue you report but see below for another
> > comment.
> >
> > On Mon, Sep 13, 2010 at 5:04 PM, infosec posts <infosec.posts at ...11827...>
> > wrote:
> >>
> >> Unfortunately, I discovered that this configuration is breaking all of
> >> my signatures that use "flow:to_client,established", so I assume it's
> >> messing with stream5 and all of my other rules which use checks that
> >> take advantage of stream5.  I'm not sure why this is, as snort should
> >> be seeing the entire (both sides of) tcp conversation setup and
> >> teardown now (as confirmed by using the same filter on tcpdump).
> >>
> >> For a given signature, changing "flow:to_client,established" produces
> >> the following results:
> >>
> >> flow:stateless; - signature alerts
> >> flow:statless,no_stream; - signature alerts
> >> flow:stateless,only_stream; - no alert
> >>
> >> Obviously, I don't want to re-write my rules to exclude flow checks &
> >> such, even via an automated process.  If anyone has insight into what
> >> is happening or additional troubleshooting/information gathering
> >> procedures, I'd appreciate the help.  Thanks!
> >>
> >> Here's my stream5 config (unchanged since before the network gear
> >> changed and we started getting the 802.1q traffic) :
> >> preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no
> >> preprocessor stream5_tcp: policy first, use_static_footprint_sizes
> >>
> >> snort[4576]: Stream5 global config:
> >> snort[4576]:     Track TCP sessions: ACTIVE
> >> snort[4576]:     Max TCP sessions: 8192
> >> snort[4576]:     Memcap (for reassembly packet storage): 8388608
> >> snort[4576]:     Track UDP sessions: INACTIVE
> >> snort[4576]:     Track ICMP sessions: INACTIVE
> >> snort[4576]:     Log info if session memory consumption exceeds 1048576
> >> snort[4576]: Stream5 TCP Policy config:
> >> snort[4576]:     Reassembly Policy: FIRST
> >> snort[4576]:     Timeout: 30 seconds
> >> snort[4576]:     Maximum number of bytes to queue per session: 1048576
> >> snort[4576]:     Maximum number of segs to queue per session: 2621
> >> snort[4576]:     Options:
> >> snort[4576]:         Static Flushpoint Sizes: YES
> >
> > This should be NO for live traffic, so remove use_static_footprint_sizes.
> >
> > The manual will be updated to make that more clear.  It was intended for
> > testing only.
> >
> >> snort[4576]:     Reassembly Ports:
> >> snort[4576]:       21 client (Footprint)
> >> snort[4576]:       23 client (Footprint)
> >> snort[4576]:       25 client (Footprint)
> >> snort[4576]:       42 client (Footprint)
> >> snort[4576]:       53 client (Footprint)
> >> snort[4576]:       80 client (Footprint)
> >> snort[4576]:       110 client (Footprint)
> >> snort[4576]:       111 client (Footprint)
> >> snort[4576]:       135 client (Footprint)
> >> snort[4576]:       136 client (Footprint)
> >> snort[4576]:       137 client (Footprint)
> >> snort[4576]:       139 client (Footprint)
> >> snort[4576]:       143 client (Footprint)
> >> snort[4576]:       445 client (Footprint)
> >> snort[4576]:       513 client (Footprint)
> >> snort[4576]:       514 client (Footprint)
> >> snort[4576]:       1433 client (Footprint)
> >> snort[4576]:       1521 client (Footprint)
> >> snort[4576]:       2401 client (Footprint)
> >> snort[4576]:       3306 client (Footprint)
> >>
> >>
> >>
> >> On Fri, Sep 10, 2010 at 10:20 AM, infosec posts <
> infosec.posts at ...11827...>
> >> wrote:
> >> > Looks like those filters are going to work, Bamm; thanks!  I thought
> >> > there had to be a solution like that, but I hadn't found the right
> >> > groupings yet.  You are also correct that the second filter should be
> >> > "port 80 or port 443"; that was an error when I typed this email, as I
> >> > wasn't looking at my actual filters when I typed it up.
> >> >
> >> > I also had an individual reply that suggested setting up a virtual
> >> > interface on my monitor nic and setting it as a vlan tagged port.  I
> >> > haven't tested that yet, but wanted to mention it in case it helps
> >> > someone else reading the list at some point.
> >> >
> >> > On Fri, Sep 10, 2010 at 9:52 AM, Bamm Visscher <
> bamm.visscher at ...11827...>
> >> > wrote:
> >> >> Use an "OR" to grab vlan or ip traffic, like so:
> >> >>
> >> >> BPF="(ip and not port 80 and not port 443) or (vlan and not port 80
> >> >> and not port 443)"
> >> >> BPF="(ip and port 80 and port 443) or (vlan and port 80 and port
> 443)"
> >> >>
> >> >> Although the "port 80 *and* port 443" doesn't make any sense to me
> >> >> (port 80 *or* port 443 maybe)?, but it's your filter.
> >> >>
> >> >> Bamm
> >> >>
> >> >>
> >> >> On Thu, Sep 9, 2010 at 7:05 PM, infosec posts <
> infosec.posts at ...11827...>
> >> >> wrote:
> >> >>> Greetings Snort Gurus,
> >> >>>
> >> >>> Our network folks were recently forced to make some architectural
> and
> >> >>> equipment changes that are creating an issue with our snort
> >> >>> monitoring.  The core of the problem is that on the switch that
> sends
> >> >>> our IDS sensor traffic via a monitor port, outbound traffic is not
> >> >>> tagged, but inbound traffic (from the Internet) come across at trunk
> >> >>> and have 802.1Q vlan tags.  This cannot be changed due to
> >> >>> architectural restrictions and (sad/ridiculous/stupid) limitations
> in
> >> >>> the network swtiches.  I know that snort supports and understands
> vlan
> >> >>> tagging, but because only one direction of the traffic is tagged, it
> >> >>> is creating a problem for us.
> >> >>>
> >> >>> Our IDS box runs two snort instances, with filters like this:
> >> >>>
> >> >>> BPF="not port 80 and not port 443"
> >> >>> BPF="port 80 and port 443"
> >> >>>
> >> >>> In order to see the inbound traffic, I include the "vlan" filter,
> like
> >> >>> so:
> >> >>> BPF="vlan and not port 80 and not port 443"
> >> >>>
> >> >>> ...but then I *only* see inbound traffic, and not outbound.
> >> >>>
> >> [snip]
> >> >>> A couple of other notes:
> >> >>> -The platform is RHEL5.
> >> >>> -We are limited to one monitor session on the swtich feeding the
> >> >>> sensor.
> >> >>>
> >> [snip]
> >> >>>
> >> >>> Thanks in advance.
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Start uncovering the many advantages of virtual appliances
> >> and start using them to simplify application deployment and
> >> accelerate your shift to cloud computing
> >> http://p.sf.net/sfu/novell-sfdev2dev
> >> _______________________________________________
> >> Snort-users mailing list
> >> Snort-users at 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20100914/eec36c34/attachment.html>


More information about the Snort-users mailing list