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, 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.

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.

Quelles sont les informations qui peuvent être enregistrées dans les journaux ?

• L'horodatage et les informations sur les événements telles que le type et le résultat d'un événement.
• L'événement déclenché ainsi que l'utilisateur qui l'a déclenché.
• Modifications des fichiers de configuration de l'audit.
• Les tentatives d'accès aux fichiers journaux d'audit.
• Tous les événements d'authentification avec les utilisateurs authentifiés, tels que ssh, etc.
• Modifications des fichiers ou des bases de données sensibles telles que les mots de passe dans /etc/passwd.
• Les informations entrantes et sortantes du système.

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.

Kernel:

• audit: hooks into the kernel to capture events and deliver them to auditd

Binaries:

• auditd: daemon to capture events and store them (log file)
• auditctl: client tool to configure auditd
• audispd: daemon to multiplex events
• aureport: reporting tool which reads from log file (auditd.log)
• ausearch: event viewer (auditd.log)
• autrace: using audit component in kernel to trace binaries
• aulast: similar to last, but instaed using audit framework
• aulastlog: similar to lastlog, also using audit framework instead
• ausyscall: map syscall ID and name
• auvirt: displaying audit information regarding virtual machines

Files:

• audit.rules: used by auditctl to read what rules need to be used
• auditd.conf: configuration file of auditd

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

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

Pour démarrer auditd :

$ systemctl start auditd

Pour l'arrêt d'auditd :

$ systemctl stop auditd

Pour le redémarrage d'auditd :

$ systemctl restart auditd

Pour obtenir le statut d'auditd:

$ systemctl status auditd

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.

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

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 :

# 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

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.

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/rules.d/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.

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

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

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 ci-dessous 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 :

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

À 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

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.

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

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

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.

L'évaluation des impacts de la politique d'audit appliquée sur un système est possible avec la commande perf 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 significative 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.

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.

L'outil aureport qui sera abordé plus en détail 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.

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.

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.

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 :

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

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

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

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 ausearch 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

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.

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

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

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

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.

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.

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.

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

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.

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

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

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.

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)

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.

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

https://github.com/rbouikila/auditd

https://blog.selectel.com/auditing-system-events-linux/

https://research.securitum.com/linux-security-monitoring-auditd-ossec-integration-part-i/

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

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

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

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

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

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