Enquêter sur les serveurs compromis

Cet article répertorie les outils disponibles pour effectuer une analyse d'un serveur compromis. (Le nettoyage du serveur compromis n'entre pas dans son champ d'application.) L'utilisation de ces outils vous aide à déterminer les informations suivantes :

• Le point d'entrée
• L'origine de l'attaque
• Quels sont les fichiers compromis
• Le niveau d'accès obtenu par l'attaquant
• La piste d'audit des empreintes de l'attaquant

De nombreux types de compromis différents peuvent exploiter un serveur Unix®. Les attaquants peuvent lancer une attaque par force brute, deviner un mot de passe faible ou tenter d'utiliser des vulnérabilités logicielles connues dans l'espoir que le serveur n'est pas sur un calendrier de correctifs régulier. Il est important de comprendre comment la machine a été compromise pour déterminer l'étendue des dommages causés à votre serveur et aux autres hôtes accessibles à la machine compromise.

Pour la plupart des compromis au niveau de la racine, l'approche de récupération la plus simple consiste à effectuer une nouvelle installation du serveur et à restaurer toutes les données critiques à partir des sauvegardes. Cependant, jusqu'à ce que vous connaissiez le point d'entrée du compromis, cette étape peut ne pas être suffisante car vous devez comprendre le compromis afin de pouvoir combler correctement la faille de sécurité.

Documenter l'attaque

Lorsque vous êtes informé qu'un système sous votre contrôle pourrait être compromis, assurez-vous d'obtenir autant d'informations que possible de la part du déclarant, y compris les éléments suivants :

• Comment le problème initial a été trouvé
• Heure estimée à laquelle la compromission s'est produite
• Si le serveur a été modifié après la détection de la compromission
• Toute autre chose que le journaliste dit importante

Important :Si vous envisagez d'impliquer les forces de l'ordre, il est impératif que vous n'entrepreniez aucune action supplémentaire sur le serveur. Le serveur doit rester dans son état actuel à des fins de collecte de preuves.

Si vous choisissez de poursuivre l'enquête, documentez tout ce que vous trouvez sur le serveur. Cette étape peut être aussi simple que copier et coller une commande et ses résultats.

Outils d'investigation

Dans certains compromis, l'attaquant parvient à supprimer tous les fichiers journaux importants pour masquer leurs traces. Cependant, cela ne se produit pas toujours. Par conséquent, les fichiers journaux contiennent des indices précieux sur ce que l'attaquant a fait au serveur. Les fichiers journaux peuvent également vous aider à déterminer si l'attaque était un piratage Web de base ou une compromission au niveau de la racine. Utilisez les commandes de cette section pour trouver des indices qui vous aideront à découvrir l'étendue du compromis.

dernière commande

Le last La commande répertorie les sessions des utilisateurs qui se sont récemment connectés au système. Sa sortie inclut les horodatages et les noms d'hôte et indique si l'utilisateur est toujours connecté. Si une adresse IP (Internet Protocol) impaire apparaît dans la sortie, vous pouvez la comparer à une attaque Secure Shell (SSH) par force brute dans le /var/log/messages ou /var/log/secure annuaire. Cette étape peut indiquer comment l'attaquant est entré, quel nom d'utilisateur il a utilisé pour y accéder et s'il a pu élever ses privilèges à root .

commande ls -lart

Le ls -lart La commande génère une liste chronologique de fichiers et de répertoires que vous pouvez comparer au moment où la compromission s'est produite. Cette sortie peut vous aider à déterminer ce que l'attaque a ajouté ou supprimé du système.

commande netstat -na

Le netstat -na La commande affiche les sockets d'écoute actuels sur la machine. L'exécution de cette commande peut révéler des portes dérobées qui écoutent ou des services errants en cours d'exécution.

commande ps -wauxef

Cette commande vous aide à retrouver tous les processus errants qui écoutent et montre d'autres processus étranges (par exemple, l'utilisateur www exécutant un processus Bash). Vous pouvez également exécuter la commande lsof |grep <pid> pour trouver plus d'informations sur les fichiers ouverts qu'un processus utilise. Simultanément, en exécutant cat /proc/<pid>/cmdline peut également vous dire où se trouve le fichier qui contrôle un processus.

commande bash_history

Le dossier historique est souvent la pierre de Rosette pour retracer ce qui s'est passé lors d'un compromis. Utilisation de bash_history commande pour parcourir le .bash_history de l'utilisateur montre souvent exactement quelles commandes ils ont exécutées, quels programmes malveillants ils ont téléchargés et les répertoires sur lesquels ils se sont concentrés.

commande supérieure

Les processus malveillants provoquent souvent des problèmes de conflit d'unité centrale de traitement (CPU) dans l'environnement et apparaissent donc en haut de la liste des processus. Utilisez le top commande pour afficher cette liste. Lorsque vous recherchez un compromis, considérez comme suspects tous les processus qui causent des problèmes de contention CPU.

commande strace

Lorsque vous exécutez le strace -p pid commande sur un processus suspect, le strace La commande peut fournir des informations importantes sur ce que fait le processus.

Autres outils

Les commandes précédentes peuvent ne pas fournir beaucoup d'indices sur ce qui s'est passé pendant l'attaque. Si tel est le cas, vous pouvez utiliser des outils plus spécialisés.

Important :Avant d'utiliser les outils de cette section, vous devez confirmer que les fichiers binaires que vous utilisez pour enquêter ne sont pas des versions contenant des chevaux de Troie. Les versions contenant des chevaux de Troie peuvent effectuer des tâches au nom de l'attaquant, telles que l'omission d'informations susceptibles de révéler ce que la compromission tentait d'accomplir.

Exécutez la commande suivante pour vérifier que vous disposez d'un bon ensemble d'outils :

rpm -Va

La vérification d'un package compare les informations sur les fichiers installés du package avec les métadonnées du package que la base de données RPM Package Manager (RPM) stocke. La vérification compare les informations sur la taille, la somme MD5, les autorisations, le type, le propriétaire et le groupe associés à chaque fichier. La sortie affiche toutes les divergences.

Important  :Les packages marqués dans les répertoires suivants peuvent indiquer que vous utilisez une version du binaire contenant un cheval de Troie et que vous ne pouvez donc pas faire confiance à sa sortie :

• /bin
• /sbin
• /usr/bin
• /usr/sbin

L'exemple suivant montre un fichier contenant un cheval de Troie :

S.5….T /bin/login

commande rpm -qa

Vous pouvez utiliser la commande rpm -qa pour afficher les paquets récemment installés dans l'ordre chronologique. Cependant, dans le cas d'une compromission de la racine, la base de données rpm peut également être compromise.

commande lsattr

Si l'attaquant obtient un accès root et troyens certains binaires, ils pourraient rendre ces binaires immuables de sorte que vous ne pouvez pas réinstaller des versions propres de ceux-ci. Vérifiez les répertoires suivants :

• /bin
• /sbin
• /usr/bin
• /usr/sbin

L'exemple suivant montre un fichier qu'un attaquant a rendu immuable :

-------i----- /bin/ps
Under normal circumstances in these directories, the rules should all look similar to:

------------- /bin/ps

commande de recherche

find est un outil Unix qui peut être essentiel pour trouver des fichiers récemment modifiés. Par exemple, vous pouvez trouver des fichiers modifiés au cours des cinq derniers jours en exécutant la commande suivante :

find / -mtime 5

Répertoires communs pour les exploits Web

Vérifiez les répertoires en écriture universelle suivants dans lesquels Apache® écrit couramment des fichiers temporaires :

• ls -al /tmp
• ls -al /var/tmp
• ls -al /dev/shm

Recherchez tous les fichiers que vous ne reconnaissez pas ou qui semblent suspects. Soyez à l'affût des fichiers cachés et des fichiers disposant d'autorisations d'exécution.

Si vous avez défini les autorisations pour les répertoires de votre site Web sur 777, vérifiez-les également.

Trouver le point d'entrée

Si vous trouvez des informations utiles en utilisant les outils des sections précédentes, vous pouvez également disposer d'un horodatage indiquant à quel moment le pirate a installé le ou les fichiers malveillants sur le serveur.

Vous pouvez utiliser cet horodatage pour examiner les journaux d'accès de votre site Web à la recherche d'entrées suspectes qui ont été ajoutées au cours de cette période. Si vous trouvez quelque chose de suspect, vous pouvez le croiser avec l'emplacement des fichiers malveillants pour affiner le point d'entrée.

Bien que la plupart des compromis proviennent de code exploitable sur votre site Web, vous ne pouvez pas exclure d'autres points d'entrée. Assurez-vous de consulter /var/log/* pour tout ce qui semble suspect pendant la période signalée.

Exemple d'enquête

L'exemple d'investigation de cette section illustre le processus que vous devez utiliser lors de l'investigation d'une suspicion de compromission au niveau de la racine.

Identifier le type d'attaque

Vérifiez s'il s'agissait d'un piratage Web de base ou si l'attaquant a réellement obtenu les privilèges root. Dans la plupart des cas, l'attaque est un simple piratage Web que vous pouvez nettoyer en toute sécurité.

1. Exécutez les commandes suivantes pour déterminer si l'attaquant a obtenu les privilèges root :

   lsattr /usr/sbin | moins

   lsattr /usr/bin | moins

   lsattr /bin | moins

   lsattr /sbin | moins

2. Recherchez les attributs modifiés, tels que les fichiers binaires définis comme immuables.

   Sortie :

    s---ia------- /sbin/shs
   

   Lorsque vous utilisez les strings commande sur ce fichier, vous voyez qu'il s'agit d'un backdoorshell.

Vérifier si l'attaquant a nettoyé ses traces

Dans de nombreux cas, les attaquants sont inexpérimentés ou négligents et n'ont pas effacé leurs traces. Utilisez les étapes suivantes pour vérifier si l'attaquant a laissé des indices :

1. Vérifiez que tous les comptes d'utilisateurs dans /etc/passwd avoir un shell valide en exécutant la commande suivante :

   chat /home/$USER/.bash_history

2. Récupérez l'historique de l'utilisateur root en exécutant les commandes suivantes :

   historique

   chat /root/.bash_history

Dans cet exemple, la sortie de /root/.bash_history révèle que l'attaquant a effectué les actions suivantes sur le serveur :

• Téléchargement d'outils malveillants à diffuser via Apache® dans /var/www/html/* .
• Installation d'outils Internet Relay Chat (IRC) et d'autres outils dans /var/tmp/.ICE-unix .
• Modification de la crontab racine pour retélécharger les outils malveillants si quelqu'un les supprime du serveur (* * * * * /var/tmp/.ICE-unix/update >/dev/null 2>&1 ).

Vérifier les hacks Web de base

Jusqu'à présent, nous avons déterminé que l'attaque est probablement un simple piratage Web que vous pouvez facilement nettoyer sans formater le serveur.

Cependant, dans cet exemple, nous savons que l'attaquant a obtenu les privilèges root. Ils pourraient aussi avoir exploité phpMyAdmin . Après le chargement du shell PHP de la porte dérobée, l'attaquant a pu effectuer un exploit racine local pour élever ses privilèges.

1. Exécutez les commandes suivantes pour rechercher des fichiers et des répertoires cachés dans les répertoires lisibles par le monde dans lesquels Apache écrit généralement tmp fichiers :

   ls -al /var/tmp |moins

   ls -al /tmp

   ls -al /dev/shm

2. Dans cet exemple, les commandes renvoient la sortie suivante :

   drwx—— 3 70 70 4096 19 novembre 02:00 /var/tmp/.ICE-unix

3. Si vous trouvez des éléments ici, vous devez essayer de retrouver le point d'entrée afin de pouvoir supprimer le site, mettre à jour le code du site ou réparer le code exploitable. L'étape 5 présente un moyen rapide d'accomplir cette tâche. Cependant, si la sortie de ps -waux La commande montre que les bots IRC sont en cours d'exécution, alors vous pouvez essayer de comprendre d'où le processus s'exécute en utilisant le lsof commande oups -wauxxef |grep <pid> .

Rechercher les identifiants de processus qui écoutent les connexions entrantes

1. Exécutez les commandes suivantes pour rechercher les identifiants de processus (PID) qui écoutent les connexions entrantes :

• netstat -natp  : recherche toutes les connexions suspectes qui s'exécutent sur des ports impairs

• ps -wauxxef  :recherche les fichiers suspects, tels que bash fonctionnant sous un www contexte

• lsof <pid>  :Aide à déterminer d'où provient le PID

  Le résultat ressemble à l'exemple suivant :

    tcp 0 0 0.0.0.0:1144 0.0.0.0:* LISTEN 1008/bash
  
    tcp 0 1 172.16.23.13:60968 22.22.22.22:7000 SYN_SENT 6860/sshd
  

  Dans cet exemple, plusieurs autres connexions établies par SSH s'exécutent également à partir de ports de haut niveau, comme illustré dans l'exemple suivant :

    [root@www tmp]# netstat -natp |grep sshd |awk '{print $4,$5,$6,$7}'
  
    0.0.0.0:22 0.0.0.0:* LISTEN 1046/sshd
  
    172.16.23.13:60986 22.22.22.22:6667 SYN_SENT 6860/sshd
  
    123.123.123.123:22 22.22.22.22:59361 ESTABLISHED 22795/sshd
  
    123.123.123.123:22 22.22.22.22:57434 ESTABLISHED 22796/sshd
  
    123.123.123.123:57139 143.143.143.143:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:57402 22.22.22.22:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:22 143.143.143.143:49238 ESTABLISHED 8860/sshd
  
    123.123.123.123:57134 22.22.22.22:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:56845 22.22.22.22:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:57127 143.143.143.143:6667 ESTABLISHED 6860/sshd
  

  Cette sortie indique que les attaquants sont toujours connectés à cette machine. Cependant, vous ne pouvez pas les voir car ils ont probablement modifié les binaires pour se cacher.

Déterminer le point d'entrée pour le compromis d'origine

Utilisez les étapes suivantes pour déterminer le point d'entrée du compromis d'origine :

1. Vérifiez /var/log/[messages|secure] pour les tentatives SSH par force brute.

2. Vérifiez les journaux d'accès Apache et les journaux d'erreurs. Cette étape peut aider à déterminer quel site est exploitable.

   Vous devez également croiser les adresses IP avec les journaux si vous pensez qu'il y a une chance que cela provienne de là. Il s'agit d'un moyen simple et rapide de retrouver le point d'origine.

   Vous pouvez vérifier rapidement les serveurs qui ont un grand nombre de journaux Web en utilisant les commandes suivantes :

   cd /var/log/httpd
   
   for i in `ls * |grep access`; do echo $i && grep wget $i; done
   
   for i in `ls * |grep access`; do echo $i && grep curl $i; done
   

   Remarque  :Cet exemple recherche wget parce que wget était dans le fichier historique de root sous ce qui aurait pu faire partie du point d'entrée.

Résultat

Dans cet exemple, notre enquête a révélé qu'un attaquant a exploité le phpMyAdmin installation dans le /var/www/html répertoire, probablement parce que la version de phpMyAdmin installé sur le serveur était très obsolète. Patcher phpMyAdmin un horaire régulier empêche cette situation de se produire.