Re: Stream5: 'STREAM5_BAD_SEGMENT' alert: false positives?

[Russ Combs <rcombs () sourcefire com>]

On Thu, Sep 19, 2013 at 4:11 PM, Bram <bram-fabeg () mail wizbit be> wrote:

> Hi,
>
>
> Attached are two dumps which trigger the 'STREAM5_BAD_SEGMENT' alert.
>
> Both dumps are recreated based on actual HTTP sessions.
>
> * The first dump does show some odd behaviour and doesn't make a lot of
> sense to me, but this is what is in the captured stream.
> The stream on which this is based on contains many retransmissions, fast
> retransmissions and acks with SACKs.
>
> * The second dump makes more sense: the sender receives no ack on a data
> packet and splits it in two (it may have assumed it was too large).
>
> Small note: what is not recreated is the delay between the packets/the TS
> value and the IP identifier.
>
>
> Config file:
>         dynamicpreprocessor directory /usr/lib/snort_**
> dynamicpreprocessor/
>         preprocessor stream5_global: track_tcp yes, \
>            track_udp no, \
>            track_icmp no
>
>         preprocessor stream5_tcp: detect_anomalies, ports both 80 5555
>
>         alert ( msg: "STREAM5_BAD_SEGMENT"; sid: 5; gid: 129; rev: 1;
> metadata: rule-type preproc ; )
>
>         output alert_fast: stdout
>
> Running it:
>         $ snort  -l /var/log -c /etc/ips/snort.conf --daq-dir /lib/daq/ -r
>  /tmp/129_5_A.cap 2>&1 | grep '129:'
>         09/26-01:18:36.196782  [**] [129:5:1] Bad segment, adjusted size
> <= 0 [**] [Priority: 0] {TCP} 192.168.173.1:5555 -> 192.168.173.153:5556
>
>         $ snort  -l /var/log -c /etc/ips/snort.conf --daq-dir /lib/daq/ -r
>  /tmp/129_5_B.cap 2>&1 | grep '129:'
>         09/27-10:14:12.388809  [**] [129:5:1] Bad segment, adjusted size
> <= 0 [**] [Priority: 0] {TCP} 192.168.173.1:5555 -> 192.168.173.153:5556
>
>
> Version:
>         $ snort  --version
>
>            ,,_     -*> Snort! <*-
>           o"  )~   Version 2.9.5.5 GRE (Build 205)
>            ''''    By Martin Roesch & The Snort Team:
> http://www.snort.org/snort/**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
>
>
> For /tmp/129_5_A.cap: alert triggered on packet 6
> For /tmp/129_5_B.cap: alert triggered on packet 14
>
>
> Running it with gdb:
>
> Breaking in 'snort_stream5_tcp.c' line 5934 (right before 'seq +=
> overlap'):
> Code:
>                     seq += overlap;
>                     slide = overlap;
>                     if(SEQ_LEQ(seq_end, seq))
>                     {
>                         /*
>                          * houston, we have a problem
>                          */
>                         /* flag an anomaly */
>                         EventBadSegment(st->tcp_**policy);
>                         s5stats.tcp_discards++;
>                         PREPROC_PROFILE_END(**s5TcpInsertPerfStats);
>                         return STREAM_INSERT_ANOMALY;
>                     }
>                     break;
>
> For /tmp/129_5_A.cap:
> * left->seq = 200001
> * left->size = 9
> * seq = 200006
> * overlap = (left->seq + left->size - seq) = (200001 + 9 - 200006) = 4
>
> Based on the sequence number there is a (potential) overlap of 4 bytes.
> This packet however contains only 1 byte.
>
> Code continues:
> * seq += overlap: 200006 + 4 = 200010
> * seq_end = 200007
>
> => seq_end is lower then seq
> ==> alert
>
>
> For /tmp/129_5_B.cap:
> * left->seq = 201925
> * left->size = 1448
> * seq = 202897
> * overlap = (left->seq + left->size - seq) = (201925 + 1448 - 202897) = 476
>
> Based on the sequence number there is a (potential) overlap of 476 bytes.
> This packet contains exactly 476 bytes
>
> Code continues:
> * seq += overlap: 202897 + 476 = 203373
> * seq_end = 203373
>
> => seq_end is equal to seq
> ==> alert
>
>
> Looking at the rule documentation: 'the preprocessor has detected a bad
> segment, the overlap adjusted size is less than or equal to 0'
> Based on the documentation it seems that this rule wants to detects
> packets that only contain data that was already seen in a previous packet?


> Was there a particular reason why this rule was added?
I feel the rule matches too much/frequently - at the very least it seems to
> match legitimate traffic.
>
> 129:5 alerts on full overlaps of retransmitted data that don't line up
with the original segmentation and is therefore potentially unusual.  I
would not rely on it as a sole indicator of evil doing, if at all,
especially when inline since the payload can be normalized.


> Best regards,
>
> Bram
>
>
> ------------------------------**------------------------------**----
> This message was sent using IMP, the Internet Messaging Program.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

_______________________________________________
Snort-devel mailing list
Snort-devel () 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!