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

Victor Roemer vroemer at ...402...
Fri Sep 6 11:37:25 EDT 2013


Thanks again, I'll open a bug for this too


On Wed, Sep 4, 2013 at 4:35 PM, Bram <bram-fabeg at ...3414...> wrote:

> 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<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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130906/bbfbcc66/attachment.html>


More information about the Snort-devel mailing list