Snort mailing list archives
Re: Vlan Tagging Issue with Snort
From: Russ Combs <rcombs () sourcefire com>
Date: Tue, 14 Sep 2010 10:00:13 -0400
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?
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 () sourcefire com> 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 () gmail com> 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: YESThis 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 () gmail com>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 () gmail com>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 port443)"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 () gmail com>wrote:Greetings Snort Gurus, Our network folks were recently forced to make some architecturalandequipment changes that are creating an issue with our snort monitoring. The core of the problem is that on the switch thatsendsour 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) limitationsinthe network swtiches. I know that snort supports and understandsvlantagging, 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,likeso: 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 () 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
------------------------------------------------------------------------------ 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
Current thread:
- Vlan Tagging Issue with Snort infosec posts (Sep 09)
- Re: Vlan Tagging Issue with Snort Joel Esler (Sep 10)
- Re: Vlan Tagging Issue with Snort infosec posts (Sep 10)
- Re: Vlan Tagging Issue with Snort Bamm Visscher (Sep 10)
- Re: Vlan Tagging Issue with Snort infosec posts (Sep 10)
- Re: Vlan Tagging Issue with Snort infosec posts (Sep 13)
- Re: Vlan Tagging Issue with Snort Russ Combs (Sep 13)
- Re: Vlan Tagging Issue with Snort infosec posts (Sep 14)
- Re: Vlan Tagging Issue with Snort Russ Combs (Sep 14)
- Re: Vlan Tagging Issue with Snort infosec posts (Sep 17)
- Re: Vlan Tagging Issue with Snort infosec posts (Sep 10)
- Re: Vlan Tagging Issue with Snort Joel Esler (Sep 10)