Auditd sur Debian 13 sans ruiner les disques : réglages pratiques pour un audit raisonné

Le modèle mental : ce que auditd fait réellement à votre machine

auditd n’est pas un « écrivain de fichiers journaux ». C’est un collecteur en espace utilisateur pour le sous-système d’audit du noyau. Les règles que vous chargez indiquent au noyau quels événements émettre. Ces événements atterrissent dans une file noyau (le backlog) puis sont tirés par auditd, formatés et écrits — habituellement dans /var/log/audit/audit.log. Si vous les expédiez ailleurs, ils existent quand même localement d’abord dans la plupart des configurations.

La douleur disque provient de deux facteurs :

• Volume d’événements : trop d’appels système audités ou de chemins surveillés, surtout sur des points chauds (gestionnaires de paquets, runtimes de conteneurs, systèmes de build, serveurs web écrivant des fichiers temporaires).
• Patron d’écriture : les enregistrements d’audit sont petits et fréquents. De petits ajouts quasi-synchrones plus des mises à jour de métadonnées peuvent devenir un générateur d’écritures aléatoires selon le système de fichiers, les options de montage et le comportement de rotation des logs.

L’audit du noyau est aussi impitoyable sur la justesse. Si le backlog déborde, vous pouvez perdre des événements. Si vous configurez « panic on failure », vous pouvez faire tomber toute la machine. La conformité adore la seconde option ; les opérations la détestent ; vous finirez par négocier.

Voici la dure vérité : vous ne pouvez pas « optimiser » un jeu de règles d’audit que vous n’avez pas limité. Si vous partez d’un énorme baseline qui audite chaque openat() et chaque execve() sur chaque hôte, vous obtiendrez beaucoup de données — et beaucoup de chauffe. Votre travail consiste à décider quelles questions vous devez réellement pouvoir répondre lors d’un incident, puis auditer suffisamment précisément pour y répondre de manière fiable.

Une citation qui tient la route en exploitation : « L’espoir n’est pas une stratégie. » — idée souvent paraphrasée et attribuée aux praticiens de la fiabilité. En audit, l’espoir ressemble à « on l’active partout et on filtrera après ». Vous ne le ferez pas. Vous vous noyerez avant.

Quelques faits et éléments d’histoire (utiles)

• L’audit sous Linux précède la plupart des outils « cloud native ». Le framework d’audit Linux existe depuis le milieu des années 2000, destiné aux environnements régulés qui avaient besoin de traces indiscutables.
• SELinux et l’audit ont grandi ensemble. Une grande part de l’adoption initiale de l’audit est venue d’environnements déployant déjà SELinux et ayant besoin de traces d’événements pour les décisions de politique et le débogage.
• La pipeline d’audit est d’abord noyau, ensuite daemon. Si l’espace utilisateur ne suit pas, la file noyau se remplit ; le démon n’est pas le seul maillon.
• Les « watch rules » (-w) sont basées sur des chemins et coûteuses à leur manière. Elles sont excellentes pour un petit ensemble de fichiers critiques ; elles deviennent un piège pour des répertoires entiers à fort turnover.
• Les règles sur les appels système peuvent exploser plus vite que prévu. Auditer les ouvertures de fichiers sur un hôte chargé est le DoS auto-infligé classique, car tout ouvre des fichiers constamment.
• Les logs d’audit sont semi-structurés, pas d’abord pensés pour les humains. Le log brut est destiné à des outils comme ausearch et aureport, pas au grepping à 3h du matin (même si vous le ferez).
• L’audit a une vraie logique « fail closed ». Avec audit=1 et des réglages stricts, les systèmes peuvent être configurés pour traiter l’échec de l’audit comme fatal. Ce n’est pas théorique ; des équipes le font.
• Debian a historiquement été conservative par défaut. Vous n’obtenez généralement pas un jeu de règles massif « gratuit ». Le dégât vient habituellement des baselines de conformité copiées qui n’avaient pas été testées sur votre charge de travail.

Blague n°1 : Les logs d’audit sont comme des paillettes — une fois que vous déployez une règle bruyante, vous la retrouverez partout pendant des mois.

À quoi ressemble un « audit raisonnable » en production

Avant de toucher aux configs, définissez des cibles. Sinon vous allez argumenter sans fin avec la Sécurité au sujet des « événements manquants » sans savoir ce que « suffisant » signifie.

Objectifs opérationnels (pratiques, mesurables)

• Pas d’amplification d’écriture soutenue due à l’audit. De courtes pointes sont acceptables ; l’usure constante ne l’est pas. Votre budget d’endurance SSD est réel.
• Aucun impact de latence significatif sur les services critiques. Mesurez la latence p99 avant et après l’activation de l’audit sous charge représentative.
• Pas de perte d’événements d’audit en charge normale. En charge d’incident (fork bomb, disque plein), vous décidez la politique : abandonner des événements, throttler, ou échouer fermé.
• Les logs d’audit sont interrogeables et interprétables. Si un spécialiste est nécessaire pour savoir « qui a modifié la config SSH », votre système va pourrir.

Objectifs sécurité (ce que vous voulez réellement savoir)

• Actions administratives : création d’utilisateurs, usage de sudo, changements de privilèges.
• Modifications liées aux identifiants et à l’auth : clés SSH, configuration PAM, /etc/shadow.
• Exécution de binaires sensibles : sudo, su, gestionnaires de paquets, gestionnaires de services.
• Modifications de configurations critiques : sous-ensemble de /etc, unités systemd, cron, configuration d’audit elle-même.
• Actions noyau/module quand pertinent : chargement/déchargement de modules sur les hôtes concernés.

Si vous avez besoin de « détection d’exfiltration de données », auditd seul n’est pas votre outil. Il peut contribuer (par ex. surveiller l’accès à un fichier clé), mais ce n’est pas un système DLP réseau.

Playbook de diagnostic rapide (chasse au goulet en minutes)

Quand quelqu’un dit « auditd tue les disques », ne débattez pas. Exécutez un court playbook et laissez la machine parler.

Premier point : est-ce le volume d’événements ou le comportement disque ?

• Vérifiez le taux d’événements d’audit et la santé du backlog.
• Vérifiez les patrons d’E/S disque (IOPS, latence, profondeur de file d’attente).
• Vérifiez si les règles d’audit sont axées sur les appels système ou sur les watches de chemins.

Deuxième point : identifiez la règle ou la charge en faute

• Trouvez les clés d’audit les plus chaudes (si vous avez utilisé des keys).
• Corrélez les timestamp : pics d’audit vs déploiements de services vs cron vs logrotate.
• Cherchez les répertoires à fort turnover surveillés.

Troisième point : décidez quel bouton de compromis tourner

• Réduire les événements : restreindre les règles, ajouter des filtres, retirer les watches de répertoires.
• Réduire la douleur d’écriture : régler flush/freq, rotation, filesystem séparé, éviter les options de montage pathologiques.
• Augmenter le buffering : réglages de backlog, mais comprenez la mémoire et la sémantique de perte.
• Changer le comportement en cas d’échec : abandonnez-vous les événements sous pression ou préférez-vous dégrader l’hôte ?

Tâches pratiques (commandes, sorties, décisions)

Voici des vérifications réelles et exécutables. Chacune se termine par une décision : conserver, changer ou escalader. Faites-les dans l’ordre la première fois ; ensuite vous développerez des réflexes.

Task 1: Confirm auditing is enabled and the daemon is healthy

cr0x@server:~$ systemctl status auditd --no-pager
● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 09:12:01 UTC; 2h 3min ago
       Docs: man:auditd(8)
   Main PID: 712 (auditd)
      Tasks: 4
     Memory: 3.2M
        CPU: 1min 22s

Que cela signifie : Il fonctionne. S’il claque régulièrement, vous avez probablement des erreurs de config ou un disque plein.

Décision : Si le service est inactif/failed, réparez la santé du service d’abord (espace disque, syntaxe de config, permissions) avant d’ajuster les règles.

Task 2: Check kernel audit status: backlog, failure mode, enabled state

cr0x@server:~$ sudo auditctl -s
enabled 1
failure 1
pid 712
rate_limit 0
backlog_limit 8192
lost 0
backlog 12
backlog_wait_time 60000

Que cela signifie : L’audit est activé. Le backlog est en grande partie vide (backlog 12). failure 1 signifie comportement « printk » ; des modes plus stricts existent.

Décision : Si lost augmente, vous perdez des événements d’audit — traitez cela comme un incident en production pour les hôtes couverts par la conformité.

Task 3: Measure audit event volume quickly (rough rate)

cr0x@server:~$ sudo awk 'BEGIN{c=0} {c++} END{print c}' /var/log/audit/audit.log
184223

Que cela signifie : Nombre brut dans le fichier courant. Combinez avec les timestamps de fichier pour estimer le débit.

Décision : Si ce nombre croit follement vite (centaines de milliers par heure sur un petit hôte), vous avez sans doute des règles syscall trop larges.

Task 4: Check which audit keys are hottest (only works if you used -k)

cr0x@server:~$ sudo aureport --summary --key | head
Key Summary Report
=========================================
total  file
=========================================
15432  ssh-config
12011  priv-esc
 8430  pkg-mgr
 4122  cron

Que cela signifie : Vous voyez quels groupes de règles génèrent le plus d’événements.

Décision : Si une clé domine, inspectez les règles associées. Réduisez la portée ou ajoutez des exclusions.

Task 5: Identify high-churn watched paths (watch rules)

cr0x@server:~$ sudo auditctl -l | sed -n '1,12p'
-w /etc/ssh/sshd_config -p wa -k ssh-config
-w /etc/sudoers -p wa -k priv-esc
-w /etc/sudoers.d/ -p wa -k priv-esc
-w /var/log/ -p wa -k logdir
-a always,exit -F arch=b64 -S execve -F euid=0 -k root-exec

Que cela signifie : Ce -w /var/log/ est un panneau au néon indiquant « j’aime la douleur ». Surveiller des répertoires entiers de logs est à fort turnover.

Décision : Supprimez les watches sur répertoires à haute activité (/var/log, /tmp, stockage de conteneurs). Remplacez par des fichiers spécifiques ou des filtres syscall.

Task 6: Check disk IO pressure and latency

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0-1-amd64 (server)  12/30/2025  _x86_64_ (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.12    0.00    1.55    6.78    0.00   88.55

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
nvme0n1          2.10  820.0    45.0  9320.0    4.12   5.05  92.30

Que cela signifie : Très grand nombre d’écritures par seconde, forte utilisation. C’est cohérent avec de petits ajouts de logs.

Décision : Si w/s est énorme et que await grimpe lors des pics d’audit, vous êtes lié par le disque. Réduisez le volume d’événements et/ou lissez les écritures avec les réglages d’auditd et une séparation des systèmes de fichiers.

Task 7: Verify audit log filesystem and mount options

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /var/log/audit
/dev/mapper/vg0-varlog ext4 rw,relatime,errors=remount-ro

Que cela signifie : Les logs d’audit sont sur ext4 avec relatime. C’est raisonnable.

Décision : Si les logs d’audit partagent un root très occupé, envisagez fortement un filesystem dédié pour /var/log ou /var/log/audit afin que les écritures d’audit ne concurrencent pas les bases de données ou couches de conteneurs.

Task 8: Confirm journald isn’t duplicating the pain

cr0x@server:~$ sudo journalctl -u auditd -n 20 --no-pager
Dec 30 10:11:22 server auditd[712]: Audit daemon started successfully
Dec 30 10:14:05 server auditd[712]: Audit backlog limit exceeded
Dec 30 10:14:05 server auditd[712]: Audit events lost

Que cela signifie : Vous voyez de la pression sur le backlog. Journald n’héberge pas majoritairement le log d’audit, mais il capture les plaintes d’auditd.

Décision : Si le backlog est dépassé, vous devez réduire le taux d’événements ou augmenter la capacité (backlog/CPU), pas « faire tourner la rotation plus vite ».

Task 9: Watch backlog and lost counters live

cr0x@server:~$ watch -n 1 'sudo auditctl -s | egrep "lost|backlog |backlog_limit|backlog_wait_time"'
Every 1.0s: sudo auditctl -s | egrep "lost|backlog |backlog_limit|backlog_wait_time"  server: Tue Dec 30 11:16:02 2025

backlog_limit 8192
lost 0
backlog 23
backlog_wait_time 60000

Que cela signifie : Si backlog monte et reste élevé, auditd n’arrive pas à drainer les événements assez vite.

Décision : Si le backlog monte lors d’opérations spécifiques (par ex. sauvegardes), recentrez les règles pour que ces jobs ne génèrent pas d’événements non pertinents.

Task 10: Find top talkers in audit.log by record type

cr0x@server:~$ sudo awk '{print $2}' /var/log/audit/audit.log | cut -d'=' -f2 | sort | uniq -c | sort -nr | head
 88421 SYSCALL
 60210 PATH
  9102 CWD
  3210 EXECVE

Que cela signifie : Beaucoup de SYSCALL et de PATH suggère que l’audit des appels système représente la majeure partie. C’est normal ; la question est de savoir si c’est trop large.

Décision : Si les entrées PATH dominent, vous auditez peut-être largement les ouvertures/attributs de fichiers. Reserrez les règles avec des filtres de répertoire/fichier et des contraintes auid/euid.

Task 11: Confirm log rotation policy for audit logs

cr0x@server:~$ sudo grep -E '^(max_log_file|num_logs|max_log_file_action|space_left_action|admin_space_left_action|disk_full_action|flush|freq)' /etc/audit/auditd.conf
max_log_file = 50
num_logs = 10
max_log_file_action = ROTATE
space_left_action = SYSLOG
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
flush = INCREMENTAL_ASYNC
freq = 50

Que cela signifie : La rotation est activée. flush = INCREMENTAL_ASYNC avec freq=50 réduit la pression de sync tout en limitant la fenêtre de perte.

Décision : Si vous voyez flush = SYNC sur des hôtes chargés, attendez-vous à de la douleur. Si num_logs est trop élevé avec des fichiers énormes, vous pourriez stocker localement sans bénéfice.

Task 12: Validate the rule files actually loaded (and aren’t duplicated)

cr0x@server:~$ sudo augenrules --check
No change

Que cela signifie : Les règles compilées correspondent à ce qui est sur disque. Pas de changements en attente.

Décision : Si des changements sont signalés, rechargez les règles de manière contrôlée ; évitez le hot-reload pendant un trafic de pointe si vous utilisez le mode immutable.

Task 13: Check whether rules are immutable (and thus hard to fix under fire)

cr0x@server:~$ sudo auditctl -s | grep enabled
enabled 1

cr0x@server:~$ sudo auditctl -e 2
Error sending enable request (Operation not permitted)

Que cela signifie : Si vous êtes déjà en mode immutable (-e 2 défini au démarrage), vous ne pouvez pas changer les règles sans redémarrer.

Décision : N’utilisez le mode immutable que sur des systèmes où cette contrainte opérationnelle est acceptable et testée. Sinon, vous risquez une longue nuit.

Task 14: Check SSD wear indicators (sanity check, not paranoia)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'percentage|data units written|wear|media'
Percentage Used:                    3%
Data Units Written:                 8,421,332 [4.31 TB]
Media and Data Integrity Errors:    0

Que cela signifie : Vous pouvez corréler la croissance des écritures avec l’activation de l’audit. Ne devinez pas ; mesurez.

Décision : Si la pente de « Data Units Written » change fortement après l’activation de l’audit, considérez cela comme un problème de capacity planning et ajustez en conséquence.

Task 15: Find the noisiest executables (common culprit: package managers and orchestration)

cr0x@server:~$ sudo ausearch -m SYSCALL -ts today | grep -oE 'exe="[^"]+"' | sort | uniq -c | sort -nr | head
  812 exe="/usr/bin/dpkg"
  640 exe="/usr/bin/apt"
  418 exe="/usr/bin/python3.12"
  251 exe="/usr/sbin/cron"

Que cela signifie : Vous avez des rafales liées à l’activité des gestionnaires de paquets et aux jobs cron. Ce n’est pas malveillant ; c’est prévisible.

Décision : Si vous auditez fortement l’activité des gestionnaires de paquets, acceptez des pointes pendant les fenêtres de patch — ou ajoutez des règles limitées dans le temps ou par hôte pour les flottes en maintenance.

Task 16: Build a report for “who touched /etc/shadow” (proof that audit is working)

cr0x@server:~$ sudo ausearch -f /etc/shadow -ts this-week | aureport -f -i | head
File Report
===============================================
# date time            file                 syscall success exe                  auid event
===============================================
1. 12/29/2025 02:10:12 /etc/shadow           openat  yes     /usr/sbin/usermod    admin  19402

Que cela signifie : C’est le type de question que l’audit doit pouvoir répondre rapidement. S’il n’y parvient pas, vos règles sont soit trop faibles soit trop confuses.

Décision : Conservez les règles qui répondent à de vraies questions d’incident. Supprimez les règles qui génèrent de la chaleur sans influencer les décisions.

Règles qui ne font pas fondre les disques : stratégie et exemples

Les règles d’audit sont l’endroit où les disques viennent mourir. La plupart des conseils de « tuning auditd » se résument à « désactivez l’audit ». C’est paresseux. Le vrai mouvement est de passer d’une couverture syscall large à une couverture étroite et motivée par l’intention.

Principe 1 : Préférez des watches ciblées pour les fichiers critiques, pas des répertoires bruyants

Surveiller /etc/shadow est peu coûteux et utile. Surveiller /var/log est une lettre de déni de service que vous vous êtes envoyée.

Exemples de watches appropriées :

• /etc/passwd, /etc/shadow, /etc/group
• /etc/sudoers, /etc/sudoers.d/
• /etc/ssh/sshd_config et éventuellement /etc/ssh/sshd_config.d/
• /etc/audit/ (oui, surveillez le watcher)
• Fichiers d’unité systemd réellement importants : /etc/systemd/system/

Principe 2 : Si vous auditez des syscalls, filtrez par identité et intention

Auditer execve pour chaque utilisateur sur un serveur de build va générer un petit roman chaque minute. À la place :

• Auditez les exécutions privilégiées (euid=0) initiées par des utilisateurs non système (auid>=1000).
• Auditez les modifications (écriture/changement d’attributs) sur un petit ensemble de systèmes de fichiers ou répertoires.
• Excluez les comptes générant du bruit connu (backup, monitoring) si la politique l’autorise — et documentez cette exception.

Principe 3 : Utilisez les keys religieusement

Les keys (-k) ne sont pas de la décoration. Elles servent au triage. Sans keys, vous resterez à regarder des enregistrements bruts et sentirez votre âme vous quitter.

Un jeu de règles de base raisonnable (opinionné)

Sur Debian, les règles sont typiquement gérées via /etc/audit/rules.d/*.rules et compilées dans /etc/audit/audit.rules avec augenrules.

Exemple : /etc/audit/rules.d/10-sane-baseline.rules (illustratif, pas maximal) :

cr0x@server:~$ sudo cat /etc/audit/rules.d/10-sane-baseline.rules
## Identity and auth files
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group  -p wa -k identity
-w /etc/gshadow -p wa -k identity

## Sudoers and SSH
-w /etc/sudoers -p wa -k priv-esc
-w /etc/sudoers.d/ -p wa -k priv-esc
-w /etc/ssh/sshd_config -p wa -k ssh-config
-w /etc/ssh/sshd_config.d/ -p wa -k ssh-config

## Audit configuration itself
-w /etc/audit/ -p wa -k audit-config

## Systemd unit overrides (where persistence happens)
-w /etc/systemd/system/ -p wa -k systemd-units
-w /etc/systemd/system.conf -p wa -k systemd-units
-w /etc/systemd/journald.conf -p wa -k logging

## Cron persistence
-w /etc/cron.d/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Privileged command execution by real users
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k root-exec
-a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k root-exec

Ce baseline fait quelques choses importantes :

• Il se concentre sur la persistance et les privilèges, pertinents pour les incidents.
• Il évite l’audit syscall pour les ouvertures de fichiers. C’est là que le volume d’événements devient sauvage.
• Il tague tout avec des keys pour que vous puissiez trier en quelques minutes.

Où les gens se trompent : « tout auditer » via les syscalls

Un baseline de conformité courant audite largement l’accès aux fichiers, souvent avec quelque chose comme « auditer tous les échecs open/openat », ou « auditer toutes les écritures par quiconque ». Sur un système moderne, c’est essentiellement auditer l’acte de respirer.

Si vous devez auditer les écritures de fichiers, faites-le de manière étroite :

• Répertoires spécifiques contenant des secrets ou des jeux de données régulés.
• Comptes de service spécifiques interagissant avec ces données.
• Seulement les écritures/changes d’attributs réussis, à moins que l’échec soit un signal de sécurité pour votre environnement.

Contrôles du bruit que vous devriez réellement utiliser

Vous pouvez filtrer les motifs de bruit connus en utilisant des champs comme auid, uid, exe et dir. Le piège : chaque filtre que vous ajoutez est aussi un angle mort futur. Assurez-vous que l’exclusion est une décision de politique, pas une commodité.

Exemple : exclure un utilisateur agent de sauvegarde dédié du bruit de root-exec (seulement si l’équipe sécurité est d’accord) :

cr0x@server:~$ sudo cat /etc/audit/rules.d/20-exclusions.rules
## Exclude known automation account from root-exec noise
-a never,exit -F arch=b64 -S execve -F auid=1105 -k exclude-backup
-a never,exit -F arch=b32 -S execve -F auid=1105 -k exclude-backup

Blague n°2 : La manière la plus rapide de découvrir un chemin de code « rare » est de l’auditer en production.

Paramètres du démon audit qui comptent (et pourquoi)

Les règles déterminent le volume. auditd.conf décide à quel point il est pénible de persister ce volume et ce qui se passe quand ça tourne mal.

Stratégie de flush : la bague d’humeur du disque

Paramètres clés :

• flush : comment auditd force l’écriture sur disque.
• freq : fréquence de flush quand vous utilisez des modes incrémentiels.

Recommandation pratique pour la plupart des hôtes de production : flush = INCREMENTAL_ASYNC et une freq modérée (par ex. 50–200). Cela réduit le problème des « petits writes syncs toute la journée ».

Ce que vous échangez : une fenêtre de perte plus large si l’hôte plante. Décidez si c’est acceptable selon la classe d’hôte. Pour des endpoints durcis en conformité, vous pouvez être forcé vers des flushs plus stricts. Si vous faites cela, vous devez réduire encore plus agressivement le volume d’événements.

Rotation des logs : rendez-la banale

Les logs d’audit tournent différemment des logs généraux ; ne laissez pas logrotate vous surprendre. Utilisez les options de rotation d’auditd :

• max_log_file et num_logs dimensionnent la rétention locale.
• max_log_file_action = ROTATE est généralement correct.
• max_log_file_action = KEEP_LOGS est comment vous vous retrouvez avec un disque plein et un incident philosophique.

Actions en cas d’espace disque : décidez à quoi ressemble l’échec

Ces paramètres sont déguisés en politique :

• space_left_action, admin_space_left_action
• disk_full_action, disk_error_action

Pour les hôtes de production généralistes, je préfère : alerter fortement, garder la machine en fonctionnement et préserver ce que vous pouvez. Pour les endpoints régulés, vous pouvez devoir suspendre l’audit ou même arrêter. Si votre politique est « halt on disk full », vous feriez mieux d’avoir des filesystems séparés et une surveillance qui prévient la croissance avant la falaise.

Backlog et temps d’attente : absorber les pics sans se mentir

Le tuning du backlog noyau sert à survivre aux pointes : mises à jour de paquets, jobs CI, tempêtes cron. Un backlog plus grand peut aider — jusqu’à ce qu’il ne le fasse plus, et alors vous n’avez fait que retarder la chute.

Utilisez la taille du backlog pour gérer des rafales légitimes, mais considérez un backlog persistant comme « vos règles sont trop larges » plutôt que « ajoutez plus de tampon ». Les tampons ne sont pas du throughput.

Position pratique Debian 13 sur le mode immutable

Le mode immutable (règles verrouillées jusqu’au reboot) est utile pour empêcher un attaquant de désactiver l’audit après avoir obtenu root. Il est aussi utile pour vous empêcher de corriger rapidement un mauvais déploiement.

Mon opinion : n’utilisez le mode immutable que sur des hôtes où vous avez :

• des jeux de règles testés sous charge réaliste,
• un rollback répété qui inclut un redémarrage,
• une responsabilité claire en cas d’« audit a cassé la prod ».

Réalités du stockage et des systèmes de fichiers : ext4, XFS, ZFS, NVMe

Le journal d’audit est une charge de petites écritures. Sur les stockages modernes, les petites écritures ne sont pas automatiquement mauvaises — jusqu’à ce que vous les transformiez en flux constant avec du churn métadonnée et des flushs forcés.

Séparez le rayon d’explosion

Si vous ne pouvez faire qu’un seul changement de stockage : mettez /var/log ou au moins /var/log/audit sur son propre filesystem avec un dimensionnement et une surveillance raisonnables. Cela fait trois choses :

• empêche la croissance d’audit de remplir le root et de rendre la machine inutilisable,
• réduit la contention I/O avec les données applicatives,
• vous permet d’appliquer des réglages système de fichiers/montage sans toucher tout le reste.

ext4 : correct, sobre, prévisible

ext4 sur NVMe est généralement correct si vous évitez les réglages pathologiques. Utilisez relatime. Ne montez pas en sync. Ne placez pas votre log d’audit sur le même filesystem qu’une base de données très active sauf si vous aimez les jeux de blâme.

XFS : solide sous concurrence, mais pas magique

XFS gère bien les charges parallèles, mais les logs d’audit sont surtout des écritures en append. Si votre problème est le volume d’événements, XFS ne vous sauvera pas. Si votre problème est la contention et le comportement des métadonnées, il peut aider. Mesurez, ne vibrez pas.

ZFS : bon outil, modes d’échec différents

Si vous écrivez les logs d’audit sur ZFS, les réglages changent. ZFS peut convertir de nombreuses petites écritures en différents patrons d’E/S selon recordsize, sync et le comportement du SLOG. Il peut être excellent, mais il est aussi facile de transformer « petits appends » en « beaucoup de transactions synchrones ».

Position pratique : si vous n’opérez pas déjà ZFS avec maturité, ne l’introduisez pas juste pour « réparer auditd ». Réduisez d’abord le volume de règles.

Endurance NVMe SSD : pas fragile, pas infinie

Les SSD modernes d’entreprise peuvent encaisser, mais l’endurance reste un budget. Ce qui vous tue, ce sont des écritures soutenues et inutiles. L’audit est souvent soutenu et inutile quand il est mal configuré. Utilisez les compteurs SMART pour prouver votre cas aux parties prenantes.

Transport, agrégation et maintien de la pertinence des logs d’audit

Les logs d’audit locaux sont nécessaires, mais pas suffisants. Dans de vrais incidents, l’hôte compromis est le moins digne de confiance pour stocker la vérité.

Local d’abord, distant toujours (mais n’écrasez pas deux fois vos disques)

Beaucoup d’environnements expédient les logs d’audit vers un SIEM via un agent qui suit /var/log/audit/audit.log. C’est normal. Surveillez deux problèmes :

• Amplification I/O induite par le tail : certains agents se comportent mal sur les rotations ou font des fsyncs fréquents. Testez votre expéditeur.
• Explosions de parsing : si votre pipeline SIEM s’étouffe, la sécurité peut demander un « raw everything » local pour toujours. Résistez. Définissez la rétention et prouvez que le pipeline distant fonctionne.

Faites des keys et métadonnées hôte une priorité

Si vous n’étiquetez pas les règles avec des keys et n’annotez pas les événements dans la pipeline avec le rôle de l’hôte, l’environnement, et le propriétaire, vous aurez un lac global de bruit identique. C’est ainsi que « l’audit » devient « stockage cher plein d’ambiance ».

Politique de rétention : n’accumulez pas localement

La rétention locale sert à :

• réponse d’incident court terme quand la centralisation est retardée,
• buffer contre des coupures réseau,
• continuité forensique de base.

Ce n’est pas pour l’archivage sur plusieurs mois sauf si vous avez une exigence spécifique et un plan de stockage. Réglez max_log_file et num_logs selon les taux mesurés et une fenêtre de panne réaliste pour votre pipeline de logs.

Trois mini-récits d’entreprise tirés du terrain

Incident causé par une mauvaise hypothèse : « les écritures d’audit, c’est juste des logs, ça se compressera bien »

Dans une entreprise de taille moyenne mixant Debian et Ubuntu, la Sécurité a déployé un « baseline d’audit Linux standard » pendant un trimestre déjà tendu. Le baseline incluait l’audit syscall pour un grand ensemble d’opérations sur fichiers, parce que le template avait été écrit pour une flotte bien plus petite et une charge bien plus calme.

Les opérations ont supposé que ça se comporterait comme du logging texte classique : « Ce sont des logs, ce seront des écritures séquentielles ; compression et rotation s’en occuperont. » Cette hypothèse est morte rapidement sur des hôtes CI. Ces hôtes exécutaient déjà intensivement des pulls de conteneurs, décompressaient des couches et écrivaient des caches. Les nouvelles règles d’audit ont essentiellement enregistré un fort pourcentage de ce churn.

Le premier symptôme n’était pas des erreurs d’audit. C’étaient des timeouts de build et des augmentations soudaines de iowait. Des services sensibles à la latence co-localisés sur les mêmes hyperviseurs ont commencé à signaler des lenteurs « aléatoires ». Puis le vrai kicker : certains hôtes ont commencé à perdre des événements d’audit car le backlog se remplissait pendant les vagues de build.

La correction n’a pas été héroïque. Ils ont supprimé les règles syscall larges, gardé des watches ciblées sur les fichiers d’identité et de persistance, et restreint l’audit d’exécution privilégiée aux vrais utilisateurs via des contraintes auid. Ils ont aussi déplacé /var/log/audit sur un filesystem séparé sur les hôtes importants. La conformité était satisfaite parce que les questions « qui a changé identité et privilège » étaient de nouveau répondables, et la flotte a cessé de se mettre en pâte.

Une optimisation qui s’est retournée contre eux : « rendre l’audit durable, mettre flush à SYNC »

Une équipe de services financiers voulait des garanties plus fortes : « Aucun événement d’audit perdu, jamais. » Quelqu’un a réglé auditd.conf pour une durabilité maximale. Ils ont mis flush = SYNC et durci les actions d’espace pour que le système suspende quand le stockage devient critique.

Sur le papier, cela ressemble à de la responsabilité. En pratique, cela a transformé des travaux d’administration routiniers en pics de latence. Chaque rafale d’événements audités se traduisait par une pression d’écriture synchrone. Lors des fenêtres de patch, les gestionnaires de paquets généraient des tempêtes d’événements denses (execs, écritures de config). La latence de stockage montait. La fenêtre de patch s’allongeait. Les gens relançaient. La tempête de relances empirait la situation.

Puis le retournement : un incident sur le pipeline de logs a retardé l’expédition hors hôte. Les logs locaux ont grossi plus vite que prévu. Le filesystem dédié aux logs s’est rempli plus tôt que prévu. Le système a suspendu l’audit juste au moment critique — pendant un événement opérationnel chaotique — à cause des actions strictes d’espace disque. Ils n’ont pas perdu la machine, mais ils ont perdu la trace d’audit pour la période exacte qui intéressait les auditeurs.

La configuration finale était moins « pure » et plus fiable : flush incrémental asynchrone, fenêtre locale de rétention soigneusement dimensionnée, surveillance de l’utilisation du filesystem de logs, et une politique convenue sur ce qu’il advient sous pression disque. « Ne jamais perdre d’événements » est devenu « ne pas perdre d’événements en fonctionnement normal ; en cas d’épuisement des ressources, préserver le système et alerter immédiatement ». Ce n’était pas aussi satisfaisant qu’une garantie stricte, mais ça fonctionnait réellement.

Une pratique ennuyeuse mais correcte qui a sauvé la journée : keys, règles minimales et répétition

Une équipe SaaS en soins de santé avait été brûlée avant, alors elle a fait quelque chose d’inguant : elle a écrit un jeu de règles d’audit strictement scopié, assigné des keys à chaque règle, et l’a mis sous gestion de configuration avec revue par les pairs. Chaque règle avait une « question d’incident » attachée dans le message de commit : « Détecter les changements de config SSH », « Détecter les chemins d’escalade de privilèges », « Détecter la persistance via cron ».

Ils se sont aussi entraînés. Une fois par trimestre, ils faisaient un exercice sur table : simuler un compte admin compromis, modifier un drop-in d’unité systemd, ajouter un job cron, et changer la config SSH. Puis ils vérifiaient qu’ils pouvaient récupérer ces événements avec ausearch rapidement, sans connaissances tribales.

Quand un vrai incident est arrivé — des identifiants d’un ingénieur ont fuité et ont été utilisés pour modifier un include sudoers — la réponse a été ennuyeuse dans le bon sens. L’astreinte a sorti le résumé de la clé priv-esc, a extrait la fenêtre de changement exacte, et a confirmé le compte acteur via auid. Ils ont rollbacké, fait tourner les credentials, et disposaient d’une trace d’audit facile à expliquer à la direction.

Personne n’a célébré le jeu de règles. Il n’avait pas de tableau de bord. Il ne « s’intégrait pas à l’IA ». Il fonctionnait simplement, et n’a pas détruit les disques dans le processus.

Erreurs fréquentes : symptôme → cause racine → correctif

1) Symptom: Disk write IOPS skyrockets right after enabling auditd

Cause racine : Règles syscall larges (souvent open/openat ou watches de répertoires sur des chemins chauds) créant un volume massif d’événements.

Correctif : Supprimez les syscalls d’accès larges ; remplacez par des watches ciblées -w sur fichiers critiques et des règles execve privilégiées filtrées par auid et euid. Utilisez des keys pour identifier les principaux coupables.

2) Symptom: lost counter increases; journald shows “backlog limit exceeded”

Cause racine : La production d’événements d’audit dépasse la consommation ; auditd n’arrive pas à drainer assez vite ; le backlog déborde.

Correctif : D’abord réduire le taux d’événements (scope des règles). Ensuite augmenter backlog_limit pour absorber les pointes. Troisièmement vérifier la contention CPU et la latence I/O ; si auditd est bloqué en écriture, cela peut entraîner l’overflow du backlog.

3) Symptom: Host latency spikes during patching or CI jobs

Cause racine : Audit d’exécutions privilégiées ou de changements de fichiers de façon trop large ; les gestionnaires de paquets et outils de build déclenchent des rafales. Souvent combiné avec flush = SYNC.

Correctif : Conservez l’audit d’exécution privilégiée mais restreignez-le (utilisateurs réels uniquement). Utilisez INCREMENTAL_ASYNC pour flush. Envisagez d’exclure des comptes automatisés connus si la politique l’autorise.

4) Symptom: Root filesystem fills, system becomes unstable

Cause racine : Logs d’audit sur le FS root, KEEP_LOGS, ou rotation mal dimensionnée par rapport aux taux d’événements réels. Parfois pipeline distant en panne + rétention locale trop grande.

Correctif : Placez /var/log/audit sur un filesystem dédié. Utilisez ROTATE. Définissez la rétention en fonction du taux mesuré et d’une fenêtre de panne réaliste. Surveillez l’utilisation.

5) Symptom: You can’t change rules during an incident

Cause racine : Mode immutable activé au démarrage (-e 2), parfois sans plan opérationnel.

Correctif : N’activez pas le mode immutable avant d’avoir validé les règles sous charge de production et répété le rollback. Si c’est déjà activé, votre seule vraie option est de redémarrer avec des règles corrigées.

6) Symptom: Audit logs are massive, but you still can’t answer “who changed X?”

Cause racine : Pas de keys, règles non focalisées, et la croyance que le volume équivaut à la visibilité.

Correctif : Réécrivez les règles autour des questions d’incident. Utilisez des keys. Testez en effectuant quelques changements contrôlés et vérifiez la récupération avec ausearch/aureport.

7) Symptom: High IO even when the system is “idle”

Cause racine : Surveiller des répertoires à fort turnover comme /var/log, /tmp ou le stockage overlay des conteneurs. « Idle » est un mensonge ; des agents en arrière-plan churnent.

Correctif : Supprimez les watches sur répertoires et auditez des fichiers critiques spécifiques à la place. Si vous devez auditer des conteneurs, utilisez la télémétrie runtime spécifique, pas des watches globaux.

Checklists / plan pas à pas

Plan A : vous activez auditd sur Debian 13 pour la première fois

1. Définissez les questions d’incident. Exemples : « Qui a modifié sudoers ? », « Qui a changé la config SSH ? », « Quel humain a exécuté des commandes root ? »
2. Commencez avec un jeu de règles minimal. Watches pour identité/auth/persistance ; exec privilégié filtré par auid.
3. Taguez tout avec des keys. Vous construisez une interface de diagnostic, pas juste un fichier journal.
4. Réglez flush = INCREMENTAL_ASYNC et choisissez freq. Démarrez à 50 ; ajustez selon le taux d’événements et la fenêtre de perte acceptable.
5. Séparez /var/log/audit si l’hôte est chargé ou critique. Réduisez le rayon d’explosion.
6. Réglez la rotation de façon sensée. max_log_file_action = ROTATE, tailles mesurées, rétention alignée sur l’expédition.
7. Chargez les règles avec augenrules et vérifiez. Assurez-vous qu’il n’y a pas de duplicata ou de fichiers legacy chargés.
8. Testez sous charge réelle. Surveillez lost, backlog, latence I/O et latence p99 des services.
9. Décidez la politique d’échec. En cas de disque plein ou d’échec d’audit : alerter, suspendre ou arrêter ? Mettez cela par écrit.
10. Ce n’est qu’ensuite que vous envisagez le mode immutable. Si vous ne pouvez pas redémarrer vite, ne vous verrouillez pas hors des corrections.

Plan B : auditd est déjà déployé et les disques hurlent

1. Confirmez les événements perdus/le comportement du backlog. Si vous perdez des événements, l’objectif principal échoue déjà.
2. Trouvez les keys et règles les plus actives. Utilisez aureport --key et auditctl -l.
3. Supprimez les évidents foot-guns. Watches de répertoires sur des chemins à fort churn, règles open/openat larges.
4. Passez en flush incrémental asynchrone si sûr. Si la politique l’interdit, vous devez réduire le volume plus fortement.
5. Déplacez les logs d’audit sur un filesystem dédié. Faites-le en fenêtre de maintenance si nécessaire. C’est une réduction de risque.
6. Remesurez. I/O, backlog, événements perdus, et votre capacité à répondre aux questions clés d’incident.

FAQ

1) Will flush = INCREMENTAL_ASYNC make audit logs “unsafe”?

Cela augmente la fenêtre d’événements qui pourraient être perdus lors d’un crash soudain. Pour la plupart des systèmes de production, ce compromis est acceptable si vous maintenez un volume d’événements raisonnable et expédiez rapidement les logs hors hôte.

2) Should I audit every execve on the system?

Non. Auditez execve privilégiés (euid=0) initiés par des utilisateurs réels (auid≥1000). Cela capture la plupart des activités d’escalade significatives sans vous noyer.

3) Why is watching a directory so much worse than watching a file?

Les répertoires avec churn génèrent un flux continu de créations/renommages/changes d’attributs. Sur les répertoires de logs ou temporaires, ce churn est constant. Surveiller quelques fichiers spécifiques donne un fort signal avec un faible volume.

4) Can I just rely on journald instead of auditd?

Pas pour la sémantique d’audit noyau. Journald est excellent pour les logs de services. Auditd fournit une capture d’événements de sécurité structurée depuis le sous-système d’audit du noyau avec des garanties et champs différents.

5) What’s the fastest proof that my ruleset is useful?

Faites un changement contrôlé : éditez /etc/ssh/sshd_config, lancez visudo ou modifiez un fichier dans /etc/sudoers.d, puis récupérez les événements avec ausearch -k ssh-config et ausearch -k priv-esc.

6) Does moving /var/log/audit to its own filesystem really help performance?

Parfois. Le plus grand bénéfice est l’isolation : vous empêchez les écritures d’audit de concurrencer l’I/O applicative et vous réduisez le risque de remplir le root. L’amélioration de performance dépend de votre pile de stockage.

7) How big should backlog_limit be?

Assez grand pour absorber des rafales sans perdre, assez petit pour que vous remarquiez une surcharge persistante. Commencez avec quelques milliers à dizaines de milliers selon le taux d’événements et la mémoire, puis mesurez le comportement du backlog pendant les jobs de pointe.

8) Should I enable immutable mode on all servers?

Non. Utilisez-le sélectivement où le coût opérationnel de « devoir redémarrer pour corriger les règles d’audit » est acceptable et répété. Sinon il transforme des mauvaises configurations en interruptions prolongées.

9) We need “everything” for compliance. What do I tell auditors?

Définissez « tout » comme « tout ce qui est pertinent pour les contrôles de sécurité ». Fournissez des preuves : les règles correspondent aux contrôles (changement d’identité, escalade de privilèges, persistance), la perte d’événements est supervisée, et les logs sont expédiés hors hôte avec rétention.

10) Why do I see multiple records (SYSCALL, PATH, CWD) per action?

Les événements d’audit sont composés de plusieurs enregistrements décrivant le contexte du syscall, le répertoire courant et les chemins de fichiers. C’est normal — et c’est pourquoi le volume d’événements croît rapidement quand vous auditez des syscalls fréquents.

Conclusion : prochaines étapes exécutables aujourd’hui

Si votre déploiement audit sur Debian 13 abîme les disques, ne commencez pas par bidouiller des nombres magiques. Commencez par réduire le tuyau d’événements. Retirez les watches de répertoires sur les chemins à fort churn. Arrêtez d’auditer largement l’accès aux fichiers sauf si vous avez une cible étroite et un budget mesuré pour cela. Conservez les règles qui répondent à des questions d’incident réelles et taguez-les avec des keys pour en apporter la preuve.

Puis rendez la persistance moins douloureuse : flush asynchrone incrémental, rotation sensée, filesystem dédié pour les logs d’audit, et une politique claire sur ce qu’il advient quand les ressources s’épuisent. Enfin, répétez : faites un petit changement sur un fichier sensible et confirmez que vous pouvez récupérer la trace d’audit rapidement. Voilà à quoi ressemble un « audit raisonné » — utile sous pression et qui n’essaie pas activement de tuer votre stockage.