Enregistrer les événements qui modifient les informations d'utilisateurs/groupes - /etc/group
Installe des surveillances auditd avec la clé audit_rules_usergroup_modification sur les bases de comptes (/etc/group, /etc/passwd, /etc/shadow, /etc/gshadow, /etc/security/opasswd) afin que chaque modification soit enregistrée.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
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
Au-delà de l'audit de la création d'utilisateurs et de groupes, ces surveillances alertent les administrateurs de toute modification des bases de comptes. Tout utilisateur, groupe ou changement inattendu dans /etc/passwd, /etc/shadow ou /etc/group doit être examiné pour en vérifier la légitimité. Sans ces règles, un attaquant qui ajoute un compte dérobé ou élève un UID à 0 ne laisse aucune trace dans la piste d'audit, rendant impossible la reconstruction forensique d'une compromission.
Ce que vérifie Pavois
Pavois exécute auditctl -l et vérifie l'ensemble de règles chargé et actif dans le noyau pour une règle ayant la clé audit_rules_usergroup_modification. Lire l'ensemble actif est décisif : une règle peut figurer dans /etc/audit/rules.d/*.rules sans jamais être chargée (erreur de syntaxe, augenrules non exécuté, service non rechargé). Seul auditctl -l prouve que le noyau surveille réellement les fichiers à cet instant.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)audit_rules_usergroup_modification\b/) }
end
describe command("grep -rhwsE 'audit_rules_usergroup_modification' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
its('stdout') { should match(/\S/) }
endComment vérifier qu’elle est appliquée
Exécutez auditctl -l | grep audit_rules_usergroup_modification. Attendez-vous à une surveillance -w par fichier de comptes, p. ex. -w /etc/group -p wa -k audit_rules_usergroup_modification. Modifiez ensuite un fichier (p. ex. chage sur un utilisateur) et confirmez qu'un événement apparaît dans le journal.
Inspecter et investiguer
Les événements générés sont écrits dans /var/log/audit/audit.log. Comme ausearch peut signaler à tort "no matches", utilisez grep sur le journal brut : grep 'key="audit_rules_usergroup_modification"' /var/log/audit/audit.log. État du service : systemctl status auditd.
Remédiation
pavois harden apply utilise la ressource audit_ruleset pour déposer un fichier de règles géré par Pavois sous /etc/audit/rules.d/ contenant les surveillances -w ... -k audit_rules_usergroup_modification, puis recharge auditd afin de charger les règles dans le noyau. Comme l'ensemble de règles est verrouillé en immuable (-e 2) sur un hôte durci, un redémarrage est signalé pour que les nouvelles règles s'appliquent proprement.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Opérationnellement anodin : ce sont des surveillances -w passives au coût négligeable. Précautions : les surveillances auditd consomment le backlog d'audit, associez donc cette règle à un audit_backlog_limit adéquat ; sur un hôte dont l'ensemble est déjà verrouillé (-e 2), le changement ne prend effet qu'après redémarrage. Si la politique disque d'auditd est halt/single et que la partition se remplit, la machine peut cesser d'accepter les actions : surveillez l'espace libre de /var/log/audit avant de verrouiller l'ensemble de règles.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | haute |
| CIS | 10.2.1.5, 6.2.3.8, 6.3.3.8, 6.3.3.12, 6.3.3.14, 6.3.3.16, 6.3.3.15, 6.3.3.17, 6.3.3.13 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.7, AC-2(4), AC-6(9), AU-12(c), AU-2(d), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 10.2.1.5 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-654130, UBTU-22-654135, UBTU-22-654140, UBTU-22-654145, UBTU-22-654150, UBTU-24-200290, UBTU-24-200310, UBTU-24-200320, UBTU-24-200280, UBTU-24-200300 | 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.