Re: stateful firewall
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/
wood@kingsley.co.za | Fax: +27 21 761 9930 | Kingsley Technologies
Reply to: