16 Attack Sensors WordPress

L’efficacité de la détection des attaques sur WordPress dépend entièrement de la qualité des signaux qu’elle surveille. ReportedIP Hive exploite 16 capteurs indépendants couvrant les interfaces de Login, de commentaires, REST, XMLRPC et 404 — chacun doté d’un seuil réglable et d’une valeur par défaut raisonnable.

Ce guide répertorie les 16 capteurs, les seuils par défaut avec lesquels ils sont livrés, ainsi que le type d’attaque que chacun d’entre eux bloque.

Qu’est-ce que ReportedIP Hive ?

ReportedIP Hive est un plugin de sécurité WordPress complet qui combine une protection contre les attaques par Brute Force, une suite complète d’authentification à deux facteurs (2FA) et des informations sur les menaces issues de la communauté (sur inscription). La couche de détection décrite ici est gratuite dans tous les modes, y compris le mode « Local Shield » entièrement hors ligne. L’ensemble complet des fonctionnalités de ReportedIP Hive est présenté sur la page dédiée au produit.

Les 16 capteurs de détection et leurs paramètres par défaut

Chaque capteur comptabilise les événements par adresse IP au sein d’une fenêtre glissante. Dès que le seuil est dépassé, l’adresse IP est transférée vers la liste de blocage. Les valeurs par défaut sont volontairement prudentes : vous pouvez les renforcer ou les assouplir dans la rubrique « Paramètres → Protection ».

Tentatives de Login infructueuses — 5 échecs / 15 min.
Attaque par « password spray » — noms d’utilisateur distincts provenant d’une même adresse IP, toutes les 5 ou 10 minutes. Les compteurs sont hachés ; ainsi, aucun nom d’utilisateur en clair n’est stocké.
Spam dans les commentaires — 5 / 60 min, évalué avant l’application du filtre de commentaires.
Abus XMLRPC — 10 / 60 min, avec system.multicall surveillance séparée.
Abus de mot de passe d’application — Tentatives d’authentification de base REST/XMLRPC visant à contourner la 2FA, toutes les 5 ou 15 minutes.
Rate Limit de l’API REST — 240 par 5 minutes au total, 20 par 5 minutes pour les routes sensibles.
Protection contre l’User Enumeration — bloque ?author=N, /wp-json/wp/v2/users et les requêtes oEmbed, et masque les erreurs de Login.
404 / détection par scanner — 12 / 2 min, plus un blocage immédiat des chemins connus pour être malveillants, tels que .env, wp-config.bak et /.git/.
Web Application Firewall — analyse l’URI, la chaîne de requête, le corps de la requête et l’agent utilisateur à la lumière d’un ensemble de règles signées et fournies par le serveur (SQLi, XSS, traversée de chemin, injection de commande, SSRF, Log4Shell, etc.). Le moteur et les règles de base OWASP Top 10 sont gratuits dans toutes les formules ; les ensembles de règles plus poussés des niveaux Paranoia Level 2 et 3 sont disponibles via Priority Sync dans la formule Professional.
Verified Bot Detection — vérifie d’abord si Googlebot, Bingbot et les autres robots d’indexation correspondent à leurs plages d’adresses IP officielles, puis effectue une vérification de secours via le Reverse DNS avec confirmation directe. Les usurpateurs sont signalés ou bloqués ; les robots d’indexation légitimes ne sont jamais bloqués.
Disposable-Email Blocking — vérifie, lors de l’inscription (WordPress et WooCommerce), si l’adresse figure dans la liste des adresses jetables, avec des modes « désactivé », « surveiller » et « bloquer ». Les relais de confidentialité tels que « Hide My Email » d’Apple sont autorisés par défaut.
Comment Honeypot — un champ leurre invisible et ignoré par les lecteurs d’écran dans le formulaire de commentaires ; les robots spammeurs qui remplissent tous les champs sont rejetés sans que les visiteurs réels aient à passer par un CAPTCHA.
Anomalie géographique : Login depuis un pays jamais utilisé auparavant par cet utilisateur, pouvant éventuellement entraîner la suppression des cookies associés aux Trusted Devices.
Politique relative aux mots de passe — longueur minimale, types de caractères autorisés et vérification facultative de l’anonymat k via « Have-I-Been-Pwned ».
Hooks de Login WooCommerce — les formulaires de paiement et « Mon compte » sont suivis séparément de wp-login.php.
Endpoints de consentement des bannières de cookies — Real Cookie Banner, Complianz, Borlabs et CookieYes sont par défaut exclus de la Whitelist des Rate Limits REST.

Pourquoi les moteurs de recherche et les robots d’indexation basés sur l’IA ne les repèrent-ils pas ?

Depuis la version 2.0.5, Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot et d’autres robots d’indexation vérifiés sont exclus des déclencheurs 404 et REST burst ; ainsi, un balayage légitime d’URL obsolètes ne fait jamais entrer un robot dans la chaîne de blocage. Cette exception est délibérée : une requête vers un chemin « Honeypot » tel que /.env se déclenche toujours instantanément, même si elle provient d’un robot se déclarant « Googlebot » — cette requête constitue en effet l’indicateur d’attaque.

Comment le fait de compter devient un obstacle

Les capteurs de type « Brute-Force » partagent une échelle commune de compteur de défaillances : 3 défaillances → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. Après la 15e défaillance, l’adresse IP est transférée vers une entrée à part entière dans la blocked table via le pipeline canonique handle_threshold_exceeded() , qui déclenche alors l’échelle d’escalade progressive et, en mode Communauté, met en file d’attente un rapport anonymisé.

Guides connexes

La documentation du plugin WordPress décrit en détail les paramètres de chaque capteur. Consultez l’intégralité des guides du plugin ReportedIP Hive ou consultez le code source sur GitHub.

Découvrez la rubrique « ReportedIP Hive » →