Que faire si le serveur est compromis

Les signes qui ne trompent pas

• Le processeur est à 100 % en permanence pour un processus au nom étrange : minage de cryptomonnaie, le cas le plus courant.
• Un signalement d'abus nous parvient : votre machine balaie d'autres serveurs ou envoie du courrier indésirable.
• Le trafic sortant explose sans raison.
• Des connexions réussies dans auth.log depuis des pays où vous n'êtes pas.
• Des fichiers modifiés dans /etc ou /usr/bin à une date que vous ne reconnaissez pas.
• Une tâche cron que vous n'avez pas écrite.

Dans l'ordre, et sans se précipiter

1. 1

   Isoler, ne pas éteindre

   Coupez l'accès réseau depuis l'espace client plutôt que d'éteindre la machine : éteindre efface la mémoire vive, où se trouvent souvent les traces les plus parlantes. Une machine isolée ne nuit plus à personne.

2. 2

   Constater, avant de toucher

   Notez l'heure, faites des captures. Si l'incident implique des données personnelles, ces éléments comptent : le RGPD impose de notifier la CNIL sous 72 heures.

   bashCopier

   ps auxf
   ss -tunap
   last -20
   sudo grep -i 'accepted' /var/log/auth.log | tail -50
   crontab -l; sudo crontab -l -u root
   ls -lat /etc | head -20

3. 3

   Changer ce qui a fui

   Tous les mots de passe et toutes les clés qui se trouvaient sur la machine doivent être considérés comme connus de l'attaquant : accès base de données, jetons d'API, clés SSH, identifiants de paiement. Changez-les depuis un autre poste.

4. 4

   Réinstaller

   C'est la seule issue sûre. On récupère les données, pas le système.

Récupérer sans réimporter le problème

• Copiez les données, jamais les exécutables ni les fichiers de configuration douteux.
• Pour un site, reprenez le code depuis votre dépôt Git, pas depuis le serveur compromis.
• Exportez la base de données, et relisez-la : les injections de code dans le contenu sont fréquentes.
• Reprenez les fichiers déposés par vos utilisateurs après avoir vérifié qu'aucun n'est exécutable.

Comprendre par où c'est entré

Sans cette étape, la nouvelle machine sera compromise par le même chemin. Les portes d'entrée habituelles : un mot de passe SSH faible, une extension de CMS non mise à jour, un service d'administration exposé sans mot de passe, un fichier .env téléchargeable, ou un jeton laissé dans un dépôt public.