S'assurer que le module pam_faillock est activé
Garantit que pam_faillock.so est présent dans la pile auth de PAM afin que les échecs de connexion soient comptés et que les comptes soient verrouillés après trop d'échecs.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Verrouiller les identifiants après un certain nombre d'échecs de connexion consécutifs atténue les attaques par force brute contre le système. Sans pam_faillock, un attaquant peut essayer des mots de passe indéfiniment à la vitesse de la machine ; le module est le point d'application qui transforme une politique de verrouillage en contrôle réel.
Ce que vérifie Pavois
Pavois recherche dans la pile PAM effective sous /etc/pam.d/ une ligne pam_faillock.so active (non commentée). Comme PAM assemble sa pile à partir de common-auth et de chaînes @include, vérifier l'ensemble résolu des fichiers détecte le cas où le module est déclaré quelque part mais retiré par un drop-in, ce qu'une analyse mono-fichier ne verrait pas.
describe command('grep -RqE \'^[^#]*\bpam_faillock\\.so\b\' /etc/pam.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Exécutez grep -rE '^[^#]*pam_faillock\.so' /etc/pam.d/ ; au moins une ligne auth active doit référencer le module (généralement deux : une entrée preauth et une authfail). faillock devrait aussi s'exécuter sans erreur et afficher les compteurs par utilisateur.
Inspecter et investiguer
Les échecs suivis et les verrouillages apparaissent dans /var/log/auth.log (Debian/Ubuntu). L'état par utilisateur s'affiche avec faillock --user <nom> et se réinitialise avec faillock --user <nom> --reset.
Remédiation
pavois harden apply utilise la ressource pam_faillock pour activer le module : elle insère les lignes preauth/authfail requises dans la pile auth via l'outillage PAM de la distribution (pam-auth-update sur Debian/Ubuntu) afin que la configuration soit correcte et persistante au fil des mises à jour de PAM.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| params | audit silent even_deny_root |
|---|---|
| resource | pam_faillock |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Une ligne pam_faillock.so mal placée ou dupliquée peut verrouiller des utilisateurs légitimes, voire tous, et un seuil trop strict permet un déni de service trivial en simulant des échecs sur des noms d'utilisateur connus. Précautions : gardez une session root/console ouverte pendant l'édition de PAM, validez la connexion depuis un second terminal avant de vous déconnecter, fixez un deny/unlock_time raisonnable, et gardez faillock --reset à portée pour récupérer un compte verrouillé.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.3.2.2 | direct | per OS, see the benchmark table | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.