OpenBSD PF: User Shell for Authenticating Gateways (authpf) : (v1.60 ; 05/05/2021)
— [ FAQ Index ] | [ Index PF ] ~ Traduction française de la page OpenBSD PF : Shell Utilisateur pour Authentification de Passerelles (authpf) —
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 :
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
:
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 :
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 :
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 :
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 :