Traduction de l'article How To Tell If Your Linux Server Has Been Compromised. Article original publié le 28 novembre 2017 sur bash-prompt.net.

Un serveur qui a été compromis ou détourné dans le sens de ce guide consiste dans le fait qu'une personne non autorisée ou un robot se soit loggé sur le serveur dans le but de l'utiliser pour son propre usage, généralement à de mauvaises fins.

Avertissement : si votre serveur a été compromis par la NSA ou une autre organisation criminelle sérieuse, alors vous ne remarquerez aucun de ces problèmes et les techniques exposées ci-dessous ne vous révèleront pas leur présence. ;-)

Cependant la majorité des serveurs compromis le sont soit par des robots, c'est-à-dire par des programmes d'attaque automatiques, soit par des attaquants sans grande compétence (les script-kiddies) ou des criminels ordinaires.

Ce type d'attaquants abusent des serveurs pour toute sorte d'usages tant qu'ils y ont accès et prennent peu de précautions pour cacher ce qu'ils font.

Symptômes d'un serveur compromis

Quand un serveur a été compromis par quelqu'un de peu expérimenté ou un programme d'attaque automatique, ces attaquants vont généralement l'utiliser pour faire quelque chose qui va consommer 100% des ressources de la machine. Ces ressources seront soit le processeur pour faire des choses comme du minages de monnaies cryptées ou l'envoi de spam, ou la bande passante pour lancer des attaques en déni de service.

Cela signifie que la première indication que quelque chose cloche est que le serveur est « ralenti ». Cela peut se manifester par le fait que le site web sert ses pages beaucoup plus lentement qu'à la normale, ou que les mails mettent plusieurs minutes à être distribués.

Quelles vérifications doit-on alors faire ?

Vérification 1 - Qui est actuellement loggé ?

La première chose à faire est de voir qui est actuellement loggé sur le serveur. Il n'est pas rare de trouver l'attaquant loggé sur le serveur et en train de travailler dessus.

La commande shell pour savoir ça est w. Lancer w donne un affichage de ce genre :

08:32:55 up 98 days,  5:43,  2 users,  load average: 0.05, 0.03, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    113.174.161.1    08:26    0.00s  0.03s  0.02s ssh root@coopeaa12
root     pts/1    78.31.109.1      08:26    0.00s  0.01s  0.00s w

Une de ces IP provient du Royaume Uni et la seconde est une IP vietnamienne. Il y a des chances que ce ne soit pas une bonne chose.

Arrêtez-vous et prenez une respiration, ne paniquez pas, mais ne tuez pas simplement leur connexion ssh. À moins que vous ne puissiez bloquer leur retour sur le serveur, ils vont faire si vite pour se reconnecter qu'ils vont probablement vous déconnecter et vous empêcher de vous reconnecter.

Regardez la section Que faire si votre serveur a été compromis à la fin de ce guide pour savoir comment procéder si vous trouvez des preuves d'une compromission.

La commande whois peut être utilisée avec une adresse IP et vous donnera tout les informations à propos de l'organisation à laquelle cette IP est confiée, y compris le pays où elle se situe.

Vérification 2 - Qui s'est connecté ?

Les serveurs linux enregistrent les connexions des utilisateurs qui se sont connectés, de l'IP à partir de laquelle ils se sont connectés, à quel moment et pendant combien de temps. Ces informations sont accessibles par la commande last.

Son affichage ressemble à ça :

root     pts/1        78.31.109.1      Thu Nov 30 08:26   still logged in
root     pts/0        113.174.161.1    Thu Nov 30 08:26   still logged in
root     pts/1        78.31.109.1      Thu Nov 30 08:24 - 08:26  (00:01)
root     pts/0        113.174.161.1    Wed Nov 29 12:34 - 12:52  (00:18)
root     pts/0        14.176.196.1     Mon Nov 27 13:32 - 13:53  (00:21)

Il y a un mélange de mes IP du Royaume Uni et quelques IP vietnamiennes, avec les deux premières encore connectées. Si vous voyez des IP non autorisées, alors reportez-vous à la dernière section.

L'historique des connections est contenu dans un fichier binaire dont le chemin est /var/log/wtmp et qui est donc facilement supprimable. Souvent les attaquants effacent simplement ce fichier pour essayer d'effacer leurs traces. En conséquence si vous lancez la commande last et que vous ne voyez que votre connexion actuelle, c'est mauvais signe.

Si il n'y a pas d'historique des connexions soyez très, très suspicieux et continuez à chercher des indications de compromission. 

Vérification 3 - Épeluchez l'historique des commandes

Les attaquants de ce niveau ne prennent souvent aucune précaution pour enlever les commandes qu'ils ont lancé de l'historique, du coup afficher l'historique des commandes va vous montrer tout ce qu'ils ont fait. Recherchez particulièrement les commandes wget ou curl qui auraient été utilisées pour télécharger des programmes en dehors des dépôts comme des robots de spam ou des programmes de minage de monaies chiffrées.

L'historique des commandes est contenu dans le fichier ~/.bash_history et du coup certains attaquants effacent ce fichier pour cacher ce qu'ils ont fait. Comme avec l'historique des connexions, si vous lancez la commande history et que vous ne voyez rien, c'est que le fichier d'historique a été effacé. Ceci est de nouveau un mauvais signe, et vous devriez contrôler votre serveur très soigneusement.

Vérification 4 - Qu'est-ce qui utilise toute la puissance du processeur ?

Le type d'attaquant que vous rencontrerez couramment ne prend pas trop de précautions pour cacher ce qu'ils font. Ils vont donc lancer des processus qui consomment toute la puissance du CPU. Cela permet généralement de les repérer assez facilement. Lancez simplement la commande top et regardez les processus affichés en haut.

Cela va aussi vous montrer les personnes qui utilisent votre serveur sans s'y être connecté. Comme par exemple quelqu'un utilisant un formulaire de mail non protégé pour relayer du spam.

Si le processus supérieur vous est inconnu, cherchez son nom sur Google ou recherchez ce qu'il peut bien faire avec losf ou strace.

Pour utiliser ces outils, copiez leur PID sur top et lancez la commande :

strace -p PID

Cela affichera tous les appels système que le processus effectue. Il y a beaucoup d'informations, mais les parcourir vous donnera une idée de ce qui se passe.

lsof  -p PID

Ce programme va lister les fichiers ouverts de ce processus. Cela encore va vous conner une bonne idée de ce qui se passe en vous montrant quels fichiers sont utilisés.

Vérification 5 - Contrôlez tous les processus du système

Si un processus non autorisé ne consomme pas assez de puissance du processeur pour être repéré avec top il apparaîtra lors de l'affichage de tous les processus avec ps. Ma commande préférée est ps auxf pour fournir le maximum d'informations de façon claire. 

Vous devriez rechercher tout les processus que vous ne reconnaissez pas. Plus vous lancerez ps sur vos serveur (ce qui est une bonne habitude) plus facilement un processus étranger vous sautera aux yeux.

Vérification 6 - Passez en revue l'utilisation du réseau par les processus

La commande iftop fonctionne commme top pour afficher une liste classée de processus qui envoient et reçoivent des données avec les sources et les destinations de ces données. Un processus comme un attaque DOS ou un robot de spam seront immédiatement visibles en haut de la liste.

Vérification 7 - Quels processus attendent-ils des connexions réseau ?

Souvent un attaquant installera un programme qui ne fait rien à part attendre des instructions sur un port réseau. Ce type de programme ne consomme pas de ressources processeur ou de bande passante tant qu'il est en attente et peut donc passer inaperçu des commandes de type top.

Les commandes lsof et netstat vont toutes les deux afficher tous les processus réseau. Je les utilise avec les options suivantes :

lsof -i

netstat -plunt

Vous devriez chercher chaque processus dans la liste qui est dans l'état LISTEN ou ESTABLISHED car ces processus soit sont en attente d'une connexion (LISTEN) soit ont ouvert une connexion (ESTABLISHED). Si vous ne reconnaissez pas ces processus utilisez strace ou lsof pour essayer de voir ce qu'ils sont en train de faire.

Que faire si votre serveur a été compromis ?

La première chose à faire est de ne pas paniquer, particulièrement si l'attaquant est actuellement connecté. Il faut que vous soyez capable de reprendre le contrôle de la machine avant que les attaquants ne s'aperçoivent que vous savez qu'ils existent.  Si ils réalisent que vous les avez détectés ils peuvent vous éjecter de votre serveur et commencer à détruire votre serveur par vengeance.

Si vous n'êtes pas très versé dans la technique, contentez vous d'arrêter le serveur. Soit depuis le serveur lui-même en utilisant les commandes shutdown -h now ou systemctl poweroff. Ou bien connectez-vous sur la page d'administration du serveur sur le site de votre hébergeur et arrêtez le serveur. Une fois qu'il est arrêté vous pouvez travailler sur les règles de pare-feu nécessaires et consulter votre hébergeur à tête reposée. 

Si vous vous sentez un peu plus confiant et que votre hébergeur ait un pare-feu en amont, alors créez et activez les deux règles suivantes dans cet ordre :

1. Autorisez les connexions SSH seulement depuis votre adresse IP ;
2. Bloquez tout le reste, pas seulement SSH mais tous les protocoles sur tous les ports.

Cela coupera immédiatement leur session SSH et vous rendra l'accès à votre serveur.

Si vous n'avez pas accès à un pare-feu en amont alors il faudra que vous créiez ces règles de pare feu sur le serveur lui-même, et lorsqu'elles seront en place tuer la session SSH des attaquants avec la commande kill.

La méthode utlime, si c'est possible, est de vous connecter à votre serveur par une connexion indépendante du réseau, comme une console série et arrêter le réseau avec la commande systemctl stop network.service. Cela arrêtera immédiatement tout accès réseau à la machine de façon à ce que vous puissiez mettre en place les règles de pare-feu à votre rythme.

Une fois que vous avez regagné le contrôle sur votre serveur, ne lui faites plus confiance.

N'essayez-pas de corriger les choses et de continuer à utiliser le serveur. Vous ne pouvez jamais être certain de ce qu'a fait l'attaquant, et donc vous ne pouvez pas être certain que le serveur soit sûr.

La seule chose sensée à faire est de copier toutes les données dont vous avez besoin et de repartir sur un nouvelle installation du système.

Ressources sur le sujet de la sécurité serveurs :

Surveillance des modifications du système de fichier :

Deux logiciels à signaler, un plus complexe à configurer que l'autre.

Integrit

Le plus simple à configurer, le sous-titre de leur site github est « l'alternative la plus simple à tripwire ». Quelques ressources intéressantes :

• Le site officiel sur github
• Un article sur system-linux.eu

Tripwire

L'outil le plus ancien, un peu plus long à configurer, mais offrant de larges possibilités.

• Le site officiel
• Un article sur it-connect.fr