Linux Auditd Il enregistre les événements liés à la sécurité directement à partir du noyau et me fournit une piste d'audit complète pour les connexions, les modifications de fichiers, l'exécution de commandes et les appels système. Correct Une fois configuré, je détecte les attaques à un stade précoce, je respecte les exigences de conformité telles que la norme ISO 27001 ou la norme PCI DSS, et j'analyse les incidents de manière fiable sur le plan médico-légal.
Points centraux
Ce Je résume délibérément cet aperçu de manière concise, concrète et sans formules toutes faites, afin que tu comprennes immédiatement comment définir des règles d'audit, protéger les journaux et en tirer des conclusions. Je consulte Citez les principaux composants, les cas d'utilisation typiques, les règles à respecter et les sources d'erreurs qui constituent souvent des angles morts dans de nombreux environnements. Donc tu vois d'un seul coup d'œil quels paramètres du fichier auditd.conf sont pris en compte et quels outils sont disponibles pour l'analyse. Ensuite, J'approfondis chaque sujet à l'aide d'exemples, de conseils clairs et d'un tableau récapitulatif des paramètres essentiels. Avec cela, tu réussiras à passer de „ Auditd fonctionne “ à „ Auditd fournit des signaux de sécurité exploitables “.
- Piste d'audit: traçabilité complète des actions liées à la sécurité
- Règles: fichiers critiques ciblés, execve, privilèges et configurations
- Protection des journaux: rotation, déclenchement par mémoire, réaction en cas de goulots d'étranglement
- À distance: collecte centralisée via TCP/TLS et intégration SIEM
- Analyse: ausearch, aureport, des clés claires et une documentation soignée
Auditd sous Linux dans le cadre du dispositif de sécurité
Auditd Il complète les journaux système classiques en se concentrant spécifiquement sur les actions liées à la sécurité et en enregistrant les événements via l'interface du noyau. Le Par défaut, Daemon enregistre ces événements dans /var/log/audit/audit.log et enregistre quel utilisateur a effectué quelle action et à quel moment. De ce fait je peux rapidement vérifier les éléments suspects, par exemple des modifications involontaires apportées à /etc/ssh/sshd_config ou sur des fichiers sensibles tels que /etc/shadow. À l'adresse suivante : Dans les environnements réglementés, cela me permet de disposer de preuves en cas de non-respect des directives et de satisfaire aux exigences en matière de journalisation fiable. En face de Contrairement aux données classiques des journaux ou du Syslog, Auditd offre une vue approfondie et axée sur la sécurité, essentielle pour l'analyse des attaques.
Architecture : noyau, démon, outils
Le Le système d'audit se compose d'un sous-système du noyau chargé de la collecte des données et d'un service de l'espace utilisateur auditd pour le stockage et les outils de gestion et d'analyse. Sur auditctl Je définis des règles au moment de l'exécution ou je charge des règles persistantes au démarrage /etc/audit/rules.d/*.rules. Avec ausearch je filtre les événements par heure, utilisateur, clé ou fichier, tandis que aureport génère des rapports concis. Donc Je combine une collecte de données contrôlée de manière granulaire avec une analyse rapide et je garantis la traçabilité de la piste d'audit tout au long du processus. Important est une nomenclature cohérente concernant -k Clés, pour que les requêtes ultérieures fonctionnent correctement.
Installation et activation
À l'adresse suivante : J'installe RHEL/CentOS audit via dnf install audit ou yum install audit, sous Debian/Ubuntu, j'utilise apt install auditd audispd-plugins. Selon Une fois l'installation terminée, je démarre et active le service à l'aide de la commande suivante : systemctl start auditd et systemctl enable auditd, je vérifie le statut avec systemctl status auditd. Dès que Lorsque le sous-système d'audit et le service sont en cours d'exécution, les événements sont enregistrés conformément aux règles dans /var/log/audit/audit.log. Je consulte Vérifie le bon fonctionnement en accédant de manière ciblée à un fichier surveillé, puis recherche l'événement à l'aide de ausearch -k keyname. Pour Pour garantir un démarrage cohérent à chaque démarrage, je veille à ce que des règles persistantes soient en place et se chargent correctement.
Début anticipé, arriéré et protection par des règles
À l'adresse suivante : Pour ne pas manquer les événements survenant au tout début du démarrage, j'active le sous-système d'audit dès le démarrage du noyau. À ce sujet Je définis les paramètres du noyau et une taille de file d'attente suffisante pour éviter que des événements ne soient perdus pendant la phase de démarrage. De plus Après le chargement, je verrouille la base de règles pour empêcher toute manipulation.
- Paramètres du noyau:
audit=1 audit_backlog_limit=8192dans/etc/default/grubcompléter, puisupdate-grub(Debian/Ubuntu) ougrub2-mkconfig -o /boot/grub2/grub.cfg(RHEL/CentOS). - Retard dans les règles: Dans les règles de démarrage, je définis
-b 8192, afin de dimensionner correctement la file d'attente du noyau. - Bloquer les règles: Une fois la base de règles définitive chargée, j'active le mode « Immutable » à l'aide de
-e 2. Les modifications ne sont alors possibles qu'après un redémarrage, ce qui constitue une protection efficace contre les manipulations en temps réel. - Comportement en cas de débordement: Dans
/etc/audit/auditd.confje définisoverflow_action(par exempleSYSLOGouCÉLIBATAIRE), afin d'obtenir des réactions bien définies lorsque la mémoire tampon est pleine.
Bien définir les règles d'audit
Le La qualité de la piste d'audit dépend de règles claires et ciblées, qui couvrent les actions critiques et évitent les informations superflues. Pour Je place par exemple les fichiers sensibles -w /etc/passwd -p warx -k passwd_changes et ajoute des règles adaptées pour /etc/shadow, /etc/sudoers ou /etc/ssh/. À l'adresse suivante : Pour enregistrer l'exécution des commandes, j'utilise -a always,exit -F arch=b64 -S execve ainsi que la version 32 bits, afin que chaque version reste visible, même via racine. Pour Je filtre de manière ciblée les utilitaires tels qu'Apache en fonction du chemin d'accès au fichier binaire, par exemple -a always,exit -F arch=b64 -S all -F exe=/usr/sbin/apache2 -k apache_activity. Je consulte Documente chaque règle à l'aide de commentaires concis et de clés univoques, afin que les analyses restent reproductibles et que vos collègues puissent en comprendre l'intention.
Exemples de règles avancées et réglages
Pour Pour aller plus loin, je mets en place un ensemble ciblé qui met en évidence les changements de privilèges, les interventions au niveau du noyau, les modifications liées au temps et au réseau, ainsi que les mécanismes persistants – sans bruit lié aux paquets ou aux sauvegardes.
- Uniquement les utilisateurs interactifs:
-F auid >= 1000 -F auid != 4294967295complété parexecve-Règles permettant d'exclure les services système. - Changement de privilèges:
-a always,exit -F arch=b64 -S setuid,setreuid,setresuid -k priv_changeet la version 32 bits. En option :-C uid != euid, si les comparaisons de champs sont prises en charge. - Modules du noyau:
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kmod_change; en outre :-w /sbin/insmod -p x -k kmod_exec,-w /sbin/modprobe -p x -k kmod_exec. - Changements d'horaires:
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_changeet-w /etc/localtime -p wa -k time_change. - Montages et système de fichiers:
-a always,exit -F arch=b64 -S mount,umount2 -k fs_mount;-w /etc/fstab -p wa -k fs_mount. - base du réseau:
-a always,exit -F arch=b64 -S sethostname,setdomainname -k net_conf;-w /etc/hosts -p wa -k net_conf,-w /etc/hostname -p wa -k net_conf,-w /etc/resolv.conf -p wa -k net_conf. - Cron et Timer:
-w /etc/crontab -p wa -k sched,-w /etc/cron.d/ -p wa -k sched,-w /var/spool/cron/ -p wa -k sched,-w /etc/systemd/system/ -p wa -k sched,-w /usr/lib/systemd/system/ -p wa -k sched. - Persistance via SSH:
-w /root/.ssh/ -p wa -k ssh_keys,-w /home/ -p wa -k ssh_keys(chemin étroit surauthorized_keys-fichiers par utilisateur, afin d'éviter le bruit de fond). - Lutter contre les abus liés aux droits SUID et SGID: Se concentrer sur les répertoires exécutables :
-w /usr/bin/ -p wa -k bin_change,-w /usr/sbin/ -p wa -k bin_change,-w /bin/ -p wa -k bin_change,-w /sbin/ -p wa -k bin_change. - N'enregistrer que les échecs (pour les appels système bruyants) :
-a always,exit -F arch=b64 -S open,openat -F success=0 -k file_denied. - Réduire le bruit: Exclure les gestionnaires de paquets et les sauvegardes, par exemple :.
-a never,exit -F exe=/usr/bin/dpkg,-a never,exit -F exe=/usr/bin/apt,-a never,exit -F exe=/usr/bin/yum,-a never,exit -F exe=/usr/bin/rpm,-a never,exit -F exe=/usr/bin/rsync(Vérifier le chemin d'accès pour chaque distribution).
Gestion des journaux et protection contre la perte de journaux
Sans Sans une rotation régulière et des seuils bien définis, les journaux d'audit risquent de perdre des données précieuses ou de saturer le système de fichiers. À l'adresse suivante : /etc/audit/auditd.conf Je définis notamment max_log_file, max_log_file_action, num_logs, space_left et des réactions telles que space_left_action, disk_full_action ou disk_error_action. Je consulte Je préfère les actions telles que ROTATE et une notification rapide via Syslog, afin que je puisse réagir à temps en cas de goulots d'étranglement. De plus Je sauvegarde les journaux d'audit sur un hôte distinct afin de compliquer toute manipulation du système concerné et de préserver les preuves. Le Le tableau suivant répertorie les paramètres principaux et indique des réglages types adaptés à la pratique.
| Paramètres | Objectif | Exemple | Remarque |
|---|---|---|---|
fichier_journal | Emplacement de stockage des journaux d'audit | /var/log/audit/audit.log | Conserver le chemin d'accès par défaut et le sécuriser clairement |
log_format | Format des événements | RAW | Le format RAW facilite l'analyse médico-légale sans perte d'informations |
max_log_file | Taille maximale du fichier (Mo) | 100 jusqu'à 500 | Adapter la taille au volume d'événements et à l'espace de stockage |
max_log_file_action | Action à déclencher lorsque la taille est atteinte | ROTATE | La rotation empêche les blocages ou les écrasements |
num_logs | Nombre de fichiers conservés | 5 jusqu'à 10 | Suffisamment d'historique pour les analyses, sans monopoliser l'espace de stockage |
space_left | Seuil de mémoire libre (Mo) | 1024 ou supérieur | Les alertes précoces permettent de gagner du temps de réaction |
space_left_action | Réaction en cas de dépassement à la baisse | SYSLOG | Envisager également l'envoi d'un e-mail ou d'une alerte SIEM |
disk_full_action | Comportement lorsque le support de données est plein | SUSPENDU ou STOP | Une décision claire en fonction du niveau d'acceptation du risque |
Enregistrement à distance et analyse centralisée
Pour Pour de nombreux serveurs, j'opte pour une collecte centralisée via TCP/TLS, contrôlée par des paramètres tels que tcp_listen_port et les terminaux correspondants. Sur À l'aide des plugins audispd ou de rsyslog, je transmets les événements à une plateforme SIEM ou de sécurité, et je mets en corrélation les erreurs de connexion, les modifications de configuration et les lancements de processus suspects. Donc je repère des schémas qui, sur un serveur isolé, passent inaperçus, mais qui, lorsqu'ils se produisent en groupe, déclenchent immédiatement une alerte. Qui qui utilise déjà des tableaux de bord bénéficie de Agrégation de logs dans l'hébergement, car les événements d'audit y sont regroupés avec d'autres données de télémétrie. Je consulte Veillez également à ce que le parcours de transport soit sécurisé et à ce qu'il y ait une séparation claire entre les systèmes de production et l'instance de collecte.
Analyse : utiliser « ausearch » et « aureport » de manière ciblée
Données brutes ne servent à rien si je ne peux pas les filtrer rapidement ; c'est pourquoi je commence avec des clés claires et j'utilise ausearch pour les requêtes ciblées. Avec ausearch -k passwd_changes -ts today j'évalue par exemple les modifications récentes apportées à /etc/passwd ; j'affinerai les plages horaires et les filtres d'utilisateurs si nécessaire. Pour fournit des rapports de synthèse aureport --summary des tableaux concis qui mettent en évidence les connexions suspectes, les modifications de fichiers et la fréquence des appels système. De plus J'ajoute à cette vue d'ensemble sur le lancement des processus et l'utilisation des ressources : Comptabilité analytique, afin de mettre en corrélation les chaînes d'exécutions et les pics de charge. Sur le site Ce qui compte, c'est que je puisse répondre en quelques secondes aux questions suivantes : qui, quoi, quand, où et par quel moyen.
Approfondir l'analyse : bien interpréter les champs d'événement
Avec cela, Pour que les analyses soient précises, je connais les champs et les types d'événements les plus importants. SYSCALL-Les entrées comprennent notamment. auid (numéro d'identification fiscale), uid/euid/suid (UID réel/effectif/enregistré), ses (identifiant de session) et exe (fichier exécutable). PATH- Les blocs indiquent les chemins concernés, EXECVE énumère les arguments, CWD fournit le répertoire de travail. Avec ausearch -m SYSCALL -sc execve -ua 1000 -ts recent je me concentre sur les présentations interactives ; aureport -x --summary -i me permet de voir d'un seul coup d'œil les fréquences et les anomalies. Important: auid reste au-dessus de sudo ou les sauts setuid sont constants et constituent donc le critère de filtrage le plus fiable pour déterminer „ qui en est à l'origine ? “.
Éviter les erreurs typiques
À propos de Des règles trop générales alourdissent les journaux et masquent les informations vraiment importantes ; c'est pourquoi je me concentre sur les fichiers critiques, la fonction `execve`, les changements de privilèges et les configurations liées à la sécurité. Manquant Une rotation bien gérée permet d'éviter que les systèmes ne prennent des risques ; c'est pourquoi je fixe des limites claires en termes de taille, de nombre et d'actions à mener en cas de goulots d'étranglement. Je consulte surveille également la configuration de l'audit et le répertoire /var/log/audit/, car les pirates veulent effacer leurs traces. Et Je consigne chaque règle en précisant la clé, l'objectif et une brève justification, afin que les analyses restent cohérentes. Qui Si vous avez des soucis de performances, vous devriez filtrer avec précision, supprimer les chemins inutiles et vérifier d'abord l'impact des nouvelles règles à l'aide de tests.
Performances, stabilité et contrôles qualité
Audit ne doit pas ralentir le fonctionnement. Je consulte vérifie régulièrement avec auditctl -s, si perdu-surveiller les événements qui se produisent et observer les valeurs du backlog après les modifications apportées aux règles. À l'adresse suivante : En cas de forte charge d'événements, j'augmente la file d'attente du répartiteur (q_depth) des plugins audispd et définis overflow_action consciemment. Où execve- Si les règles génèrent trop de volume, je limite via auid ou via exe=- Configure les listes blanches/noires et n'enregistre que les échecs en cas d'appels système bruyants. Avant Avant le déploiement à grande échelle, je valide les nouvelles règles en environnement de test, je mesure le taux d'événements et la charge CPU, puis je compare aureport --summary avant/après la modification, afin de quantifier l'effet.
Environnements de conteneurs et de virtualisation
À l'adresse suivante : Outre les hôtes de conteneurs, le noyau enregistre également les processus des conteneurs – c'est voulu, mais cela peut générer beaucoup de bruit. Je consulte je m'appuie sur la protection de l'hôte (par exemple,. dockerd ou Podman), des chemins d'accès aux binaires et des configurations sécurisés, et je filtre l'affichage utilisateur via auid. Exemples: -w /usr/bin/dockerd -p x -k container_runtime, -w /etc/docker/ -p wa -k container_conf, ainsi que des règles d'hôte génériques telles que execve avec auid-Filtre. À l'adresse suivante : Pour les machines virtuelles, je traite les journaux d'audit comme des données éphémères : j'active le transfert à distance, je configure une rotation courte et je veille à la cohérence temporelle lors des instantanés. Important Il reste à assurer une synchronisation NTP/Chrony précise afin que les analyses de la chronologie soient fiables.
Conformité et gestion des preuves
Pour Conformément à la norme ISO 27001 (notamment A.12.4 « Journalisation/Surveillance » et A.16 « Gestion des incidents ») et à la norme PCI DSS (chapitre 10), je fournis des preuves vérifiables : Quoi La durée d'accès est-elle consignée ? Qui y a accès ? Comment l'intégrité est-elle garantie ? Je consulte Gérez les versions de la base de règles, documentez les clés et leurs finalités, signez les journaux d'archivage à l'aide de hachages et stockez-les de manière à les protéger contre toute altération. À l'adresse suivante : En matière de données à caractère personnel, j'applique le principe de minimisation des données (règles ciblées, délais de conservation courts) et je définis des procédures de suppression claires. Donc Cela permet de générer des rapports qui convainquent les auditeurs et apportent réellement des réponses en cas d'incident.
Exploitation, surveillance et guides d'intervention
À l'adresse suivante : Pour un usage intensif, j'ai besoin de routines bien établies : des contrôles aléatoires quotidiens avec aureport, alertes en cas de perdu > 0, Vérification de la partition d'audit libre et du transfert à distance. Je consulte Créer des Playbooks : „ Cadres qui se font remarquer “ (filtre par exe= et auid), „ Fichier critique modifié “ (en corrélation avec PATH, SYSCALL, EXECVE), „ intervention au niveau du noyau “ (règles relatives à init_module et monter). Connu Les types d'événements tels que ANOM_PROMISCUOUS (interface en mode promisc) ou MAC_POLICY_LOAD (Politique MAC chargée) j'évalue les priorités et je déclenche les étapes de réponse.
Dépannage et redémarrage
Si Si je ne reçois aucun événement, je commence par vérifier ausearch -m DAEMON -ts today et auditctl -s (Statut/Carnet de commandes). Manquer Règles, je les télécharge avec augenrules --load nouveau et vérifie avec auditctl -l. Est le mode « Immutable » est activé (-e 2), seul un redémarrage avec des règles de démarrage adaptées peut résoudre le problème. À l'adresse suivante : Problèmes d'autorisation sur /var/log/audit/ Je rétablis les droits de propriété et les modes ; si SELinux est activé, je corrige les contextes. Et Je vérifie que log_format = RAW est défini – des données d'entrée lisibles pour l'analyse et les analyseurs syntaxiques.
Audit dans les environnements d'hébergement
Tout droit Dans les environnements d'hébergement comportant de nombreuses charges de travail, Auditd m'aide à garantir la séparation des clients de manière transparente et à détecter rapidement les abus. Je consulte Surveillez les serveurs Web, les serveurs de bases de données et les serveurs d'applications à l'aide d'ensembles de règles à plusieurs niveaux, et intégrez les événements dans les systèmes existants de surveillance et de réponse aux incidents. Pour Je veille à une séparation claire grâce à un stockage centralisé, des rôles distincts et des droits d'accès restreints aux répertoires de journaux. À l'adresse suivante : Pour compléter le diagnostic du système, j'utilise, si nécessaire, journalctl pour le dépannage, mais je conserve les analyses critiques pour la sécurité principalement dans le canal d'audit. Donc Cela permet de créer une piste d'audit fiable qui concilie les intérêts des clients, les exigences de conformité et l'efficacité opérationnelle.
En bref : ma méthode
Je consulte Commencez par définir un objectif clair, formulez des règles précises concernant les fichiers critiques, la fonction `execve` et les changements de privilèges, et sécurisez la rotation afin d'éviter toute perte de données. Ensuite J'active le transfert à distance avec TLS, je consigne les clés et je teste l'efficacité de chaque règle avant son déploiement à grande échelle. Pour Dans mon travail quotidien, je mise sur ausearch et aureport, mettez en place des recherches ciblées et générez des rapports clairs pour l'exploitation et la sécurité. À l'adresse suivante : Lorsque j'identifie des anomalies, je recoupe les événements d'audit avec d'autres signaux, tels que les données de processus ou de réseau, afin d'en isoler rapidement la cause. Donc Sous Linux, Auditd ne me fournit pas une avalanche de journaux, mais des réponses claires aux questions relatives à la sécurité dans les environnements de production.


