Le risque principal : rouvrir la même porte
Quand un serveur semble compromis, la tentation est de réinstaller vite ou de restaurer une sauvegarde. C'est parfois nécessaire, mais ce n'est pas suffisant si le compte, la clé SSH, le panel, le plugin ou le service utilisé par l'attaquant reste actif. Le serveur peut redevenir compromis quelques heures plus tard.
La bonne séquence est simple : isoler, conserver les preuves, identifier les accès critiques, vérifier les sauvegardes, puis décider de la reprise. Même une analyse courte permet d'éviter les erreurs les plus coûteuses.
Ce qu'il faut vérifier en priorité
- SSH : comptes, clés, root login, connexions récentes, IP inhabituelles ;
- services : ports ouverts, processus inconnus, services lancés automatiquement ;
- webroot : fichiers modifiés, uploads, backdoors, scripts inconnus ;
- cron et tâches planifiées : relance de scripts, téléchargements, persistance ;
- hébergeur et DNS : accès panel, domaine, Cloudflare, redirections ;
- sauvegardes : date saine, restauration testable, compte séparé.
Preuves utiles à conserver
Il n'est pas nécessaire de produire une investigation lourde pour commencer. Il faut surtout éviter de perdre les traces simples : captures d'alertes, liste des fichiers modifiés, derniers accès SSH, logs web, chronologie des actions, IP inhabituelles, comptes concernés, sauvegardes disponibles.
Ces éléments permettent de classer les risques et de comprendre ce qui doit être fermé avant la reprise.
Quand demander un regard externe
Un regard externe est utile si l'entreprise ne sait pas quel accès est touché, si le serveur contient des données clients, si plusieurs prestataires ont eu des accès, si l'hébergeur a envoyé une alerte, ou si la restauration n'est pas claire.
Avec un accès temporaire ou une prise en main encadrée, l'analyse peut produire une liste rankée des risques observés avec les preuves associées.