Un site WordPress infecté, ce n’est pas seulement “un malware qui tourne en arrière-plan”. Très vite, ça devient un problème de trafic (pics bizarres, visiteurs redirigés), de réputation (mails d’alerte de Google ou de votre hébergeur), et de responsabilités (vous avez publié du code malveillant sans l’avoir volontairement fait). Dans les faits, beaucoup de failles semblent “explosives” parce qu’elles se déclenchent d’un coup, puis continuent en boucle.
Quand on parle de configurer un blocage au niveau serveur, l’objectif est simple: casser la chaîne avant que WordPress ne soit relancé à chaque requête. Autrement dit, empêcher l’exécution ou la diffusion du contenu malveillant, ou réduire drastiquement les vecteurs d’entrée (fichiers, requêtes, endpoints, patterns). Le défi, c’est de le faire sans transformer votre serveur en marteau-piqueur qui casse aussi des pages légitimes.
Je vais donc vous expliquer une approche pragmatique, centrée sur la couche serveur, avec des exemples concrets. Selon votre environnement (Nginx, Apache, Cloudflare, firewall, WAF, type d’hébergement), le détail change. Mais la logique reste la même: identifier le comportement, bloquer précisément ce qui le permet, et ne pas compter uniquement sur WordPress pour s’auto-réparer.
Comprendre ce qu’on veut vraiment bloquer
Sur un site compromis, il y a souvent deux catégories d’actions malveillantes:
La première, c’est l’intrusion. Quelque chose a permis à l’attaquant d’écrire des fichiers, d’ajouter du code dans le thème, les plugins, ou des fichiers “hors cœur” comme des scripts dans le répertoire racine, ou encore des fichiers dans des répertoires inattendus.
La seconde, c’est l’exécution, la persistance et la distribution. Même après un nettoyage WordPress, le site peut continuer à servir un script, rediriger vers un domaine externe, appeler un endpoint qui recrée la charge utile, ou charger en base de données du contenu qui revient.
Configurer un blocage au niveau serveur sert à mettre un frein immédiat à la deuxième catégorie, voire à couper la première si le vecteur passe par une URL ou un chemin particulier.
En pratique, “bloquer” peut vouloir dire plusieurs choses:
- bloquer un ensemble d’URLs (patterns de chemins, requêtes vers des scripts cachés) interdire certains types de fichiers dans certains dossiers empêcher l’exécution de PHP dans des répertoires où vous ne devriez jamais l’avoir filtrer des paramètres caractéristiques (tokens, chaînes obfusquées, noms de fichiers d’attaque) bloquer des IP ou plages IP si l’activité vient de quelques hôtes
Le point crucial est le dosage. Plus vous bloquez large, plus vous risquez le faux positif. Et si votre serveur est déjà en stress, un mauvais blocage peut aggraver le chaos en cassant votre site au lieu de le stabiliser.
Première réponse: rendre la situation “observée” plutôt que “mystique”
Avant de toucher à Nginx ou Apache, j’aime bien passer par une mini phase de constat. Pas une enquête judiciaire interminable, juste de quoi guider les règles.
Sur la plupart des hébergements, vous avez un accès aux logs:
- logs web (access et error) logs de votre panneau hébergeur éventuels logs PHP (selon configuration) journaux WAF si vous en avez un
L’idée est de repérer un “signal”. Un signal typique, c’est une URL très spécifique appelée en boucle, ou un modèle de requête répétitif. Par exemple, un chemin qui commence par quelque chose de discret dans /wp-content/ ou la racine, avec une extension inattendue, ou un fichier PHP ajouté récemment.
Une anecdote fréquente: sur un site compromis que j’ai eu à traiter, les fichiers WordPress avaient l’air “propres” après un premier nettoyage, mais les logs continuaient à pointer vers un script PHP au même endroit depuis lequel l’attaquant re-déployait sa charge utile. On a d’abord mis un blocage serveur sur le chemin, puis seulement ensuite on a fait la remise en état complète. Sans le blocage, le nettoyage était remis en cause dès qu’une nouvelle requête arrivait.
Si vous ne voyez pas le signal, vous allez souvent bloquer trop large, ou au contraire trop à côté. C’est pour cela que la configuration serveur doit s’appuyer sur des éléments concrets.
Les actions de blocage les plus efficaces (couche serveur)
Selon votre stack, vous aurez différentes options. Je les classe par impact potentiel et par risque.
Empêcher l’exécution PHP dans des dossiers qui ne doivent pas exécuter de code
C’est une arme assez “universelle”. Si un attaquant dépose un fichier PHP dans un dossier qui ne devrait pas l’exécuter, alors la requête échoue. Vous ne bloquez pas seulement l’exécutable malveillant, vous réduisez aussi les chances de persistance.
Sur https://gardewp.fr/nettoyage-malware-wordpress/ Apache, on le fait typiquement via php_flag ou FilesMatch et des règles .htaccess ou de configuration de vhost. Sur Nginx, on contrôle via des règles location et deny all, ou en forçant un type de traitement non exécutable.
Attention au faux positif: certains sites utilisent du PHP dans des sous-dossiers qui changent selon des plugins. Si vous bloquez “trop” et qu’un plugin légitime a sa mécanique là-dedans, vous aurez une erreur 500 ou une page blanche.
La bonne approche est de cibler les dossiers qui sont clairement “statistiques” ou “upload” et dont vous contrôlez le comportement, souvent uploads/ et des sous-dossiers précis.
Bloquer des patterns de chemins (URLs) associés au malware
C’est généralement la forme la plus rapide de mise en sécurité. Vous identifiez dans les logs des chemins appelés en boucle, puis vous bloquez ces chemins.
Exemples de patterns fréquents dans les compromissions WordPress, sans prétendre que chaque attaque les utilise toujours:
- fichiers PHP dans des emplacements inhabituels sous la racine requêtes directes vers des scripts ajoutés dans des dossiers de thèmes ou plugins chemins contenant des identifiants qui changent peu, ou des noms de fichiers “cachés”
La règle de base: bloquez les chemins, pas “tout le monde”. Idéalement, utilisez des expressions ciblées et des codes renvoyés cohérents (403 plutôt que 404 selon votre stratégie). Et gardez une petite trace de ce que vous bloquez, pour pouvoir ajuster après nettoyage.
Refuser certains types de fichiers ou certains formats de contenu
Si vous observez qu’un attaquant tente d’exécuter via des extensions non standards, vous pouvez bloquer l’accès à ces formats dans des emplacements donnés.
Sur WordPress, il y a aussi un aspect important: même si vous empêchez l’exécution, un script pourrait servir un fichier qui n’est pas exécuté côté serveur, mais déclenche un navigateur. Dans ce cas, votre filtrage doit viser le bon niveau, souvent l’accès et la réponse web, pas uniquement l’exécution.
Mettre un blocage IP temporaire
Quand le trafic malveillant vient de quelques IP, vous pouvez bloquer à la source. Cela marche, mais ça ne règle pas la cause. En général, ça réduit la charge pendant que vous nettoyez.
Le risque, c’est de bloquer des IP légitimes, notamment si vous voyez des requêtes qui ressemblent à celles d’un bot SEO, d’un outil de scan interne, ou d’un partenaire. Et surtout, les attaquants changent souvent d’IP. Donc ce blocage sert plutôt de stabilisation.
Cas pratique: Nginx, blocage ciblé sur des chemins
Je ne peux pas vous donner une “recette universelle” sans connaître votre structure de configuration, mais je peux vous montrer la logique et les points à vérifier.
Imaginons que dans vos logs, vous voyez très souvent des requêtes du type:
- GET /wp-content//something.php GET /.php POST /wp-admin/admin-ajax.php avec un paramètre suspect
Dans Nginx, vous pouvez ajouter des règles dans la configuration du serveur ou dans un fichier inclus.
Une stratégie prudente consiste à: 1) créer des règles qui interceptent uniquement ces chemins précis 2) renvoyer un code 403 3) ne pas toucher au reste
Dans l’idéal, vous modifiez le vhost correspondant au domaine, pas une règle globale. La commande nginx -t avant rechargement vous évite une catastrophe où tout tombe.
Exemple de logique (à adapter, car les chemins exacts dépendent de vos logs):
- une règle pour un chemin PHP précis et un seul une règle pour un sous-dossier spécifique sous /wp-content/ qui ne doit jamais contenir de PHP exécuté
Si votre site fonctionne avec PHP-FPM, vous pouvez aussi bloquer l’accès avant la phase FastCGI. C’est plus efficace et ça limite la charge.
Cas pratique: Apache, blocage via la racine ou les répertoires
Avec Apache, vous avez des options selon que vous utilisez .htaccess ou la configuration de vhost.
Dans les scénarios où des fichiers PHP apparaissent dans des endroits inattendus, un blocage au niveau répertoire peut être très efficace. L’idée est d’empêcher l’exécution là où elle n’est pas attendue.
Un exemple classique:
- empêcher PHP dans des sous-dossiers qui ne devraient contenir que des assets, même s’ils contiennent par erreur des fichiers bloquer l’accès direct à certains scripts trouvés dans les logs
Il faut toutefois respecter la réalité de WordPress: certains plugins ou setups avancés utilisent des fichiers PHP “ailleurs” que ce que vous imaginez. C’est pour ça que je préfère une règle ciblée sur les chemins observés, plutôt qu’une règle trop générale basée uniquement sur des hypothèses.
Si votre hébergeur ou proxy filtre déjà: travailler avec, pas contre
Beaucoup de sites ont un WAF, un firewall applicatif, ou un reverse proxy en amont (y compris via Cloudflare). Dans ces cas, vous pouvez souvent faire un blocage sur:
- règles de firewall par URL règles de challenge pour patterns connus blocage par pays, ASN ou réputation IP
L’avantage, c’est que vous réduisez la charge sur votre serveur. Le risque, c’est la complexité de la chaîne: ce que vous bloquez au serveur peut arriver après un filtrage déjà existant, ou au contraire être contourné par un chemin que vous n’avez pas vu.
Mon conseil: commencez par le niveau le plus “proche” de l’attaquant si vous pouvez, puis ajoutez une couche serveur pour tenir le coup en cas de contournement. La défense en profondeur a du sens ici, mais seulement si elle reste mesurée.
Comment éviter les dégâts collatéraux
Les blocages serveur sont efficaces, mais ils doivent être testés avec méthode. Dans un contexte de site WordPress infecté, vous êtes souvent sous pression. C’est précisément là que les erreurs arrivent.
Voici les erreurs que j’ai le plus souvent vues:
- blocage trop large sur un motif qui capture aussi des routes d’un plugin blocage de l’accès à des fichiers nécessaires au CDN ou à la mise à jour oubli du comportement “cache”, ce qui fait croire à un bug alors que l’ancien contenu est encore servi mauvaise gestion des permissions ou du rechargement de service
Pour minimiser ces risques, je recommande une séquence simple, en restant sur des actions qui “échouent proprement”.
Mini check avant de déployer une règle
- vérifiez la config Nginx ou Apache dans le bon vhost (pas une règle globale) identifiez 2 ou 3 URLs exactes responsables du comportement malveillant dans vos logs testez en local ou en préproduction si vous en avez une, sinon sur une fenêtre de maintenance courte privilégiez un retour 403 sur des chemins précis, plutôt qu’un blocage massif gardez une note de ce que vous avez bloqué, avec la date et l’extrait de log associé
Cette discipline vous évite de transformer un nettoyage en chasse aux bugs invisibles.
Une approche progressive: stabiliser, puis nettoyer, puis verrouiller
Le blocage serveur ne remplace pas le nettoyage. Mais il améliore tellement la situation que vous pouvez travailler plus sereinement.
Dans un flux “terrain”, j’ai tendance à faire:
- stabilisation (couper l’exécution ou l’accès au chemin malveillant) nettoyage contrôlé (remplacer ce qui doit l’être, restaurer ce qui a été modifié, révoquer les accès) vérification (tester que le site ne redéclenche plus le pattern) durcissement (empêcher la réinfection via des contrôles, mises à jour, règles d’accès)
Le verrouillage serveur se situe surtout dans les étapes 1 et 4. L’étape 3 demande de la vigilance: il arrive que l’attaquant change légèrement son comportement après un premier blocage, par exemple en utilisant une autre route.
Exemple de durcissement: réduire les surfaces d’écriture
Même si votre question porte sur le blocage au niveau serveur, il faut comprendre qu’une surface d’écriture mal protégée rend le blocage inefficace à long terme. Si un attaquant peut encore déposer des fichiers, il finira par trouver un chemin que vous n’avez pas encore bloqué.
Selon votre environnement, vous pouvez réduire cette surface via:
- permissions système cohérentes (éviter que trop de répertoires soient accessibles en écriture) règles qui limitent l’exécution PHP dans les dossiers non prévus durcissement des uploads et des fichiers accessibles publiquement
Je préfère les protections “structurelles” à celles basées uniquement sur des signatures. Les signatures dépendent de l’attaque d’hier. La structure corrige le problème de fond.
Ce que vous devez changer, et ce que vous devez éviter
On pourrait être tenté de “bloquer tout ce qui ressemble à un malware”. C’est tentant, mais sur WordPress c’est risqué. Les plugins et thèmes génèrent parfois des chemins qui ressemblent à n’importe quoi. Un blocage basé sur des noms de fichiers “exotiques” peut casser un module légitime.
Au lieu de ça, j’utilise une logique de ciblage:
- repérer le chemin exact, ou le sous-dossier exact vérifier que le fichier était absent avant compromission (quand c’est possible) choisir une action serveur qui empêche l’exécution ou l’accès direct mesurer l’impact sur le trafic normal
Si vous ne pouvez pas confirmer l’intention malveillante, bloquez prudemment d’abord, observez, puis ajustez.
Une séquence opérationnelle concrète (sans vous noyer)
Voici une démarche que vous pouvez réellement appliquer, que vous soyez en Nginx ou Apache. L’idée n’est pas d’avoir la commande parfaite, c’est d’avoir la bonne méthode.
Procédure en 5 étapes
Repérez dans les logs les URL et fichiers appelés de manière répétitive (au moins deux exemples) Vérifiez l’existence et la date de modification des fichiers ciblés, côté système Ajoutez une règle serveur ciblée pour bloquer l’accès ou l’exécution sur ces chemins précis (403 recommandé) Rechargez la configuration et testez avec vos navigateurs, plus une requête directe sur les URL bloquées Une fois la charge coupée, lancez le nettoyage WordPress, révoquez les sessions et réinstallez ce qui a été altéréCette séquence évite l’erreur classique, “je nettoie, puis je bloque après”, alors que le site reste activement exploité pendant que vous travaillez.
Questions de configuration à vous poser avant d’écrire la règle
Le blocage serveur dépend énormément de vos choix techniques. Deux questions simples changent tout:
- Votre serveur exécute du PHP via FPM (Nginx) ou via module (Apache) ? Avez-vous un .htaccess activé, ou tout se fait au niveau de la config vhost ?
Autre point pratique: votre site utilise-t-il des réécritures, des endpoints custom, ou des APIs de plugins? Si oui, la règle doit respecter ces routes. Et si vous avez un cache ou un CDN, le test doit inclure une purge ou au moins une comparaison entre requête en mode navigation privée et requête via un outil qui court-circuite le cache.
Enfin, pensez aux pages d’erreur. Si vous renvoyez un 403 sur un chemin, certains moteurs de recherche peuvent percevoir ça différemment d’un 404, et votre stratégie SEO peut évoluer. En période de crise, la priorité est d’arrêter l’exécution malveillante, mais ce choix influence ensuite la manière dont les visiteurs voient le problème.
Et si vous bloquez mais le site reste “infecté”?
C’est un point important. Il peut rester des traces après que vous avez bloqué le chemin principal. Parfois, l’attaque utilise plusieurs routes, ou elle reconfigure ailleurs.
Dans ce cas, ne vous accrochez pas à une seule règle. Retournez aux logs. La question à vous poser est: “quel est le prochain pattern actif qui continue à provoquer un effet?”. Vous ajoutez ensuite une règle supplémentaire, toujours ciblée, jusqu’à ce que le comportement s’apaise.
Autre cas, plus pénible: le serveur peut avoir été modifié au niveau système, et pas seulement WordPress. Exemple typique, un fichier ailleurs que WordPress déclenche une action lors de certaines requêtes. Dans cette situation, le blocage au niveau vhost aide, mais il faut aussi vérifier l’intégrité système et les comptes, car WordPress n’est peut-être que le point visible.
Dure réalité: blocage serveur ne remplace pas la remise à niveau des comptes
Sur beaucoup de sites, l’infection revient parce que les identifiants compromis continuent d’exister. Le blocage serveur empêche l’exécution, mais il ne révoque pas une session. Donc, même avec un excellent blocage, vous devez:
- réinitialiser les mots de passe utilisateurs concernés vérifier les rôles et supprimer ce qui n’a pas de raison d’être contrôler les plugins et thèmes installés, surtout ceux ajoutés récemment vérifier les cron jobs et tâches planifiées
Si vous ne faites pas ça, l’attaquant peut réinstaller. Le blocage va alors devenir un jeu de whack-a-mole. Ça se termine mal, soit par une accumulation de règles, soit par une réinfection qui trouve la brèche restante.
Ce que j’utiliserais comme critères pour ajuster vos règles
Une règle serveur doit être évaluée. Je vous propose des critères simples, qui évitent le débat sans fin:
- Volume: les requêtes bloquées chutent-elles vraiment dans les logs ? Diversité: l’attaquant change-t-il d’URL, donc vous voyez de nouveaux chemins ? Impact: votre site garde-t-il ses fonctions critiques (paiement, formulaires, pages clés) ? Durabilité: la règle continue-t-elle à fonctionner après nettoyage et mises à jour ? Réversibilité: pouvez-vous désactiver la règle sans casser tout le domaine ?
Si vous cochez la plupart de ces points, vous tenez une approche solide.
Pour finir: l’équilibre entre verrouillage et stabilité
Le blocage au niveau serveur, c’est souvent la différence entre “on subit” et “on reprend la main”. Mais ce n’est pas une magie noire. Le bon réglage dépend des logs et de l’architecture. Le pire scénario, c’est un blocage trop large, qui rend le diagnostic impossible parce que vous cassez aussi le site normal.
Si vous faites une chose de manière rigoureuse, faites celle-ci: partez de comportements observés dans les logs, puis appliquez une règle ciblée, testez l’impact, et itérez. Dans le contexte d’un site WordPress infecté, cette discipline vous donne un arrêt immédiat de la charge, tout en gardant de la marge pour nettoyer proprement et verrouiller les mécanismes de réinfection.
Si vous me donnez votre configuration (Nginx ou Apache, hébergeur, et un exemple de 3 ou 4 URL issues des logs que vous voyez en boucle), je peux vous proposer une formulation de règles beaucoup plus précise, avec les pièges à éviter pour votre cas.