[Snort-users] Vlan Tagging Issue with Snort

infosec posts infosec.posts at ...11827...
Tue Sep 14 09:38:27 EDT 2010


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?

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 ...14459.....>
>> 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 ...13704......>
>> > 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 ...13704......>
>> >> 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
>
>




More information about the Snort-users mailing list