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

choosing the right OS

[wolfram_pfeiffer]

(As my statement is quite general, it may be a little off-topic, but here we go...)

What seemed most important to me in this article was not the question FreeBSD vs. OpenBSD but: "Don't view OS's as a religion, because they are only tools. Nothing more. Use the best one for a given job and let it stay at that. [...]"

Whereas hardly any Windows-user really identifies with his OS, many U*IX-users tend to do so. (Hell, I also often do so... ;-)

This does not only increase the os-for-computer-nerds image, it may also make some gurus blind for problems of their OS where another OS already offers a good solution (that might be integrated easily).

So I was quite happy to read in this article that O'Gorman used a very conservative approach to choose the os that best meets his needs. If he had also considered Linux he would have made my day... ;-)

Re:choosing the right OS

[Howl]

I don't buy that Linux is that bad (not compared to people trying to use NT as a firewall). Personally I prefer black box firwalls (I like the pix) but at home I went with BSD (despite growing up writing device drivers for version 7 and system V :-)

I think for most practical purposes the big issue in firewalls is configuration (or lack of) and user stupidity (if users have remote access without hardware authentication then assume the bad guys do too). Add to that an eggshell mentality (hard wall soft middle) and you have a recipie for bad security. If you are a real badguy (as opposed to a script kiddie) social engineering beats software attacks by a wide margin.

Re:choosing the right OS

[smkndrkn]

I agree that firewalls are only as secure as the OS they are run on. No I do not turn off all access to the firewall in most cases. What new holes have you found in slackware recently that would provide a breach of security? I think that it is important to note that while I have built many boxes with slackware as firewalls I have had no successful breaches of security in about 3 years. 3 Years ago on a home machine I had someone get a remote root shell that caused damage but it wasn't because of slackware it was because of qpopper and my weakness in security.
I think I understand computer security fairly well. While I would not run Slackware as a firewall for a large site it does a great job on small/medium sites when cost is a factor and I think you would have a tough time showing me that FreeBSD is more secure than Linux if both are configured properly.
I also use a PIX or other device when setting up a firewall for a large network.

Please show me how well you understand computer security by showing examples instead of using broad claims. I could very well be wrong, what I'm looking for is a little insite as to WHY.

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.