Suite à la mésaventure d'un ami dont le site avait été hacké pour y déposer des chevaux de Troie, je me suis demandé comment se prémunir, dans une certaine mesure, de ce genre d'expérience ennuyeuse.

Il est bien évident qu'aucun système informatique n'est à l'abri d'une intrusion. Le mécanisme que je propose ici ne vise pas à se prémunir d'un intrus dont l'objectif serait d'obtenir les privilèges de l'utilisateur root, mais plus modestement de surveiller les modifications opérées sur les fichiers qui composent un site web.

Cette idée repose sur un double constat: d'abord l'usage des CMS s'est généralisé au détriment du développement spécifique, toujours plus coûteux et soumis à davantage d'aléas. Mais nombre de CMS présente des failles, connues ou à découvrir, et plus ces CMS sont complexes, plus le risque de faille est grand. À cela s'ajoute le nombre immense de plug-ins, modules et autres extensions qui augmente le risque de façon exponentielle car il n'y a pas deux configurations identiques.

Ensuite, les intrus visent rarement à détruire ou même perturber le fonctionnement du site. La tendance consiste au contraire à se faire aussi discret que possible et installer sur le serveur des fichiers vers lesquels pointent des liens contenus dans des spams, soit dans un but strictement publicitaire, soit pour installer un logiciel malfaisant sur la machine de la victime. Le problème rencontré par mon ami était de ce dernier type, et c'est Google qui a levé le lièvre en répertoriant le site comme source de malware.

J'ai donc imaginé de légèrement détourner de son usage premier un outil de détection d'intrusion, pour scanner les fichiers du site à intervalle régulier, et envoyer un mail à l'administrateur du serveur signalant toute addition, suppression ou modification. Mon regard s'était d'abord tourné vers Tripwire, mais l'outil date un peu et ne gère pas correctement les fichiers UTF-8. J'ai donc opté pour AIDE (Advanced Intrusion Detection Environment).

Il faut donc commencer par l'installer, je vous renvoie pour cela à la doc de la distribution de votre serveur. Dans mon cas (Ubuntu), il a suffi d'un simple:

apt-get install aide

Comme je ne souhaitais pas l'utiliser pour la surveillance de tout le serveur, j'ai supprimé le fichier ajouté dans /etc/cron.daily

La surveillance des fichiers devant pouvoir se faire sans se heurter aux permissions des divers utilisateurs du serveur, la suite des opérations se fait en tant que root. Un utilisateur ordinaire peut tout à fait utiliser la même technique pour surveiller ses propres fichiers, mais en cas d'intrusion il y a fort à parier que l'intrus s'apercevra bien vite de la présence du mécanisme ce qui en réduit considérablement l'utilité :-)

J'ai donc créé un répertoire destiné à accueillir le fichier de configuration ainsi que les bases de données qu'AIDE va utiliser. En prime, assurons-nous que nul autre n'aura accès à ce répertoire:

mkdir /home/aide
chmod 700 /home/aide

Ensuite, le fichier de configuration et ses permissions:

touch /home/aide/aide.conf
chmod 600 /home/aide/aide.conf

Puis, à l'aide de son éditeur de texte favori, quelques lignes dans aide.conf:

# Emplacement de la base de données de référence
database=file:/home/aide/aide.db.in

# Emplacement de la base à écrire
database_out=file:/home/aide/aide.db.out

# Définit à quel point le programme doit être bavard
verbose=20

# Définit la sortie du programme
# On pourrait utiliser un fichier mais ici la sortie standard nous suffit
report_url=stdout

# Ici, on définit l'algorithme de vérification à utliser
# comme on ne souhaite qu'une vérification simple, md5 est suffisant
MD=md5

# Ah, enfin le ou les répertoires à protéger
/home/mon/site MD
/home/un/autre/site MD

# Mais certains CMS utilisent des caches
# ou génèrent des logs qui changent tout le temps
# on ne veut pas surveiller ceux-là
# (AIDE utilise des regex)
!/home/.*(cache|logs?|te?mp)
!/home/.*(\.log)$

Bien entendu, il faut s'assurer que les répertoires que l'on ne surveille pas ne sont pas accessibles sur le web ! Surveillez l'efficacité des instructions contenues dans les fichiers .htaccess

À ce stade, il faut initialiser la base de données:

aide --init --config=/home/aide/aide.conf

Au bout d'une durée variable selon le nombre et la taille des fichiers, AIDE annonce le succès de l'opération. Il faut alors copier la base de données nouvellement générée:

cp /home/aide/aide.db.out /home/aide/aide.db.in

Puis, on vérifie que tout va bien:

aide -c /home/aide/aide.conf --check

Si aucun fichier n'a été modifié, on obtient l'annonce suivante:

AIDE, version 0.13.1
### All files match AIDE database. Looks okay!

Dans le cas contraire, vous verrez quelque chose du genre:

AIDE found differences between database and filesystem!!
Start timestamp: 2010-08-21 14:11:32

Summary:
 Total number of files: 49944
 Added files:                   0
 Removed files:         0
 Changed files:         1


---------------------------------------------------
Changed files:
---------------------------------------------------

changed: /home/mon/site/.htaccess

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

Enfin, il ne reste plus qu'à automatiser la tâche, en l'ajoutant au crontab:

# Analyse tous les jours à 2h du matin
0 2 * * * nice -19 /usr/bin/aide --config=/home/aide/aide.conf -C| mail you@yourdomain -sAIDE\ Report

Notez toutefois, que si un fichier a été modifié, AIDE vous en avertira tant que la base de données de référence n'aura pas été mise à jour. Aussi, on peut se dire que la mettre à jour une fois par semaine nous laisse suffisamment d'opportunités d'être avertis:

# Mise à jour de la base de données de référence, une fois par semaine
0 3 * * 3  nice -19 /usr/bin/aide --config=/home/aide/aide.conf --init;cp -f /home/aide/aide.db.out /home/aide/aide.db.in

Nous voilà parés. Oh, bien sur, ce mécanisme ne prévient pas les intrusions puisque son objectif est de les découvrir après qu'elles aient eu lieu. Mais, pour en revenir à mon ami, il y avait presque 1Go de fichiers malfaisants sur son serveur, planqués loin dans l'arborescence, et il n'y avait pas vraiment de moyen simple pour lui de s'en apercevoir. Un tel mécanisme présente au moins l'avantage de signaler la moindre modification.

Et puis, tant que j'y étais, et comme ClamAV est aussi installé sur le serveur, j'en ai profité pour ajouter cette ligne au crontab:

# Antivirus
0 23 * * * nice -19 clamscan -ir --exclude-dir='/repertoire/a/exclure/1|/repertoire/a/exclure/2'  /home/|mail you@yourdomain.org -sClamScan\ Report >/dev/null 2>&1

Sortez couverts !