L'utilitaire authpf(8) est un shell utilisateur pour l'authentification sur les passerelles. Une passerelle d'authentification est simplement une passerelle réseau régulière (aussi connu comme routeur) excepté que les utilisateurs doivent en premier s'authentifier eux-mêmes avant que leur trafic soit permis de passer. Quand un shell utilisateur est paramétré vers /usr/sbin/authpf et qu'il ou elle se connecte en utilisant SSH, authpf fera les changements nécessaires pour activer le jeu de règles pf(4) ainsi le trafic utilisateur est passé au-travers le filtrage et/ou la translation utilisant la NAT ou la redirection. Une fois que l'utilisateur se déconnecte ou que la session est déconnectée, authpf enlèvera toutes règles chargées pour l'utilisateur et détruira toutes les connexions suivies que l'utilisateur a ouvert. À cause de cela, la capacité de l'utilisateur à passer son trafic au-travers de la passerelle existe seulement tant que l'utilisateur garde sa session SSH ouverte.

Les règles utilisateur sont chargées dans un unique point d'ancre par authpf. L'ancre est nommée par combinaison du nom utilisateur et de l'identifiant du processus d'authpf au format username(PID). Chaque ancre utilisateur est enregistrée dans l'ancre authpf qui est liée à son tour au jeu de règles principal. Le chemin de l'ancre pleinement qualifié devient alors :

main_ruleset/authpf/username(PID)

Les règles qu'authpf charge peuvent être configurées par utilisateur ou de manière globale.

Exemple d'usage d'authpf :

• Requiert que les utilisateur s'authentifient avant de permettre l'accès à internet.
• Accorder à certains utilisateurs, tels les administrateurs, des accès restreints à certaines parties du réseau.
• Permettre aux seuls utilisateurs connus d'accéder au reste du réseau ou d'internet depuis un réseau sans fil.
• Permettre aux travailleurs depuis leur maison ou n'importe où d'accéder aux ressources sur le réseau de l'entreprise. Les utilisateurs hors bureau peuvent non seulement accéder au réseau entreprise, mais aussi être redirigé vers des ressources particulières (leurs propres bureaux, par exemple) basées sur les noms utilisateurs qu'ils utilisent pour s'authentifier.
• Dans un contexte tel qu'une bibliothèque ou un autre endroit avec des terminaux d'accès publiques à Internet, PF doit être configuré pour permettre les accès limités à Internet aux utilisateurs invités. Les utilisateurs enregistrés peuvent alors obtenir un accès complet.

L'outil authpf journalise le nom utilisateur et l'IP de chaque utilisateur qui s'authentifie avec succès, aussi que le début et la fin de leur temps de connexion de session via syslogd(8). En utilisant cette information, un administrateur peut déterminer qui est connecté, quand et aussi rendre les utilisateurs responsables de leur trafic réseau.

Les étapes de bases nécessitant de configurer authpf sont décrites ici. Pour une complète description de la configuration d'authpf, veuillez-vous référer à la page de manuel.

L'utilitaire authpf ne fonctionne pas si le fichier de configuration /etc/authpf/authpf.conf n'est pas présent. Le fichier peut être vide, mais à moins qu'il ne soit présent, authpf s'arrêtera immédiatement après que l'utilisateur s'authentifie avec succès.

Les directives de configuration suivantes doivent être placées dans authpf.conf :

• anchor=name - Utiliser pour spécifier l'ancre name au lieu de authpf.
• table=name - Utiliser pour spécifier la table name au lieu de authpf_users.

Pour lier authpf dans le jeu de règles principal, utilisez une règle anchor :

anchor "authpf/*"

Chaque fois que la règle anchor est placée dans le jeu de règles, PF sortira du jeu de règles principal pour évaluer les règles authpf.

Les règles authpf peuvent être chargées depuis un de ces deux fichiers :

• /etc/authpf/users/$USER/authpf.rules
• /etc/authpf/authpf.rules

Le premier fichier contient les règles qui sont seulement chargées quand l'utilisateur $USER (qui est remplacé avec le nom utilisateur de l'utilisateur) se connecte. La configuration de règle par utilisateur est utilisée quand un utilisateur spécifique, tel qu'un administrateur, requiert un ensemble de règles différent de celui par défaut. Le second fichier contient les règles par défaut qui sont chargées pour chaque utilisateur qui n'a pas son propre fichier authpf.rules. Si le fichier spécifique à un utilisateur existe, il surchargera le fichier par défaut. Au moins un de ces fichiers doit exister ou authpf ne pourra fonctionner.

Les règles ont la même syntaxe que tout autre jeu de règles PF à l'exception près qu'authpf permet l'utilisation de deux macros prédéfinies :

• $user_ip - l'adresse IP de l'utilisateur connecté
• $user_id - le nom utilisateur de l'utilisateur connecté

Il est recommandé d'utiliser la macro $user_ip pour permettre seulement le trafic au-travers la passerelle depuis un ordinateur sur lequel l'utilisateur est authentifié.

En plus de la macro $user_ip, authpf utilisera la table authpf_users (si elle existe) pour enregistrer les adresses IP des utilisateurs authentifiés. Assurez-vous de définir la table avant de l'utiliser :

table <authpf_users> persist
pass in on egress proto tcp from <authpf_users> to port smtp

Cette table doit être seulement utilisée dans les règles qui doivent s'appliquer à tous les utilisateurs authentifiés.

Des utilisateurs spécifiques peuvent être empêchés d'utiliser authpf en créant un fichier à leur nom utilisateur dans le répertoire /etc/authpf/banned/. Le contenu de ce fichier sera affiché à l'utilisateur avant qu'authpf le déconnecte. Ceci fournit une manière pratique de notifier l'utilisateur des raisons pour lesquelles son accès est interdit et qui contacter pour restaurer son accès.

Inversement, il est aussi possible de permettre des accès spécifiques aux utilisateurs en plaçant leur nom utilisateur dans le fichier /etc/authpf/authpf.allow. Si le fichier n'existe pas ou si le symbole “*” est écrit dans le fichier, alors authpf permettra l'accès à tout utilisateur qui se connecte avec succès via SSH aussi longtemps qu'il n'est pas explicitement banni.

Si authpf est incapable de déterminer quel nom utilisateur est permis ou refusé, il affichera un bref message et ensuite déconnectera l'utilisateur. Une entrée dans /etc/authpf/banned/ surcharge toujours une entrée dans /etc/authpf/authpf.allow.

Chaque fois qu'un utilisateur s'authentifie avec succès à authpf, une salutation est affichée qui indique à l'utilisateur qu'il est authentifié.

Hello charlie. You are authenticated from host "198.51.100.10"

Ce message peut être complété par un message personnalisé dans /etc/authpf/authpf.message. Le contenu de ce fichier sera affiché après le message de bienvenue par défaut.

Afin qu'authpf fonctionne, il doit être assigné comme shell de connexion à l'utilisateur. Quand l'utilisateur s'authentifie avec succès sur sshd(8), authpf sera exécuté en tant que shell utilisateur. Il vérifiera alors si l'utilisateur est autorisé à utiliser authpf, chargera les règles depuis le fichier approprié, etc…

Il y a deux manières d'assigner authpf en tant que shell utilisateur :

1. Manuellement pour chaque utilisateur en utilisant chsh(1), vipw(8), useradd(8), usermod(8), etc…
2. En assignant une classe de connexion aux utilisateurs et en changeant l'option de classe shell dans login.conf(5).

Lors de l'utilisation d'authpf sur un système qui a des comptes utilisateurs réguliers et des comptes utilisateurs authpf, il peut être bénéfique d'utiliser une classe de connexion séparée pour les utilisateurs d'authpf. Cela permet de faire certains changements sur ces comptes de manière globale, et aussi d'allouer différentes politiques placées sur les comptes réguliers et les comptes authpf. Quelques exemples de politiques qui peuvent être paramétrées :

• shell - Spécifier un shell de connexion à l'utilisateur. Cela peut être utilisé pour forcer le shell utilisateur vers authpf indépendamment de l'entrée dans la base de données passwd(5).
• welcome - Spécifier quel fichier motd(5) à afficher quand l'utilisateur se connecte. Cela est utile pour afficher des messages qui sont adressés uniquement aux utilisateurs d'authpf.

Les classes de connexion sont créées dans le fichier login.conf(5). OpenBSD est fourni avec une classe de connexion authpf définie telle que :

authpf:\
    :welcome=/etc/motd.authpf:\
    :shell=/usr/sbin/authpf:\
    :tc=default:

Les utilisateurs sont assignés à une classe de connexion en éditant le champ class de l'entrée de la base de données passwd(5) de l'utilisateur. Une manière de faire cela est d'utiliser la commande chsh(1).

Une fois qu'un utilisateur est connecté avec succès et qu'authpf a ajusté les règles PF, authpf change son titre de processus pour indiquer le nom utilisateur et l'adresse IP de l'utilisateur connecté :

# ps -ax | grep authpf
23664 p0  Is+     0:00.11 -authpf: charlie@192.168.1.3 (authpf)

Ici l'utilisateur charlie est connecté depuis la machine 192.168.1.3. Par l'envoi d'un signal SIGTERM au processus d'authpf, l'utilisateur peut forcer la déconnexion. Toutes les règles chargées pour l'utilisateur seront supprimées et les connexions d'état que l'utilisateur a ouvert seront détruites.

# kill -TERM 23664

L'outil authpf est utilisé sur une passerelle OpenBSD pour authentifier les utilisateurs sur un réseau sans fil, partie d'un grand réseau de campus. Il sera permis aux utilisateur authentifiés de sortir de la connexion SSH et de naviguer sur le web (incluant les sites web sécurisés) en plus d’accéder aux serveurs DNS du campus, en assumant le fait qu'ils ne soient pas sur une liste de bannis.

Le fichier /etc/authpf/authpf.rules contient les règles suivantes :

wifi_if = "wi0"

pass in quick on $wifi_if \
   proto tcp from $user_ip to any port { ssh, http, https }

L'administrateur charlie a besoin d'être capable d'accéder aux serveurs SMTP et POP3 du campus en plus de surfer sur le web et d'utiliser SSH. Les règles suivantes sont paramétrées dans /etc/authpf/users/charlie/authpf.rules :

wifi_if = "wi0"
smtp_server = "10.0.1.50"
pop3_server = "10.0.1.51"

pass in quick on $wifi_if \
   proto tcp from $user_ip to $smtp_server port smtp
pass in quick on $wifi_if \
   proto tcp from $user_ip to $pop3_server port pop3
pass in quick on $wifi_if \
   proto tcp from $user_ip to port { ssh, http, https }

La jeu de règles principal /etc/pf.conf est paramétré ainsi :

wifi_if = "wi0"
ext_if  = "fxp0"
dns_servers = "{ 10.0.1.56, 10.0.2.56 }"

table <authpf_users> persist

block drop all

pass out quick on $ext_if \
   inet proto { tcp, udp, icmp } from { $wifi_if:network, $ext_if }

pass in quick on $wifi_if \
   inet proto tcp from $wifi_if:network to $wifi_if port ssh

pass in quick on $wifi_if \
   inet proto { tcp, udp } from <authpf_users> to $dns_servers port domain

anchor "authpf/*" in on $wifi_if

Le jeu de règles est très simple et fait ce qui suit :

• Bloque tout trafic (refus par défaut).
• Laisse passer en sortie le trafic TCP, UDP, et ICMP sur l'interface externe depuis le réseau sans fil et depuis la passerelle elle-même.
• Laisse passer le trafic SSH entrant depuis le réseau sans fil destiné à la passerelle elle-même. (Cette règle est nécessaire pour permettre aux utilisateurs de se connecter).
• Laisse passer les requêtes DNS entrantes depuis tous les utilisateurs authpf authentifiés vers les serveurs DNS du campus.
• Créer le point d'ancrage “authpf” pour le trafic entrant depuis l'interface sans fil.

L'idée derrière le jeu de règles principal est de tout bloquer et d'autoriser le moins de trafic possible. Le trafic est libre de circuler sur l'interface externe, mais il est bloqué en entrée sur l'interface sans fil par la politique de refus par défaut. Le trafic des utilisateurs authentifies est autorisé à passer sur l'interface sans fil et à traverser la passerelle vers le reste du réseau. Le mot clé quick est utilisé afin que PF n'ait pas à évalué chaque jeu de règles nommé quand une nouvelle connexion passe au-travers de la passerelle.

Cette page est la traduction officieuse de la page “User shell for authenticating gateways (authpf)“ de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.

Contribut(rice|eur)s :