Quand les choses tournent mal

Module 10: Rester en sécurité · Temps de lecture : 11 minutes

Objectif pédagogique : Après cette leçon, vous reconnaissez les signes d'un serveur piraté, vous effectuez les premières actions sans détruire de preuves ni de sauvegardes, vous choisissez entre nettoyer et réinstaller, et vous savez quand vous devez notifier une violation de données.

Notions clés : incident, signes, isolement, snapshot comme preuve, journal de l'incident, réinstallation, remplacement des clés et des mots de passe, sauvegarde saine, obligation de notifier une violation de données (72 heures), CNIL, plan d'urgence

Reconnaître un incident

Une intrusion s'annonce rarement. Le plus souvent, vous remarquez simplement quelque chose de « bizarre ». Voici les signes à prendre au sérieux :

• Une charge élevée sans raison : le processeur tourne en permanence à 100 %, par exemple à cause d'un cryptomineur. Vérifiez avec top ou htop de quel processus il s'agit, et sous quel utilisateur il tourne.
• Des processus ou services inconnus : un programme au nom étrange, souvent dans /tmp, /dev/shm ou /var/tmp, ou un service ou timer systemd que vous n'avez pas créé vous-même.
• Un trafic sortant anormal : votre hébergeur vous signale que votre serveur envoie du spam ou attaque d'autres serveurs, ou les graphiques réseau du panneau montrent des pics.
• De nouveaux utilisateurs ou de nouvelles clés : une ligne inconnue dans ~/.ssh/authorized_keys, un utilisateur avec l'UID 0 dans /etc/passwd, une nouvelle ligne dans /etc/sudoers.d/.
• Des fichiers modifiés : des fichiers PHP inconnus dans votre site web, une crontab modifiée.
• Des journaux disparus ou vides : les attaquants aiment effacer leurs traces.

Quelques commandes pour jeter rapidement un coup d'œil :

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last indique qui s'est connecté et quand, la ligne awk affiche tous les comptes avec l'UID 0 (seul root devrait en faire partie), et la ligne find recherche les units et les fichiers cron plus récents qu'un fichier créé lors de l'installation.

Attention : sur un serveur réellement compromis, ces commandes peuvent elles aussi avoir été falsifiées. Elles vous aident à soupçonner un problème, pas à prouver que tout est sain.

Les premières actions : rester calme, isoler, consigner

Dans les premières minutes, l'essentiel est de ne pas supprimer des choses dans la panique. Procédez dans cet ordre.

1. Commencez un journal. Notez sur papier ou sur votre ordinateur portable (pas sur le serveur) ce que vous constatez, à quel moment, et ce que vous faites. Vous en aurez besoin plus tard pour trouver la cause, pour une notification, une plainte ou votre assurance. Le NCSC néerlandais le recommande également.

2. Isolez le serveur. Empêchez-le de causer davantage de dégâts (spam, attaques, envoi de données) sans l'éteindre :

• dans le pare-feu de votre hébergeur (s'il en propose un), fermez tout sauf SSH depuis votre propre adresse ; ou
• faites la même chose sur le serveur lui-même, via la console ;
• s'il n'y a pas d'autre solution : éteignez le serveur depuis le panneau. Vous perdez alors le contenu de la mémoire.

3. Créez un snapshot. Un snapshot dans le panneau fige l'état actuel du serveur. C'est votre preuve et votre source pour découvrir plus tard comment l'attaquant est entré, même si vous réinstallez ensuite le serveur.

4. Mettez vos sauvegardes à l'abri. Vérifiez que vos sauvegardes hors du serveur sont toujours intactes, et faites en sorte que le serveur piraté ne puisse plus y accéder (par exemple en révoquant la clé d'accès du serveur au stockage de sauvegarde). Les attaquants tentent aussi d'effacer ou de chiffrer les sauvegardes.

Nettoyer ou réinstaller ?

La réponse tentante est : supprimer le fichier suspect, arrêter le cryptomineur, et c'est fini. Mais vous ne savez pas ce que l'attaquant a fait d'autre : une deuxième porte dérobée, un programme modifié, une clé supplémentaire, un timer qui remet tout en place. Un serveur sur lequel quelqu'un a obtenu les droits root n'est plus digne de confiance.

Le conseil des administrateurs, et aussi du NCSC néerlandais, est donc : réinstallez les systèmes touchés et restaurez vos données depuis une sauvegarde qui n'est pas elle-même infectée. Concrètement :

1. Une nouvelle installation (réinstallation depuis le panneau, ou un nouveau serveur).
2. Immédiatement, les bases de cette formation : mises à jour, utilisateur ordinaire avec sudo, SSH avec de nouvelles clés, pare-feu (modules 2 à 5).
3. Réinstaller vos applications depuis les sources officielles, de préférence à l'aide de vos fichiers compose ou de vos notes (leçon 10.4).
4. Restaurer les données (base de données, fichiers envoyés) depuis une sauvegarde antérieure à l'incident. Ne restaurez pas le code ni la configuration à l'aveugle : ils peuvent contenir la porte dérobée. Examinez aussi d'un œil critique les données restaurées ; un attaquant peut être présent depuis plus longtemps que vous ne le pensez.
5. Combler la faille par laquelle l'attaquant est entré. Sinon, cela se reproduira. Le snapshot de l'étape 3 vous aide dans cette recherche.

Remplacer tout ce qui a pu fuiter

Partez du principe que tout ce qui se trouvait sur le serveur est entre les mains de l'attaquant :

• Clés SSH : retirez partout les clés publiques qui se trouvaient sur le serveur, et créez de nouvelles paires de clés si des clés privées y étaient stockées.
• Mots de passe des bases de données, des panneaux d'administration et des utilisateurs de votre application.
• Clés d'API et jetons (e-mail, paiements, stockage cloud, stockage de sauvegarde) présents dans les fichiers .env et la configuration : révoquez-les auprès du service concerné et remplacez-les.
• Certificats : la clé privée de votre certificat se trouvait sur le serveur. Faites révoquer le certificat et demandez-en un nouveau (avec Let's Encrypt, c'est rapide, leçon 7.3).

Notifier : le RGPD et les autres

Si le serveur contenait des données personnelles (données clients, comptes, adresses e-mail), il s'agit peut-être d'une violation de données. Le RGPD (article 33) prévoit que le responsable du traitement notifie une violation de données à l'autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance. En France, il s'agit de la CNIL, et la notification se fait via son téléservice en ligne. Quelques points à retenir :

• la notification n'est pas nécessaire si la violation n'est pas susceptible d'engendrer un risque pour les personnes concernées ; en cas de doute, notifiez ;
• si vous ne disposez pas encore de toutes les informations, notifiez quand même dans les 72 heures et complétez ensuite ;
• vous informez les personnes dont les données ont fuité lorsqu'il existe un risque élevé pour elles ;
• vous consignez chaque violation de données dans un registre dédié, même si vous n'êtes pas tenu de la notifier.

Si vous gérez le serveur pour un client, vous êtes généralement sous-traitant : vous devez alors informer le client (le responsable du traitement) dans les meilleurs délais, afin qu'il puisse notifier. Cette leçon ne constitue pas un conseil juridique ; en cas de doute, consultez le site de la CNIL.

Par ailleurs : signalez à votre hébergeur les abus commis depuis votre serveur (il les a souvent déjà remarqués), et en cas d'attaque grave, portez plainte auprès de la police ou de la gendarmerie. Si votre organisation relève de la directive NIS2, des délais de notification distincts et plus courts s'appliquent ; la transposition française de NIS 2 est en cours sous le pilotage de l'ANSSI et n'est pas encore en vigueur début novembre 2026.

Se préparer : le plan d'urgence

Un incident survient toujours au mauvais moment. Ce que vous avez préparé à l'avance vous fait gagner des heures :

• Sachez comment accéder à la console et au bouton de snapshot de votre hébergeur, et conservez vos identifiants du panneau (avec authentification à deux facteurs) quelque part en dehors du serveur.
• Sachez où se trouvent vos sauvegardes, comment les restaurer et qu'elles fonctionnent (leçon 8.2).
• Tenez une liste de tous les secrets présents sur le serveur, afin de savoir ce que vous devez remplacer.
• Tenez une liste de contacts : votre hébergeur, les personnes qui doivent être informées au sujet du serveur (client, collègue), et les coordonnées pour une notification de violation de données.

En pratique

Dans l'écran VPS de WebOké, vous trouvez la console, les snapshots, les sauvegardes et le bouton de réinstallation ; chez d'autres hébergeurs, ces fonctions portent à peu près les mêmes noms (console ou VNC, snapshot, rescue, reinstall). Cette formation est en autonomie : personne ne surveille votre serveur et personne ne gère un incident à votre place. C'est justement pour cela qu'un plan d'urgence que vous pouvez exécuter vous-même est si important.

Résumé

• Signes : charge inexpliquée, processus, services ou clés inconnus, trafic sortant étrange, fichiers et journaux modifiés ou disparus.
• Premières actions : tenir un journal, isoler le serveur, créer un snapshot comme preuve, mettre les sauvegardes à l'abri.
• Un serveur sur lequel quelqu'un a eu les droits root ne se nettoie pas, il se réinstalle ; les données sont restaurées depuis une sauvegarde saine, et la faille est comblée.
• Remplacez toutes les clés, tous les mots de passe, jetons et certificats qui se trouvaient sur le serveur.
• Des données personnelles sont touchées ? Une violation de données se notifie à la CNIL, si possible dans les 72 heures, et vous consignez chaque violation.

Quiz

Exercice

Exercice O10.3 : Votre plan d'urgence sur une seule page. Rédigez pour votre propre serveur un plan d'urgence d'une page A4 au maximum : comment accédez-vous au panneau, à la console et aux snapshots ; où se trouvent vos sauvegardes et comment les restaurez-vous ; quels secrets se trouvent sur le serveur ; qui devez-vous informer (et devez-vous notifier en cas de violation de données) ; et quelles sont les cinq premières actions que vous menez si vous soupçonnez une intrusion. Conservez ce plan en dehors du serveur.

Pour aller plus loin

• Plus d'accès à votre VPS : que faire ?
• Snapshots et sauvegardes de votre VPS
• Monter votre propre ISO ou réinstaller votre VPS
• NCSC néerlandais, « Gehackt, wat nu? » (source néerlandaise, en néerlandais) : https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• CNIL, Notifier une violation de données personnelles : https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles