Verrouillage de compte ou bannissement d’adresse : où OpenVPN compte réellement

Bloquer une adresse et verrouiller un compte sont deux mécanismes distincts, et ils échouent dans des directions opposées. Un bannissement d’adresse arrête une source et laisse le compte visé joignable depuis ailleurs ; un verrouillage de compte arrête cette identité partout, y compris sur l’ordinateur portable de l’utilisateur légitime.

Pour un VPN qui délègue l’authentification à PAM, le compteur est ce que la pile PAM atteint, non ce que l’écouteur a journalisé.

Deux compteurs, deux victimes différentes

Un limiteur de débit observe une source et demande combien de tentatives en sont venues récemment. Un verrou observe une identité et demande combien d’échecs ce compte a accumulés. Le premier protège la disponibilité, le second le secret ; aucun ne remplace l’autre.

C’est pourquoi la phrase nous bloquons l’IP après cinq échecs n’est pas une réponse à un rapport de bourrage d’identifiants. L’attaquant fait tourner les sources, chacune reçoit peu de tentatives, et le compte n’est jamais compté. À l’inverse, un verrou sans contrôle de source permet à l’attaquant de garder le compte verrouillé indéfiniment en échouant exprès.

Les deux contrôles ont aussi des histoires de récupération différentes. Un bannissement d’adresse expire selon une minuterie à laquelle personne n’a à penser ; un verrouillage peut exiger un administrateur, une période d’attente documentée ou une réinitialisation en libre-service.

Trouvez le magasin qui détient déjà le décompte

Avant d’ajouter quoi que ce soit, déterminez si un magasin d’échecs existe déjà. Un compte Linux local, un service d’annuaire et un fournisseur d’identité externe tiennent chacun leur propre décompte, et un module PAM placé devant eux en crée un second au lieu d’étendre le premier.

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

Lisez le fichier de service que le VPN nomme réellement et suivez ses lignes d’inclusion. Sur beaucoup de distributions, le service VPN inclut un fichier commun, ce qui signifie que le décompte que vous réglez s’applique aussi à SSH et aux connexions locales.

Si l’annuaire impose déjà un verrou, la question utile est de savoir comment la conversation PAM parvient à cette décision et comment le VPN la rapporte. Un décompte local ajouté par-dessus ne devient pas le compteur de l’annuaire, et les deux politiques peuvent diverger sur le moment où le compte se déverrouille.

pam_faillock a trois positions d’appel, pas une

Le module sépare trois opérations qu’une ligne copiée confond souvent : vérifier si le compte est déjà verrouillé, enregistrer un échec et effacer l’historique après un succès.

C’est là que la migration depuis un module de décompte plus ancien se trompe généralement. Copier une ligne d’un exemple pam_tally2 qui fonctionne dans une pile pam_faillock n’est pas un renommage ; la configuration documentée diffère, et un appel mal placé peut enregistrer des échecs sans jamais les vérifier.

faillock --user alice
faillock --user alice --reset

L’utilitaire d’inspection est le moyen le plus rapide de voir si le compteur est réel : il affiche les échecs enregistrés pour un compte et peut les effacer. Si un échec contrôlé ne change pas cette sortie, la position de l’appel est erronée.

Un nom de service dédié n’est pas une isolation

Donner au VPN son propre fichier de service PAM rend la politique voulue visible, mais ne limite pas l’effet. Toute inclusion d’un fichier commun entraîne ce que ce fichier fait, y compris des décomptes valables pour tout le système.

Décidez explicitement si le verrou doit couvrir seulement l’accès VPN ou chaque service qui authentifie le même compte. Les deux réponses sont défendables ; l’échec consiste à croire avoir choisi l’une alors que la pile applique l’autre.

Tenez ensuite compte du coût. Un attaquant peut déclencher le verrou, et l’utilisateur qui souffre est le propriétaire du compte. Le seuil, la période d’attente et le chemin de récupération administrative font partie de la politique, et la récupération ne doit pas dépendre d’une reconfiguration du VPN pendant un incident.

Acceptez la séquence, pas un seul rejet

Testez avec des identités désignées selon un plan approuvé, et testez une chaîne plutôt qu’un événement isolé : un compte valide s’authentifie, un mot de passe délibérément faux déplace le compteur, le verrou configuré prend effet et la récupération documentée rend l’accès.

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

Examinez le comportement en cas de succès aussi soigneusement que celui en cas d’échec. Si une connexion réussie n’efface pas l’historique, un compte se verrouillera après une accumulation lente d’erreurs ordinaires. Si elle efface tout dans chaque service, le compteur est plus faible que ne le prétend la politique.

Enfin, arrêtez les clients non surveillés avant de déclarer la victoire. Un identifiant enregistré qui réessaie en arrière-plan recréera les échecs quelques minutes après une récupération et verrouillera de nouveau le compte. La limitation de débit par source peut rester comme contrôle supplémentaire, mais ce n’est pas la politique du compte.