Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

Écrire un message contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Sécuriser sa boutique après un piratage : ce qui doit changer

Un site nettoyé mais remis en ligne exactement comme avant retombe souvent dans le même état en quelques mois, parce que rien n’a changé dans la façon dont il est maintenu. L’ordre des opérations juste après l’incident compte, mais il referme seulement l’incident. Voici ce qui doit ensuite devenir une habitude, pas une action ponctuelle.

Décrire mon problème Écrire un message

Avant les habitudes : l’ordre des premières opérations

Cette page suppose le nettoyage fait. S’il ne l’est pas encore, l’ordre compte autant que les opérations elles-mêmes : remettre une boutique piratée en ligne sans avoir traité la cause revient à laisser la porte ouverte, et l’infection revient en général en quelques jours.

  1. Isoler la boutique : maintenance ou coupure temporaire, pour limiter la propagation et l’exposition des visiteurs pendant l’intervention.
  2. Changer tous les mots de passe : administration du CMS, FTP/SFTP, base de données, panneau d’hébergement. Un seul accès laissé inchangé suffit à réinfecter le site après nettoyage.
  3. Supprimer les comptes administrateurs inconnus : un compte créé par l’attaquant est l’une des portes dérobées les plus fréquentes, et il se retire avant même le nettoyage des fichiers.
  4. Comparer les fichiers à une installation propre de la même version : les fichiers modifiés ou ajoutés sont la trace la plus directe d’une infection.
  5. Vérifier la base de données : du code malveillant s’injecte aussi dans des champs de configuration ou de contenu, pas seulement dans les fichiers.
  6. Mettre à jour l’ensemble des composants : la faille exploitée provient très souvent d’un composant obsolète.
  7. Remettre en ligne, puis surveiller les journaux et l’activité des jours suivants, pour vérifier qu’aucune porte dérobée n’a été oubliée.

Cette séquence referme l’incident. Elle ne change rien à ce qui l’a rendu possible : c’est l’objet du reste de cette page.

  • 39,1 % des applications CMS compromises tournaient sur une version obsolète au moment de l’infection
  • 13,97 % des sites compromis avaient au moins une extension ou un thème vulnérable au moment de la remédiation

Sucuri, Hacked Website & Malware Threat Report 2023

Six habitudes structurelles

  1. Une politique de mise à jour, pas des mises à jour au coup par coup

    CMS, thème et modules ou extensions doivent être vérifiés à intervalle régulier, pas seulement quand un problème apparaît. Le rapport Sucuri cité plus haut montre qu’une version obsolète était impliquée dans plus d’un tiers des compromissions étudiées : c’est une corrélation constatée, pas une cause démontrée, mais elle suffit à en faire une priorité.

  2. Suivre les avis de sécurité de ce qui est installé

    Une faille publiée dans un module ou une extension laisse une fenêtre avant son exploitation réelle. Savoir où suivre ces publications selon le CMS utilisé change la donne pour agir avant d’être concerné.

  3. Supprimer ce qui n’est plus utilisé

    Un module désactivé mais toujours présent sur le serveur reste une porte d’entrée potentielle : la désactivation dans l’administration n’empêche pas l’exécution d’un fichier PHP appelé directement depuis son chemin.

  4. Revoir régulièrement les accès et les mots de passe

    Comptes administrateur créés « pour dépanner » et jamais supprimés, accès FTP donné à un ancien prestataire, mot de passe réutilisé ailleurs : une revue périodique de qui a accès à quoi referme des portes ouvertes sans qu’on s’en souvienne.

  5. Tester une sauvegarde, pas seulement la programmer

    Une sauvegarde qui existe mais n’a jamais été restaurée pour de vrai peut être incomplète, corrompue, ou sauvegarder l’infection elle-même sans le savoir. La tester périodiquement sur un environnement séparé est la seule façon de savoir qu’elle sera utilisable le jour où elle servira.

  6. Ajouter une surveillance ou un pare-feu applicatif

    Un pare-feu applicatif filtre une partie du trafic malveillant avant qu’il n’atteigne le CMS, et une surveillance de l’intégrité des fichiers signale une modification suspecte rapidement plutôt que des semaines plus tard. Aucun des deux ne remplace la mise à jour, mais les deux réduisent la fenêtre d’exposition.

Ce qui complète cette démarche

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’avez-vous constaté ?
Depuis quand le problème est-il constaté ?

Plus l’infection est ancienne, plus elle a pu se propager dans les fichiers et la base de données.

Disposez-vous d’une sauvegarde saine ?
Avez-vous encore accès à l’administration WordPress ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Une sauvegarde suffit-elle si je ne la teste jamais ?
Non. Une sauvegarde jamais restaurée pour de vrai peut être incomplète ou corrompue sans que personne ne le sache, jusqu’au jour où elle est censée servir. La tester régulièrement fait partie de la sauvegarde elle-même, pas d’une étape optionnelle.
Faut-il supprimer un module même s’il fonctionne encore ?
Oui, s’il n’est plus utilisé ou plus maintenu par son éditeur. Le risque ne dépend pas de si le module fonctionne encore, mais de si des correctifs de sécurité continuent d’être publiés pour lui.
À quelle fréquence dois-je vérifier les mises à jour disponibles ?
De façon régulière, sans qu’un chiffre unique convienne à toutes les situations. Un déclencheur fiable est chaque avis de sécurité publié concernant un composant installé, ce qui suppose de suivre ces publications plutôt que d’attendre une alerte de l’hébergeur.
Un pare-feu applicatif remplace-t-il les mises à jour ?
Non, il les complète. Il filtre une partie des tentatives d’exploitation, mais une faille non corrigée reste une faille : un pare-feu applicatif réduit l’exposition, il ne la supprime pas.
Dois-je changer mes mots de passe même si rien d’anormal n’a été observé récemment ?
Oui, périodiquement, et systématiquement après tout accès partagé avec un tiers, un prestataire ou un ancien collaborateur qui n’a plus besoin d’y accéder.
Google ou le navigateur avertit encore les visiteurs après le nettoyage, que faire ?
Une fois le nettoyage confirmé, une demande de réexamen se soumet depuis Google Search Console. Le délai de retrait de l’avertissement dépend ensuite du traitement de la demande. Tant que la faille d’origine n’est pas refermée, un nouveau signalement reste possible dans les jours qui suivent : c’est une raison de plus pour traiter la cause avant de demander le réexamen.

Pages liées