Dès qu’un site WordPress devient public, il commence à être cartographié. Les attaquants n’ont pas besoin de “pirater” au sens classique au départ. Ils cherchent d’abord des indices, des versions, des chemins, des noms d’utilisateurs, parfois même des habitudes d’exploitation. Ce travail se fait par scanning et enumeration, deux phases très différentes mais souvent confondues.
Le scanning, c’est la découverte des surfaces accessibles: endpoints, pages, fichiers présents, comportements HTTP, politiques de cache, redirections, réponses 401/403/404, tailles de contenu. L’enumeration, c’est l’extraction d’identités ou de structures: noms de plugins installés, versions exposées, auteurs, types de requêtes acceptées, ID de ressources, parfois même des comptes via des failles de configuration ou des fuites dans les réponses.
Le plus frustrant avec ces attaques, c’est qu’elles ressemblent à des “visites” ou à du trafic légitime au premier regard. Et pourtant, elles préparent la suite. Une fois que l’attaquant a un modèle fiable de votre installation, il choisit des payloads précis, réduit le bruit, augmente les chances de succès.
Pourquoi ces attaques sont si courantes sur WordPress
WordPress a une particularité: il est à la fois extensible et relativement standardisé. Le noyau, les thèmes, les plugins et les conventions de fichiers créent un terrain où les réponses du serveur trahissent facilement des informations. À cela s’ajoute le fait que beaucoup d’installations sont héritées d’anciennes pratiques: répertoires accessibles, paramètres par défaut, erreurs de permissions, compte admin admin, ou scripts d’installation conservés.
Côté attaquant, l’objectif est pragmatique. Il ne cherche pas forcément “la” faille. Il cherche d’abord à savoir ce qu’il doit attaquer. Sur une base de 30 à 200 cibles, une partie seulement souffre d’un problème grave. Mais si vous donnez des indices utilisables, la probabilité augmente rapidement.
Le résultat, ce sont des journaux qui débordent: des requêtes répétées sur des chemins sensibles, des tentatives sur des endpoints connus, des variations sur les mêmes paramètres. Même si la plupart échouent, vous payez le coût opérationnel, la charge CPU, le bruit dans la détection et, parfois, des dégâts collatéraux (blocage d’un CDN, remplissage disque des logs, saturation WAF).
Reconnaître scanning et enumeration dans vos logs
Avant d’empiler des outils, il faut lire ce qui se passe. Les attaques de type scanning et enumeration laissent des motifs. Ils ne sont pas toujours évidents, mais avec un peu d’attention, on distingue souvent deux signatures.
Première signature: des requêtes sur des chemins “génériques” mais précis. Par exemple, des accès à des fichiers PHP dans des répertoires attendus, des probes vers des endpoints REST ou des scripts de l’écosystème. Le pattern consiste souvent en variations d’une même base, avec des méthodes GET, parfois HEAD, et des réponses qui alternent 200, 301, 403 ou 404.
Deuxième signature: des requêtes où seule la valeur change. Par exemple, un paramètre numérique https://gardewp.fr/securite-wordpress/ (ID), un slug (nom de post), ou un élément d’identification (nom d’auteur, nom de plugin, nom de fichier). L’enumeration vise la structure. Le scanning vise la surface.
Une anecdote de terrain: sur un WordPress “classique” hébergé en mutualisé, on observait des pics réguliers à 02:17, exactement le même intervalle, avec des chemins différents mais des codes retour cohérents. En regardant le User-Agent, tout ressemblait à de la navigation normale. En réalité, c’était un petit bot qui testait des répertoires puis passait au même modèle d’erreur. En durcissant deux points de configuration, le trafic est devenu moins “rentable” et s’est raréfié en quelques jours.
Réduire la surface exposée sans casser le site
La défense la plus efficace contre scanning et enumeration n’est pas de “rendre tout invisible” de façon absolue. On cherche plutôt à réduire la valeur des réponses et à rendre l’analyse plus coûteuse.
Sur WordPress, cela passe par trois familles d’actions: limiter la fuite d’informations, durcir les règles d’accès, et empêcher certains chemins inutiles d’être accessibles.
Fuites d’informations: ce que vos réponses disent déjà
Sans être paranoïaque, vos réponses peuvent dévoiler beaucoup de choses: signatures de serveur, version WordPress, erreurs détaillées, comportement d’accès aux fichiers inexistants. Certains détails sont parfois liés au thème, à un plugin, ou à une config Nginx/Apache.
Un premier levier, simple, consiste à éviter d’afficher des erreurs brutes en production. Beaucoup de sites laissent WP_DEBUG à true pendant le développement, ou exposent les traces dans les pages d’erreur. Ensuite, vérifiez si un cache ou un proxy renvoie des headers trop révélateurs. Vous n’êtes pas obligé de tout masquer, mais réduire la précision aide à contrer l’étape d’identification.
Accès: bloquer au bon endroit, pas seulement “dans WordPress”
WordPress vit dans un contexte web. Les attaquants “scan” au niveau HTTP, avant même que WordPress ne traite la requête dans certains cas. Donc, les blocages les plus efficaces sont ceux qui s’appliquent le plus tôt possible: à la couche reverse proxy, web server, ou au niveau CDN/WAF.
Sur un Nginx ou Apache bien configuré, vous pouvez refuser certains patterns de chemins inutiles. Sur une plateforme managée, vous pouvez régler des règles WAF ou un firewall applicatif. Le but n’est pas de faire un mur contre tout, mais d’ajouter une friction: plus votre serveur répond lentement ou de manière homogène, moins l’attaquant peut déduire des informations.
Trade-off concret: si vous bloquez trop agressivement, vous risquez de casser des robots d’indexation légitimes, des outils de monitoring, ou des fonctionnalités d’admin distantes (par exemple XML-RPC, débogage, ou endpoints utilisés par des plugins d’authentification). La bonne approche consiste à cibler des patterns connus pour l’enumeration et à valider impact sur staging.
Hardening WordPress: actions qui comptent vraiment face à l’énumération
Le hardening WordPress utile contre scanning et enumeration est souvent plus “gestion” que “magie”. C’est moins une question de plugin miracle et plus un assemblage cohérent: mises à jour, permissions, surfaces d’exécution, gestion d’erreurs, et contrôle des endpoints.
Mises à jour et cohérence: la base, même si ça semble banal
Les scanners automatisés testent des signatures. Si vous laissez un thème ou un plugin obsolète, vous augmentez la probabilité que l’attaquant adapte sa stratégie. Ce n’est pas seulement une question de vulnérabilités connues, c’est aussi une question d’heuristiques: beaucoup de bots identifient ce qui est installé, puis basculent vers des payloads spécifiques.
Sur les sites qui ont un historique d’installations “lourdes”, la meilleure amélioration vient souvent d’un nettoyage. Retirez les plugins inutiles, désactivez ceux que vous n’utilisez plus, et remplacez ce qui n’est plus maintenu. Cela réduit à la fois la surface et le volume de réponses différentes.
Contrôler l’accès à l’admin et réduire l’attaque “par essais”
Le scanning et l’enumeration préparent souvent des attaques de brute force et d’exploitation ciblée. Donc, le durcissement de l’authentification aide indirectement. Deux leviers se combinent souvent:
- Rendre l’accès à la zone d’administration moins direct (filtrage, restriction réseau, ou challenge). Limiter la capacité de deviner des identifiants.
Dans la pratique, j’ai vu des attaques “lentes” mais persistantes, qui n’avaient pas besoin de contournement technique dès le départ. Elles profitaient surtout d’une page de connexion facile à atteindre et d’un manque de throttling.
Une règle simple, mais efficace: mettez en place un rate limiting sur les endpoints d’authentification (login, éventuellement XML-RPC selon votre usage) et sur les tentatives d’accès à des ressources sensibles. L’objectif n’est pas de bannir un visiteur unique, c’est de rendre coûteuse l’exploration automatisée.
Journaux: la meilleure défense, c’est de savoir quand ça commence
Sans journaux exploitables, vous “défendez à l’aveugle”. Un bon set de logs doit vous permettre de distinguer: tentatives répétées sur des chemins, patterns d’énumération par paramètres, et pics d’activité corrélés à certaines heures ou IP.
Quelques précautions pratiques. Gardez un accès aux logs suffisamment longtemps pour identifier des motifs récurrents. Évitez de saturer le stockage avec des détails excessifs. Et surtout, tracez les codes retour et la taille de réponse, car ces deux indicateurs aident à comprendre si l’attaquant obtient une info utile (par exemple une différence nette entre 200 et 404).
Stratégies de configuration utiles (sans liste à outrance)
XML-RPC: désactiver si vous n’en avez pas besoin
Sur WordPress, XML-RPC est une surface historique. S’il n’est pas utilisé chez vous (pings, certaines intégrations), le désactiver limite des vecteurs de test et d’exploitation. Même quand il n’y a pas de faille actuelle, les bots ciblent souvent ce endpoint, car il a été attaqué dans le passé.
Le trade-off est réel: certains plugins ou workflows d’édition distante peuvent s’en servir. Donc, testez, surveillez les logs après désactivation, et gardez un plan de retour.
REST API: gérer l’exposition et les rôles
L’API REST peut être très pratique pour des frontends découplés, mais elle attire aussi les scanners. Les attaquants cherchent à comprendre quels endpoints sont exposés, comment l’authentification se comporte, et quelles réponses varient selon les permissions.
Selon votre cas, vous pouvez réduire l’information exposée, restreindre certaines actions, et éviter d’avoir des configurations permissives. Ici encore, l’idée n’est pas de rendre tout inaccessible si votre site en dépend. C’est de fermer les portes inutiles.
Permissions de fichiers et exécution: réduire les chemins exploitables
Les scanners aiment tester les chemins de fichiers, y compris ceux qui sont là par héritage. Vérifiez:
- que les dossiers sensibles n’ont pas des permissions trop larges; que les fichiers inutiles ne sont pas accessibles en lecture; que la configuration d’exécution n’est pas trop permissive.
Sur des environnements mal configurés, il suffit parfois qu’un dossier soit lisible pour que l’attaquant confirme une hypothèse, puis passe à l’énumération plus précise.
Mettre en place un filtrage au niveau bord: CDN, WAF, firewall
Le meilleur endroit pour contrer scanning, c’est avant que la requête n’arrive à WordPress. Un CDN ou un WAF peut bloquer des patterns répétitifs, imposer des challenges aux comportements suspects, et limiter des attaques volumétriques légères.
Là où il faut être prudent, c’est la définition des règles. Si vous appliquez des règles “par défaut” trop sévères, vous créez des faux positifs. Un scanning “malveillant” peut ressembler à un crawl, surtout quand le User-Agent n’aide pas.
Une approche pragmatique consiste à commencer par la détection et la réduction de bruit, puis à durcir. Par exemple, vous pouvez d’abord taguer les requêtes suspectes, observer les logs WAF, puis activer progressivement des actions de blocage.
Deux actions simples qui changent beaucoup la donne
Voici ce que je recommande sur des WordPress exposés qui subissent régulièrement scanning et enumeration. Pas des changements conceptuels, plutôt des réglages concrets, faciles à vérifier.
Mettre à jour WordPress, thèmes et plugins, y compris les composants “moins visibles” comme les plugins de sécurité, de formulaires, et de cache. Désactiver les fonctionnalités inutiles (souvent XML-RPC si non requis) et réduire l’exposition des endpoints. Activer un contrôle de débit sur les pages d’authentification et sur les endpoints d’administration. Uniformiser la gestion des erreurs en production pour éviter des messages trop précis, notamment les traces et détails techniques. Filtrer côté reverse proxy ou WAF les patterns répétitifs et les chemins non attendus, en surveillant l’impact sur les robots légitimes.Comparer les réponses: pourquoi “répondre pareil” peut aider
Une nuance intéressante: les attaquants ne cherchent pas seulement à accéder, ils cherchent à distinguer. Si vos réponses changent fortement selon l’existence d’un fichier, selon la présence d’un auteur, ou selon une règle de permission, vous facilitez l’enumeration.
C’est pour cela que certains ajustements peuvent aider. Par exemple, si une requête “supposée” renvoie 200 avec une page vide dans un cas, puis 404 dans un autre, l’attaquant apprend. Si, au contraire, vous renvoyez une réponse homogène et sans détails, la même exploration perd en valeur.
Attention toutefois: rendre tout identique peut aussi compliquer le diagnostic interne. Vous ne voulez pas de “blinding” total au détriment du support. Un bon compromis consiste à uniformiser les détails techniques, tout en gardant des informations côté serveur pour vous.
Voici une comparaison utile, même si elle semble abstraite. Elle explique pourquoi certains réglages fonctionnent mieux ensemble.
- Réduire l’information: moins de détails techniques dans les réponses et les erreurs. Réduire l’accès: bloquer les endpoints inutiles, limiter l’admin, corriger les permissions. Réduire la vitesse d’énumération: rate limiting et protections contre les requêtes répétées. Réduire la précision offerte par le serveur: homogénéiser les réponses là où c’est faisable. Réduire les angles morts: journaux exploitables pour repérer les motifs et ajuster.
Détection active: quand un scanner “passe à l’étape suivante”
Le scanning et l’énumeration sont parfois des préludes. Un bon indicateur de changement, c’est quand le trafic bascule d’une phase “exploration” vers une phase “action”. Sur WordPress, ce basculement peut se manifester par:
- plus de requêtes vers les endpoints d’authentification; augmentation de la fréquence des tentatives sur des identifiants probables; succession rapide de requêtes, avec des paramètres de plus en plus cohérents.
Ce moment est idéal pour agir. Par exemple, vous pouvez déclencher des règles temporaires: renforcer le throttling, exiger un challenge supplémentaire sur des routes sensibles, ou bloquer des IP qui se comportent de façon trop déterministe.
J’ai vu des cas où un blocage temporaire a suffi à faire “décrocher” un bot. Pas parce qu’il était incapable de contourner, mais parce que le coût a dépassé le bénéfice estimé. Le principe vaut aussi pour des scanners “low and slow”.
Tests et validation, sans se mentir
Il est facile de croire que “tout est sécurisé” parce qu’un test rapide ne montre rien. Le vrai test, c’est la combinaison de trois choses: l’impact sur le site, la réduction des signaux d’énumération, et l’évolution du trafic hostile.
Quelques méthodes défendables:
- Vérifier sur staging que les endpoints que vous utilisez fonctionnent encore après durcissement. Comparer les logs avant et après modifications sur une fenêtre de quelques jours, pas sur une seule heure. Surveiller les codes retour: si vos 404 explosent au point de saturer les logs, vous devrez peut-être ajuster plutôt que bloquer aveuglément. Observer la part du trafic qui diminue, et pas seulement le nombre de requêtes.
Un piège classique: appliquer un WAF qui bloque beaucoup, puis confondre la baisse du bruit avec une vraie réduction des capacités d’énumération. Si l’attaquant trouve un chemin alternatif, vous devez le repérer.
Edge cases: ce qui casse quand on durcit trop
Le durcissement est rarement “gratuit”. Voici les situations fréquentes qui compliquent la défense contre scanning et enumeration:
- Des outils internes ou des prestataires utilisent des endpoints d’administration à des horaires précis, et se retrouvent bloqués par le filtrage trop strict. Des plugins dépendent d’API ou de XML-RPC, et le désactiver “par sécurité” casse une fonctionnalité. Un CDN ou un WAF modifie les headers et perturbe des intégrations (auth OAuth, webhooks, cache). Les règles de rate limiting déclenchent un faux positif pendant une campagne marketing (pics d’accès légitimes).
Ce n’est pas un argument contre la sécurité. C’est une raison de calibrer. Commencez par réduire ce qui est inutile, puis ajoutez des protections graduelles.
Une stratégie réaliste: réduire la rentabilité plutôt que viser l’innocence
Les attaques de type scanning et enumeration ne disparaissent pas. Si votre site a de la valeur, il sera scanné. La réussite, c’est d’augmenter le coût et de diminuer la précision. Un attaquant qui passe trop de temps à essayer des hypothèses, et qui ne peut pas déduire rapidement l’environnement, finit par se tourner ailleurs.
C’est aussi pour cela que les meilleures défenses sont souvent modestes, mais cohérentes: mises à jour régulières, surfaces réduites, contrôles d’accès, gestion propre des erreurs, et protections réseau.
Si vous devez retenir une idée: le scanning est une conversation entre le bot et votre serveur. Vous ne pouvez pas empêcher la conversation, mais vous pouvez réduire ce que votre serveur lui permet de conclure.
Plan de travail pour les prochaines semaines
Si vous voulez rendre la démarche concrète, procédez par cycles. Un premier cycle pour corriger les évidences, puis un second pour affiner les règles et l’observabilité.
Sur la durée, vous gagnerez surtout en clarté. Vous saurez quels chemins sont réellement inutiles chez vous, quels endpoints doivent rester ouverts, et quelles réponses posent problème. Ensuite, durcir devient une question d’ajustement, pas de pari.
Au final, le meilleur hardening WordPress contre scanning et enumeration, ce n’est pas un secret. C’est un système cohérent, maintenu, et observé. Quand vous combinez ça, le bruit diminue, les tentatives deviennent moins pertinentes, et vos équipes voient moins d’urgences.