Home page logo
/

snort logo Snort mailing list archives

Re: Binary log capture looks incomplete.
From: James Lay <jlay () slave-tothe-box net>
Date: Thu, 23 May 2013 16:21:25 -0600

Joseph,

How are you logging this...with:

output log_tcpdump: tcpdump.log

or

output unified2: filename unified

?

As I understand it, (someone please correct me if I'm way off) Snort 
will capture the packet (or re-assembled packets) that fired the rule.  
Snort won't capture the whole conversation or file.  For example, VRT 
rule 25513 will capture the packet(s) that match 
content:"application/octet-stream"; and content:"MZ";, but won't capture 
the entire file.  Hope that sheds some light on it.

James


On 2013-05-23 14:05, Shields, Joseph (NIH/NIEHS) [C] wrote:
I sent the below question to the user list yesterday but did not see
any replies to it. I think I have an idea about what is going on 
here.
I had my own rule to look for a specific event. In watching the
snort-sigs user list I saw last week a rule that looked like it might
be more effective, so I added it to the rule set. What I've noticed
when trying to look at the binary captures this week is that it looks
like the transmission is being restarted. I get the same beginning
sequence number for the internal computer showing up in the log file
capture. I think that what is happening is I have both rules tagged 
to
capture any hits (flowbits:set,tagged;
tag:session,0,packets,1000,seconds;). I think both rules are
triggering a binary capture for the same session and so the binary 
log
file is being written to essentially twice. I noticed today that I 
had
one session alert on three different rules. I can see from the 
capture
that I have the starting packet sequence number show up three times 
(I
had 3 different rules that alerted). I think this is causing me to 
not
get the complete file capture at all.

 The question is what to do about this? My main concern is to not 
miss
a network traffic of interest. I don't want to disable rules rules
because they may not all fire. (I'm thinking two rules may ensure the
most coverage. I've had cases where 1 rule will fire without the 
other
being triggered). I think it is possible to have Snort stop any
further rule testing if a rule gets triggered. That would be fine
(setup suggestions are welcomed). I am thinking to I could turn off
the binary log capture and use the "logto" option within each rule to
point it to a separate file (or folder to use)? I suppose it would be
a file much as what the binary capture does where multiple hits that
day would all end up in the same file.

 Here is how I start the snort monitoring process:

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

Brian

I SENT THIS
 SUBJECT: Binary log capture looks incomplete.

In examining a Snort session binary capture resulting from a rule
being triggered I noticed that the transfer was attempted 4 different
times. The amount of data being sent each time was longer before a
reset occurred. The HTTP session parameters noted a content length of
191K. It is clear the transfer was incomplete as the largest file 
size
I had to work with was about 24K. What I observed in looking at the
session packets is that the sequence numbers are not complete in
ascending order. Here is how I have the rule tagged in the rules file
so as to perform a capture.

flowbits:set,tagged; tag:session,0,packets,1000,seconds;

I am wondering if there is a problem in: 1) the logging being done by
Snort; 2) our mirrored tap is dropping packets; or 3) or if perhaps
the transfer was messed up for whatever reason so I do not need to do
anything. In looking at the sequence numbers I'm thinking a reset
should have occurred when the sequence number of the receiving system
went from 484 to 504 (snipett below from full list further down in
this message). Yet, the dump continued after 504 was received (no
reset). This has me tending to believe more data was sent (nothing
wrong with Snort and is why the logging continued) and very likely 
our
network tap (dropping packets) has a problem. I thought I would see
what others have seen and would recommend.


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

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 ]
AlienVault