AIDE : Utilisation et configuration d’une solution de contrôle d’intégrité sous Linux

I. Présentation

Dans ce tutoriel, nous allons apprendre à utiliser la solution AIDE (Advanced Intrusion Detection Environment). Il s'agit d'une solution de détection des intrusions basée sur les modifications apportées au système surveillé. Ce type de solution est également appelée solution de contrôle d'intégrité ou de scellement, elle vise à s'assurer qu'un ensemble d'éléments de notre système n'ont pas été modifiés, ce qui pourrait être le fruit d'une intrusion. Par intrusion, on entends bien entendu une attaque informatique qui résulterait en la compromission d'un service ou d'un serveur, cela peut alors entraîner la compromission de données, la réalisation d'actes de sabotage, la propagation d'une compromission à d'autres actifs, l’implantation durable sur le serveur compromis, etc.

Note : Il existe bon nombre de façon de détecter des intrusions grâce aux IDS (Intrusion Detecte System), certaines solutions se basent sur les journaux d’événements (appelées Log-based IDS), d'autres sur l'analyse en directe du réseau (Network-based IDS). D'autres solutions permettent elles d'effectuer automatiquement des actions de blocage ou de correction (bloquer une IP, désactiver un utilisateur, etc.) ont appelle ces solutions des IPS (Intrusion Prevention System).

Bref, nous allons aujourd'hui installer la solution AIDE, étudier son fonctionnement basique et sa configuration. Nous irons jusqu'à adapter sa configuration pour prendre en compte un nouveau service et voir comment un attaquant pourrait se faire détecter. C'est loin d'être aussi compliqué que ça en à l'air 🙂

Le code source de la solution est disponible sur Github : https://github.com/aide/aide. On peut notamment constater que des mises à jour y sont apportées fréquemment grâce à la partie commit : https://github.com/aide/aide/commits/master

Pour décrire le fonctionnement de la solution AIDE en quelques mots, elle va prendre une signature (sous forme de hash) des fichiers et dossiers que nous souhaitons surveiller et ensuite, pour chaque nouvelle vérification, comparer cette signature modèle à celle des fichiers analysés.

II. Installation et première utilisation

Dans le cadre de ce tutoriel, j'installe la solution AIDE sur une machine CentOS 8.1 à jour. La version d'AIDE utilisée est la version 0.16. On commence naturellement par récupérer les dernières versions des listes de paquet dans les dépôts :

[root@localhost ~]# yum update

Puis on installe la solution AIDE avec la commande suivante :

[root@localhost ~]# yum install aide

La configuration principale de la solution AIDE se situe dans /etc/aide.conf. Y jeter un œil vous fera certainement renoncer à l'utiliser (à tord, encore une fois ce n'est pas si compliqué). Nous n'allons donc pour l'instant pas nous y intéresser. Comme indiqué précédemment, la solution AIDE se base sur l'utilisation d'une base de données (ou base de signature pour être plus exact) contenant toutes les signatures (les hash, permettant le contrôle d'intégrité) des fichiers et dossiers à surveiller. Il nous est donc nécessaire dans un premier temps d'initialiser cette base (d'en créer une première version). Assurez vous d'abord d'avoir un système proche de son état "final" :

  • Les applications métiers sont installées
  • Les utilisateurs principaux sont créés
  • Les durcissement et outils de sécurité, de sauvegarde, de supervision sont installés également
  • etc.

Bien sur, un système est vivant et bougera sans cesse, par exemple lors des mises à jour. Nous verrons comment traiter ces exceptions ou ces événements un peu plus tard. Donc, l'initialisation de cette première version de base de signature se fait grâce à la commande suivante :

[root@localhost ~]# aide --init

L'opération peut prendre quelques minutes (longues minutes si vous avez un système conséquent avec de nombreux fichiers) :

[root@localhost ~]# aide --init
Start timestamp: 2020-01-18 06:41:01 -0500 (AIDE 0.16)
AIDE initialized database at /var/lib/aide/aide.db.new.gz

Number of entries:      36025

---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------

/var/lib/aide/aide.db.new.gz
  MD5      : eyc+BLDzD6Xu4N0OkQojqg==
  SHA1     : BuC3W6z+Rthf5J7OXd7n03rKMUI=
  RMD160   : DPDgQUNEbZQ8lX9qd1x+AYKWjJA=
  TIGER    : CxJ0hk3cjH5BIL9Qu34q25wNsfvRCTqr
  SHA256   : q0gCBj+Gvwvq/AFQy4HV1Jk8g/VvufxzO4blRuhtark=
  SHA512   : puNw9AWyDIHkizRVUQ5vPnT5ZNaei1fQR75ruxSFZy2OMaBLvErXt/+4JDYNHXflqE3PEGgktfqKzIQ3HzwiGg==
End timestamp: 2020-01-18 06:41:09 -0500 (run time: 0m 8s)

Bien, cet affichage nous donne plusieurs informations, notre base de signature est positionnée dans /var/lib/aide/aide.db.new.gz, ensuite, les hashs (ou empreintes) de cette base de signature nous sont fournis et calculés avec plusieurs algorithmes de hashage. Cela afin d'être certains qu'aucune collision de hash (avoir le même hash pour des données différentes), n'est exploitée. Dans sa configuration par défaut, la base de signature du fichier /var/lib/aide/aide.db.gz est utilisée, les bases de signature nouvellement générées sont nommées /var/lib/aide/aide.db.new.gz comme nous venons de le voir. Il nous faut donc renommer ce fichier pour qu'AIDE retrouve ses petits :

mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Dans l'utilisation courante, on peut comprendre ce fonctionnement, il serait périlleux de remplacer la base de signature en cours d'utilisation, avoir un fichier différents pour les nouvelles bases de signature (estampillé "new") permet également de faire des comparatifs entre bases de signature, voire de l'archivage.

A présent, nous pouvons effectuer une première comparaison entre l'état enregistré de nos fichiers dans la base de signature et leur état actuel grâce à la l'option --check :

[root@localhost ~]# aide --check

L'opération d'AIDE est ici simple, pour chaque fichier contenu dans les dossiers et liste de fichier à vérifier, il recalcule un hash, regarde si cet objet est présent dans la base de signature, et compare les signatures :

  • Si la signature de l'objet n'est pas présente dans la base de signature, il s'agit d'un nouvel objet (dossier ou fichier) : on lève une alerte
  • Si la signature de l'objet est présente dans la base de signature et que les signatures sont identiques: tout est OK, l'intégrité de l'objet est vérifiée
  • Si la signature de l'objet est présente dans la base de signature et que les signatures ne sont pas identiques : on lève une alerte, le fichier a été modifié

Voici le résultat que j’obtiens dans le cadre de mes tests :

[root@localhost ~]# aide --check
Start timestamp: 2020-01-18 06:48:33 -0500 (AIDE 0.16)
AIDE found NO differences between database and filesystem. Looks okay!!

Number of entries: 36025

Pour vous montrer les types d'alertes émises lorsqu'une modification est détectée, nous allons ajouter un nouvel utilisateur dans le fichier /etc/passwd, qui est par défaut surveillé par AIDE, puis nous rééxécutons notre vérification d'intégrité :

[root@localhost ~]# useradd john
[root@localhost ~]# aide --check
Start timestamp: 2020-01-18 06:49:28 -0500 (AIDE 0.16)
AIDE found differences between database and filesystem!!

Summary:
Total number of entries: 36027
Added entries: 2
Removed entries: 0
Changed entries: 6

---------------------------------------------------
Added entries:
---------------------------------------------------

f++++++++++++++++: /etc/subgid-
f++++++++++++++++: /etc/subuid-

---------------------------------------------------
Changed entries:
---------------------------------------------------

f ... .C... : /etc/group
f ... .C... : /etc/gshadow
f ... .C... : /etc/passwd
f ... .C... : /etc/shadow
f ... .C... : /etc/subgid
f ... .C... : /etc/subuid

---------------------------------------------------
Detailed information about changes:
---------------------------------------------------

File: /etc/group
SHA512 : /P+yN4HGkIvuo1DbsQgfjNwpS3pfe8h1 | 1+fVfheMQ3PhIebOxtyd6dICGkpBcMZT
pHWVLZPGdzhyIcjMUi6VpZFFrYsrUrHA | f3FFiUe3MxqXroYFuMlO54V06V+zMjFyb1Rcx9Aa6//3GKggOQJVWw== | fF69GpxbTiAzsWMXckAU8Q==

File: /etc/gshadow
SHA512 : 9Ii[...]27x3Omnwr9AA==

File: /etc/passwd
SHA512 : khP[...]2KYOE1A==

File: /etc/shadow
SHA512 : Bg[...]R0w==

File: /etc/subgid
SHA512 : z4PhNX[...]TNpCg==

File: /etc/subuid
SHA512 : z4PhN[...]NpCg==

J'ai volontairement tronqué les hash des fichiers par soucis de lisibilité dans l'article. Nous voyons ici que la réponse est différente, la section "Changed entries:" contient notamment une liste de fichiers. Si l'on s'intéresse au processus d'ajout d'un utilisateur, on remarquera que ce sont les fichiers concernés lorsque l'on créé un utilisateur :

  • /etc/passwd contient la liste des utilisateurs du système et d'autres informations (leur home, leur description);
  • /etc/shadow contient les hash de mots de passe des utilisateurs;
  • /etc/group contient la liste des groupes et leur membres, lorsque l’on créé un nouvel utilisateur, un groupe à son nom est automatiquement créé;
  • etc.

En étant un peu plus attentif, nous pouvons également savoir ce qui a vraiment changé dans le fichier, est-ce sa taille, son contenu, les permissions qui lui sont affectées, les liens symboliques le concernant ? Exemple avec la ligne suivante :

f ... .C... : /etc/group;

Ici, le f indique que l'objet concerné est un fichier. Si l'on jette un œil au manuel de configuration d'AIDE (ici : manpage AIDE), on trouve l'information suivante :

manpage de la configuration AIDE
Extrait de la manpage de la configuration AIDE

C'est le checksum (le hash, ou empreinte) du fichier qui a changé. Le C indique donc que c'est son contenu qui a été modifié. Maintenant que nous avons une vue sur ce qui a été modifié, il faut en faire quelque chose : investiguer.

L'objectif du contrôle d'intégrité et de s'assurer que rien n'a été modifié se notre système, toute alerte doit donc être traitée :

  • C'est une modification légitime, aucun problème, je sais pourquoi AIDE me lève une alerte;
  • Ce n'est pas une modification légitime : cela peut trahir la présence d'un attaquant.

A présent, il faut que l'on prenne en compte cette nouvelle base de signature, nous en produisons donc une nouvelle version et remplaçons l'ancienne base avec la nouvelle :

[root@localhost ~]# aide --update
[root@localhost ~]# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
mv : voulez-vous écraser '/var/lib/aide/aide.db.gz' ? o

Note : AIDE n'est pas logiciel de sauvegarde, il ne vous permettra pas d'effectuer une restauration en l'état des fichiers modifiés. Les alertes qu'il émet doivent donc être traitées, et les modifications de signature acceptées après avoir été évaluées (après avoir remis les objets modifiés dans un état maîtrisé si les modifications ne sont pas légitimes).

Faisons un nouveau test avec la modification d'un autre attribut, par exemple les permissions affectées à un fichier. Dans le cadre du test, je modifie les permissions du fichier /etc/passwd (à ne pas faire en conditions réelles bien entendu) :

[root@localhost ~]# ls -al /etc/passwd
-rw-r--r--. 1 root root 1119 18 janv. 06:49 /etc/passwd
[root@localhost ~]# chmod 777 /etc/passwd
[root@localhost ~]# ls -al /etc/passwd
-rwxrwxrwx. 1 root root 1119 18 janv. 06:49 /etc/passwd
# Pour revenir à l'état initial : chmod 644 /etc/passwd

[root@localhost ~]# aide --check
Start timestamp: 2020-01-18 07:15:23 -0500 (AIDE 0.16)
AIDE found differences between database and filesystem!!

Summary:
  Total number of entries:      36027
  Added entries:                0
  Removed entries:              0
  Changed entries:              1

---------------------------------------------------
Changed entries:
---------------------------------------------------
f   p..    ..A.. : /etc/passwd

---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /etc/passwd
  Perm     : -rw-r--r--                       | -rwxrwxrwx
  ACL      : A: user::rw-                     | A: user::rwx
             A: group::r--                    | A: group::rwx
             A: other::r--                    | A: other::rwx

Nous avons ici une alerte concernant le fichier /etc/passwd avec comme attribut ..A... Si l'on regarde dans l'extrait de la manpage de configuration AIDE exposé plus haut, on remarque que cette alerte concerne bien les permissions d'accès à l'objet qui ont été modifiées. La section "Detailed information about changes:" nous indique quel était l'état initial des permissions des fichiers, il peut retrouver cette information à partir de sa base de signature initiale avec laquelle il compare la base de signature produite.

Nous savons à présent réaliser les opérations nécessaires à l'utilisation d'AIDE et notamment comprendre ce qu'il peut bien nous raconter au travers différents types d'alertes.

III. Utilisation quotidienne

En conditions réelles, notamment en environnement professionnel, l'implémentation d'AIDE doit être un projet à part entière car il ne suffit pas de l'installer pour que vos serveurs deviennent invulnérables, plusieurs difficultés doivent être anticipées :

  • Allo serveur ?

Nous savons à présent de manière basique détecter certains changement non légitimes sur nos systèmes. Cependant, ces alertes ne restent émises qu'en local et dans un cas réel, plusieurs dizaines de serveurs peuvent chacun avoir leur solution AIDE et leur signatures propres. Je vous conseille donc de faire en sorte que les serveurs soient en capacité de vous envoyer des alertes plutôt que d'attendre que ce soit vous qui alliez les constater sur chaque serveur. La première chose à faire est la création de tâches planifiées régulières qui exécuterons une vérification de la base de signature, mais qui vous avertirons également en cas de détection. Les cas les plus courants étant l'envoi d'un mail ou l'envoi d'un trap SNMP à votre solution de supervision (avec un gros voyant rouge !).

  • Vos serveurs sont vivants !

Une quantité importante des fichiers par défaut contrôlés par AIDE vont être modifiés régulièrement et engendrer des alertes. Qu'il s'agisse de fichiers temporaires, de configurations, de journaux d’événements... Les mises à jour, tâches planifiées et maintenance régulières des sysadmin entraîneront des modifications très fréquentes. Il faut donc anticipé une importante charge de travail (proportionnelle à votre nombre de serveur) due aux alertes que remonterons vos contrôles d'intégrité.

C'est pourquoi je vous conseille de passer par une phase d'apprentissage une fois que vos configurations seront finalisées. Cette phase consistera à avoir, dans un premier temps, un grande attention sur les alertes émises par AIDE afin de qualifier chacune d'elles et de savoir s'il s'agit d'un comporte normal ou non. Si c'est le cas, il faudra prendre le temps d'adapter la configuration à votre contexte pour que cette alerte ne soit plus émise.

  • Alerte rouge, qu'est ce qu'on fait ?

Je vous recommande également de créer des procédures de traitement des alertes et former vos collaborateurs à l'utilisation d'AIDE et aux opérations de maintenance que l'on vient de voir (renouvellement de la base, identification des modifications remontées par AIDE, etc.). Il n'y a rien de pire que de voir une alerte passer trahissant une potentielle attaque de ne pas savoir quoi en faire ou comment la traiter.

  • L'enfant qui criait au loup

Il est important de ne pas s'habituer à recevoir une alerte (importance d'avoir une phase d'apprentissage rondement menée), il serait désolant de voir que les administrateurs d'une plateforme ne prêtent plus attention aux alertes émises par AIDE car celles-ci sont soit trop nombreuses, soit systématiquement identiques. La détection d'une attaque serait alors impossible.

  • Attention au timing

Nous l'avons vu, la génération d'une base de signature peut prendre quelques secondes.. sur un serveur vide. Sur les serveurs de production, contenant souvent un grand nombre de fichiers (métier, journaux, configuration, etc.) la génération de la base de signature peut prendre plusieurs minutes (j'ai déjà constaté des temps d'attente de 25 minutes). Souvenez vous que l'équivalent d'une nouvelle base de signature est généré à chaque fois que vous fait un --init, mais aussi un --update ou un --check. Dans le cadre d'une vérification régulière de la signature des objets d'un système, il faut veiller à ce que la tâche planifiée n’entraîne pas une surcharge côté serveur, notamment si on lance une nouvelle vérification alors que la précédente n'est pas terminée.

IV. Ajout d'un nouveau service et configuration AIDE

Nous allons à présent creuser un peu plus la configuration d'AIDE et voir comment nous pouvons lui faire prendre en compte de nouveaux objets (dossiers/fichiers) par exemple suite à l'ajout d'un nouveau service ou d'une nouvelle application sur notre serveur.

A. Découverte du fichier de configuration

Comme indiqué précédemment, la configuration AIDE est située dans le fichier /etc/aide.conf, en voici un aperçu :

[root@localhost ~]# cat /etc/aide.conf
# Example configuration file for AIDE.
###################### PARTIE 1 ###################### 
@@define DBDIR /var/lib/aide
@@define LOGDIR /var/log/aide

# The location of the database to be read.
database=file:@@{DBDIR}/aide.db.gz

# The location of the database to be written.
#database_out=sql:host:port:database:login_name:passwd:table
#database_out=file:aide.db.new
database_out=file:@@{DBDIR}/aide.db.new.gz

# Whether to gzip the output to database
gzip_dbout=yes

# Default.
verbose=5

###################### PARTIE 2 ###################### 

# Sane
# NORMAL = R+sha512
NORMAL = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha512

# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+selinux+xattrs

# Access control only
PERMS = p+u+g+acl+selinux+xattrs

# Logfile are special, in that they often change
LOG = p+u+g+n+S+acl+selinux+xattrs

# Content + file type.
CONTENT = sha512+ftype

# Extended content + file type + access.
CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs

# Some files get updated automatically, so the inode/ctime/mtime change
# but we want to know when the data inside them changes
DATAONLY = p+n+u+g+s+acl+selinux+xattrs+sha512

######################   PARTIE 3    ###################### 

# Next decide what directories/files you want in the database.

/boot CONTENT_EX
/opt/ CONTENT

# Admins dot files constantly change, just check perms
/root/\..* PERMS
# Otherwise get all of /root.
/root/ CONTENT_EX

# These are too volatile
!/usr/src/
!/usr/tmp/

# Otherwise get all of /usr.
/usr/ CONTENT_EX

# trusted databases
/etc/hosts$ CONTENT_EX
/etc/host.conf$ CONTENT_EX
/etc/hostname$ CONTENT_EX
/etc/issue$ CONTENT_EX
/etc/issue.net$ CONTENT_EX
/etc/protocols$ CONTENT_EX
/etc/services$ CONTENT_EX
/etc/localtime$ CONTENT_EX
/etc/alternatives/ CONTENT_EX
/etc/sysconfig CONTENT_EX
/etc/mime.types$ CONTENT_EX
/etc/terminfo/ CONTENT_EX
/etc/exports$ CONTENT_EX
/etc/fstab$ CONTENT_EX
/etc/passwd$ CONTENT_EX
/etc/group$ CONTENT_EX
/etc/gshadow$ CONTENT_EX

Alors pas de panique, c'est loin d'être aussi complexe que ça en à l'air. J'ai notamment tronqué certains commentaires qui détaillent l'utilisation des différents symboles que l'on peu voir ("!", "sha512+ftype+p+u+g+n+acl+selinux+xattrs", etc.) pour des soucis de lisibilité dans l'article. Nous allons creuser cela ensemble. On peut déjà distinguer trois parties dans cette configuration, elles sont mises en avant par mes soins dans l'extrait ci-dessus.

La définition des paramètres de configuration AIDE

La première partie permet de définir quelques éléments tels que le nom et le répertoire de stockage des bases de signature et des nouvelles bases de signatures produites (les fameux aide.db.gz, et aide.new.db.gz). On apprend via les commentaires que les bases de données AIDE peuvent également être stockées en SQL (pourquoi pas sur un serveur distant qui centralise et archive toutes ces signatures pour plus de sécurité ?). On voit également que le répertoire de stockage par défaut de ces données est /var/lib/aide/ et que les journaux d’événements d'AIDE seront stockés dans /var/log/aide.

La définition des variables d'attributs

La seconde partie de la configuration par défaut contient la déclaration de sortes de variables ou "groupes" d'attributs, regardez par exemple celui-ci :

CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs

La variable CONTENT_EX est réutilisée dans la configuration par défaut, c'est pourquoi il est intéressant de se pencher dessus. Chaque attribut est séparé par un "+", ce qui rend la lecture un peu gênante, mais considérez qu'il s'agit simplement d'un séparateur (comme un virgule dans une phrase). On peut alors décrire simplement, grâce à la documentation en ligne, à quoi sert chaque attribut :

  • sha512 : permet de contrôler l'intégrité, on utilisera un hash calculé avec l'algorithme de hashage SHA512;
  • ftype : on surveille le type de fichier (non pas grâce à l’extension, mais grâce au "magic number");
  • p : on surveille les permissions attribuées à l'objet ciblé;
  • u : on surveille si l'objet ciblé change de propriétaire;
  • g : on surveille si l'objet ciblé change de groupe propriétaire;
  • n : on surveille le nombre de liens symboliques qui ciblent l'objet ciblé;
  • acl : on surveille les ACL affectés à cet objet (attentions ACL et permissions, ce n'est pas la même chose !);
  • selinux : on surveille les attributs SELinux de l'objet ciblé (le contexte de l'objet);
  • xattrs : on surveille les attributs étendus de l'objet ciblé.

La définition des objets et attributs à surveiller

On trouvera en troisième partie des couples  objets - variables qui servent, comme vous vous en doutez, à indiquer pour un objet spécifique (fichier ou dossier), qu'est ce que l'on souhaite surveiller. On aperçoit alors que la variable CONTENT_EX est très utilisée par défaut. Par exemple :

/etc/fstab$ CONTENT_EX
/etc/passwd$ CONTENT_EX
/etc/group$ CONTENT_EX
/etc/gshadow$ CONTENT_EX

On retrouve dans cet aperçu une partie des fichiers qui ont été ciblés par des alertes lors d'une création d'utilisateur (/etc/shadow, et /etc/passwd). On voit ici que par défaut, AIDE surveille les attributs contenus dans la variable CONTENT_EX (décrite plus haut) pour ces fichiers. On comprend dans ces quelques lignes clairement quels fichiers on regarde et qu'est-ce que l'on y surveille.

Autres particularités

  • Le $ à la fin est le même $ que dans une expression régulière, vous croiserez d'autres signes d'expression régulières (activement utilisées dans la configuration AIDE), par exemple :
!/etc/.*~

Il indique que le fichier doit finir par ce nom là. ce qui évite de prendre ne compte /etc/passwd.bak au lieu de /etc/passwd par exemple.

  • Le "!" de la commande ci-dessus signifie "ignore ces objets". Si je veux surveiller le contenu d'un répertoire, sauf un fichier bien précis, j'écris alors :
/etc/monappli/.*!
/etc/monappli/saufce.fichier
  • Le "=" indique que l'on contrôlera le dossier /tmp, mais pas ses objets enfants

B. Ajout d'un application et prise en compte dans AIDE

Nous allons maintenant installer une application web basique contenant quelques fichiers statiques et de configuration. Je simule cette application à la main avec les commandes suivantes :

yum install httpd 
mkdir -p /var/www/html/site1/config /var/www/html/site1/user_upload /var/www/html/site1/html
echo "nomappli=monAppliweb" >> /var/www/html/site1/config/web.conf.php
echo "Hello, déposez vos fichiers sur ce formulaire" >>/var/www/html/site1/html/index.php
chown apache -R /var/www/html/

On simule donc une application web contenant un répertoire avec ses pages web statiques, un répertoire avec les dépôts des utilisateurs (fichiers uploadés) et un répertoire avec la configuration de l'application web. Dans ce contexte, on comprend rapidement ce qui ne devra jamais être modifié (les pages web, la configuration) et ce qui va être modifié quotidiennement (le contenu du répertoire d'upload).

Faites donc un aide --check à la suite de l'installation de HTTPD, vous verrez que le nombre d'alerte que cela lève est assez conséquent, d'où l'importance de la phase d'apprentissage décrite dans la section précédente :). Pensez alors à faire une update de votre base de signature (la procédure est décrire plus haut dans ce même article).

Je vais donc vouloir créer une règle qui me permet d'être certains que rien n'est ajouté dans le répertoire racine, le répertoire de configuration et de pages web statiques, mais également que mes fichiers statiques sont intègres en étant vigilant à ignorer les modifications du répertoire d'upload de fichier. On ouvre donc le fichier /etc/aide.conf et on y ajoute le contenu suivant :

# Configuration HTTDP site1
/var/www/html/site1 DIR
/var/www/html/site1/config/.* CONTENT_EX
/var/www/html/site1/html/.* CONTENT_EX
!/var/www/html/site1/user_upload/

Ici, je vais essayer d'être un attaquant très maladroit et effectuer une multitude de changements. J'ajoute une backdoor PHP dans les dossiers config, user_upload et html, je modifie les permissions du fichier de configuration web.conf.php et du répertoire site1 :

[root@localhost ~]# touch /var/www/html/site1/config/super.backdoor.php  /var/www/html/site1/html/super.backdoor.php  /var/www/html/site1/user_upload/super.backdoor.php 
[root@localhost ~]# chmod 777 /var/www/html/site1/ /var/www/html/site1/config/web.conf.php

Ensuite, j'effectue une vérification d'intégrité et je regarde le résultat:

[root@localhost site1]# aide --check
Start timestamp: 2020-01-18 11:12:50 -0500 (AIDE 0.16)
AIDE found differences between database and filesystem!!

Summary:
Total number of entries: 38554
Added entries: 2
Removed entries: 0
Changed entries: 2

---------------------------------------------------
Added entries:
---------------------------------------------------

f++++++++++++++++: /var/www/html/site1/config/super.backdoor.php
f++++++++++++++++: /var/www/html/site1/html/super.backdoor.php

---------------------------------------------------
Changed entries:
---------------------------------------------------

d p.. .. A.. : /var/www/html/site1
f p.. ..A.. : /var/www/html/site1/config/web.conf.php

---------------------------------------------------
Detailed information about changes:
---------------------------------------------------

Directory: /var/www/html/site1
Perm : drw-r--r-- | drwxrwxrwx
ACL : A: user::rw- | A: user::rwx
A: group::r-- | A: group::rwx
A: other::r-- | A: other::rwx

File: /var/www/html/site1/config/web.conf.php
Perm : -rw-r--r-- | -rwxrwxrwx
ACL : A: user::rw- | A: user::rwx
A: group::r-- | A: group::rwx
A: other::r-- | A: other::rwx

On voit donc ici que deux fichiers super.backdoor.php ont été ajoutés et que les permissions du fichier /var/www/html/site1/config/web.conf.php et du répertoire /var/www/html/site1 ont été modifiées, ce qui correspond aux actions de mon attaquant. La création d'un fichier dans /var/www/html/site1/user_upload/ a été ignorée comme demandé.

Pendant les phases d'apprentissage, je vous conseille de toujours tester vos règles. Ici, on peut par exemple être surpris de ne pas détecter de modification sur les permissions du répertoire si l'on écrit la règle suivante :

/var/www/html/site1/ DIR

Il faut en effet ne pas écrire le "/" après le répertoire à surveiller, comme ceci :

/var/www/html/site1 DIR

Egalement, on évitera de faire un contrôle de hash sur un répertoire, ce qui pourrait être très long (incluant tous les fichiers qu'il contient) et redondant, on utilisera donc la variable créée par défaut DIR plutôt que CONTENT_EX :

# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+selinux+xattrs

[...]

# Extended content + file type + access.
CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs

On voit que la directive sha512 n'y est pas présente, ce qui évite de calculer un hash pour un répertoire.

V. Quelques astuces supplémentaires

A. Utiliser des fichiers de configuration différents

On peut également utiliser des fichiers de configuration différents en fonction des besoins. Un contexte d'exemple :

On souhaite vérifier l'intégrité de nos répertoires de configuration toutes les 5 minutes mais notre serveur contient de très gros répertoires avec de nombreux fichiers, la réalisation du contrôle d'intégrité prend donc 20 minutes à s'exécuter. Ici, on peut créer une configuration /etc/aide_etc.conf qui contiendra les directives relatifs aux répertoires dans /etc, une tâche planifiera toutes les 10 minutes un contrôle d'intégrité. Puis on créera un autre fichier de configuration /etc/aide_autre.conf qui contiendra toutes les autres directives, notamment celles concernant nos répertoires contenant de très nombreux fichiers, celui-ci sera lancé par une autre tâche planifiée qui s'exécutera, elle, toutes les 3 heures. Pour cela, on utilisera l'option -c :

[root@localhost aide]# aide -c /etc/aide_etc.conf
[root@localhost aide]# aide -c /etc/aide_autre.conf

B. Une base de signature, ça ressemble à quoi ?

On peut s'intéresser à ce que contient une base de signature. Pour cela, on utilise l'utilitaire gunzip pour décompresser notre base de signature, puis on l'ouvre avec un simple éditeur de texte :

[root@localhost aide]# gunzip aide.db.gz
[root@localhost aide]# vim aide.db

Voila un extrait du contenu de ce fichier :

/var/log/README 0 13759416349 100644 8570597 0 0 1 0 POSIX,dXNlcjo6cnctCmdyb3VwOjpyLS0Kb3RoZXI6OnItLQo=,0 0 c3lzdGVtX3U6b2JqZWN0X3I6dmFyX2xvZ190OnMw 1040
[..]
/var/log/aide 0 13759416349 40700 856482 0 0 2 0 POSIX,dXNlcjo6cnd4Cmdyb3VwOjotLS0Kb3RoZXI6Oi0tLQo=,0 0 c3lzdGVtX3U6b2JqZWN0X3I6YWlkZV9sb2dfdDpzMA== 22
[..]
/var/log/aide/aide.log 0 13759416349 100600 856461 0 0 1 0 POSIX,dXNlcjo6cnctCmdyb3VwOjotLS0Kb3RoZXI6Oi0tLQo=,0 0 dW5jb25maW5lZF91Om9iamVjdF9yOmFpZGVfbG9nX3Q6czA= 0

On remarque ici plusieurs noms des fichiers contrôlés, suivis de différentes données, dont des hashs. Je n'ai évidemment pas le détails de chacun des champs mais on peut imaginer que AIDE distingue ici le hash du fichier, ses permissions, ses ACL, son propriétaire, etc. 🙂

VI. Conclusion

L'implémentation d'une solution de scellement est une recommandation émise notamment par l'ANSSI dans son guide Recommandations pour la configuration d'un système GNU/Linux (Recommandation 51, page 62) :

Extrait du guide de l'ANSSI sur la sécurité des systèmes GNU/Linux

Au delà de l'aspect "réglementaire", il s'agit d'une très bonne solution lorsque celle-ci est correctement déployée et intégrée dans la vie quotidienne d'un parc de systèmes Linux. Elle peut permettre de trahir la présence d'une attaque en cours. J'espère que cet article vous sera utile et vous aura éclairci sur le fonctionnement d'AIDE et son intérêt en termes de sécurité.

Je rencontre un grand nombre de système d'information différents dans le cadre professionnel et ils sont trop rare à profiter des apports de ce type de solutions, je ne peux donc que vous conseiller d'expérimenter, de tester, d'apprendre et de déployer AIDE sur vos systèmes Linux.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Mickael Dorigny

Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.

Nombre de posts de cet auteur : 521.Voir tous les posts

3 thoughts on “AIDE : Utilisation et configuration d’une solution de contrôle d’intégrité sous Linux

  • Pour une solution de contrôle d’intégrité, je conseille plutôt Ossec qui a l’avantage d’être Multi plateforme.

    Répondre
    • Bonjour

      Comment faire pour être alerté quand on a 2 fichiers de configurations différents ?
      Jai bien 2 config avec 2 DB différentes mais en tache CRON, il prend toujours la même a savoir aide.db, meme en modifiant le fichier dans le répertoire cron.hourly et cron.daily

      En ligne de commande, init ou check, ça fonctionne correctement

      Merci d’avance

      Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.