Authenticating PF

Authenticating PF

One common requirement is for a firewall to require authentication before allowing a user to access the Internet. PF includes this functionality through the use of authpf(8). When a user authenticates via SSH, PF will check several files for PF rules to insert into the ruleset via anchor attachment points. When the user terminates the SSH session, the rules are removed. While SSH can intimidate new users, it's very simple to take any of a variety of free SSH clients and set them up on users' desktops as a "double-click here, log in, read the message, and minimize the icon" tool.

To use authpf, you must properly set up user accounts, make sure your server is configured to use authpf, and set up rules.

User Account Setup

Every user who can authenticate to the firewall needs a shell of /usr/sbin/ authpf. This shell will not allow users to get a command-line shell; it exists solely for authentication purposes. As these users require almost no system resources, you may wish to use a login class (see Chapter 7) to define the shell and very minimal resource allocation. This is also useful if the user login information is distributed from a central source, such as NIS.

Note�

Do not add /usr/sbin/authpf to /etc/shells, unless you want your users to be able to FTP to the firewall host.

Server Setup

Authpf(8) will keep rules in place until the SSH session terminates. An intruder might attempt to hijack an existing SSH connection to gain access out through the firewall. If you're using OpenBSD's integrated OpenSSH, add the following two options to /etc/ssh/sshd_config.

ClientAliveInterval 1 15
ClientAliveCountMax 2 3

This tells sshd(8) to make a keepalive check every 1 15 seconds and to disconnect after 2 three failed keepalive checks. Because keepalives cannot be faked in a hijacked connection, this ensures that any attacker will be disconnected within 60 seconds.

You might also want to create a file /etc/authpf/authpf.message, displaying text to be displayed upon a successful authpf login. This is an excellent place to put your acceptable use policy, network notices, or anything else you want your users to actually see. ^[1] This is much like /etc/motd, but only appears for authpf users.

You can also create a /etc/authpf/authpf.problem file, which will be displayed if there is a problem. This is a good place to put your helpdesk phone number or a link to your internal trouble ticket system.

PF Setup

Most authpf(8) configuration is done in /etc/pf.conf and in the /etc/authpf/ directory. You'll need to configure PF to accept instructions from authpf(8) through the use of anchors. In /etc/authpf/, you must at least have a basic configuration file, authpf.conf, and a rules file, authpf.rules.

/etc/pf.conf

Authpf(8) uses anchor attachment points to insert rules into the running ruleset. Your /etc/pf.conf must include anchor rules. By default, these anchors are named "authpf," but you can change this with an entry in /etc/authpf/ authpf.conf. You must include these anchors, in order, within /etc/pf.conf, for authpf(8) to work.

nat-anchor authpf
rdr-anchor authpf
binat-anchor authpf
anchor authpf

If you are using anchor rules to provide network access, this means that you can also get rid of most general-purpose PF rules. With authpf(8) implementing rules that allow individual workstations out, you can strip your general-purpose PF rules to only those that provide basic network infrastructure support. You'll want to retain the rules to let the world view your website, for example, and maybe rules that let one or two key management workstations SSH out, but authpf(8) should provide most of your rules.

/etc/authpf/authpf.conf

The authpf.conf file is used to set general authpf(8) options. When a client logs in with authpf(8), one of the first things the program does is check for the existence of /etc/authpf/authpf.conf. If that file does not exist, the program immediately exits. If you don't need to set any authpf options, then simply running "touch /etc/authpf/authpf.conf" will suffice to let authpf(8) run normally. (You'll still need to add rules for your users, mind you, but authpf(8) will run.)

Options in authpf.conf are simple "variable=value" pairs. At the time of this writing, authpf.conf only has one option: choice of anchor name. If you don't want to name your anchors "authpf," you can choose a new name here like this:

anchor=newanchorname

If you're happy with the default name, however, just touch(1) /etc/authpf/ authpf.conf to proceed.

Creating authpf(8) Rules

The file /etc/authpf/authpf.rules contains a generic list of rules that will be added to PF when a user successfully authenticates with authpf(8). These rules are completely identical to those used in /etc/pf.conf, with one minor addition. The macro "$user_ip" is used for the IP address that the user authenticated from. You can use this IP address to write very specific rules for outbound access. For example, here's a very generous authpf.rules that allows an authenticated user complete outbound access from behind a NAT device. This assumes that the only entries you have in /etc/pf.conf are those required by authpf(8).

ext_if="fxp1"
nat on $ext_if inet from $user_ip to any -> $ExtIf
pass out log on $ext_if inet from $user_ip to any modulate state

You can, of course, use authpf(8) to create far more restrictive rules. One popular use for authpf(8) is to create a secure wireless gateway. In that case, you almost certainly want to only allow secure network protocols such as SSH, SSL, and IPSEC through PF. The authpf(8) man page contains an example of exactly that configuration.

Per-User Authpf Rules

While most of your users should be given access with the standard rule template, it's entirely possible that you'll have one or two users with special needs. The authpf(8) system includes the ability to use per-user configuration files. If a user has a private configuration file, it will be used. If not, the user will get the configuration given in /etc/authpf/authpf.rules.

Per-user authpf(8) configuration files should be kept in the directory /etc/ authpf/users/username/ and named "authpf.rules." For example, the rules file for the user "chris" would be in the file /etc/authpf/users/chris/authpf.rules.

Do not give users the ability to edit their own authpf.rules files! Remember, the rules in this file are injected directly into the main /etc/pf.conf configuration. If a user was to put in a simple rule that solved all their problems, such as "pass in from any to any keep state," your entire security policy would be eviscerated.

Authpf Access Lists

The authpf(8) system can allow specific users to use authpf, instead of just letting anyone with a system account authenticate to the packet filter. It also includes the ability to ban particular users from using the firewall.

The file /etc/authpf/authpf.allow can contain usernames, one per line. If the file /etc/authpf/authpf.allow exists, PF will only allow users whose usernames appear in that file to use authpf. Without this file, anyone who can authenticate on the firewall machine can get standard user authpf access.

On the other hand, we have the directory /etc/authpf/banned. If the systems administrator does not want a user with an account to use the firewall, he can create a file in this directory with the same name as the username. That user cannot authenticate to the firewall as long as the file exists. For example, once I've had enough of Phil surfing the Net while he should be working I can just do this:

# touch /etc/authpf/banned/phil

Even if the username "phil" appears in /etc/authpf/authpf.allow, he will not be able to authenticate to authpf(8). A ban always overrides a permit. (If Phil made me cranky enough, I could even use chflags(1) to make the file immutable and hence not removable without a reboot. But that wouldn't be professional.)

^[1]"You didn't know we were taking the mail server down over lunch? Well, did you use the Internet today? The message appeared when you logged on." No matter how tempted you are, it is not polite to add words such as "loser" or "moron" to the end of such a statement.