[Firehol-support] possible problem with 'malformed-bad'

[Thomas Arendsen Hein]

On Thu, Mar 04, 2004 at 01:05:33AM +0200, Costa Tsaousis wrote:
> > I think these may be bad, too:
> > --tcp-flags SYN,RST,ACK SYN,RST
> 
> I think this is a subset of the existing:
> 
> --tcp-flags SYN,RST SYN,RST

You're right.

> > --tcp-flags SYN,RST,PSH,ACK,URG SYN,RST,PSH,URG
> 
> Added this in v1.180 in the CVS.

This is a subset of SYN,RST SYN,RST, too, so you can remove it.
Seems as if that rule didn't make it to my brain :)

> > Here are some links discussing this topic:
> > http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
> > http://www.kb.cert.org/vuls/id/464113
> > http://cgi.nessus.org/bid.php3?bid=7487
> >
> > Would it be feasible to use the usual firewall policy here, i.e.
> > allow only known good combinations, deny everything else?
> > Will this break some existing (buggy) TCP stacks?
> 
> It is possible. However with a stateful firewall like FireHOL, the
> iptables connection tracker matches all packets against the active sockets
> list it already has for allowing them to pass. I think that what you are
> suggesting  will not offer more security: If there is no existing socket
> to match a new packet against, and the new packet does not have the SYN
> bit set, it will not pass anyway (it will be dropped as "NEW TCP w/o
> SYN"). If it has the SYN bit set, then the firewall rules will decide. On
> the other hand, if the connection has been established the right way
> (accepted by the firewall rules as a NEW connection), what is the thread
> we should be protected from?
> 
> The worst thing to happen could be a TCP stack confusion; a risk we are
> trying to minimize with the malformed packets rules. However, I don't
> think that the iptables connection tracker can be confused by tcp flags
> since it matches source/destination IPs and source/destination ports for
> deciding if the packet is part of an established connection or not.

There may be another problem: Detecting which OS and/or OS version
is used on a host behind the firewall, depending on the reaction to
a tcp package with bad flags. At least nessus complains about this
when scanning the firewall, so there is at least the threat of a
false positive.

Thomas

-- 
Email: thomas at intevation.de
http://intevation.de/~thomas/