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

[Costa Tsaousis]

Hi,

> 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

Isn't it?

> --tcp-flags SYN,RST,PSH,ACK,URG SYN,RST,PSH,URG

Added this in v1.180 in the CVS.
Thanx

> and probably more ...

Yes, I am sure.

> 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.

Costa