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/*"
The "/*" at the end of the anchor name is required for pf(4) to process the rulesets attached to the anchor by 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.
The
authpf.rules
file must exist in one of the above locations for
authpf
to run.
/etc/authpf/authpf.conf
file.
If the file is empty, defaults are used for all
configuration options.
The file consists of pairs of the form
name=value
,
one per line.
Currently, the allowed values are as follows:
anchor
name instead of "authpf".
table
name instead of "authpf_users".
/etc/authpf/authpf.message
if the file exists and is readable.
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.
On failure, messages will be logged to
syslogd(8)
for the system administrator.
The user does not see these, but will be told the system is unavailable due to
technical difficulties.
The contents of the file
/etc/authpf/authpf.problem
will also be displayed if the file exists and is readable.
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.
authpf
modifies the packet filter and address translation rules, and because
of this it needs to be configured carefully.
authpf
will not run and will exit silently if the
/etc/authpf/authpf.conf
file does not exist.
After considering the effect
authpf
may have on the main packet filter rules, the system administrator may
enable
authpf
by creating an appropriate
/etc/authpf/authpf.conf
file.
/etc/authpf/authpf.conf
/etc/authpf/authpf.allow
/etc/authpf/authpf.rules
/etc/authpf/authpf.message
/etc/authpf/authpf.problem
/etc/authpf/banned/
directory.
If bob has somehow fallen from grace in the eyes of the
powers-that-be, they can prohibit him from using the gateway by creating
the file
/etc/authpf/banned/bob
containing a message about why he has been banned from using the network.
Once bob has done suitable penance, his access may be restored by moving or
removing the file
/etc/authpf/banned/bob
.
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 OpenBSD 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.
To tell the user where to go when the system is broken,
/etc/authpf/authpf.problem
could contain something like this:
Sorry, there appears to be some system problem. To report this
problem so we can fix it, please phone 1-900-314-1597 or send
an email to remove@bulkmailerz.net.
Packet Filter Rules - In areas where this gateway is used to protect a wireless network (a hub with several hundred ports), the default rule set as well as the per-user rules should probably allow very few things beyond encrypted protocols like ssh(1), ssl(8), or ipsec(4). On a securely switched network, with plug-in jacks for visitors who are given authentication accounts, you might want to allow out everything. In this context, a secure switch is one that tries to prevent address table overflow attacks.
Example
/etc/pf.conf
:
# by default we allow internal clients to talk to us using
# ssh and use us as a dns server.
internal_if="fxp1"
gateway_addr="10.0.1.1"
nat-anchor "authpf/*"
rdr-anchor "authpf/*"
binat-anchor "authpf/*"
block in on $internal_if from any to any
pass in quick on $internal_if proto tcp from any to $gateway_addr \
port = ssh
pass in quick on $internal_if proto udp from any to $gateway_addr \
port = domain
anchor "authpf/*"
For a switched, wired net
- This example
pass in log quick on $internal_if proto tcp from $user_ip to any
pass in quick on $internal_if from $user_ip to any
/etc/authpf/authpf.rules
makes no real restrictions; it turns the IP address on and off, logging
TCP connections.
external_if = "xl0"
internal_if = "fxp0"
For a wireless or shared net
- This example
# rdr ftp for proxying by ftp-proxy(8)
rdr on $internal_if proto tcp from $user_ip to any port 21 \
-> 127.0.0.1 port 8021
# allow out ftp, ssh, www and https only, and allow user to negotiate
# ipsec with the ipsec server.
pass in log quick on $internal_if proto tcp from $user_ip to any \
port { 21, 22, 80, 443 }
pass in quick on $internal_if proto tcp from $user_ip to any \
port { 21, 22, 80, 443 }
pass in quick proto udp from $user_ip to $ipsec_gw port = isakmp
pass in quick proto esp from $user_ip to $ipsec_gw
/etc/authpf/authpf.rules
could be used for an insecure network (such as a public wireless network) where
we might need to be a bit more restrictive.
internal_if="fxp1"
ipsec_gw="10.2.3.4"
Dealing with NAT
- The following
/etc/authpf/authpf.rules
shows how to deal with NAT, using tags:
ext_if = "fxp1"
ext_addr = 129.128.11.10
int_if = "fxp0"
# nat and tag connections...
nat on $ext_if from $user_ip to any tag $user_ip -> $ext_addr
pass in quick on $int_if from $user_ip to any
pass out log quick on $ext_if tagged $user_ip
With the above rules added by
,
outbound connections corresponding to each users NAT'ed connections
will be logged as in the example below, where the user may be identified
from the ruleset name.
# tcpdump -n -e -ttt -i pflog0
Oct 31 19:42:30.296553 rule 0.bbeck(20267).1/0(match): pass out on fxp1: \
129.128.11.10.60539 > 198.137.240.92.22: S 2131494121:2131494121(0) win \
16384
Using the authpf_users table
- Simple
authpf
settings can be implemented without an anchor by just using the "authpf_users"
table
.
For example, the following
pf.conf(5)
lines will give SMTP and IMAP access to logged in users:
table
It is also possible to use the "authpf_users"
table
in combination with anchors.
For example,
pf(4)
processing can be sped up by looking up the anchor
only for packets coming from logged in users:
table
authpf is not designed to prevent users from denying service to other users.