I. Présentation

La norme de sécurité de l’industrie des cartes de paiement (Payment Card Industry Data Security Standard ou PCI DSS) est un standard destiné à poser les normes de la sécurité des systèmes d’information amenés à traiter et stocker des process ou des informations relatives aux systèmes de paiement.

Dans ce cadre, de nombreuses conditions sont à respecter afin d’être compatible avec cette norme. Parmi celles-ci, l’enregistrement des commandes et instructions saisies par les utilisateurs à privilèges sur un système.

Il s’agit en effet du point 10.2.2 de la version 3 de la norme PCI-DSS :

Vérifier que toutes les actions exécutées par tout utilisateur avec des droits racine ou administrateur sont consignées.

Comme l’indique ce point de la norme PCI-DSS, les comptes à privilèges sont des cibles prioritaires pour les attaquants car leur compromission accroît considérablement les possibilités de vol ou de destruction. Ainsi, avoir une trace des commandes exécutées par un compte administrateur permet, lors d’une compromission, de récupérer les actions effectuées par l’attaquant. Ne pas posséder ces informations pourrait rendre très complexe, voir impossible, la remise en état d’un système compromis.

Note : Pour plus d’informations, je vous oriente vers la dernière version en date de la norme PCI-DSS (conditions 10.2.2 à la page 98) : Industrie des cartes de paiement (PCI) Norme de sécurité des données

Hors de la norme PCI-DSS. Sauvegarder ces informations peut être très utile, en plus de la sécurité en cas d’attaque, cela permet également de retracer d’éventuelles erreurs lors de l’administration d’un système.

Vous l’aurez compris, nous allons dans ce tutoriel mettre en place une sauvegarde de toutes les commandes saisies par les utilisateurs sur un système Linux. Pour ce faire, nous utiliserons l’outil « auditd » pour l’enregistrement sur les machines. Également, nous utiliserons « rsyslog » afin d’envoyer les commandes sur un serveur distant.

Note : La configuration rsyslog sera indiquée mais non expliquée en détail, ayant déjà écrit un tutoriel à ce sujet, je vous orienterai vers celui-ci pour plus d’explication

Passons maintenant à la mise en place de cet enregistrement des commandes saisies !

II. Installation et configuration d’auditd

Nous allons donc utiliser « auditd« , un outil de sécurité sur les distributions Linux. Il permet d’effectuer une monitoring des accès aux données et au système et notamment d’effectuer un audit des logs. Un tutoriel incluant auditd a déjà été présenté sur IT-Connect, il s’agissait alors de surveiller les accès au fichier /etc/passwd. Pour l’installation sur Debian/Ubuntu, saisir la commande suivante :

apt-get install auditd

De souvenir, auditd est présent sur certaines distributions de l’univers CentOS/Fedora. Dans le doute, voici la commande d’installation :

yum install auditd

Il est possible d’avoir à ajouter les dépôts EPEL. Suite à cette installation, un répertoire « /etc/audit » permettant la configuration d’auditd est créé. Nous allons ajouter les lignes suivantes dans  /etc/auditd/audit.rules » :

-a exit,always -F arch=b64 -S execve -k root-commands
-a exit,always -F arch=b32 -S execve -k root-commands

L’option « -a » permet d’indiquer au système d’ajouter une règle.

• « -F » : permet de spécifier l’architecture et plus généralement les règles de matching avec ce que l’on veut auditer.
• « -S » : Permet de cibler certains appels systèmes. execve est l’instruction système qui permet d’exécuter un programme ou un script, par exemple « echo » qui pointe vers « /bin/echo ».
• « -k » : Permet d’ajouter un filtre à la règle d’audit. Ici nous ciblons, les données enregistrées dans les logs pourront être recherchée à l’aide du tag indiqué.

Nous pourrons ensuite redémarrer le service auditd avec la commande suivante :

service auditd restart

Pour confirmer que les règles sont bien chargées, nous pouvons utiliser la commande « auditctl -l« . Voici la sortie attendue :

Bien maintenant, nous pouvons constater que les commandes saisies sont ajoutées dans le fichier de log /var/log/audit/audit.log, voici ce que l’on peut voir après l’exécution de quelques commandes :

Ici, nous pouvons voir trois commandes saisies. Beaucoup d’informations sont affichées, nous avons ici les détails sur le contexte d’exécution, l’utilisateur, la commande exécutée, etc.

En bleu, nous pouvons voir que l’utilisateur root a exécuté la commande « ls », en vert la commande « cat » avec comme argument « /etc/passwd » et enfin en orange la commande « cat » sur « /var/log/audit/audit.log« .

auditd est un outil complet qui permet de grande customisation et de nombreuses possibilités. J’en reste néanmoins ici car mon objectif est rempli, les commandes saisies par tous les utilisateurs de mon système sont enregistrées.

III. Envoyer les logs sur un serveur distant via rsyslog

L’enregistrement des commandes, c’est fait. Que ce passe-t-il à présent si un attaquant arrive à prendre le contrôle de votre serveur (notamment les droits root) et à effacer les logs enregistrés sur votre machine ?

Il faut savoir que l’effacement des traces est une étape que les attaquant oublient rarement, la suppression des logs est à prévoir dans le cas ou votre serveur est compromis. Ainsi, il est important d’exporter vos logs en temps réel vers une autre machine à laquelle l’attaquant n’aura pas accès. Voir à plusieurs machines en fonction de la taille et de l’importance de votre système d’information.

Dans cette partie, je vous présente quelques commandes pour envoyer vos logs auditd vers un serveur rsyslog. Comme je l’ai indiqué précédemment, je ne détail que peu les commandes, un tutoriel plus détaillé est déjà présent sur IT-Connect : Centralisez vos logs avec Rsyslog

Bien, sur notre serveur rsyslog, qui est la machine destinée à recevoir les logs auditd générés, modifier le fichier /etc/rsyslog.conf en dé-commentant les lignes suivantes :

$ModLoad imudp
$UDPServerRun 514

Pour la machine cliente, les modifications suivantes sont à effectuer dans le fichier /etc/rsyslog.conf :

# auditd audit.log
$InputFileName /var/log/audit/audit.log
$InputFileTag tag_audit_log:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor

local6.* @192.168.1.22:514

Pensez à remplacer « 192.168.1.22 » par l’IP de votre serveur rsyslog.

Après redémarrage des deux services rsyslog via la commande « service rsyslog restart« , les logs auditd devraient arriver dans le fichier /etc/syslog de votre serveur rsyslog ! Vous pourrez les remarquer facilement car ils comporteront le nom de votre machine distante et non celui de votre machine locale comme habituellement.

C’est tout pour cet article, nos logs sont maintenant envoyés sur un serveur distant. Bien entendu, si un attaquant arrive à prendre le contrôle total de votre serveur, il arrivera toujours à couper l’écriture des logs ou l’envoie de données à des serveurs distant, sous conditions qu’il ai remarqué que les commandes qu’il tape sont enregistrées… Néanmoins, il est toujours possible de retracer ses premières actions et ainsi d’en savoir plus sur son mode opératoire.

Il existe d’autres outils sous Linux permettant de remplir ce rôle mais auditd me parait être l’outil libre le plus intéressant. N’hésitez pas à partager vos avis et questions dans les commentaires.