In this chapter, we will create a very simple setup with PF. We’ll begin with the simplest configuration possible: a single machine configured to communicate with a single network. That network could very well be the Internet.
Your two main tools for configuring PF are your favorite text editor and the pfctl command-line administration tool. PF configurations, usually stored in /etc/pf.conf, are called rule sets, because each line in the configuration file is a rule that helps determine what the packet-filtering subsystem should do with the network traffic it sees. In ordinary, day-to-day administration, you will edit your configuration in the /etc/pf.conf file, and then load your changes using pfctl. There are web interfaces for PF administration tasks, but they are not part of the base system. The PF developers are not hostile toward these options, but they have yet to see a graphical interface for configuring PF that is clearly preferable to editing pf.conf and using pfctl commands.
Before you can get started on the fun parts of shaping your network with PF and related tools, you need to make sure that PF is available and enabled. The details depend on your specific operating system: OpenBSD, FreeBSD, or NetBSD. Check your setup by following the instructions for your operating system, and then move on to A Simple PF Rule Set: A Single, Stand-Alone Machine in A Simple PF Rule Set: A Single, Stand-Alone Machine.
The pfctl command is a program that requires higher privilege than the default for ordinary users. In the rest of this book, you will see commands that require extra privilege prefixed with sudo. If you have not started using sudo yet, you should. sudo is in the base system on OpenBSD. On FreeBSD and NetBSD, it is within easy reach via the ports system or pkgsrc system, respectively, as security/sudo.
Here are a couple general notes regarding using pfctl:
The command to disable PF is
pfctl -d. Once you have entered that command, all PF-based filtering that may have been in place will be disabled, and all traffic will be allowed to pass.For convenience,
pfctlcan handle several operations on a single command line. To enable PF and load the rule set in a single command, enter this:$ sudo pfctl -ef /etc/pf.conf
In OpenBSD 4.6 and later, you do not need to enable PF, since it is enabled by default with a minimal configuration in place.[9] If you were watching the system console closely while the system was starting up, you may have noticed the pf enabled message appear soon after the kernel messages completed.
If you did not see the pf enabled message on the console at startup, you have several options to check that PF is indeed enabled. One simple way to check is to enter the command you would otherwise use to enable PF from the command line, like this:
$ sudo pfctl -eIf PF is already enabled, the system responds with this message:
pfctl: pf already enabled
If PF is not enabled, the pfctl -e command will enable PF and display this:
pf enabled
In versions prior to OpenBSD 4.6, PF was not enabled by default. You can override the default by editing your /etc/rc.conf.local file (or creating the file, if it does not exist). Although it is not necessary on recent OpenBSD versions, it does not hurt to add this line to your /etc/rc.conf.local file:
pf=YES # enable PF
If you take a look at the /etc/pf.conf file in a fresh OpenBSD installation, you get your first exposure to a working rule set.
The default OpenBSD pf.conf file starts off with a set skip on lo rule to make sure traffic on the loopback interface is not filtered in any way. The next active line is a simple pass default to let your network traffic pass by default. Finally, an explicit block rule blocks remote X11 traffic to your machine.
As you probably noticed, the default pf.conf file also contains a few comment lines starting with a hash mark (#). In those comments, you will find suggested rules that hint at useful configurations such as FTP proxying (see Chapter 3) and spamd, the OpenBSD spam-deferral daemon (see Chapter 6). These items are potentially useful in various real-world scenarios, but since they may not be relevant in all configurations, they are commented out in the file by default.
If you look for PF-related settings in your /etc/rc.conf file, you will find the setting pf_rules=. In principle, this lets you specify that your configuration is in a file other than the default /etc/pf.conf. However, changing this setting is probably not worth the trouble. Using the default setting lets you take advantage of a number of automatic housekeeping features, such as automatic nightly backup of your configuration to /var/backups.
On OpenBSD, the /etc/rc script has a built-in mechanism to help you out if you reboot with either no pf.conf file or one that contains an invalid rule set. Before enabling any network interfaces, the rc script loads a rule set that allows a few basic services: SSH from anywhere, basic name resolution, and NFS mounts. This allows you to log in and correct any errors in your rule set, load the corrected rule set, and then go on working from there.
Good code travels well, and FreeBSD users will tell you that good code from elsewhere tends to find its way into FreeBSD sooner or later. PF is no exception, and from FreeBSD 5.2.1 and the 4.x series onward, PF and related tools became part of FreeBSD.
If you read through the previous section on setting up PF on OpenBSD, you saw that on OpenBSD, PF is enabled by default. That is not the case on FreeBSD, where PF is one of three possible packet-filtering options. Here, you need to take explicit steps to enable PF, and compared to OpenBSD, it seems that you need a little more magic in your /etc/rc.conf. A look at your /etc/defaults/rc.conf file shows that the FreeBSD default values for PF-related settings are as follows:
pf_enable="NO" # Set to YES to enable packet filter (pf) pf_rules="/etc/pf.conf" # rules definition file for pf pf_program="/sbin/pfctl" # where pfctl lives pf_flags="" # additional flags for pfctl pflog_enable="NO" # set to YES to enable packet filter logging pflog_logfile="/var/log/pflog" # where pflogd should store the logfile pflog_program="/sbin/pflogd" # where pflogd lives pflog_flags="" # additional flags for pflogd pfsync_enable="NO" # expose pf state to other hosts for syncing pfsync_syncdev="" # interface for pfsync to work through pfsync_ifconfig="" # additional options to ifconfig(8) for pfsync
Fortunately, you can safely ignore most of these—at least for now. The following are the only options that you need to add to your /etc/rc.conf configuration:
pf_enable="YES" # Enable PF (load module if required) pflog_enable="YES" # start pflogd(8)
There are some differences between the FreeBSD 4.x, 5.x, and later with respect to PF. Refer to the FreeBSD Handbook, specifically the PF section of the “Firewalls” chapter, available from http://www.freebsd.org/, to see which information applies in your case. The PF code in FreeBSD 7 and 8 is equivalent to the code in OpenBSD 4.1 with some bug fixes. The instructions in this book assume that you are running FreeBSD 7.0 or newer.
On FreeBSD, PF is compiled as a kernel-loadable module by default. If your FreeBSD setup runs with a GENERIC kernel, you should be able to start PF with the following:
$sudo kldload pf$sudo pfctl -e
Assuming you have put the lines just mentioned in your /etc/rc.conf and created an /etc/pf.conf file, you could also use the PF rc script to run PF. The following enables PF:
$ sudo /etc/rc.d/pf startAnd this disables the packet filter:
$ sudo /etc/rc.d/pf stopNote
On FreeBSD, the /etc/rc.d/pf script requires at least a line in /etc/rc.conf that reads pf_enable="YES" and a valid /etc/pf.conf file. If either of these requirements is not met, the script will exit with an error message. There is no /etc/pf.conf file in a default FreeBSD installation, so you’ll need to create one before you reboot the system with PF enabled. For our purposes, creating an empty /etc/pf.conf with touch will do, but you could also work from a copy of the /usr/share/examples/pf/pf.conf file supplied by the system.
The supplied sample file /usr/share/examples/pf/pf.conf contains no active settings. It has only comment lines starting with a # character and commented-out rules, but it does give you a preview of what a working rule set will look like. For example, if you remove the # sign before the line that says set skip on lo to uncomment the line, and then save the file as your /etc/pf.conf, once you enable PF and load the rule set, your loopback interface will not be filtered. However, even if PF is enabled on your FreeBSD system, we haven’t gotten around to writing an actual rule set, so PF is not doing much of anything and all packets will pass.
As of this writing (September 2010), the FreeBSD rc scripts do not set up a default rule set as a fallback if the configuration read from /etc/pf.conf fails to load. This means that enabling PF with no rule set or with pf.conf content that is syntactically invalid will leave the packet filter enabled with a default pass all rule set.
On NetBSD 2.0, PF became available as a loadable kernel module that could be installed via packages (security/pflkm) or compiled into a static kernel configuration. In NetBSD 3.0 and later, PF is part of the base system. On NetBSD, PF is one of several possible packet-filtering systems, and you need to take explicit action to enable it.
Some details of PF configuration have changed between NetBSD releases. This book assumes you are using NetBSD 5.0 or later.[10]
To use the loadable PF module for NetBSD, add the following lines to your /etc/rc.conf to enable loadable kernel modules, PF, and the PF log interface, respectively.
lkm="YES" # do load kernel modules pf=YES pflogd=YES
To load the pf module manually and enable PF, enter this:
$sudo modload /usr/lkm/pf.o$sudo pfctl -e
Alternatively, you can run the rc.d scripts to enable PF and logging, as follows:
$sudo /etc/rc.d/pf start$sudo /etc/rc.d/pflogd start
To load the module automatically at startup, add the following line to /etc/lkm.conf:
/usr/lkm/pf.o - - - - BEFORENET
If your /usr filesystem is on a separate partition, add this line to your /etc/rc.conf:
critical_filesystems_local="${critical_filesystems_local} /usr"If there are no errors at this point, you have enabled PF on your system, and you are ready to move on to creating a complete configuration.
The supplied /etc/pf.conf file contains no active settings. It has only comment lines starting with a hash mark (#) and commented-out rules, but it does give you a preview of what a working rule set will look like. For example, if you remove the hash mark before the line that says set skip on lo to uncomment it, and then save the file, once you enable PF and load the rule set, your loopback interface will not be filtered. However, even if PF is enabled on your NetBSD system, we haven’t gotten around to writing an actual rule set, so PF is not doing much of anything but passing packets.
NetBSD implements a default or fallback rule set via the file /etc/defaults/pf.boot.conf. This rule set is intended only to let your system complete its boot process in case the /etc/pf.conf file does not exist or contains an invalid rule set. You can override the default rules by putting your own customizations in /etc/pf.boot.conf.
[9] If you are setting up your first PF configuration on an OpenBSD version earlier than this, the best advice is to upgrade to the most recent stable version. If for some reason you must stay with the older version, it might be useful to consult the first edition of this book, as well as the man pages and other documentation for the specific version you are using.
[10] For instructions on using PF in earlier releases, see the documentation for your release and look up supporting literature listed in Appendix A of this book.