Introduction
L’auditing est un mécanisme de journalisation d’événements système. Il est essentiellement utilisé dans un contexte de sécurité ou de contrôle du respect d’une réglementation.
Son but est la surveillance des appels système, des accès aux fichiers sensibles, et il peut être interfacé avec des SIEM (Security Information and Event Management). On l’utilise généralement pour surveiller des systèmes de façon préventive afin de détecter des tentatives d’intrusion ou prévenir des actes de malveillance, mais aussi à posteriori pour analyser finement les compromissions qui ont pu avoir lieu, grâce à des enregistrements d’événements permettant de savoir qui a fait quoi, et quand.
Cependant, il ne protège pas les systèmes de façon active contrairement à des logiciels comme SELinux, Apparmor, iptables, fail2ban, etc.
Bien que l’on puisse l’utiliser, avec des outils appropriés, pour analyser des applications multi-processus fortement consommatrices de temps CPU, comme par exemple BitBake (de Yocto), l’auditing n’est pas initialement conçu pour analyser les performances des applications dans un but d’optimisation. Il est différent du profiling, qui, lui, permet la collecte d’informations servant à l’optimisation de programmes ou processus en détectant par exemple des sur-consommations de temps CPU ou des appels de fonctions très nombreux, parfois trop nombreux, voire inutiles.
Leurs domaines d’utilisation sont donc différents et ils ne doivent pas être confondus :
- l’auditing est lié à la sécurité, la traçabilité et la conformité,
- le profiling est lié à l’analyse de la performance et à l’optimisation.
1. Principe de fonctionnement
L'auditing Linux permet, grâce à l'interception des appels systèmes, de collecter des événements correspondant à une politique de sécurité définie dans les règles de sécurité du système. Ces événements sont stockés dans des fichiers de logs ASCII (dans lesquels les événements sont séparés par le code ASCII GS), et peuvent ensuite être consultés et analysés à des fins diverses.
La configuration de l'audit est définie dans un fichier servant à spécifier les paramètres du démon d'audit, et dans d'autres fichiers servant à définir les règles d'audit.
Plusieurs commandes permettent d'extraire de l'information de ces fichiers de logs, selon différents critères comme, par exemple, les dates et tranches horaires ou les types d'événements. D'autres permettent d'extraire des informations relatives aux connexions des utilisateurs.
2. Les logiciels utilisés
Le système d’audit de Linux utilise le sous-système d'audit du noyau, capable d'intercepter les appels systèmes et d'identifier leurs paramètres puis de générer des événements, et des applications s’exécutant dans l’espace utilisateur, dont les fonctions sont de configurer le système d’audit ou de gérer le stockage et l’extraction d’événements.
Le principal programme s’exécutant dans l’espace utilisateur et impliqué dans l’audit est le démon (daemon) auditd. Celui-ci communique avec le système d’audit du noyau grâce à une interface Netlink.
Peu après son lancement, auditd s’abonne à la socket NETLINK_AUDIT, puis se met en attente de réception d’événements en provenance du noyau. Lorsqu’un message arrive, il peut le stocker dans un fichier de logs, le transmettre à un plug-in ou l’envoyer à un serveur distant, selon sa configuration. Il peut également modifier des règles d’audit, notamment dans le cas où il est associé à un plug-in.
On notera que dans des versions un peu anciennes de l'audit, le démon auditd communiquait avec un processus nommé audispd (pour "dispatcher") qui avait la charge de ventiler les événements vers des plug-ins ou des fichiers de logs. Ce programme a été fusionné avec auditd dans la version 3.0.0 et a maintenant disparu : c'est dorénavant auditd qui écrit dans les fichiers de logs.
Un autre programme essentiel est auditctl, qui offre la possibilité de manipuler dynamiquement les règles d’audit en communiquant directement avec le noyau via l’interface Netlink.
Les autres commandes disponibles sont les suivantes :
ausearch
Effectue des recherches d’informations dans les logs, selon de multiples critères.aureport
Génère des rapports statistiques.augenrules
Shell script qui effectue un traitement des fichiers de règles contenus dans le répertoire /etc/audit/rules.d pour produire le fichier /etc/audit/audit.rules.aulast
Affiche l’historique des connexions et déconnexions des utilisateurs à partir des logs d’audit. Fonctionne comme la commande last, mais utilise les données auditées par auditd.aulastlog
Affiche la dernière connexion des utilisateurs.
Fonctionne comme la commande lastlog, mais utilise les logs d’audit au lieu du fichier /var/log/lastlog.autrace
Permet de tracer l’exécution d’un programme (comme strace) en ajoutant automatiquement des règles d’audit pour suivre les appels système effectués par le programme tracé, qu’il lance avec les arguments spécifiés. Les événements collectés peuvent ensuite être analysés à l’aide de ausearch ou aureport. Il est utile pour diagnostiquer ou auditer en détail les comportements d’un binaire.ausyscall
Donne la correspondance entre le nom des appels système (syscalls) et leur numéro en fonction de l’architecture du système (par exemple x86_64, i386, , etc.).
Permet de s’assurer que des directives dans lesquelles l’architecture n’a pas été spécifiée couvriront les architectures ciblées, ou, dans le cas contraire, permettra d’identifier les règles pour lesquelles il sera nécessaire de spécifier explicitement l’architecture. Voir la page de manuel pour un exemple.auvirt
Affiche les données d’audit relatives aux machines virtuelles.
3. Installation
Le système d’audit Linux est installé sous Debian à l’aide de la commande suivante, sous root :
# apt install auditdou, à partir d’un compte utilisateur autorisé :
$ sudo apt install auditdLa visualisation des packages liés à l'auditing est effectuée classiquement avec la commande dpkg :
# dpkg -l | grep audit
ii auditd 1:3.0.9-1 amd64 User space tools for security auditing
ii libaudit-common 1:3.0.9-1 all Dynamic library for security auditing - common files
ii libaudit1:amd64 1:3.0.9-1 amd64 Dynamic library for security auditing
ii libauparse0:amd64 1:3.0.9-1 amd64 Dynamic library for parsing security auditing4. Activation, désactivation, statut de l’audit
Le système d'audit doit être actif pour pouvoir effectuer une collecte d'événements.
Sous Debian, il est démarré à l'aide de la commande :
$ sudo systemctl start auditdSi l'on veut qu'il soit démarré au lancement du système, il doit être activé de la façon suivante :
$ sudo systemctl enable auditdRemarque : afin d'alléger leur écriture, nous omettrons la commande sudo dans les commandes ultérieures.
L'audit peut être arrêté à l'aide de la commande :
# systemctl stop auditdet désactivé avec :
# systemctl disable auditdSon état peut être contrôlé avec la commande :
# systemctl status auditdet son état d'activité peut être affiché à l'aide de la commande :
# auditctl -squi affichera des informations telles que :
enabled 1
failure 1
pid 747
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
backlog_wait_time 60000
backlog_wait_time_actual 0
loginuid_immutable 0 unlockedLa valeur qui suit le mot-clé "enabled" indique le statut : 0 = désactivé, 1 = activé.
Il est possible de suspendre temporairement l'auditing à l'aide de la commande :
# auditctl -e 0et de le relancer avec :
# auditctl -e 1La configuration peut être verrouillée à l'aide de la commande :
# auditctl -e 2Cette commande empêche toute modification ultérieure de la configuration de l'auditing jusqu'au prochain reboot. Si le verrouillage est demandé dans la configuration, il doit évidemment figurer en dernière instruction du fichier de règles.
Si l'on souhaite l'activation de l'audit dès le démarrage du noyau, il faut ajouter la chaîne :
audit=1dans la configuration grub spécifiant les paramètres de boot du noyau.
Lorsque l'audit est installé et actif, on peut observer des processus supplémentaires sur la machine :
1 S root 40 2 0 80 0 - 0 kaudit 15:26 ? 00:00:00 [kauditd] 5 S root 543 1 0 76 -4 - 3282 do_sel 15:26 ? 00:00:00 /sbin/auditd
5. Configuration
5.1. Configuration du démon auditd
Le fichier de configuration du démon auditd est /etc/audit/auditd.conf. Une version par défaut du fichier de configuration est créée lors de l’installation du package. L’administrateur du système peut ensuite l’éditer pour modifier manuellement la configuration. Sur Debian 12 (bookworm), la version par défaut contient ceci :
# # This file controls the configuration of the audit daemon # local_events = yes write_logs = yes log_file = /var/log/audit/audit.log log_group = adm log_format = ENRICHED flush = INCREMENTAL_ASYNC freq = 50 max_log_file = 8 num_logs = 5 priority_boost = 4 name_format = NONE ##name = mydomain max_log_file_action = ROTATE space_left = 75 space_left_action = SYSLOG verify_email = yes action_mail_acct = root admin_space_left = 50 admin_space_left_action = SUSPEND disk_full_action = SUSPEND disk_error_action = SUSPEND use_libwrap = yes ##tcp_listen_port = 60 tcp_listen_queue = 5 tcp_max_per_addr = 1 ##tcp_client_ports = 1024-65535 tcp_client_max_idle = 0 transport = TCP krb5_principal = auditd ##krb5_key_file = /etc/audit/audit.key distribute_network = no q_depth = 2000 overflow_action = SYSLOG max_restarts = 10 plugin_dir = /etc/audit/plugins.d end_of_event_timeout = 2
Nous ne décrirons que quelques paramètres dans cet article. Si vous cherchez une information particulière sur l'un d'entre eux, sachez qu'ils sont tous sont décrits dans la page de manuel auditd.conf(5).
Parmi les paramètres notables figurent :
- log_file :
sa valeur sert à spécifier le pathname du fichier de collecte des événements.
La valeur généralement utilisée pour le fichier de logs est /var/log/audit/audit.log, mais elle peut être modifiée à l'aide de ce paramètre.
- log_format :
accepte les valeurs RAW et ENRICHED. Le format RAW est celui dans lequel le noyau envoie les informations brutes. Le format ENRICHED est un format dans lequel les informations uid, gid, syscall, architecture, et adresse de socket sont interprétées et converties relativement au système local. Cela permet d'analyser plus facilement les logs, sachant que ces valeurs n'ont pas forcément la même signification d'un serveur à l'autre.
- priority_boost :
sa valeur, allant de 0 à 4, sert à indiquer le niveau d'augmentation de priorité à utiliser (priority boost), la valeur par défaut étant 0.
- flush :
les valeurs possibles de ce paramètre sont none, incremental, incremental_async, data, et sync :
- none : pas d'effort particulier pour faire un flush des enregistrements sur disque,
- incremental : dans ce cas, le paramètre freq est utilisé pour déterminer la fréquence des flushes sur disque,
- incremental_async : même signification que le paramètre incremental, mais le sync sur disque est fait de façon asynchrone,
- data : cette valeur demande que les données soient toujours synchronisées avec le disque, de façon prioritaire par rapport aux métadonnées (par utilisation de fdatasync() au lieu de fsync())
- action_mail_acct :
doit contenir une adresse e-mail ou un alias valide.
Il y a aussi un certain nombre de paramètres servant à dicter le comportement du démon en fonction de la place disque disponible (space_left, space_left_action, admin_space_left, etc.), de façon à anticiper une éventuelle saturation.
D'autres paramètres relatifs à la gestion des logs vont être décrits dans le paragraphe suivant.
5.2. Rotation des logs par auditd
auditd est capable d'effectuer une rotation des fichiers de logs mais il ne sait se baser que sur la taille des fichiers. Les paramètres utilisés sont :
- log_file : pathname du fichier de logs,
- max_log_file : taille maximum autorisée du fichier avant rotation, en Mo,
- num_logs : nombre maximum de fichiers de logs à garder après rotation,
- max_log_file_action : action à effectuer quand la taille max_log_file est atteinte, les actions
étant :
- ignore : ne rien faire,
- syslog : envoyer un avertissement (warning) à syslog,
- suspend : suspendre la journalisation,
- rotate : effectuer une rotation des fichiers de logs,
- keep_logs : similaire à rotate, mais ne tient pas compte de num_logs.
Les paramètres par défaut sous Debian 12 sont :
log_file = /var/log/audit/audit.log max_log_file = 8 num_logs = 5 max_log_file_action = ROTATE
5.3. Rotation des logs par logrotate
Si l'on souhaite effectuer une rotation des logs en fonction du temps plutôt qu'en fonction de la taille, on doit passer par un outil externe tel que logrotate, par exemple.
On pourra positionner les paramètres d'auditd de cette façon :
log_file = /var/log/audit/audit.log max_log_file_action = ignore
Peu importe la valeur des deux autres paramètres, elles seront ignorées.
Cette nouvelle configuration pourra être rechargée à l'aide de la commande :
# systemctl reload auditd
La configuration de logrotate (dans /etc/logrotate.d/auditd) pourra ressembler à la suivante, mais les commentaires devront être supprimés car ils peuvent poser problème pour certains des mots-clés :
/var/log/audit/audit.log {
daily # Rotation journalière des logs
rotate 30 # Conservation des 30 derniers fichiers
compress # Compression des anciens fichiers
delaycompress # Différer la compression jusqu'à la
# prochaine rotation
missingok # Pas d'erreur si le fichiers est absent
notifempty # Pas de rotation si fichier vide
create 0600 root root # Permissions pour les nouveaux fichiers
sharedscripts # Lancer 1 fois le script postrotate
postrotate
systemctl restart auditd > /dev/null 2>&1 || true
endscript
}
Elle peut être testée à l'aide de la commande :
# logrotate -f /etc/logrotate.d/auditd
5.4. Définition des règles d’audit
Les règles d’audit sont définies dans le fichier /etc/audit/audit.rules. Ce fichier est généralement généré automatiquement lors du boot du système par le lancement du script augenrules, qui utilise les fichiers situées dans le répertoire /etc/audit/rules.d et les concatène en respectant l’ordre de tri des noms de fichiers. Ces derniers doivent posséder l'extension .rules, faute de quoi ils seront ignorés par la commande. Le fait de répartir les règles sous forme d'un ensemble de fichiers permet une plus grande modularité et une plus grande facilité de gestion.
Les options -D (delete all rules), -b (backlog size), -f (failure mode) et -e (enabled flag), lorsqu’elles sont présentes dans les fichiers de configuration, ont toutefois une position fixe déterminée par le script : elles se trouvent respectivement en première, deuxième, troisième et dernière position dans le fichier produit (voir man page auditctl(8)).
Les règles du fichier /etc/audit/audit.rules sont lues par la commande auditctl au démarrage du système et chargées dans le noyau.
Voici quelques exemples de règles d'audit :
-a exit,always -F arch=b64 -S execve -a exit,always -F arch=b32 -S execve
Ces deux règles servent à indiquer au noyau que l'on souhaite tracer les exécutions de processus avec execve(), dans les modes 64 bits et 32 bits.
-a exit,always -F arch=b64 -S execve -k process_start -a exit,always -F arch=b32 -S execve -k process_start -a exit,always -F arch=b64 -S exit_group -k process_end -a exit,always -F arch=b32 -S exit_group -k process_end
Les règles précédentes servent à tracer les créations de processus (labellisées avec le texte process_start) et les fins de processus (labellisées avec le texte process_end).
-a exit,always -F arch=b64 -S openat2 -k file_access -a exit,always -F arch=b32 -S openat2 -k file_access
Cet exemple montre comment on peut demander à tracer les ouvertures de fichiers utilisant l'appel système openat2(), pour les architectures 64 bits et 32 bits.
Si maintenant nous voulons surveiller les permissions du fichier /etc/ssh/sshd_config, mais sans placer de directives de façon permanente dans les fichiers de règles, nous pouvons utiliser une commande telle que la suivante :
# auditctl -w /etc/ssh/sshd_config -p rwxa -k sshconfigchange
Ici, l'option -w permet de surveiller un pathname, et l'option -p définit les permissions qui déclencheront la génération d'un événement. L'argument qui suit l'option -k est une chaîne arbitraire qui permet de tracer des événements. Nous verrons dans le paragraphe 8 comment récupérer les logs relatifs aux potentiels événements générés par cette règle.
6. Les informations collectées
L'auditing collecte des événements comportant un grand nombre d'informations, parmi lesquelles figurent, de manière non exhaustive :
- le type d'événement,
- un timestamp avec date et heure,
- un numéro de séquence d'événement,
- les noms (réel, effectif, etc.) de l'utilisateur ayant effectué l'appel système,
- les noms (réel, effectif, etc.) des groupes de l'utilisateur ayant effectué l'appel système,
- le résultat de l'événement (succès ou échec : success=yes/no),
- l'ID du processus (PID),
- l'ID du processus parent (PPID),
- les capabilities du processus,
- le répertoire courant,
- le pathname,
- le numéro d'i-node,
- le numéro de device,
- une clé d'identification d'événement définie par l'administrateur,
- etc.
7. Types d’événements traités
Les événements d’audit gérés dans le code de l’auditing Linux sont données ci-après. Ils sont tirés du fichier audit-userspace/lib/audit-records.h disponible dans l’arborescence du code d’audit en espace utilisateur disponible sur github, et qui peut être récupéré par la commande :
$ git clone https://github.com/linux-audit/audit-userspace.git
Voici donc les événements disponibles (dont le préfixe AUDIT_ a été volontairement supprimé pour une meilleure lisibilité) :
FIRST_USER_MSG 1100 /* First user space message */
LAST_USER_MSG 1199 /* Last user space message */
USER_AUTH 1100 /* User system access authentication */
USER_ACCT 1101 /* User system access authorization */
USER_MGMT 1102 /* User acct attribute change */
CRED_ACQ 1103 /* User credential acquired */
CRED_DISP 1104 /* User credential disposed */
USER_START 1105 /* User session start */
USER_END 1106 /* User session end */
USER_AVC 1107 /* User space avc message */
USER_CHAUTHTOK 1108 /* User acct password or pin changed */
USER_ERR 1109 /* User acct state error */
CRED_REFR 1110 /* User credential refreshed */
USYS_CONFIG 1111 /* User space system config change */
USER_LOGIN 1112 /* User has logged in */
USER_LOGOUT 1113 /* User has logged out */
ADD_USER 1114 /* User account added */
DEL_USER 1115 /* User account deleted */
ADD_GROUP 1116 /* Group account added */
DEL_GROUP 1117 /* Group account deleted */
DAC_CHECK 1118 /* User space DAC check results */
CHGRP_ID 1119 /* User space group ID changed */
TEST 1120 /* Used for test success messages */
TRUSTED_APP 1121 /* Trusted app msg - freestyle text */
USER_SELINUX_ERR 1122 /* SE Linux user space error */
USER_CMD 1123 /* User shell command and args */
USER_TTY 1124 /* Non-ICANON TTY input meaning */
CHUSER_ID 1125 /* Changed user ID supplemental data */
GRP_AUTH 1126 /* Authentication for group password */
SYSTEM_BOOT 1127 /* System boot */
SYSTEM_SHUTDOWN 1128 /* System shutdown */
SYSTEM_RUNLEVEL 1129 /* System runlevel change */
SERVICE_START 1130 /* Service (daemon) start */
SERVICE_STOP 1131 /* Service (daemon) stop */
GRP_MGMT 1132 /* Group account attr was modified */
GRP_CHAUTHTOK 1133 /* Group acct password or pin changed */
MAC_CHECK 1134 /* User space MAC decision results */
ACCT_LOCK 1135 /* User's account locked by admin */
ACCT_UNLOCK 1136 /* User's account unlocked by admin */
USER_DEVICE 1137 /* User space hotplug device changes */
SOFTWARE_UPDATE 1138 /* Software update event */
FIRST_DAEMON 1200
LAST_DAEMON 1299
DAEMON_RECONFIG 1204 /* Auditd should reconfigure */
DAEMON_ROTATE 1205 /* Auditd should rotate logs */
DAEMON_RESUME 1206 /* Auditd should resume logging */
DAEMON_ACCEPT 1207 /* Auditd accepted remote connection */
DAEMON_CLOSE 1208 /* Auditd closed remote connection */
DAEMON_ERR 1209 /* Auditd internal error */
FIRST_EVENT 1300
LAST_EVENT 1399
FIRST_SELINUX 1400
LAST_SELINUX 1499
FIRST_APPARMOR 1500
LAST_APPARMOR 1599
AA 1500 /* Not upstream yet */
APPARMOR_AUDIT 1501
APPARMOR_ALLOWED 1502
APPARMOR_DENIED 1503
APPARMOR_HINT 1504
APPARMOR_STATUS 1505
APPARMOR_ERROR 1506
APPARMOR_KILL 1507
FIRST_KERN_CRYPTO_MSG 1600
LAST_KERN_CRYPTO_MSG 1699
FIRST_KERN_ANOM_MSG 1700
LAST_KERN_ANOM_MSG 1799
INTEGRITY_FIRST_MSG 1800
INTEGRITY_LAST_MSG 1899
INTEGRITY_DATA 1800 /* Data integrity verification */
INTEGRITY_METADATA 1801 // Metadata integrity verification
INTEGRITY_STATUS 1802 /* Integrity enable status */
INTEGRITY_HASH 1803 /* Integrity HASH type */
INTEGRITY_PCR 1804 /* PCR invalidation msgs */
INTEGRITY_RULE 1805 /* Policy rule */
INTEGRITY_EVM_XATTR 1806 /* New EVM-covered xattr */
INTEGRITY_POLICY_RULE 1807 /* Integrity Policy rule */
FIRST_ANOM_MSG 2100
LAST_ANOM_MSG 2199
ANOM_LOGIN_FAILURES 2100 // Failed login limit reached
ANOM_LOGIN_TIME 2101 // Login attempted at bad time
ANOM_LOGIN_SESSIONS 2102 // Max concurrent sessions reached
ANOM_LOGIN_ACCT 2103 // Login attempted to watched acct
ANOM_LOGIN_LOCATION 2104 // Login from forbidden location
ANOM_MAX_DAC 2105 // Max DAC failures reached
ANOM_MAX_MAC 2106 // Max MAC failures reached
ANOM_AMTU_FAIL 2107 // AMTU failure
ANOM_RBAC_FAIL 2108 // RBAC self test failure
ANOM_RBAC_INTEGRITY_FAIL 2109 // RBAC file integrity failure
ANOM_CRYPTO_FAIL 2110 // Crypto system test failure
ANOM_ACCESS_FS 2111 // Access of file or dir
ANOM_EXEC 2112 // Execution of file
ANOM_MK_EXEC 2113 // Make an executable
ANOM_ADD_ACCT 2114 // Adding an acct
ANOM_DEL_ACCT 2115 // Deleting an acct
ANOM_MOD_ACCT 2116 // Changing an acct
ANOM_ROOT_TRANS 2117 // User became root
ANOM_LOGIN_SERVICE 2118 // Service acct attempted login
ANOM_LOGIN_ROOT 2119 // Root login attempted
ANOM_ORIGIN_FAILURES 2120 // Origin has too many failed login
ANOM_SESSION 2121 // The user session is bad
FIRST_ANOM_RESP 2200
LAST_ANOM_RESP 2299
RESP_ANOMALY 2200 /* Anomaly not reacted to */
RESP_ALERT 2201 /* Alert email was sent */
RESP_KILL_PROC 2202 /* Kill program */
RESP_TERM_ACCESS 2203 /* Terminate session */
RESP_ACCT_REMOTE 2204 /* Acct locked from remote access*/
RESP_ACCT_LOCK_TIMED 2205 /* User acct locked for time */
RESP_ACCT_UNLOCK_TIMED 2206 /* User acct unlocked from time */
RESP_ACCT_LOCK 2207 /* User acct was locked */
RESP_TERM_LOCK 2208 /* Terminal was locked */
RESP_SEBOOL 2209 /* Set an SE Linux boolean */
RESP_EXEC 2210 /* Execute a script */
RESP_SINGLE 2211 /* Go to single user mode */
RESP_HALT 2212 /* take the system down */
RESP_ORIGIN_BLOCK 2213 /* Address blocked by iptables */
RESP_ORIGIN_BLOCK_TIMED 2214 /* Address blocked for time */
RESP_ORIGIN_UNBLOCK_TIMED 2215 /* Address unblocked from timed */
FIRST_USER_LSPP_MSG 2300
LAST_USER_LSPP_MSG 2399
USER_ROLE_CHANGE 2300 /* User changed to a new role */
ROLE_ASSIGN 2301 /* Admin assigned user to role */
ROLE_REMOVE 2302 /* Admin removed user from role */
LABEL_OVERRIDE 2303 /* Admin is overriding a label */
LABEL_LEVEL_CHANGE 2304 /* Object's level was changed */
USER_LABELED_EXPORT 2305 /* Object exported with label */
USER_UNLABELED_EXPORT 2306 /* Object exported without label */
DEV_ALLOC 2307 /* Device was allocated */
DEV_DEALLOC 2308 /* Device was deallocated */
FS_RELABEL 2309 /* Filesystem relabeled */
USER_MAC_POLICY_LOAD 2310 /* Userspc daemon loaded policy */
ROLE_MODIFY 2311 /* Admin modified a role */
USER_MAC_CONFIG_CHANGE 2312 /* Change made to MAC policy */
USER_MAC_STATUS 2313 /* Userspc daemon enforcing change */
FIRST_CRYPTO_MSG 2400
CRYPTO_TEST_USER 2400 /* Crypto test results */
CRYPTO_PARAM_CHANGE_USER 2401 /* Crypto attribute change */
CRYPTO_LOGIN 2402 /* Logged in as crypto officer */
CRYPTO_LOGOUT 2403 /* Logged out from crypto */
CRYPTO_KEY_USER 2404 /* Create,delete,negotiate */
CRYPTO_FAILURE_USER 2405 /* Fail decrypt,encrypt,randomiz */
CRYPTO_REPLAY_USER 2406 /* Crypto replay detected */
CRYPTO_SESSION 2407 /* Record parameters set during
TLS session establishment */
CRYPTO_IKE_SA 2408 /* Record parameters related to
IKE SA */
CRYPTO_IPSEC_SA 2409 /* Record parameters related to
IPSEC SA */
LAST_CRYPTO_MSG 2499
FIRST_VIRT_MSG 2500
VIRT_CONTROL 2500 /* Start,Pause,Stop VM/container */
VIRT_RESOURCE 2501 /* Resource assignment */
VIRT_MACHINE_ID 2502 /* Binding of label to VM/cont */
VIRT_INTEGRITY_CHECK 2503 /* Guest integrity results */
VIRT_CREATE 2504 /* Creation of guest image */
VIRT_DESTROY 2505 /* Destruction of guest image */
VIRT_MIGRATE_IN 2506 /* Inbound guest migration info */
VIRT_MIGRATE_OUT 2507 /* Outbound guest migration info */
LAST_VIRT_MSG 2599
FIRST_USER_MSG2 2100 /* More userspace messages */
LAST_USER_MSG2 2999
BPF 1334 /* BPF load/unload */
EVENT_LISTENER 1335 /* audit mcast sock join/part */
URINGOP 1336 /* io_uring operations */
OPENAT2 1337 /* openat2 open_how flags */
DM_CTRL 1338 /* Device Mapper target control */
DM_EVENT 1339 /* Device Mapper events */
ANOM_CREAT 1703 /* Suspicious file creation */
8. Recherche d'informations dans les logs d’audit
La recherche d'événements est effectuée à l'aide de la commande ausearch. Elle a de très nombreuses options que nous ne pouvons pas décrire dans cet article. Référez-vous la page de manuel ausearch(8) pour les découvrir toutes.
Il est important de noter qu'un appel système peut engendrer une multitude d'événements d'audit, et qu'il est facile de les corréler grâce à un numéro de séquence qui est commun aux événements liés à un même appel système. Dans l'exemple qui suit, l'appel système est execve, et il engendre les événements dont les types sont spécifiés après la chaîne type= . Ils ont tous le numéro de séquence 976.
type=PROCTITLE msg=audit(08/20/2025 11:42:21.397:976) : proctitle=/usr/bin/dpkg --print-foreign-architectures
type=PATH msg=audit(08/20/2025 11:42:21.397:976) : item=2 name=/lib64/ld-linux-x86-64.so.2 inode=262159 dev=fe:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(08/20/2025 11:42:21.397:976) : item=1 name=/usr/bin/dpkg inode=262789 dev=fe:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(08/20/2025 11:42:21.397:976) : item=0 name=/usr/bin/dpkg inode=262789 dev=fe:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(08/20/2025 11:42:21.397:976) : cwd=/root
type=EXECVE msg=audit(08/20/2025 11:42:21.397:976) : argc=2 a0=/usr/bin/dpkg a1=--print-foreign-architectures
type=SYSCALL msg=audit(08/20/2025 11:42:21.397:976) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x55bab76b0f70 a1=0x55bab740a120 a2=0x55bab73885b0 a3=0x485e652cb946122b items=3 ppid=1471 pid=1611 auid=mb uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=2 comm=dpkg exe=/usr/bin/dpkg subj=unconfined key=(null)
En observant les attributs des événements ci-dessus, on peut repérer des informations telles que PID, PPID, UID, eUID, sUID, TTY, CWD, des capabilities, etc. Il y a donc une multitude d'informations que l'on peut récupérer et analyser, selon les besoins.
Si l'on souhaite récupérer les éventuels événements générés suite à la définition de la règle identifiée par sshconfigchange au paragraphe 5.4, on peut utiliser la commande :
# ausearch -k sshconfigchange -i
qui affiche des informations ressemblant à :
type=PROCTITLE msg=audit(08/28/2025 11:07:32.711:635) : proctitle=chmod 755 sshd_config type=PATH msg=audit(08/28/2025 11:07:32.711:635) : item=0 name=sshd_config inode=4458032 dev=fe:01 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(08/28/2025 11:07:32.711:635) : cwd=/etc/ssh type=SYSCALL msg=audit(08/28/2025 11:07:32.711:635) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=AT_FDCWD a1=0x5604ee19c4d0 a2=0755 a3=0x7f99181c3fb8 items=1 ppid=958 pid=1385 auid=mb uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=2 comm=chmod exe=/usr/bin/chmod subj=unconfined key=sshconfigchange
Des lignes de ce type peuvent parfois être nombreuses pour certains événéments, et leur analyse visuelle peut être grandement facilitée par des configurations adaptées de la commande de colorisation hl (https://github.com/mbornet-hl/hl).
9. Production de rapports d’audit
La commande aureport produit une synthèse relative aux logs d'audit. Elle comporte également de nombreuses options de sélection qui sont décrites dans la page de manuel de aureport(8). Ces options permettent, entre autres, de choisir le type d'événement pour lequel il faut afficher une synthèse : tentatives d'authentification, modifications de configuration, connexions, modifications de compte, exécution de programmes, etc. Voici un exemple de résultat d'exécution, provenant d'une VM Debian 12 peu fréquemment utilisée, qui montre le rapport principal, à savoir une synthèse des différents événements présents dans les logs :
# aureport Summary Report ====================== Range of time in logs: 08/20/2025 11:42:21.009 - 08/27/2025 12:05:40.199 Selected time for report: 08/20/2025 11:42:21 - 08/27/2025 12:05:40.199 Number of changes in configuration: 18 Number of changes to accounts, groups, or roles: 0 Number of logins: 2 Number of failed logins: 0 Number of authentications: 11 Number of failed authentications: 0 Number of users: 5 Number of terminals: 10 Number of host names: 2 Number of executables: 108 Number of commands: 129 Number of files: 179 Number of AVC's: 0 Number of MAC events: 0 Number of failed syscalls: 113 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 0 Number of integrity events: 0 Number of virt events: 0 Number of keys: 0 Number of process IDs: 696 Number of events: 1602
Le rapport principal est le seul qui ne fait pas figurer les numéros d'événement.
En voici un autre qui montre les tentatives d'authentification :
# aureport -au Authentication Report ============================================ # date time acct host term exe success event ============================================ 1. 08/21/2025 11:13:39 mb 192.168.122.1 ssh /usr/sbin/sshd yes 243 2. 08/21/2025 11:13:45 root ? /dev/pts/0 /usr/bin/su yes 321 3. 08/21/2025 11:18:34 nobody ? ? /usr/bin/su yes 398 4. 08/21/2025 11:18:34 nobody ? ? /usr/bin/su yes 427 5. 08/21/2025 11:18:34 nobody ? ? /usr/bin/su yes 436 6. 08/27/2025 11:31:29 mb 192.168.122.1 ssh /usr/sbin/sshd yes 242 [...] 27. 09/01/2025 10:38:29 nobody ? ? /usr/bin/su yes 502 28. 09/01/2025 10:38:29 nobody ? ? /usr/bin/su yes 512 29. 09/01/2025 11:29:28 mb 192.168.122.1 ssh /usr/sbin/sshd yes 788 30. 09/01/2025 11:29:34 root ? /dev/pts/1 /usr/bin/su yes 817
Les rapports générés par aureport sont des synthèses qui peuvent être utilisées à des fins statistiques, ils ne fournissent pas d'informations détaillées sur les événements.
10. Synthèse relative aux VMs
La commande auvirt peut afficher des synthèses relatives à l'audit des machines virtuelles exécutées sur le système. En voici deux exemples :
# auvirt --start today --summary Range of time for report: Fri Aug 29 10:24 - Fri Aug 29 12:40 Number of guest starts: 5 Number of guest stops: 2 Number of resource assignments: 75 Number of related AVCs: 2 Number of related anomalies: 0 Number of failed operations: 0 # auvirt --start today debian12-yocto root Fri Aug 29 10:24 alpha root Fri Aug 29 10:25 beta root Fri Aug 29 10:25 eta root Fri Aug 29 10:25 - 12:40 (02:14 gamma root Fri Aug 29 10:25 - 12:38 (02:12
11. Exemples d’utilisation de commandes
Voici ci-dessous quelques exemples d'utilisation possible des commandes décrites précédemment.
11.1. auditctl
- auditctl -s
Affiche le statut de l'audit
- auditctl -l
Affiche la liste des règles configurées
- auditctl -e 0
Désactive temporairement l'audit
- auditctl -e 1
Réactive l 'audit
- auditctl -e 2
Verrouille la configuration de l'audit : un reboot est nécessaire pour modifier la configuration.
11.2. ausearch
ausearch -m 2>&1 1>/dev/null | grep '^Valid message types are:' | sed 's/^Valid message types are: //' | tr ' ' '\n' |
sed '/^[ ]*$/d' | less -RX
Cette commande affiche la liste des types de messages que l'on peut passer en argument à la commande ausearch après l'option -m :ACCT_LOCK ACCT_UNLOCK ADD_GROUP ADD_USER ALL ANOM_ABEND ANOM_ACCESS_FS [...] CRYPTO_SESSION CRYPTO_IKE_SA CRYPTO_IPSEC_SA VIRT_CONTROL VIRT_RESOURCE VIRT_MACHINE_ID VIRT_INTEGRITY_CHECK VIRT_CREATE VIRT_DESTROY VIRT_MIGRATE_IN VIRT_MIGRATE_OUT
- ausearch -m ALL -i
Affiche tous les événements enregistrés dans l'audit en interprétant localement certaines valeurs numériques telles ques que UID, eUID, GID, eGID, etc.
- ausearch -m execve -i
Affiche tous les événements de type EXECVE en interprétant certaines valeurs numériques.
11.3. aureport
- aureport -x --summary
Affiche une synthèse des programmes exécutés sur le système.
- aureport -k
Affiche les événements associés aux règles nommées (key).
11.4. aulast
aulast
Affiche la liste des connexions utilisateurs en se basant sur les logs d'audit.# aulast mb pts/0 192.168.122.1 Thu Aug 21 11:13 - 15:31 (04:18) reboot system boot 6.1.0-37-amd64 Thu Aug 21 11:13 - 15:31 (04:18) reboot system boot 6.1.0-37-amd64 Wed Aug 27 11:31 mb pts/0 192.168.122.1 Wed Aug 27 11:31 still logged in
aulast --bad
Affichage la liste des connexions qui ont échoué.# aulast --bad (invalid sshd 192.168.122.1 Tue Sep 2 14:02 - 14:02 (00:00) (invalid sshd 192.168.122.1 Tue Sep 2 14:02 - 14:02 (00:00) (invalid sshd 192.168.122.1 Tue Sep 2 14:02 - 14:02 (00:00) (invalid sshd 192.168.122.1 Tue Sep 2 14:02 - 14:02 (00:00) (invalid sshd 192.168.122.1 Tue Sep 2 14:02 - 14:02 (00:00) (invalid sshd ::1 Tue Sep 2 14:15 - 14:15 (00:00) (invalid sshd ::1 Tue Sep 2 14:15 - 14:15 (00:00) (invalid sshd ::1 Tue Sep 2 14:15 - 14:15 (00:00) (invalid sshd ::1 Tue Sep 2 14:15 - 14:15 (00:00) (invalid sshd ::1 Tue Sep 2 14:15 - 14:15 (00:00)
11.5. aulastlog
aulastlog
Affiche la dernière connexion des utilisateurs.# aulastlog Username Port From Latest root **Never logged in** daemon **Never logged in** bin **Never logged in** sys **Never logged in** sync **Never logged in** games **Never logged in** man **Never logged in** lp **Never logged in** mail **Never logged in** news **Never logged in** uucp **Never logged in** proxy **Never logged in** www-data **Never logged in** backup **Never logged in** list **Never logged in** irc **Never logged in** _apt **Never logged in** nobody **Never logged in** systemd-network **Never logged in** systemd-timesync **Never logged in** messagebus **Never logged in** sshd **Never logged in** dnsmasq **Never logged in** avahi **Never logged in** speech-dispatcher **Never logged in** pulse **Never logged in** saned **Never logged in** lightdm **Never logged in** polkitd **Never logged in** rtkit **Never logged in** colord **Never logged in** mb /dev/pts/0 192.168.122.1 08/27/2025 11:31:29 yoctouser **Never logged in**
aulastlog --user root
Affiche la dernière connexion de l'utilisateur spécifié (ici : root).# aulastlog --user root Username Port From Latest root /dev/pts/1 192.168.122.1 09/02/2025 14:20:27
12. Interfaces avec d'autres logiciels
12.1. Les plug-ins
Il existe, sous Debian, un package appelé audispd-plugins (audit dispatcher plug-in) contenant des plug-ins pour le système d'auditing. Ce package peut être installé à l'aide de la commande :
# apt install audispd-plugins
Il peut être utilisé pour transférer des événements d'audit à syslog, faire suivre des logs à travers un socket Unix (AF_UNIX) ou exécuter un script (exec) en réponse à des événements. C'est une extension à auditd qui permet de traiter les événements de différentes façons en fonction des logiciels consommateurs.
12.2. Les SIEM (Security Information and Event Manager)
Il est possible d'interfacer auditd avec des SIEM, comme par exemple Wazuh. Ce dernier va exploiter les logs d'auditd directement grâce à la configuration suivante à placer dans le fichier /var/ossec/etc/ossec.conf :
<localfile>
<location>/var/log/audit/audit.log</location>
<log_format>audit</log_format>
</localfile>Grâce aux informations remontées par auditd, Wazuh peut détecter des tentatives d'intrusion ou d'autres comportements suspects.
13. Impact sur les performances du système
Il faut être conscient de l'effet de l'activation de l'auditing sur les performances d'un système, particulièrement si ce système est en production avec des contraintes fortes. Activer l'audit avec des règles générant beaucoup d'événements, comme la surveillance de l'appel système execve() par exemple, peut avoir un impact significatif et fortement dégrader les performances du système.
Il faut également se méfier de potentiels effets de seuils qui se produiraient par un simple ajout d'une règle dans un système déjà fortement audité : un effet d'engorgement du backlog aurait des conséquences potentiellement graves sur le fonctionnement d'un système.
Le cas échéant, une augmentation du nombre de buffers constituant le backlog pour être opérée à l'aide de l'option -b de la commande auditctl. La valeur courante de ce paramètre peut être affichée à l'aide de la commande :
# auditctl -s | grep backlog_limit
14. Fichiers relatifs au système d'audit
De nombreux fichiers sont liés à l'audit Linux, que ce soit des commandes système, des bibliothèques, des fichiers de configuration ou d'état, des fichiers d'exemples ou des pages de manuel, etc.
Nous allons en lister un grand nombre ci-dessous afin de les identifier et de pouvoir les trouver rapidement sur le système si nécessaire.
14.1. Commandes système
/usr/sbin/auditctl /usr/sbin/auditd /usr/sbin/augenrules /usr/sbin/aureport /usr/sbin/ausearch /usr/sbin/autrace /usr/sbin/audisp-syslog /usr/sbin/audisp-remote (pour les plug-ins) /usr/sbin/audispd-zos-remote (pour les plug-ins) /usr/bin/aulast /usr/bin/aulastlog /usr/bin/ausyscall /usr/bin/auvirt
14.2. Bibliothèques
/usr/lib/x86_64-linux-gnu/libaudit.so.1 /usr/lib/x86_64-linux-gnu/libauparse.so.0
14.3. Fichiers headers
/usr/include/linux/audit.h [audit-userspace] /lib/audit-records.h
14.4. Fichiers de configuration
/etc/audit/auditd.conf /etc/audit/audit.rules /etc/audit/rules.d/*.rules /etc/audit/plugins.d/* (pour les plug-ins) /etc/audit/zos-remote.conf (pour les plug-ins) /etc/libaudit.conf
14.5. Fichiers utilisés pour le fonctionnement des processus
/var/run/auditd.pid /var/run/audispd_events (pour les plug-ins)
14.6. Fichiers d'exemples
/usr/share/doc/auditd/* /usr/share/doc/auditd/examples/rules/*.rules
15. Man pages
Les pages de manuel ci-dessous décrivent les commandes, les fichiers de configurations ou certains fonctionnements liés au système d'audit.
15.1. Man pages des commandes système
auditctl(8) auditd(8) augenrules(8) aureport(8) ausearch(8) autrace(8) audisp-syslog(8) (pour les plug-ins) audisp-remote(8) (pour les plug-ins) aulast(8) aulastlog(8) ausyscall(8) auvirt(8)
15.2. Man pages des fichiers de configuration
auditd.conf(5) audit.rules(7) libaudit.conf(5)
15.3. Man page de fonctionnement des plug-ins
auditd-plugins(5)
16. Dépôts publics du projet d’audit
Le projet d’auditing sous Linux est un projet libre dont les sources et la documentation se trouvent sur des dépôts github :
- audit-kernel
Il s’agit de la partie de l’audit contenue dans le noyau Linux, c’est la partie centrale qui fait le travail d’audit.
L’URL de son dépôt est :
https://github.com/linux-audit/audit-kernel
- audit-userspace
Ce dépôt contient tous les programmes s'exécutant dans l'espace utilisateur, le démon lui-même et toutes les autres commandes.
L'URL du dépôt est :
https://github.com/linux-audit/audit-userspace
- audit-testsuite
Ce dépôt contient un jeu de tests de non-régression.
L'URL du dépôt est :
https://github.com/linux-audit/audit-testsuite
- audit-documentation
Ce dépôt contient la documentation et les spécifications liées au projet.
L'URL du dépôt est :
https://github.com/linux-audit/audit-documentation
Conclusion
Cet article constitue une introduction à l'utilisation de l'audit sous Linux. Il est généralement employé dans le monde des serveurs, mais on peut aussi envisager de l'utiliser dans une distribution Yocto pour des besoins très spécifiques. Cela fera peut-être l'objet d'un prochain article.
Bibliographie
Les documents de références officiels concernant l'audit Linux sont évidemment les pages de manuel, le site audit-documentation et les sites de codes sources citées au paragraphe précédent. Toutefois, pour les compléter de façon plus vulgarisatrice, voici une liste d'URL fournissant des descriptions de l'audit dont certaines pourront vous sembler moins rébarbatives, ainsi que des exemples complémentaires de règles :
1. Comprehensive Guide to Auditd for Linux Embedded Systems: Security Auditing and Compliance, https://koansoftware.com/comprehensive-guide-to-auditd-for-linux-embedded-systems/
2. Red-Hat : Configure Linux system auditing with auditd, https://www.redhat.com/en/blog/configure-linux-auditing-auditd/a>
3. GNU Linux Magazine France, , Journalisez les actions de vos utilisateurs avec Auditd, HS 93, nov. 2017, https://connect.ed-diamond.com/GNU-Linux-Magazine/glmfhs-093/journalisez-les-actions-de-vos-utilisateurs-avec-auditd/
4. Arch Linux : Linux audit system, https://pmhahn.github.io/audit/
5. Audit framework, https://wiki.archlinux.org/title/Audit_framework
6. Audit d'un système Linux avec l'outil Auditd, https://www.linkedin.com/pulse/audit-dun-syst%C3%A8me-linux-avec-loutil-auditd-sylvanus-hougbekey-cfbof/
7. Linux Audit :Tuning auditd: high-performance Linux Auditing, https://linux-audit.com/linux-audit-framework/tuning-auditd-high-performance-linux-auditing
8. SUSE : Understanding Linux Audit, https://documentation.suse.com/en-us/sles/12-SP5/html/SLES-all/cha-audit-comp.html
9. ANSSI : Recommandations de configuration d'un système GNU / Linux,https://cyber.gouv.fr/sites/default/files/document/fr_np_linux_configuration-v2.0.pdf