Comment utiliser le système d’audit Linux sur CentOS 7

introduction

Le système d’audit Linux aide les administrateurs système à créer une piste d’audit, un journal pour chaque action sur le serveur. Nous pouvons suivre les événements liés à la sécurité, les enregistrer dans un fichier journal et détecter les utilisations abusives ou non autorisées en inspectant les fichiers du journal d’audit. Nous pouvons choisir quelles actions sur le serveur surveiller et dans quelle mesure. Audit n’apporte pas de sécurité supplémentaire à votre système, mais permet de suivre toute violation des stratégies du système et vous permet de prendre des mesures de sécurité supplémentaires pour les prévenir.

Ce tutoriel explique le système d’audit, comment le configurer, comment générer des rapports et comment lire ces rapports. Nous verrons également comment rechercher des événements spécifiques dans les journaux d’audit.

Conditions préalables

Pour ce tutoriel, vous avez besoin des éléments suivants:

CentOS 7 Droplet (fonctionne également avec CentOS 6)
Utilisateur non root avec privilèges sudo. Pour configurer un utilisateur de ce type, suivez le tutoriel Initial Server Initial with CentOS 7. Toutes les commandes seront exécutées sous cet utilisateur.

Vérification de l’installation d’audit

Le système d’audit comporte deux parties principales:

Le composant du noyau d’audit intercepte les appels système des applications utilisateur, enregistre les événements et envoie ces messages d’audit au démon d’audit.
Le démon + auditd + `collecte les informations du noyau et crée des entrées dans un fichier journal

Le système d’audit utilise les packages suivants: + audit et` + audit-libs`. Ces packages sont installés par défaut sur un nouveau droplet CentOS 7 (et un nouveau droplet CentOS 6). Il est bon de vérifier que vous les avez installés sur votre serveur en utilisant:

sudo yum list audit audit-libs

Vous devriez voir les deux paquets sous + Installed Packages + dans la sortie:

Installed Packages
audit.x86_64
audit-libs.x86_64

Configuration de l’audit

Le fichier de configuration principal pour + auditd + est + / etc / audit / auditd.conf +. Ce fichier se compose de paramètres de configuration qui incluent où enregistrer les événements, comment traiter des disques complets et la rotation des journaux. Pour éditer ce fichier, vous devez utiliser sudo:

sudo nano /etc/audit/auditd.conf

Par exemple, pour augmenter à 10 le nombre de fichiers journaux d’audit conservés sur votre serveur, modifiez l’option suivante:

/etc/audit/auditd.conf

num_logs =

Vous pouvez également configurer la taille maximale du fichier journal en Mo et les mesures à prendre une fois la taille atteinte:

/etc/audit/auditd.conf

max_log_file =
max_log_file_action =

Lorsque vous apportez des modifications à la configuration, vous devez redémarrer le service auditd en utilisant:

sudo service auditd restart

pour que les modifications prennent effet.

L’autre fichier de configuration est + / etc / audit / rules.d / audit.rules. (Si vous utilisez CentOS 6, le fichier est à la place + / etc / audit / audit.rules +.) Il est utilisé pour ajouter de manière permanente des règles d’audit.

Lorsque + auditd + est en cours d’exécution, les messages d’audit seront enregistrés dans le fichier + / var / log / audit / audit.log +.

Comprendre les fichiers journaux d’audit

Par défaut, le système d’audit consigne les messages d’audit dans le fichier + / var / log / audit / audit.log +. Les fichiers journaux d’audit contiennent beaucoup d’informations utiles, mais la lecture et la compréhension des fichiers journaux peuvent sembler difficiles pour de nombreux utilisateurs en raison de la quantité d’informations fournies, des abréviations et des codes utilisés, etc. Dans cette section, nous allons essayer de comprendre certains des champs d’un message d’audit type dans les fichiers journaux d’audit.

Pour cet exemple, supposons qu’une règle d’audit soit configurée sur le serveur avec l’étiquette (+ key +) + sshconfigchange + pour consigner chaque accès ou modification au fichier + / etc / ssh / sshd_config +. Si vous le souhaitez, vous pouvez ajouter cette règle temporairement en utilisant:

sudo auditctl -w /etc/ssh/sshd_config -p rwxa -k sshconfigchange

L’exécution de la commande suivante pour afficher le fichier + sshd_config + crée un nouvel * événement * dans le fichier journal d’audit:

sudo cat /etc/ssh/sshd_config

Cet événement dans le fichier + audit.log + se présente comme suit:

/var/log/audit/audit.log

type=SYSCALL msg=audit(1434371271.277:135496): arch=c000003e syscall=2 success=yes exit=3 a0=7fff0054e929 a1=0 a2=1fffffffffff0000 a3=7fff0054c390 items=1 ppid=6265 pid=6266 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=113 comm="cat" exe="/usr/bin/cat" key="sshconfigchange"

type=CWD msg=audit(1434371271.277:135496):  cwd="/home/sammy"

type=PATH msg=audit(1434371271.277:135496): item=0 name="/etc/ssh/sshd_config" inode=392210 dev=fd:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 objtype=NORMAL

L’événement ci-dessus est constitué de trois enregistrements (commençant chacun par le mot-clé + type = +), partageant le même horodatage (+ 1434371271.277 +) et id (+ 135496 +). Chaque enregistrement est composé de plusieurs paires name = valeur séparées par un espace ou une virgule. Nous verrons en détail ce que certains de ces domaines représentent.

Dans le premier enregistrement:

+ type = SYSCALL +

Le champ + type + contient le type du message d’audit. Dans ce cas, la valeur + SYSCALL + indique que ce message a été déclenché par un appel système au noyau.

+ msg = audit (1434371271.277: 135496): +

L’horodatage et l’ID du message d’audit sous la forme + audit (time_stamp: ID) +. Plusieurs messages / enregistrements d’audit peuvent partager le même horodatage et le même identifiant s’ils ont été générés dans le cadre du même événement d’audit. Dans notre exemple, nous pouvons voir les mêmes horodatages (1434371271.277) et ID (135496) sur les trois messages générés par l’événement d’audit.

+ arch = c000003e +

Le champ + arch + contient des informations sur l’architecture de la CPU du système. La valeur, c000003e, est en notation hexadécimale et signifie x86_64.

+ syscall = 2 +

Le champ + syscall + indique le type de l’appel système envoyé au noyau. Dans ce cas, 2 est l’appel système + open +. L’utilitaire + ausyscall + vous permet de convertir les numéros d’appel système en leurs équivalents lisibles par l’homme. Par exemple, exécutez la commande suivante pour convertir la valeur 2 en son équivalent lisible par l’homme:

sudo ausyscall 2

La sortie montre:

open

+ succès = oui +

Le champ + success + indique si l’appel système dans cet événement particulier a réussi ou échoué. Dans ce cas, l’appel a réussi. L’utilisateur sammy a pu ouvrir et lire le fichier + sshd_config + lorsque la commande + sudo cat / etc / ssh / sshd_config + a été exécutée.

+ ppid = 6265 +

Le champ + ppid + enregistre l’ID de processus parent (PPID). Dans ce cas, + 6265 + était le PPID du processus + bash +.

+ pid = 6266 +

Le champ + pid + enregistre l’ID de processus (PID). Dans ce cas, + 6266 + était le PID du processus + cat +.

+ auid = 1000 +

+ auid + est l’UID d’audit ou l’UID d’origine de l’utilisateur qui a déclenché ce message d’audit. Le système d’audit gardera en mémoire votre UID d’origine même si vous élevez des privilèges via su ou sudo après la connexion initiale.

+ uid = 0 +

Le champ + uid + enregistre l’ID utilisateur de l’utilisateur qui a démarré le processus analysé. Dans ce cas, la commande + cat + a été lancée par l’utilisateur root avec l’uid 0.

+ comm =" cat "+

+ comm + enregistre le nom de la commande qui a déclenché ce message d’audit.

+ exe =" / usr / bin / cat "+

Le champ + exe + enregistre le chemin d’accès à la commande utilisée pour déclencher ce message d’audit.

+ key =" ssh config change "+

Le champ + key + enregistre la chaîne définie par l’administrateur associée à la règle d’audit qui a généré cet événement dans le journal. Les clés sont généralement définies lors de la création de règles d’audit personnalisées pour faciliter la recherche de certains types d’événements à partir des journaux d’audit.

Pour le deuxième disque:

+ type = CWD +

Dans le deuxième enregistrement, le type est + CWD + - Répertoire de travail actuel. Ce type est utilisé pour enregistrer le répertoire de travail à partir duquel le processus qui a déclenché l’appel système spécifié dans le premier enregistrement a été exécuté.

+ cwd =" / home / sammy "+

Le champ + cwd + contient le chemin du répertoire à partir duquel l’appel système a été appelé. Dans notre cas, la commande + cat + qui a déclenché le syscall + open + du premier enregistrement a été exécutée à partir du répertoire + / home / sammy +.

Pour le troisième enregistrement:

+ type = PATH +

Dans le troisième enregistrement, le type est + PATH +. Un événement d’audit contient un enregistrement + PATH + pour chaque chemin transmis à l’appel système en tant qu’argument. Dans notre événement d’audit, un seul chemin (+ / etc / ssh / sshd_config +) a été utilisé comme argument.

+ msg = audit (1434371271.277: 135496): +

Le champ + msg + indique les mêmes combinaisons d’horodatage et d’identité que dans les premier et deuxième enregistrements, étant donné que les trois enregistrements font partie du même événement d’audit.

+ name =" / etc / ssh / sshd_config "+

Le champ + name + enregistre le chemin d’accès complet du fichier ou du répertoire transmis à l’appel système (open) en tant qu’argument. Dans ce cas, il s’agissait du fichier + / etc / ssh / sshd_config +.

+ ouid = 0 +

Le champ + ouid + enregistre l’ID utilisateur du propriétaire de l’objet. Ici, l’objet est le fichier + / etc / ssh / sshd_config.

Recherche dans les journaux d’audit d’événements

Le système d’audit Linux est livré avec un outil puissant appelé + ausearch + pour la recherche de journaux d’audit. Avec + ausearch +, vous pouvez filtrer et rechercher des types d’événements. Il peut également interpréter des événements pour vous en traduisant des valeurs numériques en valeurs lisibles par l’homme, telles que les appels système ou les noms d’utilisateur.

Voyons quelques exemples.

La commande suivante va rechercher dans les journaux d’audit tous les événements d’audit du type LOGIN à partir d’aujourd’hui et interpréter les noms d’utilisateur.

sudo ausearch -m LOGIN --start today -i

La commande ci-dessous recherche tous les événements portant l’ID d’événement 27020 (à condition qu’un événement portant cet identifiant soit présent).

sudo ausearch -a 27020

Cette commande recherchera tous les événements (le cas échéant) touchant le fichier + / etc / ssh / sshd_config + et les interprétera:

sudo ausearch -f /etc/ssh/sshd_config -i

Générer des rapports d’audit

Au lieu de lire les journaux d’audit bruts, vous pouvez obtenir un résumé des messages d’audit à l’aide de l’outil + aureport +. Il fournit des rapports dans un format lisible par l’homme. Ces rapports peuvent être utilisés comme éléments de base pour une analyse plus complexe. Lorsque + aureport + est exécuté sans aucune option, un résumé des différents types d’événements présents dans les journaux d’audit apparaît. Utilisé avec les options de recherche, il affichera la liste des événements correspondant aux critères de recherche.

Essayons quelques exemples pour + aureport +. Si vous souhaitez générer un rapport de synthèse sur toutes les exécutions de commandes sur le serveur, exécutez:

sudo aureport -x --summary

La sortie ressemblera à ceci avec des valeurs différentes:

Executable Summary Report
=================================
total  file
=================================
117795  /usr/sbin/sshd
1776  /usr/sbin/crond
210  /usr/bin/sudo
141  /usr/bin/date
24  /usr/sbin/autrace
18  /usr/bin/su

La première colonne indique le nombre de fois que la commande a été exécutée et la deuxième colonne indique la commande exécutée. Veuillez noter que toutes les commandes ne sont pas journalisées par défaut. Seuls ceux liés à la sécurité sont enregistrés.

La commande suivante vous donnera les statistiques de tous les événements ayant échoué:

sudo aureport --failed

La sortie ressemble à:

Failed Summary Report
======================
Number of failed logins: 11783
Number of failed authentications: 41679
Number of users: 3
Number of terminals: 4
Number of host names: 203
Number of executables: 3
Number of files: 4
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 9

Pour générer un rapport sur les fichiers consultés avec les appels système et les noms d’utilisateur:

sudo aureport -f -i

Exemple de sortie:

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. Monday 15 June 2015 08:27:51 /etc/ssh/sshd_config open yes /usr/bin/cat sammy 135496
2. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147481
3. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config lgetxattr yes /usr/bin/ls root 147482
4. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147483
5. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147484
6. Tuesday 16 June 2015 05:40:08 /bin/date execve yes /usr/bin/date root 148617

Pour visualiser la même chose au format résumé, vous pouvez exécuter:

sudo aureport -f -i --summary

Analyse d’un processus à l’aide de autrace

Pour auditer un processus individuel, nous pouvons utiliser l’outil + autrace +. Cet outil retrace les appels système effectués par un processus. Cela peut être utile pour enquêter sur un cheval de Troie suspecté ou sur un processus problématique. Le résultat de + autrace + est écrit dans + / var / log / audit / audit.log + et ressemble aux entrées standard du journal d’audit. Après exécution, + autrace + vous présentera un exemple de commande + ausearch + pour examiner les journaux. Utilisez toujours le chemin complet du binaire à suivre avec autrace, par exemple + sudo autrace / bin / ls / tmp +.

Essayons un exemple, disons, nous voulons suivre le processus + date + et afficher les fichiers et les appels système utilisés par celui-ci. Exécutez ce qui suit:

sudo autrace /bin/date

Vous devriez voir quelque chose de similaire au suivant:

Waiting to execute: /bin/date
Wed Jun 17 07:22:03 EDT 2015
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 27020'

Vous pouvez utiliser la commande + ausearch + à partir de la sortie ci-dessus pour afficher les journaux associés ou même la transmettre à + aureport + pour obtenir une sortie lisible par un humain bien formatée:

sudo ausearch -p 27020 --raw | aureport -f -i

Cette commande recherche l’événement portant l’ID d’événement + 27020 + dans les journaux d’audit, l’extrait au format de journal brut et le transmet à + aureport +, qui interprète et donne les résultats dans un meilleur format pour une lecture plus facile. .

Vous devriez voir une sortie similaire à celle-ci:

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. Wednesday 17 June 2015 07:22:03 /bin/date execve yes /usr/bin/date sammy 169660
2. Wednesday 17 June 2015 07:22:03 /etc/ld.so.preload access no /usr/bin/date sammy 169663
3. Wednesday 17 June 2015 07:22:03 /etc/ld.so.cache open yes /usr/bin/date sammy 169664
4. Wednesday 17 June 2015 07:22:03 /lib64/libc.so.6 open yes /usr/bin/date sammy 169668
5. Wednesday 17 June 2015 07:22:03 /usr/lib/locale/locale-archive open yes /usr/bin/date sammy 169683
6. Wednesday 17 June 2015 07:22:03 /etc/localtime open yes /usr/bin/date sammy 169691

Conclusion

Nous avons présenté les bases du système d’audit Linux dans ce tutoriel. Vous devez maintenant bien comprendre le fonctionnement du système d’audit, comment lire les journaux d’audit et les différents outils disponibles pour faciliter l’audit de votre serveur.

Par défaut, le système d’audit n’enregistre que quelques événements dans les journaux, tels que les utilisateurs qui se connectent et ceux qui utilisent sudo. Les messages relatifs à SELinux sont également enregistrés. Le démon d’audit utilise des règles pour surveiller des événements spécifiques et créer des entrées de journal associées. Il est possible de créer des règles d’audit personnalisées pour surveiller et enregistrer dans les journaux tout ce que nous voulons. C’est là que le système d’audit devient puissant pour un administrateur système. Nous pouvons ajouter des règles à l’aide de l’outil de ligne de commande + auditctl + ou de manière permanente dans le fichier + / etc / audit / rules.d / audit.rules +. L’écriture de règles personnalisées et l’utilisation d’ensembles de règles prédéfinis sont décrites en détail dans les Writing Custom Audit System Rules on CentOS 7 tutoriel.

Vous pouvez également consulter les ressources suivantes pour obtenir encore plus d’informations sur le système d’audit:

TOC