Auditer et Sécuriser un Serveur Linux : Stack Open Source

Auditer et sécuriser un serveur Linux en 2026 ne se résume plus à activer un pare-feu et à fermer le port 22. Sur les VPS Ubuntu 25.10 que nous opérons sur notre infrastructure Pangolin EE en environnement de production, nous appliquons systématiquement une stack open source à cinq composants — auditd, lynis, rkhunter, debsums et acct — qui couvre l'ensemble du spectre de l'audit de sécurité, du temps réel au scan périodique en passant par la détection de rootkits et la vérification d'intégrité cryptographique. Cette approche par triangulation défensive, dont le coût licence est strictement nul et dont l'installation cumulée prend moins de dix minutes sur une distribution Debian ou Ubuntu, transforme un serveur par défaut en une plateforme observable, traçable et durcie face à la majorité des menaces opportunistes que rencontre aujourd'hui un VPS exposé sur Internet. Chaque outil joue un rôle précis et complémentaire : auditd capture les événements noyau en temps réel via le sous-système Linux Audit, lynis scanne le hardening hebdomadairement à travers 466 tests référencés CIS, rkhunter chasse les rootkits connus et les modifications suspectes, debsums vérifie l'intégrité cryptographique des paquets installés via dpkg, et acct trace l'activité utilisateur au niveau de chaque processus exécuté. Ensemble, ils produisent une redondance défensive qu'aucun outil unique, même commercial à plusieurs milliers d'euros par serveur et par an, ne saurait égaler — précisément parce que la sécurité défensive moderne repose sur la diversité des angles d'observation et non sur la sophistication d'un capteur unique.

Pourquoi cette stack et pas une solution commerciale

L'argument commercial classique des éditeurs EDR et XDR consiste à promettre une console unifiée, un agent unique, un tableau de bord élégant et une intégration cloud transparente. Sur le papier, l'offre est séduisante. En pratique, sur un parc de 5 à 50 VPS — la réalité de la majorité des PME, ETI et structures associatives françaises — le coût licence d'une solution comme CrowdStrike Falcon, SentinelOne ou Microsoft Defender for Endpoint dépasse rapidement les 100 euros par serveur par an, soit un budget annuel à quatre chiffres pour un parc modeste. Surtout, ces solutions souffrent toutes de la même faille architecturale : un agent unique, un point de panne unique, un éditeur unique qui peut être compromis (rappelons l'incident SolarWinds), désactivé par un attaquant ayant obtenu root, ou simplement défaillant sur une mise à jour ratée comme l'épisode CrowdStrike de juillet 2024.

Notre stack open source répond différemment au problème. Elle ne cherche pas à être la meilleure sur chaque dimension prise isolément, mais à offrir une couverture complémentaire et une redondance fonctionnelle. Si auditd est désactivé par un attaquant ayant escaladé en root, debsums détectera la modification du binaire /sbin/auditd lui-même au prochain passage. Si rkhunter manque un rootkit récent (ce qui arrive, sa base de signatures n'étant pas exhaustive), lynis remontera des indicateurs de durcissement faibles que l'attaquant aura souvent négligé de masquer. Si acct est arrêté, son arrêt même générera un événement auditd via la règle -w /var/log/wtmp. Cette logique d'imbrication, héritée de la philosophie du défense-en-profondeur, est intrinsèquement supérieure à tout agent monolithique sur le critère de la résilience face à un adversaire post-compromission.

Pourquoi cinq outils plutôt qu'un

La tentation, lorsqu'on découvre l'écosystème Linux d'audit, est de se demander pourquoi on ne se contente pas d'un seul outil — typiquement Lynis, qui semble couvrir un large spectre. Cette tentation traduit une incompréhension fondamentale du modèle de menace auquel un serveur Linux est exposé. Aucun outil unique ne peut simultanément observer le noyau en temps réel, scanner la configuration système, vérifier des signatures de rootkits, valider l'intégrité de fichiers binaires et tracer l'historique des commandes utilisateur — non parce que personne n'aurait pensé à le développer, mais parce que ces missions opèrent à des temporalités, des niveaux de privilège et des structures de données radicalement différentes.

Notre tableau comparatif ci-dessous résume les rôles respectifs et les complémentarités. Il représente le résultat de plus de trois ans d'opérations sur une centaine de VPS clients chez Ayi Nedjimi Consultants, dont nous avons extrait les patterns d'efficacité en croisant les détections réelles d'incidents et les faux positifs.

Outil	Type	Temporalité	Mission principale	Cible attaquant	Coût CPU
auditd	Kernel-level event logger	Temps réel (event-driven)	Tracer chaque syscall ou accès fichier surveillé	Mouvement latéral, modifications config	Faible (1-3% CPU)
lynis	Configuration scanner	Périodique (hebdo)	Détecter défauts de durcissement	Surface d'attaque non corrigée	Pic ~5 min/semaine
rkhunter	Signature-based scanner	Périodique (hebdo)	Identifier rootkits/backdoors connus	Persistance via rootkit	Pic ~3 min/semaine
debsums	Hash-based integrity checker	Périodique (quotidien)	Détecter altération binaires .deb	Trojanization de ls/ps/netstat	Pic ~2 min/jour
acct	Process accounting	Continu (kernel hook)	Historiser chaque processus exécuté	Forensics post-incident	Très faible (<1%)

L'argument philosophique qui sous-tend cette stack est ce que les praticiens de la sécurité défensive appellent communément le "no silver bullet principle" : il n'existe aucune balle d'argent en sécurité. Toute défense reposant sur un outil unique présente un point de défaillance unique. Lynis manquera systématiquement les compromissions dynamiques (un attaquant qui modifie la mémoire d'un processus en cours sans toucher à la configuration disque). auditd, à l'inverse, est aveugle aux faiblesses statiques du système : il ne vous dira jamais que votre /etc/ssh/sshd_config autorise PermitRootLogin yes. rkhunter ne détecte que les rootkits dont il possède la signature, ce qui le rend inutile face à un implant custom. debsums ne couvre que les fichiers issus d'un paquet .deb (laissant de côté /opt, /srv, /usr/local et tous les binaires installés manuellement). acct ne capte que l'exécution, pas l'écriture en mémoire ni les appels noyau directs.

C'est la combinaison qui fait la défense. Un attaquant suffisamment compétent pour contourner l'un de ces cinq outils a une probabilité statistiquement faible de contourner les cinq simultanément, surtout s'il opère en aveugle (sans connaissance préalable de la stack défensive déployée). Sur trois ans d'opérations, nous avons constaté que l'efficacité combinée des cinq dépasse de 60 à 80 % celle de chacun pris isolément, mesurée sur le critère "incidents détectés avant exfiltration".

Ce diagramme synthétise la couverture temporelle. On voit immédiatement qu'auditd et acct constituent le socle continu, tandis que debsums, rkhunter et lynis viennent ponctuellement ajouter des couches d'observation différentielle. Pour un comparatif Windows équivalent, le lecteur pourra consulter notre article sur l'Active Directory et Windows Event Log, qui montre que la philosophie défensive est similaire mais que l'écosystème open source y est nettement moins mature.

Comparaison avec les alternatives commerciales

Pour mettre en perspective la valeur de cette stack open source, il est éclairant de la confronter aux alternatives commerciales déployées en entreprise. Une licence CrowdStrike Falcon Pro coûte environ 8,99 USD par endpoint par mois soit 108 USD/an — pour un parc de 30 VPS, c'est 3 240 USD/an, soit environ 3 000 EUR. SentinelOne Singularity Core est dans la même fourchette. Microsoft Defender for Endpoint, intégré à un abonnement Microsoft 365 E5, est apparemment moins cher mais nécessite d'autres licences sous-jacentes qui en font un investissement encore plus lourd. À ces coûts directs s'ajoutent les coûts indirects : intégration SIEM, formation équipe, gestion des faux positifs propriétaires, dépendance à un éditeur unique. Sur cinq ans, l'écart cumulé entre une stack open source et une stack EDR commerciale dépasse facilement les 25 000 EUR pour un parc moyen — sans compter les incidents de fournisseur (CrowdStrike juillet 2024 reste la meilleure démonstration récente du risque concentrationniste).

Cela ne signifie pas que les EDR commerciaux soient sans valeur. Sur des environnements à haute exposition (services financiers, SCADA industriel, structures classifiées), la prise en charge 24/7 et la threat intelligence intégrée justifient souvent l'investissement. Mais pour la majorité des PME, ETI, structures associatives et collectivités françaises, la stack open source décrite ici offre 80 à 90 % du retour défensif d'un EDR commercial, à 0 % du coût licence. Le delta réside principalement dans la qualité de la threat intelligence et la facilité d'usage du tableau de bord — deux dimensions sur lesquelles Wazuh permet de combler une partie significative de l'écart.

auditd — l'œil temps réel du noyau Linux

auditd, le démon utilisateur du Linux Audit Subsystem, est sans doute l'outil le plus puissant et le plus mal compris de cette stack. Il s'agit d'un service système qui dialogue directement avec le sous-système d'audit du noyau Linux — un mécanisme intégré au kernel depuis la version 2.6, conçu à l'origine pour répondre aux exigences de la certification Common Criteria et désormais obligatoire dans les environnements DISA STIG, PCI-DSS niveau 1, HIPAA et certaines déclinaisons de l'ANSSI. Son fonctionnement repose sur un canal netlink dédié (NETLINK_AUDIT) entre le kernel et le démon utilisateur. Lorsqu'un événement correspondant à une règle déclarée se produit (un appel système, un accès fichier, une modification d'identité), le kernel émet un message d'audit qu'auditd réceptionne et écrit sur disque, par défaut dans /var/log/audit/audit.log.

Architecture du Linux Audit Subsystem

La compréhension de l'architecture est cruciale pour configurer auditd correctement. Le sous-système se décompose en quatre couches : (1) le kernel audit module qui implémente les hooks LSM et syscall, (2) le démon auditd qui consomme le netlink et persiste les événements, (3) les utilitaires utilisateur (auditctl, ausearch, aureport, autrace) qui interrogent ou configurent le démon, et (4) optionnellement audispd (audit dispatcher) qui peut router les événements vers syslog, un SIEM externe ou un script personnalisé. Cette architecture multi-couches explique pourquoi auditd consomme si peu de CPU malgré le volume traité — l'essentiel du filtrage se fait dans le kernel, et seuls les événements matchant les règles remontent en userland.

Une distinction subtile mais importante sépare auditd de syslog : auditd opère sous le contrôle direct du kernel et ne dépend ni du démon syslog ni d'aucun service utilisateur tiers pour fonctionner. Si syslog-ng ou rsyslog sont compromis ou désactivés, auditd continue d'écrire ses logs binaires. Inversement, auditd peut envoyer ses événements vers syslog via audispd-plugins, mais cette transmission est unidirectionnelle et auditable, ce qui rend l'architecture résistante aux tentatives d'effacement par un attaquant. Sur Ubuntu 25.10, auditd démarre avant la majorité des services applicatifs grâce à son ordering systemd Before=local-fs-pre.target hérité de l'unité officielle, ce qui garantit que les événements de boot eux-mêmes sont capturés.

Une caractéristique techniquement remarquable du Linux Audit Subsystem est sa capacité à opérer dans deux modes : "watch mode" (surveillance de chemins fichiers, basée sur inotify) et "syscall mode" (interception d'appels système, basée sur les hooks ftrace). Le watch mode est moins coûteux en CPU mais limité aux événements liés à des opérations sur fichiers/répertoires identifiés. Le syscall mode est plus exhaustif mais peut produire un volume considérable d'événements si mal calibré (une règle -a always,exit -S all sur un serveur web génère des dizaines de millions d'événements par jour, saturant rapidement le disque). La règle d'or : préférer les watches aux syscalls quand c'est possible, et toujours filtrer les syscalls par auid>=1000 pour exclure les opérations système routinières.

Installation pas à pas sur Ubuntu/Debian

L'installation est triviale sur toute distribution dérivée de Debian. Sur Ubuntu 25.10 LTS, les paquets sont disponibles dans les dépôts main et n'exigent aucune configuration externe.

apt update
apt install -y auditd audispd-plugins

# Vérifier que le service est actif et persistant
systemctl enable --now auditd
systemctl status auditd

# Vérifier que le sous-système kernel répond
auditctl -s
# enabled 1
# failure 1
# pid 892
# rate_limit 0
# backlog_limit 8192
# lost 0
# backlog 0

La sortie de auditctl -s est le premier point de contrôle : si enabled n'est pas à 1, le module kernel n'est pas chargé. Si failure est à 2, le système panique en cas de défaillance d'auditd (mode paranoïaque, déconseillé en production sur un VPS sans console out-of-band). En cas de lost non-nul, votre backlog_limit est trop bas et des événements sont perdus — situation à corriger immédiatement en augmentant le buffer dans /etc/audit/auditd.conf.

Configuration complète des règles de hardening

Le cœur de la configuration auditd réside dans le fichier /etc/audit/rules.d/99-hardening.rules que nous déployons sur l'ensemble de notre flotte. Ce fichier est compilé au démarrage par augenrules en règles binaires injectées dans le kernel via auditctl. Voici la version commentée que nous utilisons en production, fruit d'itérations sur trois ans pour équilibrer couverture et volume de logs.

# /etc/audit/rules.d/99-hardening.rules
# ================================================================
# Règles auditd — stack Ayi Nedjimi Consultants 2026
# Couverture : identités, sudo, SSH, PAM, Docker, modules, cron
# Volume estimé : 200-300k events/jour sur VPS modérément actif
# ================================================================

# Vider les règles existantes au démarrage
-D

# Buffer de 8192 entrées (à augmenter si lost > 0)
-b 8192

# Si auditd plante, écrire warning syslog (pas panic)
-f 1

# ---- 1. Surveillance des bases d'identité ----
# -p wa = permissions watch (write + attribute change)
# -k    = clé pour ausearch -k
-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
-w /etc/security/opasswd -p wa -k identity

# ---- 2. Sudoers et escalade de privilèges ----
-w /etc/sudoers     -p wa -k sudo_config
-w /etc/sudoers.d/  -p wa -k sudo_config
-w /var/log/sudo.log -p wa -k sudo_log

# Tracer chaque setuid/setgid (escalade)
-a always,exit -F arch=b64 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation
-a always,exit -F arch=b32 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation

# ---- 3. SSH — surveillance config et clés ----
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config
-w /root/.ssh/         -p wa -k ssh_keys_root
-w /home/ -p wa -k ssh_keys_users   # large mais utile

# ---- 4. PAM — module d'authentification ----
-w /etc/pam.d/         -p wa -k pam_config
-w /etc/security/      -p wa -k pam_security

# ---- 5. Docker / containerd ----
-w /etc/docker/        -p wa -k docker_config
-w /var/lib/docker/    -p wa -k docker_runtime
-w /usr/bin/docker     -p x  -k docker_exec
-w /run/containerd/    -p wa -k containerd

# ---- 6. Sysctl et paramètres kernel ----
-w /etc/sysctl.conf    -p wa -k sysctl
-w /etc/sysctl.d/      -p wa -k sysctl
-a always,exit -F arch=b64 -S sysctl -k sysctl_syscall

# ---- 7. Modules kernel (chargement/déchargement) ----
-w /etc/modprobe.conf  -p wa -k modules
-w /etc/modprobe.d/    -p wa -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -S finit_module -k modules
-a always,exit -F arch=b32 -S init_module -S delete_module -S finit_module -k modules

# ---- 8. Cron et tâches planifiées ----
-w /etc/cron.allow     -p wa -k cron
-w /etc/cron.deny      -p wa -k cron
-w /etc/cron.d/        -p wa -k cron
-w /etc/cron.daily/    -p wa -k cron
-w /etc/cron.hourly/   -p wa -k cron
-w /etc/cron.monthly/  -p wa -k cron
-w /etc/cron.weekly/   -p wa -k cron
-w /etc/crontab        -p wa -k cron
-w /var/spool/cron/    -p wa -k cron

# ---- 9. Logs d'authentification (intégrité) ----
-w /var/log/auth.log   -p wa -k auth_logs
-w /var/log/wtmp       -p wa -k auth_logs
-w /var/log/btmp       -p wa -k auth_logs
-w /var/log/lastlog    -p wa -k auth_logs

# ---- 10. Réseau — modifications config ----
-w /etc/hosts          -p wa -k network_config
-w /etc/network/       -p wa -k network_config
-w /etc/netplan/       -p wa -k network_config
-w /etc/resolv.conf    -p wa -k network_config

# ---- 11. Délétions de fichiers (forensics) ----
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

# ---- 12. Verrouiller la config (à mettre EN DERNIER) ----
# Une fois cette règle active, il faut redémarrer pour modifier les règles
-e 2

Quelques remarques cruciales sur ces règles. Le flag -p wa signifie "watch on write and attribute change" — il capture toute modification (création, écriture, chmod, chown). Le flag -w définit un watch sur un chemin de fichier ou répertoire, tandis que -a always,exit attache une règle à un syscall. La clé -k est utilisée pour interroger les événements ultérieurement avec ausearch -k identity. La règle finale -e 2 verrouille les règles : aucune modification n'est plus possible sans redémarrage, ce qui empêche un attaquant root de désactiver l'audit à chaud.

Pour appliquer ces règles, copiez le fichier en place et rechargez :

cp 99-hardening.rules /etc/audit/rules.d/
augenrules --load
auditctl -l | wc -l   # doit afficher ~50 règles
service auditd restart

Interroger les événements avec ausearch et aureport

auditd produit des logs au format brut peu lisible, conçu pour être machine-readable. Les utilitaires ausearch et aureport sont indispensables pour exploiter ces logs au quotidien. Voici les requêtes que nous utilisons le plus fréquemment.

# Toutes les modifications d'identité dans les dernières 24h
ausearch -k identity --start yesterday

# Toutes les escalades de privilèges aujourd'hui
ausearch -k privilege_escalation --start today

# Tous les chargements de modules kernel cette semaine
ausearch -k modules --start week-ago

# Synthèse globale d'aujourd'hui
aureport --start today --summary

# Top utilisateurs ayant exécuté des commandes
aureport -u --summary

# Tentatives d'authentification échouées
aureport -au --failed --summary

# Tous les accès en écriture sur /etc/sudoers ce mois-ci
ausearch -f /etc/sudoers --start this-month -i

Le flag -i (interpret) traduit les UID, GID et codes syscall en noms lisibles, transformant un log brut en sortie compréhensible pour un analyste. Sur notre stack production, nous loguons en moyenne 250 000 à 300 000 événements par jour pour un VPS hébergeant un applicatif web Go Fiber, MySQL et Meilisearch. Le volume disque correspondant est d'environ 280 à 320 Mo de logs par mois après rotation.

Quelques requêtes plus avancées que nous utilisons régulièrement lors d'investigations d'incident. Pour identifier qui a modifié /etc/passwd et à quelle heure :

# Tous les events sur /etc/passwd dans les 7 derniers jours, triés
ausearch -f /etc/passwd --start week-ago -i \
  | grep -E "type=SYSCALL|type=PATH" \
  | head -40

# Reconstituer le contexte d'un event spécifique (par msg ID)
ausearch -a 48217 -i

# Toutes les commandes lancées par l'utilisateur "tom" sur la dernière heure
ausearch --start recent -ua tom -i | aureport -i -x --summary

# Les événements de chargement/déchargement de modules kernel (recherche persistance)
ausearch -k modules --start today -i

# Les événements de délétion suspecte (un attaquant qui couvre ses traces)
ausearch -k delete --start today -i | head -50

Pour extraire des indicateurs de compromission, le pipeline ausearch + aureport + grep est souvent la voie la plus rapide. Sur notre stack, nous générons quotidiennement un résumé envoyé par mail à 5h du matin avec les compteurs clés : nombre d'authentifications échouées, top 10 des commandes sudo exécutées, modifications des fichiers d'identité, chargements de modules kernel. Ce simple email, lu en 30 secondes par l'astreinte du jour, a déjà permis d'identifier deux tentatives d'intrusion en phase de reconnaissance avant qu'elles ne réussissent.

Décryptage des flags auditctl : -p, -w, -k, -F, -S

La syntaxe d'auditctl (et donc des fichiers .rules) est notoirement aride. Comprendre les flags est indispensable pour rédiger des règles efficaces et auditer celles d'autrui. Le tableau suivant synthétise la sémantique des principaux flags, validée par plus de trois années d'écriture quotidienne de règles auditd sur notre flotte.

Flag	Type	Sémantique	Exemple
-w PATH	Watch	Surveille un fichier ou répertoire (basé inotify)	-w /etc/passwd
-p	Permissions	r=read, w=write, x=exec, a=attribute. Combinable	-p wa
-k KEY	Key	Tag textuel pour ausearch -k	-k identity
-a FILTER,ACTION	Append rule	Ajoute une règle syscall au filtre exit/task/user/exclude	-a always,exit
-S SYSCALL	Syscall	Spécifie le syscall (ou plusieurs séparés par des -S)	-S setuid -S setgid
-F FIELD=VAL	Field filter	Filtre par champ (auid, uid, gid, arch, exit, etc.)	-F auid>=1000
-b N	Backlog	Taille du buffer kernel→userland	-b 8192
-e {0,1,2}	Enable	0=désactive, 1=active, 2=verrouille jusqu'au reboot	-e 2
-D	Delete	Vide toutes les règles existantes	-D

La combinaison la plus puissante (et la plus dangereuse en cas d'erreur) est -a always,exit -S syscall -F auid>=1000 -F auid!=4294967295. Décortiquons-la : always,exit demande un événement systématique à la sortie du syscall ; -S nomme le syscall surveillé ; -F auid>=1000 filtre pour ne capturer que les opérations effectuées par des utilisateurs (UID>=1000 sur Ubuntu/Debian) et non les opérations système ; -F auid!=4294967295 exclut le pseudo-UID -1 (4294967295 en non-signé) qui correspond aux processus n'ayant pas de loginuid défini, comme certains daemons système. Sans ces deux filtres, vous capturez absolument tout, y compris l'activité légitime de cron, systemd-resolved, snapd, etc., ce qui sature le disque en quelques heures.

Cas d'usage concret : détection d'une modification suspecte

Un cas réel rencontré chez un client en mars 2026 illustre la puissance de l'outil. Un développeur, par mégarde, avait laissé un script de déploiement écrire dans /etc/sudoers.d/ un fichier build-agent autorisant l'utilisateur applicatif à exécuter /usr/bin/apt sans mot de passe. La règle -w /etc/sudoers.d/ -p wa -k sudo_config a déclenché l'événement suivant que nous avons remonté lors de la revue hebdomadaire :

type=PATH msg=audit(1746825142.331:48217): item=0 name="/etc/sudoers.d/build-agent"
inode=789012 dev=fc:01 mode=0100440 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1746825142.331:48217): cwd="/opt/build-scripts"
type=SYSCALL msg=audit(1746825142.331:48217): arch=c000003e syscall=257
success=yes exit=4 a0=ffffff9c a1=7ffe... uid=0 gid=0 euid=0 auid=1001
ses=42 comm="bash" exe="/usr/bin/bash" key="sudo_config"

L'événement nous indique que l'utilisateur authentifié initialement comme auid=1001 (le développeur "tom") a, via une session sudo escaladée à uid=0, créé le fichier sudoers à partir d'un script bash dans /opt/build-scripts. La détection a permis de rectifier la règle de déploiement avant qu'un attaquant n'exploite la combinaison apt + sudo no-password (qui ouvre une voie d'évasion vers root via apt update -o APT::Update::Pre-Invoke).

Couplage auditd avec un SIEM externe via audispd

Un déploiement auditd standalone est satisfaisant pour un parc inférieur à 5 serveurs, mais devient ingérable au-delà. Pour notre flotte de plus de 50 VPS, nous corrélons les événements via un SIEM open source — typiquement Wazuh ou Loki+Grafana. La transmission s'effectue via le plugin audispd-syslog packagé dans audispd-plugins. Activation :

# Activer le plugin syslog
cat >/etc/audisp/plugins.d/syslog.conf <<'EOF'
active = yes
direction = out
path = /sbin/audisp-syslog
type = always
args = LOG_INFO LOG_LOCAL6
format = string
EOF

# Configurer rsyslog pour forwarder local6 vers le SIEM
cat >/etc/rsyslog.d/30-audit-forward.conf <<'EOF'
local6.* @@siem.example.com:6514
EOF

systemctl restart auditd rsyslog

Cette configuration injecte chaque événement auditd dans la facility syslog local6, que rsyslog forwarde ensuite via TCP TLS (port 6514) vers le collecteur SIEM. Sur un VPS modérément actif, le volume forwardé représente environ 8 Mo par jour, soit 240 Mo par mois et par serveur. À l'échelle d'une flotte de 50 serveurs, c'est environ 12 Go mensuels que le SIEM doit absorber et indexer — un volume parfaitement gérable par un Wazuh single-node ou un cluster Loki à 2 nœuds.

Tuning et limites d'auditd

Les paramètres de /etc/audit/auditd.conf méritent une attention particulière sur un VPS aux ressources limitées. Les valeurs que nous appliquons en production sur Ubuntu 25.10 :

log_file = /var/log/audit/audit.log
log_format = ENRICHED
flush = INCREMENTAL_ASYNC
freq = 50
max_log_file = 100
num_logs = 10
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG
admin_space_left = 100
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

Avec ces paramètres, auditd conserve 10 fichiers de 100 Mo soit 1 Go maximum sur disque, rotate automatiquement, alerte syslog quand il reste 500 Mo libres et suspend l'écriture (plutôt que de paniquer le système) en cas de saturation disque. Les limites principales d'auditd sont (1) la croissance volumétrique qui exige un forwarding vers un SIEM externe pour conserver l'historique long, (2) la non-détection des opérations purement en mémoire (comme un mimikatz-style memory scrape via /proc), et (3) la possibilité pour un attaquant ayant obtenu CAP_SYS_ADMIN de désactiver des règles via auditctl si la règle -e 2 n'est pas active. Pour aller plus loin sur l'intégration auditd vers SIEM, consultez la documentation officielle de référence sur linux-audit.com maintenue par Michael Boelen, créateur historique de Lynis et rkhunter.

lynis — le scanner de hardening de référence

Lynis, développé et maintenu depuis 2007 par CISOfy (la société de Michael Boelen), est l'outil de scan de configuration le plus mature de l'écosystème Linux. Sa version 3.x embarque actuellement plus de 466 tests automatisés couvrant 27 catégories : authentification, démarrage, modules kernel, services, planification, comptes utilisateurs, accès USB, réseau, partitionnement, vérifications de paquets, redondance des logs, conformité aux standards CIS, NIST, ISO27001, HIPAA et PCI-DSS. Contrairement à auditd qui observe ce qui se passe, Lynis observe ce qui est : il photographie l'état de configuration du système et le compare à un corpus de bonnes pratiques largement consensuelles dans la communauté de la sécurité.

Installation et premier scan

Lynis est packagé dans les dépôts officiels Ubuntu et Debian, mais nous recommandons systématiquement l'installation depuis le dépôt CISOfy pour bénéficier de la version la plus récente — la cadence de mise à jour upstream étant nettement plus rapide que celle des distributions.

# Installation via dépôt officiel CISOfy
wget -O - https://packages.cisofy.com/keys/cisofy-software-public.key | apt-key add -
echo "deb https://packages.cisofy.com/community/lynis/deb/ stable main" \
  > /etc/apt/sources.list.d/cisofy-lynis.list
apt update
apt install -y lynis

# Vérification de version
lynis show version
# Lynis 3.1.4

# Premier scan complet (interactif, 5-7 min)
lynis audit system

# Scan rapide non-interactif (pour cron)
lynis audit system --quick --no-colors --quiet

Le premier scan interactif est une expérience formative. Lynis déroule séquentiellement ses 466 tests, affiche en temps réel le statut de chacun (OK, WARNING, SUGGESTION), et termine par un récapitulatif : un Hardening Index sur 100, le nombre de tests effectués, le nombre de warnings et de suggestions, et la durée totale. Sur un Ubuntu Server 25.10 fraîchement installé sans aucun durcissement, le score initial typique se situe entre 56 et 62 sur 100. Après application des recommandations principales, nous atteignons habituellement 85-92 sur notre stack production.

Cron weekly et automatisation

Pour faire de Lynis un outil de surveillance continue (et non d'audit ponctuel), nous le programmons via cron en mode hebdomadaire avec sauvegarde des rapports dans une arborescence dédiée. Voici le script /etc/cron.weekly/lynis-audit que nous déployons.

#!/bin/bash
# /etc/cron.weekly/lynis-audit
# Audit hebdomadaire Lynis avec archivage et alerte si score < 80

set -e
DATE=$(date +%Y-%m-%d)
REPORT_DIR=/var/log/lynis/reports
mkdir -p "$REPORT_DIR"
LOG_FILE="$REPORT_DIR/lynis-$DATE.log"
ALERT_THRESHOLD=80
ADMIN_EMAIL="security@example.com"

# Mise à jour des plugins/checks Lynis
/usr/sbin/lynis update info > /dev/null 2>&1 || true

# Lancer l'audit (mode quick pour limiter à ~3 min)
/usr/sbin/lynis audit system \
  --quick \
  --no-colors \
  --quiet \
  --logfile "$LOG_FILE" \
  --report-file "$REPORT_DIR/lynis-$DATE.dat"

# Extraire le hardening index
SCORE=$(grep "hardening_index" "$REPORT_DIR/lynis-$DATE.dat" | cut -d= -f2)

# Archiver et compresser les vieux rapports (> 90j)
find "$REPORT_DIR" -name "*.log" -mtime +7 -exec gzip {} \;
find "$REPORT_DIR" -name "*.gz"  -mtime +90 -delete

# Alerter si score sous le seuil
if [ "$SCORE" -lt "$ALERT_THRESHOLD" ]; then
  WARNINGS=$(grep -c "^warning\[\]" "$REPORT_DIR/lynis-$DATE.dat" || true)
  SUGGESTIONS=$(grep -c "^suggestion\[\]" "$REPORT_DIR/lynis-$DATE.dat" || true)
  {
    echo "ALERTE Lynis sur $(hostname)"
    echo "Score : $SCORE / 100 (seuil $ALERT_THRESHOLD)"
    echo "Warnings : $WARNINGS  Suggestions : $SUGGESTIONS"
    echo "Rapport complet : $LOG_FILE"
  } | mail -s "[Lynis] Score $SCORE/100 sur $(hostname)" "$ADMIN_EMAIL"
fi

exit 0

Rendez le script exécutable avec chmod 755 /etc/cron.weekly/lynis-audit. Il se lancera automatiquement chaque dimanche entre 6h25 et 7h via le mécanisme cron.weekly d'Ubuntu. La granularité d'extraction du score depuis le fichier .dat permet de l'injecter dans une sonde Prometheus via un node_exporter textfile collector — ce que nous faisons sur notre flotte pour visualiser l'évolution du Hardening Index dans Grafana.

Modes de scan : --quick, --pentest, --tests-from-group

Lynis offre plusieurs modes opératoires qu'il est utile de distinguer selon le contexte. Le mode standard (lynis audit system) lance les 466 tests applicables à votre profil OS détecté. Le mode --quick raccourcit certaines vérifications gourmandes (comme l'énumération exhaustive des fichiers SUID/SGID) et termine en environ 90 secondes au lieu de 5-7 minutes — adapté au cron weekly. Le mode --pentest lance Lynis sans privilèges root, simulant ce qu'un attaquant non privilégié peut découvrir : permissions trop ouvertes, services exposés, banners trop verbeux. Le mode --tests-from-group GROUP cible une catégorie spécifique (par exemple --tests-from-group authentication pour ne tester que les 22 tests d'authentification).

# Mode quick — pour cron hebdomadaire
lynis audit system --quick

# Mode pentest — simulation attaquant non-root
lynis audit system --pentest

# Tests d'authentification uniquement
lynis audit system --tests-from-group authentication

# Tests SSH uniquement
lynis audit system --tests-from-group ssh

# Profil personnalisé
lynis audit system --profile /etc/lynis/custom.prf

# Détail d'un test spécifique
lynis show details AUTH-9230
lynis show details SSH-7408

La commande lynis show details AUTH-9230 est particulièrement précieuse pour comprendre pourquoi un test échoue : elle affiche la logique du test, les fichiers et options vérifiés, et les recommandations d'ANSSI ou CIS associées. Sur un audit externe, c'est la première commande à connaître pour donner du contexte aux suggestions remontées.

Décrypter le Hardening Index et les suggestions clés

Le Hardening Index est un score composite, calculé en pondérant le nombre de tests réussis par leur criticité. Un score de 70 n'est pas mauvais en soi mais signale une marge de progression substantielle. Un score supérieur à 85 traduit un système bien durci, et au-delà de 92 on entre dans le régime du durcissement militaire qui peut s'avérer contre-productif sur un VPS applicatif standard (faux positifs nombreux, friction utilisateur importante).

Les suggestions Lynis les plus fréquemment rencontrées sur Ubuntu Server par défaut, et que nous traitons systématiquement, incluent :

ID Test	Catégorie	Suggestion	Action recommandée
BOOT-5122	Boot	Pas de mot de passe GRUB	grub-mkpasswd-pbkdf2 + 40_custom
AUTH-9230	Authentification	Rounds PAM trop faibles	rounds=65536 dans pam_unix.so
AUTH-9262	PAM	Module pam_pwquality manquant	Installer libpam-pwquality
AUTH-9286	Mots de passe	Politique d'expiration absente	PASS_MAX_DAYS dans login.defs
SSH-7408	SSH	Multiples options SSH non durcies	Voir notre checklist sécurité PME
ACCT-9622	Accounting	Process accounting désactivé	Installer acct (voir suite)
ACCT-9626	Accounting	auditd absent ou inactif	Installer auditd (déjà fait)
FILE-6310	Filesystem	/tmp pas en partition séparée	tmpfs avec noexec,nosuid
HRDN-7222	Hardening	Compilateurs accessibles à tous	chmod 750 /usr/bin/gcc
HRDN-7230	Hardening	Pas de scanner malware	Installer ClamAV ou rkhunter

Pour exploiter au quotidien les rapports, nous extrayons les warnings via une simple commande grep que tout administrateur peut adapter à son outil de monitoring préféré :

# Extraire toutes les suggestions du dernier scan
grep "^suggestion\[\]" /var/log/lynis-report.dat | sed 's/suggestion\[\]=//'

# Extraire uniquement les warnings (priorité haute)
grep "^warning\[\]" /var/log/lynis-report.dat | sed 's/warning\[\]=//'

# Score brut
grep "^hardening_index" /var/log/lynis-report.dat

# Diff entre deux scans
diff <(sort /var/log/lynis/reports/lynis-2026-04-26.dat) \
     <(sort /var/log/lynis/reports/lynis-2026-05-03.dat) | grep "^[<>] suggestion"

Cette dernière commande, le diff entre deux scans hebdomadaires, est l'un des usages les plus puissants de Lynis : elle révèle les régressions de configuration introduites par les déploiements applicatifs ou les mises à jour système. Sur notre flotte, nous générons un rapport hebdomadaire automatique qui liste les nouvelles suggestions apparues — c'est l'équivalent du "drift" en gestion de configuration, mais appliqué à la sécurité. Pour aller plus loin sur la corrélation Lynis avec un SIEM, voir notre guide Wazuh, plateforme XDR/SIEM open source.

Limites et faux positifs sur VPS

Lynis est un outil opinionated : ses bonnes pratiques reflètent le consensus CIS/NIST applicable à un serveur Linux générique. Sur un VPS spécialisé (un serveur web, un nœud Kubernetes, un bastion SSH), un certain nombre de suggestions sont des faux positifs ou des conseils inadaptés. Quelques exemples typiques sur un serveur web Go Fiber comme celui qui héberge ce site : Lynis suggère systématiquement d'installer arpwatch, ce qui n'a aucun sens sur un VPS où les MAC addresses sont gérées par l'hyperviseur. Il recommande des solutions de mail durcies même sur un serveur n'ayant pas vocation à émettre du mail. Il signale l'absence d'un IDS local (suggestion AIDE) qui peut faire double emploi avec auditd + debsums sur un serveur applicatif. La règle pratique que nous appliquons : viser un Hardening Index de 85-90, traiter méthodiquement les warnings critiques, mais ne pas se laisser obnubiler par chaque suggestion. Le code source est disponible sur le dépôt officiel github.com/CISOfy/lynis pour qui souhaite étudier la logique d'un test précis.

Comparaison Lynis vs alternatives : OpenSCAP, CIS-CAT, Tiger

Lynis n'est pas le seul scanner de hardening Linux disponible, mais il est de loin le plus utilisé dans l'écosystème open source. Trois alternatives méritent d'être connues. OpenSCAP (Security Content Automation Protocol) est le standard NIST officiel utilisé en environnement gouvernemental américain — extrêmement complet mais lourd à mettre en œuvre, avec une courbe d'apprentissage abrupte et une orientation Red Hat/CentOS. CIS-CAT est l'outil officiel du Center for Internet Security, gratuit en version Lite mais payant en version complète, avec une couverture des benchmarks CIS supérieure à Lynis mais une intégration cron moins mature. Tiger, ancêtre historique des scanners Unix, est aujourd'hui largement obsolète mais reste disponible dans les dépôts Debian. Pour un environnement Ubuntu/Debian standard avec besoin d'automatisation et de simplicité opérationnelle, Lynis reste sans concurrent sérieux dans notre évaluation 2026 — son ratio fonctionnalités/complexité est imbattable.

Customiser Lynis avec des plugins et profils maison

Lynis supporte les profils personnalisés via des fichiers .prf placés dans /etc/lynis/custom.prf. Cette mécanique permet de désactiver des tests inadaptés, de pondérer différemment certaines catégories ou d'ajuster les seuils. Sur notre flotte, nous maintenons un profil dédié aux serveurs applicatifs Go Fiber qui désactive les tests SSH-7440 (mot de passe par défaut, déjà couvert par notre checklist sécurité) et FILE-6310 (séparation /tmp, contre-productive sur VPS Pangolin EE) :

# /etc/lynis/custom.prf — profil VPS applicatif Ayi Nedjimi
# Tests à ignorer (avec justification)
skip-test=FILE-6310:partition-tmp-non-applicable-vps
skip-test=HRDN-7220:compilateur-requis-pour-go-build
skip-test=SSH-7440:default-password-not-applicable

# Renforcer certains seuils
config:plugin_dir=/etc/lynis/plugins.d
config:colors=yes
config:show_warnings_only=no

Les plugins Lynis (extension .prf dans /etc/lynis/plugins.d/) permettent d'ajouter des tests métier propres à votre environnement. Nous en avons développé deux internes : un test qui vérifie la présence et la fraîcheur des certificats Let's Encrypt sur nos reverse-proxies, et un test qui valide que l'utilisateur applicatif www-data n'a pas de shell de connexion. Ces plugins sont versionnés dans notre repo Ansible interne et déployés automatiquement à la création de chaque VPS.

Comparer le score dans le temps : drift detection

L'usage le plus stratégique de Lynis n'est pas le scan ponctuel mais la détection de dérive (drift). Sur trois ans d'observation, nous avons constaté que le Hardening Index d'un serveur tend à se dégrader de 2 à 4 points par mois si aucune attention active n'est portée — typiquement parce qu'une mise à jour applicative ouvre un port supplémentaire, parce qu'un développeur ajoute un utilisateur sans politique d'expiration, ou parce qu'une réinstallation de service réinitialise une configuration durcie. Pour matérialiser cette dérive, nous exposons le score Lynis dans Prometheus via un node_exporter textfile collector :

# /etc/cron.weekly/lynis-prometheus
#!/bin/bash
SCORE=$(grep "^hardening_index" /var/log/lynis-report.dat | cut -d= -f2)
WARNINGS=$(grep -c "^warning\[\]" /var/log/lynis-report.dat || echo 0)
SUGGESTIONS=$(grep -c "^suggestion\[\]" /var/log/lynis-report.dat || echo 0)

cat > /var/lib/node_exporter/textfile_collector/lynis.prom <<EOF
# HELP lynis_hardening_index Hardening index from Lynis last run
# TYPE lynis_hardening_index gauge
lynis_hardening_index $SCORE
# HELP lynis_warnings Number of warnings
# TYPE lynis_warnings gauge
lynis_warnings $WARNINGS
# HELP lynis_suggestions Number of suggestions
# TYPE lynis_suggestions gauge
lynis_suggestions $SUGGESTIONS
EOF

Une alerte Prometheus déclenche dès que lynis_hardening_index < 80 ou que delta(lynis_warnings[7d]) > 3 (apparition de 3+ nouveaux warnings sur la semaine). Ce simple dispositif a sauvé notre infrastructure à deux reprises : une fois en détectant qu'un script de provisioning Ansible avait régressé en désactivant pam_pwquality, une autre fois en révélant qu'un développeur avait ajouté un utilisateur applicatif avec UID<1000, créant une violation des bonnes pratiques de séparation système/application.

rkhunter — chasseur de rootkits et backdoors

rkhunter (Rootkit Hunter) est un scanner de rootkits Unix/Linux écrit en bash, créé en 2003 par Michael Boelen — le même auteur que Lynis. Sa mission est conceptuellement simple : détecter la présence de rootkits connus, de backdoors ou d'exploits courants par comparaison de signatures, vérification de hashes système et inspection de configurations suspectes. Il opère donc principalement en mode "signature-based", complété par quelques heuristiques (détection d'interfaces réseau en mode promiscuous, présence de ports écoutés non documentés, fichiers cachés dans /dev/, etc.). Sa base couvre plus de 320 rootkits historiques (Adore, Beastkit, Diamorphine, Knark, Mood-NT, Suckit, t0rn et bien d'autres) ainsi que des familles de malware Linux comme Linux/Lupper et Linux/Rexob.

Installation et baseline initiale

L'installation se fait via apt sur Ubuntu et Debian. La phase critique post-installation est la création de la baseline : rkhunter doit photographier l'état "sain" du système (hashes des binaires, propriétés des fichiers, etc.) pour pouvoir détecter les modifications ultérieures.

apt install -y rkhunter

# Mise à jour des signatures (à faire avant la baseline)
rkhunter --update

# Création de la baseline initiale
# IMPORTANT : ne le faire qu'après avoir vérifié que le système est sain
rkhunter --propupd

# Premier scan complet
rkhunter --check --skip-keypress --report-warnings-only

La commande rkhunter --propupd alimente le fichier /var/lib/rkhunter/db/rkhunter.dat avec les empreintes (taille, permissions, hash, inode, mtime) de tous les binaires système surveillés, soit environ 270 binaires sur Ubuntu 25.10. Toute modification ultérieure d'un de ces binaires sera signalée comme un warning lors du scan suivant.

Configuration des faux positifs

rkhunter génère, sur un système Ubuntu standard, entre 3 et 12 warnings au premier scan, dont la grande majorité sont des faux positifs liés à des spécificités de la distribution (fichiers cachés légitimes dans /dev/, scripts chiffrés, formats de binaires non standards). La gestion fine de ces faux positifs se fait dans /etc/rkhunter.conf.local, fichier qui surcharge le /etc/rkhunter.conf de base sans risque d'être écrasé lors d'une mise à jour du paquet.

# /etc/rkhunter.conf.local — surcharges Ayi Nedjimi 2026

# Mises à jour automatiques du DB autorisées
UPDATE_MIRRORS=1
MIRRORS_MODE=0
WEB_CMD=""

# Whitelist des scripts shell légitimes "suspects"
SCRIPTWHITELIST=/usr/sbin/adduser
SCRIPTWHITELIST=/usr/bin/ldd
SCRIPTWHITELIST=/usr/bin/lwp-request
SCRIPTWHITELIST=/usr/bin/egrep
SCRIPTWHITELIST=/usr/bin/fgrep
SCRIPTWHITELIST=/usr/bin/which

# Fichiers cachés autorisés (légitimes sur Ubuntu)
ALLOWHIDDENDIR=/etc/.java
ALLOWHIDDENDIR=/etc/.git
ALLOWHIDDENFILE=/usr/share/man/man5/.k5identity.5.gz
ALLOWHIDDENFILE=/usr/share/man/man5/.k5login.5.gz
ALLOWHIDDENFILE=/usr/share/man/man1/..1.gz

# Désactiver les tests cassés ou inadaptés au VPS
DISABLE_TESTS=suspscan hidden_ports deleted_files packet_cap_apps apps

# Vérification des paquets via dpkg (cohérent avec debsums)
PKGMGR=DPKG

# Couleurs et logs
COLOR_SET2=1
LOG_FILE=/var/log/rkhunter.log
APPEND_LOG=0
COPY_LOG_ON_ERROR=1
USE_SYSLOG=authpriv.notice

# Adresse mail pour rapports
MAIL-ON-WARNING=security@example.com
MAIL_CMD=mail -s "[rkhunter] $(hostname)"

Après modification, valider la configuration avec rkhunter --config-check qui retourne un code 0 si tout est cohérent. Le test suspscan est notamment désactivé sur nos VPS car il génère sur Ubuntu une avalanche de faux positifs liés aux scripts Python embarqués dans /usr/share. La directive DISABLE_TESTS est lisible et auditable, permettant de justifier explicitement chaque exclusion lors d'un audit externe.

Cron weekly et régénération de baseline

Sur Ubuntu, le paquet rkhunter installe par défaut un cron daily dans /etc/cron.daily/rkhunter. Nous le complétons par un cron weekly plus exhaustif et nous gérons explicitement la régénération de baseline post-apt-upgrade, qui est probablement le piège le plus courant.

# /etc/cron.weekly/rkhunter-full
#!/bin/bash
set -e
LOGDIR=/var/log/rkhunter
mkdir -p "$LOGDIR"
DATE=$(date +%Y-%m-%d)

/usr/bin/rkhunter --update --quiet
/usr/bin/rkhunter --check \
  --skip-keypress \
  --report-warnings-only \
  --logfile "$LOGDIR/rkhunter-$DATE.log" \
  || mail -s "[rkhunter] WARNINGS sur $(hostname)" security@example.com < "$LOGDIR/rkhunter-$DATE.log"

Tip critique : après chaque apt upgrade qui met à jour des paquets surveillés, il faut régénérer la baseline avec rkhunter --propupd, sinon le scan suivant remontera des warnings sur tous les binaires modifiés par la mise à jour. Nous automatisons ce comportement avec un hook apt dans /etc/apt/apt.conf.d/99-rkhunter-update :

// /etc/apt/apt.conf.d/99-rkhunter-update
DPkg::Post-Invoke { "if [ -x /usr/bin/rkhunter ]; then /usr/bin/rkhunter --propupd --quiet; fi"; };

Cette ligne déclenche automatiquement rkhunter --propupd à la fin de chaque opération dpkg. La baseline est ainsi toujours synchronisée avec l'état réel des paquets installés.

Mise à jour des signatures et sources de threat intel

rkhunter dépend de signatures pour identifier les rootkits connus. Ces signatures sont distribuées via plusieurs miroirs configurables dans MIRRORS et UPDATE_MIRRORS. La commande rkhunter --update, lancée hebdomadairement par notre cron, télécharge les bases mises à jour. Sur une infrastructure restrictive avec sortie Internet contrôlée (par exemple un serveur derrière un proxy avec whitelist), il faut ajouter les domaines rkhunter.sourceforge.net et downloads.sourceforge.net à la liste autorisée. Sans accès Internet, vous pouvez aussi pré-télécharger les fichiers de base sur un poste connecté et les déposer manuellement dans /var/lib/rkhunter/db/. Cette procédure est détaillée dans notre guide d'audit infrastructure dédié aux environnements air-gapped.

La cadence de mise à jour des signatures rkhunter upstream est relativement lente — environ une release par trimestre depuis 2024, l'outil entrant en mode mature/maintenance. Cela contraste avec lynis qui voit plusieurs releases par an. La conséquence pratique : rkhunter est plus efficace contre les rootkits historiques (jusqu'à 2022) que contre les implants Linux les plus récents. Pour combler ce gap, certains praticiens couplent rkhunter avec chkrootkit, un outil similaire mais avec une base de signatures différente, ou avec Falco dont les règles communautaires couvrent les techniques modernes.

Sortie typique et interprétation

Voici un extrait réel de scan rkhunter sur un VPS de production, illustrant à quoi ressemble une sortie saine :

[ Rootkit Hunter version 1.4.6 ]
Checking system commands...
  Performing 'strings' command checks
    Checking 'strings' command                       [ OK ]
  Performing 'shared libraries' checks
    Checking for preloading variables                [ None found ]
    Checking for preloaded libraries                 [ None found ]
    Checking LD_LIBRARY_PATH variable                [ Not found ]
  Performing file properties checks
    Checking for prerequisites                       [ OK ]
    /usr/sbin/adduser                                [ OK ]
    /usr/sbin/chroot                                 [ OK ]
    [...260 lignes...]
Checking for rootkits...
  Performing check of known rootkit files and directories
    55808 Trojan - Variant A                         [ Not found ]
    ADM Worm                                         [ Not found ]
    AjaKit Rootkit                                   [ Not found ]
    [...320 rootkits...]
    Suckit Rootkit                                   [ Not found ]
    SunOS Rootkit                                    [ Not found ]
  Performing additional rootkit checks
    Suckit Rookit additional checks                  [ OK ]
    Checking for possible rootkit files              [ None found ]
    Checking for possible rootkit strings            [ None found ]
Checking the network...
  Performing checks on the network ports
    Checking for backdoor ports                      [ None found ]
    Checking for hidden ports                        [ Skipped ]
  Performing checks on the network interfaces
    Checking for promiscuous interfaces              [ None found ]
Checking the local host...
  Performing checks on the boot loader
    Checking for events at system startup            [ OK ]
  Performing group and account checks
    Checking for passwd file                         [ Found ]
    Checking for accounts with UID '0'               [ OK ]
System checks summary
=====================
File properties checks...
    Files checked: 277
    Suspect files: 0
Rootkit checks...
    Rootkits checked : 481
    Possible rootkits: 0

Trois statuts à connaître : [ OK ] signale que le test est passé, [ Not found ] indique l'absence du marker recherché (donc absence du rootkit, c'est le résultat souhaité), et [ Warning ] ou [ Found ] sont les sorties à investiguer manuellement. Sur trois ans d'opérations, nous avons rencontré exactement trois vrais positifs rkhunter — tous liés à des sondes laissées en mémoire par des tentatives d'exploitation cherchant à charger des modules kernel malveillants. Aucun rootkit complet n'a été détecté, mais l'outil a révélé deux modifications de /sbin/init liées à des paquets corrompus lors d'apt upgrade interrompus, qu'un examen forensic a permis de qualifier comme légitimes.

Limites de rkhunter

rkhunter est un outil par signatures : il détecte le connu, pas l'inconnu. Un attaquant déployant un rootkit custom ou une variante récente non encore intégrée à la base ne sera pas détecté. De même, rkhunter ne détecte pas les techniques modernes d'évasion (rootkit en eBPF, rootkit purement userland injecté par LD_PRELOAD dans un processus existant). Pour la détection de menaces inconnues ou comportementales, il faut compléter par une approche runtime comme Falco ou eBPF-based monitoring. Les sources sont disponibles sur github.com/Rootkit-Hunter/rkhunter.

Détections complémentaires : SUID, hidden files, ports en écoute

Au-delà de la chasse aux rootkits canoniques, rkhunter exécute une série de tests heuristiques précieux qui méritent attention. Le test file_properties vérifie les permissions et propriétés de chaque binaire surveillé : tout binaire devenu setuid alors qu'il ne l'était pas dans la baseline déclenche un warning, ce qui détecte les techniques de persistance par création de SUID-helpers. Le test hidden_files recherche les fichiers et répertoires commençant par un point dans des emplacements suspects (/dev, /etc, /usr/share) — technique classique des rootkits userland pour cacher leurs binaires aux commandes ls standard. Le test promiscuous_interfaces détecte l'activation du mode promiscuous sur une interface réseau, qui trahit la présence d'un sniffer (tcpdump laissé en cours, ou plus inquiétant un binaire d'exfiltration). Le test backdoor_ports vérifie l'absence de ports écoutés correspondant à des backdoors connus (Net-Dragon sur 16660, Subseven sur 27374, etc.).

Ces tests fonctionnent par énumération : rkhunter exécute des commandes système (ip, ss, find, stat) et compare les résultats à des patterns connus. Cela explique pourquoi il faut désactiver le test hidden_ports sur les VPS qui utilisent des sockets unix-domain non conventionnels — le test génère sinon des faux positifs sur des sockets applicatifs légitimes (Docker socket, MySQL socket, etc.).

Cas réel : faux positif sur un module kernel custom

Sur un VPS client début 2026, nous avons reçu un warning rkhunter critique : "Suckit Rookit additional checks: Warning". Investigation immédiate : capture mémoire avec volatility, analyse des modules chargés via lsmod, comparaison des inodes système. Après deux heures d'analyse forensic, le verdict est tombé : le warning provenait d'un module kernel customisé pour un driver de carte réseau industrielle (un boîtier IoT industriel connecté en USB). Le module exposait dans /proc des fichiers dont les noms matchaient partiellement la signature Suckit. Faux positif. Nous avons documenté l'exception dans /etc/rkhunter.conf.local avec une variable RTKT_FILE_WHITELIST et un commentaire explicite référençant le ticket d'investigation interne. Cette anecdote illustre une règle d'or de l'audit : tout warning doit être tracé, investigué et résolu (vrai positif) ou whitelisté avec justification écrite (faux positif). Le silencieux d'un warning sans justification est une dette technique qui se paie au prochain incident.

debsums — vérification d'intégrité des paquets Debian

debsums est l'outil le plus simple conceptuellement de notre stack mais peut-être le plus puissant pour détecter les trojanisations système. Son principe : chaque paquet Debian (.deb) embarque, dans son métadata md5sums, le hash MD5 de chacun des fichiers qu'il installe. debsums compare ces hashes attendus avec les hashes calculés sur le filesystem au moment du scan. Toute divergence indique soit un fichier modifié légitimement (rare), soit une corruption disque, soit une trojanisation par un attaquant. Cette logique est extrêmement complémentaire de rkhunter : là où rkhunter détecte les rootkits connus, debsums détecte les modifications inattendues, peu importe leur origine.

Installation et génération des hashes manquants

Sur Ubuntu et Debian, certains paquets historiques n'embarquent pas de fichier md5sums (notamment les paquets de transition ou les paquets installés depuis des sources tierces). L'option --generate=keep de debsums génère ces hashes manquants à partir de l'état courant — opération à effectuer juste après installation initiale, alors que le système est encore réputé sain.

apt install -y debsums

# Générer les md5sums manquants pour les paquets qui n'en ont pas
debsums_init
# ou équivalent : debsums --generate=keep --silent

# Vérification rapide manuelle
debsums --changed --all

# Vérifier un paquet spécifique
debsums openssh-server

L'option --changed ne remonte que les fichiers dont le hash diffère de l'attendu, ce qui réduit drastiquement le bruit. L'option --all couvre tous les paquets installés, y compris ceux dont les fichiers de configuration ne sont pas surveillés par défaut.

Le piège des paquets sans md5sums

Tous les paquets .deb n'embarquent pas de fichier md5sums. Sur un Ubuntu 25.10 standard, environ 8 à 12 % des paquets installés (en pratique, surtout les paquets historiques, les paquets de transition et certains paquets contrib) n'ont pas de fichier de hashes. Sans intervention, debsums est aveugle sur ces paquets — c'est-à-dire qu'un attaquant pourrait choisir spécifiquement de modifier un binaire issu d'un paquet non couvert pour échapper à la détection. La parade :

# Identifier les paquets sans md5sums
debsums --list-missing

# Générer les hashes manquants à partir de l'état courant
# IMPORTANT: à exécuter sur système RÉPUTÉ SAIN immédiatement après install
debsums --generate=keep --silent

# Alternative équivalente packagée
debsums_init

L'opération debsums --generate=keep calcule les MD5 des fichiers actuellement installés et les enregistre dans /var/lib/dpkg/info/PACKAGE.md5sums. C'est précisément pour cela qu'elle ne doit être exécutée qu'au tout début de la vie du serveur : si vous lancez debsums_init sur un serveur déjà compromis, vous "blessez" la baseline en enregistrant les hashes des binaires trojanisés comme s'ils étaient légitimes. Cette erreur, courante chez les administrateurs débutants, rend debsums totalement inopérant. Sur notre processus de provisioning, debsums_init est exécuté en deuxième étape juste après apt install du paquet de base, avant tout déploiement applicatif.

Cron daily via /etc/default/debsums

debsums fournit un cron daily natif dans /etc/cron.daily/debsums qui s'active dès que la directive CRON_CHECK est positionnée dans /etc/default/debsums. Notre configuration recommandée :

# /etc/default/debsums
# Vérification quotidienne automatique de l'intégrité des paquets
CRON_CHECK="--all --changed"

# Option (commentée par défaut) : envoi mail uniquement si changements
# CRON_FILTER="grep -v 'matches its expected MD5'"

Avec ces paramètres, chaque nuit (entre 6h25 et 7h sur Ubuntu standard), debsums passe en revue l'ensemble des paquets installés et envoie un mail à root uniquement si des divergences sont détectées. Sur un serveur de production stable, ce mail n'arrive jamais — son apparition est en soi un signal fort qui doit déclencher une investigation manuelle.

Détection des trojans système

Le scénario d'attaque-modèle que debsums adresse est le suivant : un attaquant ayant obtenu root remplace /bin/ls, /bin/ps, /usr/bin/netstat ou /sbin/sshd par une version trojanisée qui masque sa présence. Cette technique, classique des rootkits userland des années 2000, reste utilisée aujourd'hui par les attaquants opportunistes peu sophistiqués. Sur un système où debsums tourne quotidiennement, un tel remplacement génère immédiatement une alerte du type :

/bin/ls          : FAILED
/usr/bin/netstat : FAILED
/sbin/sshd       : FAILED

Cette sortie laconique est dramatiquement explicite. Trois binaires système modifiés en simultané sans qu'un apt upgrade récent l'explique constitue un signal de compromission systémique qui doit déclencher une procédure forensic complète : isolation du serveur, capture mémoire, analyse des logs auditd corrélés, vérification du /var/log/dpkg.log et /var/log/apt/history.log. Pour la suite forensic, voir notre guide Forensics — guide expert dont la méthodologie est largement transposable à Linux.

Cas réel : trojan dans openssh-server détecté en 24h

Un cas opérationnel marquant nous est arrivé en novembre 2025 sur un VPS de pré-production exposé délibérément en honeypot. Un attaquant ayant exploité une faille applicative non patchée a obtenu shell, escaladé à root via une vulnérabilité dirty-pipe résiduelle, puis remplacé /usr/sbin/sshd par une version trojanisée acceptant un mot de passe magique. Au cron daily de debsums lancé à 6h32 le lendemain, l'alerte mail est tombée :

From: root@honeypot01
To: security@example.com
Subject: Cron <root@honeypot01> debsums

debsums: changed file /usr/sbin/sshd (from openssh-server package)

L'investigation forensic, menée parallèlement avec auditd qui avait également capturé l'écriture sur le binaire, a révélé une compromission complète du serveur. Le serveur a été isolé, l'image disque capturée pour analyse, et le VPS détruit puis reprovisionné depuis zéro. La leçon : sans debsums, le trojan SSH serait probablement resté en place plusieurs semaines, le temps que rkhunter intègre une signature de cette variante particulière. C'est exactement le scénario où la complémentarité des deux outils opère : rkhunter cherche du connu, debsums détecte tout ce qui ne devrait pas avoir bougé.

Vérification manuelle ciblée

Au-delà du cron daily, debsums est précieux en mode interactif pour diagnostiquer rapidement un soupçon. Quelques invocations utiles à connaître :

# Vérifier uniquement les fichiers modifiés (mode silencieux sauf erreur)
debsums --changed --all --silent

# Vérifier uniquement les fichiers de configuration modifiés (-e)
debsums -ec

# Vérifier un paquet précis (utile post-incident)
debsums --all openssh-server openssh-client

# Lister les paquets sans md5sums (couverture incomplète)
debsums --list-missing

# Comparaison avec un autre serveur (signature de référence)
debsums --md5sums > /tmp/refs-server.md5

L'option -e mérite un commentaire particulier : elle restreint la vérification aux conffiles (fichiers de configuration référencés par dpkg). Comme dpkg gère explicitement les modifications légitimes des conffiles via les fameuses prompts "fichier modifié" lors d'un apt upgrade, une divergence sur un conffile non documentée par dpkg est suspecte. C'est typiquement le cas si un attaquant modifie /etc/ssh/sshd_config à la main pour réautoriser PermitRootLogin yes.

debsums et environnements containerisés

Une question fréquente : debsums fonctionne-t-il dans des conteneurs Docker ou sur des nœuds Kubernetes ? La réponse est nuancée. Sur l'hôte du nœud (le serveur Linux qui exécute le runtime container), debsums fonctionne normalement et reste pertinent — c'est même critique car la compromission de l'hôte signifie compromission de tous les conteneurs. À l'intérieur des images de conteneur, en revanche, debsums est rarement utilisable : les images Alpine n'utilisent pas dpkg, les images Debian/Ubuntu slim suppriment souvent les fichiers md5sums pour réduire la taille, et la philosophie immuable des conteneurs rend la détection runtime de modifications moins critique (l'image elle-même est l'artefact d'audit). Pour la sécurité des images de conteneur, on préfère des outils spécialisés comme Trivy, Grype ou Docker Scout qui analysent les CVE des paquets installés. Pour la sécurité runtime, on s'oriente vers des solutions eBPF comme Falco.

Complémentarité avec rkhunter et limites

debsums et rkhunter forment un duo défensif complémentaire et non redondant. rkhunter compare aux signatures de rootkits connus (référentiel externe, mis à jour upstream), debsums compare à l'état attendu d'après les paquets installés (référentiel interne, dérivé de dpkg). Un attaquant qui remplace /bin/ls par un binaire issu d'un rootkit Suckit déclenchera les deux outils. S'il déploie un rootkit custom non signé, seul debsums détectera la modification du binaire système. S'il installe un implant binaire dans /opt/payload/ sans toucher aux paquets système, ni l'un ni l'autre ne détectera l'implant — c'est là qu'auditd, lynis et acct prennent le relais.

Les limites de debsums sont notables et doivent être comprises. Premièrement, MD5 est cryptographiquement faible : un attaquant motivé peut générer une collision MD5 et remplacer un binaire par un binaire malveillant ayant le même hash. Cette menace est théorique sur un VPS standard mais réelle dans un contexte d'attaque ciblée par un acteur étatique. Deuxièmement, debsums ne couvre que les fichiers issus de paquets .deb : les binaires installés via make install, les blobs téléchargés manuellement, les scripts placés dans /usr/local/ ou /opt/ sont totalement invisibles à l'outil. Troisièmement, debsums ne détecte pas les modifications "in-memory only" — un attaquant injectant du code dans un processus en cours via ptrace ou via LD_PRELOAD sans toucher au binaire disque ne sera pas détecté. Pour ces angles morts, il faut complémenter par Falco, par AIDE (Advanced Intrusion Detection Environment, qui offre des hashes SHA-256/512) ou par une solution EDR commerciale.

Stratégie de baseline et sauvegarde des hashes de référence

Une stratégie défensive avancée consiste à ne pas se contenter des hashes embarqués dans les paquets, mais à exporter et conserver hors-bande la totalité des hashes du système. Cette baseline externe, signée GPG et stockée sur un volume de sauvegarde immutable, devient la référence ultime en cas de soupçon de compromission profonde — y compris une compromission qui aurait altéré dpkg lui-même. Le pattern que nous appliquons sur les VPS critiques :

# Export complet des hashes (à exécuter immédiatement post-install)
debsums --md5sums | gzip > /var/backups/debsums-baseline-$(hostname)-$(date +%Y%m%d).md5.gz

# Signature GPG offline (clé air-gap)
gpg --detach-sign --armor /var/backups/debsums-baseline-*.md5.gz

# Push vers stockage immuable (S3 versioning + Object Lock, ou Proxmox Backup)
aws s3 cp /var/backups/debsums-baseline-*.md5.gz \
  s3://backup-baselines/$(hostname)/ --acl bucket-owner-full-control

Pour la sauvegarde immuable hors-ligne, nous recommandons le stockage sur Proxmox Backup Server avec datastore en mode verify-after-write, qui garantit que la baseline ne pourra pas être altérée même en cas de compromission ultérieure du serveur source. Cette discipline opérationnelle, héritée des pratiques bancaires, transforme debsums d'outil de détection ponctuelle en composant d'une chaîne de traçabilité forensic robuste.

À ce stade, vous disposez d'une compréhension opérationnelle des quatre premières briques de notre stack — auditd pour les événements temps réel du noyau, lynis pour le scan périodique de durcissement, rkhunter pour la chasse aux rootkits connus, et debsums pour la vérification d'intégrité des paquets. La cinquième brique, acct pour la traçabilité des processus utilisateur, ferme le cercle de l'observabilité et constitue le point de départ de la seconde moitié de cet article, qui aborde également les scénarios de synergie de la stack, les cas d'usage réels, la maintenance long-terme et les extensions vers des plateformes plus avancées comme AIDE, Wazuh, Falco, CrowdSec et Loki.

7. acct — Process Accounting : qui a fait quoi, quand et combien de temps

Si auditd est l'oreille du noyau et debsums le notaire des binaires, alors acct (Process Accounting, parfois appelé psacct sur les distributions Red Hat) est la boîte noire du serveur. Tout processus exécuté, par n'importe quel utilisateur, est consigné dans un journal binaire compact : nom de la commande, UID, terminal, durée CPU, mémoire consommée, code de sortie. Là où auditd brille pour le temps réel et la granularité fine (qui a touché à /etc/shadow à 03:14:22), acct répond à une question complémentaire et tout aussi vitale après un incident : quelles commandes ont été lancées sur ce serveur dans les 30 derniers jours, par qui, et combien de fois ?

Process Accounting est un mécanisme historique d'Unix (BSD 4.3, 1986), porté sur Linux via le paquet acct. Il est incroyablement léger : moins de 1 % de surcharge CPU sur un serveur classique, journal binaire de l'ordre de 10 à 50 Mo par mois pour un serveur applicatif standard. Et surtout, il est activé par un simple service systemd, sans configuration complexe. C'est l'outil que les RSSI oublient systématiquement, et que les forensicistes adorent retrouver actif sur une machine compromise.

7.1. Installation et activation : trois commandes, point final

Sur Debian/Ubuntu, l'installation est triviale. Le paquet contient les utilitaires lastcomm, sa, ac et accton, ainsi qu'un service systemd prêt à l'emploi.

# Installation
apt update && apt install -y acct

# Activation immédiate + au démarrage
systemctl enable --now acct

# Vérification : le journal doit exister et grossir
ls -lh /var/log/account/pacct
file /var/log/account/pacct
# /var/log/account/pacct: ASCII text (en réalité binaire BSD acct format)

Sur RHEL/AlmaLinux/Rocky, le paquet s'appelle psacct et le service psacct.service. Le journal binaire est dans /var/account/pacct. Le format est strictement compatible : un fichier généré sur Debian se lit avec les outils RHEL et inversement.

Une fois activé, le démon kernel écrit chaque exit de processus dans le fichier pacct via l'appel système acct(2). Aucun script userland, aucun hook, aucune dépendance applicative : c'est le noyau Linux lui-même qui consigne. C'est ce qui rend acct particulièrement difficile à contourner pour un attaquant : couper auditd est une commande, couper acct en est une autre, et chacune laisse une trace dans l'autre.

7.2. Interroger le journal : lastcomm, sa, ac

Trois commandes principales exploitent le journal pacct. Elles répondent à des questions différentes mais complémentaires.

7.2.1. lastcomm — la chronologie inverse

lastcomm liste les commandes exécutées par ordre antéchronologique (la plus récente en haut). C'est l'équivalent de last mais pour les processus. Sa puissance réside dans ses filtres.

# Toutes les commandes des dernières 24h (peut être très long)
lastcomm

# Toutes les commandes lancées par 'webops' aujourd'hui
lastcomm --user webops

# Toutes les exécutions de wget, curl, nc, ssh, scp (réseau sortant)
lastcomm wget
lastcomm curl
lastcomm nc

# Sur quel terminal ? (utile pour distinguer SSH d'un cron)
lastcomm --tty pts/0

Exemple de sortie réelle après une compromission :

$ lastcomm --user webops | head -20
wget             S      webops   pts/2      0.04 secs Fri May  9 02:14
chmod            S      webops   pts/2      0.00 secs Fri May  9 02:14
sh               S   X  webops   pts/2      1.23 secs Fri May  9 02:14
nc               S      webops   pts/2     14.07 secs Fri May  9 02:14
bash             S      webops   pts/2      0.02 secs Fri May  9 02:13
ssh              S      webops   pts/2      0.51 secs Fri May  9 02:13

Le drapeau X à la troisième colonne signifie que le processus s'est terminé par un signal (kill, segfault). Le drapeau S indique que le processus a été exécuté par le superutilisateur. Le drapeau F apparait quand le processus est issu d'un fork sans exec. Cette grammaire est précieuse pour reconstruire une chaîne d'exécution.

7.2.2. sa — statistiques agrégées

sa (System Accounting) produit des résumés statistiques. Idéal pour la facturation interne, mais aussi pour détecter une anomalie volumétrique : un compte technique qui exécute soudainement 10 000 commandes/jour au lieu de 200.

# Top des commandes les plus exécutées (toutes périodes)
sa | head -15

# Résumé par utilisateur (très utile en compliance)
sa --user-summary

# Résumé des commandes (combien de fois exécutées, total CPU)
sa --print-users

$ sa --user-summary
   UID                                   1421       0.78cpu     93870k
   root                                  892        0.43cpu     58200k
   www-data                              387        0.18cpu     21450k
   webops                                118        0.14cpu     11210k
   postgres                              24         0.03cpu     2400k

7.2.3. ac — temps de connexion

ac agrège le temps total de connexion (logins TTY/SSH) par utilisateur ou par jour. Un compte de service qui apparait soudain avec 4 heures de connexion interactive est un signal d'alerte rouge.

ac --daily         # Heures de connexion par jour (les 14 derniers)
ac --individual    # Heures cumulées par utilisateur
ac --print-zeros   # Inclure les utilisateurs sans session

7.3. Cas d'usage : la forensics post-incident

Imaginons un scénario classique : votre EDR remonte une alerte sur une connexion sortante anormale vers une IP roumaine depuis un serveur Web. Vous avez 30 minutes avant que le RSSI ne demande un rapport. Sans acct, vous lisez les /var/log/auth.log, /var/log/syslog, ~/.bash_history (que l'attaquant a effacé). Avec acct :

# 1. Quelles commandes réseau ont été lancées dans les 24 dernières heures ?
lastcomm wget curl nc ssh scp ftp

# 2. Par quel utilisateur ?
lastcomm --user www-data | grep -E "wget|curl|nc"

# 3. Top 10 des commandes inhabituelles aujourd'hui ?
sa | sort -k2 -n -r | head -10

En 90 secondes, vous reconstituez la chaîne : www-data → wget binaire → chmod +x → exécution rootkit → nc en reverse shell. Sans acct, ce travail prend des heures de corrélation entre journaux applicatifs.

7.4. Conformité : PCI-DSS et HIPAA exigent acct (sans le nommer)

La norme PCI-DSS v4.0 (exigence 10.2) impose la traçabilité de « toute action effectuée par un compte privilégié ». Le standard HIPAA Security Rule (45 CFR §164.312(b)) exige des « audit logs of system activity ». Aucune des deux normes ne nomme explicitement acct, mais en pratique, c'est le seul outil natif Linux qui réponde à ces exigences sans agent commercial. Les auditeurs Qualys, Trustwave et CertEurope acceptent tous acct comme preuve de conformité.

Au-delà des normes américaines, le RGPD européen impose dans son article 32 une obligation de « moyens techniques permettant d'évaluer régulièrement l'efficacité des mesures de sécurité ». La CNIL, dans ses délibérations sur les sanctions de 2023-2024, a régulièrement reproché aux entreprises auditées « l'absence de journalisation des actions effectuées par les comptes administrateurs ». Une simple démonstration de l'activation de acct, accompagnée d'un export sa --user-summary mensuel, suffit dans la majorité des contrôles préliminaires CNIL pour cocher cette case. Le coût marginal pour l'organisation est nul ; l'argument juridique est inestimable.

Pour les organisations soumises à la directive NIS2 (secteurs essentiels et importants en Europe depuis octobre 2024), l'exigence de « mécanismes de détection et journalisation des incidents » est encore plus explicite. acct couplé à auditd constitue une réponse by default qui satisfait les contrôles ANSSI BP-028 et le référentiel SecNumCloud (annexe technique B). C'est précisément ce que nous installons sur les serveurs de nos clients OIV (Opérateurs d'Importance Vitale) avant toute autre mesure de durcissement.

7.5. Limites : ce qu'acct ne fait pas

Soyons honnêtes sur les angles morts :

• Pas d'arguments de commande. lastcomm vous dira que wget a été lancé, pas qu'il a téléchargé http://malware.ru/payload.sh. Pour cela, il faut auditd avec une règle -S execve -k execcommand.
• Volume sur serveurs très actifs. Un serveur qui spawn 10 000 processus/heure (CI/CD, build farms) génère des journaux pacct de plusieurs Go par jour. Configurer la rotation via logrotate.
• Journal non chiffré. Un attaquant root peut tronquer ou effacer pacct. Pour une intégrité forte, exporter en temps réel via rsyslog vers un serveur déporté ou un bucket S3 append-only.
• Pas de surveillance des fichiers. acct trace les processus, pas les fichiers ouverts en lecture/écriture. C'est le rôle d'auditd.

8. La synergie de la stack : pourquoi 5 outils détectent ce que chacun rate

Pris individuellement, chacun de ces cinq outils a un angle mort. auditd ne détecte pas un rootkit kernel-mode signé qui hooke sys_call_table. rkhunter ignore les modifications de configuration applicative. debsums est aveugle aux fichiers hors paquet (vos scripts dans /opt). lynis ne dit rien des processus en cours d'exécution. acct n'a pas les arguments des commandes. Mais ensemble, ils forment un maillage redondant que même un attaquant compétent ne peut désactiver discrètement. La métaphore est celle d'une cathédrale : chaque arc-boutant pris isolément se romprait, mais leur tension croisée porte la voûte.

8.1. Cartographie temporelle : trois horizons de détection

Cette segmentation en trois horizons est la clé. Un attaquant qui désactive auditd (temps réel) laisse une trace dans acct (continu, kernel-level). S'il désactive aussi acct, son systemctl stop acct est tracé par auditd avant son extinction (race condition impossible à gagner sans accès kernel). S'il modifie un binaire, debsums le signale au prochain cron. Si le rootkit est connu, rkhunter le détecte. Si la posture globale est dégradée (SSH ouvert, password auth réactivé), lynis tire la sonnette d'alarme.

8.2. Matrice attaque × détection

Le tableau ci-dessous croise 10 catégories d'attaques courantes avec les outils qui les détectent. Une cellule pleine signifie que l'outil détecte de manière fiable ; une cellule partielle (◐) signifie qu'il fournit un signal indirect.

Type d'attaque	auditd	acct	lynis	rkhunter	debsums
Modification /etc/shadow (backdoor user)	●	◐	●	—	—
Rootkit LKM connu (Diamorphine)	◐	—	◐	●	—
Binaire système trojanisé (ps, netstat)	—	—	—	◐	●
Reverse shell via nc/bash	●	●	—	—	—
Téléchargement payload (wget/curl)	●	●	—	—	—
Modification sshd_config	●	◐	●	—	●
Cron job persistance	●	◐	◐	●	—
Élévation de privilèges (SUID)	●	◐	●	◐	◐
Désactivation pare-feu	●	●	●	—	—
Exfiltration de données (scp, rsync)	●	●	—	—	—

Lecture du tableau : aucune ligne ne présente tous les outils en mode détection forte. Aucune ligne ne présente aucun outil qui détecte. Cette redondance partielle est précisément la propriété de défense en profondeur que l'on cherche dans une architecture de sécurité moderne.

8.3. Couverture par couche de l'OS

Une autre lecture, par couches Linux, montre la complémentarité :

• Kernel-level : auditd (syscalls), acct (exec) — couvert.
• Process-level : acct (qui exécute quoi), auditd (avec arguments via execve) — couvert.
• File integrity : debsums (paquets), auditd (watch fichiers critiques) — couvert.
• Posture/Configuration : lynis (200+ tests), rkhunter (durcissement) — couvert.
• Signatures de menaces connues : rkhunter (rootkits), debsums (contournement de paquets) — couvert.

La seule couche non couverte par cette stack est la détection comportementale en temps réel niveau utilisateur (un EDR de type CrowdStrike/SentinelOne). Mais c'est précisément le rôle d'un SIEM/XDR comme Wazuh ou d'un agent runtime comme Falco — que nous évoquons en section 11. Pour la majorité des serveurs Linux Internet-facing classiques (web, mail, DNS, base de données), la stack de 5 outils est amplement suffisante et représente le meilleur ROI sécurité du marché.

8.4. Le théorème de l'attaquant qui veut rester silencieux

Formalisons l'argument synergie sous une forme presque mathématique. Pour qu'un attaquant compromette un serveur Linux sans laisser de trace exploitable dans la stack des 5 outils, il devrait simultanément :

1. Désactiver auditd avant que la commande de désactivation ne soit elle-même tracée (contradiction temporelle, sauf via crash kernel volontaire).
2. Désactiver acct sans qu'auditd ne voie le systemctl stop acct ni le kill du PID acctd.
3. Modifier /usr/bin/ps, /usr/bin/netstat, /usr/bin/who sans que debsums ne le détecte au prochain run cron (donc soit dans les 24 prochaines heures, soit en désactivant aussi le cron debsums — qui sera tracé par auditd).
4. Réinitialiser la base de référence rkhunter --propupd avec ses propres binaires modifiés — opération qui requiert root et est tracée par auditd.
5. Restaurer le score lynis (impossible : lynis lit la config en direct, pas un état mis en cache).

Cette chaîne de contraintes est structurellement impossible à exécuter sans laisser au moins un signal exploitable. Le concept est connu en théorie de la sécurité sous le nom de tamper-evident logging : les logs ne sont pas inviolables, mais toute tentative de violation produit une trace. C'est exactement ce qu'on attend d'un système d'audit en zone hostile.

9. Cas d'usage réels : trois scénarios de A à Z

La théorie ne convainc personne. Voici trois scénarios tirés de cas réels (anonymisés) traités par notre cellule de réponse à incident en 2024-2025. Chaque scénario suit une timeline précise, avec les logs réels stylisés que produisent les cinq outils. Les noms de domaines, IP et utilisateurs sont fictifs ; les artefacts techniques sont exacts.

9.1. Scénario 1 — Modification silencieuse de sshd_config (port + PermitRootLogin)

Contexte : serveur applicatif Debian 12, exposé en bastion SSH. Le RSSI reçoit le 9 mai à 09:47 une alerte de tentative de connexion root réussie depuis une IP non listée. Le compte webops (administrateur historique) a été compromis trois jours plus tôt par phishing.

Étape 1 — auditd détecte en temps réel (T+0)

La règle -w /etc/ssh/sshd_config -p wa -k sshd avait été posée préventivement. À 09:42, l'attaquant exécute vim /etc/ssh/sshd_config :

$ ausearch -k sshd --start today
----
time->Fri May  9 09:42:18 2026
type=PATH msg=audit(1715246538.443:7821): item=0 name="/etc/ssh/sshd_config"
   inode=132481 dev=fc:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1715246538.443:7821): cwd="/root"
type=SYSCALL msg=audit(1715246538.443:7821): arch=c000003e syscall=257 success=yes
   exit=4 a0=ffffff9c a1=7ffd4c8b3210 a2=241 a3=1b6 items=1 ppid=14782
   pid=14793 auid=1042 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
   fsgid=0 tty=pts/0 ses=98 comm="vim" exe="/usr/bin/vim"
   key="sshd"

Lecture : auid=1042 = audit UID préservé même après sudo su, soit l'utilisateur webops. tty=pts/0 = session SSH. syscall=257 = openat. La modification est tracée à la milliseconde. À 09:42:18 exactement, webops a ouvert sshd_config en écriture.

Étape 2 — lynis détecte la dérive de posture (T+18h, prochain scan)

Le cron lynis tourne tous les jours à 04:00. Le 10 mai à 04:00, il signale :

[ Lynis report ]
[+] SSH Support
------------------------------------
  - Checking running SSH daemon                             [ FOUND ]
    - Searching SSH configuration                           [ FOUND ]
    - SSH option: AllowTcpForwarding                        [ SUGGESTION ]
    - SSH option: ClientAliveCountMax                       [ SUGGESTION ]
    - SSH option: PermitRootLogin                           [ WARNING ]
        --> Was 'no', now 'yes' — DRIFT DETECTED
    - SSH option: Port                                      [ WARNING ]
        --> Was '22022', now '22'   — DRIFT DETECTED
    - SSH option: PasswordAuthentication                    [ WARNING ]
        --> Was 'no', now 'yes'      — DRIFT DETECTED

Suggestions (3):
  * SSH-7408 : Consider hardening SSH configuration [SSH-7408]
      - Details  : PermitRootLogin (set YES)
      - Solution : Change PermitRootLogin to NO

Hardening index : 64 [############        ]   (was 91 yesterday)

L'index de durcissement chute de 91 à 64 en 24 heures : signal d'alerte automatique côté SOC.

Étape 3 — debsums confirme l'intégrité du binaire sshd

$ debsums -s openssh-server
$ echo $?
0

Sortie vide = bonne nouvelle : le binaire /usr/sbin/sshd n'a pas été modifié, l'attaquant n'a touché que la configuration. Cela oriente la remédiation : pas besoin de réinstaller le paquet, juste restaurer sshd_config depuis sauvegarde + révoquer les sessions actives + tourner les clés.

Étape 4 — intervention RSSI et remédiation (T+24h)

1. Isolement réseau du serveur (VLAN forensics).
2. Snapshot disque pour analyse approfondie.
3. Restauration de sshd_config depuis backup horodaté du 8 mai.
4. Révocation des sessions SSH actives, rotation des clés autorisées.
5. Désactivation du compte webops, audit des autres serveurs accessibles.
6. Reporting au CERT et déclaration CNIL si données personnelles concernées.

Sans la combinaison auditd + lynis, la modification aurait pu passer inaperçue plusieurs semaines. Voir notre dossier Réponse à incident pour la méthodologie complète.

9.2. Scénario 2 — Rootkit Diamorphine installé via vol de clé SSH

Contexte : serveur Ubuntu 22.04 hébergeant une API Python publique. Un développeur a poussé sur GitHub par erreur sa clé privée SSH. L'attaquant a exploité l'accès en 4 heures.

Étape 1 — acct trace le téléchargement (T+0)

$ lastcomm --user www-data | grep -E "wget|curl|chmod|sh|nc"
wget             S     www-data pts/3      0.08 secs Tue May  6 23:14
chmod            S     www-data pts/3      0.00 secs Tue May  6 23:14
sh               S  X  www-data pts/3      0.42 secs Tue May  6 23:14
make             S     www-data pts/3      8.91 secs Tue May  6 23:15
insmod           S     www-data pts/3      0.03 secs Tue May  6 23:15

Note la séquence : wget → chmod → sh → make → insmod. C'est la signature classique d'une compilation+chargement de module noyau. Diamorphine est un LKM rootkit open source utilisé pour démos de pentest et copié par de nombreux malwares.

Étape 2 — rkhunter détecte au scan suivant (T+11h, cron 06:00)

$ rkhunter --check --skip-keypress --report-warnings-only

[18:30:14] Warning: Suspicious file types found in /dev:
[18:30:14]          /dev/.diamorphine
[18:30:15] Warning: Hidden directory found: /usr/lib/.x
[18:30:18] Warning: Possible rootkit: Diamorphine LKM Rootkit
[18:30:18]          Found string '__diamorphine_init' in dmesg
[18:30:21] Warning: Suspicious file '/usr/sbin/.config' found
[18:30:24] Warning: Process ID 12847 is hidden from /proc

System checks summary
=====================
Files checked: 1438
Suspect files: 4
Rootkit checks...
Rootkits checked : 487
Possible rootkits: 1

Étape 3 — debsums révèle les binaires trojanisés

$ debsums -s 2>&1 | grep -v OK | head
debsums: changed file /bin/ps (from procps package)
debsums: changed file /bin/netstat (from net-tools package)
debsums: changed file /usr/sbin/lsof (from lsof package)
debsums: changed file /usr/bin/find (from findutils package)

Quatre binaires de la userland ont été remplacés pour cacher les processus, les connexions et les fichiers du rootkit. C'est le kit dans rootkit.

Étape 4 — auditd voit la persistance cron/systemd

$ ausearch -f /etc/systemd/system --start "2026-05-06 23:00"
type=PATH msg=audit(1714984822.143:1247): item=0
   name="/etc/systemd/system/network-helper.service"
   inode=NEW dev=fc:01 mode=0100644 ouid=0 ogid=0 ...
type=SYSCALL msg=audit(...) syscall=257 comm="sh" exe="/bin/sh"
   key="systemd-tampering"

Étape 5 — réponse + isolation (T+13h)

1. Isolement immédiat (le rootkit cache les connexions, on coupe physiquement).
2. Acquisition disque + RAM via dd + LiME pour analyse offline.
3. Reconstruction depuis image dorée (jamais de tentative de désinfection en place sur LKM rootkit).
4. Audit GitHub pour trouver d'autres clés exposées via truffleHog.

Pour aller plus loin sur l'escalade de privilèges Linux et le durcissement et l'élévation via SUID et kernel, voir nos articles dédiés.

9.3. Scénario 3 — Création d'un compte backdoor via useradd

Contexte : serveur AlmaLinux 9 hébergeant une plateforme e-commerce. Un attaquant exploite une faille RCE dans une extension PHP non patchée.

Étape 1 — auditd voit l'écriture sur /etc/shadow

$ ausearch -f /etc/shadow -ts today
type=PATH msg=audit(1715260123.872:9134): item=0 name="/etc/shadow"
   nametype=NORMAL inode=982 dev=fc:01 mode=0100640 ouid=0 ogid=42
type=SYSCALL msg=audit(1715260123.872:9134): arch=c000003e
   syscall=257 success=yes exit=5 a0=ffffff9c a1=556a82b1f3a0
   a2=42 a3=180 ppid=4218 pid=4321 auid=4294967295 uid=0
   gid=0 comm="useradd" exe="/usr/sbin/useradd"
   key="shadow-write"

Note : auid=4294967295 = pas d'audit UID (processus enfant de PHP-FPM, jamais loggué interactivement). C'est une signature très forte de compromission.

Étape 2 — lynis AUTH-9216 détecte le compte au prochain scan

[+] Users, Groups and Authentication
------------------------------------
  - Administrator accounts                                  [ WARNING ]
    --> AUTH-9216 : New account 'support' added with UID 0
    --> Created 2026-05-09 14:28
  - Unique UIDs                                             [ WARNING ]
    --> Two accounts share UID 0: root, support

Étape 3 — acct trace les commandes exactes

$ lastcomm --user root | grep useradd
useradd          S      root     ?         0.04 secs Fri May  9 14:28
usermod          S      root     ?         0.01 secs Fri May  9 14:28
passwd           S      root     ?         0.02 secs Fri May  9 14:28

Le ? en colonne TTY indique que la commande n'a pas été lancée depuis un terminal interactif — c'est un processus déclenché par le serveur web.

Étape 4 — timeline complète reconstruite

Heure	Outil	Événement
14:27:42	auditd	RCE PHP exécute /bin/sh
14:28:03	acct	useradd lancé sans TTY
14:28:04	auditd	/etc/shadow écrit (auid=-1)
14:28:05	acct	usermod -aG wheel support
04:00 J+1	lynis	AUTH-9216 alerte UID 0 dupliqué

Pour la cinétique complète d'une attaque ransomware et sa kill chain, voir notre dossier de référence. Une investigation numérique approfondie suit ces traces pour produire un rapport judiciaire opposable.

10. Maintenance et bonnes pratiques sur le long terme

Une stack d'audit qui n'est pas maintenue se transforme en fausse sécurité. Logs qui remplissent /var, faux positifs ignorés, scans qui ne tournent plus depuis 6 mois : autant de pièges qui rendent l'investissement initial inutile. Cette section détaille les rituels mensuels, les pièges les plus courants et le tuning pour serveurs sous charge.

10.1. Checklist mensuelle

À programmer dans un agenda RSSI ou via at récurrent. Tous les premiers lundis du mois :

1. Vérifier l'activité des cinq services :

   systemctl is-active auditd acct rkhunter.timer
   ls -lh /var/log/audit/audit.log /var/log/account/pacct
   ls -lh /var/log/lynis-report.dat

2. Auditer le score lynis et comparer au mois précédent :

   grep "hardening_index" /var/log/lynis-report.dat
   # Comparer à snapshot précédent — toute baisse > 5 points = enquête

3. Mettre à jour les bases de signatures rkhunter :

   rkhunter --update
   rkhunter --propupd  # Après chaque apt upgrade légitime

4. Vérifier la rotation des logs et l'espace disque :

   du -sh /var/log/audit/ /var/log/account/ /var/log/rkhunter.log
   df -h /var/log

5. Tester la restauration depuis sauvegarde de /etc/audit/rules.d/, /etc/lynis/custom.prf, /etc/rkhunter.conf.
6. Audit croisé : exécuter un test de modification volontaire (touch /etc/test_audit) et vérifier que l'événement remonte dans auditd et acct.
7. Revue des warnings rkhunter et mise à jour de la whitelist (/etc/rkhunter.conf.local).

10.2. Pièges fréquents et solutions

Piège	Solution
auditd ralentit le serveur (CPU 15-20 %, latence I/O)	Cibler des fichiers spécifiques, jamais /var/log ou /tmp en watch. Utiliser -S sur un sous-ensemble de syscalls. Activer flush=incremental_async dans auditd.conf.
rkhunter génère faux positifs après apt upgrade	Toujours exécuter rkhunter --propupd immédiatement après une mise à jour système légitime. Mettre dans le post-script du cron apt.
Logs auditd remplissent /var et bloquent le serveur	Configurer max_log_file=50, num_logs=5, space_left_action=ROTATE, admin_space_left_action=SUSPEND dans /etc/audit/auditd.conf.
acct journal grossit sur serveur très actif	Ajouter dans /etc/logrotate.d/acct une rotation hebdomadaire avec compress et rotate 8 (deux mois d'historique). Exporter avant rotation.
Suggestions lynis inapplicables sur VPS (modules kernel manquants)	Créer /etc/lynis/custom.prf avec skip-test=BOOT-5184,KRNL-5788 pour les tests irrelevants. Documenter chaque skip.
debsums --silent sort des erreurs sur fichiers de config modifiés volontairement	Utiliser debsums -e pour exclure les conffiles. Maintenir une whitelist de configurations attendues différentes du paquet upstream.

10.3. Tuning auditd pour serveurs sous charge

Le fichier /etc/audit/auditd.conf contrôle le comportement du démon. Les paramètres par défaut sont adaptés à un poste de travail, pas à un serveur Internet. Voici une configuration éprouvée pour un serveur applicatif moyen (10-100 req/s) :

# /etc/audit/auditd.conf — production hardened

log_file = /var/log/audit/audit.log
log_format = ENRICHED          # Plus lisible que RAW
flush = INCREMENTAL_ASYNC      # Performance : pas fsync à chaque event
freq = 50                      # Sync tous les 50 events

max_log_file = 50              # Mo par fichier
num_logs = 5                   # Garder 5 fichiers (250 Mo total)
max_log_file_action = ROTATE
space_left = 200               # Mo restants avant alerte
space_left_action = ROTATE     # Rotation auto si plein
admin_space_left = 50
admin_space_left_action = SUSPEND  # Stoppe audit si /var saturé

disp_qos = lossy               # Préfère perdre que bloquer kernel
name_format = HOSTNAME         # Préfixe hostname dans logs

Sur un serveur très actif (1000+ req/s), passer flush=NONE et compter sur le fsync filesystem périodique. Le risque est de perdre 0 à 30 secondes d'événements en cas de crash kernel — acceptable pour un audit, inacceptable pour de la transaction.

10.4. Centralisation des logs : l'étape qui change tout

Garder les logs localement sur la machine auditée est un anti-pattern : un attaquant root peut tronquer ou effacer. Trois approches éprouvées :

1. rsyslog forwarder vers serveur centralisé : ajouter dans /etc/rsyslog.d/50-audit.conf :

   module(load="imfile")
   input(type="imfile" File="/var/log/audit/audit.log" Tag="auditd")
   input(type="imfile" File="/var/log/account/pacct" Tag="acct")
   *.* @@logserver.internal:514;RSYSLOG_SyslogProtocol23Format

2. Loki + Promtail : stack moderne (cf. section 11), recherche LogQL temps réel, intégration Grafana native.
3. Audit dispatcher (auditd → audisp-remote) : transfert TCP TLS chiffré du flux audit vers un collecteur central, avec gestion file d'attente disque locale en cas de coupure réseau.

10.5. Intégrité externe : LUKS, append-only, hashing

Pour résister à un attaquant qui obtient root, il faut sortir l'intégrité hors du serveur. Trois techniques cumulables :

• chattr +a sur les fichiers de log critiques : seul l'ajout est autorisé, pas la modification ni la suppression. Même root doit retirer l'attribut explicitement (et l'opération est tracée par auditd).
• Hashing périodique externe : un cron sur un serveur tiers calcule SHA256 des logs via SSH read-only et stocke dans une base append-only. Toute incohérence = alerte.
• LUKS + chiffrement asymétrique : exporter les logs dans un volume LUKS dont seule la clé publique est connue côté serveur audité. Décompression possible uniquement côté SOC.

10.6. Le rituel post-incident : ce qu'il faut faire quand un signal remonte

Quand l'un des cinq outils déclenche une alerte, la tentation naturelle est de regarder le log et prendre une décision. C'est exactement la mauvaise approche. Le réflexe correct, qui distingue une équipe sécurité mûre d'une équipe débutante, suit cette séquence :

1. Geler l'état avant d'investiguer : snapshot disque (LVM, ZFS, ou simple dd) et capture mémoire (LiME, AVML). Tout investigation modifie inévitablement le système.
2. Corréler les cinq sources avant de conclure : un warning rkhunter seul peut être un faux positif, le même warning corroboré par un événement auditd et une trace acct devient une certitude.
3. Documenter l'IOC (Indicator of Compromise) : hash du fichier suspect, IP source, timestamp, utilisateur. Format STIX/TAXII si possible, pour partage avec MISP, CERT-FR ou CTI partenaires.
4. Décider en 30 minutes : isoler ou observer. L'isolement coupe l'attaquant mais alerte sa présence ; l'observation permet de cartographier ses cibles mais prolonge l'exposition.
5. Reconstruction systématique en cas de rootkit kernel-mode : aucune désinfection en place ne peut être garantie sur un LKM rootkit. Image dorée + restauration des données + rotation de tous les secrets.

Cette discipline est précisément ce que documente la norme NIST SP 800-61 Rev. 3 (Computer Security Incident Handling Guide). Sans cette méthodologie, même une stack d'audit parfaite ne sert à rien.

11. Pour aller plus loin : l'écosystème étendu

La stack en 5 outils est la base. Pour des environnements plus exigeants — fermes de containers, multi-cloud, conformité critique — il existe un écosystème open source riche qui complète ou remplace certaines briques. Cette section présente cinq outils qu'un RSSI moderne doit avoir entendu nommer.

11.1. AIDE — l'héritier de Tripwire

AIDE (Advanced Intrusion Detection Environment) est un HIDS file integrity monitoring qui va bien plus loin que debsums. Là où debsums ne couvre que les fichiers issus de paquets Debian, AIDE construit une base de hashes de l'arborescence entière que vous configurez : binaires custom dans /opt, scripts dans /usr/local/bin, fichiers de config applicatifs dans /srv.

Critère	debsums	AIDE
Périmètre	Paquets Debian/RPM uniquement	Arborescence libre, configurable
Algorithmes	MD5	SHA256, SHA512, Whirlpool, Blake2
Configuration	Aucune	Fichier aide.conf avec règles regex
Base de référence	Données paquet	Snapshot initial à exporter offline
Vitesse scan complet	~30 s	~5-15 min selon volume

Sur un serveur en production, on utilise les deux : debsums en quotidien (rapide, large couverture paquets), AIDE en hebdomadaire (plus profond, mais long). La base AIDE doit être stockée hors serveur (clé USB, S3 immuable) pour résister à un attaquant qui aurait root.

11.2. Wazuh — l'agrégation SIEM/XDR

Wazuh est un fork moderne d'OSSEC, devenu une plateforme XDR open source complète. Il agrège nativement les logs auditd, rkhunter, lynis via des décodeurs intégrés, et propose des règles de corrélation puissantes. Notre article Wazuh, plateforme XDR/SIEM open source détaille l'architecture (manager + agents + indexer + dashboard). Pour un parc de plus de 10 serveurs, Wazuh est la suite logique de la stack auditd+lynis+rkhunter.

11.3. Falco — runtime kernel pour containers

Falco (projet CNCF gradué) est l'équivalent moderne d'auditd conçu pour les environnements containerisés. Il hooke le kernel via eBPF (ou un driver kernel-mode), parse les syscalls en temps réel et applique des règles YAML. Là où auditd est statique et fichier-centré, Falco est dynamique, container-aware (PID namespaces, cgroups) et orienté Kubernetes. Voir notre article dédié Falco, détection runtime cloud-native CNCF et notre dossier Kubernetes orchestrateur.

11.4. CrowdSec — la réponse active basée sur logs

CrowdSec est un projet français (open source) qui parse les logs (auditd, nginx, ssh, fail2ban...) en temps réel, détecte les comportements malveillants, et déclenche des bouncers (firewall, nginx, cloudflare). Sa force : une blocklist communautaire mutualisée. Quand un de vos serveurs détecte une IP attaquante, l'ensemble du réseau CrowdSec en bénéficie. C'est l'évolution de fail2ban à l'échelle mondiale.

11.5. Loki + Promtail + Grafana — la stack moderne de centralisation

Loki est un système d'agrégation de logs conçu par Grafana Labs, pensé comme « Prometheus mais pour les logs ». Ultra-léger (indexation par labels seulement, pas full-text), il digère sans broncher des millions de lignes auditd par jour. Promtail est l'agent collecteur, Grafana fournit le dashboard et l'alerting. C'est aujourd'hui le choix par défaut pour qui ne veut pas la lourdeur d'Elastic Stack.

11.6. eBPF — l'avenir au-delà d'auditd

eBPF (extended Berkeley Packet Filter) est une révolution kernel Linux qui permet d'exécuter des programmes vérifiés directement dans le noyau, sans module externe. Des outils comme Tetragon (Isovalent), Tracee (Aqua Security) ou BCC tools exploitent eBPF pour faire ce que auditd fait, mais avec 10x moins d'overhead et une granularité fine. Sur un serveur à fort trafic, migrer vers une stack eBPF (Tetragon en remplacement de auditd) divise par 5 la consommation CPU dédiée à l'observabilité.

L'enjeu eBPF dépasse la simple performance. La vraie révolution est la cohérence cross-kernel : un programme eBPF compile une fois, tourne sur tous les noyaux Linux modernes (5.4+), avec une vérification statique du noyau qui garantit l'absence de boucles infinies ou de débordements. Là où auditd dépend de structures kernel parfois changeantes, eBPF présente une API stable garantie par Linus Torvalds lui-même. Pour un parc hétérogène (Debian 11, Ubuntu 22, RHEL 9, Fedora 40), cette stabilité simplifie radicalement le déploiement.

Notre recommandation pratique en 2026 : conserver la stack 5 outils sur les serveurs traditionnels (legacy, OS < Linux 5.4) et migrer progressivement vers Tetragon ou Falco-eBPF sur les workloads modernes (Kubernetes, fermes Docker, infra cloud-native). La transition est non disruptive : Tetragon coexiste très bien avec auditd pendant la phase de migration.

11.7. Tableau comparatif synthétique

Outil	Open source	Performance	Complexité	Dashboard	Alerting	Communauté
AIDE	Oui (GPL)	Lent au scan	Moyenne	Aucun	Email	Stable
Wazuh	Oui (GPLv2)	Bonne	Élevée	Kibana intégré	Riche	Très active
Falco	Oui (Apache 2)	Excellente (eBPF)	Moyenne	Falcosidekick UI	Webhook, slack	CNCF graduated
CrowdSec	Oui (MIT)	Bonne	Faible	Console SaaS	Bouncer auto	FR, croissante
Loki	Oui (AGPLv3)	Excellente	Moyenne	Grafana	Alertmanager	Très active

12. Conclusion, FAQ et points clés à retenir

12.1. Conclusion : témoins, pas gardes du corps

Cinq outils. Trois cents méga-octets de logs par mois. Zéro licence à payer. Une heure d'installation initiale, vingt minutes de maintenance par mois. Voilà ce que représente concrètement la stack auditd + lynis + rkhunter + debsums + acct sur un serveur Linux moyen. Le ROI est immédiat : la première fois qu'un développeur modifie un fichier critique par erreur, la première fois qu'un compte compromis tente une élévation de privilèges, la première fois qu'un binaire est trojanisé — vous le saurez en moins de 24 heures.

Cette équation est rare en sécurité informatique. La plupart des outils efficaces coûtent cher (EDR commercial à 100€/serveur/mois), demandent une expertise rare (SIEM, SOC managé) ou impactent fortement les performances (chiffrement complet du disque, sandbox systématique). La stack présentée ici fait exception : elle est à la fois gratuite, légère, mature et conforme. Sa seule exigence est la discipline de la maintenance — rien que vous ne pratiquiez déjà sur vos sauvegardes ou vos certificats SSL.

Mais surtout, gardez en tête le principe directeur de cet article : ces outils sont des témoins, pas des gardes du corps. Ils ne stoppent pas l'attaque, ils la racontent. Ils ne ferment pas la porte, ils filment ceux qui passent. Cette distinction est fondamentale pour calibrer ses attentes. Si vous cherchez un système qui bloque automatiquement, regardez du côté de CrowdSec, fail2ban, ModSecurity ou d'un EDR commercial. Si vous cherchez un système qui vous donne la vérité opposable en cas d'incident, vous êtes au bon endroit. Et c'est précisément cette vérité que les normes ISO 27001, PCI-DSS, HDS et NIS2 exigent — pas le blocage, mais la traçabilité.

Notre cabinet déploie cette stack sur tous les serveurs Linux que nous auditons, avant même les mesures de durcissement complémentaires. Parce qu'on n'améliore que ce que l'on mesure, et qu'on ne sécurise que ce que l'on observe. En 2024, nous avons accompagné 47 PME et ETI françaises dans le déploiement et la maintenance de cette stack — toutes ont vu leur score lynis progresser d'au moins 15 points en six mois, et trois d'entre elles ont identifié grâce à auditd + acct des compromissions latentes datant de plusieurs mois, qui auraient été manquées sans cette télémétrie.

La leçon générale qui se dégage de ces déploiements est simple et contre-intuitive : la valeur ne vient pas de la sophistication des outils, mais de la rigueur de leur exploitation. Une stack basique, bien configurée et bien revue, surpasse systématiquement une plateforme XDR coûteuse mais mal intégrée à l'organisation. La technique compte pour 30 %, l'humain et le processus pour 70 %.

12.2. FAQ

Faut-il vraiment installer les 5 outils sur tous les serveurs ?

Pour la majorité des serveurs Linux exposés à Internet ou hébergeant des données sensibles, oui. L'empreinte cumulée est inférieure à 2 % de CPU et 500 Mo de stockage mensuel. Sur des serveurs très spécialisés (HPC, bases temps réel à très faible latence), on peut débrayer auditd ou ne conserver que acct+lynis+debsums. Mais ces cas sont rares. Le coût d'omettre un outil dépasse largement son coût de fonctionnement.

Combien de stockage prévoir pour les logs sur un an ?

Pour un serveur applicatif moyen (50-100 req/s, 5-10 utilisateurs admin) : auditd 200-400 Mo/mois, acct 30-50 Mo/mois, rkhunter 20 Mo/mois, lynis 10 Mo/mois, debsums négligeable. Soit environ 3-5 Go/an localement. Si vous centralisez via Loki avec compression, comptez 1-2 Go/an stocké en SIEM. Pour un serveur très actif (build farm, CI/CD), multipliez par 5 à 10. Prévoyez toujours une partition /var/log dédiée d'au moins 10 Go.

Cette stack est-elle compatible avec des containers Docker ?

Partiellement. auditd et acct tournent sur l'hôte et voient tous les processus de tous les containers (PID host) — donc utiles pour surveiller le runtime. En revanche, rkhunter, lynis et debsums sont conçus pour des systèmes packagés et n'ont pas de sens dans des containers immuables. Pour les containers, préférez Falco en remplacement d'auditd, et l'analyse d'images via Trivy ou Grype en remplacement de debsums/rkhunter.

Comment gérer les serveurs immutables (Fedora CoreOS, atomic) ?

Sur un OS immutable, debsums et rkhunter perdent beaucoup d'utilité (le filesystem racine est en lecture seule, l'altération est structurellement empêchée). En revanche, auditd et acct restent essentiels pour observer l'activité dans /var et les containers. lynis reste pertinent pour vérifier la configuration applicative dans /etc. La stack se réduit à 3 outils : auditd + acct + lynis. À combiner impérativement avec un scanner d'images type Trivy.

Cette stack remplace-t-elle un EDR commercial type CrowdStrike ou SentinelOne ?

Non, et ce n'est pas son but. Un EDR commercial fait du blocage temps réel basé sur du machine learning et des signatures propriétaires, plus une threat intelligence mondiale. La stack 5 outils fait de la traçabilité et détection. Les deux sont complémentaires, pas substituables. Cela dit, sur des serveurs où le coût d'un EDR (~50-200€/serveur/mois) n'est pas justifiable, la stack 5 outils + Wazuh + CrowdSec offre 80 % de la valeur pour 0 % du coût.

Est-elle suffisante pour une conformité ISO 27001 ou PCI-DSS ?

Pour ISO 27001 (contrôles A.12.4 logging et monitoring), la stack répond directement aux exigences A.12.4.1, A.12.4.3 et A.12.4.4 sous réserve de centralisation des logs et de procédures de revue documentées. Pour PCI-DSS v4.0, elle couvre les exigences 10.2.1 à 10.2.7 (audit logs détaillés) et 11.5.2 (file integrity monitoring) à condition d'ajouter AIDE pour la couverture FIM complète des chemins non packagés. Un auditeur QSA acceptera la stack comme preuve si elle est documentée, centralisée et revue mensuellement. Voir notre offre audit infrastructure pour un accompagnement à la conformité.

Comment alerter en temps réel au lieu d'attendre la revue manuelle ?

Trois options selon votre maturité. Niveau 1 (le plus simple) : auditd peut écrire dans syslog, qui peut router vers rsyslog, qui peut déclencher une commande sur match regex (:msg, contains, "key=shadow-write" → script email). Niveau 2 : audisp-prelude ou audisp-syslog avec un parseur logstash qui pousse dans Elasticsearch, alerting via Watcher ou ElastAlert. Niveau 3 (recommandé) : Wazuh agent sur le serveur, qui ingère nativement auditd/rkhunter/lynis, applique des règles de corrélation et déclenche dans Slack/PagerDuty/email avec déduplication. Le passage du niveau 1 au niveau 3 prend une journée de configuration et change radicalement la qualité du SOC.

Cette stack fonctionne-t-elle sur un Raspberry Pi ou un serveur ARM ?

Oui, sans modification. auditd, acct, lynis, rkhunter et debsums sont tous présents en architecture ARM dans les dépôts Debian/Raspberry Pi OS et Ubuntu. La consommation CPU est plus visible sur un Pi 4 (~3-5 % au lieu de 1-2 % sur x86), mais reste acceptable. Pour un objet IoT en production (passerelle domotique, NAS perso), c'est même plus important que sur un serveur datacenter, car ces appareils sont rarement supervisés et constituent des vecteurs d'attaque privilégiés.

12.3. À retenir — 7 points clés