Journaliser les modifications des informations de processus et de session
Garantit qu'auditd possède une règle active (clé session) journalisant les modifications des enregistrements de session utmp/wtmp/btmp.
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 fichiers qui suivent les sessions de connexion et le démarrage des processus, /var/run/utmp, /var/log/wtmp et /var/log/btmp, sont des cibles de choix pour un attaquant voulant effacer la preuve d'une connexion. Auditer les écritures sur ces fichiers (sous la clé session) enregistre toute falsification manuelle, préservant l'historique de session nécessaire pour reconstituer qui était sur le système et repérer les tentatives d'effacement de traces d'intrusion.
Ce que vérifie Pavois
Pavois exécute auditctl -l et cherche dans l'ensemble chargé une règle marquée session. Il lit l'ensemble effectif du noyau plutôt que les fichiers de règles : une surveillance présente dans /etc/audit/rules.d/ mais non chargée (erreur d'analyse, rechargement manquant, redémarrage en attente) échoue correctement ici, là où un scanner de fichiers serait trompé.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)session\b/) }
end
describe command("grep -rhwsE 'session' /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 session. Attendu : des règles de surveillance sur /var/run/utmp, /var/log/wtmp et /var/log/btmp se terminant par -k session (ou key=session). Aucune sortie signifie que la règle n'est pas active.
Inspecter et investiguer
- Confirmer la règle chargée :
auditctl -l | grep session. - Voir les événements enregistrés :
grep 'key="session"' /var/log/audit/audit.log(préférez un grep brut ; ausearch est peu fiable). - État du service :
systemctl status auditd.
Remédiation
pavois harden apply utilise la ressource audit_ruleset pour écrire les surveillances de suivi de session (clé session) sur utmp/wtmp/btmp dans le répertoire de règles d'auditd et recharger l'ensemble. La règle est reboot_required : un redémarrage garantit que les règles se chargent dès le démarrage et que tout mode immuable prend effet.
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
Sans cette règle, un attaquant peut éditer les enregistrements de session pour masquer sa présence sans laisser de trace d'audit, faussant la chronologie forensique et échouant aux exigences PCI/STIG. L'appliquer ajoute des surveillances d'audit et peut nécessiter un redémarrage ; l'impact est faible, mais chaque connexion met à jour ces fichiers, attendez-vous donc à un volume régulier (modeste) d'événements de session.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | haute |
| CIS | 6.2.3.11, 6.3.3.20, 6.3.3.11 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.7, 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.3 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-654195, UBTU-22-654205, UBTU-22-654200, UBTU-24-900610, UBTU-24-900600, UBTU-24-900590 | 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.