CONTENTS

SYNOPSIS

DESCRIPTION

authpf can add filter and translation rules using the syntax described in pf.conf(5). authpf requires that the pf(4) system be enabled before use. authpf can also maintain the list of IP address of connected users in the "authpf_users" table.

authpf is meant to be used with users who can connect via ssh(1) only. On startup, authpf retrieves the client’s connecting IP address via the SSH_CLIENT environment variable and, after performing additional access checks, reads a template file to determine what filter and translation rules (if any) to add. On session exit the same rules that were added at startup are removed.

Each authpf process stores its rules in a separate ruleset inside a pf(4) anchor shared by all authpf processes. By default, the anchor name "authpf" is used, and the ruleset names equal the username and PID of the authpf processes as "username(pid)". The following rules need to be added to the main ruleset /etc/pf.conf in order to cause evaluation of any authpf rules:
nat-anchor "authpf/*"
rdr-anchor "authpf/*"
binat-anchor "authpf/*"
anchor "authpf/*"

Filter and translation rules are stored in a file called authpf.rules. This file will first be searched for in /etc/authpf/users/$USER/ and then in /etc/authpf/. Only one of these files will be used if both are present.

Per-user rules from the /etc/authpf/users/$USER/ directory are intended to be used when non-default rules are needed on an individual user basis. It is important to ensure that a user can not write or change these configuration files.

USER MESSAGES

There exist two methods for providing additional granularity to the control offered by authpf - it is possible to set the gateway to explicitly allow users who have authenticated to ssh(1) and deny access to only a few troublesome individuals. This is done by creating a file with the banned user’s login name as the filename in /etc/authpf/banned/. The contents of this file will be displayed to a banned user, thus providing a method for informing the user that they have been banned, and where they can go and how to get there if they want to have their service restored. This is the default behaviour.

It is also possible to configure authpf to only allow specific users access. This is done by listing their login names, one per line, in /etc/authpf/authpf.allow. If "*" is found on a line, then all usernames match. If authpf is unable to verify the user’s permission to use the gateway, it will print a brief message and die. It should be noted that a ban takes precedence over an allow.

authpf will remove state table entries that were created during a user’s session. This ensures that there will be no unauthenticated traffic allowed to pass after the controlling ssh(1) session has been closed.

authpf is designed for gateway machines which typically do not have regular (non-administrative) users using the machine. An administrator must remember that authpf can be used to modify the filter rules through the environment in which it is run, and as such could be used to modify the filter rules (based on the contents of the configuration files) by regular users. In the case where a machine has regular users using it, as well as users with authpf as their shell, the regular users should be prevented from running authpf by using the /etc/authpf/authpf.allow or /etc/authpf/banned/ facilities.

Now consider a workgroup containing alice, bob, carol and dave. They have a wireless network which they would like to protect from unauthorized use. To accomplish this, they create the file /etc/authpf/authpf.allow which lists their login ids, one per line. At this point, even if eve could authenticate to sshd(8), she would not be allowed to use the gateway. Adding and removing users from the work group is a simple matter of maintaining a list of allowed userids. If bob once again manages to annoy the powers-that-be, they can ban him from using the gateway by creating the familiar /etc/authpf/banned/bob file. Though bob is listed in the allow file, he is prevented from using this gateway due to the existence of a ban file.

Distributed Authentication - It is often desirable to interface with a distributed password system rather than forcing the sysadmins to keep a large number of local password files in sync. The login.conf(5) mechanism in
.Ox can be used to fork the right shell. To make that happen, login.conf(5) should have entries that look something like this:
shell-default:shell=/bin/csh

default:\
...
:shell=/usr/sbin/authpf

daemon:\
...
:shell=/bin/csh:\
:tc=default:

staff:\
...
:shell=/bin/csh:\
:tc=default:

Using a default password file, all users will get authpf as their shell except for root who will get /bin/csh.

SSH Configuration - As stated earlier, sshd(8) must be properly configured to detect and defeat network attacks. To that end, the following options should be added to sshd_config(5):
Protocol 2
ClientAliveInterval 15
ClientAliveCountMax 3

This ensures that unresponsive or spoofed sessions are terminated within a minute, since a hijacker should not be able to spoof ssh keepalive messages.

Banners - Once authenticated, the user is shown the contents of /etc/authpf/authpf.message. This message may be a screen-full of the appropriate use policy, the contents of /etc/motd or something as simple as the following:
This means you will be held accountable by the powers that be
for traffic originating from your machine, so please play nice.

SEE ALSO

HISTORY

BUGS