Définir la durée de verrouillage après des échecs de saisie du mot de passe
Configure pam_faillock pour qu'un compte verrouillé le reste pendant au moins 900 secondes (15 minutes) avant de pouvoir être réutilisé (unlock_time ≥ 900).
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
Un seuil de verrouillage ne ralentit un attaquant que si le verrou dure assez longtemps pour rendre les tentatives répétées inutiles. Maintenir le compte verrouillé au moins 15 minutes après l'atteinte de la limite réduit drastiquement le nombre de mots de passe pouvant être essayés par heure, déjouant la force brute en ligne et la pulvérisation de mots de passe tout en permettant à un utilisateur légitime de réessayer après une courte attente.
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 unlock_time (celle que PAM applique réellement), puis exige qu'elle soit ≥ 900. Respecter la priorité des fichiers additionnels est important : un unlock_time court dans un fichier .d remplacerait une valeur plus longue de la configuration principale, et seule la lecture du résultat fusionné effectif le détecte.
describe command('v=$(grep -rh \'^[[:space:]]*unlock_time[[:space:]]*=\' /etc/security/faillock.conf /etc/security/faillock.conf.d/ 2>/dev/null | tail -1 | grep -oE \'[0-9]+\'); { [ -n "$v" ] && [ "$v" -ge 900 ] && 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:]]*unlock_time' /etc/security/faillock.conf /etc/security/faillock.conf.d/ | tail -1 (attendez unlock_time = 900 ou plus). L'état de verrouillage en direct par utilisateur est affiché par faillock --user <nom>. La réexécution de la commande InSpec doit afficher ok.
Inspecter et investiguer
Les tentatives échouées et les événements de verrouillage sont enregistrés dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (famille RHEL), ou via journalctl -t sshd -t login. Inspectez ou réinitialisez les compteurs d'un utilisateur avec faillock --user <nom> et faillock --user <nom> --reset.
Remédiation
pavois harden apply utilise la ressource keyval pour écrire unlock_time = 900 dans le fichier additionnel /etc/security/faillock.conf.d/99-Pavois.conf. Lu en dernier, ce fichier l'emporte de façon déterministe sur toute valeur plus courte du fichier principal, imposant la durée minimale 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 | unlock_time |
| resource | keyval |
| value | 900 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un utilisateur verrouillé doit attendre 15 minutes (ou demander à un administrateur d'exécuter faillock --user <nom> --reset) avant de réessayer. Combiné à un seuil deny strict, cela peut verrouiller des comptes réels après quelques fautes de frappe ; conservez donc une console hors bande ou un second compte privilégié pour éviter un verrouillage de l'administrateur. Définir unlock_time = 0 maintiendrait les comptes verrouillés jusqu'à réinitialisation manuelle, possible mais plus lourd à exploiter.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R31 | direct | 2.0 | haute |
| CIS | 5.3.3.1.2, 8.3.4 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.8, AC-7(b), 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.