Thanks, again.
"rmkml" <rmkml@free.fr> wrote:
Snort support PAWS but possible not detect DoS
Yeah, that was my guess as well. If snort doesn't detect this issue, would
it be possible/feasible/easy to add a ruleset that would allow snort to
detect it ?
Im detected PAWS discard (linux stack) with firestorm nids product :
Im not a developer myself, so im not quite sure what it is that firestorm is
supposed to check, but ... it looks like it triggers an alert if any
supplied TCP timestamp in a given tcp session is set more than 24 hours into
the future or past ?
Sincerely,
John Smith
PS:
Just in case, Im adding the snort-sigs list to the thread. In summary, the
question is whether snort allows for the detection of the following issue :
Multiple Vendor TCP Timestamp PAWS Remote Denial Of Service Vulnerability
http://www.securityfocus.com/bid/13676
TCP does not adequately validate segments before updating timestamp value
http://www.kb.cert.org/vuls/id/637934
CAN-2005-0356
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0356
----- Original Message -----
From: "rmkml" <rmkml@free.fr>
To: "J.Smith" <lbalbalba@hotmail.com>
Sent: Sunday, August 07, 2005 2:15 PM
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from tracefile
Snort support PAWS but possible not detect DoS (same Bro nids),
Im detected PAWS discard (linux stack) with firestorm nids product :
firestorm-0.5.5/decode_plugins/tcpstream.c :
* o PAWS (rfc1323) evasion
...
static struct alert alert_tcp3={
.alert="PAWS discard",
...
/* rfc1323: H1. Apply PAWS checks first */
if ( rcv->flags & TF_TSTAMP_OK &&
(tp->saw_tstamp=tcp_fast_options(tcph, &tp->tsval)) ) {
if ( (int32_t)(rcv->ts_recent - tp->tsval) > TCP_PAWS_WINDOW &&
(u_int32_t)p->time.tv_sec < rcv->ts_recent_stamp
+ TCP_PAWS_24DAYS ) {
alert_tag(cur.pkt, &alert_tcp3, -1);
return;
}
Regards
Rmkml
On Sun, 7 Aug 2005, rmkml wrote:
Date: Sun, 7 Aug 2005 13:52:59 +0200 (CEST)
From: rmkml <rmkml@free.fr>
To: J.Smith <lbalbalba@hotmail.com>
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from
tracefile
Possible send (anonymazing ip) tracefile/pcapfile to the list ?
On Sun, 7 Aug 2005, J.Smith wrote:
Date: Sun, 7 Aug 2005 13:29:29 +0200
From: J.Smith <lbalbalba@hotmail.com>
To: rmkml <rmkml@free.fr>, snort-users@lists.sourceforge.net,
snort-devel@lists.sourceforge.net
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from
tracefile
Hi.
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 ?
Thanks,
Sincerely,
John Smith.
----- Original Message ----- From: "rmkml" <rmkml@free.fr>
To: "J.Smith" <lbalbalba@hotmail.com>
Sent: Sunday, August 07, 2005 1:19 PM
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from
tracefile
Hi,
Found PAWS on src snort 240 : (ChangeLog)
2005-03-15 Jeremy Hewlett <jh@sourcefire.com>
...
* 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.
Regards
Rmkml
On Sun, 7 Aug 2005, J.Smith wrote:
Date: Sun, 7 Aug 2005 12:43:23 +0200
From: J.Smith <lbalbalba@hotmail.com>
To: snort-users@lists.sourceforge.net,
snort-devel@lists.sourceforge.net
Subject: [Snort-devel] Detecting TCP Timestamp PAWS DoS from tracefile
Hi.
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
http://www.securityfocus.com/bid/13676
TCP does not adequately validate segments before updating timestamp
value
http://www.kb.cert.org/vuls/id/637934
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 ?
Thanks,
John Smith.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Snort-users mailing list
Snort-users@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
