Nettoyer un site WordPress infecté, c’est souvent le moment où l’on respire enfin. Le code malveillant a disparu, la page d’accueil ne renvoie plus une redirection bizarre, les comptes administrateurs n’ont plus l’air “piratés”. Puis, quelques jours plus tard, parfois quelques semaines, l’histoire recommence. Pas forcément avec la même charge utile. Parfois, c’est un accès persistant oublié, parfois une faiblesse restée en place, parfois une configuration qui rend la réinfection facile.
Le durcissement (hardening) après nettoyage sert à une chose très concrète: rendre l’environnement moins accueillant, limiter ce qui peut être modifié à distance, réduire les surfaces d’attaque et surtout éviter de “nettoyer” en boucle sans corriger la cause.
Dans ce billet, je vous propose une approche pragmatique, pensée pour des sites WordPress réellement exposés, pas pour des laboratoires. Vous verrez aussi où j’ai déjà vu des équipes se faire piéger, et comment arbitrer quand il faut choisir entre sécurité et confort.
Pourquoi le nettoyage ne suffit pas
Quand un site est compromis, l’attaquant peut viser plusieurs objectifs à la fois: exécuter du code, voler des identifiants, maintenir une porte dérobée, modifier durablement la configuration, ou simplement installer des webshells ou des injections dans des fichiers “moins évidents” (thème, plugin, uploads, fichiers racine).
Le nettoyage peut éliminer ce qui est visible. Mais il peut aussi laisser derrière lui des traces fonctionnelles, par exemple:
- un plugin “de secours” créé pendant l’incident, qui n’apparaît pas immédiatement un compte administrateur ajouté puis discrètement “rebaptisé” des réglages WordPress ou PHP modifiés pour faciliter l’exécution de scripts des variables serveur ou des droits de fichiers qui permettent encore des écritures non maîtrisées des identifiants réutilisés ailleurs, dont la compromission initiale a peut-être déjà eu lieu
Et surtout, même si vous avez corrigé l’infection, vous avez peut-être reconduit le même ensemble de risques. Par exemple, un WordPress ancien, des plugins “qui ont l’air de marcher”, des permissions de fichiers trop larges, un mot de passe réutilisé, ou une absence d’authentification renforcée.
Le durcissement consiste à casser la chaîne d’attaque. L’infection n’est plus un événement isolé, elle devient un incident raréfié.
Le premier vrai objectif: vérifier que vous repartez d’une base saine
Avant de “durcir”, il faut être sûr que le nettoyage a réellement remis le site à plat. Sinon, vous allez verrouiller une infrastructure déjà déformée, et un verrouillage bien intentionné peut masquer des problèmes pendant des semaines.
Sur des cas que j’ai vus, les signaux faibles reviennent presque toujours. Une connexion admin qui se fait depuis une adresse inhabituelle, une charge CPU anormale, des fichiers qui réapparaissent dans un répertoire précis, des fichiers modifiés “le bon jour” mais sans cause légitime. Parfois, l’attaque ne laisse pas de script clair, elle s’exprime via des changements de configuration, ou via un plugin compromis.
Une bonne pratique, c’est de comparer ce que vous avez sur le serveur à ce que WordPress attend, et de garder une trace. Pas besoin de faire un audit exhaustif au départ, mais au minimum:
- vérifier l’intégrité globale des fichiers WordPress et des thèmes/plugins installés relire les journaux d’accès (au moins les dernières semaines) et repérer les pics ou patterns étranges contrôler les comptes WordPress, notamment les rôles élevés, les utilisateurs récemment créés, et l’historique d’actions
Je reste volontairement pragmatique ici: une équipe qui n’a pas encore mis en place un minimum de supervision va perdre du temps à “tout verrouiller” sans savoir ce qui a réellement été changé.
Durcir WordPress côté identités et accès
La plupart des compromissions WordPress passent par l’accès. Donc le durcissement le plus rentable concerne l’authentification, la gestion des rôles, et la réduction des possibilités d’accès non autorisé.
Réduire les risques de comptes compromis
Après un incident, j’ai appris à être très strict sur trois points: les comptes administrateurs, les mots de passe, et les sessions.
1) Les comptes administrateurs doivent être “nettoyés” et justifiés. S’il y a un utilisateur admin dont vous ne reconnaissez pas le créateur, vous n’avez aucune raison de le garder. Même si “tout semble fonctionner”, un compte oublié est souvent l’accès persistant le plus simple pour l’attaquant.
2) Renforcez les mots de passe, pas seulement pour les admins. Si un compte auteur a été utilisé pour publier des contenus, il peut aussi être devenu un levier. J’ai déjà vu des sites où seul l’administrateur a été changé, alors que le compte auteur avait servi à déposer un fichier via un plugin “d’upload”. Dans ce cas, l’attaque revient dès que les rôles sont réutilisés.
3) Révoquez les sessions existantes. WordPress maintient des sessions et des cookies. Si l’incident a eu lieu alors que quelqu’un avait encore un cookie valide, ce cookie peut survivre au nettoyage. La révocation des sessions et la déconnexion forcée réduisent le risque de “retour fantôme”.
Au-delà, l’ajout d’une authentification à deux facteurs pour tous les rôles qui peuvent modifier des choses sérieuses change la donne. En pratique, si un attaquant a le mot de passe mais pas le second facteur, l’incident s’arrête avant la modification de fichiers ou la réinstallation d’un plugin malveillant.
Protéger l’accès au panneau d’administration
Si vous utilisez un formulaire d’identification standard, vous restez exposé aux attaques par brute force, par credential stuffing, et à des tentatives qui passent par des endpoints d’auth déjà connus. L’objectif ici n’est pas de “rendre impossible”, mais de rendre l’attaque plus lente, plus coûteuse, et plus visible.
Selon votre architecture, plusieurs options existent, toutes avec des compromis:
- limiter le nombre de tentatives par adresse IP filtrer géographiquement ou par plages IP “connues” (quand c’est réaliste) ajouter une couche WAF ou un reverse proxy qui gère le rate limiting
Le compromis, c’est l’erreur humaine. Si votre site est accessible par un public mondial et que vous durcissez trop fort, vous risquez de bloquer des accès légitimes. Si, au contraire, vous gérez un site interne, un rate limiting strict peut être sans douleur.
Durcir la surface applicative: plugins, thèmes, et mises à jour
On sous-estime souvent la discipline de maintenance après un incident. Pourtant, c’est là que la https://gardewp.fr/ différence se joue.
Repartir sur un périmètre minimal
Après nettoyage, la tentation est de “remettre comme avant”. C’est parfois nécessaire, mais ce qui est pratique peut aussi être dangereux. Les plugins et les thèmes sont des pièces logicielles, avec des degrés de permission et des comportements variables.
Une règle simple, adoptée dans de nombreuses équipes sécurité: vous gardez ce qui est indispensable, vous retirez ce qui n’est pas maintenu, et vous réduisez la complexité. Un plugin “juste pour un effet” peut être un vecteur, même s’il ne ressemble à rien de suspect.
Le durcissement, c’est aussi de surveiller les mises à jour. Un plugin non mis à jour depuis des mois, ou une mise à jour répétée “mais on ne sait pas ce que ça casse”, finit toujours par se transformer en crise.
Mettre à jour sans casser
Je vous conseille d’organiser les mises à jour pour limiter le risque de régressions. Un schéma robuste consiste à tester sur une copie (staging), surtout pour les plugins lourds (cache, e-commerce, SEO, formulaires). Si vous n’avez pas de staging, un minimum de discipline s’impose: sauvegarde complète, fenêtre de maintenance planifiée, et validation fonctionnelle après mise à jour.
Le piège fréquent après incident, c’est de mettre à jour tout en même temps, puis de se retrouver avec un site instable, sans savoir si le problème vient de l’ancienne infection, d’une incompatibilité, ou d’une mauvaise mise à jour. Vous finissez alors par bricoler. Et bricoler, ça fait souvent réintroduire des modifications non traçables.
Réduire les capacités d’écriture et d’exécution (PHP et droits)
Un site WordPress se “défend” aussi avec le système. Un durcissement efficace ne dépend pas uniquement de WordPress, il dépend de PHP, du web server et des permissions.
Droits de fichiers: moins de privilèges, moins de dégâts
Après nettoyage, j’insiste sur un point: les permissions trop larges sont une invitation. Si l’environnement web peut écrire plus que nécessaire, un exploit a plus de marge.
En pratique, sur beaucoup d’hébergements, le web user doit pouvoir lire et éventuellement écrire dans un sous-ensemble limité, par exemple wp-content/uploads. Le reste doit rester en lecture seule pour l’utilisateur serveur, sauf lors de mises à jour et d’opérations contrôlées.
Le compromis ici, c’est l’opérationnel: certains outils d’auto-mise à jour ou certains plugins attendent des capacités d’écriture sur d’autres répertoires. Si vous verrouillez trop tôt, vous verrez des échecs de mise à jour. L’approche que j’adopte consiste à définir une politique progressive: commencer par corriger les répertoires les plus exposés, puis ajuster au cas par cas.
Désactiver des comportements dangereux côté PHP
Chaque hébergeur a sa propre façon de gérer php.ini ou des fichiers .user.ini. Sur les cas WordPress, je regarde typiquement:
- les options qui contrôlent l’exécution d’archives, l’accès à certains flux, et la génération dynamique les limites d’exécution et de mémoire, pour limiter les effets d’un payload les réglages qui influencent les uploads et leur traitement
Je reste prudent sur ce point, parce que les noms d’options et les impacts varient énormément. L’idée n’est pas d’appliquer “une recette universelle”. L’idée est de vérifier que votre configuration PHP ne permet pas des comportements inutiles qui servent souvent d’exécution indirecte.
Contrôler les fichiers et la persistance
Un des problèmes des incidents WordPress, c’est la persistance. L’attaquant ne cherche pas toujours à laisser des traces visibles. Il cherche à survivre à vos actions.
Surveiller les changements de fichiers
Même sans automatisation sophistiquée, vous pouvez réduire la fenêtre de réaction. Un contrôle périodique des fichiers modifiés, surtout dans wp-content, et des accès anormaux, change votre capacité à détecter une réinfection.
Sur un site que j’ai accompagné, le symptôme n’était pas un redoutable “fichier webshell”. C’était un changement répété dans un thème enfant, avec une heure de modification très régulière. Sans comparaison, on aurait attribué ça à des mises à jour. Avec une vérification et des logs, on a vu que c’était une injection scriptée, déclenchée à intervalles constants.
Vérifier la provenance des thèmes et plugins
Pendant le nettoyage, il est facile de réinstaller à l’identique, puis de découvrir ensuite que certains éléments n’étaient pas issus des sources légitimes. Une discipline utile consiste à:
- vérifier que les plugins installés correspondent à ceux que vous utilisez réellement vérifier la provenance des fichiers (version, source, cohérence) si possible, utiliser des sources de téléchargement officielles
Le durcissement ne vise pas la paranoïa, il vise la réduction des erreurs humaines. Si vous avez déjà eu un plugin compromis, vous avez intérêt à empêcher sa “version voisine” de revenir.
Sécuriser la couche réseau et l’accès au serveur
Le hardening WordPress ne s’arrête pas au logiciel. Si l’attaque passe par le réseau, un WAF, un reverse proxy, et une gestion propre des IP peuvent diminuer drastiquement le volume de tentatives.
WAF, rate limiting, et règles de surface
Un WAF peut:
- filtrer certains patterns d’injection réduire les accès automatiques agressifs aider à détecter des comportements atypiques
Mais il faut être conscient des faux positifs. Dans les environnements WordPress, certaines requêtes légitimes peuvent être mal interprétées, surtout si vous avez des outils d’API, des formulaires complexes, ou des plugins qui appellent des endpoints.
Je conseille de mettre ces protections en “apprentissage” quand c’est possible, puis de durcir progressivement. L’objectif est de ne pas transformer un incident sécurité en incident disponibilité.
Limiter les points d’entrée
Si votre hébergement ou votre architecture le permet, réduire l’exposition de certains endpoints réduit la surface d’attaque. Cela ne remplace pas la sécurité applicative, mais cela ajoute un amortisseur.
La bonne approche consiste à agir sur l’ensemble: identités, droits, PHP, et réseau. Un seul levier ne suffit presque jamais, mais la combinaison crée un effet cumulatif.
Ajuster WordPress pour limiter les vecteurs typiques
Certains réglages WordPress influencent directement la surface d’attaque, notamment via la publication, les modifications de fichiers, et les comportements des utilisateurs.
Désactiver ce qui n’est pas utilisé
Si vous n’utilisez pas l’éditeur de fichiers depuis l’interface WordPress, autant le limiter. Selon les versions et les configurations, certains paramètres peuvent empêcher l’écriture directe par l’interface d’administration. Cela peut être très utile après un nettoyage, parce que vous réduisez la capacité d’un compte compromis à modifier des fichiers.
Pareil pour XML-RPC, qui a été un vecteur historiquement. Aujourd’hui encore, la pertinence dépend de votre usage réel. Si vous n’utilisez pas de clients externes qui s’appuient dessus, le limiter est souvent un gain net. Si vous l’utilisez, il faut une approche de contrôle plus fine.
L’arbitrage ici est clair: vous devez connaître vos usages. Le durcissement n’est pas une checklist générique, c’est un alignement entre vos fonctionnalités et la réduction de surface.
Remettre le suivi au centre (détection et réaction)
Après nettoyage, beaucoup d’équipes se focalisent sur la prévention pure. C’est normal. Mais la sécurité efficace combine prévention et détection.
Mettre en place une surveillance réaliste
Vous n’avez pas besoin d’une usine à gaz. Un suivi simple, mais cohérent, peut suffire à détecter un retour d’attaque: logs d’accès, logs d’erreurs, alertes sur changements de fichiers, et métriques de charge.
Sur un hébergement mutualisé, vous pouvez manquer de détails. Dans ce cas, regardez ce que vous pouvez: fichiers de logs disponibles, événements via l’interface de l’hébergeur, et au minimum les tendances (pics de requêtes vers /wp-login.php, pics d’erreurs 403/404, augmentation d’erreurs PHP).
Le durcissement améliore la stabilité, mais la détection vous évite d’attendre “l’évidence” trop longtemps.
Tester la capacité de réaction
Je considère qu’une bonne posture sécurité inclut une simulation de réaction, même légère. Par exemple:
- savoir où se trouvent les logs utiles savoir comment re-déployer une version “propre” avoir un plan de restauration et une procédure pour réinitialiser les clés et identifiants
Le jour où une réinfection arrive, votre vitesse d’exécution détermine la gravité. Pas besoin d’attendre un incident majeur pour vous préparer.
Deux checklists utiles pour cadrer sans se perdre
Après avoir vu des redoutables “faux retours à la normale”, j’ai fini par aimer deux checklists courtes, utilisées avant et après durcissement. Elles ne remplacent pas une analyse, elles évitent surtout de sauter des étapes.
Checklist de validation après nettoyage (rapide)
- Vérifier qu’aucun nouvel utilisateur admin non reconnu n’existe Contrôler les thèmes et plugins présents, leur cohérence et leurs dates de modification Rechercher des fichiers inattendus dans wp-content et les répertoires d’uploads Revoir les logs d’accès autour de la période d’incident, repérer les patterns Révoquer toutes les sessions et forcer une rotation des mots de passe
Checklist de durcissement prioritaire (orientée risque)
- Mettre à jour WordPress, thèmes et plugins, idéalement via un staging Activer l’authentification à deux facteurs pour les rôles à privilèges Réduire les permissions d’écriture là où ce n’est pas nécessaire Limiter l’interface et les fonctionnalités trop exposées (éditeur, XML-RPC si inutilisé) Ajouter une couche de protection réseau, au moins rate limiting et filtrage basique
Ces listes sont volontairement compactes. Si vous devez en faire une vingtaine, c’est souvent le signe que vous manquez de visibilité sur votre environnement et que vous risquez de tout faire “au hasard”.
Cas limites et décisions qui font la différence
Il y a des situations où le durcissement “standard” peut gêner, ou être impossible.
Hébergement mutualisé sans contrôle PHP fin
Dans certains mutualisés, vous ne contrôlez pas autant la configuration. Dans ce cas, le durcissement se déplace vers ce que vous pouvez vraiment faire: mises à jour, plugins minimaux, permissions via l’interface, durcissement applicatif, règles d’auth, et protection réseau au niveau hébergeur.
Site multiauteur, équipe distribuée
Si plusieurs rédacteurs travaillent et que l’auth forte devient trop lourde, vous risquez de créer de la contournabilité. Le bon choix consiste à imposer le second facteur aux rôles les plus sensibles, et à cadrer les permissions des autres. Par exemple, un auteur n’a pas besoin de la même capacité qu’un admin. C’est moins une question de “secouer tout le monde” qu’une question de modèle de droits.
Plugins indispensables mais historiquement risqués
Parfois, vous avez un plugin “utile” mais pas parfait. Le durcissement ne consiste pas à l’interdire sans discussion, il consiste à réduire sa place et à le contenir. Mieux vaut isoler la fonctionnalité, s’assurer qu’elle est maintenue, et surveiller ses comportements plutôt que de l’abandonner au mauvais moment.
La sécurité, c’est aussi une gestion du risque. Vous connaissez l’impact potentiel d’un plugin. Vous connaissez aussi l’impact du retrait. Vous choisissez une trajectoire réaliste.
Le piège le plus courant après incident: “on a nettoyé, donc c’est bon”
Ce piège revient sous des formes différentes. Parfois, c’est “on a réinstallé WordPress, on est tranquilles”. Sauf que la compromission peut être dans la configuration, dans les comptes, ou dans un accès réseau ou un plugin persisté. D’autres fois, c’est “on a changé le mot de passe admin”. Sauf que l’attaquant a déjà validé un autre compte, ou a laissé un script dans un endroit non surveillé.
Durcir, c’est se donner une chance de casser la logique de l’attaquant. Et surtout, c’est se donner le droit de ne pas refaire la même opération en boucle.
Si vous devez retenir une idée: le nettoyage traite l’incident, le hardening traite les conditions qui le rendent probable.
Une trajectoire simple pour passer à l’action
Si vous êtes en train de sécuriser un site après nettoyage, vous n’avez pas besoin de tout faire en une nuit.
Commencez par le socle: rotation des identifiants, révocation des sessions, audit des comptes, mise à jour des composants, et réduction du périmètre (plugins et thèmes). Ensuite, passez au durcissement d’exécution et d’écriture via permissions et configuration PHP quand c’est possible. Enfin, renforcez la détection: logs, surveillance de changements, et alertes adaptées à votre environnement.
C’est cette progression qui évite les mauvaises surprises, car chaque étape confirme que vous contrôlez ce qui s’est passé. Vous ne faites pas seulement “plus sûr”, vous faites aussi “plus lisible”.
Si vous souhaitez, décrivez-moi votre configuration (hébergement, présence de staging, plugins clés, et ce que vous avez déjà changé pendant le nettoyage). Je pourrai vous proposer une feuille de route de durcissement adaptée, avec les priorités les plus rentables pour votre cas.