Re: Security flaw in Stateful filtering ??????

[Emmanuel Fleury <fleury@cs.auc.dk>]

Hi,

Rusty Russell wrote:
> 
> 	I disagree.  Consider the original complaint: that --state NEW
> allowed TCP ACK packets through, which allowed an ack scan.  This
> surprised the observers, who then blocked acks.

Precisely.

Actually, my exact complain is now that the documentation is not
making you awared of what you are exactly doing...

Somehow, this is dangerous and can lead you to have a flaw in your
firewall without being awared of it.

Moreover, most of the papers, articles, and web pages about Netfilter
are wrong about this.

Just as an example, the following (very nice) documentation about
Netfilter (http://www.knowplace.org/netfilter/index.html), state
that:

"Note: An ACK packet is a TCP packet with the ACK flag set only. The 
important thing to note here is that after the three-way handshake is 
completed, and the connection is complete, every packet that is part of 
this TCP connection will always have the ACK bit set.

This is also the reason why connection tracking is so important. Without 
connection tracking, there is no way for your firewall to know whether 
an arriving ACK packet is really a part of an established connection. 
When simple packet filters (and Ipchains) receives a packet with the ACK 
flag set, it simply allows the packet through (does this sound like a 
good idea?). When a stateful firewall received an ACK packet, it'll 
consult a connection table to see if the packet belongs to an 
established connection. If it does not, the packet is dropped."

See: http://www.knowplace.org/netfilter/ip_overview.html

Which is obviously wrong in respect of what we were discussing...

I think that this is due (as Rusty said) to a confusion between the
TCP protocol's states and the connection tracking module's states
which are different.

This should definitely be emphased in the documentation (IMHO).


The other points are more about the policy you want to apply for
the development of Netfilter. I mean, should it be left up to
the user to patch this in the ruleset or fixed in the code...

This could be discussed forever without any result.
Therefore, it makes no point to just keep going on this way.


It appears, also, to me that you are focusing more on an
"advanced NAT", than on real "stateful inspection". You agreed
on loosing some stateful key features to increase the connectivity
because as you are using stateful inspection to do NAT, the features
that you loose does not affect so much the security of your network.
But loosing this feature prevent you to use Netfilter as a real
stateful inspection firewall (I'll explain this point later in this
post).

Actually, this discussion start to make aware of the difference
between "connection tracking" and "stateful inspection". :-)


> 	Of course, you can still use SYNs to scan the network, so they
> haven't actually won anything here, except that if their firewall
> reboots, established connections will die.

Well, if you consider a full implementation of a stateful inspection
firewall, you should be able to "hide" a network from outside without
using NAT.

For example, you can make up the following ruleset:

o DENY SYN from outside -> inside
o Allow NEW, ESTABLISHED, RELATED

                       +-----------+
+--------+    +--+    | Hidden Net|
|Internet|----|FW|----| w/o NAT   |
+--------+    +--+    +-----------+

On this configuration, you allow all the computers of your hidden net
to have their own IP address and you disallow any sort of scan from
outside. You can even imagine to have a web server somewhere in your
hidden network (you just have to add as first rule that you allow
all the traffic on the port 80 to this precise IP address).

This configuration can't be done with Netfilter because you are doing
what we could call "connection tracking" and not "stateful inspection".


> 	The confusion here comes from the "TCP connection" vs
> "connection tracking connection" distinction, which is subtle and
> usually harmless.

Harmless if you are running NAT. But, if you are trying to use Netfilter
as a complete stateful inspection firewall, then you are in trouble
(IMHO).

> Hope that helps,

Yes. Thanks. :-)

Regards
-- 
Emmanuel

Security is a process, not a product.
   -- Bruce Schneier (Crypto-gram, February 15, 2002)