Re: Vlan Tagging Issue with Snort

[infosec posts <infosec.posts () gmail com>]

I'll post one more reply to this thread, just because I hate when I
find threads on mailing lists that either don't have a resolution, or
end with "fixed!" and no indication what the solution was.  There's a
good chance nobody else will ever end up with the questionable network
design that I am dealing with, but I'm posting anyway.

To recap, forced network changes created a situation where the packet
stream from a switch monitor session included the following:
* all outbound traffic was not in any vlan
* all return traffic was in one of several vlans; the packets
contained 802.1q tags in the headers

After adjusting BPF filters so that snort could see all packet streams
(but filtering ports I don't want it to see), all rules with flow
checks were still broken, because stream5 couldn't associate a given
outbound SYN packet (no vlan) with the return SYN/ACK packet (in vlan
"x").  Sourcefire confirmed that this is by design:

"Snort includes the vlan tag along with ip addresses and ports in the
session cache key used to store session state.  To Snort, the traffic
in each direction is effectively on different sessions.  Can't offer
any advice on how to resolve the problem, sorry."  (Thanks, Russ!)

A gentlemen with the handle of "Joe Vuln" pointed me in the right
direction to a temporary fix, which was this:
* create virtual vlan interfaces for each vlan on the inbound stream.
This terminates the vlan at my snort sensor and strips the 802.1Q tags
off the packets
* use multiple daemonlogger instances as a soft tap to forward traffic
from the physical interface and each of the vlan subinterfaces to a
single separate interface
* snort monitors the destination interface that is receiving all the
daemonlogger feeds

Surprisingly, even with 11 daemonlogger processes running, and packet
streams running 300-400 megabits, the boxes seem to be performing just
fine so far.  Kudos to Marty for daemonlogger performance.  If
daemonlogger could tap multiple source interfaces in the same session,
that would help me out, but I don't believe it can do that (perhaps a
libpcap limitation?), and I don't have the skills to modify it.

This is definitely a duct tape and bubble gum workaround, not a
permanent fix.  The long-term solution is to make architectural
changes so the entire packet stream from the switch has 802.1Q vlan
tags, and I can go back to monitoring normally.

Thanks to those of you who provided assistance and suggestions.


On Tue, Sep 14, 2010 at 9:00 AM, Russ Combs <rcombs () sourcefire com> wrote:
> On Tue, Sep 14, 2010 at 9:38 AM, infosec posts <infosec.posts () gmail com>
> 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?

------------------------------------------------------------------------------
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 () 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