Verrouiller les comptes après des échecs de saisie du mot de passe
Configure pam_faillock pour verrouiller un compte après au plus 3 tentatives d'authentification échouées consécutives (deny ≤ 3).
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
Sans seuil de verrouillage, un attaquant peut essayer des mots de passe indéfiniment jusqu'à en trouver un valide. Plafonner les échecs consécutifs à 3 et verrouiller le compte rend les attaques par force brute en ligne et par pulvérisation de mots de passe impraticables, tout en tolérant la faute de frappe occasionnelle d'un utilisateur légitime.
Ce que vérifie Pavois
Pavois lit le réglage faillock effectif en fusionnant /etc/security/faillock.conf avec chaque fichier additionnel sous /etc/security/faillock.conf.d/ et en prenant la dernière valeur de deny (celle que PAM applique réellement), puis exige qu'elle soit comprise entre 1 et 3. Respecter la priorité des fichiers additionnels est précisément ce qu'une lecture naïve d'un seul fichier manquerait : une dérogation permissive dans un fichier .d annihilerait silencieusement une configuration principale plus stricte.
describe command('v=$(grep -rh \'^[[:space:]]*deny[[:space:]]*=\' /etc/security/faillock.conf /etc/security/faillock.conf.d/ 2>/dev/null | tail -1 | grep -oE \'[0-9]+\'); { [ -n "$v" ] && [ "$v" -le 3 ] && echo ok; } || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Inspectez la valeur fusionnée avec grep -rh '^[[:space:]]*deny' /etc/security/faillock.conf /etc/security/faillock.conf.d/ | tail -1 (attendez deny = 3 ou moins). Vérifiez l'état de verrouillage en direct d'un utilisateur avec faillock --user <nom>. La réexécution de la commande InSpec doit afficher ok.
Inspecter et investiguer
Les tentatives échouées et les verrouillages apparaissent dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (famille RHEL), ou via journalctl -t sshd -t login. Les compteurs par utilisateur et l'état de verrouillage sont affichés par faillock --user <nom> ; réinitialisez-les avec faillock --user <nom> --reset.
Remédiation
pavois harden apply utilise la ressource keyval pour écrire deny = 3 dans le fichier additionnel /etc/security/faillock.conf.d/99-Pavois.conf. Comme ce fichier est lu en dernier, il l'emporte de façon déterministe sur tout réglage plus laxiste du fichier principal, imposant le seuil de verrouillage à toutes les connexions basées sur PAM.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| file | /etc/security/faillock.conf |
|---|---|
| key | deny |
| resource | keyval |
| value | 3 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque de verrouillage involontaire : un mot de passe oublié ou une tâche automatisée utilisant des identifiants périmés peut verrouiller un compte réel après 3 échecs, et verrouiller les comptes root/administrateur peut bloquer une récupération à distance. Avant d'appliquer, assurez-vous de disposer d'une console hors bande ou d'un second compte privilégié, et sachez que faillock --user <nom> --reset déverrouille un compte. Notez qu'un outillage de force brute contre SSH peut rapidement franchir ce seuil pour les utilisateurs ciblés.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R31 | direct | 2.0 | haute |
| CIS | 5.3.3.1.1, 8.3.4 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.8, AC-7(a), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 8.3.4 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-411045, UBTU-24-200610 | direct | per OS STIG release | 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.