The simplest possible PF setup is on a single machine that will not run any services and talks to only one network (which may be the Internet).

We’ll begin with an /etc/pf.conf file that looks like this:

block in all
pass out all keep state

This rule set denies all incoming traffic, allows traffic we send, and retains state information on our connections. PF reads rules from top to bottom; the last rule in a rule set that matches a packet or connection is the one that is applied.

Here, any connection coming into our system from anywhere else will match the block in all rule. Even with this tentative result, the rule evaluation will continue to the next rule (pass out all keep state), but the traffic will not even match the first criterion (the out direction) in this rule. With no more rules to evaluate, the status will not change, and the traffic will be blocked. In a similar manner, any connection initiated from the machine with this rule set will not match the first rule, but will match the second (once again, the wrong direction); matching a pass rule, it is allowed to pass.

We’ll examine the way that PF evaluates rules and how ordering matters in a bit more detail in Chapter 3, in the context of a slightly longer rule set.

For any rule that has a keep state part, PF keeps information about the connection (including various counters and sequence numbers) as an entry in the state table. The state table is where PF keeps information about existing connections that have already matched a rule, and new packets that arrive are compared to existing state table entries to find a match first. Only when a packet does not match any existing state will PF move on to a full rule set evaluation, checking if the packet matches a rule in the loaded rule set. We can also instruct PF to act on state information in various ways, but in a simple case like this, our main goal is to allow return traffic for connections we initiate to return to us.

Note that on OpenBSD 4.1 and later, the default for pass rules is to keep state information,^[11] and we no longer need to specify keep state explicitly in a simple case like this. This means the rule set could be written like this:

# minimal rule set, OpenBSD 4.1 onwards keeps state by default
block in all
pass out all

In fact, you could even leave out the all keyword here if you like.

The other BSDs have mostly caught up with this change by now, and for the rest of this book, we will stick to the newer style rules, with an occasional reminder in case you are using an older system.

It goes pretty much without saying that passing all traffic generated by a specific host implies that the host in question is, in fact, trustworthy. This is something you do only if this is a machine you know you can trust.

When you’re ready to use this rule set, load it with the following:

$ sudo pfctl -ef /etc/pf.conf

The rule set should load without any error messages or warnings. On all but the slowest systems, you should be returned to the $ prompt immediately.

It’s always a good idea to test your rule sets to make sure that they work as expected. Proper testing will become essential once you move on to more complicated configurations.

To test the simple rule set, see if it can perform domain name resolution. For example, you could see if $ host nostarch.com returns information such as the IP address of the host nostarch.com and the hostnames of that domain’s mail exchangers. Or just see if you can surf the Web. If you can connect to external websites by name, the rule set is able to perform domain name resolution. Basically, any service you try to access from your own system should work, and any service you try to access on your system from another machine should produce a Connection refused message.