[Snort-devel] Stream5: 'STREAM5_BAD_TIMESTAMP' alert, 'false' positives on delayed/out of order packets

Bram bram-fabeg at ...3414...
Wed Sep 4 16:35:31 EDT 2013


Attached is a dump file which was recreated based on an HTTP connection.

What happens in the dump is that the 'ACK' (packet 9) on the request  
(packet 4) is delayed and arrives after the data (packets 5 and 6).

There are several ways to see this in the dump:
* the IP Identification number is lower
* the sequence number is lower then the last received sequence number
* the timestamp value is lower

The 'correct' order of the packets (based on the 'IP Identification'):  
  1, 2, 3, 4, 9, 5, 6, 7, 8(, 10)

Running snort with the dump triggers the 'STREAM5_BAD_TIMESTAMP' alert.
This alert is given because packet 9 in the dump contains a lower  
TSVal then packet 6.

 From RFC 1323:
       PAWS uses the same TCP Timestamps option as the RTTM mechanism
       described earlier, and assumes that every received TCP segment
       (including data and ACK segments) contains a timestamp SEG.TSval
       whose values are monotone non-decreasing in time.  The basic idea
       is that a segment can be discarded as an old duplicate if it is
       received with a timestamp SEG.TSval less than some timestamp
       recently received on this connection.

Technically speaking: based on RFC 1323 the alert is correct and the  
packet can be dropped.
[In this particular case dropping the packet has no effect whatsoever  
since it contains no data and an ack for the data was already send  
with packet 5 and 6]

Reading further in RFC 1323 suggest that the case in the dump file was  
never taken fully into consideration...
If packet 9 had contained some data then it would have been handled by  
RFC 1323 since 'TS.Recent' is only updated when there are no gaps in  
the sequece numbers. [I checked how short behaves in such a case and  
it seems to handle it correctly]
Since packet 9 contains no data 'TS.Recent' is updated when packet 5  
is received (no gap in the data) and this causes packet 9 to be seen  
as outside the PAWS window...

I'm not convinced that producing an alert in this particular case is useful...
In my opinion it's not really an anomaly but is more business as usual...

The result is that the alert (IMO) becomes close to useless since it  
matches 'normal' traffic...
In the 7 hours this alert was active it was triggered at least 673  
times (duplicates filtered)...
I'm aware that this number is not really useful without reference to  
number of tcp sessions but that data is not available.
Again in my opinion, this are simply too much alerts to investigate  
and this can only result in the rule being disabled/ignored.

A possible fix can be to not generate the alert when the tcp packets  
contains no data.
I'm not sure tho if this is sufficient for all cases, hopefully it is  
sufficient for most cases...
(Just thinking out loud: there could still be an 'issue' when a tcp  
packet is retransmitted which was already received and which arrives  
after another packet with a higher TSVal..)

Even if no fix is preformed then it seems - tt the very least -  
worthwhile to mention this in the documentation of the rule...

Just for reference:

	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 5555

	alert ( msg: "STREAM5_BAD_TIMESTAMP"; sid: 4; gid: 129; 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/stream5_paws.cap 2>&1 | grep '129:'
	09/04-22:19:40.141184  [**] [129:4:1] TCP Timestamp is outside of  
PAWS window [**] [Priority: 0] {TCP} ->

	$ snort -V
	   ,,_     -*> Snort! <*-
	  o"  )~   Version GRE (Build 132)
	   ''''    By Martin Roesch & The 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,


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stream5_paws.cap
Type: application/octet-stream
Size: 887 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130904/ab79bf68/attachment.obj>

More information about the Snort-devel mailing list