Aller au contenu

Étude de cas · Sécurité & maintenance

Reprise d’un site compromis : audit du compte, nettoyage et remise à plat

Un site en erreur 500 sans sauvegarde exploitable : la procédure complète, montrée sur un site qui m'appartient.

Rôle : Diagnostic, nettoyage et reconstruction Client : Cas interne — un site que j'exploite moi-même
Rôle tenu
Diagnostic, nettoyage et reconstruction
Client final
Cas interne — un site que j'exploite moi-même
Socle technique
WordPress · PHP · hébergement mutualisé (cPanel + accès SSH)
Périmètre
Site hors ligne, audit du compte d'hébergement, purge des accès, remise en ligne
WordPressPHPcPanelSSH

Cette étude de cas porte sur un de mes propres sites, et c’est volontaire : un incident de sécurité appartient à celui qui l’a subi. Je ne publie pas ceux de mes clients, même anonymisés. Celui-ci m’appartient, je peux donc en montrer la procédure complète — c’est exactement celle que j’applique quand on me confie un site compromis.

Ce qui s’est passé

Le site s’est retrouvé en erreur 500, avec une suspicion d’infection. Deux aggravants classiques : aucune sauvegarde exploitable au moment de l’incident, et une incertitude sur ce qui avait été déployé en dernier. C’est la situation dans laquelle arrivent la plupart des demandes de dépannage — rarement un site propre avec un historique clair.

La première règle : le périmètre n’est pas le site

L’erreur la plus répandue est de nettoyer le site et de le remettre en ligne. Sur un hébergement mutualisé, le périmètre compromis est le compte entier, pas le dossier du site : les autres sites hébergés sur le même compte, les tâches planifiées, les boîtes mail, les accès. Nettoyer le site seul, c’est se faire réinfecter dans la semaine.

La procédure appliquée

  • Audit de l’ensemble du compte d’hébergement, et non du seul site en panne ;
  • Purge des clés SSH — toutes celles qui n’étaient pas formellement reconnues ont été retirées ;
  • recherche des portes d’entrée : extensions abandonnées, versions de PHP dépassées, fichiers déposés hors des emplacements attendus, extensions chargées automatiquement ;
  • reconstruction propre plutôt que réparation, quand l’état du site ne permet pas de garantir qu’il ne reste rien ;
  • vérification du second compte d’hébergement, pour s’assurer que l’incident ne s’était pas propagé.

Ce que j’en retiens, et ce que je propose ensuite

Une remise en ligne n’est pas une fin : sans sauvegardes vérifiées et sans durcissement, le même incident se reproduit. C’est la partie que les clients arbitrent souvent à la baisse dans l’urgence, et c’est celle qui coûte le plus cher la fois suivante. Je le dis avant, pas après.

À voir aussi : Sécurisation et dépannage · Maintenance et TMA.

f
FullDo

Studio de développement web full-stack & IA — Drupal, DSFR, accessibilité.