Hi all, Hope I am not bursting in to this thread at a too late point.. but here goes.
The --state NEW ! --syn -j DROP rule applied in the iptables tutorial (now at 1.1.11, available at http://iptables-tutorial.haringstad.com). What does it do? Simple enough, it blocks all packets considered as NEW and which does not have the SYN flag set (out of SYN,ACK,FIN). It should solve your (Emmanuel Fleury) problem as it looks today. The NEW state can be used for, as has already been discussed, connection pick-up (i.e., when the firewall reboots). Another, related, usage is if we have a redundant firewall (I haven't seen this discussed so far so.... Consider this: 1 main firewall 1 router and a secondary firewall. The three are set up in a routing zone. If the main firewall goes down, the router will notice, and route packets through the redundant firewall. If the NEW target was to allow only SYN packets, this would be impossible as you can understand from this. I have already suggested this, but noone picked up on it. 1. Patch netfilter so you can write and read connection tracking entries via a netlink socket. On top of this, make a daemon that will share states between the firewalls. This will make a much better solution, though a bit more "needy" in resources etcetera. Put this idea together with our old behaviour (currently used), and we could perhaps make the default behaviour of netfilter to only pick up SYN packets as NEW, then make it possible to pick up connections by also allowing ACK and other packets, and finally the third solution above. All of them together would cover all big areas AFAIK (e.g. small home networks, medium networks (pickup) and the big and expensive solution (routing zones with several firewalls being able to pick up connections from eachother). Finally, I agree with Emmanuel that the current documentation is _not_ clear enough on this matter. As he says, this is a huge backdoor that most people miss when they make a ruleset. I'm sorry for this rather long mail, but I am just getting some thoughts off of my head. Have a nice day, Oskar Andreasson http://www.boingworld.com http://people.unix-fu.org/andreasson/ mailto: [EMAIL PROTECTED] ----- Original Message ----- From: "Emmanuel Fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 07, 2002 10:15 AM Subject: Re: Security flaw in Stateful filtering ?????? > 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) > > >
