[Snort-users] http_inspect missing requests

James Lay jlay at ...13475...
Wed Feb 8 07:04:13 EST 2017


On Wed, 2017-02-08 at 12:39 +0100, Felix Erlacher wrote:
> Thanks for the help.
> All GET requests where processed in inline mode like you proposed. Is
> this because in IDS mode Snort works in post-ack inspection mode and
> in
> inline (IPS) mode it does pre-ack inspection?
> I couldn't find any information about this in the Snort manual.
> 
> But there are still some questions regarding this trace.
> You say that if packets are not ACKed, Snort will not look at them
> (if
> not in IPS mode).
> But if I put the same TCP payload in one segment (10GETonePanon.pcap)
> and feed it to Snort, the http_inspect stats show me 10 GET requests.
> But according to your last mail it shouldn't because the segment is
> not
> ACKed.
> (Again, I used the standard snort.conf from 2.9.9.0 in IDS mode with
> the
> -k none switch)
> 
> The same holds if I put every GET request in an individual packet,
> resulting in 10 TCP segments (10indivGETanon.pcap). http_inspect
> tells
> me it processed 10 GET requests altough none of the 10 packets was
> ACKed. (They even have all the same SEQ numbers.)
> 
> There is one difference betwee the two traces, though. The rule with
> sid
> 2013504 from the Emerging Threats ruleset looks for
> content:"APT-HTTP|2F|" in the http_header.
> It fires 5 alerts for the 10GETonePanon.pcap trace but 10 alerts for
> the
> 10indivGETanon.pcap trace. The payload can be found 10 times in both
> traces.
> 
> It would be great if someone could give me some insights on this.
> 
> greets
> 
> felix
> 
This is my experience as well when testing.  Especially interesting is
the single packet capture stats:
Packet I/O Totals:
   Received:            1
   Analyzed:            1 (100.000%)
    Dropped:            0 (  0.000%)
   Filtered:            0 (  0.000%)
Outstanding:            0 (  0.000%)
   Injected:            0
=======================================================================
========
Breakdown by protocol (includes rebuilt packets):
        Eth:            1 (100.000%)
       VLAN:            0 (  0.000%)
        IP4:            1 (100.000%)
       Frag:            0 (  0.000%)
       ICMP:            0 (  0.000%)
        UDP:            0 (  0.000%)
        TCP:            1 (100.000%)
      Total:            1

HTTP Inspect - encodings (Note: stream-reassembled packets included):
    POST methods:                         0         
    GET methods:                          10        
    HTTP Request Headers extracted:       10        
    HTTP Request Cookies extracted:       0         
    Post parameters extracted:            0         
    HTTP response Headers extracted:      0         
    HTTP Response Cookies extracted:      0         
    Unicode:                              0         
    Double unicode:                       0         
    Non-ASCII representable:              0         
    Directory traversals:                 0         
    Extra slashes ("//"):                 0         
    Self-referencing paths ("./"):        0         
    HTTP Response Gzip packets extracted: 0         
    Gzip Compressed Data Processed:       n/a       
    Gzip Decompressed Data Processed:     n/a       
    Http/2 Rebuilt Packets:               0         
    Total packets processed:              1    

One packet should not equal 10 HTTP GET's....something is amiss....I
think this might be a bug.
James
     
> On 03/02/17 23:06, Russ wrote:
> 
> > 
> > The final 3 GET requests were not acknowledged by the TCP server and so
> > weren't processed.  If you run in IPS mode you will see them get them
> > processed.  To enable IPS mode, make sure you have
> > 
> >     preprocessor normalize_tcp: ips
> > 
> > in your conf and add these args to your command line:
> > 
> >     --daq dump --daq-var load-mode=read-file -Q
> > 
> > The dump DAQ allows you to test inline mode with pcaps (it will create a
> > new pcap with only the packets allowed to pass); -Q enables inline mode;
> > and normalize_tcp: ips enables stream normalization.
> > 
> > On 2/3/17 1:27 PM, Felix Erlacher wrote:
> > 
> > > 
> > > Hi all,
> > > 
> > > I have a pcap trace containing HTTP traffic. I began to wonder because
> > > Snort did not trigger all alerts I was expecting. So I extracted the TCP
> > > stream in question and looked at it more closely. My impression is that
> > > for some reason the HTTP preprocessor is not parsing all GET requests.
> > > If I load this trace in Wireshark, than "follow TCP stream", it shows me
> > > 10 GET requests.
> > > If I use ngrep to manually inspect the trace, I count 10 GET requests as
> > > well.
> > > 
> > > But the HTTP Inspect preprocessor of Snort tells me it found only 7 GET
> > > requests?!
> > > What could possibly be the problem?
> > > 
> > > Some peculiarities of the trace:
> > > Heavy usage of HTTP/1.1 pipelining
> > > While Wireshark and the Snort DAQ tell me they processed 13 packets,
> > > HTTP inspect tells me it processed 17 packets.
> > > This trace contains checksum errors and a tcp RST in the last packet.
> > > 
> > > I am using Snort 2.9.9.0 with snort.conf from tarball and "-k none" switch.
> > > 
> > > I would be happy to share the trace, but for privacy reasons I don't
> > > want to do that on the list. In case someone wants to take a look, just
> > > drop me a mail.
> > > 
> > > thanks and greetings
> > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Snort-users mailing list
> > > 
Snort-users at 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!
> > >  to stay current on all the latest Snort news!
> > > 

> > 
> > 
> > 



> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Snort-users mailing list
> 
Snort-users at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20170208/b0012f45/attachment.html>


More information about the Snort-users mailing list