Plugin WordPress : ReportedIP Hive (Full Edition)

ReportedIP Hive est un plugin de sécurité WordPress développé par la communauté. Il transforme chaque site protégé en capteur : lorsqu’un site est attaqué, la « ruche » en tire des enseignements et tous les autres sites peuvent repousser l’attaquant avant même que la première requête n’aboutisse. Informations en temps réel sur les menaces, seize Attack Sensors dont un Web Application Firewall, une authentification à deux facteurs (2FA) à quatre méthodes, Progressive Block Escalation et des ensembles de règles de pare-feu signés et fournis par le serveur. Open source, publié sous licence GPLv2+ sur GitHub.

Installation

Démarrage rapide

Le démarrage rapide a remplacé le Setup Wizard en dix étapes dans la version 2.1.54. Il pose deux questions, le mode et la clé, lit votre formule lors de la vérification de la clé et active une recommandation pour cette formule. Community Network est présélectionné et exige une clé vérifiée ; Local Shield est l’alternative et n’est jamais bloqué. Le bouton expert applique la même recommandation et ouvre les paramètres ; vous pouvez aussi importer un export JSON existant. L’ancienne adresse page=reportedip-hive-wizard redirige vers le démarrage rapide.

Une montée de formule ultérieure active ce que recommande la nouvelle formule pour chaque paramètre que vous n’avez pas modifié vous-même ; la bannière après la montée liste ce qui a changé. Relancer le démarrage rapide réapplique les valeurs recommandées pour votre formule et les trois interrupteurs ; tous les autres paramètres restent en l’état.

Modes de fonctionnement

Deux modes, basculez entre eux à tout moment sans perdre les données locales.

Ce dont vous bénéficiez à chaque niveau

Le plugin Hive lui-même est entièrement fonctionnel sur la formule Free : protection locale, les seize capteurs, les quatre méthodes d’authentification à deux facteurs (2FA). Les niveaux payants incluent une infrastructure de diffusion gérée (e-mail et SMS) ainsi que des quotas plus élevés pour le Community Network. Consultez la page Tarifs pour une comparaison complète et pour passer à un niveau supérieur.

La formule « Business » est cumulable. Tous les chiffres indiqués ci-dessus pour la formule « Business » s’entendent par licence. Souscrivez à la formule « Business » x2, x5, x10 ou x20 lors du paiement (ou modifiez ce nombre ultérieurement dans le portail client Stripe) : le nombre de vérifications/rapports quotidiens, le quota mensuel d’e-mails/SMS pour l’authentification à deux facteurs (2FA) et le nombre de domaines s’adaptent tous au nombre de licences que vous possédez. Par exemple, x5 correspond à 75 domaines et 500 000 vérifications par jour. Une remise sur volume s’applique automatiquement à partir de x2. La formule PRO reste à licence unique ; les chiffres de la formule Enterprise sont illimités (dans le cadre d’une utilisation raisonnable) et ne sont jamais multipliés.

Ordre de consommation des forfaits (PRO et Business) : d’abord le quota mensuel inclus (25 SMS / 500 e-mails pour la version PRO, 75 / 2 500 pour la version Business), puis le solde prépayé du forfait. Une fois ces deux quotas épuisés, l’API renvoie un code HTTP 429 et Hive bascule vers l’authentification locale wp_mail() pour les e-mails (ou les limites strictes pour les SMS), les autres méthodes de 2FA restent opérationnelles. Les crédits des forfaits n’expirent jamais. Stripe utilise tax_behavior = inclusive pour les forfaits au prix brut (conformes à la PAngV) ; la facturation inversée / OSS est gérée automatiquement par Stripe Tax.

Défense à 6 couches

Hive applique ses vérifications dans l’ordre ; chaque couche peut interrompre la requête avant qu’elle n’atteigne la suivante. Associé à init avec une priorité 1 afin que les autres plugins ne s’exécutent pas pour une adresse IP bloquée.

1. La Whitelist, les adresses IP de confiance et les plages CIDR sont toujours autorisées (votre bureau, les services de surveillance, etc.).
2. Liste de blocage locale : les adresses IP que vous avez bloquées manuellement ou qui ont dépassé les seuils locaux. Stockées dans le wp_reportedip_hive_blocked.
3. Web Application Firewall (WAF), l'ensemble de règles WAF actif est comparé à l'URI, à la requête, au corps du message et à l'agent utilisateur ; toute correspondance est bloquée via le chemin 403 partagé et codé par référence. Prise en compte de la Whitelist et de l'auteur du contenu pour éviter les False Positives. Un module optionnel à intégrer avant WordPress peut exécuter cette couche avant même le chargement de WordPress.
4. Les compteurs de tentatives, de Login, de commentaires, de requêtes XMLRPC, de rafales REST et de scans 404 déclenchent un blocage automatique dès que le seuil est atteint.
5. En mode « Community Network », les adresses IP dont le niveau de confiance est ≥ au seuil défini sont bloquées en périphérie.
6. Authentification à deux facteurs (2FA) : les comptes protégés doivent fournir un deuxième facteur d’authentification pour se connecter.

Les seize Attack Sensors

Chaque capteur peut être activé ou désactivé et réglé indépendamment dans Protection → Détection et seuils. Le tableau contient également trois mécanismes complémentaires qui empruntent le même pipeline sans compter comme capteurs à part entière : les chemins leurres signalent à la communauté au lieu de bloquer localement et relèvent de la couche honeypot, l'adresse de connexion masquée est un interrupteur d'accès et non un détecteur, et Block Escalation est l'échelle de réponse alimentée par chaque capteur. Le plugin lui-même compte seize capteurs, tout comme son readme : l’escalade correspond à l’échelle de réponse alimentée par chaque capteur, et le pont WooCommerce comptabilise les échecs de Login à la vitrine au profit du capteur de Brute Force existant.

Progressive Block Escalation

Les récidivistes paient plus cher. L’échelle par défaut est la suivante : 5 min → 15 min → 30 min → 24 h → 48 h → 7 j. Après 30 jours sans incident, le compteur revient à l’étape 1. Les visiteurs légitimes bloqués pour la première fois (CGNAT, administrateurs maladroits, sortie du réseau mobile) sont débloqués en quelques minutes ; les attaquants persistants atteignent l’étape des 7 jours.

L'échelle, la fenêtre de réinitialisation et le commutateur principal se trouvent sous Protection → Blocage et escalade → Progressive Block Escalation. La recommandation du démarrage rapide laisse l'échelle activée afin que les nouvelles installations escaladent dès la première sauvegarde. Le paramètre fixe block_duration s'applique toujours lorsque l'échelle est désactivée. Une granularité inférieure à l'heure est fournie par le ReportedIP_Hive_Database::block_ip_for_minutes().

Web Application Firewall et mise en place des règles

Depuis la version 2.1.2, Hive intègre un Web Application Firewall inspectant les requêtes. Lorsqu’ init il compare l’ waf ensemble de règles actives par rapport à l’URI, à la chaîne de requête, au corps de la requête et à l’agent utilisateur, et bloque toute correspondance via le chemin 403 partagé, compatible avec la mise en cache et codé par référence. Il est renforcé contre les attaques ReDoS (retour en arrière PCRE limité, mode « fail-open » en cas de règle mal formée), prend en compte les Whitelists et l’auteur du contenu pour éviter les False Positives, et ajoute environ 4 µs d’utilisation du processeur par requête sans aucune requête de base de données supplémentaire lorsqu’un cache d’objets persistant est présent.

Les règles ne sont pas codées en dur dans le plugin. Elles sont fournies par la Rule API de ReportedIP : servies par le serveur, versionnées, signées avec Ed25519 et réparties par niveaux sur cinq ensembles de règles (waf, bot_signatures, disposable_domains, scan_paths, tor_exits). Le plugin vérifie chaque ensemble de règles par rapport à une clé publique intégrée avant de l’appliquer et se rabat toujours sur un ensemble de base intégré ; ainsi, un flux altéré, surdimensionné ou inaccessible ne peut jamais corrompre vos règles. Les nouvelles signatures d’attaques sont diffusées à toutes les installations en quelques heures, sans qu’aucune mise à jour du plugin ne soit nécessaire.

• Inclus gratuitement dans toutes les formules : le moteur WAF et l’ensemble de règles de base « OWASP Top 10, Paranoia-Level 1 », entièrement utilisables hors ligne en mode « Local Shield » à partir de la base intégrée.
• Priority Sync (à partir de la formule Professional) : les ensembles de règles Paranoia-Level-2/3 plus complets, fréquemment mis à jour et signés (couverture de l’obfuscation et du contournement), ainsi que les flux en temps réel des plages d’adresses IP de bots et des domaines jetables. La version Free synchronise la base de référence intégrée ; la version Contributor, une fois par semaine ; les versions Professional et supérieures, quotidiennement.
• Extended Protection (en option), un module pré-WordPress auto_prepend_file qui exécute le WAF avant le chargement de WordPress. Les piles Apache (.htaccess) et PHP-FPM, y compris nginx + PHP-FPM, sont automatiquement configurées via un répertoire racine .user.ini, qui couvre tous les Endpoints PHP indépendamment des location (depuis la version 2.1.17) ; les piles sans SAPI PHP FastCGI bénéficient d’une ligne dans le fichier php.ini ou dans le panneau d’hébergement auto_prepend_file ou un extrait de code nginx fastcgi_param extrait de l’onglet « Configuration du serveur ». Par défaut, le garde ignore l’inspection du corps de la requête pour les requêtes authentifiées ; ainsi, les éditeurs connectés qui enregistrent du contenu ne le déclenchent jamais. Les règles relatives aux URL et aux user-agents s’appliquent toujours, et le moteur intégré à WordPress reste le dispositif de sécurité tenant compte des capacités. Désactivé par défaut ; sa suppression supprime les directives contrôlées par Hive et neutralise le garde en le transformant en un espace réservé inerte au lieu de le supprimer (depuis la version 2.1.8), de sorte qu’une directive résiduelle dans un fichier php.ini ou une configuration nginx modifiée manuellement ne peut jamais pointer vers un fichier manquant et provoquer une erreur 500 sur le site. La désactivation du moteur WAF ou le passage en mode « rapport uniquement » neutralise également automatiquement le garde.
• Codes de référence : chaque bloc (WAF ou capteur) porte un code corrélable tel que WAF_SQLI-3F9A2B71, affiché sur la page de blocage et émis dans l’en-tête X-RIP-Ref en-tête. Un visiteur bloqué à tort génère une courte chaîne de caractères que l’administrateur peut retrouver dans les journaux ; ce jeton est un hachage unidirectionnel de l’adresse IP, du motif et de l’heure, ce qui garantit qu’aucune donnée personnelle n’est exposée.

La configuration se trouve sur la page « Protection », dans la carte « Pare-feu et bots » (moteur, mode, sélecteur de Paranoia-Level, vérification des bots, défense anti-spam). Rule Sync, les exceptions WAF, la protection « Extended Protection » et tous les extraits de code du serveur web se trouvent sur la page « Outils » (onglets « Règles » et « Serveur » ; affichée dans le menu en mode expert, toujours accessible par URL). Le journal du pare-feu se trouve sur la page « Activité ».

WAF Exceptions : gestion des False Positives

Depuis la version 2.1.9, un False Positive peut être résolu depuis l’interface d’administration sans modifier le code, à l’instar du fonctionnement des exclusions ModSecurity et de l’Allowlist de Wordfence. Un endpoint propriétaire qui reçoit légitimement des Payloads ressemblant à des attaques (un formulaire acceptant du code HTML, une API de sécurité ingérant des données d’attaques signalées, un constructeur de pages publiant du balisage brut) déclenche parfois une signature d’injection ; une exception permet à ce cas particulier de passer tandis que le moteur continue de protéger tout le reste.

• Où ? Outils → Règles → WAF Exceptions, plus une action « Autoriser » en un clic sur chaque ligne du journal WAF qui préremplit une exception ciblée pour cette règle précise sur ce chemin d’accès, sans qu’il soit nécessaire de connaître l’ID de la règle par cœur.
• Portées. Une exception cible une seule règle (par ID de règle, tiré du journal des blocages du WAF), un groupe de règles (sélectionné parmi les catégories connues du moteur) ou, pour un Endpoint propriétaire, l’ensemble du moteur sur un chemin, éventuellement restreint à une plage d’adresses IP ou CIDR. Une exception portant sur l’ensemble du moteur doit toujours comporter une restriction de chemin d’accès ou d’adresse IP, afin que le pare-feu ne puisse jamais être désactivé globalement par accident.
• Définissez son champ d’application de la manière la plus restrictive possible. Préférez une règle unique sur un chemin à un groupe de règles, et un groupe de règles à une exception portant sur l’ensemble du moteur. Le journal des blocages enregistre la valeur correspondante, la cible inspectée, la méthode de requête, l’URI et l’agent utilisateur (depuis la version 2.1.11), ce qui vous permet de voir exactement quelle règle s’est déclenchée et pourquoi avant de l’autoriser.
• L'Extended Protection respecte cette même liste. Les exceptions actives sont intégrées au pare-feu « drop-in » pré-WordPress et mises à jour à chaque modification de l'Allowlist ; la couche pré-WordPress et le moteur intégré à WordPress ne présentent jamais de divergence.
• Multisite et formules d’abonnement. Les exceptions constituent des données à l’échelle du réseau, disponibles sur toutes les formules d’abonnement ; le moteur de protection lui-même reste gratuit.
• Porte de secours pour les développeurs. apply_filters('reportedip_hive_waf_bypass_routes', []) Exclut les routes REST au niveau du code. La correspondance s’effectue via un test de préfixe ancré par rapport à la route WP REST résolue, et non via une sous-chaîne non ancrée de l’URI brute ; ainsi, un jeton de contournement introduit clandestinement dans un paramètre de requête sans rapport ne peut pas désactiver le WAF.

Verified Bot Detection, Disposable-Email Blocking et Comment Spam

• Verified Bot Detection (gratuite). Permet de confirmer qu’une requête se présentant comme provenant de Googlebot, Bingbot ou d’un autre robot d’indexation provient bien de ces sources : d’abord une correspondance sans DNS avec les plages d’adresses IP officielles du robot (Priority Sync), puis un repli vers un Reverse DNS confirmé en amont qui résout à la fois les enregistrements A et AAAA. Les usurpateurs sont signalés (par défaut) ou bloqués ; un robot d’indexation authentique n’est jamais bloqué. facebookexternalhit Vérification par rapport aux plages d’adresses IP publiées par Meta.
• Disposable-Email Blocking (gratuit). Vérifie l'adresse fournie lors de l'inscription (WordPress et WooCommerce) par rapport à la liste des adresses e-mail jetables. Trois modes : désactivé / surveillance / blocage. Les relais de confidentialité (Apple « Hide My Email », Firefox Relay, etc.) constituent une catégorie distincte qui est autorisée par défaut. La liste en temps réel s’appuie sur Priority Sync.
• Comment Honeypot (gratuit). Un champ leurre invisible, exclu des lecteurs d’écran, sur 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. Depuis la version 2.1.52, un robot qui tombe dans le piège compte aussi dans le compteur de commentaires de son adresse, si bien qu’un récidiviste atteint le seuil de blocage.
• Filtre anti-spam des commentaires (gratuit, depuis la version 2.1.52). Note chaque commentaire entrant selon le nombre de liens, la densité de liens, le nombre de domaines distincts, les domaines de messagerie jetable, les domaines de premier niveau révélateurs, un domaine dans le nom de l’auteur et un texte sans message propre derrière un lien. Plusieurs signaux doivent concorder avant qu’un commentaire ne compte. Par défaut, il est classé comme spam pour vérification ; le rejet immédiat est une option à activer, et le filtre peut être désactivé sous Protection → Inscription et spam.
• Preuve d’exécution du formulaire (gratuite, depuis la version 2.1.53). Les formulaires de commentaire, d’inscription et de réinitialisation du mot de passe portent un champ d’ancrage caché, et un petit script ajoute un second champ dont le nom est aléatoire pour chaque installation. Une soumission qui ne contient aucun des deux n’a jamais affiché le formulaire, ce qui est exactement l’allure d’un script qui poste directement à l’adresse. Rien de spécifique à la requête n’est émis, les caches de pages ne sont donc pas concernés. Pour les commentaires, le résultat n’est qu’un signal de notation : un visiteur qui navigue sans JavaScript voit son commentaire classé pour vérification plutôt que refusé, et ce motif seul ne compte jamais pour un blocage ; l’inscription et la réinitialisation du mot de passe, elles, refusent et expliquent pourquoi. REPORTEDIP_HIVE_DISABLE_FORM_PROOF dans wp-config.php désactive toute la couche.

Blocage des nœuds de sortie Tor (version Professional)

Depuis la version 2.1.41, Hive peut rejeter les connexions provenant de nœuds de sortie Tor connus. Cette fonctionnalité est strictement optionnelle ; le bouton de activation se trouve sous Protection → Blocage et escalade, est désactivé par défaut et nécessite la formule Professional : la liste des nœuds de sortie est fournie sous forme de tor_exits via la Rule Sync régulière et est actualisée deux fois par jour côté serveur, ce qui lui permet de rester à jour malgré la rotation des nœuds de sortie. Le isTor indicateur de réputation de la communauté couvre les adresses que la liste n’a pas encore répertoriées.

Les blocages Tor sont délibérément modérés. Ils sont temporaires : 24 heures par défaut, réglables via le reportedip_hive_tor_block_hours filtre, et ne sont jamais signalés à la communauté, car l’exploitation d’un nœud de sortie Tor ne constitue pas en soi une preuve d’abus. Les adresses IP figurant sur la liste Whitelist ne sont jamais bloquées par Tor. Une fois le blocage expiré, la requête suivante réévalue la liste actuelle des nœuds de sortie.

Règles d’inscription

Depuis la version 2.1.51, toutes les interfaces d’inscription sont soumises à un ensemble de règles unique : le formulaire d’inscription WordPress, l’inscription client WooCommerce, les inscriptions Multisite et la création programmatique d’utilisateurs. Les règles se trouvent sous Protection → Inscription et spam et sont évaluées dans un ordre fixe, selon le principe du « premier résultat trouvé » : Allowlist d’adresses IP, Rate Limit, noms d’utilisateur interdits, règles relatives aux e-mails, vérification des adresses e-mail jetables.

• Noms d’utilisateur interdits. Une entrée par ligne en plus d’une liste de base intégrée (admin, administrator, root, sysadmin, superadmin, webmaster, hostmaster, postmaster, support, moderator), qui peut être désactivée et n’est jamais décomptée de la limite gratuite.
• Règles relatives aux e-mails. Une liste proposant trois modes : désactivé, bloquer les adresses répertoriées ou n’autoriser que les adresses répertoriées. Un nom d’hôte seul signifie *@host. Une correspondance en mode « autoriser » prévaut sur la vérification des adresses e-mail jetables ; une liste vide en mode « autoriser » se comporte comme si le mode était désactivé, ce qui évite que les utilisateurs ne se bloquent eux-mêmes l’accès.
• Rate Limit. Par adresse IP, trois inscriptions toutes les 60 minutes par défaut, gratuite et configurable (plage de 1 à 60 minutes). Cela refuse uniquement l'inscription : pas de blocage d'IP, pas de signalement à la communauté, de sorte qu'un bureau utilisant un NAT n'est jamais pénalisé pour ses voisins.
• Inscription réservée à la liste Allowlist (version Professional). Si des plages d’adresses IP figurent dans la liste Allowlist, seules ces plages peuvent créer un compte.
• Blocage des noms d’utilisateur inconnus (activation manuelle, désactivé par défaut). Une tentative de connexion avec un nom d’utilisateur inexistant bloque immédiatement l’adresse IP. Notez le compromis : le blocage qui en résulte fait office d’oracle d’existence pour les noms d’utilisateur, c’est pourquoi cette option est désactivée par défaut et que l’événement n’est jamais signalé à la communauté.

Règles syntaxiques des entrées. Une entrée simple correspond exactement (sans distinction de majuscules/minuscules) ; une entrée contenant * est un caractère générique ancré, et une entrée encadrée de barres obliques (/^shop[0-9]+$/) est une expression régulière. Les formules Free disposent de dix entrées simples par liste, caractères génériques compris ; la formule Professional supprime cette limite et active les expressions régulières ainsi que l’inscription par liste Allowlist uniquement. Une sauvegarde dépassant la limite gratuite est rejetée avec un message indiquant la formule souscrite plutôt que d’être tronquée en silence.

Les refus sont consignés sous la forme prohibited_username, registration_denied et registration_limit et peuvent être filtrés sur la page « Activité » sous « Inscription ».

Commutateurs de verrouillage d’accès

Également disponibles depuis la version 2.1.51, et gratuits sur tous les forfaits : des commutateurs sous « Protection → En-têtes de sécurité » qui désactivent les parties de WordPress qu’un site n’utilise pas. Ils sont tous désactivés par défaut et peuvent être réactivés depuis le même écran.

• Accès à la REST API. Trois modes : ouvert, réservé aux visiteurs connectés ou restreint à certains rôles. Les espaces de noms figurant sur l’Allowlist restent publics dans tous les modes ; ils contiennent les Endpoints qui, sans cela, ne fonctionneraient pas (oembed/1.0, wp-site-health/v1les espaces de noms courants des bannières de cookies et des formulaires, ainsi que l’API de la boutique WooCommerce) ; reportedip-hive/v1 est toujours autorisé afin que les routes 2FA continuent de fonctionner. Les visiteurs reçoivent un code d’erreur 401, les utilisateurs connectés ne figurant pas dans la liste des rôles reçoivent un code d’erreur 403. La fermeture de l’API aux visiteurs supprime également les liens de découverte REST.
• XML-RPC. Refuse xmlrpc.php, désactive les pingbacks, supprime l’ X-Pingback en-tête à la source et supprime les liens vers les manifestes RSD et WLW. Les mots de passe d’application via REST ne sont pas affectés ; il s’agit du remplacement moderne des clients XML-RPC.
• Flux. Les flux RSS, Atom et de commentaires renvoient un code 404 et les liens vers les flux disparaissent de l’en-tête de la page.
• Espace d’administration pour les visiteurs non connectés. Refus d’accès /wp-admin/ aux visiteurs non connectés, ainsi que l’ /admin et /dashboard alias, vers lesquels WordPress redirige. L’ /login alias permet toujours d’accéder au formulaire de connexion, sauf si l’option « Hide Login » est activée : seule cette option supprime la redirection par défaut qui y envoie l’utilisateur wp-login.php. L’option « Hide Login » rend également wp-admin inaccessible aux visiteurs ; ce commutateur permet d’activer cette fonctionnalité séparément. admin-ajax.php et admin-post.php reste accessible, car des callbacks non authentifiés y envoient légitimement des requêtes POST.
• Exécution de PHP dans le répertoire « uploads ». Écrit un bloc marqueur dans le répertoire « uploads » .htaccess qui rejette les requêtes portant sur des noms de fichiers de type PHP, y compris la double extension classique shell.php.jpg. Apache uniquement ; sur nginx et les serveurs inconnus, la page affiche à la place l’extrait de code à coller dans la configuration du serveur. La désactivation de cette option supprime complètement le bloc.
• Empreintes logicielles. Supprime la balise de générateur WordPress et désactive l’affichage des erreurs PHP, sauf si WP_DEBUG et WP_DEBUG_DISPLAY soient activées. Il s’agit d’un renforcement de sécurité purement cosmétique : les numéros de version restent déductibles à partir des URL des ressources.

Le plan du site utilisateur (wp-sitemap-users-1.xml) ne constitue pas un paramètre à part entière. Il disparaît lorsque l’option « Bloquer la User Enumeration » est activée (ce qui est le cas par défaut), car il publiait précisément la liste que la défense masque.

Les refus sont enregistrés une fois par adresse IP et par événement, avec un délai d’attente de cinq secondes (rest_denied, xmlrpc_denied, feed_denied, admin_guest_denied). Ils ne déclenchent jamais l'escalade de blocage et ne sont jamais signalés à la communauté : il s’agit d’un contrôle d’accès, et non d’une détection d’attaques.

État de préparation du système

Dix-huit détecteurs surveillent les composants d’une installation susceptibles de tomber en panne sans signe avant-coureur : douze signalent un défaut, six proposent une amélioration et apparaissent comme carte d’étape suivante sur le tableau de bord plutôt que comme problème. Les problèmes en cours apparaissent dans la section « État du système » avec leur niveau de gravité, leur date d’apparition, un lien vers le paramètre concerné et un lien vers cette page. Les problèmes critiques et les avertissements génèrent en outre une notification récapitulative sur les pages du plugin ; le widget du Dashboard affiche leur nombre, et wp reportedip status les signale dans le issues champ. Les avertissements et les recommandations peuvent être ignorés à l’échelle du site pendant sept jours ; les problèmes critiques ne peuvent pas être ignorés. Un problème qui disparaît est oublié et recommence à zéro s’il réapparaît.

• File d’attente de protection non accessible en écriture (critique). Extended Protection est activée, mais le module de protection pré-WordPress ne peut pas écrire dans sa file d’attente d’événements, de sorte que ses blocages ne sont jamais importés et ne sont jamais escaladés. Corrigez les droits d’accès du répertoire mentionné dans le message, ou désactivez Extended Protection.
• Tâches planifiées bloquées (critique). Tous les hooks cron de Hive ont plus de 24 heures de retard, ce qui bloque le traitement de la file d’attente, la synchronisation de la réputation et le nettoyage. Il s’agit généralement d’un problème de boucle WP-Cron ; configurez un véritable cron système et désactivez DISABLE_WP_CRON.
• WP-Cron est désactivé sans solution de remplacement (avertissement). DISABLE_WP_CRON est activé, ALTERNATE_WP_CRON n’est pas activé, et aucun déclencheur externe ne s’est exécuté depuis plus d’une heure.
• En-tête d’IP de confiance sans plages de proxy (avertissement). Un en-tête d’IP client est pris en compte pour chaque pair ; par conséquent, toute personne accédant directement à l’origine peut usurper une adresse, se débarrasser d’un bloc ou se faire passer pour une IP figurant sur la liste Whitelist. Définissez vos plages de proxy sous Community.
• Schéma de base de données obsolète (critique). La version du schéma stockée est antérieure à celle du plugin. Il s’agit généralement d’une migration qui a échoué ; le rechargement de la page du plugin permet de la relancer.
• Couche communautaire dégradée (avertissement). La fenêtre des requêtes récentes affiche un faible taux de réussite. Vérifiez le trafic HTTPS sortant vers ReportedIP.com et la Community Access Key.
• Limite de Mail Relay atteinte (avertissement). Le quota mensuel de messagerie gérée est épuisé et les e-mails d’authentification à deux facteurs (2FA) sont redirigés vers wp_mail(). Souscrivez à un forfait de recharge ou attendez la réinitialisation.
• Limite de SMS Relay atteinte (avertissement). Le quota mensuel de SMS est épuisé. Les utilisateurs dont le SMS est le seul moyen de vérification doivent ajouter un deuxième moyen.
• Échec de la livraison des e-mails (avertissement). WordPress a signalé des wp_mail_failed erreurs ; les codes 2FA et les alertes ne parviennent donc pas. Vérifiez la configuration SMTP. Les adresses des destinataires sont supprimées du message stocké.
• Absence de backend de chiffrement (critique). Ni libsodium ni OpenSSL ne sont disponibles ; les secrets TOTP et les numéros de téléphone ne peuvent donc pas être chiffrés au repos. Demandez à votre hébergeur d’activer l’une de ces deux extensions.
• La file d’attente des rapports contient des entrées ayant échoué (avertissement). Les Reports ont épuisé leurs tentatives de réessai. Vérifiez-les et réessayez-les dans l’onglet « File d’attente API ».
• Retard dans la file d’attente des rapports (avertissement). Les rapports en attente s’accumulent, ce qui indique généralement un problème de cron ou de connectivité.
• Adresse de connexion encore publique (indicatif). Hide Login est désactivé, chaque bot sait donc où se trouve le formulaire de connexion. La carte d’étape suivante accepte un slug et active la fonction en une seule étape.
• 2FA boutique incluse mais désactivée (indicatif). Le site utilise WooCommerce et la formule comprend le défi client intégré au thème, qui n’est pas activé. Un clic suffit.
• Badge de pied de page désactivé (indicatif). Le badge « Protected by ReportedIP » n’est pas affiché. Il est facultatif et un clic l’active.
• Protection étendue possible mais inactive (indicatif). Le serveur prend en charge le guard exécuté avant WordPress et celui-ci ne tourne pas : chaque requête bloquée démarre donc encore WordPress d’abord.
• Local Shield au lieu du réseau communautaire (indicatif). Le site se protège lui-même, mais il n’interroge pas le réseau et n’y contribue pas.
• Votre propre second facteur manque (indicatif). L’authentification à deux facteurs est active pour le site et le compte qui consulte la page n’a configuré aucune méthode. Signalé par personne, jamais pour tout le site.

Sources de proxy de confiance (Cloudflare, proxys inversés, équilibreurs de charge)

Lorsque votre site fonctionne derrière Cloudflare, un proxy inverse ou un équilibreur de charge, le pair qui se connecte est le proxy ; l’adresse réelle du visiteur est transmise dans un en-tête HTTP tel que CF-Connecting-IP ou X-Forwarded-For. Sélectionnez cet en-tête sous Community → En-tête IP de confiance, et depuis la version 2.1.41, déclarez les adresses du proxy dans la liste Sources de proxy de confiance située juste en dessous, à raison d’une adresse IP ou d’une plage CIDR par ligne, par exemple les plages Cloudflare publiées.

Une fois cette liste configurée, l’en-tête n’est pris en compte que pour les requêtes provenant effectivement d’une adresse de proxy déclarée. Toute personne accédant directement à l’origine ne peut pas usurper l’en-tête pour se faire passer pour une adresse figurant sur la Whitelist ni contourner un blocage actif. Une liste vide conserve le comportement précédent (en-tête accepté depuis n’importe quel pair), de sorte que les configurations existantes continuent de fonctionner, mais si vous faites confiance à un en-tête, déclarez vos proxys. La même vérification est appliquée dans le garde « Extended Protection » pré-WordPress.

Security Headers

Renforcement des en-têtes de réponse sur chaque requête front-end. Les en-têtes déjà envoyées par votre serveur ou par un autre plugin sont détectées et laissées inchangées.

• Trio de base (gratuit), X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
• Avancé (Professional) : HSTS, Permissions-Policy, une politique de sécurité du contenu (Content-Security-Policy) (en mode « rapport uniquement » par défaut, avec un générateur) et le trio d’isolation inter-origines (COOP / CORP / COEP).

L'onglet « Configuration du serveur » permet en outre d'exporter les en-têtes configurés au niveau du serveur nginx add_header / Apache Header au niveau du serveur.

Protection & Hardening Score

Deux jauges du Dashboard (de 0 à 100, plus une notation de A+ à F, à la manière de Mozilla Observatory) évaluent votre couverture de détection et votre niveau de renforcement de la sécurité, avec des liens directs vers chaque élément pour activer un capteur. Les fonctionnalités verrouillées (payantes) sont prises en compte dans le potentiel visible, mais n’affectent pas votre score ; la formule Free peut donc tout de même atteindre la meilleure note.

Dashboard de sécurité et analyses

Depuis la version 2.1.57, le dashboard répond à « terminé, et maintenant ? » : une bannière d’état indique la formule pour laquelle la recommandation a été appliquée, la date de configuration et le nombre de réglages qui s’en écartent ; des cartes « prochaines étapes » (Hide Login désactivé, 2FA boutique incluse mais désactivée, badge désactivé, protection étendue possible mais inactive, Local Shield au lieu du Community Network, votre propre second facteur manquant) portent une action en ligne ou un lien et peuvent être reportées de sept jours ; une ligne par domaine de protection affiche l’état résumé et mène à la carte ; au plus une carte de formule s’affiche par visite. Le mode expert est un commutateur dans l’en-tête de page.

Le Dashboard principal s’ouvre sur une bande d’en-tête indiquant les attaques bloquées au cours des 30 derniers jours, celles bloquées aujourd’hui, les adresses IP actuellement bloquées et le nombre de vos couches de protection activées (par exemple 17 / 20). En dessous, les analyses s’appuient sur toutes les données des capteurs, et pas seulement sur les compteurs classiques de Login et de spam.

• Chronologie des événements de sécurité. Un graphique à aires empilées regroupant toutes les activités en sept catégories : Login et identifiants, Pare-feu (WAF), Scanners et sondes, Faux bots, Reconnaissance et énumération, Spam et inondations, et Anomalies, sur une période sélectionnable de 7, 30 ou 90 jours.
• Répartition des menaces. Une ventilation indiquant quelle famille d’attaques a dominé la période, afin que vous puissiez voir d’un seul coup d’œil si vous êtes confronté à des attaques par Brute Force, à des tentatives d’exploitation au niveau du pare-feu, à des scanners ou à du spam.
• Pare-feu : principaux types d’attaques. Classement des blocages du WAF par groupe de règles (SQL Injection, cross-site scripting, traversée de chemin, Log4Shell, agents utilisateurs de scanners, etc.).
• Répartition par niveau de gravité. Nombre d’événements critiques / élevés / moyens / faibles, afin que le volume des événements graves ne soit jamais masqué dans un total unique.
• Principaux attaquants (30 jours). Les adresses IP sources les plus actives avec leur nombre d’attaques, la date de leur dernière détection et s’elles sont actuellement bloquées ou simplement surveillées.
• Activité récente. Le flux d’événements en temps réel, chaque entrée étant associée à sa gravité et à sa famille de menaces, ainsi qu’aux détails pertinents (règle WAF correspondante, chemin exploré, nom de bot usurpé par le Spoofing).

Tous les chiffres sont réels quel que soit le forfait ; le Dashboard reflète ce que votre site a réellement bloqué. Les formules « Professional » et « Business » offrent en outre des analyses plus approfondies (historique et conservation des journaux plus longs, géolocalisation des attaquants et piste d’audit conforme aux normes de conformité décrite ci-dessous).

Depuis la version 2.1.41, les chiffres clés s’affichent également sous forme de widget de sécurité directement sur le Dashboard WordPress lui-même : les attaques bloquées au cours des 30 derniers jours, les blocages du jour, les adresses IP activement bloquées, les couches de protection et le score de détection apparaissent directement sur la page d’accueil du Dashboard de wp-admin, avec des liens directs vers le plugin. Sur les sites Multisite, le widget s’affiche sur le Dashboard du réseau et, pour les super-administrateurs, sur les Dashboard des sous-sites avec les chiffres à l’échelle du réseau. Depuis la version 2.1.51, il indique également le nombre de problèmes d’état de préparation en cours ; voir État de préparation du système.

Outre le Dashboard, il existe sept écrans sous forme de tableaux : « IP bloquées », « Whitelist », « Journaux de sécurité », « File d’attente API », l’Audit Event Trail (version Business), le gestionnaire de sessions sous « Utilisateurs → Sessions » (version Business) et la grille d’administration de l’authentification à deux facteurs (2FA). Une page distincte « État du système » répertorie tous les problèmes de préparation en cours avec leur niveau de gravité, leur date d’apparition et un lien vers le paramètre concerné. Depuis la 2.1.62, le filtre d'événements du journal de sécurité est consultable et sélectionne des groupes entiers, et chaque type d'événement écrit par l'extension figure dans un registre unique.

Audit Event Trail (Business)

Depuis la version 2.1.62, la piste enregistre qui a modifié quoi sur le site, et pas seulement ce qui est arrivé aux comptes. Huit groupes de déclencheurs, 48 types d'événements, chaque groupe étant un interrupteur sur la page Protection (carte « Confidentialité et journaux ») :

• Connexions et déconnexions (désactivé par défaut : ce sont les lignes les plus nombreuses, et les échecs figurent de toute façon dans le journal de sécurité).
• Comptes utilisateurs : inscription, suppression, modifications du profil, de l'e-mail et du mot de passe, changements de rôle avec l'utilisateur à l'origine, réinitialisations de mot de passe, blocages de compte, sessions terminées, capacités de rôle modifiées.
• Pages et articles : publié, dépublié, mis à la corbeille, restauré, supprimé, slug d'URL modifié. Les sauvegardes automatiques, révisions et brouillons automatiques sont ignorés.
• Extensions, thèmes et cœur : installé, mis à jour, activé, désactivé, supprimé, thème changé, cœur mis à jour, avec la version avant et après. Les mises à jour automatiques sont aussi des lignes, marquées cron.
• Réglages du site : 26 options du cœur (adresse du site, permaliens, lecture, discussion, inscription, mises à jour automatiques) et chaque réglage Hive, avec l'ancienne et la nouvelle valeur ; une liste est stockée sous forme d'ajouts et de suppressions.
• Menus et widgets : menus créés, modifiés et supprimés, emplacements de menu, widgets ajoutés à une barre latérale ou retirés.
• Éditeur de fichiers de thème et d'extension : un fichier enregistré via l'éditeur intégré, consigné uniquement si le fichier a réellement changé.
• Réseau (multisite uniquement) : sites créés, modifiés, archivés ou supprimés, utilisateurs ajoutés à un site ou retirés, droits de super administrateur accordés ou révoqués.

Chaque ligne indique l'utilisateur à l'origine, la voie de la requête (navigateur, WP-CLI, cron, REST, AJAX) et l'objet concerné, avec un lien tant qu'il existe. Les secrets ne sont jamais écrits : une clé de données ou un nom d'option désignant un mot de passe, un jeton, une clé ou un code garde ses valeurs hors de la table. La conservation est de 90 jours par défaut, réglable de 1 à 365, et le nettoyage nocturne s'exécute par blocs de 5 000 lignes comme pour le journal de sécurité. Stocké dans la table dédiée audit_log ; l'export et l'effacement RGPD la couvrent.

L'onglet sous Activité filtre par événement ou groupe de déclencheurs, utilisateur, adresse, objet et plage de dates, et les exports CSV et JSON reprennent le filtre actif. Sur un réseau, l'administrateur réseau restreint la liste à un site ou aux lignes réseau, et chaque administrateur de site dispose d'une page Piste d'audit dans le menu du site avec les lignes de ce site. En dessous du plan Business, l'onglet montre cinq lignes d'exemple et ce qu'il répondrait ; rien n'y est enregistré, et le journal de sécurité de 30 jours reste disponible sur chaque plan.

Contrôle des comptes utilisateurs et des sessions (formule Business)

Depuis la version 2.1.51, un compte peut être bloqué sans être supprimé : depuis la page de profil de l’utilisateur, depuis la liste des utilisateurs (colonne « Bloqués » et actions groupées) ou à l’aide wp reportedip user block. Le blocage s’accompagne d’un message facultatif affiché lors de la connexion et d’une note interne qui n’est jamais visible par l’utilisateur.

Un compte bloqué conserve l’intégralité de son contenu, mais ne peut pas se connecter, ne peut pas authentifier un mot de passe d’application et ne peut pas effectuer de réinitialisation de mot de passe. Le blocage met immédiatement fin à toutes les sessions et désactive tous les appareils 2FA de confiance ; ainsi, un utilisateur déjà connecté est déconnecté dès la requête suivante. Le blocage de votre propre compte ou de celui d’un super-administrateur est refusé, tout comme, dans le cas d’une installation sur un seul site, le blocage du dernier administrateur restant. Un blocage reste en vigueur même si l’abonnement expire, et la levée d’un blocage n’est jamais soumise à des conditions.

La page Utilisateurs → Sessions répertorie les sessions actives de chaque utilisateur connecté avec l’heure de connexion, la date d’expiration, l’adresse IP et l’appareil, et permet de mettre fin à une seule session ou à toutes les sessions d’un utilisateur. Votre propre session en cours ne peut jamais être interrompue à partir de cette liste. Les blocages et les interruptions sont consignés dans l’Audit Event Trail. En Multisite, la page se trouve dans l'administration du réseau, et un blocage s'applique à l'ensemble du réseau, car les utilisateurs et les sessions WordPress sont globaux au niveau du réseau.

MainWP Integration

Hive peut être géré à distance depuis un Dashboard MainWP sans plugin enfant supplémentaire et sans extension MainWP à acheter. Il s’intègre au filtre « MainWP Child » mainwp_child_extra_execution , de sorte que chaque tâche est authentifiée par le canal MainWP Child existant, sans identifiants supplémentaires ni nouvelle surface d’attaque. La configuration est simple : installez MainWP Child et Hive sur le site géré, connectez le site à votre Dashboard MainWP comme d’habitude, et le tour est joué.

Deux types de tâches sont pris en charge :

• Synchronisation des métriques de sécurité, chiffres agrégés uniquement : blocages actifs, taille de la Whitelist, tentatives de Login échouées, spam dans les commentaires, blocages pour raison de réputation, taille de la file d’attente, événements critiques récents, utilisateurs ayant activé l’authentification à deux facteurs (2FA). Depuis la version 2.1.6, la synchronisation rend également compte de l’état du pare-feu (waf_enabled, waf_report_only, waf_dropin_enabled, waf_dropin_running, waf_server et un waf_needs_setup ), ce qui permet à un Dashboard de signaler les sites dont l'Extended Protection est activée mais ne fonctionne pas encore, généralement un hôte nginx qui attend toujours son snippet serveur.
• Provisionnement (reportedip_hive_provision) : envoie une API Key à un site géré depuis le Dashboard de confiance et, depuis la version 2.1.12, permet en option de le basculer en mode « Community Network » au cours de la même tâche (community indicateur). La tâche de synchronisation signale l’état actuel de chaque site enfant operation_mode.

Aucune adresse IP, aucun nom d'utilisateur, aucun Secret ni aucune API Key ne quittent jamais le site géré ; la Payload de synchronisation se compose uniquement de comptages et d'indicateurs d'état.

Depuis la version 2.1.47, l’extension MainWP peut en outre gérer centralement les paramètres Hive : elle lit un schéma de paramètres versionné sur chaque site, applique une politique globale avec des remplacements de champs spécifiques à chaque site, et détecte les divergences grâce à une empreinte des paramètres rapportée à chaque synchronisation. La validation s’effectue toujours sur le site géré lui-même, clé par clé, les valeurs soumises à des restrictions de forfait étant ignorées de manière transparente.

Gestion de parc cloud (Business)

Avec la formule Business, ces mêmes politiques de paramètres peuvent être gérées sans MainWP, directement depuis votre Dashboard ReportedIP sous « Domaines » : définissez une politique globale, remplacez des champs individuels par site, appliquez-la en un clic et constatez immédiatement lorsqu’un site s’écarte de la politique, avec notamment une comparaison en temps réel entre les valeurs cibles et réelles par site.

• Participation strictement facultative. Chaque site décide : le bouton « Gestion de parc dans le cloud » de l’onglet « Paramètres généraux » de Hive est désactivé par défaut. Sans lui, le site rejette toute demande de gestion.
• Uniquement des requêtes signées. Chaque envoi est signé avec Ed25519 par le service de flotte de ReportedIP.com et vérifié sur votre site à l’aide d’une clé publique intégrée au plugin, avec en plus une fenêtre de validité de cinq minutes, des identifiants de requête à usage unique, une liaison à l’adresse propre à votre site et une preuve de votre Community Access Key. Il n’y a ni mot de passe, ni jeton, ni identifiant supplémentaire à gérer.
• Mêmes règles que MainWP. Les deux Dashboards utilisent le même protocole de paramètres ; chaque valeur est validée sur votre site avant d’être enregistrée, et les paramètres liés à un forfait sont ignorés, jamais imposés.
• Nécessite Hive 2.1.48 ou une version plus récente, le mode « Community Network » et une formule Business (ou Enterprise).

Réseaux multisites

La Full Edition est réservée aux réseaux (Network: truedepuis la version 2.0.0) : l’activation par site est masquée par WordPress afin que la configuration de sécurité reste uniforme sur l’ensemble du réseau. Les neuf tables se trouvent toutes sous $wpdb->base_prefix, ce qui fait que chaque décision relative aux menaces s’applique à l’ensemble du réseau, que les tentatives de Brute Force inter-sites sont agrégées dans un compteur central, et qu’un seul blocage exclut l’adresse IP de tous les sous-sites simultanément.

• Les administrateurs du réseau disposent de l'ensemble des paramètres, d'une vue des journaux pour tous les sites et de la piste d'audit avec un filtre par site.
• Les administrateurs de site d'un sous-site disposent d'une interface « Statut / Journaux » en lecture seule, de la piste d'audit de leur propre site (Business) et d'exactement deux réglages modifiables par site : le slug de la 2FA en frontend et des rôles supplémentaires soumis à la 2FA (un sous-site peut imposer la 2FA à davantage de rôles, jamais à moins).
• Cron ne s’exécute que sur le site principal ; il n’y a pas de synchronisations redondantes ni de nettoyages par sous-site.
• Les WAF Exceptions concernent l’ensemble du réseau et sont gérées par l’administrateur réseau.

Authentification à deux facteurs (2FA)

Quatre méthodes sont prises en charge et peuvent être combinées par utilisateur. Les Recovery Codes sont générés lors de la première configuration. Les Secrets sont chiffrés au repos (libsodium avec une solution de secours OpenSSL).

• TOTP : RFC 6238 (6 chiffres, fenêtre de 30 secondes). Compatible avec Google Authenticator, Authy, 1Password, Bitwarden, etc.
• E-mail : mot de passe OTP à six chiffres via le fournisseur de messagerie configuré ; limité en fréquence (3 codes toutes les 15 minutes, 5 tentatives de vérification par code, délai de réenvoi de 60 secondes).
• SMS : mot de passe à usage unique (OTP) à six chiffres via le SMS Relay managed ReportedIP (formule Professional et supérieures ; voir ci-dessous). Le numéro de téléphone est chiffré au repos.
• WebAuthn, Passkeys, clés de sécurité (YubiKey), authentificateurs de plateforme (Touch ID, Face ID, Windows Hello). Analyseur CBOR interne, aucune dépendance externe.
• Trusted Devices, jetons « se souvenir de cet appareil » activables avec une durée d’expiration configurable (30 jours par défaut). Stockés sous forme wp_reportedip_hive_trusted_devices sous forme de hachages SHA-256.
• Recovery Codes : 10 codes à usage unique xxxx-xxxx ; alerte de niveau de code faible lorsqu’il en reste ≤ 3.

Clés de sécurité matérielles (YubiKey)

Depuis la série 2.1.33–2.1.36, les clés matérielles FIDO2 sont pleinement prises en charge : la série YubiKey 5 (USB-A, USB-C, Lightning et les modèles NFC à approcher d’un téléphone), la gamme de clés de sécurité de Yubico et tous les autres authentificateurs CTAP2 fonctionnent sur les trois surfaces de vérification : la page interstitielle wp-login, le défi de la vitrine WooCommerce et la page de réinitialisation du mot de passe. Les anciennes clés U2F uniquement (CTAP1) ne sont pas officiellement prises en charge.

• Pour la configurer, ouvrez votre page de profil (Utilisateurs → Profil → Authentification à deux facteurs), sélectionnez « Ajouter une clé de sécurité » → « Clé de sécurité (USB / NFC) », donnez un nom à la clé, puis insérez-la et touchez le contact doré lorsque le navigateur vous y invite. Sur un téléphone, placez la clé à plat contre l’arrière de l’appareil, près du haut (NFC). Aucun code PIN FIDO2 n’est requis pour l’enregistrement.
• Une clé par compte est gratuite. La formule Business ajoute des clés de sécurité avancées : plusieurs clés par compte, la possibilité d’enregistrer une deuxième YubiKey et de la conserver en lieu sûr à titre de clé de secours, ainsi que la détection automatique du modèle (« YubiKey série 5 avec NFC » s’affiche à côté de la clé) et des alertes par e-mail chaque fois qu’une clé est ajoutée ou supprimée.
• Vous avez perdu votre clé ? Connectez-vous à l’aide de l’un de vos Recovery Codes (ou de votre clé de secours avec le forfait Business), puis supprimez la clé perdue sur la page de votre profil. La suppression de la dernière clé désactive définitivement cette méthode.
• Détection des clones : chaque connexion fait progresser le compteur de signatures de la clé. Toute authentification dont le compteur n’avance pas est rejetée, consignée et signalée au titulaire du compte par e-mail, quel que soit le forfait.
• Algorithmes : ES256 sur chaque clé ; Ed25519 est négocié automatiquement sur le micrologiciel YubiKey 5.2.3+ lorsque le serveur dispose de libsodium.

Protection contre les attaques Brute-Force de l'authentification 2FA

L'échelle de vérification de l'authentification à deux facteurs (2FA) est la suivante : 3 → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. Lorsque le compteur atteint le dernier échelon, l'adresse IP est transférée vers le auto_block_ip() (événement 2fa_brute_force) ce qui déclenche une escalade progressive et des Reports en mode « Community » comme n’importe quel autre capteur.

Headless 2FA REST

Pour les intégrations d’applications, le plugin expose trois routes sous l’espace de noms reportedip-hive/v1:

• POST /2fa/challenge nom d’utilisateur + mot de passe → jeton de vérification + méthodes activées (20 requêtes / 5 min par adresse IP).
• POST /2fa/verify jeton + méthode + code → définit le cookie d'authentification (30 requêtes / 5 min par adresse IP).
• GET /2fa/methods Inspecte les méthodes actives pour l'utilisateur actuel.

Déclencheurs adaptatifs de renforcement de la sécurité (version Professional)

L'application de la 2FA pour un rôle nécessite la saisie du deuxième facteur à chaque connexion. Les déclencheurs adaptatifs, ajoutés dans la version 2.1.51, constituent un juste milieu pour tous les autres utilisateurs : les utilisateurs ayant configuré une méthode ne sont invités à la saisir à nouveau que si un élément de la connexion a changé. La matrice se trouve sous Protection → Authentification à deux facteurs → Application, avec une colonne par déclencheur et une ligne par rôle.

• Nouveau pays, nouvelle adresse IP, nouveau réseau (/24 ou IPv6 /64) ou nouvel appareil, chacun étant comparé à l’historique de l’utilisateur concerné. La détection du pays nécessite le mode « Community Network » ; en mode « Local Shield », ce déclencheur reste inactif.
• Tous les N jours depuis la dernière vérification réussie et toutes les N connexions, N étant configurable à côté de la matrice.
• Plus de N sessions simultanées pour cet utilisateur.

Un défi déclenché ignore le cookie de Trusted Device, ce qui est justement le but recherché : l’appareil est de confiance, mais les circonstances ne le sont pas. L’Allowlist d’adresses IP pour la 2FA et le reportedip_2fa_bypass filtre continuent d’être contournés. Les utilisateurs qui n’ont aucune méthode configurée ne sont jamais bloqués ; le contournement est consigné (2fa_stepup_skipped_no_method) et on leur rappelle d’en configurer une. L’historique est propre à chaque utilisateur ; ainsi, la première connexion après l’activation d’un déclencheur ne donne jamais lieu à un défi, et le rôle d’administrateur ne peut être activé qu’une fois qu’un administrateur a réussi un défi sur le site.

Login front-end WooCommerce

Le Frontend 2FA de Hive en interface client s'intègre à votre thème de vitrine actif ; les clients qui se connectent via [woocommerce_my_account], via la page de paiement classique ou les blocs « Panier » / « Paiement » de WooCommerce, effectuent leur deuxième facteur d’authentification sur une page personnalisée selon le thème. L’état du panier et de la page de paiement est conservé après la redirection, et le cookie Trusted Device est partagé avec le flux wp-login.

• Chemin de configuration : 2FA → Login en front-end pour WooCommerce.
• Slugs configurables, slug du défi (par défaut reportedip-hive-2fa) et le slug de configuration (par défaut reportedip-hive-2fa-setup) ; tous deux modifiables, avec vérification des conflits, et les règles de réécriture sont automatiquement actualisées en cas de modification.
• Rétrogradation de formule, désactivation partielle sur les formules Free et Contributor ; les paramètres, les choix de slugs et l’état d’intégration sont conservés, aucune perte de données lors de la nouvelle mise à niveau.
• Détection des conflits : Hive affiche une notification d’administration lorsque Solid Security, le plugin WP Two-Factor ou Wordfence 2FA gère le formulaire de Login, et désactive le défi en front-end pour éviter les doubles invites.
• Disponibilité des formules : « Professional » et supérieures. Les capteurs gratuits d’échec de Login WooCommerce (woocommerce_login_failed, woocommerce_checkout_login_form_failed_login) restent disponibles sur toutes les formules et continuent d’alimenter le compteur d’attaques Brute-Force.

Envoi d’e-mails et de SMS

La couche de messagerie fonctionne via un contrat de fournisseur modulable (ReportedIP_Hive_Mailer). Le fournisseur par défaut est WordPress wp_mail() ; les intégrateurs peuvent le remplacer par leur propre fournisseur sans modifier le reste du plugin. À partir de la formule Professional, les e-mails transactionnels (codes 2FA, notifications de sécurité) peuvent être acheminés via le Mail Relay géré par ReportedIP : une infrastructure d'expédition conforme aux normes SPF, DKIM et DMARC, afin que les e-mails contenant des codes OTP ne finissent pas dans les spams, contrairement à ce qui arrive souvent avec un wp_mail() provenant d’un hébergement mutualisé.

• L'authentification à deux facteurs par SMS est une fonctionnalité de la formule « Professional » fournie exclusivement via le relais géré de ReportedIP.com ; aucun compte SMS, identifiants Twilio ou contrat avec un opérateur n’est requis. Elle est configurée automatiquement avec une formule payante ; activez-la dans Protection → Authentification à deux facteurs → SMS. Le délai de réenvoi par destinataire augmente progressivement (0 s → 30 s → 1 m → 2 m → 5 m → 15 m), ce qui permet de redemander un SMS lent ou non reçu sans pénalité, tandis qu’une véritable rafale de messages reste limitée.
• Forfaits mensuels et packs prépayés. La formule PRO comprend 25 SMS / 500 e-mails par mois, la formule Business 75 / 2 500 (par licence). Les forfaits prépayés viennent compléter ces quotas ; consultez le tableau des formules ci-dessus pour connaître les tarifs et le paragraphe sur l’ordre de consommation des forfaits pour savoir exactement ce qui se passe lorsqu’un quota est épuisé (spoiler : les e-mails reviennent à la solution locale wp_mail(), aucune méthode d’authentification à deux facteurs (2FA) n’est jamais désactivée).
• Modèles d’e-mails personnalisés (à partir de la formule Business). La formule Business permet d’utiliser des e-mails transactionnels White-label : votre logo, vos couleurs et votre identité d’expéditeur apparaissent sur les e-mails de 2FA et de notification à la place de la marque ReportedIP, en cohérence avec le démarrage rapide et les pages de 2FA White-label.

Aperçu de la configuration

Tous les paramètres tiennent sur une seule page, ReportedIP Hive → Protection : quatorze cartes, une par domaine, chacune avec un état résumé, un champ de recherche qui ouvre la carte correspondante et deux niveaux de détail. La vue simple montre les seize réglages du quotidien ; le commutateur expert dans l’en-tête de page affiche tous les champs. Ce qui n’est pas un réglage (le drop-in de protection étendue, les extraits serveur, la synchronisation des règles, les exceptions, l’import/export, l’e-mail de test) se trouve sous Outils, listé dans le menu en mode expert et toujours accessible par URL. Chaque option figure dans un registre canonique unique, est accompagnée d’une description en une phrase et est nettoyée en un seul endroit ; ainsi, la page Protection, le formulaire MainWP et le parc cloud affichent le même champ avec le même texte, et le démarrage rapide écrit via le même registre. Chaque option du registre peut être gérée à distance. Seules quelques-unes restent locales par conception : l’identité de connexion (mode de fonctionnement, clé API, point de terminaison), l’activation de la gestion à distance elle-même, le commutateur de suppression des données à la désinstallation, le commutateur principal du Hardening Mode (son état « sans valeur stockée » active automatiquement le renforcement à partir de la version Professional) et le commutateur de protection étendue, qui nécessite une directive serveur à ses côtés.

Les valeurs par défaut les plus importantes :

Tables de la base de données

Neuf tables, créées lors de l’activation et préfixées wp_reportedip_hive_. Version 17 du schéma, avec migration idempotente étape par étape à chaque mise à jour du plugin ; suppression sur demande lors de la désinstallation. La migration v16, fournie avec la version 2.1.50, supprime les seuils de blocage liés à la réputation qui étaient stockés en dessous du seuil minimal de 25 %, de sorte que l’écran des paramètres affiche ce qui est réellement appliqué. En Multisite, toutes les tables se trouvent sous $wpdb->base_prefix , de sorte que les décisions relatives aux menaces s’appliquent à l’ensemble du réseau. La migration v17, livrée avec la 2.1.62, ajoute les colonnes d'objet de la piste d'audit.

• logs événements de sécurité, détails JSON, gravité, indicateur « signalé » ; source des analyses du Dashboard (tendances sur 7, 30 et 90 jours, répartitions par famille et par gravité, principaux attaquants).
• whitelist les adresses IP et plages CIDR de confiance ; expiration facultative.
• blocked blocages actifs (manuels / automatiques / par réputation), avec blocked_until.
• attempts des compteurs par adresse IP et par type de tentative, avec horodatage de la première et de la dernière tentative ; opération « upsert » atomique sans risque de concurrence sur une clé unique (adresse IP, type de tentative) depuis la version v15 du schéma.
• api_queue rapports en attente et ayant échoué vers l’API communautaire ; logique de nouvelle tentative.
• stats Agrégats quotidiens (Logins échoués, blocages, spam, XML-RPC, réputation) pour les synthèses de tendances et les Reports.
• trusted_devices Jeton d’authentification 2FA (hachage SHA-256), adresse IP et nom de l’appareil, date d’expiration.
• audit_log piste d'audit en ajout seul de qui a modifié quoi (Business) ; ajoutée dans le schéma v9, colonnes d'objet depuis le schéma v17.
• waf_exceptions Liste blanche WAF gérée par le backend (portée : règle / groupe / chemin, IP/CIDR en option) ; ajoutée dans le schéma v10, à l'échelle du réseau.

Shortcodes front-end et pied de page automatique

Intégrez un petit badge « Protégé par Hive » n’importe où sur le site. Tous les codes courts génèrent un seul <rip-hive-banner> composant web et récupèrent des chiffres en temps réel à partir d’un cache temporaire de 6 heures (aucun appel API par page vue).

• [reportedip_badge] petit badge (ton « protect » par défaut).
• [reportedip_stat] une seule statistique (ton « confiance » par défaut).
• [reportedip_banner] une grande bannière (ton « communauté » par défaut).
• [reportedip_shield] icône en forme de bouclier (ton « Contributor » par défaut).

Attributs communs : stat (par ex. attacks_30d, reports_total), tone (protect / trust / community / contributor), color, background, label, intro. Le pied de page automatique activé par le démarrage rapide utilise le même composant, avec une variante et un alignement configurables.

Référence WP-CLI

Les outils d’authentification à deux facteurs (2FA), le Hardening Mode et (depuis la version 2.1.41) la recherche d’adresses IP de la communauté sont entièrement scriptables :

wp reportedip 2fa status [--user=<id>]
wp reportedip 2fa enable <user_id> --method=<totp|email|sms|webauthn> [--secret=<base32>]
wp reportedip 2fa disable <user_id> [--method=<m>]
wp reportedip 2fa reset <user_id>
wp reportedip 2fa enforce --role=<role> [--remove]
wp reportedip 2fa audit [--user=<id>] [--since=<date>]
wp reportedip 2fa cleanup
wp reportedip hardening <status|activate|deactivate>
wp reportedip lookup <ip> [--format=<table|json|csv|yaml>]
wp reportedip status [--format=<table|json|csv|yaml>]
wp reportedip user block <user> [--message=<text>] [--note=<text>]
wp reportedip user unblock <user>
wp reportedip user list [--format=<table|json|csv|yaml>]

wp reportedip status indique le mode de fonctionnement, le forfait et, depuis la version 2.1.51, un issues champ répertoriant les problèmes de préparation en cours sous la forme key (severity), ce qui permet de l’utiliser comme sonde de surveillance. Les user commandes nécessitent une formule Business pour le blocage ; le déblocage fonctionne toujours.

Compatibilité avec les plugins de cache

Depuis la version 1.5.2, la réponse de page bloquée définit DONOTCACHEPAGE, DONOTCACHEDB et DONOTCACHEOBJECT (respecté par WP Rocket, W3 Total Cache, WP Super Cache et LiteSpeed Cache) et émet des Cache-Control: no-store, no-cache, must-revalidate, max-age=0, Pragma: no-cache ainsi que le WordPress nocache_headers() . Un seul attaquant bloqué ne peut plus polluer le cache de la page avec un code 403 que les visiteurs légitimes recevraient autrement jusqu’à l’expiration du cache.

Filtres et crochets d’action

• apply_filters('reportedip_hive_external_url', $url, $context) remplacent n’importe quelle URL externe (politique de confidentialité, inscription, FAQ, etc.).
• apply_filters('reportedip_hive_rest_bypass_routes', $routes) étendent la liste des préfixes de routes REST qui contournent le moniteur de rafales (intégrations de bannières de cookies).
• apply_filters('reportedip_hive_scan_paths', $paths) étendent la liste des chemins d’accès aux Honeypots pour le détecteur de scan.
• apply_filters('reportedip_hive_decoy_paths', $paths) étendre la liste des chemins-appâts.
• apply_filters('reportedip_hive_waf_bypass_routes', $routes) excluez des routes REST du WAF au niveau du code (correspondance de préfixe ancré par rapport à la route résolue ; vide par défaut). Privilégiez les exceptions WAF gérées par le backend pour les False Positives ponctuels.
• apply_filters('reportedip_hive_mail_provider', $provider) Remplacer par votre propre fournisseur de messagerie (implémenter interface-mail-provider.php).
• apply_filters('reportedip_hive_blocked_page_strings', $strings, $context) remplacer les textes destinés aux visiteurs sur la page de blocage 403 (White-label ; clés doc_title, title, message, reason). Depuis la version 2.1.41.
• apply_filters('reportedip_hive_reputation_block_hours', 24) / apply_filters('reportedip_hive_tor_block_hours', 24) durée des blocages liés à la réputation temporaire et aux nœuds de sortie Tor.
• do_action('reportedip_hive_threshold_exceeded', $ip, $event_type, $details) déclenché à chaque détection confirmée par un capteur, quels que soient les paramètres de blocage automatique et de rapport. Depuis la version 2.1.41.
• do_action('reportedip_hive_ip_blocked', $ip, $reason, $blocked_until) déclenché lorsqu'une adresse IP est bloquée ; $blocked_until est une date-heure UTC ou null pour les blocages permanents.
• do_action('reportedip_hive_ip_unblocked', $ip) déclenché lorsqu’un blocage est levé.
• do_action('reportedip_hive_report_queued', $ip, $category_ids, $report_type) déclenché une fois par rapport entrant dans la file d’attente de l’API (identifiants de catégorie séparés par des virgules ; negative ou positive).
• do_action('reportedip_hive_access_denied', $ip, $context) déclenché juste avant l'affichage de la page de blocage 403. Depuis la version 2.1.41.
• do_action('reportedip_hive_2fa_verified', $user_id, $method) déclenchée après la réussite d’un défi à deux facteurs, aussi bien sur le formulaire de Login que sur l’Endpoint REST de vérification. Depuis la version 2.1.51, l’action principale wp_login s’y déclenche également : jusqu’alors, elle ne se déclenchait que pour les Logins n’ayant jamais fait l’objet d’un défi, ce qui empêchait le capteur d’anomalies géographiques, l’e-mail de nouvel appareil, la piste d’audit et le rappel 2FA de détecter toute connexion ayant fait l’objet d’un défi.
• apply_filters('reportedip_hive_reputation_threshold_floor', 25) Augmente le seuil minimal de 25 % sous le seuil de blocage lié à la confiance de la communauté. Il n’est pas possible de l’abaisser.
• apply_filters('reportedip_hive_2fa_bypass', false, $user) Ignorer le deuxième facteur pour un utilisateur, ce qui est également pris en charge par les déclencheurs adaptatifs de renforcement de la sécurité.

Foire aux questions

Les questions qui nous sont le plus souvent posées. Chaque réponse renvoie, le cas échéant, à la section correspondante ci-dessus.

Généralités

Installation et configuration

Modes et capteurs

2FA

Performances et compatibilité

Confidentialité et RGPD

Personnalisation et extension

add_filter('reportedip_hive_rest_bypass_routes', function ($routes) {
    $routes[] = '/my-consent-plugin/v1';
    return $routes;
});

add_filter('reportedip_hive_scan_paths', function ($paths) {
    $paths[] = '/.aws/credentials';
    return $paths;
});

Quotas, formules et compte

Dépannage

Le plugin ne bloque aucune adresse IP

Vérifiez si le Report-Only Mode est activé ; dans ce cas, les menaces sont consignées sans être bloquées. Vérifiez également que le seuil de blocage n’est pas défini à une valeur trop élevée (75 % par défaut) et que le blocage automatique est activé (la stratégie de durée est désactivée lorsque le blocage automatique est désactivé).

Le plan du site de l’utilisateur a disparu après la mise à jour

Un plugin, une application ou un flux a cessé de fonctionner après l’activation d’un commutateur de verrouillage

Ouvrez Protection → En-têtes de sécurité et désactivez à nouveau le commutateur suspect ; le changement est immédiat. Cas typiques : une application mobile ou un service de type Jetpack qui utilise encore XML-RPC, une interface frontale sans interface graphique ou un plugin d’éditeur de blocs qui appelle la REST API sans être connecté (ajoutez son espace de noms à l’Allowlist au lieu de réactiver la REST API), un service de podcast ou de newsletter lisant le flux RSS, et un prestataire de paiement effectuant une publication dans /wp-admin/. La page « Activité » répertorie chaque refus avec son chemin d’accès sous « Pare-feu », ce qui vous permet d’identifier l’appelant avant d’effectuer toute modification. Une inscription refusée de manière inattendue est consignée sous « Inscription » avec la règle qui a été appliquée.

Erreurs de connexion à l’API en mode « Community Network »

Assurez-vous que votre serveur peut effectuer des requêtes HTTPS sortantes vers reportedip.com. Certains hébergeurs bloquent les connexions sortantes par défaut. Vérifiez l’API Key sur le Dashboard.

Les visiteurs de la bannière de cookies sont bloqués

Depuis la version 1.5.0, les quatre espaces de noms de consentement courants (real-cookie-banner, complianz, borlabs-cookie, cookie-law-info) sont ignorés par défaut. Si votre pile utilise un espace de noms différent, étendez la liste des exceptions via le reportedip_hive_rest_bypass_routes filtre.

Des utilisateurs légitimes sont bloqués

Ajoutez leurs adresses IP ou leurs plages CIDR à la Whitelist locale. Les adresses IP figurant sur la Whitelist ne sont jamais bloquées, quelle que soit leur réputation.

Vous vous êtes exclu ? (votre propre adresse IP est bloquée, wp-admin est inaccessible)

Si votre propre adresse IP figure dans la liste de blocage et que wp-admin est inaccessible, vous pouvez rétablir l’accès directement dans la base de données, via phpMyAdmin ou la console de base de données de votre hébergeur. Privilégiez l’interface d’administration (le formulaire de Whitelist dispose d’une option « Ajouter mon IP » depuis la version 2.1.41) dès qu’elle est accessible ; l’accès direct à la base de données est une solution d’urgence, et non un outil au quotidien, car il contourne la validation du plugin.

Ajoutez votre adresse IP publique actuelle à la table de la Whitelist ; les adresses figurant sur la Whitelist prévalent sur tout blocage :

INSERT INTO wp_reportedip_hive_whitelist (ip_address, ip_type, reason, added_by, is_active)
VALUES ('203.0.113.42', 'ipv4', 'Self-rescue: restore admin access', 1, 1);

Utilisez 'ipv6' ou 'cidr' comme ip_type pour une adresse IPv6 ou une plage ; pour les préfixes IPv6 résidentiels tournants, ajoutez votre réseau /64 à la liste Whitelist en utilisant 'cidr'. added_by correspond à votre identifiant d’utilisateur WordPress (1 pour le premier compte administrateur). Vous pouvez également supprimer votre ligne du tableau des blocages :

DELETE FROM wp_reportedip_hive_blocked WHERE ip_address = '203.0.113.42';

Remplacez le wp_ préfixe par votre préfixe de table réel à partir de wp-config.php s'il diffère (sur un site Multisite, les tables du plugin utilisent le préfixe de base). La modification prendra effet dès la prochaine requête. Si Extended Protection (le garde pré-WordPress) est actif et que le blocage persiste, supprimez également le fichier de liste de blocage mis en cache wp-content/uploads/reportedip-hive/blocked-*.list : le garde fonctionne en mode « fail-open » et le fichier est reconstruit automatiquement lors de la prochaine synchronisation.

Le pare-feu bloque une requête légitime (False Positive du WAF)

Ouvrez Activité, repérez le blocage dans le journal (le X-RIP-Ref code de référence de la page bloquée correspond à une ligne du journal) et cliquez sur Autoriser ; cela crée une exception ciblée pour cette règle précise sur ce chemin d’accès. Consultez la section WAF Exceptions pour obtenir des conseils sur la portée des exceptions. Les exceptions s’appliquent également au pare-feu « Extended Protection » pré-WordPress.

Extended Protection est activée mais indique « ne fonctionne pas »

C’est courant sur les hébergements nginx où la directive .user.ini n’est pas prise en compte (par exemple, user_ini.filename désactivée, ou si la racine du document n’est pas le chemin d’analyse). L’onglet Outils → Serveur affiche les options manuelles : la ligne PHP-FPM-pool / php.ini auto_prepend_file ou le snippet nginx fastcgi_param . Le statut est vérifiable : il indique si la protection s’est effectivement déclenchée pour la requête en cours. Le moteur intégré à WordPress protège le site de toute façon ; le module « drop-in » ne fait qu’avancer ces mêmes vérifications.

Utilisation élevée de l’API / épuisement des contrôles

Les réponses sont mises en cache localement (avec ETag) pendant 24 heures par défaut. Si vous arrivez toujours à court de vérifications, augmentez cache_duration ou passez à un forfait supérieur. Surveillez la file d’attente et le quota depuis le Dashboard.

Blocage dû à l’authentification à deux facteurs (2FA)

Utilisez l’un des Recovery Codes enregistrés lors de la configuration de la 2FA. Si vous les avez perdus, un administrateur peut réinitialiser la 2FA pour n’importe quel utilisateur sous Utilisateurs → 2FA. En dernier recours : wp reportedip 2fa reset <user_id>.

Depuis la version 2.1.22, un utilisateur soumis à la 2FA qui n’a jamais configuré cette fonctionnalité n’est plus bloqué par défaut : une fois la période de grâce et les tentatives autorisées épuisées, il est connecté et directement redirigé vers l’inscription forcée (sans option de report). Les administrateurs et les super-administrateurs Multisite ne peuvent jamais être définitivement bloqués, même si vous rétablissez la politique « Bloquer la connexion ».

L’éditeur de blocs (Gutenberg) continue d’être bridé

L'éditeur de blocs déclenche plus de 50 appels REST en quelques secondes. Depuis la version 1.2.2, les utilisateurs connectés ne sont plus soumis au contrôleur global de rafales REST ; seules les rafales des utilisateurs anonymes sont prises en compte. Assurez-vous d'utiliser la version 1.2.2 ou une version plus récente.

RGPD et confidentialité

Le plugin a été conçu dans le respect de la vie privée et est entièrement GDPR Compliant.

• Mode « Local Shield » : aucune donnée ne quitte votre serveur. Toutes les détections et tous les blocages s’effectuent localement.
• Mode « Community Network » : l’adresse IP de l’attaquant, la Threat Category et l’horodatage sont partagés, et chaque requête identifie l’installation elle-même (adresse du site, version du plugin/de WordPress, utilisée pour le comptage des domaines de licence et l’assistance). Aucun nom d’utilisateur, aucun mot de passe, aucun contenu de commentaire, aucune donnée relative à l’utilisateur final.
• Les user-agents sont tronqués à 50 caractères avant d'être stockés.
• Nettoyage automatique : les journaux de sécurité sont supprimés après la période de conservation configurée (30 jours par défaut). L’anonymisation automatique intervient plus tôt (7 jours par défaut).
• Chiffrement au repos : les secrets TOTP, les identifiants WebAuthn et les numéros de téléphone SMS sont chiffrés avec libsodium (recul sur OpenSSL).
• Pas de suivi des visiteurs : pas de cookies, pas de pixels de suivi. La seule télémétrie concerne l’identité de l’installation (adresse du site, version du plugin/de WordPress) envoyée avec les requêtes API en mode « Community », ainsi que les données relatives à votre installation, jamais à vos visiteurs.
• Intégration aux outils de confidentialité de WordPress : Hive enregistre un exportateur et un effaceur de données personnelles dans le cœur de WordPress ; ainsi, les requêtes de « Outils → Exporter / Effacer les données personnelles » incluent automatiquement les enregistrements de Hive correspondant au sujet demandé (lignes de journal, Trusted Devices, entrées de piste d’audit). Il propose également un paragraphe à inclure dans le guide de la politique de confidentialité de WordPress (Protection → Confidentialité et journaux → Guide de la politique) que vous pouvez copier dans votre propre politique.
• Open source : le code source complet est publié sur GitHub, chaque ligne est vérifiable.

Points forts du Changelog

• 2.1.62 : la piste d'audit enregistre qui a modifié quoi : huit groupes de déclencheurs (comptes, pages et articles, extensions et thèmes, réglages avec ancienne et nouvelle valeur, menus et widgets, éditeur de fichiers, réseau) avec l'utilisateur à l'origine, la voie de la requête et l'objet concerné, un interrupteur par groupe, 90 jours de conservation par défaut avec un nettoyage par blocs, un filtre par site pour les réseaux et une page Piste d'audit pour chaque administrateur de site. Chaque type d'événement vit dans un registre unique ; le filtre du journal des événements est consultable et sélectionne des groupes entiers, et le spam de formulaire est de retour dans les graphiques.
• 2.1.58–2.1.61 : la preuve d'exécution des formulaires peut exiger un calcul (Professional), un remplacement de captcha que vos propres formulaires utilisent via une petite API ; Contact Form 7 et Ultimate Member sont couverts sur Professional, Formidable Forms et Elementor Forms sur Business ; le filtre anti-spam des commentaires lit huit signaux de plus ; les réglages de formulaires ont leur propre carte et chaque réglage indique le plan auquel il appartient.
• 2.1.57 : la page Activité s’ouvre sur le journal des événements derrière une barre de filtres que l’on peut mettre en favori, la page Communauté se divise en Réglages, Communauté et Badges (badge de pied de page en un clic et générateur de bannières), le tableau de bord porte une seule ligne d’état et des domaines de protection repliés, et les signalements sur la file de rapports se taisent tant que rien ne peut l’envoyer. Une clé refusée ne compte plus comme échec dans la fenêtre de santé de l’API.
• 2.1.56 : les pages Réglages et Pare-feu ont été remplacées par une page Protection (une carte par domaine du registre, recherche, profondeur simple et experte, un service d’enregistrement partagé avec MainWP, la flotte et l’import) et par une page Outils pour le drop-in, la synchronisation des règles, les exceptions du WAF, l’import, l’export, la réinitialisation et le courriel de test. Le tableau de bord a reçu une bannière d’état, des cartes d’étape suivante issues de six détecteurs indicatifs et une ligne par domaine de protection. Les anciennes adresses redirigent.
• 2.1.54–2.1.55 : l’assistant d’installation est devenu un démarrage rapide d’une page qui lit la formule depuis la vérification de la clé et active une recommandation adaptée via le registre de configuration ; un passage ultérieur à une formule supérieure active ce que celle-ci recommande pour les valeurs non modifiées. Chaque réglage enregistré suit désormais une seule norme, et le tableau de bord affiche les dernières actualités de reportedip.com dans la langue de l’administrateur.
• 2.1.52–2.1.53 : défense des commentaires et des formulaires. Un filtre anti-spam noté sur une vingtaine de signaux (un commentaire en attente de modération n’est plus un verdict de spam), une preuve d’exécution résistante au cache sur les formulaires de commentaire, d’inscription et de réinitialisation, et la vérification de réputation communautaire étendue de la page de connexion à ces trois mêmes formulaires. Gratuit dans toutes les formules.
• 2.1.51 : Cinq nouvelles protections. Protection lors de l’inscription (noms d’utilisateur interdits, règles relatives aux e-mails, Rate Limit pour le nombre d’inscriptions par adresse IP, blocage des connexions pour les noms d’utilisateur inexistants), commutateurs de verrouillage d’accès pour REST, XML-RPC, les flux, wp-admin, PHP dans les téléchargements et les empreintes de version, ainsi qu’un registre de préparation du système comprenant douze détecteurs, le tout gratuit sur toutes les formules. Blocage d’un compte et gestionnaire de sessions sous Utilisateurs → Sessions sur la formule Business ; déclencheurs adaptatifs de renforcement à deux facteurs par rôle sur la formule Professional. Soixante-dix options ont été transférées dans le registre des paramètres (169 au total, toutes décrites, dont 71 gérables à distance) ; l’importation des paramètres ne peut plus contourner le filtre de nettoyage, et Hardening Mode limite désormais également les seuils sur les interfaces de Login WooCommerce et par mot de passe d’application.
• 2.1.48–2.1.50 : Gestion de flotte cloud (Business) via trois routes REST signées Ed25519 avec une fenêtre de validité, des identifiants de requête à usage unique et une liaison à l’audience ; activation optionnelle et désactivée par défaut. Un seuil plancher de 25 % sous le seuil de blocage basé sur la confiance de la communauté, la migration v16 supprimant les valeurs de seuil plancher stockées, et une gestion complète des adresses IP sur WP-CLI (whitelist, block, unblock, blocked list, attempts reset) parallèlement à wp reportedip status.
• 2.1.42–2.1.47 : l’audit de sécurité et de conformité : admin-ajax.php réalisé à l’intérieur de la barrière de blocage et du pare-feu, des codes TOTP à usage unique, une exception WAF qui ne masque plus les règles qu’elle recouvre, des sondes encodées en pourcentage détectées par trois capteurs supplémentaires, et quarante-deux gestionnaires AJAX sur un seul garde d’autorisation partagé. Sans oublier une identité d’installation de type wp.org sur chaque requête API, une fiche des domaines sous licence sur le Dashboard, le registre des paramètres canoniques avec son protocole distant versionné, et les mises à jour de plugins à nouveau visibles pour MainWP et ManageWP.
• 2.1.37–2.1.41 : Blocage optionnel des nœuds de sortie Tor (Professional, ensemble de règles signé tor_exits ), des plages de sources de proxys de confiance contre le Spoofing d’en-têtes transférées, un widget de sécurité sur le Dashboard wp-admin, un veto « ne jamais bloquer » pour les infrastructures vérifiées par la communauté, une recherche d’adresse IP plus complète avec wp reportedip lookup, des hooks d’intégration stables (reportedip_hive_threshold_exceeded), des compteurs de tentatives à l’abri des conflits d’accès (schéma v15), ainsi qu’un pare-feu plus strict : les exemptions pour les robots d’indexation nécessitent un signal vérifiable, les groupes de règles de Payload bloquent dès la première occurrence, les versions de publication intègrent à nouveau les ensembles de règles groupés, et quatre règles comblent la faille CVE-2026-64638 (XSS2Shell). Le domaine a été transféré vers ReportedIP.com.
• 2.1.33–2.1.36 : Prise en charge officielle de YubiKey / des clés de sécurité matérielles : procédures WebAuthn complètes sur les trois surfaces de vérification, gestionnaire multi-clés avec détection de modèle basée sur l’attestation (Business), détection des clés clonées via une régression du compteur de signatures avec des alertes par e-mail sur tous les forfaits, Ed25519 lorsque libsodium est disponible, et une section 2FA du profil réécrite en langage clair avec une méthode par défaut sélectionnable par l’utilisateur.
• 2.1.26–2.1.32 : Contrôle croisé des robots d’indexation vérifiés (un agent utilisateur Googlebot usurpé n’achète rien), un mécanisme central de protection « ne jamais bloquer un robot vérifié », des blocages basés sur la réputation de la communauté couvrant toutes les surfaces, prévention de l’auto-blocage pour les adresses du serveur lui-même, Block Escalation pondérée en fonction du volume, et amélioration des performances : 36 → 11 requêtes par demande, lecture d’un en-tête de Blocklist de 8 Ko et TTFB du Dashboard passant de 920 à 278 ms (schéma v13).
• 2.1.25 : Le WAF bloque la classe d’attaques par confusion de routes REST du cœur de WordPress sur tous les forfaits (règles structurelles, pas de correspondance de jetons), inspecte une copie décodée du corps de la requête (ce qui empêche le contournement par Payload encodé), et les blocages de Paranoia-Level 2/3 affichent leur catégorie de référence spécifique.
• 2.1.22–2.1.24 : L’authentification à deux facteurs (2FA) imposée par défaut entraîne désormais une inscription obligatoire au lieu d’un verrouillage (les administrateurs et super-administrateurs ne peuvent jamais être définitivement bloqués) ; l’envoi en double du défi 2FA ne bloque plus les utilisateurs sur le message « session expirée » ; la sonde RCE PHPUnit eval-stdin.php (CVE-2017-9841) est bloquée sur toutes les formules.
• 2.1.14–2.1.20 : Exactitude de l’hébergement de production : dates et heures cohérentes avec l’UTC (le blocage automatique échouait silencieusement sur les serveurs de bases de données non UTC), Hide Login fonctionne derrière les caches de page et sur les sites utilisant la barre oblique finale ou Nginx, la Extended Protection se configure automatiquement sur nginx + PHP-FPM et ignore l’inspection du corps de la requête pour les éditeurs connectés, la santé de l’API utilise une fenêtre glissante, et l’interrogation du quota de relais sur les chemins fréquents a été supprimée.
• 2.1.9–2.1.13 : WAF Exceptions gérées par le backend avec une action « Autoriser » en un clic (schéma v10), journalisation des blocages intuitive (valeur correspondante, cible, méthode, URI, agent utilisateur), le provisionnement MainWP permet de basculer les sites en mode « Communauté », et le Dashboard de sécurité est devenu une vue analytique complète (sept familles de menaces, graphique des groupes de règles WAF, principaux attaquants).
• 2.1.0–2.1.8 : Lancement du pare-feu : un cadre de diffusion des règles (Rule Delivery Framework) fourni par le serveur et signé avec Ed25519, alimentant un Web Application Firewall inspectant les requêtes (moteur gratuit + configuration de base « Paranoia-Level-1 », niveaux PRO 2/3 via Priority Sync), Verified Bot Detection, Disposable-Email Blocking, Comment Honeypot, Security Headers (de base gratuits, avancés en version PRO), Protection & Hardening Score sur le Dashboard, codes de référence pour les pages de blocage (X-RIP-Ref), l’Audit Event Trail d’entreprise (schéma v9), l’intégration MainWP et un espace d’administration du pare-feu, suivis de corrections de False Positives pour les robots d’indexation légitimes et de la suppression sans risque des éléments « drop-in ».
• 2.0.x : activation multisite à l’échelle du réseau (Network: true), gestion des niveaux par blog, bannières de mise à niveau, renforcement des moniteurs de mots de passe d’application et d’anomalies géographiques, ouverture du Frontend 2FA en interface utilisateur WooCommerce pour la version PRO+, Hardening Mode contre les attaques coordonnées, détection et signalement des chemins leurres.
• 1.5.2 : Compatibilité avec les plugins de cache sur la page 403 ; la limitation de l’authentification à deux facteurs (2FA) évolue vers un véritable blocage par escalade ; init priorité 1.
• 1.5.1 : Clarté de l’onglet de blocage (Signaler uniquement > Blocage automatique > stratégie de durée) ; permutation en ligne des éditeurs à longueur fixe et à échelle.
• 1.5.0 : Progressive Block Escalation (échelle de 5 m → 7 j) ; les Endpoints de la bannière de cookies sont contournés par défaut ; assouplissement des paramètres par défaut pour les pages 404 et le spam dans les commentaires.
• 1.2.4 : le bouton « Réessayer » de la file d’attente API déclenche désormais réellement l’appel API.
• 1.2.0 : Sept nouveaux capteurs : surveillance des mots de passe d'application, surveillance des pics REST, blocage de l'User Enumeration, détecteur de 404/scans, anomalie géographique, force des mots de passe, masquage de l'URL de connexion.
• 1.1.0 : Système d’envoi d’e-mails centralisé avec modèle personnalisé.
• 1.0.0 : Première version publique : blocage d'adresses IP, 2FA à 4 méthodes, Setup Wizard, tableaux de listes.

Historique complet : Changelog.md sur GitHub.

Vous recherchez la version allégée ?

Dernière mise à jour: 20. septembre 2026 · Maintenu par l’équipe ReportedIP