Building Firewalls With OpenBSD And PF, 2nd Edition (2003)

#allow connections to SSH on the internal interface (otherwise

#joe, residing in the private network segment will not be able

#to connect and authenticate.

pass in on $int_if inet proto tcp \

from any to ($int_if) port 22 flags S/SA synproxy state anchor authpf

Make a copy of /etc/pf.conf:

# cp /etc/pf.conf /etc/pf.conf.old

Open /etc/pf.conf and edit it, so it contains rules similar to those shown earlier.

Save /etc/pf.conf (press Esc, type :x and hit the Enter/Return key).

Reload the ruleset (this is best done from the console and not over the network, if you make a mistake you might cut yourself off the line):

# pftcl -F all ; pfctl -f /etc/pf.conf

Create a ruleset for joe:

# vi /etc/authpf/users/joe/authpf.rules

And type this:

# MACROS ext_if = "ne1"

# allow user joe to connect to HTTP servers pass out on $ext_if inet proto tcp \

from $user_ip to any port 80 flags S/SA synproxy state

Save joe's ruleset (press Esc, type :x and hit the Enter/Return key).

Use an SSH client (command-line or window-based) to connect to the Œrewall from one of the machines on the private network. You should see the following message:

Hello, joe, You are authenticated from host "192.168.32.12" Where are you going with that NIC in your hand?

That's it! You can now repeat this process for other users.

Later on, when you want to see who's authenticating on your Œrewall, use:

# ps -ax | grep authpf

from spammers, the load it places on the system is negligible and because it's job is very well-deŒned, conŒguring it is a breeze.

Out of all options listed in spamd(8), the two that are most important are:

ƒ-p port Š speciŒes which port should spamd(8) listen for connections on. This cannot be port 25, since that is where the real sendmail(8) or other MTA is listening on. Choose one on of the higher ports that are not used for anything else, like 8025, 8125, etc.

ƒ-c connections Š the maximum number of concurrent connections accepted by spamd(8). The default is 200, but you can adjust it up or down, as you wish.

Other options are explained in spamd(8) and we are not going to dwell on them here. If you are not sure which ones you need, let spamd(8) use the defaults.

You can start spamd(8) from the command line:

# spamd -p 8025 -c 200

Or, to start spamd(8) automatically at system startup add the following line to /etc/rc.local:

spamd -p 8025 -c 200

Because spamd(8) is not listening on port 25, pf(4) must redirect connections from spammers' hosts to the port deŒned with the -p option (in our case, 8025). The list of spammer's addresses will be held in the <spamd> table, that can be updated while pf(4) and spamd(8) are running.

The contents of /etc/pf.conf will differ depending on where the MTA is running. If you are new to pf(4) and spamd(8) start with these simple rulesets. First, we assume that the MTA is running on the Œrewall host. It listens on port 25, as all MTAs do:

# MACROS ext_if = "ne1"

# Tables

table <spamd> persist

You should now see a banner of the MTA waiting for delivery of mail.

Once it is running, spamd(8) is designed to be conŒgurable in-•ight, and comes with a conŒguration utility, spamd-setup(8) which sends conŒguration directives and makes changes to the spamd table automatically. It does its magic by parsing the spamd.conf(5) conŒguration Œle located in /etc/spamd.conf, retrieving blacklists (lists of addresses known to send spam), and removing addresses from whitelists (addresses that we never want to put on a blacklist, even if they manage to get on some blacklist). Then, it sends the data in the format understood by spamd(8) to the port that the daemon is listening on.

Spamd-setup(8) must be run from root account or form another user's account as long as it has access to run it via sudo(8). It's best to run spamdsetup at regular intervals from cron(8).

244

Chapter 14

Ruleset Optimization

Every CPU cycle counts. Here are a few ideas on how to save them.

The job of a Œrewall administrator does not stop once the rules are working and the Œrewall is doing its job. Another, quite often forgotten step, is the optimization of Œrewall rules.

The aim of optimization is to make your Œrewall do its job in shorter time and using less CPU time and memory. While such problems may seem distant to small network administrator, they are very familiar to administrators of busy networks where every delay is magniŒed and perceived by the users as a slow or unreliable connection.

14.1 The pf Optimization Checklist

Pf(4) does a very good job of automatically optimizing rulesets, but you can help it in various ways:

ƒWrite clean rules. It's as obvious as that, but often forgotten. Simple, short rules are not only easier to understand, but also easier for pf(4) to optimize and more efŒcient.

ƒLearn to use the quick keyword. This little keyword can greatly speed up the process of ruleset evaluation. Think about it, if your packet Œltering section contains 100 rules, but most of the trafŒc is matched by the Œrst rule and not the other 99 rules, then the time required to parse these rules is wasted. If you add the quick keyword to the Œrst rule, then you will save a lot of CPU time and speed up your Œrewall at no cost. For more information see Chapter 8, Packet Filtering.

ƒLearn to use the pass keyword in NAT rules. Its' job is similar to the quick keyword in packet Œltering rules. It skips the packet Œltering section and passes packets directly to the destination address.

ƒChange the order of rules. Another trick, related to the previous idea is

changing the order of the rules in the packet Œltering section. If you use rules with the quick keyword, put them before those without the quick keyword.

ƒUse tables instead of lists of addresses. Tables are more efŒcient than lists of addresses. Read Chapter 5, /etc/pf.conf and Chapter 9, Dynamic

Rulesets.

ƒDo not use ppp packet Œltering. Although ppp comes with its own packet Œlter, which you can use for Œltering dial-up connections (that includes various DSL devices as well as analog modems, or digital ISDN modems), pf(4) will be a much safer solution.

ƒUse bridge packet Œltering. If possible, conŒgure your Œrewall as an invisible Œltering bridge. It is a very secure solution. Consult Chapter 4,

ConŒguring OpenBSD.

ƒOutsource logging. Send logs to another machine. Read Chapter 11,

Logging and Log Analysis.

ƒUpgrade your network hardware. Yup, faster cards, hubs, switches, and better cabling might help.

ƒUse bandwidth shaping. This might require a faster machine with more RAM, but with ALTQ you will be able to control patterns of usage of your network. More information in Chapter 10, Bandwidth Shaping and

Load Balancing.

ƒRe-design your network. When your Œrewall cannot keep up with the growth of your network, it doesn't necessarily mean that it's the fault of pf(4). For example, when a NAT-ing Œrewall starts to clog the network, you might be running out of ports on the external interface (for a solution, read Chapter 7, Packet Redirection. On other times, visitors to your web site might be getting too many `server busy' responses. If that is the case, you might want to consider adding another HTTP server and implementing load balancing.

ƒUpgrade your hardware. When all else fails, upgrade the machine you run OpenBSD and pf(4) on. Pay careful attention to the efŒciency of all subsystems: disks, system bus, memory, and network cards. The processor speed is not the only, and not the most important parameter here.

14.2 Pf Optimization Options

The optimization rule controls the packet Œlter engine optimization options. The old optimization options -O found in earlier version of have been replaced with the optimization algorithm rule. There are six values of the algorithm argument: