En bref : avant de réinstaller un serveur compromis, sécurisez les preuves dans l'ordre de leur volatilité : d'abord les processus, les connexions et les utilisateurs connectés, puis les journaux et la configuration, puis une image complète du système et les données des services en amont. Chaque sauvegarde reçoit une somme de contrôle et est stockée en dehors du serveur. Pour cela, le serveur est déconnecté du réseau, mais pas éteint.
Le réflexe de tout réinstaller aussitôt
Quiconque découvre une intrusion veut y mettre fin le plus vite possible. Un système neuf, installé proprement, avec de nouveaux mots de passe : cela donne l'impression de reprendre le contrôle. Techniquement, une reconstruction est souvent aussi la bonne voie, surtout si un attaquant a eu les droits root.
Le problème, c'est le moment. Avec l'ancien système disparaissent toutes les réponses aux questions qui se poseront dans les jours suivants. Par quelle faille l'attaquant est-il entré ? Depuis quand était-il dans le système ? Avait-il accès aux données clients ? Le serveur de base de données voisin est-il lui aussi touché ? Sans traces, il ne reste que des suppositions, et elles n'aident ni pour la protection des données ni pour l'assurance.
Avec PHP2Shell s'ajoute un point particulier : il n'existe pas d'indicateurs de compromission (IoC) publiés et confirmés. Savoir si un serveur a été touché, et comment, ne se lit que dans son comportement, donc précisément dans les traces qu'une reconstruction précipitée efface. La presse spécialisée conseille de conserver les journaux du serveur à partir du 20 octobre 2026.
Préservation des preuves sur le serveur : l'ordre compte
Les traces ne sont pas toutes aussi volatiles. Ce qui se trouve en mémoire vive disparaît au prochain redémarrage. Les journaux survivent plus longtemps, mais sont soumis à rotation. Les données des services en amont disparaissent selon leurs propres délais. L'ordre en découle :
| Trace | Volatilité | Comment la sauvegarder |
|---|---|---|
| Processus, connexions réseau, utilisateurs connectés | disparaît au redémarrage | écrire les sorties des commandes système dans des fichiers |
| Mémoire vive | disparaît au redémarrage | uniquement avec un outil spécialisé, tâche pour des experts en forensique |
Fichiers temporaires dans /tmp ou /dev/shm |
souvent supprimés au redémarrage | copier, sans exécuter |
| Journaux du serveur web, de PHP, du système | soumis à rotation | copier intégralement, suspendre la rotation |
| Système de fichiers et base de données | stable jusqu'à la réinstallation | instantané ou image de disque, export de la base de données |
| CDN, WAF, pare-feu, hébergeur | conservation selon les délais du fournisseur | demander un export, le faire confirmer par écrit |
Ne sauvegardez la mémoire vive que si quelqu'un disposant de l'outil adapté et de l'expérience est disponible. Pour les systèmes contenant des données sensibles ou en cas de litige prévisible, c'est une analyse forensique informatique qui devrait s'en charger.
Fixer les données volatiles en quelques minutes
Les commandes suivantes ne modifient rien sur le système. Elles écrivent l'état actuel dans des fichiers qui sont ensuite sauvegardés en dehors du serveur. Créez si possible le répertoire cible sur un support séparé et connecté :
ZIEL=/mnt/sicherung/fall-$(date -u +%Y%m%dT%H%MZ)
mkdir -p "$ZIEL"
date -u > "$ZIEL/zeitpunkt-utc.txt"
ps auxwwf > "$ZIEL/prozesse.txt"
ss -tunap > "$ZIEL/verbindungen.txt"
who -a > "$ZIEL/angemeldet.txt"
last -F > "$ZIEL/anmeldungen.txt"
ip addr > "$ZIEL/netz.txt"; ip route >> "$ZIEL/netz.txt"
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done > "$ZIEL/cronjobs.txt"
sha256sum "$ZIEL"/* > "$ZIEL.sha256"
La manière de sauvegarder ensuite intégralement les journaux et de les analyser est décrite dans le guide Analyser les journaux du serveur web après une attaque. Pour les serveurs virtuels, un instantané via l'interface de gestion du fournisseur est le moyen le plus simple d'obtenir une image complète. Il capture le système sans que vous ayez à lancer d'autres outils sur le serveur compromis.
Pour que la sauvegarde ait une valeur plus tard
Une sauvegarde ne vaut que par sa preuve. Trois règles la rendent fiable :
- Sommes de contrôle : chaque fichier sauvegardé reçoit une somme de contrôle SHA-256. Elle permet de montrer plus tard que la copie est inchangée.
- Journal : qui a sauvegardé quoi, quand, avec quelle commande, vers où ? Chaque remise à un tiers est consignée. Les spécialistes appellent cela la chaîne de conservation des preuves.
- Stockage séparé : les copies doivent se trouver sur un système auquel l'attaquant n'a pas eu accès, et n'être réutilisées qu'en lecture seule.
Ensuite, ne travaillez plus qu'avec des copies. Toute analyse sur l'original modifie les horodatages et peut écraser des traces. N'exécutez jamais de fichiers suspects et ne les ouvrez pas dans le navigateur.
Demandez tôt les journaux du CDN, du WAF et de l'hébergeur. Ces données se trouvent en dehors de votre serveur et sont difficiles à manipuler pour un attaquant, mais elles ne sont souvent conservées que brièvement.
Ce qui détruit les preuves
Beaucoup de traces ne sont pas perdues à cause de l'attaquant, mais à cause de premiers secours bien intentionnés. Ces actions devraient être évitées avant la sauvegarde :
- Redémarrage ou extinction : processus, connexions et mémoire vive sont ensuite perdus.
- Antivirus avec suppression automatique : il supprime des fichiers avant que quiconque les ait sauvegardés et modifie les horodatages.
- Nettoyage des journaux ou des dossiers temporaires : même si la place manque, d'abord copier, ensuite supprimer.
- Installer sur le serveur de nouveaux outils téléchargés sur Internet : chaque installation écrit dans le système de fichiers et peut recouvrir des traces.
- Connexion avec des identifiants privilégiés sans nécessité : si du code malveillant tourne encore sur le serveur, les mots de passe saisis peuvent être lus.
Les assureurs, en particulier, demanderont plus tard ce qui a été sauvegardé et quand. Des indications sur les obligations typiques figurent dans Cyberassurance : ce qui compte en cas de sinistre.
Arbitrer : de combien de temps dispose-t-on pour la sauvegarde ?
Tous les incidents ne permettent pas une longue sauvegarde. Si une fuite de données est en cours ou si des visiteurs sont attaqués, le confinement est prioritaire. La déconnexion du réseau sur un système en fonctionnement concilie les deux : l'attaquant perd l'accès, les traces sont conservées. Pour la plupart des serveurs web, un laps de temps raisonnable suffit ensuite pour les données volatiles et l'instantané.
Prenez la décision en connaissance de cause et consignez-la : qui a décidé du moment de la réinstallation, et qu'est-ce qui a été sauvegardé auparavant ? Cette note fera plus tard partie de la chronologie de l'incident. L'article Réinstaller le serveur ou le nettoyer ? examine si la reconstruction ou le nettoyage est la bonne voie.
Comment PHP SOS aide-t-il concrètement ?
- Nous sauvegardons données volatiles, journaux et images système dans le bon ordre, avec sommes de contrôle et journal.
- Nous demandons les données des services en amont avant l'expiration de leurs délais de conservation.
- Si nécessaire, nous assurons avec des partenaires spécialisés la sauvegarde et l'analyse forensiques.
- Ce n'est qu'ensuite que nous reconstruisons le serveur, fermons la porte d'entrée et documentons l'incident jusqu'à sa clôture.
Questions fréquentes
Pourquoi préserver les preuves avant de réinstaller ?
Parce que seules les traces montrent comment l'attaquant est entré, combien de temps il est resté dans le système et à quelles données il a pu accéder. Vous avez besoin de ces réponses pour la protection des données, l'assurance et pour savoir si d'autres systèmes sont touchés. Après la reconstruction, elles sont perdues.
Qu'est-ce qui est le plus urgent lors de la sauvegarde ?
Les données volatiles, comme les processus en cours, les connexions réseau et les utilisateurs connectés, disparaissent à l'arrêt. On les fixe en premier. Viennent ensuite les journaux, une image du système et les données des services en amont.
Une sauvegarde normale suffit-elle comme préservation des preuves ?
Le plus souvent non. De nombreuses sauvegardes ne contiennent ni journaux, ni fichiers système, ni métadonnées telles que les horodatages et les propriétaires. Pour la préservation des preuves, il faut une copie complète et inchangée avec somme de contrôle, idéalement un instantané ou une image de disque.
Puis-je déconnecter le serveur du réseau avant la sauvegarde ?
Oui, s'il continue de fonctionner. Une déconnexion du réseau arrête la fuite de données et le contrôle à distance sans détruire les traces volatiles. Un redémarrage ou une extinction, en revanche, efface la mémoire vive et les processus en cours.