[Snort-devel] Fwd: Snort blocking connection but not logging the drop

Cody Brugh cbrugh at ...2499...
Tue May 13 10:36:28 EDT 2014


Attached is the info you requested.... I included tcpdump from a server
successfully connecting to the API with snort OFF.

Also is attached is the PCAP for when snort is ON and the packet being
dropped.

Let me know the next steps.



On Tue, May 13, 2014 at 10:19 AM, Cody Brugh <cbrugh at ...2499...> wrote:

> Quick question on the "passive mode"... we use a bypass switch that checks
> snort heartbeat... if I set snort to passive mode the bypass switch doesn't
> flow traffic through the snort box at all.  This means the packet captures
> for the passive mode will need ran from a server itself, is that fine?
>
>
>
> On Tue, May 13, 2014 at 9:51 AM, Russ Combs (rucombs) <rucombs at ...3461...>wrote:
>
>>
>>  ------------------------------
>> *From:* Cody Brugh [cbrugh at ...2499...]
>> *Sent:* Monday, May 12, 2014 6:30 PM
>>
>> *To:* Russ Combs (rucombs)
>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but not
>> logging the drop
>>
>>   Ok, I disabled everything (rules, normalizations, pre-processors,
>> dynamic rules) and still not able to connect  with snort in-line.
>>
>>  Attached is my snort.conf to make sure I got everything... At this point
>> do you believe this is a bug?  Would the alpha snort version maybe work?
>>
>>  * Not clear what is going on, but with everything disabled, changing
>> versions shouldn't make a difference.
>>
>>  Please send:
>>
>>  -- Snort configure line (./configure ... )
>> -- Snort command line
>> -- Snort conf
>> -- pcap with one successful connection while running Snort in passive mode
>> -- pcap with one unsuccessful connection while running Snort in inline
>> mode
>> -- snort-passive.log and snort-inline.log
>>
>>  Based on the earlier emails, the commands to generate the logs are
>> these:
>>
>>      snort -A cmg --daq afpacket -i eth2:eth3 --daq-var
>> buffer_size_mb=2048MB \
>>          -c /etc/snort/snort.conf &> snort-passive.log
>>
>>      snort -A cmg --daq afpacket -i eth2:eth3 -Q --daq-var
>> buffer_size_mb=2048MB \
>>         -c /etc/snort/snort.conf &> snort-inline.log
>>
>>  The pcaps should be captured for each of the above runs.
>>
>>  You can send directly to me if anything is sensitive.
>>
>>  Thanks
>> Russ
>>
>>   On Mon, May 12, 2014 at 6:19 PM, Russ Combs (rucombs) <
>> rucombs at ...3461...> wrote:
>>
>>>
>>>  ------------------------------
>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>
>>> *Sent:* Monday, May 12, 2014 6:11 PM
>>> *To:* Russ Combs (rucombs)
>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but not
>>> logging the drop
>>>
>>>   Would a pre-processor engine be blocking but not logging?  When you
>>> say disable things are you talking about removing pre-processing engines or
>>> other?
>>>
>>>  * The are two ways packets get blocked: rules and normalization.  If
>>> those aren't indicated, it could be a bug or it could be something else
>>> entirely, like your Snort environment.  To isolate, first disable all your
>>> rules.  Then disable all normalizations.  Then start disabling
>>> preprocessors.
>>>
>>>
>>> On Mon, May 12, 2014 at 6:06 PM, Russ Combs (rucombs) <rucombs at ...3461...
>>> > wrote:
>>>
>>>>
>>>>  ------------------------------
>>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>> *Sent:* Monday, May 12, 2014 4:32 PM
>>>>
>>>> *To:* Russ Combs (rucombs)
>>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but not
>>>> logging the drop
>>>>
>>>>    Running in passive mode I see no alerts/blocks for this specefic
>>>> API command... Also note that the API command is running without a problem
>>>> now that snort is in passive mode.
>>>>
>>>>  Something inside of snort is catching it but I cannot figure out
>>>> what... would this be like a preprocessor or dynamic rules or something?
>>>>
>>>>  * If there is something in Snort blocking your session, then the
>>>> output should indicate that.  At this point I would try disabling things
>>>> systematically to isolate it.
>>>>
>>>>
>>>> On Mon, May 12, 2014 at 4:18 PM, Russ Combs (rucombs) <
>>>> rucombs at ...3461...> wrote:
>>>>
>>>>>
>>>>>  ------------------------------
>>>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>>> *Sent:* Monday, May 12, 2014 4:11 PM
>>>>>
>>>>> *To:* Russ Combs (rucombs)
>>>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but not
>>>>> logging the drop
>>>>>
>>>>>   I now see my other alerts/drops coming in on the console, however
>>>>> when I run the API command I get nothing from a alert/drop status...  What
>>>>> else could be blocking it?
>>>>>
>>>>>  * The log you sent shows no blocks, so either it isn't configured the
>>>>> same or it isn't getting the same traffic as before.  Or maybe you have
>>>>> more than one Snort running?  In any case, the output you sent indicates
>>>>> Snort is not the problem.
>>>>>
>>>>> What happens if you run in passive mode by just removing the -Q?  Do
>>>>> you get alerts?  Blocks?
>>>>>
>>>>>
>>>>> On Mon, May 12, 2014 at 4:09 PM, Cody Brugh <cbrugh at ...2499...> wrote:
>>>>>
>>>>>> Attached.
>>>>>>
>>>>>>
>>>>>> On Mon, May 12, 2014 at 4:05 PM, Russ Combs (rucombs) <
>>>>>> rucombs at ...3461...> wrote:
>>>>>>
>>>>>>>
>>>>>>>  ------------------------------
>>>>>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>>>>> *Sent:* Monday, May 12, 2014 3:59 PM
>>>>>>>
>>>>>>> *To:* Russ Combs (rucombs)
>>>>>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>>>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but not
>>>>>>> logging the drop
>>>>>>>
>>>>>>>    Alright, I done that and run my command but see nothing...
>>>>>>> looking at the console and /var/log/messages...
>>>>>>>
>>>>>>> /usr/local/bin/snort -M -A console -q --daq afpacket -i eth2:eth3 -Q
>>>>>>> --daq-var buffer_size_mb=2048MB -c /etc/snort/snort.conf
>>>>>>>
>>>>>>>  * Ok, do this and send the whole output file (snort.log) after
>>>>>>> stopping with ctl-c:
>>>>>>>
>>>>>>> /usr/local/bin/snort -A cmg --daq afpacket -i eth2:eth3 -Q --daq-var
>>>>>>> buffer_size_mb=2048MB -c /etc/snort/snort.conf &> snort.log
>>>>>>>
>>>>>>>  This is very odd
>>>>>>>
>>>>>>>
>>>>>>> On Mon, May 12, 2014 at 3:24 PM, Russ Combs (rucombs) <
>>>>>>> rucombs at ...3461...> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>  ------------------------------
>>>>>>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>>>>>> *Sent:* Monday, May 12, 2014 3:01 PM
>>>>>>>>
>>>>>>>> *To:* Russ Combs (rucombs)
>>>>>>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>>>>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but
>>>>>>>> not logging the drop
>>>>>>>>
>>>>>>>>   That's the thing, I don't know what rule is being hit as it
>>>>>>>> doesn't show in sborby. Is there a way to show the rule that was triggered?
>>>>>>>>  Maybe that is done with the perf monitoring stuff?
>>>>>>>>
>>>>>>>>  * I can't help you with Snorby.  Since this is easy for you to
>>>>>>>> reproduce, I suggest running Snort from the command line directly, no
>>>>>>>> scripts, and no -M option.  Add -A cmg -q to your command line.  You will
>>>>>>>> see the alert.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 12, 2014, at 2:59 PM, "Russ Combs (rucombs)" <
>>>>>>>> rucombs at ...3461...> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>  ------------------------------
>>>>>>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>>>>>> *Sent:* Monday, May 12, 2014 2:53 PM
>>>>>>>> *To:* Russ Combs (rucombs)
>>>>>>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>>>>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but
>>>>>>>> not logging the drop
>>>>>>>>
>>>>>>>>   I just disabled the tcp normalize and cleaned up some
>>>>>>>> pre-processeors that I don't need, however I am still being dropped when
>>>>>>>> trying to connect to the API with snort ON.  Attached are the stats from a
>>>>>>>> quick run where I tried to connect 4-5 times.  Let me know if you see
>>>>>>>> something or other suggestions.
>>>>>>>>
>>>>>>>> * You have 1 alert, 2 blocks, 1 blacklisted, and 2 injects.  I
>>>>>>>> would start by changing the rule that is firing from drop to alert.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Cody
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, May 12, 2014 at 1:05 PM, Russ Combs (rucombs) <
>>>>>>>> rucombs at ...3461...> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>  ------------------------------
>>>>>>>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>>>>>>> *Sent:* Monday, May 12, 2014 12:53 PM
>>>>>>>>>
>>>>>>>>> *To:* Russ Combs (rucombs)
>>>>>>>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>>>>>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but
>>>>>>>>> not logging the drop
>>>>>>>>>
>>>>>>>>>   What all is the normalizer used for?  Will turning it off make
>>>>>>>>> me vulnerable?
>>>>>>>>>
>>>>>>>>>  * The normalizer does various scrubbing and blocking to improve
>>>>>>>>> detection.  You need to assess your security position with or without it.
>>>>>>>>> For details on the normalizer, check here:
>>>>>>>>> http://manual.snort.org/node168.html.
>>>>>>>>>
>>>>>>>>>  Just trying to understand what that mechanism does.
>>>>>>>>>
>>>>>>>>>  Thanks,
>>>>>>>>> Cody
>>>>>>>>>
>>>>>>>>> On May 12, 2014, at 12:02 PM, "Russ Combs (rucombs)" <
>>>>>>>>> rucombs at ...3461...> wrote:
>>>>>>>>>
>>>>>>>>>   The normalizer is blocking packets:
>>>>>>>>>
>>>>>>>>>              tcp::block: 272
>>>>>>>>>
>>>>>>>>> You can prevent that by commenting out the normalize_tcp line from
>>>>>>>>> your conf.
>>>>>>>>>
>>>>>>>>> You can debug it a little further by enabling all preprocessor
>>>>>>>>> rules by adding / uncommenting them in your conf or by adding this to your
>>>>>>>>> conf:
>>>>>>>>>
>>>>>>>>>     config autogenerate_preprocessor_decoder_rules
>>>>>>>>>
>>>>>>>>> Then you should see why the normalizer is blocking.  When I do
>>>>>>>>> that with the pcap you sent I see a bad TCP reset.
>>>>>>>>>
>>>>>>>>>  ------------------------------
>>>>>>>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>>>>>>> *Sent:* Monday, May 12, 2014 11:52 AM
>>>>>>>>> *To:* Russ Combs (rucombs)
>>>>>>>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>>>>>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but
>>>>>>>>> not logging the drop
>>>>>>>>>
>>>>>>>>>   Attached is the shutdown stats.  Let me know what you
>>>>>>>>> find/suggest.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Cody
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, May 12, 2014 at 11:41 AM, Russ Combs (rucombs) <
>>>>>>>>> rucombs at ...3461...> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  ------------------------------
>>>>>>>>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>>>>>>>> *Sent:* Monday, May 12, 2014 11:18 AM
>>>>>>>>>>
>>>>>>>>>> *To:* Russ Combs (rucombs)
>>>>>>>>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>>>>>>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but
>>>>>>>>>> not logging the drop
>>>>>>>>>>
>>>>>>>>>>    How do I gather those stats?  Are you looking for this?
>>>>>>>>>> http://manual.snort.org/node20.html
>>>>>>>>>>
>>>>>>>>>>  * Not those.  Do a clean start, run your traffic, and then stop
>>>>>>>>>> Snort or give it a usr1 signal and check the output.  Check console or
>>>>>>>>>> syslog depending on how you run.
>>>>>>>>>>
>>>>>>>>>>  Thanks,
>>>>>>>>>> Cody
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, May 12, 2014 at 11:05 AM, Russ Combs (rucombs) <
>>>>>>>>>> rucombs at ...3461...> wrote:
>>>>>>>>>>
>>>>>>>>>>>  What are your shutdown / usr1 stats?  Do they show normalizer
>>>>>>>>>>> blocks?
>>>>>>>>>>>
>>>>>>>>>>>  ------------------------------
>>>>>>>>>>> *From:* Cody Brugh [cbrugh at ...2499...]
>>>>>>>>>>> *Sent:* Monday, May 12, 2014 10:29 AM
>>>>>>>>>>> *To:* Russ Combs (rucombs)
>>>>>>>>>>> *Cc:* Joel Esler (jesler); snort-devel at lists.sourceforge.net
>>>>>>>>>>>
>>>>>>>>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but
>>>>>>>>>>> not logging the drop
>>>>>>>>>>>
>>>>>>>>>>>    Can you confirm you received my PCAP file?  I would really
>>>>>>>>>>> like to get this issue resolved so I can work with their API.
>>>>>>>>>>>
>>>>>>>>>>> Let me know the status please.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, May 9, 2014 at 9:02 AM, Cody Brugh <cbrugh at ...2499...>wrote:
>>>>>>>>>>>
>>>>>>>>>>>>  Attached is the pcap of the stamps.com packet capture... can
>>>>>>>>>>>> someone check and see what I should do?
>>>>>>>>>>>>
>>>>>>>>>>>>  Thanks,
>>>>>>>>>>>> Cody
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, May 9, 2014 at 8:19 AM, Russ Combs (rucombs) <
>>>>>>>>>>>> rucombs at ...3461...> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  ------------------------------
>>>>>>>>>>>>> *From:* Joel Esler (jesler)
>>>>>>>>>>>>> *Sent:* Thursday, May 08, 2014 8:51 PM
>>>>>>>>>>>>> *To:* Cody Brugh
>>>>>>>>>>>>> *Cc:* snort-devel at lists.sourceforge.net
>>>>>>>>>>>>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection
>>>>>>>>>>>>> but not logging the drop
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Can you send your configuration file, and a packet capture
>>>>>>>>>>>>> of the session?
>>>>>>>>>>>>>
>>>>>>>>>>>>>  * Can you also send your usr1 / shutdown stats?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Joel Esler
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>> On May 8, 2014, at 20:49, "Cody Brugh" <cbrugh at ...2499...>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Our dev team is trying to work with stamps.com API however
>>>>>>>>>>>>> our in-line snort box is blocking the return connection for unknown
>>>>>>>>>>>>> reasons.  When I turn off snort the connection flows perfectly.  Looking at
>>>>>>>>>>>>> snorby I see no event of the connection being dropped.  I've included the
>>>>>>>>>>>>> command we are running from a internal server that is behind the snort.  I
>>>>>>>>>>>>> also included the tcpdump from this same server for the connection.
>>>>>>>>>>>>>
>>>>>>>>>>>>> wget https://216.52.211.91/label/health.aspx
>>>>>>>>>>>>> --2014-05-08 20:37:33--
>>>>>>>>>>>>> https://216.52.211.91/label/health.aspx
>>>>>>>>>>>>> Connecting to 216.52.211.91:443... connected.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 20:37:33.443962 IP 10.2.2.1.52661 > 216.52.211.91.443: Flags
>>>>>>>>>>>>> [F.], seq 3298140140, ack 2463587275, win 8208, options [nop,nop,TS val
>>>>>>>>>>>>> 2824990869 ecr 3731400338], length 0
>>>>>>>>>>>>> 20:37:33.444478 IP 216.52.211.91.443 > 10.2.2.1.52661: Flags
>>>>>>>>>>>>> [R.], seq 1, ack 1, win 8208, length 0
>>>>>>>>>>>>> 20:37:33.989510 IP 10.2.2.1.59800 > 216.52.211.91.443: Flags
>>>>>>>>>>>>> [S], seq 3306929108, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS
>>>>>>>>>>>>> val 2824990923 ecr 0], length 0
>>>>>>>>>>>>> 20:37:34.071548 IP 216.52.211.91.443 > 10.2.2.1.59800: Flags
>>>>>>>>>>>>> [S.], seq 361712399, ack 3306929109, win 4140, options [mss 1380,nop,wscale
>>>>>>>>>>>>> 3,nop,nop,TS val 3731482846 ecr 2824990923,sackOK,eol], length 0
>>>>>>>>>>>>> 20:37:34.071610 IP 10.2.2.1.59800 > 216.52.211.91.443: Flags
>>>>>>>>>>>>> [.], ack 1, win 8208, options [nop,nop,TS val 2824990932 ecr 3731482846],
>>>>>>>>>>>>> length 0
>>>>>>>>>>>>> 20:37:34.071750 IP 10.2.2.1.59800 > 216.52.211.91.443: Flags
>>>>>>>>>>>>> [P.], ack 1, win 8208, options [nop,nop,TS val 2824990932 ecr 3731482846],
>>>>>>>>>>>>> length 139
>>>>>>>>>>>>> 20:37:34.154367 IP 216.52.211.91.443 > 10.2.2.1.59800: Flags
>>>>>>>>>>>>> [.], ack 140, win 517, options [nop,nop,TS val 3731482928 ecr 2824990932],
>>>>>>>>>>>>> length 1368
>>>>>>>>>>>>> 20:37:34.154462 IP 216.52.211.91.443 > 10.2.2.1.59800: Flags
>>>>>>>>>>>>> [.], ack 140, win 517, options [nop,nop,TS val 3731482928 ecr 2824990932],
>>>>>>>>>>>>> length 1368
>>>>>>>>>>>>> 20:37:34.154490 IP 10.2.2.1.59800 > 216.52.211.91.443: Flags
>>>>>>>>>>>>> [.], ack 2737, win 7877, options [nop,nop,TS val 2824990940 ecr
>>>>>>>>>>>>> 3731482928], length 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> 20:37:44.153373 IP 216.52.211.91.443 > 10.2.2.1.59800: Flags
>>>>>>>>>>>>> [R.], seq 4233:4288, ack 140, win 534, length 55
>>>>>>>>>>>>>
>>>>>>>>>>>>>  any help or suggestions would be great, I would like to
>>>>>>>>>>>>> disable the rule that is blocking this connection but like I said I cannot
>>>>>>>>>>>>> see which rule blocked it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> Is your legacy SCM system holding you back? Join Perforce May
>>>>>>>>>>>>> 7 to find out:
>>>>>>>>>>>>> • 3 signs your SCM is hindering your productivity
>>>>>>>>>>>>> • Requirements for releasing software faster
>>>>>>>>>>>>> • Expert tips and advice for migrating your SCM now
>>>>>>>>>>>>> http://p.sf.net/sfu/perforce
>>>>>>>>>>>>>
>>>>>>>>>>>>>  _______________________________________________
>>>>>>>>>>>>> Snort-devel mailing list
>>>>>>>>>>>>> Snort-devel at lists.sourceforge.net
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/snort-devel
>>>>>>>>>>>>> Archive:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please visit http://blog.snort.org for the latest news about
>>>>>>>>>>>>> Snort!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20140513/1f7dbfed/attachment.html>
-------------- next part --------------
Snort configure = ./configure


[root at snort snort]# snort --version

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.6.1 GRE (Build 56) 
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
           Copyright (C) 2014 Cisco and/or its affiliates. All rights reserved.
           Copyright (C) 1998-2013 Sourcefire, Inc., et al.
           Using libpcap version 1.0.0
           Using PCRE version: 7.8 2008-09-05
           Using ZLIB version: 1.2.3


-------------- next part --------------
A non-text attachment was scrubbed...
Name: snort.conf
Type: application/octet-stream
Size: 22595 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20140513/1f7dbfed/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stamps_pcap_ON.pcap
Type: application/octet-stream
Size: 24403 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20140513/1f7dbfed/attachment-0001.obj>
-------------- next part --------------

10:32:20.741763 IP 10.2.2.1.36977 > 216.52.211.91.443: Flags [S], seq 2330121195, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2864565085 ecr 0], length 0
10:32:20.823573 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [S.], seq 3864553535, ack 2330121196, win 4140, options [mss 1380,nop,wscale 3,nop,nop,TS val 4127169600 ecr 2864565085,sackOK,eol], length 0
10:32:20.823628 IP 10.2.2.1.36977 > 216.52.211.91.443: Flags [.], ack 1, win 8208, options [nop,nop,TS val 2864565094 ecr 4127169600], length 0
10:32:20.826374 IP 10.2.2.1.36977 > 216.52.211.91.443: Flags [P.], ack 1, win 8208, options [nop,nop,TS val 2864565094 ecr 4127169600], length 139
10:32:20.908581 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [.], ack 140, win 517, options [nop,nop,TS val 4127169685 ecr 2864565094], length 1368
10:32:20.908660 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [.], ack 140, win 517, options [nop,nop,TS val 4127169685 ecr 2864565094], length 1368
10:32:20.908686 IP 10.2.2.1.36977 > 216.52.211.91.443: Flags [.], ack 2737, win 7876, options [nop,nop,TS val 2864565102 ecr 4127169685], length 0
10:32:20.908843 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [.], ack 140, win 517, options [nop,nop,TS val 4127169685 ecr 2864565094], length 1368
10:32:20.908862 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [P.], ack 140, win 517, options [nop,nop,TS val 4127169685 ecr 2864565094], length 128
10:32:20.908890 IP 10.2.2.1.36977 > 216.52.211.91.443: Flags [.], ack 4105, win 8208, options [nop,nop,TS val 2864565102 ecr 4127169685], length 0
10:32:20.909709 IP 10.2.2.1.36977 > 216.52.211.91.443: Flags [P.], ack 4233, win 8208, options [nop,nop,TS val 2864565102 ecr 4127169685], length 314
10:32:20.990998 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [.], ack 454, win 574, options [nop,nop,TS val 4127169768 ecr 2864565102], length 0
10:32:20.994557 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [P.], ack 454, win 574, options [nop,nop,TS val 4127169771 ecr 2864565102], length 47
10:32:20.995081 IP 10.2.2.1.36977 > 216.52.211.91.443: Flags [P.], ack 4280, win 8208, options [nop,nop,TS val 2864565111 ecr 4127169771], length 335
10:32:21.076507 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [.], ack 789, win 616, options [nop,nop,TS val 4127169853 ecr 2864565111], length 0
10:32:21.086614 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [P.], ack 789, win 616, options [nop,nop,TS val 4127169864 ecr 2864565111], length 348
10:32:21.086642 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [F.], seq 4628, ack 789, win 616, options [nop,nop,TS val 4127169864 ecr 2864565111], length 0
10:32:21.086674 IP 10.2.2.1.36977 > 216.52.211.91.443: Flags [.], ack 4629, win 8164, options [nop,nop,TS val 2864565120 ecr 4127169864], length 0
10:32:21.092198 IP 10.2.2.1.36977 > 216.52.211.91.443: Flags [F.], seq 789, ack 4629, win 8208, options [nop,nop,TS val 2864565120 ecr 4127169864], length 0
10:32:21.173676 IP 216.52.211.91.443 > 10.2.2.1.36977: Flags [.], ack 790, win 616, options [nop,nop,TS val 4127169951 ecr 2864565120], length 0


More information about the Snort-devel mailing list