Il n’est pas nécessaire d’être une cible de grande valeur pour subir une attaque automatisée à grande échelle. Pas besoin de données précieuses, d’être connu, ni d’avoir commis la moindre erreur. Il suffit d’avoir un WordPress accessible publiquement sur Internet. Voici ce qui s’est passé, couche par couche, lorsqu’un site protégé par SeenSecure a reçu une rafale de plus de 300 requêtes par minute en quelques secondes.
Ce n’est pas une personne, c’est un scanner
Une attaque de ce type n’est presque jamais lancée par quelqu’un assis devant un clavier en train de décider quoi tester. C’est un script qui parcourt une liste de milliers de chemins connus — anciens dossiers de plugins, fichiers de démonstration, scripts de test oubliés — et les teste contre des millions de domaines, l’un après l’autre, sans relâche ni discernement. La cible n’est pas “votre” WordPress en particulier : c’est n’importe quel WordPress qui répond “oui” à l’un de ces chemins.
Dans ce cas précis, les requêtes comportaient des motifs immédiatement reconnaissables pour quiconque a de l’expérience en sécurité WordPress :
- Des requêtes vers des fichiers de démonstration de bibliothèques tierces (comme
getid3) qui, dans d’anciennes versions de certaines extensions, permettaient de lire voire d’écrire des fichiers sur le serveur. - Des scripts de test abandonnés d’intégrations de paiement/CRM (comme Infusionsoft) qui exposent parfois des fonctions internes sans authentification.
- Des tentatives de traversée de répertoires (path traversal) du type
../../../etc/passwd, cherchant à sortir du dossier du site pour lire des fichiers système. - Des charges avec syntaxe d’injection SQL, testant si un paramètre d’URL arrive sans filtrage jusqu’à une requête en base de données.
Aucune de ces techniques n’est nouvelle ni sophistiquée. Ce sont, littéralement, les mêmes catégories de failles qu’exploitait déjà le ver Morris en 1988 — sauf qu’aujourd’hui elles sont testées contre des millions de sites à la fois, automatiquement, gratuitement, sans le moindre effort pour celui qui lance le scanner.
Couche par couche : ce qui a stoppé chaque tentative
Un site sans protection dédiée doit faire confiance au fait que WordPress lui-même, l’extension en question et le serveur soient tous parfaitement à jour et bien configurés — un pari risqué quand un seul fichier oublié suffit à ouvrir la porte. Voici où la chaîne se rompt à chaque couche :
- Rate Limiting : dès qu’une même IP dépasse le nombre de requêtes par minute autorisé, elle est coupée — sans attendre d’analyser ce qu’elle demande exactement. C’est la première barrière, et la moins coûteuse à maintenir sous forte charge.
- Règles du pare-feu (WAF) : chaque requête restante est comparée à des motifs d’attaque connus — traversée de répertoires, injection SQL, XSS. En cas de correspondance, elle est bloquée avant même d’atteindre WordPress.
- Protection des fichiers sensibles : les chemins vers les fichiers de démonstration, sauvegardes, journaux ou manifestes de dépendances sont bloqués au niveau du serveur, sans même exécuter PHP.
- Persistance du blocage : une IP qui déclenche plusieurs de ces alertes en peu de temps est bloquée pour une période donnée, si bien que ses requêtes suivantes ne sont même plus évaluées — elles sont coupées dès la première étape, à un coût quasi nul pour le serveur.
Le résultat, dans ce cas précis : plus de 300 requêtes par minute traversant ces couches, et zéro requête ayant réussi à exécuter du code non autorisé ou à accéder à un fichier qu’elle n’aurait pas dû voir.
Pourquoi ce n’est pas un cas isolé
Ce qui est inquiétant dans ce type d’attaque, ce n’est pas sa sophistication — elle n’en a aucune — c’est sa normalité. Ce même schéma se répète, avec de légères variations, contre pratiquement tous les sites WordPress publics, chaque jour, à toute heure. La différence entre un site compromis et un site qui ne se rend même pas compte qu’il a été sondé ne tient généralement pas à “plus de sécurité” dans l’absolu, mais au fait d’avoir des couches qui se complètent : l’une qui coupe par volume, une autre par motif, une autre par réputation, et un journal de tout cela pour savoir exactement ce qui s’est passé si quelque chose passe à travers.
Si vous voulez voir ce même type de trafic sur votre propre WordPress — vous en recevez probablement en ce moment même sans le savoir — le Moniteur de Trafic en temps réel de SeenSecure affiche chaque requête bloquée, avec la raison exacte en langage clair, sans avoir besoin de lire un journal technique pour comprendre ce qui se passe.