| AUTHPF(8) | System Manager's Manual | AUTHPF(8) | 
authpf —
| authpf | 
authpf is a user shell for authenticating gateways. It
  is used to change pf(4) rules when a
  user authenticates and starts a session with
  sshd(8) and to undo these changes
  when the user's session exits. It is designed for changing filter and
  translation rules for an individual source IP address as long as a user
  maintains an active ssh(1) session.
  Typical use would be for a gateway that authenticates users before allowing
  them Internet use, or a gateway that allows different users into different
  places. authpf logs the successful start and end of a
  session to syslogd(8). This,
  combined with properly set up filter rules and secure switches, can be used to
  ensure users are held accountable for their network traffic.
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.
authpf use the same
  format described in pf.conf(5).
  The only difference is that these rules may (and probably should) use the
  macro user_ip, which is assigned the connecting IP address
  whenever authpf is run. Additionally, the macro
  user_id is assigned the user name.
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.
name=value, one
  per line. Currently, the allowed values are as follows:
authpf displays a message
  telling the user he or she has been authenticated. It will additionally
  display the contents of the file
  /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 maintains the changed filter rules as long as the
  user maintains an active session. It is important to remember however, that
  the existence of this session means the user is authenticated. Because of
  this, it is important to configure
  sshd(8) to ensure the security of
  the session, and to ensure that the network through which users connect is
  secure. sshd(8) should be
  configured to use the ClientAliveInterval and
  ClientAliveCountMax parameters to ensure that a ssh
  session is terminated quickly if it becomes unresponsive, or if arp or address
  spoofing is used to hijack the session. Note that TCP keepalives are not
  sufficient for this, since they are not secure. Also note that the various SSH
  tunnelling mechanisms, such as AllowTcpForwarding and
  PermitTunnel, should be disabled for
  authpf users to prevent them from circumventing
  restrictions imposed by the packet filter ruleset.
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.
authpf program will load
  the appropriate rules. Enter the /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) 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 /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" 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
For a wireless or shared net - This example /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"
# 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
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 authpf,
    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 <mss 1460,nop,nop,sackOK> (DF)
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 <authpf_users> persist
pass in on $ext_if proto tcp from <authpf_users> \
        to port { smtp imap }
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_users> persist anchor "authpf/*" from <authpf_users> rdr-anchor "authpf/*" from <authpf_users>
authpf program first appeared in
  OpenBSD 3.1.
authpf is not designed to prevent users
    from denying service to other users.
| May 31, 2007 | NetBSD 9.4 |