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

Bram bram-fabeg at ...3414...
Thu Sep 19 16:11:53 EDT 2013


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
	           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.


Best regards,

Bram


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 129_5_A.cap
Type: application/octet-stream
Size: 784 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130919/6c40ef42/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 129_5_B.cap
Type: application/octet-stream
Size: 8375 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130919/6c40ef42/attachment-0001.obj>


More information about the Snort-devel mailing list