Tuesday, March 3, 2009

Switching Firewalls from ipf to pf on FreeBSD

It's time to deploy a new FreeBSD firewall, and I thought I'd check out pf instead of my standard ipf package.

pf is written by the OpenBSD team, and was designed to replace ipf because of the licensing issues with that code not being a proper BSD license. There's also some political issues, but I'll leave those along.

The Background:

Since the early days my office firewalls have been FreeBSD platforms. I've always loved the BSD platform, back from the days where I built an ISP around the BSDi package in the early 90's.

For as long as I can remember, I've been using ipf (ipfilter) by Darren Reed. It became so standard that FreeBSD started including it in their releases which makes life much easier.

Unix based firewalls always had my vote - They are infinitely configurable and extensible. They are not overly hard to setup, and they don't need a lot of hardware to run. In the day my options were a very expensive Cisco-class router, or Unix.

But as NAT routers kept dropping in price and improving in quality, my Unix based router/firewalls started slowly disappearing from sites. Most small offices don't need much - basic NAT with one port for remote access from us, and they are happy. A simple D-Link DI-604 goes for $50. That's a far cry cheaper than a decent computer and the charge for my time to setup a custom firewall.

So the Unix-Based firewalls only exist in some of my more complex, larger, or secure customer sites. The rest have Linksys or D-Link routers.

A few months ago my aged FreeBSD firewall finally died. Heck, it was a Pentium-233Mhz - I think I got my money's worth out of it. I knew it's days were numbered so I had a spare DI-604 ready to go, and popped it into place when needed.

I didn't really notice much of a difference in speed of the network (my main concern against the little routers) and it was handy to be able to use a web interface to configure it. I know you can do this with Unix, but it was one of the things I didn't bother updating as I upgraded the boxes over the years, relying on SSH instead. I don't pay a lot of attention to my firewall, and I didn't want to worry about security issues in the web interface screwing me up.

Life's been fine on the little D-Link until I started getting heavier into uTorrent. You put a few Windows 2003 machines on a network running uTorrent, and you can bring a little NAT router to it's knees. They just don't have enough memory and processor power.

The answer was to go back into some sort of Unix based firewall. Wanting something easier and FreeBSD based, I found pfSense. That didn't work out well for me, but it's another blog.

I made some compromises on how I use uTorrent, and my little DI-604 was still useful...

..until I had some heavy Spammer hacking going on. Talk about dragging your network into the ground. The DI-604 can't handle large amounts of traffic, even if it's rejecting it, and I was getting a lot of traffic. One old Windows 2000 IIS server (ticking time bomb really) was compromised, and the scum of the world was lining up at my router to use my bandwidth.

Back to Today - Trying pf over ipf:

So I have to build a new FreeBSD firewall. A quick download of 7.1-RELEASE i386 Disc1 (no need for 64 bit on a fw as far as I can see), and I'm on my way.

(btw msk support in 7.1 seems to be much better than 7.0 - no watchdog timeouts for me so far)

I decided to make this one a pf test platform as pf is also included by default with FreeBSD 7.1. I've heard mixed reviews of which is better, but the thing that intrigued me the most was that pf was a superset of ipf - my knowledge of rules for ipf wouldn't' be wasted, and I'd have more things to play with. ipf bugs me at times, as it doesn't seem to be evolving (like qmail). There is something to be said for a stable codebase, but I also don't think we've reached the pinacle of these packages.

Setup is simple;

in rc.conf;

pf_enable="YES"
pflog_enable="YES"

and your config file is /etc/pf.conf

pfctl is your control program for start, stop, and status.

If you want to be lazy, I'm quite sure a standard ipf.conf would work if you wanted to play with this.

So far I like pf. It's got a bit of a learning curve, but it has additional features that ipf lacks.

I like that the NAT portion is in the pf.conf - just looks cleaner to me to have one file for it. I like that I have more NAT rules. I have a "no nat" rule that blocks any outgoing SMTP traffic that doesn't go through one of our main mailservers. Just a different way of doing it, but nice.

pf also has the ability to do QoS routing via the ALTQ interface.

I'm currently checking out fwanalog so I can get a better look at pf's logs (also works for ipf) and I think I'm going to have to move into a Snort setup so I can detect these attacks and prevent them in the future.

This link has some simple info for monitoring pf firewalls;

http://prefetch.net/articles/monitoringpf.html

I'll post more as I find them.

1 comment:

  1. Pf is dead sexy and the syntax is much clearer than ipf. I almost feel sorry for people that have to use iptables :-)

    There is also a very nifty web interface that you can use called pfw (http://www.allard.nu/pfw/) and that combined with lighttpd will give you a very light weight solution.

    ReplyDelete