[Snort-devel] Stream5: 'STREAM5_BAD_SEGMENT' alert: false positives?

Russ Combs rcombs at ...402...
Mon Sep 23 17:39:32 EDT 2013


On Thu, Sep 19, 2013 at 4:11 PM, Bram <bram-fabeg at ...3414...> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130923/35369d25/attachment.html>


More information about the Snort-devel mailing list