[Snort-users] Rule works in replay file mode, but not when sniffing

Pavel Rantorski fhjull01 at ...15979...
Fri Jul 12 13:50:22 EDT 2013


>>  Where was this pcap captured?

On the same machine/interface Snort is listening on, using 'tshark -i eth1 -w /tmp/dump.pcap'.

>> Are you sure you don't have this (https://www.myricom.com/software/myri10ge/349-when-i-view-traffic-with-tcpdump-why-do-i-see-packets-larger-than-the-mtu.html)
 going on?  I definitely saw evidence of that in your earlier Snort 
pcap.  If you use the same options to run Snort both in readback and 
replay modes and you get different results, it is very likely due to how
 the packets are presented to Snort. 

The first pcap may have been captured before I disabled 'generic-receive-offload'. I didn't realize this before you mentioned it - that would explain the difference. I have checked the article and noticed that 'tcp-segmentation-offload' was still enabled - I disabled it using ethtool, but nothing changed.

Currently, the network card features look like this:
root at ...16433...:/tmp# ethtool -k eth1
Features for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

(I've done a new pcap with those settings, if you wish to take a look - http://img.dreamchaser.cz/testdata8.zip)

I've tried to disable rx/tx checksumming as well, but nothing changed (so I enabled them again). I cannot disable rx/tx vlan-offload using ethtool - if you think they may be causing the problem, I'll try to look into other ways of disabling them. 

Can you think of anything else that would be causing the discrepancy between readback/replay modes?

I have modified few network-related kernel parameters (Centos6.4) in /etc/sysctl.conf, if that may be relevant:

net.core.netdev_max_backlog = 10000
net.core.rmem_default = 16777216
net.core.rmem_max = 33554432

net.ipv4.tcp_rmem = 1048576 4194304 33554432
net.ipv4.tcp_no_metrics_save = 1



Date: Fri, 12 Jul 2013 12:55:19 -0400
Subject: Re: [Snort-users] Rule works in replay file mode, but not when sniffing
From: rcombs at ...1935...
To: fhjull01 at ...15979...
CC: jesler at ...1935...; snort-users at lists.sourceforge.net



On Fri, Jul 12, 2013 at 12:22 PM, Pavel Rantorski <fhjull01 at ...15979...> wrote:







Thank you for your answers.

When I use rule:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”Test file 
download”; content:”filename=“; fast_pattern:only; http_header;)

It behaves in a same way - won't fire when sniffing, fires when replayed.


You are correct that with --dirty-pig, no alert is generated even on replay with the sample I sent. I trimmed the sample I sent before, perhaps a bit too much. Larger pcap (hopefully with full session) can be found at:


http://img.dreamchaser.cz/testdata7.zip (8MB)

Where was this pcap captured?


This sample fires both rules (mine + the one suggested by Joel Esler) even with --dirty-pig, but no results when sniffed directly.

Are you sure you don't have this (https://www.myricom.com/software/myri10ge/349-when-i-view-traffic-with-tcpdump-why-do-i-see-packets-larger-than-the-mtu.html) going on?  I definitely saw evidence of that in your earlier Snort pcap.  If you use the same options to run Snort both in readback and replay modes and you get different results, it is very likely due to how the packets are presented to Snort. 


Date: Fri, 12 Jul 2013 11:12:05 -0400
Subject: Re: [Snort-users] Rule works in replay file mode, but not when sniffing

From: rcombs at ...1935...
To: jesler at ...1935...
CC: fhjull01 at ...15979...; snort-users at lists.sourceforge.net


I think you have something else going on.  Can you send a full session capture?

The capture you have is alerting in readback at shutdown.  To confirm, --dirty-pig to your command line and you won't get the alert.



The reason is Content-Length: 9156548 but you only have 4101 bytes in the capture.  Snort is trying to reassemble more data which never shows up.  You can get the alert to fire even with --dirty-pig if you change paf_max to something like 3072.



If you want it fire in replay you need at least paf_max worth of the response body.

On Fri, Jul 12, 2013 at 10:10 AM, Joel Esler <jesler at ...1935...> wrote:


What happens when you do a:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”Test file download”; content:”filename=“; fast_pattern:only; http_header;)



On Jul 12, 2013, at 9:05 AM, Pavel Rantorski <fhjull01 at ...15979...> wrote:



Hello,
I'm testing a rule that should (eventually) detect download/upload of specific file types from public HTTP servers. I could not get the rule to trigger, so I simplified it to:



alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"Test file download"; content:"Content-Disposition|3a|"; nocase; http_header; pcre:"/filename=/simH"; classtype:policy-violation; sid:1000004; rev:7;)



(the rule is nowhere near complete, it is simplified to be less prone to mistakes)

Unfortunatelly, the rule still does not work. I captured the traffic (on the same machine/interface that Snort was running) and verified that such packet is indeed there. When I let Snort analyze the traffic from this pcap file ('snort -A console -c /etc/snort/snort.conf -r /tmp/testdata5.pcap -l . -u snort'), the rule is fired on console correctly.



The rule is (in standard, sniffing mode) sometimes triggered as well (although never from this particular server I am testing).

What could be the cause of this? Snort is running in IDS mode (not inline) and is not dropping packets. LRO and GRO are disabled on network adapter. I have tried running Snort with '-k none' without any results.



I have attached small pcap sample of the traffic I'm trying to catch - this is enough to trigger the rule in replay mode, but didn't trigger when sniffing.

Thank you,
Pavel


<testdata5.pcap>------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics


Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________


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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!



------------------------------------------------------------------------------

See everything from the browser to the database with AppDynamics

Get end-to-end visibility with application monitoring from AppDynamics

Isolate bottlenecks and diagnose root cause in seconds.

Start your free trial of AppDynamics Pro today!

http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________



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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users



Please visit http://blog.snort.org to stay current on all the latest Snort news!


 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20130712/0148b487/attachment.html>


More information about the Snort-users mailing list