Aller directement au contenu principalAller directement au pied de page
Guides des plugins

12 capteurs d'attaques qui détectent les intrusions dans WordPress en temps réel

Patrick Schlesinger
Couverture du guide du plugin ReportedIP — 12 capteurs de détection d'attaques WordPress

L'efficacité de la détection des attaques sur WordPress dépend entièrement de la qualité des signaux qu'elle surveille. ReportedIP exploite 12 capteurs indépendants couvrant les interfaces de connexion, 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 12 capteurs, les seuils par défaut avec lesquels ils sont livrés, ainsi que les attaques que chacun d'entre eux permet de bloquer.

Qu'est-ce que ReportedIP ?

ReportedIP est un plugin de sécurité WordPress complet qui combine une protection contre les attaques par force brute, 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 ReportedIP est présenté sur la page du produit.

Les 12 capteurs de détection et leurs réglages par défaut

Chaque capteur comptabilise les événements par adresse IP dans une fenêtre glissante. Dès que le seuil est dépassé, l'adresse IP passe au niveau supérieur de la grille de blocage. Les valeurs par défaut sont volontairement prudentes : vous pouvez les ajuster à votre guise dans Paramètres → Protection.

  • Connexions infructueuses — 5 échecs / 15 min.
  • Attaque par force brute — noms d'utilisateur uniques provenant d'une seule adresse IP, toutes les 5 ou 10 minutes. Les compteurs sont hachés, de sorte qu'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 via XMLRPC — 10 / 60 min, avec system.multicall regardés séparément.
  • Abus de mot de passe d'application — Tentatives d'authentification de base REST/XMLRPC visant à contourner la 2FA, 5 / 15 min.
  • Limite de requêtes de l'API REST: 240 par 5 minutes au total, 20 par 5 minutes pour les routes sensibles.
  • Protection contre l'énumération des utilisateurs — blocs ?author=N, /wp-json/wp/v2/users et les requêtes oEmbed, et masque les erreurs de connexion.
  • 404 / détection par scanner — 12 / 2 min, plus un blocage immédiat sur les chemins connus pour être défectueux, tels que .env, wp-config.bak et /.git/.
  • Anomalie géographique — une connexion provenant d'un pays jamais utilisé auparavant par cet utilisateur, ce qui peut éventuellement entraîner la suppression des cookies associés aux appareils de confiance.
  • 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 connexion WooCommerce — les formulaires de paiement et « Mon compte » sont suivis séparément de wp-login.php.
  • Points de terminaison de consentement des bannières de cookies — Real Cookie Banner, Complianz, Borlabs et CookieYes sont par défaut exclus de la limitation de débit 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 lorsqu'elle provient d'un « Googlebot » autoproclamé — cette requête est l'indicateur d'attaque.

Comment le fait de compter peut devenir un obstacle

Les capteurs de type « force brute » partagent une échelle commune de compteur d'échecs : 3 échecs → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. Après le 15e échec, l'adresse IP est transférée vers une entrée réelle dans le blocked tableau via le canonique handle_threshold_exceeded() pipeline, qui déclenche alors la procédure 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 pluginReportedIP ou consultez le code source sur GitHub.

Découvrez ReportedIP →

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués d'un *

Remplissez ce champ
Remplissez ce champ
Veuillez saisir une adresse e-mail valide.
Vous devez accepter les conditions pour continuer