On Wed, Mar 21, 2001 at 04:27:00PM -0800, Cory Petkovsek wrote: [snip] > Can anyone tell me either by opinion, or preferably by > scientific fact, how much more secure the stateful netfilter > in the 2.4 kernel is compared to the 2.2 series firewall? Are > they about the same, or are we talking an order of magnitude?
I would expect they are pretty much the same except for the statefulness. Of course this may not be the case, but I don't see why not :) > Note, I'm not talking about ipchains vs iptables; the > interface to the firewall, rather I'm talking about netfilter > as the kernel firewall versus whatever the 2.2 kernel filter > was called. Statefulness vs statelessness. Statefulness is generally considered better than statelessness. There are articles comparing the two. Basically stateful firewalls allow more complex things to be done more simply. This means it's more difficult to write the code to implement a stateful packet filter, but much easier to write the firewall rules. It also makes certain things possible that aren't possible with stateless firewalls. e.g. filtering FTP traffic properly. With a stateless firewall, you either have to allow only active FTP sessions into your network from the outside if you have an internal FTP server for some reason, and passive FTP sessions from the inside to external FTP servers, or you have to allow anyone to connect to any high port on any of your internal machines. With a stateful packet filter that understands the FTP protocol, you can just tell it to allow FTP connections and not have to open up huge ranges of ports that actually have nothing at all to do with FTP, but could be used in transferring FTP data. The only problem with this is that, because stateful packet filters involve more code, there's perhaps a higher chance of a bug, and someone might be able to trick the firewall into allowing connections to port 139 on your internal network, by making it look as if an FTP server wants to use that as part of the data channel. (It sometimes helps if the FTP server has certain types of bug as well.) The above might be a little vague, but there was a problem not too long ago, where in certain cases, an attacker could make a firewall (I think the particular product that was found to be vulnerable was Firewall-1, but I could be wrong.) open an arbitrary port on the FTP server. See BUGTRAQ archives for details. I think this was found last year some time, or perhaps the end of the year before. > When I specify, allow Established and Related connections in, > is this secure? Is it possible for someone to highjack an > established connection? Even with spoofed packets? What is a > related connection? Whether or not it's secure depends on how well the section of code that deals with that protocol is written :) As to how easy or difficult it would be to hijack a connection, I wouldn't know. A related connection is another connection that forms part of the same "session." e.g. with FTP you have a command channel and a data channel. You send commands (like LIST or RECV) in the command channel and the data gets sent or received via a completely separate TCP connection (the data channel.) A stateful packet filter would monitor the command channel and take notice of the FTP that involve opening a data channel. It would then allow connections that match the parameters of the data channel. e.g. if the server says to the client that the client can connect to it on port 1369 to get the data it's just requested, the firewall will allow a connection to that port on the firewall from the client. The data channel is "related" to the command channel, since it is part of the same FTP session. Hope this helps. -- Michael Wood | Tel: +27 21 762 0276 | http://www.kingsley.co.za/ [EMAIL PROTECTED] | Fax: +27 21 761 9930 | Kingsley Technologies
