Configurer le verrouillage du compte root après des échecs de mot de passe
Impose l'option even_deny_root sur pam_faillock.so afin que le compte root soit lui aussi verrouillé après plusieurs échecs de connexion.
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
En limitant le nombre d'échecs de connexion, le risque d'accès non autorisé par devinette de mot de passe (force brute) est réduit. Par défaut, pam_faillock exempte root, laissant le compte le plus privilégié exposé à des tentatives illimitées ; even_deny_root comble cette faille pour que la politique de verrouillage s'applique aussi à root.
Ce que vérifie Pavois
Pavois recherche dans la pile PAM effective sous /etc/pam.d/ une ligne pam_faillock.so non commentée portant even_deny_root. Lire la pile assemblée (et ses chaînes @include et drop-ins) plutôt qu'un seul fichier évite le faux positif où l'option figure dans un exemple mais pas dans le chemin de règles réellement évalué par PAM.
describe command('grep -RqE \'^[^#]*\bpam_faillock\.so\' /etc/pam.d/ 2>/dev/null && { grep -RqE \'^[^#]*\bpam_faillock\.so[^#]*\beven_deny_root\' /etc/pam.d/ 2>/dev/null || grep -qE \'^[[:space:]]*even_deny_root\b\' /etc/security/faillock.conf 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/ et vérifiez que les lignes auth/account incluent even_deny_root. Pour le prouver, provoquez délibérément des échecs de connexion root au-delà du seuil, puis vérifiez que faillock --user root affiche les échecs (et un état verrouillé).
Inspecter et investiguer
Les événements de verrouillage de root apparaissent dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/audit/audit.log (auditd, RHEL). Inspectez et réinitialisez le compteur root avec faillock --user root et faillock --user root --reset.
Remédiation
Aucune remédiation automatisée n'est câblée pour cette règle, elle doit donc être appliquée manuellement : ajoutez l'option even_deny_root aux lignes pam_faillock.so de votre configuration PAM (via pam-auth-update/faillock.conf sur Debian/Ubuntu ou authselect sur RHEL) puis régénérez la pile.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| resource | pam_faillock |
|---|
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Verrouiller root peut être dangereux : si un attaquant distant (ou une automatisation mal saisie) atteint le seuil, le seul recours peut être un accès physique/console. Précautions : privilégiez une capacité de récupération console plutôt qu'un assouplissement de la politique ; gardez une session root active pendant l'édition de PAM ; combinez avec un délai de déverrouillage raisonnable (unlock_time) pour que le compte se rétablisse seul ; et rappelez-vous que le mode mono-utilisateur/récupération peut toujours réinitialiser les compteurs avec faillock --user root --reset.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R31 | direct | 2.0 | haute |
| NIST | AC-7(b), CM-6(a), IA-5(c) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| CIS | 5.3.3.1.3 | 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.