Re: Binary log capture looks incomplete.

[James Lay <jlay () slave-tothe-box net>]

Ah...flowbits and tag I'm not real familiar with, so I'll defer to the 
(much) smarter people in this group :)

James

On 2013-05-23 16:35, Shields, Joseph (NIH/NIEHS) [C] wrote:
> James,
>    My understanding from reading the Snort manual is that in the rule
> these settings affect logging:
> 1) flowbits:set,tagged;     Tells snort that the session should be
> logged when this rule is positive.
> 2) tag:session,0,packets,1000,seconds;      Tells snort to not limit
> the size (set to zero) and to log for up to 1000 seconds.
>
> I am not setting the dump type format, so it ought to use the default
> which I believe is tcpdump.
>
> I am now trying to run snort without the -b option and I have setup
> individual files for each rule by setting the logto option
> For example, logto:"/var/log/snort/logto/sid2000419.log";
>
> I don't have any hits yet to see if this is working.
>
> Brian
>
> -----Original Message-----
> From: James Lay [mailto:jlay () slave-tothe-box net]
> Sent: Thursday, May 23, 2013 6:21 PM
> To: snort-users () lists sourceforge net
> Subject: Re: [Snort-users] Binary log capture looks incomplete.
>
> 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!

------------------------------------------------------------------------------
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!