Que faire si mon VPS a été piraté ?

Ne nettoyez pas un VPS compromis

Si votre VPS est compromis, la décision la plus importante intervient avant même l'exécution de la moindre commande. N'essayez pas de nettoyer la machine. Isolez-la via l'interface de votre fournisseur, créez un snapshot du disque pour servir de preuve, révoquez tous les identifiants qu'elle contenait, puis redéployez un serveur propre à partir de sources de confiance.

Vous ne pouvez pas prouver qu'un rootkit a été supprimé, car les outils qui permettraient de le prouver sont ceux que l'attaquant contrôle.

C'est l'argument central. Voici le mécanisme sous-jacent. Un attaquant ayant obtenu les privilèges root peut remplacer ps afin qu'un identifiant de processus (PID) n'apparaisse jamais dans sa sortie. Une ligne dans /etc/ld.so.preload charge le code de l'attaquant dans chaque programme lié dynamiquement sur la machine, de sorte que ls, ss et find mentent tous de manière cohérente. Un module noyau chargeable (LKM) peut masquer des fichiers au niveau des appels système, si bien que même un binaire fraîchement téléchargé verra un disque propre. Vous supprimez le mineur, la courbe d'utilisation CPU chute et le serveur devient silencieux. Le silence est aussi l'état d'une porte dérobée fonctionnelle.

La reconstruction coûte moins cher qu'il n'y paraît. Un VPS classique se résume à quelques paquets, un répertoire de configuration et un jeu de données ; la reconstruction est donc une tâche finie avec une fin claire. Traquer chaque modification effectuée par un attaquant est un processus sans fin qui n'aboutit jamais à une preuve de sécurité.

Confirmer qu'il s'agit bien d'un compromis

De nombreux serveurs signalés comme piratés ne le sont pas. Des milliers d'échecs de connexion SSH par jour constituent le bruit de fond d'Internet, car chaque adresse IPv4 publique est scannée en permanence. Une sortie lastb remplie de tentatives root et admin signifie que les scanners ont trouvé votre port. Cela ne signifie pas que quelqu'un a réussi à entrer.

Ces signaux, en revanche, sont révélateurs :

• Une connexion réussie que vous ne pouvez pas justifier, comme Accepted password for root from 203.0.113.7.
• Une clé dans authorized_keys que vous n'avez pas ajoutée.
• Un avis d'abus de la part de votre hébergeur concernant du trafic sortant de votre serveur.
• Un processus à 100 % de CPU portant un nom copié sur un thread du noyau. Les mineurs déposés via des sockets Redis ou Docker exposés sont couramment signalés sous des noms tels que kdevtmpfsi et kinsing.
• Des connexions sortantes vers des adresses qu'aucun de vos services n'utilise.

Le déguisement en thread du noyau peut être rapidement vérifié. Les vrais threads du noyau s'affichent entre crochets et n'ont aucun exécutable associé, donc sudo ls -l /proc/<pid>/exe échoue pour eux avec No such file or directory. Si un processus affiché comme [kworker/0:2] possède un lien exe pointant vers un emplacement sous /tmp, il s'agit d'un programme utilisateur ordinaire usurpant un nom de noyau.

Effectuez ces vérifications en gardant à l'esprit que la machine peut vous tromper. Ces tests suffisent à déterminer que quelque chose ne va pas. Ils ne suffisent pas à garantir qu'il n'y a aucun problème.

Coupez le réseau au niveau du fournisseur, pas depuis l'intérieur de la machine

L'isolation est la priorité, car chaque étape suivante est inutile tant qu'un tiers conserve un shell. Analyser les logs, renouveler les clés et restaurer des données ne servent à rien si un attaquant observe vos actions en temps réel.

Effectuez cette opération dans le panneau de contrôle de votre fournisseur, via le pare-feu réseau qui s'exécute en dehors de votre système d'exploitation. Bloquez le trafic entrant et sortant, et utilisez la console web comme seul accès. Les règles appliquées à ce niveau survivent à tout ce qui peut se produire sur le disque.

Il y a deux raisons de ne pas faire cela depuis l'intérieur du serveur. Un pare-feu configuré dans un noyau compromis est appliqué par ce même noyau, et root peut vider les règles nftables aussi facilement que vous les écrivez. De plus, sudo ip link set enp1s0 down via SSH coupe votre propre session en premier, ce qui vous verrouille hors d'une machine que vous étiez en train d'examiner.

Bloquez le trafic sortant autant que le trafic entrant. Un reverse shell établit une connexion depuis votre machine vers l'attaquant ; un blocage entrant seul laisserait une connexion établie fonctionner parfaitement. Si votre fournisseur ne propose que des règles entrantes, les options restantes sont le détachement de l'interface réseau ou l'extinction de l'instance.

Ne redémarrez pas encore. Vérifiez d'abord si /var/log/journal existe. Si ce répertoire est absent, journald écrit dans /run/log/journal, qui réside en mémoire vive ; un redémarrage effacerait donc toute trace de l'intrusion. Les processus en cours disparaissent également au redémarrage, alors que leurs lignes de commande constituent souvent la preuve la plus claire que vous pourrez obtenir.

Prenez un snapshot du disque avant toute intervention

Un snapshot et une sauvegarde remplissent ici des rôles différents. Le snapshot que vous effectuez maintenant est une copie d'un disque compromis : il constitue votre preuve et c'est le seul moyen de revenir en arrière si vous écrasez accidentellement un élément. Vos sauvegardes plus anciennes constituent votre chemin de restauration. Si l'interface de votre fournisseur utilise ces deux termes de manière imprécise, lisez d'abord en quoi les snapshots VPS diffèrent des sauvegardes réelles, car les règles de rétention et le comportement de restauration ne sont pas identiques.

Prenez le snapshot depuis l'interface du fournisseur avant de vous reconnecter. Un snapshot à chaud est cohérent en cas de crash : il capture le disque tel qu'il était à cet instant précis, comme si vous aviez coupé l'alimentation. C'est suffisant pour constituer une preuve. Nommez-le de manière à ce que personne ne le restaure par erreur. Un nom explicite comme COMPROMISED-do-not-restore-2026-08-12 est le niveau de subtilité approprié. Conservez-le jusqu'à ce que votre enquête soit terminée et que tout ticket d'abus auprès de votre hébergeur soit clos.

Comment accéder au serveur quand SSH ne répond plus

Il existe deux méthodes, toutes deux accessibles depuis le panneau de contrôle de votre hébergeur. La console web (VNC ou série) se connecte à la machine comme si vous y aviez branché un clavier physique. Elle fonctionne même si sshd est arrêté, si le pare-feu est mal configuré ou si un attaquant a modifié le port SSH. L'authentification se fait par mot de passe local ; si votre serveur n'accepte que les clés SSH, vous devrez peut-être réinitialiser le mot de passe root pour que la console soit utilisable.

Le mode rescue est la meilleure option. Il démarre un système live minimal avec votre disque monté en tant que stockage externe, sans exécuter votre système d'exploitation. Vos commandes sont donc fiables : le noyau et les binaires compromis ne sont pas en cours d'exécution. Montez le disque en lecture seule.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

Si lsblk affiche des volumes LVM (logical volume manager) au lieu d'une partition classique, activez-les d'abord avec sudo vgchange -ay, puis montez le périphérique qui apparaît sous /dev/mapper/.

N'utilisez pas chroot pour entrer dans le disque monté afin d'inspecter le système. Un chroot exécute les binaires de l'attaquant avec vos privilèges, ce qui annule tout l'intérêt du mode rescue.

Collecter les preuves encore fiables

Exécutez ces commandes depuis le mode rescue, avec le disque monté en lecture seule sur /mnt/victim. Commencez par les connexions, car elles datent l'intrusion et facilitent le reste une fois la fenêtre temporelle identifiée.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

L'absence de /var/log/auth.log n'est pas suspecte en soi. Certaines images Ubuntu actuelles sont livrées sans rsyslog, donc sshd journalise uniquement vers le journal, ce que lit la ligne journalctl -D. Ce qui mérite attention, c'est une interruption dans des journaux autrement continus, ou un fichier de log tronqué à zéro octet. Le nettoyage de logs est courant et souvent maladroit.

Ensuite, vérifiez les comptes et les clés.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

La ligne awk affiche tous les comptes avec un identifiant utilisateur 0. Tout résultat autre que root indique un second compte root. Le motif find correspond délibérément à authorized_keys2 également, car OpenSSH lit les deux noms de fichiers par défaut et le second est facile à ignorer. Si lsattr affiche un i dans la liste des attributs, le fichier est immuable : un attaquant définit ce flag pour que votre tentative de suppression de sa clé échoue avec Operation not permitted, et un administrateur fatigué supposera que la modification a fonctionné.

La persistance se cache dans un nombre restreint d'endroits, vérifiez-les tous.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

/etc/ld.so.preload n'existe pas sur un système Ubuntu ou Debian standard, donc No such file or directory est le résultat sain et tout contenu mérite votre attention. Un fichier de connexion qui redirige la sortie de base64 -d vers un shell relève du même constat : une configuration légitime n'a pas besoin de masquer son propre texte.

Établissez la chronologie à partir de la date de changement plutôt que de la date de modification.

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch définit la date de modification à n'importe quelle valeur choisie par l'attaquant, donc mtime est peu fiable. La date de changement (ctime) se met à jour lors de toute modification de l'inode, et touch ne peut pas la reculer, donc -newerct fournit une liste plus honnête de ce qui a été écrit récemment. Ce n'est toujours pas une preuve absolue, car root peut modifier l'horloge système ou écrire directement sur le périphérique bloc.

L'intégrité des paquets mérite une commande et une mise en garde. Sur un système en ligne, sudo dpkg --verify affiche une ligne pour chaque fichier de paquet dont la somme de contrôle ne correspond plus, avec un 5 dans la colonne de somme de contrôle, et sudo debsums -ac effectue le même travail en incluant les fichiers de configuration lorsque le paquet debsums est installé. Lisez le résultat dans un seul sens. Un /usr/sbin/sshd modifié est une preuve réelle. Un rapport propre ne prouve rien, car le même compte root qui a remplacé le binaire peut réécrire les listes de sommes de contrôle sous /var/lib/dpkg/info/. Les scanners de rootkits tels que rkhunter et chkrootkit suivent la même règle : une détection est une information, une exécution propre n'est pas une garantie d'absence de compromission.

Copiez ce que vous avez collecté hors de la machine avant toute action destructive.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

Notez ce hash quelque part en dehors du serveur. Si cela devient un dossier d'assurance ou un rapport de police, pouvoir démontrer que l'archive n'a pas changé depuis la collecte fait la différence entre une preuve et un simple dossier de fichiers. Supprimer des éléments par accident pendant une enquête est courant, et le snapshot combiné à cette archive permet de limiter les dégâts. Annuler une mauvaise commande rm est bien plus difficile qu'on ne le pense, comme l'explique la récupération de fichiers supprimés avec rm -rf.

Identifier la porte d'entrée

Une reconstruction qui ne ferme pas la route d'entrée vous expose à une nouvelle compromission, souvent en quelques jours, car le scan qui vous a détecté la première fois ne s'arrête jamais. Quatre portes couvrent la majorité des compromissions sur serveur unique.

Connexion SSH par mot de passe. Une ligne Accepted password for root provenant d'une adresse que vous ne reconnaissez pas est une réponse en soi. Vérifiez PasswordAuthentication dans /etc/ssh/sshd_config et dans chaque fichier sous /etc/ssh/sshd_config.d/. sshd utilise la première valeur obtenue pour un mot-clé, et la ligne Include se trouve en haut du fichier principal sur Ubuntu ; un fichier de configuration ajouté prend donc silencieusement le pas sur le paramètre que vous avez modifié plus bas.

Un service publié sans authentification. Redis sur 6379, l'API Docker sur 2375, une base de données liée à 0.0.0.0 au lieu de 127.0.0.1. Docker est la surprise classique. La publication d'un port de conteneur insère des règles DNAT (destination network address translation) qui sont évaluées avant les chaînes ufw. Ainsi, ufw status peut indiquer qu'un port est bloqué alors que le conteneur derrière répond à tout Internet. Comprenez cela avant la reconstruction : pourquoi les ports publiés par Docker contournent ufw détaille l'ordre des règles et la correction.

Une application web non corrigée. Recherchez dans le journal d'accès du serveur web, autour de votre première horodatage suspect, une requête POST vers un chemin d'upload ou un chemin d'administration, puis cherchez des fichiers sous la racine web ayant une date de modification correspondante. Un fichier PHP égaré dans un répertoire d'uploads est le résultat classique.

Un identifiant compromis. Une clé committée dans un dépôt, un jeton collé dans une discussion, un fichier .env servi comme fichier statique par un serveur web mal configuré. L'automatisation rend cela facile à faire par accident, ce qui justifie de garder les secrets hors des agents IA et de leurs fichiers de configuration.

Si vous ne parvenez pas à identifier la porte après tout cela, supposez qu'un identifiant a été compromis et considérez chaque secret détenu par la machine comme public.

Renouvelez toutes les informations d'identification auxquelles la machine a pu accéder

Effectuez la rotation après avoir coupé le réseau, jamais avant. Renouveler les secrets alors que l'attaquant possède toujours une connexion lui transmet simplement les nouveaux accès.

• Chaque clé privée SSH stockée sur le serveur, ainsi que chaque compte distant ayant fait confiance à la clé publique correspondante.
• Toute clé transmise sur la machine via ssh -A. Le transfert d'agent laisse une socket sous /tmp ; l'utilisateur root sur cette machine peut l'utiliser pour s'authentifier en votre nom partout où votre clé est acceptée, tant que votre session reste ouverte.
• Les jetons d'API présents dans les fichiers .env, dans les lignes Environment= de systemd, dans les configurations de CI et dans les identifiants des fournisseurs.
• Les mots de passe de base de données et les comptes applicatifs qui les utilisent.
• Les clés privées TLS (transport layer security) détenues par le serveur. Réémettez le certificat et révoquez l'ancien.
• Le mot de passe de votre compte d'hébergement, avec l'authentification à deux facteurs activée. Ce panneau de contrôle permet de reconstruire, de prendre des snapshots et d'accéder à la console de tous vos serveurs ; il constitue donc le véritable périmètre de sécurité.
• Tout mot de passe saisi dans une session shell sur cet hôte pendant qu'il était compromis, car l'utilisateur root peut enregistrer une session de terminal en temps réel.

Si un mot de passe utilisé sur cette machine est employé ailleurs, modifiez-le également sur ces autres services. La réutilisation est le moyen par lequel un VPS compromis devient un compte de messagerie compromis.

La liste de vérification pour la reconstruction

1. Créez un nouveau serveur à partir d'une image de distribution propre. N'utilisez ni le snapshot de la machine compromise, ni une restauration complète du système de fichiers racine.
2. Installez les paquets depuis les dépôts de la distribution. Ne copiez jamais un binaire depuis l'ancien disque.
3. Restaurez uniquement les données, à partir d'une sauvegarde datée d'avant la première preuve identifiée dans votre chronologie. Cela inclut les dumps de bases de données, les fichiers téléversés et l'état des applications. Laissez de côté /etc, /usr ainsi que les anciens fichiers d'unité.
4. Saisissez manuellement les secrets renouvelés. Ne copiez pas l'ancien .env.
5. Inspectez le contenu web restauré pour détecter tout fichier ajouté durant la période d'intrusion avant de le remettre en ligne.
6. Sécurisez le serveur avant de l'exposer : utilisez uniquement des clés SSH, un compte utilisateur sans privilèges root, un pare-feu configuré en refus par défaut, et ne publiez aucun service au-delà du strict nécessaire. Suivez les étapes pour les dix premières minutes sur un nouveau VPS, puis sécurisez SSH correctement, et ajoutez fail2ban sur Ubuntu 24.04 pour réduire le bruit dans les logs de connexion. Attribuez à chaque service son propre compte avec le privilège minimum afin qu'une future compromission ne donne pas accès au compte root.
7. Éteignez l'ancien serveur et conservez son snapshot jusqu'à la clôture de l'enquête et de tout ticket d'abus.
8. Corrigez vos sauvegardes. Si l'étape 3 a nécessité des suppositions, la leçon est que votre historique de sauvegarde était trop court pour remonter avant l'intrusion. Des sauvegardes versionnées hors site avec une longue rétention permettent d'obtenir un point de restauration sain la prochaine fois : les sauvegardes restic sur un VPS vous offrent les deux.

Si vous ne pouvez pas dater l'intrusion, vous ne pouvez pas choisir une sauvegarde sûre. Dans ce cas, restaurez uniquement les données que vous pouvez inspecter visuellement : un dump SQL lisible, un répertoire d'images que vous pouvez lister. Considérez tout exécutable comme suspect et réinstallez-le depuis les dépôts.

Ce que signifie l'avis d'abus de votre hébergeur

La plupart des utilisateurs apprennent que leur serveur a été compromis par leur hébergeur, et non par leur propre monitoring. Les hébergeurs détectent le trafic sortant : attaques par force brute SSH vers d'autres réseaux, spam sur le port 25, ou participation à une attaque par réflexion. Le ticket contient généralement des horodatages, des ports et un échantillon des flux, accompagnés d'un délai de quelques heures.

Répondez au ticket, même si votre seule réponse est que le serveur est isolé et en cours de réinstallation. Les hébergeurs appliquent un null-route ou suspendent un serveur lorsqu'un ticket reste sans réponse, ce qui transforme votre incident en interruption de service. Demandez ensuite les lignes de logs brutes à l'origine du signalement. Ces horodatages ont été enregistrés en dehors de votre machine ; ils constituent la seule partie de la chronologie que l'attaquant n'a pas pu modifier, et ils permettent souvent de dater l'intrusion plus précisément que n'importe quel élément sur le disque.

Un serveur client compromis est une procédure courante pour un hébergeur, et une gestion rigoureuse ne vous sera pas reprochée. La question plus large de savoir si l'hébergement VPS est sûr dépend principalement de la configuration effectuée par le client, ce qui est précisément la tâche que vous allez maintenant devoir refaire depuis zéro.

Quand faire appel à un professionnel

• Le serveur contenait des données personnelles appartenant à des tiers. Conformément au RGPD (Règlement général sur la protection des données), toute violation de données personnelles doit être notifiée à l'autorité de contrôle dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance. Déterminer si ce délai a commencé à courir relève du domaine juridique et non de l'administration système.
• Des données de cartes de paiement étaient concernées. Les réseaux de cartes exigent l'intervention d'un expert judiciaire agréé ; vos propres investigations pourraient compromettre le dossier.
• Vous faites l'objet d'une demande d'extorsion ou vos données ont été chiffrées.
• La machine pouvait accéder à d'autres équipements : réseau interne, hyperviseur, ou runner CI contenant des identifiants de production. Un hôte compromis au sein d'un groupe constitue un incident touchant l'ensemble du groupe jusqu'à preuve du contraire.
• Vous aurez besoin que les preuves soient recevables pour une assurance ou les forces de l'ordre. Arrêtez-vous au snapshot, effectuez une image disque complète et consignez qui a manipulé les données et à quel moment.

Pour un VPS unique hébergeant vos propres services, sans données appartenant à autrui, la procédure ci-dessus constitue l'intégralité du travail. Isolez le serveur via l'interface du fournisseur. Prenez un snapshot pour les preuves. Récupérez ce qui est encore fiable. Renouvelez tous les secrets. Réinstallez proprement.

FAQ

Puis-je nettoyer un VPS compromis au lieu de le réinstaller ?

Non, pas avec certitude, car vous demanderiez au système compromis de faire son propre rapport. Un ps remplacé masque un processus, une ligne dans /etc/ld.so.preload injecte du code dans chaque outil lié dynamiquement que vous exécutez, et un module noyau peut masquer des fichiers à tous les programmes simultanément. Vous pouvez trouver des preuves, donc un résultat positif est significatif. Vous ne pouvez pas démontrer l'absence de menace, donc un résultat « propre » n'est pas fiable. Le nettoyage n'est défendable que si le serveur ne contient rien d'important et que vous acceptez le risque d'une nouvelle compromission.

Dois-je éteindre un serveur compromis ou le laisser tourner ?

Coupez d'abord son accès réseau via votre fournisseur, puis laissez-le allumé assez longtemps pour effectuer un snapshot et examiner les processus en cours. Éteindre le serveur détruit la liste des processus et supprime intégralement le journal si /var/log/journal n'existe pas, car journald écrit alors en mémoire sous /run. Éteignez-le tout de même s'il attaque activement d'autres réseaux et que vous n'avez aucun moyen de bloquer son trafic sortant. Stopper les dommages est prioritaire sur la conservation des preuves.

Comment déterminer quand l'attaquant s'est introduit ?

Recherchez la première ligne Accepted password ou Accepted publickey que vous ne pouvez pas expliquer, dans /var/log/auth.log ou dans le journal. Croisez cette information avec une liste des temps de changement, find / -xdev -newerct 'YYYY-MM-DD' -type f, car le ctime est plus difficile à falsifier que le mtime. Comparez ensuite ces deux éléments avec les horodatages du ticket d'abus de votre fournisseur, qui ont été enregistrés hors de la machine et ne peuvent pas être modifiés. Choisissez une sauvegarde antérieure à la plus ancienne de ces trois dates. Si rien ne concorde, supposez que la compromission est plus ancienne que votre historique de sauvegarde et ne restaurez que les données que vous pouvez inspecter.

Mes sauvegardes sont-elles sûres à restaurer après une compromission ?

Les données le sont généralement, après inspection. Les fichiers système ne le sont pas. Une sauvegarde effectuée après l'intrusion contient la porte dérobée ; restaurer tout le système de fichiers racine restaure donc aussi l'attaquant. Vérifiez également le dépôt de sauvegarde lui-même : si les identifiants d'accès étaient stockés sur le serveur compromis, l'historique a pu être supprimé ou altéré. C'est pourquoi il est recommandé d'utiliser des cibles de sauvegarde en mode « append-only » ou basées sur une récupération (pull). Restaurez les données applicatives, puis réinstallez les logiciels depuis les dépôts de votre distribution.

Dois-je signaler la compromission de mon VPS ?

Répondez toujours à l'avis d'abus de votre hébergeur. Au-delà, cela dépend des données présentes sur la machine. Les données personnelles appartenant à des tiers peuvent déclencher une obligation légale de signalement, comme le délai de 72 heures imposé par le RGPD pour notifier une autorité de contrôle. Si des identifiants d'utilisateurs étaient stockés sur le serveur, informez ces utilisateurs afin qu'ils puissent changer leurs mots de passe ailleurs. Si des clés présentes sur la machine autorisaient l'accès à des systèmes tiers, comme un hébergeur de code ou un compte cloud, prévenez ces fournisseurs afin qu'ils puissent vérifier s'il y a eu usage abusif. Un serveur purement personnel ne contenant aucune donnée tierce n'entraîne aucune obligation au-delà de la réponse au ticket d'abus.