Stream5: 'STREAM5_BAD_TIMESTAMP' alert, 'false' positives on delayed/out of order packets

[Bram <bram-fabeg () mail wizbit be>]

Hi,


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:

config:
        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} 192.168.173.1:5555 ->  
192.168.173.153:5556

version:
        $ snort -V
           ,,_     -*> 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



Best regards,

Bram


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

Attachment: stream5_paws.cap
Description:

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&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!