Choosing a BSD Firewall

Anonymous Coward writes "Jim O'Gorman has an article at bsdtoday.com about choosing an OS for a firewall project. While OpenBSD has a lot of followers, find out why Jim chose FreeBSD instead."

Comments

OpenBSD discussion

[wozz]

There's an interesting discussion going on one of the OpenBSD mailing lists about this article. It basically boils down to the fact that being able to easily upgrade to the latest version of IPF is not a security feature, in fact, its more likely a IN-security feature. The latest batch of IPF releases have suffered from some problems, and until they are all resolved, the OpenBSD folks didn't want to merge it into the tree. Basically, it boils down to newer does NOT equal better, and OpenBSD is going to be sure the software they put in their tree is as secure as it can possibly be.

Re:statefull filters?

[ninjaz]

I'm not a firewall expert, but, the basic idea is that IPFilter can be configured to only allow packets in from the outside if they're in response to a previously made connection request from the internal network (or part of the resulting session)

From the IP Filter site here:

Packet state filtering

Packet state filtering can be used for any TCP flow to short-cut later filtering. The "short-cuts" are kept in a table, with no alterations to the packet filter list made. Subsequent packets, if a matching packet is found in the table, are not passed through the list. For TCP flows, the filter will follow the ack/sequence numbers of packets and only allow packets through which fall inside the correct window.

#
# Keep state for all outgoing telnet connections
# and disallow all other TCP traffic.
#
pass out on le1 proto tcp from any to any port = telnet keep state
block out on le1 all

For UDP packets, packet exchanges are effectively stateless. However, if a packet is first sent out from a given port, a reply is usually expected in answer, in the `reverse' direction.

#
# allow UDP replies back from name servers
#
pass out on le1 proto udp from any to any port = domain keep state

Held UDP state is timed out, as is TCP state for entries added which do not have the SYN flag set. If an entry is created with the SYN flag set, any subsequent matching packet which doesn't have this flag set (ie a SYN-ACK) will cause it to be "timeless" (actually, the timeout defaults to 5 days), until either a FIN or RST is seen.

This sort of thing is also possible using the ipfw facility in FreeBSD:

# Allow TCP through if setup succeeded
$fwcmd add pass tcp from any to any established

# Allow setup of incoming email
$fwcmd add pass tcp from any to ${ip} 25 setup

# Allow setup of outgoing TCP connections only
$fwcmd add pass tcp from ${ip} to any setup

# Disallow setup of all other TCP connections
$fwcmd add deny tcp from any to any setup

Regarding Linux, it can kind of do that sort of thing currently, but only if you use IP Masquerading in conjunction with your firewalling. The idea there is that the only way to get a TCP packet past your Masquerading proxy is for it to be in response to a packet generated from inside your network. Of course, since you'd be doing many-to-one NAT in that scenario, the usual complications apply eg., since there is only 1 externally visible IP, you can't choose to allow specific incoming ports for multiple clients.

From what I understand, netfilter, which will be available in a stable release as of Linux 2.4.x, will make a more elegant method of doing this possible.