Journalisez les actions de vos utilisateurs avec Auditd

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
93
Mois de parution
novembre 2017
Spécialité(s)


Résumé

Au-delà de la tendance à la journalisation et l'audit à tous crins, de nombreuses règlementations imposent de tracer les actions réalisées par les utilisateurs d'un système. Le framework Auditd, disponible nativement sur la majeure partie des distributions GNU/Linux, permet de répondre à ces exigences en surveillant les activités d'un système. Il permet de générer des journaux d'événements afin d’enregistrer des informations sur les différentes activités qui rythment la vie d'un système, des accès aux fichiers en passant par les processus exécutés par des administrateurs.


Body

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.

Anatomie_du_framework_Auditd_figure_01

Fig. 1 : Présentation des composants du framework Audit.

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 :

$ sudo apt-get install 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) :

type=SYSCALL msg=audit(1499674671.167:1807): arch=c000003e syscall=2 success=yes exit=3 a0=7fffcf9b38a9 a1=0 a2=0 a3=7fffcf9b2690 items=1 ppid=1031 pid=1032 auid=1003 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4 comm="tail" exe="/usr/bin/tail" key=(null)

type=PATH msg=audit(1499674671.167:1807): item=0 name="/var/log/audit/audit.log" inode=389001 dev=fe:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL

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] :

# Exécution de insmod,rmmod et modprobe

-w /sbin/insmod -p x -k audit_modules

-w /sbin/modprobe -p x -k audit_modules

-w /sbin/rmmod -p x -k audit_modules

 

# Journaliser les modifications dans /etc/

-w /etc/ -p wa -k audit_conf

# Surveillance de montage/démontage

-a exit,always -S mount -S umount2 -k audit_mount

# Appels de syscalls x86 suspects

-a exit,always -S ioperm -S modify_ldt -k audit_syscall

# Appels de syscalls qui doivent être rares et surveillés de près

-a exit,always -S get_kernel_syms -S ptrace -S prctl -k audit_syscall

# Rajout du monitoring pour la création ou suppression de fichiers

-a exit,always -F arch=b64 -S unlink -S rmdir -S rename –k audit_files

-a exit,always -F arch=b64 -S creat -S open -S openat -F exit=-EACCESS –k audit_files

-a exit,always -F arch=b64 -S truncate -S ftruncate -F exit=-EACCESS –k audit_files

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 :

# Kernel panic

-f 2

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/) :

-w /etc/ -p wa -k audit_conf

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 :

Anatomie_du_framework_Auditd_figure_02

Fig. 2 : Traitement des appels système.

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

-a exit,always -S get_kernel_syms -S ptrace -S prctl -k audit_syscall

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.

# Appels de syscalls x86 suspects

-a exit,always -S ioperm -S modify_ldt -k audit_syscall

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) :

type=SYSCALL msg=audit(1480270680.382:705): arch=c000003e syscall=263 success=yes exit=0 a0=ffffffffffffff9c a1=250e0c0 a2=0 a3=0 items=2 ppid=3342 pid=3577 auid=1003 uid=1003 gid=1003 euid=1003 suid=1003 fsuid=1003 egid=1003 sgid=1003 fsgid=1003 tty=pts1 ses=7 comm="rm" exe="/bin/rm" key="audit_file_delete"

type=CWD msg=audit(1480270680.382:705): cwd="/home/test"

type=PATH msg=audit(1480270680.382:705): item=1 name="test" inode=130565 dev=fe:02 mode=0100644 ouid=1003 ogid=1003 rdev=00:00

type=PATH msg=audit(1480270680.382:705): item=0 name="/home/test" inode=130561 dev=fe:02 mode=040755 ouid=1000 ogid=1000 rdev=00:00

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

-a exit,always -S unlink -S unlinkat -S rename -S renameat -k audit_file_delete

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.

Un ensemble des règles prédéfinies est disponible pour différents standards de certifications tels que PCI-DSS (norme de sécurité de l'industrie des cartes de paiement) ou des profils de protection issus des critères communs (LSPP). Ces dernières sont accessibles dans le répertoire /usr/share/doc/auditd/examples/.

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 :

Samples: 272K of event 'block:block_rq_issue', Event count (approx.): 272098

+ 33.11% 33.11% auditd [kernel.kallsyms] [k] blk_peek_request

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é) :

$ sudo aureport -i -k –summary | head

Key Summary Report

===========================

total  key

===========================

12058  root_cmd

4179  audit_time

1247  audit_session

742  audit_config

633  audit_gestion_compte

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) :

-a exit,always -F path=/bin/su -F perm=x -F auid=1003 -k audit_binaries

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) :

-a exclude,always -F msgtype=CWD

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 :

Anatomie_du_framework_Auditd_figure_03

Fig. 3 : Composants et interfaces entre les différents composants framework Auditd.

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é :

$ sudo auditctl -l

-w /etc/audit/ -p wa -k audit_config

-w /etc/libaudit.conf -p wa -k audit_config

-w /etc/audisp/ -p wa -k audit_config

-w /sbin/auditctl -p x -k audit_tools

-w /sbin/auditd -p x -k audit_tools

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 :

$ sudo ausearch -ui 1003

time->Mon Jul 10 10:16:44 2017

type=PROCTITLE msg=audit(1499674604.807:1562): proctitle="su"

type=PATH msg=audit(1499674604.807:1562): item=1 name=(null) inode=1021 dev=fe:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL

type=PATH msg=audit(1499674604.807:1562): item=0 name="/bin/su" inode=259601 dev=fe:00 mode=0104755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL

type=EXECVE msg=audit(1499674604.807:1562): argc=1 a0="su"

type=BPRM_FCAPS msg=audit(1499674604.807:1562): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=0000003fffffffff new_pi=0000000000000000 new_pe=0000003fffffffff

type=SYSCALL msg=audit(1499674604.807:1562): arch=c000003e syscall=59 success=yes exit=0 a0=ce12e8 a1=ce14c8 a2=dbf008 a3=7fff1ce78bc0 items=2 ppid=988 pid=997 auid=1003 uid=1003 gid=1003 euid=0 suid=0 fsuid=0 egid=1003 sgid=1003 fsgid=1003 tty=tty1 ses=2 comm="su" exe="/bin/su" key="root_cmd"

  • 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/ :

$ sudo ausearch –-uid 0 --syscall EXECVE –success yes -i

----

type=PROCTITLE msg=audit(05/04/2017 16:37:09.528:1594) : proctitle=ls

type=PATH msg=audit(05/04/2017 16:37:09.528:1594) : item=1 name=(null) inode=1021 dev=fe:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL

type=PATH msg=audit(05/04/2017 16:37:09.528:1594) : item=0 name=/bin/ls inode=261019 dev=fe:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL

type=EXECVE msg=audit(05/04/2017 16:37:09.528:1594) : argc=2 a0=ls a1=/etc/bash_completion.d

type=SYSCALL msg=audit(05/04/2017 16:37:09.528:1594) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x1f52168 a1=0x1f5df48 a2=0x2047008 a3=0x7ffd95f13860 items=2 ppid=1433 pid=1434 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=tty1 ses=6 comm=ls exe=/bin/ls key=root_cmd

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) :

$ sudo aureport -n -i

 

Anomaly Report

=========================================

# date time type exe term host auid event

=========================================

1. 07/10/2017 10:46:26 ANOM_PROMISCUOUS/sbin/ifconfig pts1 ? test 3134

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

$ sudo aureport -au

100. 05/04/2017 16:37:09 root ? /dev/tty1 /bin/login yes 1577

101. 05/06/2017 15:34:51 root 192.168.139.1 ssh /usr/sbin/sshd no 993

102. 05/06/2017 15:36:19 test ? /dev/pts/0 /bin/su yes 1017

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

$ sudo aureport --login --failed

Login Report

============================================

# date time auid host term exe success event

============================================

1. 04/03/2017 13:43:55 root ? /dev/tty1 /bin/login no 1586

2. 05/04/2017 16:37:04 root ? /dev/tty1 /bin/login no 1575

3. 05/06/2017 15:25:48 root ? /dev/tty1 /bin/login no 789

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 :

$ sudo ausearch --event 1000 --raw | aureport -s -i

Syscall Report

=======================================

# date time syscall pid comm auid event

=======================================

1. 03/28/2017 12:06:50 openat 1253 mandb root 1000

2. 03/29/2017 16:33:13 open 868 bash root 1000

3. 03/29/2017 22:01:23 open 886 bash root 1000

4. 03/31/2017 16:03:12 execve 1013 sleep unset 1000

5. 04/03/2017 10:33:54 execve 952 tput root 1000

6. 04/03/2017 14:16:51 execve 3926 update-rc.d root 1000

7. 04/03/2017 15:23:44 execve 3420 chgrp root 1000

8. 04/26/2017 23:37:21 execve 1054 tail root 1000

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 :

$ sudo autrace /bin/hostname

Waiting to execute: /bin/hostname

audit

Cleaning up...

Trace complete. You can locate the records with 'ausearch -i -p 1717'

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 :

$ sudo ausearch -p 1717 --raw | aureport -f -i

File Report

===============================================

# date time file syscall success exe auid event

===============================================

1. 05/22/2017 15:17:55 /bin/hostname execve yes /bin/hostname root 682

2. 05/22/2017 15:17:55 /etc/ld.so.nohwcap access no /bin/hostname root 684

3. 05/22/2017 15:17:55 /etc/ld.so.preload access no /bin/hostname root 686

4. 05/22/2017 15:17:55 /etc/ld.so.cache open yes /bin/hostname root 687

5. 05/22/2017 15:17:55 /etc/ld.so.nohwcap access no /bin/hostname root 691

6. 05/22/2017 15:17:55 /lib/x86_64-linux-gnu/libnsl.so.1 open yes /bin/hostname root 692

7. 05/22/2017 15:17:55 /etc/ld.so.nohwcap access no /bin/hostname root 700

8. 05/22/2017 15:17:55 /lib/x86_64-linux-gnu/libc.so.6 open yes /bin/hostname root 701

L’utilisation d’autrace entraîne la suppression temporaire de l’ensemble des règles « maison ». À la fin de son exécution, les règles temporaires sont supprimées pour éviter toute interférence avec la politique d’audit mise en œuvre. C’est aussi pour cette raison que l’outil ne peut fonctionner lorsque les règles sont marquées comme immutables.

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 :

$ sudo cat etc/pam.d/common-session | grep pam_tty_audit

session required pam_tty_audit.so disable=* enable=root open_only

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é) :

type=TTY msg=audit(1494104091.451:464): tty pid=893 uid=0 auid=0 ses=1 major=136 minor=0 comm="bash" data=6C73202F0D7461696C202F7661096C6F670961750

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.

65. 05/06/2017 22:54:51 464 root ? 1 bash "ls /",<ret>,"tail /va",<tab>,"log",<tab>,"au",<tab>,"d",<tab>,"au",<tab>,<ret>,<up>,<backspace>,<backspace>,<backspace>,<backspace>,<backspace>,<backspace>,<backspace>,<backspace>,<backspace>,<tab>,<tab>,<tab>,<backspace>,<backspace>,<backspace>,<tab> ,<tab>,<tab>,<ret>,<up>,<down>,<ret>,"shu",<tab>,"t",<tab>,"- ",<backspace>,"h now",<ret>

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

- ls /

- tail /var/log/audit/audit.log

- shutdown –h now

Il convient d'évaluer la pertinence d'utiliser cette fonctionnalité dans des contextes où il n'est pas obligatoire de tracer l'ensemble des actions effectuées par les administrateurs, car son activation peut impacter le système en termes de performances et les journaux générés se révèlent difficiles à analyser.

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 :

# Verrouillage de la configuration de auditd

-e 2

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) :

$ sudo vi /etc/audit/auditd.conf

tcp_listen_port = 515

tcp_listen_queue = 50

tcp_max_per_addr = 1

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 :

$ sudo vi /etc/audisp/audisp-remote.conf

remote_server = <adresse IP du collecteur de logs>

port = 515

transport = tcp

Et activer le plugin comme suit :

$ sudo vi /etc/audisp/plugins.d/au-remote.conf

active = yes

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) :

$ sudo vi /etc/audisp/plugins.d/syslog.conf

active = yes

direction = out

path = builtin_syslog

type = builtin

format = string

args = LOG_LOCAL7

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.

Anatomie_du_framework_Auditd_figure_04

Fig. 4 : Timeline de la répartition des appels système journalisés sur la VM de test.

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 :

/*

 * Check for appropriate CAP_AUDIT_ capabilities on incoming audit

 * control messages.

 */

static int audit_netlink_ok(struct sk_buff *skb, u16 msg_type)

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.

Merci aux relecteurs du Service des Technologies de l’Information et de la Communication (Direction de l’Énergie Nucléaire, CEA Cadarache) avec une mention particulière pour Jean-Philip et ses conseils avisés.

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

 



Article rédigé par

Par le(s) même(s) auteur(s)

Collecte de logs d’installations industrielles isolées

Magazine
Marque
MISC
Numéro
100
Mois de parution
novembre 2018
Spécialité(s)
Résumé

La mise en place d’un SOC est un projet bien moins technique qu’organisationnel. Dans le cadre de la supervision sécurité d’installations industrielles isolées, la collecte de logs peut cependant présenter quelques spécificités techniques qu’il semble intéressant d'aborder dans cet article.Les postes de supervision et les serveurs de contrôle-commande constituant un point d'entrée important vis-à-vis d'une malveillance informatique sur un système industriel, leurs journaux systèmes représentent une source d'informations intéressante à collecter. L'article propose un retour d'expérience sur la mise en œuvre d'une infrastructure de collecte des journaux Windows et de leurs transferts vers un SOC, dans le respect d'une exigence d'isolation.

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous