É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 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
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.
Studio de développement web full-stack & IA — Drupal, DSFR, accessibilité.