Que fait Analyse des Journaux d'Audit Linux pour les Intrusions ?
Quand l'Utiliser
- Enquêter sur des suspicions d'accès non autorisé ou d'escalade de privilèges sur des hôtes Linux
- Rechercher des preuves d'exploitation, d'installation de porte dérobée ou de mécanismes de persistance
- Auditer la conformité avec les bases de sécurité (CIS, STIG, PCI-DSS) qui exigent la surveillance des appels système
- Reconstituer une chronologie des actions d'un attaquant lors d'une réponse à incident
- Détecter la falsification de fichiers système critiques comme
/etc/passwd,/etc/shadowou les clés SSH
Ne pas utiliser pour la détection d'intrusion au niveau réseau ; utilisez Suricata ou Zeek pour l'analyse du trafic réseau. Auditd opère au niveau du noyau sur des hôtes individuels.
Prérequis
- Système Linux avec le paquet
auditdinstallé et le démon d'audit en cours d'exécution (systemctl status auditd) - Accès root ou sudo pour configurer les règles d'audit et interroger les journaux
- Règles d'audit déployées via
/etc/audit/rules.d/*.rulesou chargées avecauditctl - Recommandé : le jeu de règles Neo23x0/auditd de GitHub pour une couverture de base complète
- Familiarité avec les appels système Linux (
execve,open,connect,ptrace, etc.) - Stockage des journaux avec une rétention suffisante (emplacement par défaut :
/var/log/audit/audit.log)
Workflow
Étape 1 : Vérifier l'État et la Configuration du Démon d'Audit
Confirmer que le système d'audit est en cours d'exécution et vérifier l'ensemble des règles actuelles :
# Vérifier l'état du service auditd
systemctl status auditd
# Afficher les règles d'audit actuellement chargées dans le noyau
auditctl -l
# Afficher la configuration du démon d'audit
cat /etc/audit/auditd.conf | grep -E "log_file|max_log_file|num_logs|space_left_action"
# Vérifier si le backlog d'audit est dépassé (événements perdus)
auditctl -s
Si la limite du backlog est atteinte, l'augmenter :
auditctl -b 8192
Étape 2 : Déployer des Règles d'Audit Axées sur les Intrusions
Ajouter des règles ciblant les indicateurs d'intrusion courants. Placer ces règles dans /etc/audit/rules.d/intrusion.rules :
# Surveiller les fichiers d'identifiants pour les lectures ou modifications non autorisées
-w /etc/passwd -p wa -k credential_access
-w /etc/shadow -p rwa -k credential_access
-w /etc/gshadow -p rwa -k credential_access
-w /etc/sudoers -p wa -k privilege_escalation
-w /etc/sudoers.d/ -p wa -k privilege_escalation
# Surveiller la configuration SSH et les clés autorisées
-w /etc/ssh/sshd_config -p wa -k sshd_config_change
-w /root/.ssh/authorized_keys -p wa -k ssh_key_tampering
# Surveiller les commandes de gestion des utilisateurs et des groupes
-w /usr/sbin/useradd -p x -k user_management
-w /usr/sbin/usermod -p x -k user_management
-w /usr/sbin/groupadd -p x -k user_management
# Détecter l'injection de processus via ptrace
-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -k process_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x5 -k process_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x6 -k process_injection
# Surveiller l'exécution de programmes depuis des répertoires inhabituels
-a always,exit -F arch=b64 -S execve -F exe=/tmp -k exec_from_tmp
-a always,exit -F arch=b64 -S execve -F exe=/dev/shm -k exec_from_shm
# Détecter le chargement de modules noyau (installation de rootkit)
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_module_load
-a always,exit -F arch=b64 -S delete_module -k kernel_module_remove
-w /sbin/insmod -p x -k kernel_module_tool
-w /sbin/modprobe -p x -k kernel_module_tool
# Surveiller la création de sockets réseau pour les reverse shells
-a always,exit -F arch=b64 -S socket -F a0=2 -k network_socket_created
-a always,exit -F arch=b64 -S connect -F a0=2 -k network_connection
# Détecter les modifications de cron (persistance)
-w /etc/crontab -p wa -k cron_persistence
-w /etc/cron.d/ -p wa -k cron_persistence
-w /var/spool/cron/ -p wa -k cron_persistence
# Surveiller la suppression ou la falsification des journaux
-w /var/log/ -p wa -k log_tampering
Recharger les règles après édition :
augenrules --load
auditctl -l | wc -l # Confirmer le nombre de règles
Étape 3 : Rechercher des Indicateurs d'Intrusion avec ausearch
Utiliser ausearch pour interroger le journal d'audit pour des événements spécifiques :
# Rechercher toutes les tentatives de connexion échouées au cours des dernières 24 heures
ausearch -m USER_LOGIN --success no -ts recent
# Rechercher les commandes exécutées par un utilisateur spécifique
ausearch -ua 1001 -m EXECVE -ts today
# Rechercher tous les événements d'accès au fichier sur /etc/shadow
ausearch -f /etc/shadow -ts this-week
# Rechercher l'escalade de privilèges via sudo
ausearch -m USER_CMD -ts today
# Rechercher les événements de chargement de modules noyau
ausearch -k kernel_module_load -ts this-month
# Rechercher les processus exécutés depuis /tmp (étape d'attaque courante)
ausearch -k exec_from_tmp -ts this-week
# Rechercher les modifications des clés SSH
ausearch -k ssh_key_tampering -ts this-month
# Rechercher un événement spécifique par son ID d'événement d'audit
ausearch -a 12345
# Rechercher des événements dans une plage horaire spécifique
ausearch -ts 03/15/2026 08:00:00 -te 03/15/2026 18:00:00
# Interpréter les numéros d'appels système et formater la sortie lisiblement
ausearch -k credential_access -i -ts today
Étape 4 : Générer des Rapports Récapitulatifs avec aureport
Utiliser aureport pour produire des résumés agrégés pour le triage :
# Résumé de tous les événements d'authentification
aureport -au -ts this-week --summary
# Rapport de tous les événements échoués (connexion, accès, etc.)
aureport --failed --summary -ts today
# Rapport des exécutions
aureport -x --summary -ts today
# Rapport de tous les événements anormaux (segfaults, mode promiscuité, etc.)
aureport --anomaly -ts this-week
# Rapport des événements d'accès aux fichiers
aureport -f --summary -ts today
# Rapport de tous les événements par clé (correspond à vos clés de règles personnalisées)
aureport -k --summary -ts this-month
# Rapport de tous les appels système
aureport -s --summary -ts today
# Rapport des événements groupés par utilisateur
aureport -u --summary -ts this-week
# Rapport détaillé basé sur le temps pour la construction de la chronologie
aureport -ts 03/15/2026 08:00:00 -te 03/15/2026 18:00:00 --summary
Étape 5 : Reconstituer la Chronologie de l'Attaque
Combiner les requêtes ausearch pour construire un récit chronologique :
# Étape 5a : Identifier l'horodatage de l'accès initial
ausearch -m USER_LOGIN -ua 0 --success yes -ts this-week -i | head -50
# Étape 5b : Tracer ce que l'attaquant a fait après avoir obtenu l'accès
# Obtenir tous les événements du compte compromis dans la fenêtre d'incident
ausearch -ua <UID> -ts "03/15/2026 14:00:00" -te "03/15/2026 18:00:00" -i \
| aureport -f -i
# Étape 5c : Extraire toutes les commandes exécutées pendant la fenêtre d'incident
ausearch -m EXECVE -ts "03/15/2026 14:00:00" -te "03/15/2026 18:00:00" -i
# Étape 5d : Vérifier l'installation de mécanismes de persistance
ausearch -k cron_persistence -ts "03/15/2026 14:00:00" -i
ausearch -k ssh_key_tampering -ts "03/15/2026 14:00:00" -i
# Étape 5e : Vérifier les mouvements latéraux (connexions sortantes)
ausearch -k network_connection -ts "03/15/2026 14:00:00" -i
Étape 6 : Transférer les Journaux d'Audit vers un SIEM
Configurer audisp-remote ou auditbeat pour expédier les journaux vers un SIEM central pour corrélation :
# Option A : Utilisation du plugin audisp-remote
# Editer /etc/audit/plugins.d/au-remote.conf
active = yes
direction = out
path = /sbin/audisp-remote
type = always
# Configurer la cible distante dans /etc/audit/audisp-remote.conf
remote_server = siem.internal.corp
port = 6514
transport = tcp
# Option B : Utilisation d'Elastic Auditbeat
# Installer auditbeat et configurer /etc/auditbeat/auditbeat.yml
# Auditbeat lit directement depuis le framework d'audit du noyau
Concepts Clés
| Terme | Définition |
|---|---|
| auditd | Le démon d'audit Linux qui reçoit les événements d'audit du noyau et les écrit dans /var/log/audit/audit.log |
| auditctl | Utilitaire en ligne de commande pour contrôler le système d'audit : ajouter/supprimer des règles, vérifier l'état, définir la taille du backlog |
| ausearch | Outil de requête qui recherche dans les journaux d'audit par type de message, utilisateur, fichier, clé, plage horaire ou ID d'événement |
| aureport | Outil de rapport qui génère des résumés agrégés des événements d'audit pour le triage et la conformité |
| clé de règle d'audit (-k) | Un libellé défini par l'utilisateur attaché à une règle d'audit, permettant un filtrage rapide des événements associés avec ausearch et aureport |
| audit des appels système | Surveillance au niveau du noyau des appels système (execve, open, connect, ptrace) qui capture l'activité des processus et des fichiers |
| augenrules | Utilitaire qui fusionne tous les fichiers de /etc/audit/rules.d/ dans /etc/audit/audit.rules et les charge dans le noyau |
Vérification
- auditd est en cours d'exécution et les règles sont chargées (
auditctl -lretourne le nombre de règles attendu) - Pas de débordement du backlog d'audit (
auditctl -smontrebacklog: 0ou une valeur basse, lost: 0) - ausearch retourne des événements pour chaque clé personnalisée (
ausearch -k <key> -ts todayretourne des résultats) - aureport génère des résumés non vides pour les événements d'authentification, d'exécution et de fichiers
- La reconstruction de la chronologie produit une séquence chronologique cohérente des actions de l'attaquant
- Les surveillances de fichiers critiques déclenchent des alertes lors de modifications de test (
touch /etc/shadowgénère un événement) - Les journaux sont transférés vers le SIEM central (vérifier avec un événement de test et confirmer la réception)
- Les règles d'audit persistent après redémarrage (règles dans
/etc/audit/rules.d/, pas uniquement viaauditctl)