TCP RST vulnerability - handling question

Hi,

I am using an iptables 1.3.5 based setup and wonder if there
are any
tools or techniques available to prevent or mitigate the TCP
RST
spoofing issue (http:/
/osvdb.org/displayvuln.php?osvdb_id=4030)

I see elsewhere there has been suggestions of only accepting
the RST
if the sequence id is 1 more than the current, or providing
some sort
of challenge response
(http://tools.ietf.org/html/draft-ietf-tcpm-tc
psecure-02#section-2.2).
I don't believe netfilter uses either of these, so I am
interested in
hearing other peoples approaches to it.

Regards,

Mike

>From what I can tell, using IPSec mitigates this
vulnerability, but if you
can grok this article better than I you may be able to
tighten your security
even further:

http:/
/www.cert.org/advisories/CA-2001-09.html



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul Blondé
Web Programmer
enTel Communications Inc
jpbentel.ca
250.633.5151
866.633.2644
 


> -----Original Message-----
> From: netfilter-bounceslists.netfilter.org 
> [mailto:netfilter-bounceslists.netfilter.org] On
Behalf Of Mike C
> Sent: Wednesday, May 16, 2007 5:57 PM
> To: netfilterlists.netfilter.org
> Subject: TCP RST vulnerability - handling question
> 
> 
> Hi,
> 
> I am using an iptables 1.3.5 based setup and wonder if
there are any
> tools or techniques available to prevent or mitigate
the TCP RST
> spoofing issue (http:/
/osvdb.org/displayvuln.php?osvdb_id=4030)
> 
> I see elsewhere there has been suggestions of only
accepting the RST
> if the sequence id is 1 more than the current, or
providing some sort
> of challenge response
> (http://tools.ietf.org/html/draft-ietf-tcpm-tc
psecure-02#section-2.2).
> I don't believe netfilter uses either of these, so I am
interested in
> hearing other peoples approaches to it.
> 
> Regards,
> 
> Mike
> 

On 5/17/07, Mike C <smith.not.westerngmail.com> wrote:
> I am using an iptables 1.3.5 based setup and wonder if
there are any
> tools or techniques available to prevent or mitigate
the TCP RST
> spoofing issue (http:/
/osvdb.org/displayvuln.php?osvdb_id=4030)

I just realised that I posted the wrong issue. The one I am
referring
to is where a third party sends a RST with a sequence number
less than
the current window, which is still treated as a valid RST by
the end
point.

>From http://
www.securityfocus.com/archive/1/361009 - "the
4.4BSD stack
from which NetBSD's stack is derived, did not even check
that a RST's
sequence number was inside the window. RSTs anywhere to the
left of
the window were treated as valid."

I should outline my situation a bit more. I have a firewall
that I
want to prevent passing illegal RST packets to an inside
host. In my
case the host is patched against this issue, but this may
not always
be the case, so need to stop the invalid resets from
traversing the
firewall in the first place.

Regards,

Mike

On Fri, 18 May 2007, Mike C wrote:

> On 5/17/07, Mike C <smith.not.westerngmail.com> wrote:
>> I am using an iptables 1.3.5 based setup and wonder
if there are any
>> tools or techniques available to prevent or
mitigate the TCP RST
>> spoofing issue (http:/
/osvdb.org/displayvuln.php?osvdb_id=4030)
>
> I just realised that I posted the wrong issue. The one
I am referring
> to is where a third party sends a RST with a sequence
number less than
> the current window, which is still treated as a valid
RST by the end
> point.
[...]
> I should outline my situation a bit more. I have a
firewall that I
> want to prevent passing illegal RST packets to an
inside host. In my
> case the host is patched against this issue, but this
may not always
> be the case, so need to stop the invalid resets from
traversing the
> firewall in the first place.

Any recent kernel from the 2.6 series come with TCP window
tracking in 
netfilter, which makes sure that the RST segment is in the
window.
Nothing is needed besides enabling connection tracking.

Best regards,
Jozsef
-
E-mail  : kadlecblackhole.kfki.hu, kadlecsunserv.kfki.hu
PGP key : http://
www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear
Physics
           H-1525 Budapest 114, POB. 49, Hungary