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 permet de bloquer.

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 le nombre d’é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 l’échelle 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 uniques par adresse IP, 5 / 10 min. Les compteurs sont hachés ; ainsi, aucun nom d’utilisateur n’est stocké en clair.
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/.
Le Web Application Firewall analyse l’URI, la chaîne de requête, le corps de la requête et l’User-Agent à l’aide d’un ensemble de règles signées fournies par le serveur (SQLi, XSS, traversée de chemin, injection de commande, SSRF, Log4Shell, etc.). Le moteur et la base de référence 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 : le système vérifie d’abord l’identité de Googlebot, Bingbot et d’autres robots d’indexation par rapport à leurs plages d’adresses IP officielles, puis recourt à une solution de secours basée sur le Forward-confirmed reverse DNS. Les usurpateurs sont signalés ou bloqués ; les robots d’indexation légitimes ne sont jamais bloqués.
Protection contre les inscriptions abusives, un ensemble de règles unique pour chaque interface d’inscription : domaines de messagerie jetables avec modes « désactivé », « surveillé » ou « bloqué » (les relais de confidentialité tels que « Masquer mon e-mail » d’Apple sont autorisés par défaut), noms d’utilisateur interdits, règles d’autorisation et de blocage des e-mails, et une Rate Limit du nombre d’inscriptions par adresse IP.
Preuve de l’exécution du formulaire : un champ d’ancrage masqué ainsi qu’un champ jumeau ajouté par script, dont le nom varie selon l’installation, dans les commentaires, les inscriptions et les réinitialisations de mot de passe ; une soumission ne contenant aucun de ces deux champs n’a jamais permis d’afficher le formulaire. Verdict à quatre volets, gratuit sur toutes les formules.
La vérification des menaces pour la communauté au niveau des formulaires, des commentaires, des inscriptions et des réinitialisations de mot de passe s’effectue par rapport au Community Network, selon le même seuil que celui appliqué par la page de Login ; une adresse à partir de laquelle le site refuserait une connexion ne peut pas non plus publier de commentaire.
Anomalie géographique : Login provenant d’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, classes de caractères et vérification facultative de l’anonymat de type « k » via Have-I-Been-Pwned.
Les hooks de Login WooCommerce, ainsi que les formulaires de paiement et « Mon compte », sont suivis séparément de wp-login.php.

Deux éléments présents sur le même écran qui ne sont pas des capteurs. Le « Honeypot » des commentaires est un champ leurre invisible, ignoré par les lecteurs d’écran, situé dans le formulaire de commentaire : les bots qui remplissent tous les champs sont rejetés, et un véritable visiteur ne voit jamais de CAPTCHA. Il fait partie de la couche « Honeypot » plutôt que des capteurs de comptage. De plus, les endpoints de consentement de Real Cookie Banner, Complianz, Borlabs et CookieYes sont d’emblée exemptés de la Rate Limit REST, car sur un site conforme, ils apparaissent comme une série de requêtes à chaque consultation de page. Aucun d’entre eux n’entre en ligne de compte pour un blocage, c’est pourquoi aucun n’est considéré comme un capteur.

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, une exploration 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 déclenche toujours instantanément le mécanisme ; même si elle provient d’un « Googlebot » autoproclamé, cette requête constitue un 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 le 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 » →