On entend beaucoup parler en ce moment de hacking, de hackers, de supers hackers….Comme j’ai la chance d’être entourée de super geeks, entre Benoit Tersiguel, l’auteur de la Minute Geek, Sylvain Gautier, le papa de mon site et Patrice Lazareff, dont les articles vont de la définition de l’ingénieur du son, en passant par Bitcoin ou la neutralité du Net, je me suis dit qu’il était temps de parler de “Comment éviter de se faire hacker son site”. En effet, je m’aperçois que ce qui est le plus demandé sur le site, c’est du geek, du technique, du code, des trucs qui marchent. Du Do It Yourself quoi. Des choses qui vous permettent de démarrer seuls et de mettre les mains dans le cambouis. Donc mettons les mains dans le code. Et c’est Patrice Lazareff qui s’y colle.
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
C’est à vous.
Illustration photo: “We want more”
J’avais eu l’occasion de lire cet article, intéressant si on a un serveur dédié, mais d’en le cas d’un serveur mutualisé, les moyens de surveillance sont plus limités.
Il convient dans ce cas, et je pense que ça concerne la majorité, d’abord d’utiliser un mot de passe fort pour l’interface administration chez votre hébergeur. Le mieux étant d’utiliser une suite de caractères sans signification. Idem sur l’interface de votre CMS et votre accès FTP, et bien sûr un mot de passe différent. Et bien sur les changer régulièrement.
Une bonne solution consiste, lorsqu’on le peut, à désactiver le compte admin par défaut et d’utiliser un login connu de vous seul. C’est moins facile de hacker un site en brute force lorsqu’on ne connait pas la porte où frapper. Pour les plus avertis d’entre vous, changer le nom et l’adresse de la page d’administration permet de ralentir le travail d’un éventuel hacker. La mise en place d’un honeypot, comme de faire un faute site d’administration qui vous envoie un mail dès que quelqu’un se connecte.
Bien évidement, il faut surveiller les nouvelles versions de votre CMS et plugins, pour les tenir à jour. Je ne conseille pas forcément de l’installer tout de suite, on n’est jamais à l’abri d’une incompatibilité, d’un bug ou d’une nouvelle faille. Surveiller sur les forums officiels, les éventuels problèmes des nouvelles versions et les solutions qui sont proposer.
Je conseille le site Zataz.com qui répertorie la plus part des failles sur les CMS.
Vérifiez aussi qu’au niveau de votre FTP, tous les accès soit verrouillés, qu’il n’y est pas de dossier en 777
Mais l’indispensable, c’est de faire des sauvegardes complètes Bases+fichiers de votre site de façon régulière, et les conserver en local ( sur votre ordi perso). L’idéal étant de garder vos différentes sauvegardes, au moins les dix dernières.