Re: Binary log capture looks incomplete.

["Shields, Joseph (NIH/NIEHS) [C]" <joseph.shields () nih gov>]

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.

   TCP TTL:50 TOS:0x0 ID:64484 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10067 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10068 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64504 IpLen:20 DgmLen:1420 DF

I'm looking for advice about what to do now to make sure the 1st two concerns are not issues I need to deal with.

Here is a full list of the session sequence numbers .  I indented the dest system data that was receiving the download.

05/21-13:33:04.478230 (remainder  of line redacted)
TRANSFER START.
    TCP TTL:50 TOS:0x0 ID:64481 IpLen:20 DgmLen:1420 DF
RESTART
    TCP TTL:50 TOS:0x0 ID:64481 IpLen:20 DgmLen:1420 DF
    TCP TTL:50 TOS:0x0 ID:64482 IpLen:20 DgmLen:1420 DF
    TCP TTL:50 TOS:0x0 ID:64483 IpLen:20 DgmLen:1381 DF
TCP TTL:125 TOS:0x0 ID:10060 IpLen:20 DgmLen:40 DF
    TCP TTL:50 TOS:0x0 ID:64484 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10061 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10062 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64487 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64488 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64489 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10063 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10064 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64494 IpLen:20 DgmLen:1420 DF
RESTART
   TCP TTL:50 TOS:0x0 ID:64481 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64482 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64483 IpLen:20 DgmLen:1381 DF
   TCP TTL:50 TOS:0x0 ID:64484 IpLen:20 DgmLen:1420 DF
RESTART
   TCP TTL:50 TOS:0x0 ID:64481 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64482 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64483 IpLen:20 DgmLen:1381 DF
   TCP TTL:50 TOS:0x0 ID:64484 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10067 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10068 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64504 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10071 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64518 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10090 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10108 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10114 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64595 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64596 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10115 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64599 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64600 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64601 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10116 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10117 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64604 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10118 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10119 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64605 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64606 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64607 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64608 IpLen:20 DgmLen:1420 DF
   TCP TTL:50 TOS:0x0 ID:64612 IpLen:20 DgmLen:1420 DF
TCP TTL:125 TOS:0x0 ID:10124 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64619 IpLen:20 DgmLen:1242 DF
TCP TTL:125 TOS:0x0 ID:10126 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10127 IpLen:20 DgmLen:40 DF
TCP TTL:125 TOS:0x0 ID:10129 IpLen:20 DgmLen:40 DF
   TCP TTL:50 TOS:0x0 ID:64620 IpLen:20 DgmLen:40 DF
05/21-13:33:06.220462 (remainer of line redacted)
TCP TTL:125 TOS:0x0 ID:10130 IpLen:20 DgmLen:40 DF



Here are the HTTP session settings for the transfer:

48 54 54 50 2F 31 2E 31 20 32 30 30 20 4F 4B 0D  HTTP/1.1 200 OK.
0A 53 65 72 76 65 72 3A 20 6E 67 69 6E 78 2F 31  .Server: nginx/1
2E 30 2E 31 33 0D 0A 44 61 74 65 3A 20 54 75 65  .0.13..Date: Tue
2C 20 32 31 20 4D 61 79 20 32 30 31 33 20 31 37  , 21 May 2013 17
3A 33 32 3A 35 39 20 47 4D 54 0D 0A 43 6F 6E 74  :32:59 GMT..Cont
65 6E 74 2D 54 79 70 65 3A 20 61 70 70 6C 69 63  ent-Type: applic
61 74 69 6F 6E 2F 78 2D 6D 73 64 6F 77 6E 6C 6F  ation/x-msdownlo
61 64 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20  ad..Connection:
6B 65 65 70 2D 61 6C 69 76 65 0D 0A 50 72 61 67  keep-alive..Prag
6D 61 3A 20 70 75 62 6C 69 63 0D 0A 45 78 70 69  ma: public..Expi
72 65 73 3A 20 54 75 65 2C 20 32 31 20 4D 61 79  res: Tue, 21 May
20 32 30 31 33 20 31 37 3A 33 33 3A 30 34 20 47   2013 17:33:04 G
4D 54 0D 0A 43 61 63 68 65 2D 43 6F 6E 74 72 6F  MT..Cache-Contro
6C 3A 20 6D 75 73 74 2D 72 65 76 61 6C 69 64 61  l: must-revalida
74 65 2C 20 70 6F 73 74 2D 63 68 65 63 6B 3D 30  te, post-check=0
2C 20 70 72 65 2D 63 68 65 63 6B 3D 30 0D 0A 43  , pre-check=0..C
61 63 68 65 2D 43 6F 6E 74 72 6F 6C 3A 20 70 72  ache-Control: pr
69 76 61 74 65 0D 0A 43 6F 6E 74 65 6E 74 2D 44  ivate..Content-D
69 73 70 6F 73 69 74 69 6F 6E 3A 20 61 74 74 61  isposition: atta
63 68 6D 65 6E 74 3B 20 66 69 6C 65 6E 61 6D 65  chment; filename
3D 22 63 6F 6E 74 61 63 74 73 2E 65 78 65 22 0D  ="contacts.exe".
0A 43 6F 6E 74 65 6E 74 2D 54 72 61 6E 73 66 65  .Content-Transfe
72 2D 45 6E 63 6F 64 69 6E 67 3A 20 62 69 6E 61  r-Encoding: bina
72 79 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67  ry..Content-Leng
74 68 3A 20 31 39 31 32 30 35 0D 0A 0D 0A 4D 5A  th: 191205....MZ


Brian

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