[Firehol-support] possible problem with 'malformed-bad'
costa at tsaousis.gr
Wed Mar 3 23:05:33 GMT 2004
> 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
> --tcp-flags SYN,RST,PSH,ACK,URG SYN,RST,PSH,URG
Added this in v1.180 in the CVS.
> and probably more ...
Yes, I am sure.
> Here are some links discussing this topic:
> 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.
More information about the Firehol-support