Journalisez les actions de vos utilisateurs avec Auditd

Cet article est l'occasion de présenter l'architecture de ce framework, les nombreuses possibilités offertes pour définir une politique d'audit pertinente et ses apports dans la cadre de la sécurisation d'un système d'information composé de postes et serveurs GNU/Linux.  

L'analyse de logs n'est pas en reste, car le framework met à la disposition des administrateurs et des responsables de la sécurité plusieurs outils permettant une fouille exploratoire des journaux d'événements générés à la recherche de la cause d'un dysfonctionnement fonctionnel ou d'un événement susceptible d'indiquer une compromission.

Néanmoins avant de se jeter à corps perdu dans la mise en œuvre d'une politique d'audit sur l'ensemble des postes GNU/Linux d'une entreprise, il convient d'évaluer les capacités offertes par le framework en les mettant en regard avec ses impacts sur les systèmes supervisés.

1. Un peu d'histoire

Le développement du framework Auditd a été initié en 2004 par les sociétés Red Hat, HP et IBM dans le cadre de la certification Critères Communs au niveau EAL 3+ (Evaluation Assurance Level) de la Red Hat Enterprise Linux 4. Dans le document spécifiant la cible d'évaluation [1], il est appelé « Lightweight Auditing Framework », nomenclature actuellement toujours utilisée. Ironie de l'histoire, à la même époque SUSE développe Linux Audit Subsystem (LAuS).

Le projet actuellement en version 2.7.7 est maintenu par Steve Grubb de la société Red Hat. Le site officiel du projet est accessible à l’adresse suivante : https://people.redhat.com/sgrubb/auditd.

2. Architecture

2.1 Mode de fonctionnement

Le framework Auditd implémente des hooks des appels système, en mode noyau, qui permettent de surveiller les processus en mode utilisateur et générer des événements d’audit dans le cas où ils correspondent à la politique de sécurité définie sur le système.

2.2 Composants

Le démon auditd est l’élément principal du framework en espace utilisateur. Il est responsable de la réception des événements d’audit envoyés par le noyau à travers une socket netlink et du stockage de ces derniers sur le système de fichiers.

Lancé au démarrage du système d'exploitation, il lit son fichier de configuration /etc/audit/auditd.conf, se connecte à la socket netlink et se met en attente de réception des événements en provenance du noyau.

Le démon auditd lance ensuite le démon dispatcher audisp. Ce dernier interagit avec le démon auditd, recevant les événements et se chargeant de leur traitement via un mécanisme de plugins. Le traitement appliqué peut être par exemple le déport vers un serveur de collecte dédié ou le stockage dans une base de données. Cette fonctionnalité sera abordée dans une section de cet article.

L'outil auditctl permet quant à lui de contrôler le démon auditd en communiquant en passant par les mécanismes offerts par la socket netlink.

Le schéma de la figure 1 illustre les interactions entre différents composants du framework.

3. Installation

Il est à noter que les capacités offertes par le framework seront illustrées dans suite de cet article avec l'utilisation d'une distribution Debian GNU/Linux. L'installation et la configuration des différents outils sont effectuées avec un utilisateur possédant le droit d'effectuer une élévation de privilèges via sudo.

Sur cette distribution, l’installation des composants du framework est effectuée via le package auditd :

3.1 Configuration

Pour pouvoir auditer au plus tôt les processus, il est nécessaire d’ajouter l’argument audit=1 aux arguments de boot du noyau. Les modifications sont à effectuer dans le fichier /boot/grub/grub.cfg via son insertion pour chaque entrée présente dans le fichier.

3.2 Pluggable Authentication Module

Garantir l'imputabilité d'un événement en cas d'élévation de privilèges est une condition sine qua non. L'utilisation du module PAM pam_loginuid permet de répondre à cette problématique en préservant l'UID original via l'utilisation d'un identifiant appelé audit UID (auid). Techniquement, le module gère une entrée /proc/PID/loginuid avec l'UID de l'utilisateur pour chaque service configuré pour être utilisé avec ce dernier.

L'utilisation du module passe par l'ajout de l'entrée suivante pour chaque service devant être audité :

session required pam_loginuid.so require_auditd.

Le paramètre require_auditd permet de demander au module d'interroger le statut du démon auditd et d'interdire toute authentification si ce dernier n'est pas actif.

Ci-dessous, l'exemple de la commande tail /var/log/audit.log exécutée après une élévation de privilèges. La commande a été exécutée par l'utilisateur root (uid = 0) après une élévation de privilèges effectuée par l'utilisateur test (id 1003) :

4. Règles

Une règle sert à décrire les paramètres d'audit que l'on souhaite appliquer à un objet (par exemple. « je souhaite auditer l'ensemble des binaires exécutés par l'utilisateur root »). Une politique d'audit est décrite à l'aide d'un ensemble de règles dont la sémantique sera décrite dans la suite de cet article.   

À titre d'exemple, ci-dessous la politique d'audit proposée par l’ANSSI (Agence Nationale de Sécurité des Systèmes d'Information) dans son document de recommandations de configuration d’un système GNU/Linux [2] :

4.1 Type

Il existe 3 types de règles implémentables pour la définition d’une politique d’audit :

• les règles permettant de contrôler le fonctionnement du démon auditd ;
• les règles permettant de surveiller les opérations effectuées sur le système de fichiers ;
• les règles permettant d’auditer les appels système.

4.2 Édition

Les règles peuvent être écrites via l’outil auditctl (les règles sont dans ce cas non persistantes au reboot) ou directement en éditant le fichier de configuration /etc/audit/audit.rules (règles persistantes).

La première méthode permet de tester une règle et de valider son bon fonctionnement avant de l'ajouter à la politique d'audit.

4.3 Implémentation

4.3.1 Règles de contrôle

Ces règles permettent de modifier le traitement des messages en permettant notamment la modification du nombre de buffers alloués (-b), le nombre de messages par secondes (-r) ou encore l'action en cas d'erreur critique survenant lors du traitement. L'exemple ci-dessous configure le déclenchement d'un kernel panic dans ce dernier cas de figure :

4.3.2 Règles sur les accès au système de fichiers

Une règle d'audit touchant le système de fichiers est construite de la manière suivante : spécification de l'objet à superviser (répertoire ou fichier) (-w) et le type d'accès à auditer (-p). Les types d'accès auditables sont les suivants :

• r pour auditer les accès en lecture ;
• w pour les accès en écriture ;
• x pour les accès en exécution ;
• a pour les changements d’attributs.

La règle ci-dessous spécifie l'audit de l'ensemble des accès en écriture et des changements d'attributs (-p wa) sur les fichiers présents dans le répertoire /etc (-w /etc/) :

4.3.3 Règles sur les appels système

Les règles d'audit sur les appels systèmes obéissent aux paramètres suivants :

• a : action, liste (l'ordre inverse dans les paramètres est autorisé). Le paramètre action peut être défini à always ou never. La figure 2, issue de la documentation officielle Red Hat accessible à l'adresse https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sec-Defining_Audit_Rules_and_Controls.html, illustre le fonctionnement de l'architecture et met en exergue les listes appliquées par le noyau quand il reçoit un appel système provenant d'une application ;
• S : spécification de l'appel système à auditer (évalué avec un OU logique).

Dans l'exemple précédent, la règle ci-dessous permet d'auditer les appels système get_kernel_syms, ptrace et prctl :

4.3.4 Labels

À chaque règle peut être associé un label (préfixé par -k) permettant d'affiner les recherches dans les événements d'audit.

4.4 Journaux

4.4.1 Gestion

Les journaux d'audit générés par le démon dispatcher audisp sont stockés par défaut dans le répertoire /var/log/audit/audit.log. Il est possible de modifier l'emplacement du fichier en modifiant le paramètre log_file dans le fichier de configuration /etc/audit/auditd.conf. Le déport des événements d'audit sur un collecteur de logs sera quant à lui traité dans un chapitre dédié de cet article.

4.4.2 Propriétés

Les journaux d'audit possèdent les propriétés suivantes :

• chaque enregistrement est constitué par plusieurs couples de type clé=valeur ;
• les événements peuvent générer un ou plusieurs enregistrements.

Un événement qui correspond à une règle d'audit sur le système génère plusieurs enregistrements. Le nombre d'enregistrements est déterminé par le type de règle (appel système, événement sur le système de fichiers, etc.).

4.4.3 Analyse

L'exemple ci-dessous permet d'appréhender l'ensemble des enregistrements générés suite à la suppression du fichier /home/test/test depuis le répertoire /home/test (rm /home/test/test) :

Il est à noter que ces enregistrements ont été générés par la règle suivante :

Cette commande génère 4 enregistrements préfixés par leur catégorie (type=) qui peuvent être corrélés via leur timestamp (1480270680.382) et leur id (705).

Ces enregistrements permettent notamment d'extraire les informations suivantes :

• l'appel système utilisé (type=SYSCALL) a pour identifiant 263 (correspondant à l'appel système sys_unlinkat) ;
• l'exécution de l'appel système s'est correctement déroulée (success=1) ;
• le nombre d’items utilisés est de 2 (item=2) ;
• le PID du processus est 3577 (pid=3577) ;
• l’audit UID de l’utilisateur ayant exécuté la commande est 1003 (auid=1003) ;
• la commande utilisée est /bin/rm (exe=/bin/rm) ;
• la commande a été exécutée depuis le répertoire /home/test (cwd=/home/test) ;
• les enregistrements de type PATH fournissent des informations issues du système de fichiers tels les numéros d’inode et les droits positionnés sur le répertoire (identifiés par item=0) et le fichier (identifié par item=1).

Pour plus d’informations sur les couples clé/valeur, il convient de se référer au fichier CSV field-dictionnary.csv disponible sur le dépôt GitHub du projet [3]. L'auteur du projet propose aussi un diagramme des champs utilisés pour chaque événement d'audit disponible à l'adresse suivante : https://people.redhat.com/sgrubb/audit/record-fields.html.

4.5  Impacts sur le système

L'activation des fonctions d'audit, et principalement celles concernant les appels système, a un impact sur les systèmes supervisés qu'il convient d'évaluer notamment sur des postes nécessitant d'importantes ressources pour assurer leur fonction (ex. cluster de calcul). Sur ce type de postes, il est impératif d'analyser les impacts induits sur l'occupation CPU et les entrées/sorties disques.

4.5.1 Évaluation

L'évaluation des impacts de la politique d'audit appliquée sur un système est possible avec la commande perf [4] disponible dans le package linux-tools disponible dans les dépôts de la distribution Debian GNU/Linux.

Les tests basiques effectués sur une machine de qualification n'offrant pas de services utilisateur ont pu mettre en avant une augmentation signicative des I/O en utilisant une règle spécifiant l'audit de l'ensemble des appels système. L'exemple ci-dessous montre que sur la période de test représentant 272098 événements, un peu plus de 33% sont issus du processus auditd :

Même si ce test prend comme postulat de départ le cas le plus défavorable en termes d'impacts, il a pour vertu d'illustrer l'augmentation des I/O correspondant aux événements d'audit journalisés.

4.5.2 Optimisations

Chaque événement généré fait l'objet d'une évaluation au regard de la politique d'audit définie sur le système. Ainsi chaque règle est testée jusqu’à ce que l'une d'entre elles corresponde, entraînant la fin de l'évaluation, et ce même si d'autres règles auraient pu déclencher un événement. Fort de ce constat, il convient :

• d'organiser les règles en fonction de leurs occurrences respectives ;
• d'utiliser les mécanismes de filtres et d'exclusion ;
• de factoriser les règles dans la majorité des cas.

4.5.2.1 Organisation

L'outil aureport qui sera abordé plus en détail dans la suite de cet article permet notamment de générer des statistiques basées sur les événements d'audit. Il est entre autres possible de demander à l'outil une statistique basée sur le nombre d'occurrences pour chaque label utilisé comme présenté dans l'exemple ci-dessous (seuls les 5 premiers labels sont affichés pour des questions de lisibilité) :

Cet exemple montre que la règle root_cmd (règle d'audit de l'ensemble des binaires exécutés par l'utilisateur root) a été déclenchée 12058 fois. Dans une logique d'optimisation, cette règle devra être positionnée dans les premières règles du fichier audit.rules.

4.5.2.2 Filtres

La mise en œuvre de filtres s'effectue en utilisant le paramètre -F qui permet de choisir les champs à auditer.  Les filtres peuvent être combinés (évalués avec un ET logique) sur un nombre maximum de 64 champs.

Pour illustrer le fonctionnement des filtres, ci-dessous un exemple de règle définissant l'audit de l'exécution (perm=x) du binaire su (path=/bin/su) pour l'utilisateur test (auid=1003) :

Les possibilités offertes vont bien au-delà de cet exemple sachant que le framework offre la capacité de définir des critères de filtre pouvant aller jusqu'aux arguments d'un appel système.

4.5.2.3 Exclusions

Le mécanisme d'exclusion permet de répondre à l'objectif d'optimisation en éliminant du mécanisme d'audit les événements jugés peu pertinents ou trop verbeux et par voie de conséquence impactant en termes de performance.

L'exclusion peut être implémentée de diverses manières, pour celles qui concernent les types de messages (msgtype=) elle est effectuée en appelant le paramètre exclude. À titre d'exemple, la règle suivante permet de filtrer l'ensemble des messages de type CWD (Current Working Directory) :

Ce type de règle devant être évaluée au plus vite pour éviter une analyse inutile de l'ensemble des règles de la politique, doit être placée au début du fichier audit.rules.

5. Les outils disponibles

Le framework est accompagné de plusieurs outils qui vont notamment permettre à l'administrateur de rechercher et visualiser de manière simple et rapide dans les événements d'audit afin de pouvoir détecter d'éventuelles anomalies et de les imputer aux utilisateurs responsables.

Le schéma de la figure 3 met en avant les différentes interactions possibles entre les outils disponibles :

5.1 La gestion avec auditctl

L’outil auditctl est utilisé pour contrôler, connaître le statut du démon et gérer la politique d’audit appliquée sur le système en ayant la capacité de modifier les règles définies.

L'exemple ci-dessous met en exergue la capacité de lister les règles appliquées sur le système supervisé :

5.2 La recherche avec ausearch

L’outil ausearch permet d’effectuer des recherches dans les événements d’audit générés sur le système. Il possède des capacités de filtres qui permettent de cibler facilement les événements intéressants.

Ci-dessous 2 exemples de recherches rendues possibles avec cet outil :

• recherche des événements d’audit de l'utilisateur ayant pour id 1003 :

• recherche de tous les programmes exécutés avec succès par l’utilisateur root. Dans l’exemple ci-dessous, il est notamment possible de voir que l’utilisateur root a exécuté avec succès la commande suivante : ls /etc/bash.completion.d/ :

5.3 La génération de rapports avec aureport

L'outil aureport permet de sélectionner les informations intéressantes en fonction de critères spécifiques : contexte sur des échecs d’authentification, rapport d’événement sur certains fichiers ou répertoires, etc.

Dans une optique de détection d'intrusion, l'outil propose aussi une option de recherche dans les événements anormaux (crash de programmes, cartes réseau configurées en mode promiscuous, etc.). Ces derniers sont préfixés par ANOM_ et sont listables avec l'option -n. L'exemple ci-dessous permet de voir que l'utilisateur test a exécuté la commande ifconfig afin de passer une des cartes réseau en mode promiscuous (événement ANOM_PROMISCUOUS) :

Ci-dessous les rapports concernant les événements d'authentification :

Il est aussi possible de lister les authentifications en échec :

Les outils ausearch et aureport ont la capacité de prendre en entrée des journaux au format brut, il est par conséquent possible d'effectuer une recherche sur un événement spécifique et de générer un rapport prenant en entrée les résultats de la recherche :

5.4 Le debug avec autrace

L’utilitaire autrace permet de tracer l’ensemble des appels système effectués lors de l’exécution d’un processus.

Ci-dessous un exemple des informations retournées par l'outil avec la commande /bin/hostname :

Une fois l’audit du processus finalisé, il est possible de générer un rapport spécifique à l’aide des outils auserach et aureport comme suit :

6. Un keylogger avec pam_tty_audit

Pour aller plus loin dans l'audit des événements, il est possible d'utiliser le module PAM pam_tty_audit disponible dans le paquet auditd qui permet d’enregistrer l’ensemble des frappes claviers effectuées par un ou plusieurs utilisateurs du système (y compris l’utilisateur root).

Ce module peut être utile pour répondre aux problématiques suivantes :

• être en conformité par rapport à la règlementation en vigueur (ex. PCI-DSS) ;
• auditer les actions effectuées par les administrateurs d'un système d’information sensible ;
• faciliter l’analyse forensique en cas de compromission.

6.1 Configuration

Comme la plupart des modules de PAM, pam_tty_audit est appelé et configuré dans les fichiers de configuration des modules de PAM se situant traditionnellement dans le répertoire /etc/pam.d.

Sur une distribution Debian GNU/Linux, il est ajouté au fichier /etc/pam.d/common-session. Dans l’exemple ci-dessous, le module est configuré pour enregistrer l’ensemble des frappes claviers de l’utilisateur root. Il est à noter l’utilisation de la directive open_only qui permet de prendre en charge les processus qui ne forkent pas tels que sudo :

6.2 Journaux

6.2.1  Structure

Les frappes claviers sont journalisées dans le fichier /var/log/audit/audit.log. Ces dernières sont regroupées dans le type TTY et se trouvent dans le champ data encodées en hexadécimal (le champ affiché dans l’exemple est volontairement tronqué pour des questions de lisibilité) :

6.2.2 Analyse

Il est possible d’utiliser ausearch avec l’option --tty pour visualiser les journaux d’événements générés par le module PAM. Il est possible de voir dans l'exemple ci-dessous que l’ensemble des frappes claviers sont journalisées y compris celles ne correspondant pas explicitement à une commande (par ex. la touche <Tab> utilisée pour la complétion). Les informations retournées par le shell lors d’une complétion ne sont bien entendu pas visibles dans le journal d’audit.

Dans l’exemple ci-dessus on peut deviner que l’utilisateur root a tapé les commandes suivantes :

7. Protection

7.1 Prévention de la perte de journaux

7.1.1 Politique de rétention

Afin de se prémunir de la perte des journaux d'audit, il est possible de définir une politique de rétention permettant d'en garantir le stockage sans impacts sur le système supervisé. Il est entendu que cette politique de rétention ne se substitue pas au mécanisme de déport des journaux tel que décrit dans le chapitre suivant.

Cette politique est contrôlée par les 2 paramètres suivants du fichier /etc/audit/auditd.conf :

• max_log_file : taille maximum d’un fichier de log ;
• max_log_file_action : action à effectuer en cas d’atteinte de la taille maximum du fichier.

7.1.2 Alertes

Afin de garantir la disponibilité du système supervisé, l'administrateur du système a la possibilité de définir des seuils auxquels sont associées des actions. Les seuils peuvent être définis sur des critères tels que l'occupation disque de la partition sur laquelle sont écrits les journaux d'événements.

Les 5 paramètres ci-dessous permettent d'implémenter cette politique (/etc/audit/auditd.conf) :

• space_left : taille (en Mb) à partir de laquelle la partition atteint un seuil d’occupation disque significatif ;
• space_left_action: action à effectuer sur seuil d’alerte atteint ;
• admin_space_left : taille (en Mb) à partir de laquelle la partition atteint un seuil d’occupation nécessitant des actions administratives ;
• disk_full_action : action à effectuer en cas de partition pleine ;
• disk_error_action : action à effectuer en cas de détection d’erreur lors de l’écriture des événements sur disque.

En fonction de la sensibilité du système, il peut même être configuré pour arrêter le système dans le cas où il n'est plus possible d'écrire les journaux sur le disque.

7.2 Protection de la politique d'audit

Le framework offre la possibilité de protéger le système supervisé contre toute modification de règles ou suppression accidentelle du fichier de règles lui-même. L'option -e permet de donner au fichier audit.rules l’attribut immutable. Dans ce mode de fonctionnement, la modification ou la désactivation ne sont possibles qu'après un redémarrage du poste :

8. Centralisation des journaux d'audit

La centralisation des journaux d’audit sur un serveur de collecte dédié répond à plusieurs besoins. Le premier est de garantir la disponibilité et l’intégrité des journaux en cas de compromission de tout ou partie du système d’information. Le second est d’en faciliter leur exploitation que ce soit pour les tâches d’administration courante ou les analyses forensiques en cas de compromission.

En termes de mise en œuvre, il existe deux possibilités offertes par le mécanisme de plugins :

• utiliser les capacités intrinsèques du framework ;
• utiliser les mécanismes de déport syslog.

8.1 Déport avec le plugin remote

8.1.1 Configuration du collecteur

La mise en œuvre repose sur l’utilisation du plugin audisp remote. La configuration du collecteur de journaux d'événements est relativement simple et est effectuée en modifiant le fichier de configuration /etc/audit/auditd.conf.

Pour prévenir tout risque de saturation du collecteur, il est recommandé de fixer une limite de connexions en attente tcp_listen_queue et de n'autoriser qu'une seule connexion par adresse IP cliente  (tcp_max_per_addr) :

8.1.2 Configuration des clients

Sur les postes clients, il faut simplement indiquer l’adresse IP et le port d’écoute du collecteur de logs dans le fichier de configuration /etc/audisp/audsip-remote.conf :

Et activer le plugin comme suit :

8.2 Déport avec Syslog

Ici le mécanisme de déport s'appuie sur le plugin audisp syslog. Il est nécessaire de modifier le fichier /etc/audisp/plugins.d/syslog.conf afin d’activer ce dernier et de choisir une catégorie de journaux qui permettent de les identifier et d’appliquer d’éventuels filtres pour le traitement sur le collecteur (le choix du LOG_LOCAL7 est ici totalement arbitraire) :

L'intérêt dans ce cas est de pouvoir bénéficier de l'infrastructure de collecte existante dans la grande majorité des architectures déployées en entreprise.

9. Supervision

Quel que soit le périmètre du système d'information, la supervision et la visualisation des événements sont des éléments prépondérants du maintien en condition de sécurité. Des scripts dédiés aux tableaux de bord offerts par une infrastructure de type SOC (Security Operations Center) de nombreux outils permettent de créer des représentations graphiques pertinentes pour les administrateurs et les responsables de la sécurité.

9.1 Visualisation à l'aide de scripts

L'auteur du framework propose la possibilité de visualiser les événements d'audit sous forme de graphique ou d'histogramme par le biais des scripts mkgraph et mkbar disponibles à l'adresse suivante : http://people.redhat.com/sgrubb/audit/visualize/. Quelques exemples sont disponibles sur le site pour aider à générer des visualisations à l'aide de ces scripts.

Même si ce type de visualisations permet de distinguer rapidement les éventuels événements anormaux, elles restent néanmoins circonscrites à des périmètres de recherches restreints, car elles ne passent pas à l'échelle et se révèlent totalement inutiles dans les cas de recherches complexes.

9.2 Intégration dans un SIEM

Le SIEM (Security Information and Event Management) et sa capacité d'indexation des événements d'audit permettent de répondre en partie aux problématiques soulevées dans les chapitres précédents.  

Le principal avantage du SIEM est qu'il est capable d'indexer une quantité importante de données, d'effectuer des corrélations entre différentes sources de données (ex. exécution d'un processus et requêtes HTTP analysées par un proxy d'entreprise) tout ayant la capacité de les représenter  graphiquement.

L'intégration des sources de données ne fait pas partie de cet article, mais diverses sources d'informations permettent d'aider le lecteur utilisateur de la suite Elastic [5].

La représentation graphique de la figure 4 a été créée en utilisant le SIEM Splunk (http://www.splunk.com)  et présente les capacités de représentation graphique des journaux d'audit sur une durée de plusieurs mois.

10. Limites

Chaque programme compilé avec la librairie libaudit, exécuté avec les privilèges de l'utilisateur root ou possédant les capacités CAP_AUDIT_CONTROL/CAP_AUDIT_WRITE [6] a la possibilité de communiquer avec la socket netlink dédiée. En effet, la communication avec cette dernière est possible sans restrictions ni authentification. La validation est effectuée via la fonction audit_netlink_ok()implémentée dans le fichier kernel/audit.c :

10.1 POC

Bruno Morisson, auteur d'une thèse consacrée à l'analyse technique du framework Auditd a développé un POC (Proof Of Concept) [7] permettant d'illustrer les capacités d'altération des capacités d'audit du système en mettant en avant la possibilité de stopper le processus auditd sans générer de logs susceptibles d'avertir l'administrateur du système.

10.2 Contre-mesures

Même s'il est clair qu'un attaquant possédant les privilèges root sur un système a toute latitude pour modifier ce dernier, il convient de détecter au plus tôt la compromission en utilisant les mesures suivantes :

• audit des actions effectuées par l'utilisateur root ;
• déport des journaux d'audit vers un collecteur dédié pour en garantir l'intégrité ;
• analyse des journaux à la recherche d'anomalies (par exemple, l'absence de journaux sur un intervalle de temps inhabituel).

11. Pour aller plus loin

Cet article a abordé les nombreuses possibilités offertes par le framework en termes d’audit d’un système GNU/Linux. Il est possible de le coupler avec IMA (Integrity Measurement Architecture), module du noyau intégré depuis la version 2.6.30 qui a pour objectif de mesurer l’intégrité des modules, exécutables ou librairies dynamiques à chaque chargement.

Conclusion

Nous avons pu voir tout au long de cet article que les capacités offertes par le framework Auditd permettent d'augmenter considérablement la visibilité des actions effectuées sur un système. Les possibilités offertes sont larges, que cela soit pour tracer les actions administratives ou mettre en place une surveillance fine d'un système sensible. L'écosystème logiciel est riche et permet aux administrateurs d'avoir simplement une vision synthétique de ce qui se passe sur leur système d'information. Au-delà de l'aspect prévention, les journaux d'audit permettent aussi de bénéficier d'une source de données essentielle pour l'investigation en cas de compromission.

La mise en place de ce type de solution nécessite toutefois de réfléchir en amont aux attendus, d'une part parce que la question de l'impact en termes de performance reste entière et d'autre part parce qu'il est illusoire de vouloir mettre en œuvre une politique d'audit traçant l'ensemble des activités d'un système.

Références

[1] Red Hat common critria evaluations and road map : https://www.redhat.com/f/pdf/gov/cceval_roadmap.pdf

[2] Recommandations de configuration d'un système GNU/Linux : https://www.ssi.gouv.fr/uploads/2015/10/NP_Linux_Configuration.pdf

[3] Dépôt GitHub du projet Linux Audit Documentation Project : https://github.com/linux-audit/audit-documentation/wiki

[4] Site officiel de l'outil perf : https://perf.wiki.kernel.org/index.php/Main_Page

[5] Intégration des journaux d'audit dans la suite Elastic : https://www.elastic.co/blog/brewing-in-beats-collecting-auditd-logs

[6] GRENECHE N., « Les capabilities sous Linux », GNU/Linux Magazine n°164, octobre 2013 : https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-164/Les-capabilities-sous-Linux

[7] MORISSON B., « Analysis of the Linux Audit System », avril 2015, Annexe 1 p. 53 : https://www.ma.rhul.ac.uk/static/techrep/2015/RHUL-MA-2015-13.pdf