Re: http_inspect missing requests

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

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