auditd répond aux questions qui ne surgissent qu’après coup : qui a modifié ce fichier, quand cet utilisateur a-t-il été créé, d’où ce processus a-t-il été lancé ? Aucun autre outil n’y répond — les journaux applicatifs ne contiennent pas ces informations, et l’historique des commandes est modifiable par celui qui l’a laissé.

La difficulté est qu’installer le paquet n’apporte rien en soi. Il n’existe pratiquement aucune règle par défaut, le journal s’écrit mais reste vide sur le fond — et on le découvre au pire moment : quand les données sont nécessaires et qu’elles ne sont pas là.

Installation

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

Une particularité : sur certaines versions, auditd ne se redémarre pas par systemctl restart — le service se pilote par sa propre commande. Les règles se relisent ainsi :

sudo augenrules --load
sudo auditctl -l

La seconde commande montre ce qui est réellement chargé. C’est à elle qu’il faut se fier, pas au contenu des fichiers.

Le jeu de règles

Les règles se déposent dans /etc/audit/rules.d/ en un fichier séparé. Voici un jeu minimal qui se rentabilise : il répond à la plupart des questions d’un incident sans saturer le disque.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Utilisateurs et privilèges
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privileges
-w /etc/sudoers.d/ -p wa -k privileges

## Accès SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## Tâches planifiées
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Modules du noyau
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

## Utilisation de sudo et su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

La syntaxe est courte : -w est un chemin à surveiller, -p wa signifie réagir aux écritures et aux changements d’attributs, -p x à l’exécution, -k est la clé de recherche ultérieure. Ces clés sont le principal confort : sans elles, chercher dans le journal revient à parcourir un gigaoctet de texte.

Ce qui ne figure pas dans cette liste, et pourquoi

Les guides proposent souvent d’enregistrer tous les appels execve — c’est-à-dire chaque lancement de chaque programme. La tentation se comprend : une image complète des actions. En pratique, sur un serveur en production, cela produit des centaines de mégaoctets par jour, consomme une part notable du processeur et conduit à tronquer le journal plus tôt qu’il ne sera nécessaire. Si ce niveau de détail est requis, activez-le ponctuellement — pour un utilisateur, ou le temps d’une enquête.

Il en va de même pour la surveillance du répertoire du site : on y écrit en permanence, et la règle transforme le journal en flot d’événements dépourvus de sens.

La lecture

Recherche par clé, avec les identifiants numériques résolus en noms :

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

L’option -i est indispensable à la lisibilité : sans elle, vous obtenez des nombres au lieu des noms d’utilisateurs et d’appels système. -ts limite la période (today, recent ou une date précise).

Un récapitulatif sur une période :

sudo aureport --summary -i
sudo aureport --auth -i --failed

Trois champs d’un enregistrement méritent l’attention : auid, l’identifiant de l’utilisateur qui a ouvert la session, uid, l’identité sous laquelle l’action s’est déroulée, et exe, le programme qui l’a exécutée. L’écart entre auid et uid est la réponse au « qui exactement est devenu root » : uid=0 avec l’auid d’une personne précise désigne le responsable sans ambiguïté, quelle que soit l’identité qu’il a prise à l’intérieur de la session.

Le disque

Les réglages de volume se trouvent dans /etc/audit/auditd.conf :

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

Regardez à part disk_full_action. Certaines configurations prévoient par défaut l’arrêt du système quand le disque est plein — comportement justifié sur des machines soumises à des exigences d’audit et parfaitement déplacé sur un serveur web. Vérifiez cette valeur avant que le disque ne se remplisse.

Le mode règles immuables

La ligne -e 2 à la fin du fichier de règles interdit de modifier les règles jusqu’au redémarrage — y compris à celui qui a obtenu root. Cela accroît nettement la valeur du journal : un intrus ne peut pas désactiver la surveillance sans redémarrer la machine, et un redémarrage se remarque de lui-même.

Le revers est évident : vous ne pourrez pas non plus modifier vos propres règles sans redémarrer. Activez-le une fois que le jeu de règles s’est stabilisé et que vous avez vécu un mois avec.

À quoi bon sur un serveur ordinaire

auditd n’empêche rien. Sa valeur se manifeste exactement une fois — quand il faut reconstituer l’enchaînement des événements, et que les données sont là ou ne le sont pas. Elles ne se collectent pas après coup, c’est pourquoi le jeu de règles se met en place d’avance et se laisse ensuite tranquille.

Un signe pratique que le réglage est bon : la liste des règles n’est pas vide, le journal ne grossit pas de façon incontrôlée, et les événements portant les clés identity et privileges sont rares et chacun explicable. À quoi cela ressemble sur une page, la démonstration ci-dessous le montre.