← Toutes les règles
SOCLE-CLD-IAM-023// Accounts (PAM modules)moyenneconfig persistante

Les verrouillages de compte doivent être journalisés

Impose l'option audit sur pam_faillock.so afin que chaque échec d'authentification comptant pour un verrouillage soit journalisé.

Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.

Un PASS prouve? actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 2 normes

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 journalisation des échecs de connexion, il est difficile (souvent impossible) de reconstituer ce qu'un attaquant a tenté avant ou pendant une attaque par force brute. L'option audit fait consigner par pam_faillock le nom d'utilisateur de chaque échec suivi, y compris pour des comptes inexistants, donnant aux équipes d'intervention la traçabilité nécessaire pour détecter les campagnes de devinette de mot de passe et identifier les comptes ciblés.

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 l'option audit. Lire la pile PAM telle qu'elle est réellement assemblée (auth/common-auth et leurs inclusions) vaut mieux que se fier à un seul fichier d'exemple : PAM résout les directives @include et les drop-ins propres à la distribution, si bien qu'un drapeau présent dans un fichier mais absent ou remplacé dans le fichier inclus échapperait à une vérification mono-fichier naïve.

describe command('grep -RqE \'^[^#]*\bpam_faillock\.so\' /etc/pam.d/ 2>/dev/null && { grep -RqE \'^[^#]*\bpam_faillock\.so[^#]*\baudit\' /etc/pam.d/ 2>/dev/null || grep -qE \'^[[:space:]]*audit\b\' /etc/security/faillock.conf 2>/dev/null; } && echo ok || echo ko') do
  its('stdout.strip') { should eq 'ok' }
end

Comment vérifier qu’elle est appliquée

Exécutez grep -rE '^[^#]*pam_faillock\.so' /etc/pam.d/ et vérifiez que les lignes auth obtenues contiennent le mot-clé audit. Vous pouvez aussi provoquer un échec (su - utilisateur avec un mauvais mot de passe) et vérifier que le nom d'utilisateur apparaît dans le journal d'audit/auth.

Inspecter et investiguer

Les tentatives échouées suivies par faillock apparaissent dans /var/log/auth.log (Debian/Ubuntu) ou via journalctl -u systemd-logind / le service émetteur PAM. Sur les systèmes dotés d'auditd, consultez /var/log/audit/audit.log. Le compteur en direct par utilisateur s'affiche avec faillock --user <nom>.

Remédiation

pavois harden apply utilise la ressource pam_faillock : elle s'assure que pam_faillock.so est intégré dans la pile auth avec l'option audit, en s'appuyant sur l'outillage PAM de la distribution (pam-auth-update sur Debian/Ubuntu, authselect sur RHEL) pour que la modification survive à une régénération de PAM.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

resourcepam_faillock
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Activer la journalisation des verrouillages présente peu de risque ; cela ajoute seulement de la verbosité aux journaux. Le risque principal réside dans une mauvaise configuration de pam_faillock lui-même : une ligne auth mal ordonnée ou dupliquée peut verrouiller tous les utilisateurs, root compris. Précautions : gardez une session root/console active pendant la modification de PAM, testez l'authentification depuis un second terminal avant de vous déconnecter, et sachez réinitialiser les compteurs avec faillock --user <nom> --reset en cas de verrouillage imprévu.

Mapping des normes

NormeRéférenceTypeVersionConfiance
NISTAC-7 (a)support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne
DISA STIGUBTU-22-411045, UBTU-24-200610directper OS STIG releasehaute

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.

Sources & références