S'assurer qu'auditd collecte les actions de l'administrateur système
Impose une règle auditd (clé actions) qui enregistre les actions de l'administrateur système, notamment les modifications de la configuration sudoers.
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
Les actions des administrateurs système, principalement les modifications de la politique sudoers sous /etc/sudoers et /etc/sudoers.d/, doivent être auditées pour conserver une trace de ce qui a été changé sur le système et par qui, à des fins de responsabilité. Comme modifier la politique d'élévation est une technique courante d'attaquant pour établir une persistance, enregistrer ces modifications fournit une alerte précoce et une trace forensique.
Ce que vérifie Pavois
Pavois exécute auditctl -l et vérifie qu'une règle de clé actions est chargée. Lire le jeu de règles réellement chargé dans le noyau vaut mieux qu'analyser /etc/audit/rules.d/*.rules : une règle sur disque jamais chargée (pas de augenrules --load, erreur de syntaxe, échec de rechargement) ferait passer à tort un scanner de fichiers. auditctl -l reflète ce que le noyau audite à l'instant présent.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)actions\b/) }
end
describe command("grep -rhwsE 'actions' /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 -E '(-k |key=)actions' (en root). La sortie attendue est l'ensemble des surveillances sur les fichiers sudoers, par exemple :
-w /etc/sudoers -p wa -k actions-w /etc/sudoers.d -p wa -k actions
Aucune sortie signifie que les règles ne sont pas chargées.
Inspecter et investiguer
Les événements aboutissent dans /var/log/audit/audit.log. Après qu'un administrateur a modifié sudoers, trouvez l'enregistrement avec grep 'key="actions"' /var/log/audit/audit.log (grep sur le journal brut ; ausearch peut signaler à tort l'absence de correspondance). L'enregistrement indique l'auid, le fichier modifié et l'horodatage.
Remédiation
pavois harden apply utilise la ressource audit_ruleset pour ajouter les surveillances actions manquantes dans un drop-in géré par Pavois sous /etc/audit/rules.d/ et les charger. Le sous-système d'audit étant verrouillé une fois lancé, la modification n'est pleinement effective qu'après un redémarrage (reboot_required: true).
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
Il s'agit d'une surveillance de fichier passive, elle ne bloque jamais les modifications de sudoers, donc visudo et la gestion de configuration continuent de fonctionner ; elle ajoute seulement des enregistrements dans /var/log/audit/audit.log. Précautions :
- Le volume d'audit est minime car sudoers change rarement, aucune préoccupation de performance notable.
- Si le jeu de règles est immuable (
-e 2), la règle ne peut être ajoutée qu'après un redémarrage. - Confirmez que la règle a été analysée avec
augenrules --loadpuis revérifiezauditctl -l.
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.1, 6.3.3.1 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.7, AC-2(7)(b), 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-24-900510, UBTU-24-900520 | 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.