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."

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... ;-)

also check out the comments following the article

[jslag]

Predictably enough, OBSD folks are not so impressed by the complaint that running the latest version of OBSD is unsafe, but upgrading to the latest version of the firewall software is fine. Also sounds like the author is confused about the stability of OBSD's -current release (sounds to me more like Debian's unstable, which I've been running for over a year on 4 machines with nothing but a few temporary dependancy problems...)

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:choosing the right OS

[Anonymous Coward]

I would never use Linux distributions where security is important. If security was semi-important, I might, just might, use Debian, but lets face it, Linux simply doesn't cut it when it comes to security and servers in general. Not to say that you can't use it if you're familiar with Linux, because you then can probably do a better job with Linux than you can with BSD.

Re:choosing the right OS

[smkndrkn]

Can you explain this statement a little better? I have built quite a few linux firewalls. I always use slack for a couple reasons:
1. I know slack better than any other distro of linux
2. You usually don't get the latest and greatest as quick so things can be tested better.
I also use OpenBSD and FreeBSD ( Usually OpenBSD because, again, I know it better ). I've been using Linux for about 4.5 years and BSDs for about 2. I don't see how you can say BSD is tougher than Linux as a blanket statement.
Can someone tell me why "Linux simply doesn't cut it when it comes to security and servers in general" as stated by the coward?
Thanks

Re:OpenBSD discussion

[Anonymous Coward]

Is it just me or does this article make it sound like the author never did the install of either.. and was just using this as excuse to promote FreeBSD? Everything is so superficial.. and with the exception of the few lines about the -current updating method there are no details on why you might choose one over the other. IMHO the differences are very minor.. one is not 'better' than the other.. they just have their differences. Clearly OBSD's focus is on security.. and for a security oriented use it would seem to make the most sense to use it over a more generic OS like FreeBSD or Linux. Also, the argument about a 'home user' using OBSD because it's more secure by default dosen't hold water with me... somehow I think if someone is informaed enough to install and configure a firewall on /either/ BSD they have enough going on upstairs to understand the other security isses involved with a unix box.

Just my .02

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.

Re:OpenBSD discussion

[3263827]

Trust me. I hired him to implement the first firewall solution (using OpenBSD) and then signed off on the switch to Freebsd. I believe that Jim was avoiding a long lecture on firewall theory and installation.

statefull filters?

[Dionysus]

In the article, they mention statefull filters as a reason to choose *BSD. What is that? How is that different than how Linux does it (not to start a flamewar)?

And yes, I have ordered the O'Reilly book on Firewalls, but I'm waiting for the next version to come out (June 5th?).

ipf on freebsd

[fuzzybunny]

I'm running ipf on FreeBSD 4.0-R. I've found it to be super-stable, and the configuration isn't particularly difficult. It does NAT well, and I like its logging. This is especially important, as I'm installing it for clients who have some UNIX know-how, but aren't necessarily super-clued.

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 [anu.edu.au]:

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.

Re:statefull filters?

[fuzzybunny]

I've actually found that ipfw's stateful filtering acts, well, "goofy". I've got a bit of a unique environment, to be sure--I'm running a firewall on the rear box of a dual NAT setup.

Basically, I found that ipfw wasn't able to reliably keep state on a lot of traffic which it had to pass out a NAT _after_ passing the natd running on the ipfw machine.

It also had problems with ftp connections-- maybe I just didn't find the corresponding facility in ipfw/natd, but ipf has an excellent ftp 'proxying' mechanism which will not just keep state on two-way tcp/udp connections, but also keep track of the return ftp data connections.

Re:statefull filters?

[Shanep]

Re: goofy problem with FTP through NAT.

Are you running FTP in passive mode? Since it's return port is otherwise random, NAT does'nt know what to do with the remote response, so the connection is not made.

Re:A couple of questions

[spit-it-out]

uhm