[Snort-devel] HTTP preprocessor: TCP retransmissions of requests body causes (incorrect) alerts

Bram bram-fabeg at ...3414...
Tue Sep 3 13:44:35 EDT 2013


Hi,


I'm using snort 2.9.5.3 compiled without patches and with -O0.

I just retested it by downloading the dump (from the mailinglist  
archve) and by copying the config and I can reproduce this without  
problem..

snort version:

$ snort --version

    ,,_     -*> Snort! <*-
   o"  )~   Version 2.9.5.3 GRE (Build 132)
    ''''    By Martin Roesch & The Snort Team:  
http://www.snort.org/snort/snort-team
            Copyright (C) 1998-2013 Sourcefire, Inc., et al.
            Using libpcap version 1.3.0
            Using PCRE version: 8.32 2012-11-30
            Using ZLIB version: 1.2.8


I just tested this with the previous version (snort 2.9.5) using the  
same config and the same dump and this is also reproducable...

Just for reference:

$ snort --version

    ,,_     -*> Snort! <*-
   o"  )~   Version 2.9.5 GRE (Build 103)
    ''''    By Martin Roesch & The Snort Team:  
http://www.snort.org/snort/snort-team
            Copyright (C) 1998-2013 Sourcefire, Inc., et al.
            Using libpcap version 1.3.0
            Using PCRE version: 8.32 2012-11-30
            Using ZLIB version: 1.2.8


Best regards,

Bram


(PS: if needed you can also find me on IRC)

Quoting Bhagya Bantwal <bbantwal at ...402...>:

>
> Hello Bram,
>
> What version of Snort are you running? 2.9.5.3?
>
> I am unable to reproduce this issue with 2.9.5.3 with the conf you provided.
>
> Thanks!
>
> B
>
>
> On Mon, Sep 2, 2013 at 10:23 AM, Bram <bram-fabeg at ...3414...> wrote:
>
>> Hi,
>>
>>
>> When a TCP packet of a HTTP request is retransmitted then it can causes
>> alerts to be triggered incorrectly (AKA false positives).
>> This seems to happen only when a packet is retransmitted.
>>
>> The attached dump was recreated using raw sockets based on an actual HTTP
>> session.
>> The difference between the attached dump and the real traffic:
>> * less data
>> * the delay between packets is different
>> * port is different (5555 vs 80)
>>
>> Config:
>>         dynamicpreprocessor directory /usr/lib/snort_**
>> dynamicpreprocessor/
>>         preprocessor stream5_global: \
>>            track_tcp yes, \
>>            track_udp no, \
>>            track_icmp no
>>         preprocessor stream5_tcp: policy first, ports both 80 5555
>>
>>         preprocessor http_inspect: global iis_unicode_map unicode.map 1252
>> compress_depth 65535 decompress_depth 65535
>>         preprocessor http_inspect_server: server default \
>>             http_methods { GET HEAD POST PUT SEARCH MKCOL COPY MOVE LOCK
>> UNLOCK NOTIFY POLL BCOPY BDELETE BMOVE LINK UNLINK OPTIONS HEAD DELETE
>> TRACE TRACK CONNECT SOURCE SUBSCRIBE UNSUBSCRIBE PROPFIND PROPPATCH
>> BPROPFIND BPROPPATCH RPC_CONNECT PROXY_SUCCESS BITS_POST CCM_POST SMS_POST
>> RPC_IN_DATA RPC_OUT_DATA RPC_ECHO_DATA } \
>>             chunk_length 500000 \
>>             server_flow_depth 0 \
>>             client_flow_depth 0 \
>>             post_depth 65495 \
>>             oversize_dir_length 500 \
>>             max_header_length 4096 \
>>             max_headers 100 \
>>             max_spaces 0 \
>>             small_chunk_length { 10 5 } \
>>             ports { 80 5555 } \
>>             webroot no
>>
>>         alert ( msg: "HI_CLIENT_UNESCAPED_SPACE_IN_**URI"; sid:33; gid:
>> 119; rev: 1; metadata: rule-type preproc ; )
>>
>>         output alert_fast: stdout
>>
>> Running it:
>>         $ snort -v -l /var/log -c /etc/ips/snort.conf --daq-dir /lib/daq/
>> -r /tmp/http_body_retransmit.cap  2>&1 | grep '119:'
>>         09/02-16:52:20.309803  [**] [119:33:1] (http_inspect) UNESCAPED
>> SPACE IN HTTP URI [**] [Priority: 0] {TCP} 192.168.173.153:5556 ->
>> 192.168.173.1:5555
>>
>>
>> Looking at it shows that the alert is triggered on packet 10 which is the
>> 'TCP Retransmission' of the request body...
>>
>> My *guess* is that this problem is not directly related to the
>> 'HI_CLIENT_UNESCAPED_SPACE_IN_**URI' alert but that this is a more
>> general problem..
>> That is: I believe it is related to how the packets got reassembled and
>> that it is possible to trigger other alerts as well... but have not (yet at
>> least) attempted this.
>>
>>
>>
>> Best regards,
>>
>> Bram
>>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.





More information about the Snort-devel mailing list