Home page logo

snort logo Snort mailing list archives

Re: Snort only partially alerting
From: Frank Calone <fc10011001 () gmail com>
Date: Wed, 26 Jun 2013 16:31:29 -0400

Fellow Snorters,
    After much testing and with special thanks to Joel, I have an update on
the problem I had with Snort only partially alerting.  I was unaware during
the first few weeks of running snort that the packet datagram was being
truncated for some reason, but not in all cases.  We had an older Snort app
that was flagging alerts which our new server was not.  I was running snort
in the background with this command:

/usr/sbin/snort -A fast -d -D -i p1p1 -u snort -g snort -c
/etc/snort/snort.conf -l /var/log/snort -G 3

I suspect this message in the "messages" log folder (This is a CENTOS
box) may have been tied to the truncating error:

Jun 24 17:20:04 security1 rsyslogd-2177: imuxsock begins to drop messages
from pid 10279 due to rate-limiting

I started running Snort in the foreground as part of my testing.  Then I
received this error message:

 (snort_decoder) WARNING: IP dgm len > captured len

I performed binary captures at the same time while doing an Internet
download to compare results using TCPDUMP and Snort as follows (the
IP below is fake.  it represents my PC's address):

 snort -l ./logall -b -i p1p1 src or dst

tcpdump -i p1p1 -N -w tcpdump.jun26.v1.pcap src or dst

Doing a playback with snort -dvr showed clearly that the snort log
capture had a problem.  Joel recommended starting snort with an option to
force the capture length.  This then resulted in normal looking binary
captures and to my delight, an alert showed up when I tested an Internet
download (that a rule I have should detect)!  The fix was using -P on the
command line, here is how I start it now:

/usr/sbin/snort -A fast -d -D -P 9000 -i p1p1 -u snort -g snort -c
/etc/snort/snort.conf -l /var/log/snort -G 3

The default packet capture length is 1514, though for some reason I wasn't
even getting that.  This override has for the moment resolved my problem!!!
I would highly recommend starting Snort in the foreground on occasion just
to see if there are error messages you may not be aware of.    Now I can
finally get into doing the real work...Yeah!...oh no, I'm afraid of all the
work this is going to bring about.  Guess I'll be working late tonight!!!


On Wed, Jun 19, 2013 at 2:14 PM, James Lay <jlay () slave-tothe-box net> wrote:

Hi again Frank.

I would absolutely do the below:

turn up some kind of sniffer on our CentOS box to see what is being passed
to it on that interface, paying attention to the datagram sizes.

If we have a hardware issue, nothing else is going to work well ;)  After
verifying good hardware, then I'd do the repost to the mailing list.  I'd
post the rules, the output of snort when you find one that slipped by (run
it in the foreground then ctrl-c to get the info).  If you can get a small
packet capture ready just in case one of the dev's wants it offline that
would help.  Hope that works out Frank.


On 2013-06-19 10:54, Frank Calone wrote:


   I do have the full rules list as I have downloaded it and  have
pulled out some Java related ones to use on our Appliance with Snort
on it.  It already flagged one nice item!   In my testing I even
have used the exact same rule for the exe alerting on the appliance,
so I really dont see where doing anything with the rules will help me

at this time.  The two rules I show below are very simple and just
looking for plain text.  I will look into the archive discussions to
see what I can find about logging.  I want to wait on that though
until I just get the alerting to work.  No need to worry about
logging if the alerts are being missed.  That is a good tip though
and I will look though the last couple of months archives.  So, at
this time you would agree I have these options:
1) turn up some kind of sniffer on our CentOS box to see what is being
passed to it on that interface, paying attention to the datagram
2) contact the Snort development team asking for help.
3) Repost this message again to the user list (how much of the
4) other options you may be thinking about????


On Wed, Jun 19, 2013 at 12:41 PM, James Lay <jlay () slave-tothe-box net
[5]> wrote:

Ahhh...ok youre wanting to do a full packet capture once the rules

fire...gotcha.  Three things I would do:

Download both the latest snort rules and emerging threats rules,
extract them into a dir, and grep for exe..there are a bunch of
rules identifying executables and you can use those to your
advantage and tweaking.

Search the Snort mailing list archive to include last month...Im

certain there was a discussion that hit upon full captures using
snort when it fires on certain alerts.

Lastly, if the mailing list archive doesnt give a solution, post the
below info to the group (scrub/obfuscate the real IPs however)...the
Sourcefire Engineers should have an answer on why this isnt working

(it looks good to me and should be working correctly).

Thanks Frank...hope this helps.


On 2013-06-19 10:07, Frank Calone wrote:

   I do appreciate your thoughts on this.  The engine is very
current (  Im running CentOS and have 4 processors and a

total of 4 GB memory.  I have none of the distribution rules
loaded.  I am only running 2 rules looking for exes.  The

as I understand it was only to do packet captures for the session
was "tagged" due to an alert.     So, here is the startup

/usr/sbin/snort -A fast -d -D -i p1p1 -u snort -g snort -c
 -l /var/log/snort2 -G 1

Here are the 2 rules:

alert tcp  $EXTERNAL_NET !20 -> $HOME_NET any (msg:"Snort_Windows
loaded [not DOS mode] not recognized mirror"; content:"This
cannot be ru
n in DOS mode"; logto:"/var/log/snort/logto/**sid3000000.log";
 ; tag:session,0,packets,1000,**seconds; sid:3000000; rev:5;)

alert tcp $EXTERNAL_NET !20 -> $HOME_NET any (msg:"Snort_Win32 exe
ded [Win32 req]"; content:"This program must be run under Win32";
g/snort/logto/sid3000001.log"; flowbits:set,tagged;
 econds; sid:3000001; rev:5;)

I have been unable to get the "logto" option to work.  I realize
manual says it will not work when the startup command is set to
logging.  This is just a leftover from various testing I have
doing with the logging.  My understanding is that the flowbits
tagged   causes snort to say this session needs to be logged
when an
alert occurs.  The tab session, 0 , packets, 1000, seconds
is causing the session (all packets) to be captured in its
for up to 1000 seconds is necessary.  This has worked when we
hits, though on large binary captures (in the 50 MB sizes I am not
convinced I am getting everything.  I say this because the html
header info notes the "content size".  So I am able to determine
much was captured.  Smaller file sizes this has worked fine.
ones I usually dont get the exact value noted.  Im noting this

so you can see what we are trying to do.  The bigger problem is
getting the alert at all.  As you can see our testing is very
looking for plain text.

Our network guy supposedly put a network sniffer on our tap last
and he said that the mirror looks to be working fine.  Full
are showing up.  I suppose I could try to run wireshark on our
system to see what it sees coming in.  If there is a way to

the pcap component of Snort to do this, please do let me know how
would run it to see what is showing up to Snort.  Based on what
network guy has just told us, I am lead to believe there is a
in the way our Snort server is handling the data stream.  I was
using 2 rules and yet it only occasionally flags the exes.  I was

doing a binary capture on all of the packets, just the specific
sessions that alerted.  I feel like I am at wits end as to what
going wrong here.  I have performance monitoring turned on and
as I can see the system is usually 90% idle and memory usage
gets above 250 MB.  I setup stream5 memcap to 1 GB.  Im

my head as to why then the datagram length is being truncated.  I
appreciate whatever suggestions you might have on this.  It seems
like what I am trying to do ought to work.

 Yesterday I even removed the session tagging in the rule to just
the Snort application to alert on everything with no extra
(see rules below).  I tried just 2 rules with one being even
(going to the youtube web site, I replaced my PCs IP address with

57.n.n.n one you see in the rule below for non-displosure
requirements).  Every time I refreshed my web page for youtube
alerts worked just fine.  When I downloaded putty.exe my new
server never alerted and yet our IBM appliance with Snort alerted
and every time.  Im ready to pull my hair out.

alert tcp EXTERNAL_NET any -> $HOME_NET any (msg:"Snort_DOS exe
downloaded [DOS req]"; content:"This program cannot be run in DOS
mode"; sid:3000001; rev:5;)

alert tcp any -> $EXTERNAL_NET any (msg:"Youtube";
content:"www.youtube.com [1] [1]"; sid:1999987;)


On Wed, Jun 19, 2013 at 11:07 AM, James Lay
<jlay () slave-tothe-box net [2]
[2]> wrote:

On 2013-06-19 08:44, Frank Calone wrote:

   Thanks for the tips.   I have looked through the
manual.  Ive also used the site to search for specific

such.  I look at all the user group postings now for well
over a
month (since we first tried using Snort).  I just am not a
what you guys are doing.  The manual says Snort can do
capture of everything.  When I turned that on, that is when
saw the
problem (error message showing up).  I did not get that error
in the syslog when I was running snort the other way (as the
recommends starting it).  Yet, this looks to explain well
randomness of my hits.  We have an appliance that monitors
as its
main purpose, but it also has a snort engine that we have been
using.  We look for exes and it does a good job of that.

problem is it does not log at all.  We are wanting to log
so we
pull the exe out, then can do MD5,AV Totals, and other tests
determine if it is malicious.
   This other appliance then tells me what I ought to be
on.  Yet, I only get an occasional hit.  If the packets are
complete with payload (datagram issue), that would explain my
problem.  I am not convinced our network tap is giving me
though my boss thinks it is.  So, when I turned up full
yesterday with Snort, I could see I was mostly just getting
header.  What I dont know here is whether Snort itself is

the packets or if it is the network appliance that is giving
tap.  I really think this is the heart of my issue and I need
figure out which is the problem.  So when you suggest a pcap
I am presuming you are suggesting using a networking appliance
other tool to see what I am getting on the wire correct?

some other setting within Snort that I need to be using to do
this is

Hi Frank,

I can totally see where doing a full packet capture using snort
would cause issues..its busy logging packets instead of doing

IDS job.  I would suggest using tcpdump or tshark to do a full
packet capture off the tap (maybe just plug in a laptop running
linux and either of the above) for an hour and see if you get
data.  Id also recommend making sure the Snort engine is up to

as well as the rulesets.  I would not use Snort as a full
capture plus IDS at the same time.  Hope that helps.


[1] http://www.youtube.com/ [3]
[2] mailto:jlay () slave-tothe-box **net <jlay () slave-tothe-box net> [4]

[1] http://www.youtube.com/
[2] mailto:jlay () slave-tothe-box **net <jlay () slave-tothe-box net>
[3] http://www.youtube.com/
[4] mailto:jlay () slave-tothe-box **net <jlay () slave-tothe-box net>
[5] mailto:jlay () slave-tothe-box **net <jlay () slave-tothe-box net>

This SF.net email is sponsored by Windows:

Build for Windows Store.

Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
Snort-users list archive:

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]