[Snort-users] Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from tracefile
lbalbalba at ...125...
Sun Aug 7 04:30:07 EDT 2005
Thanks for the information, but from the limited information in the
changelog I cannot actually determine if this is really referring to the
same ddos attack as the one that I am referring to.
If I understand the issue I originally mentioned correctly, then the
attacker injects a forged packet into the stream that has a TCP timestamp
that lies somewhere into the future, causing all subsequent packets to be
dropped because they are deemed to be too old or invalid, effectively
'stalling' the connection.
So if I understand correctly, then any relevant snort ruleset would have to
verify that at least all timestamps in a given tcp session are somewhat
'consecutive' ? Or if the timestamp value was set to a large value by the
attacker, then it will likely be larger than the timestamp values in any
subsequent incoming segments that belong to the same tcp session - does any
snort ruleset detect this ?
----- Original Message -----
From: "rmkml" <rmkml at ...953...>
To: "J.Smith" <lbalbalba at ...125...>
Sent: Sunday, August 07, 2005 1:19 PM
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from tracefile
> Found PAWS on src snort 240 : (ChangeLog)
> 2005-03-15 Jeremy Hewlett <jh at ...1935...>
> * etc/snort.conf:
> Stream4 fixes - Handle PAWS, NULL TCP Flags in established session,
> limit overlaps in established session, update ACK when server sends
> RST. Performance changes for cleaning up session cache. Thanks
> Steve Sturges and Andy Mullican for the patches.
> src/preprocessors/spp_stream4.c :
> * 04 Feb 2005: SAS Updated to handle favor_old and favor_new options.
> * favor_new traverses the tree in the opposite
> * direction and builds the stream using newer packets.
> * Also added checks for:
> * - PAWS (Timestamp option is set and 0) on an
> * establiahed session and ACK in the packet. Win32
> * uses 0 Timestamp on Syn-only packets.
> On Sun, 7 Aug 2005, J.Smith wrote:
>> Date: Sun, 7 Aug 2005 12:43:23 +0200
>> From: J.Smith <lbalbalba at ...125...>
>> To: snort-users at lists.sourceforge.net, snort-devel at lists.sourceforge.net
>> Subject: [Snort-devel] Detecting TCP Timestamp PAWS DoS from tracefile
>> At our site, we have the impression that we might have been hit by the
>> following issue :
>> Multiple Vendor TCP Timestamp PAWS Remote Denial Of Service Vulnerability
>> TCP does not adequately validate segments before updating timestamp value
>> In a nutshell, the issue manifests if an attacker transmits a sufficient
>> TCP PAWS packet to a vulnerable computer. A large value is set by the
>> attacker as the tcp packet timestamp. When the target computer processes
>> this packet, the internal timer is updated to the large attacker supplied
>> value. This causes all other valid packets that are received subsequent
>> to an attack to be dropped as they are deemed to be too old, or invalid.
>> This effectively 'stalls' the connection, which will deny service for a
>> target connection.
>> Fortunately, we have a tracefile of some of the traffic that hit our site
>> at the time. I was wondering how easy it would be to 'proof' that we did
>> indeed experience this issue with the use of snort ? I did a quick scan
>> of the snort ruleset database, but it appears that detection of this
>> issue is not included in the snort database yet ?
>> John Smith.
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
>> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>> Snort-devel mailing list
>> Snort-devel at lists.sourceforge.net
More information about the Snort-users