Définir la durée de verrouillage de root après des échecs d'authentification
Fixe root_unlock_time à 60 secondes au minimum afin que, lorsque le compte root est verrouillé par pam_faillock après des échecs d'authentification répétés, il le reste assez longtemps pour rendre la devinette de mot de passe impraticable, au lieu d'être réessayable immédiatement.
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 de tentatives de connexion en échec, on réduit le risque d'accès root non autorisé par devinette de mot de passe, autrement dit par force brute. La limite est imposée en verrouillant le compte.
Ce que vérifie Pavois
Pavois recherche root_unlock_time dans /etc/security/faillock.conf et dans le répertoire de drop-ins /etc/security/faillock.conf.d/, retient la dernière occurrence (tail -1, celle que pam_faillock honorerait lui-même) et exige une valeur >= 60. C'est le fait d'auditer l'ensemble des drop-ins, et pas seulement le fichier principal, qui permet de détecter une valeur plus basse réintroduite par un fragment ultérieur. À noter : root_unlock_time n'a de sens que si pam_faillock est réellement présent dans la pile PAM et que le verrouillage de root est activé (even_deny_root), ce qui relève de contrôles distincts.
describe command('v=$(grep -rh \'^[[:space:]]*root_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 60 ] && echo ok; } || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Relisez la directive résolue :
grep -rE '^[[:space:]]*root_unlock_time' /etc/security/faillock.conf /etc/security/faillock.conf.d/
/etc/security/faillock.conf:root_unlock_time = 60
Le compteur en vigueur s'inspecte avec faillock --user root, qui liste les échecs enregistrés et leur horodatage ; faillock --user root --reset les efface.
Inspecter et investiguer
Les verrouillages sont journalisés par PAM dans /var/log/auth.log (Debian/Ubuntu) ou via journalctl -u sshd (famille RHEL) :
sshd[4567]: pam_faillock(sshd:auth): Consecutive login failures for user root account temporarily locked
Lorsque pam_faillock est configuré avec l'option audit, les tentatives en échec sont aussi enregistrées par auditd ; grepez le journal brut plutôt que de compter sur ausearch :
grep -E 'ANOM_LOGIN_FAILURES|RESP_ACCT_LOCK' /var/log/audit/audit.log
Remédiation
Le plan de durcissement Pavois utilise une remédiation keyval qui écrit root_unlock_time = 60 dans /etc/security/faillock.conf. Cette ressource est agrégée : Pavois réécrit l'intégralité du fichier avec l'ensemble des clés faillock qu'il gère (deny, unlock_time, even_deny_root, audit, etc.), de sorte que le fichier reflète toujours l'état désiré complet plutôt qu'une ligne rapiécée. Toute clé ajoutée à la main dans ce fichier est donc écrasée à l'application suivante, et un plan généré depuis un scan périmé peut supprimer un réglage que vous vouliez conserver : régénérez toujours le plan depuis un scan récent.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| file | /etc/security/faillock.conf |
|---|---|
| key | root_unlock_time |
| resource | keyval |
| value | 60 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Sans délai de déverrouillage pour root, un attaquant ayant accès à une invite de connexion root peut réessayer des mots de passe sans le moindre coût. C'est la configuration inverse qui est réellement dangereuse : associé à even_deny_root, un root_unlock_time à 0 signifie que root est verrouillé définitivement et n'est récupérable que depuis une console physique, un mode mono-utilisateur ou un démarrage de secours. Même les 60 secondes recommandées transforment des échecs répétés en déni de service sur root (un attaquant peut maintenir le compte verrouillé en échouant volontairement). Avant d'appliquer, gardez une session root ou une console hors bande ouverte, conservez un compte non privilégié disposant de sudo comme voie de repli, et rappelez-vous que faillock --user root --reset remet le compteur à zéro immédiatement.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| 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.