ReportedIP Hive 2.1.21 — Renforcement du pare-feu WordPress
La version 2.1.21 de ReportedIP Hive vient clore une série de 17 mises à jour axées sur le renforcement de la sécurité. Depuis l’intégration du pare-feu dans les versions 2.1.2 à 2.1.4, chaque version, de la 2.1.5 à la 2.1.21, a contribué à rendre cette nouvelle couche WAF apte à une utilisation en production : la protection pré-WordPress couvre désormais automatiquement nginx, les False Positives ont été supprimés de l’interface d’administration et un véritable bug de blocage automatique sur les bases de données non UTC a été corrigé.
L’ensemble du noyau de détection reste libre et sous licence GPL-2.0. Effectuez la mise à jour via « Plugins → Vérifier les mises à jour », ou téléchargez le dernier fichier ZIP depuis la page des versions sur GitHub Releases. Si vous n’avez pas encore installé le pare-feu lui-même, commencez par consulter la documentation relative à la version 2.1.4 du pare-feu.
Quelles sont les nouveautés depuis la version 2.1.4 de Hive ?
Dix-sept versions ont été publiées entre la 2.1.5 (11 juin 2026) et la 2.1.21 (3 juillet 2026). Aucune n’a ajouté de nouveau pilier : cette série de versions visait à renforcer le WAF, à étendre Extended Protection et à optimiser le blocage automatique introduits dans les versions 2.1.2 à 2.1.4.
| Version | Modification du titre |
|---|---|
| 2.1.5 | Problème critique ArithmeticError dans le module de correspondance CIDR : les robots d’indexation légitimes ne sont plus bloqués comme s’il s’agissait d’une User Enumeration ; les adresses IP de bouclage et privées ne sont jamais signalées comme provenant d’attaquants. |
| 2.1.6 | Le classificateur de bots vérifiés a été configuré en mode « trois états » ; ainsi, les adresses IP réelles de Bing ou de robots d’indexation situées en dehors de la plage de référence ne sont plus classées à tort comme « faux bots ». |
| 2.1.7 | Harmonisation des badges de niveau dans l’interface d’administration ; regroupement des filtres par type d’événement dans les journaux ; correction de l’exportation des journaux au format JSON/CSV. |
| 2.1.8 | La désactivation de l’Extended Protection ne provoque plus la mise hors ligne du site : le système de protection est neutralisé et transformé en un élément de remplacement inerte, à la manière de Wordfence. |
| 2.1.9–2.1.11 | WAF Exceptions gérées par le backend : suppression d’un False Positive depuis l’interface d’administration, sans intervention sur le code ; formulaire d’exception intuitif et FAQ. |
| 2.1.12 | La fonctionnalité de provisionnement de MainWP permet de basculer un site géré en mode « Community Network ». |
| 2.1.13 | Le Dashboard de sécurité a été repensé pour offrir une vue analytique complète ; le Hardening Mode ne se déclenche plus lors des attaques de Brute Force de routine en arrière-plan. |
| 2.1.14–2.1.15 | Le blocage automatique est désormais compatible avec l’UTC sur les serveurs de base de données non UTC ; les horodatages d’administration s’affichent dans le fuseau horaire du site. |
| 2.1.16 | On a bloqué un /relay-quota qui risquait de se déclencher à chaque requête frontale. |
| 2.1.17 | Extended Protection couvre automatiquement tous les Endpoints PHP sur nginx ; le garde ne procède pas à l’inspection du corps de la requête pour les éditeurs connectés. |
| 2.1.18 | Le message « Dégradation de l’état de l’API » se résout de lui-même (fenêtre glissante) ; le journal de sécurité ne peut plus être saturé par une boucle de défaillance. |
| 2.1.19 | Problème de Hide Login résolu derrière les permaliens avec barre oblique finale et les caches de page (WP Rocket et autres). |
| 2 janvier 2020 – 2 janvier 2021 | Les instructions de configuration du serveur nginx s’affichent désormais lorsque la configuration automatique est désactivée ; le Setup Wizard et la copie de l’authentification à deux facteurs (2FA) ont été améliorés. |
« Extended Protection » a évolué : le WAF, qui existait avant WordPress, prend désormais automatiquement en charge nginx
Extended Protection fait passer le pare-feu par un auto_prepend_file filtre avant le chargement de WordPress. Sur nginx, cela impliquait auparavant de coller un location — qui ne protège que le bloc dans lequel il se trouve ; ainsi, les requêtes traitées par leurs propres blocs (wp-login.php, le contrôleur frontal mis en cache) passaient à travers les mailles du pare-feu.
La version 2.1.17 détecte le SAPI PHP-FPM avant la chaîne du serveur nginx et définit un répertoire racine du document .user.ini à la place. PHP-FPM respecte auto_prepend_file ce chemin pour chaque requête, quel que soit le bloc nginx location , sans aucune intervention manuelle. L’extrait de code nginx / php.ini ne sert plus que de solution de secours pour les piles ne disposant pas d’une SAPI PHP FastCGI, et la version 2.1.20 affiche ces instructions manuelles chaque fois que la directive générée automatiquement n’est pas encore effective.
La protection n’empêche plus les contributeurs connectés d’éditer, ni ne se déclenche lorsqu’ils se déconnectent.
Comme le module de sécurité s’exécute avant WordPress, il inspectait auparavant le corps de chaque requête ; ainsi, un auteur connecté qui enregistrait un article via admin-ajax.php ou via la REST API pouvait déclencher une signature XSS/SQLi et obtenir une erreur 403. La version 2.1.17 détecte le wordpress_logged_in cookie et ne vérifie plus le corps des requêtes authentifiées (les règles relatives à l’URL et à l’agent utilisateur continuent toutefois de s’appliquer), le moteur intégré à WordPress restant le dernier rempart tenant compte des capacités du système. La désactivation du WAF, ou son passage en mode « rapport uniquement », désactive désormais également le garde pré-WordPress.
La désinstallation est désormais sans risque elle aussi. Avant la version 2.1.8, la désactivation du plugin alors que la auto_prepend_file directive se trouvait dans un fichier que Hive ne peut pas modifier (un fichier nginx fastcgi_param ou un fichier php.ini modifié manuellement), ce qui faisait que PHP continuait de pointer vers une protection supprimée et provoquait un plantage à chaque requête avec un code d’erreur 500. La suppression supprime désormais les directives contrôlées par Hive et laisse un espace réservé inerte, de sorte qu’une directive restante ne puisse jamais faire référence à un fichier manquant.
Les False Positives du WAF sont désormais supprimés depuis l’interface d’administration, sans intervention sur le code
Un pare-feu basé sur les signatures peut parfois signaler une requête légitime provenant du site lui-même — un plugin de sécurité qui analyse des Payloads ressemblant à des attaques en est un exemple classique. Les versions 2.1.9 à 2.1.11 ont introduit un système d’exceptions géré en arrière-plan qui fonctionne de la même manière que les exclusions de ModSecurity et l’Allowlist de Wordfence.
- Chaque ligne du journal du WAF comporte une action « Allow » qui crée une exception ciblée pour cette règle précise sur ce chemin d’accès.
- Une exception s’applique à une seule règle, à un groupe de règles ou — pour un endpoint de première partie — à l’ensemble du moteur sur un chemin, éventuellement restreint à une adresse IP ou à un CIDR. Une exception portant sur l’ensemble du moteur doit toujours comporter un chemin ou une adresse IP, afin que le pare-feu ne puisse jamais être désactivé par inadvertance à l’échelle globale.
- Les données à l’échelle du réseau (option
reportedip_hive_waf_exceptions,db_version10) et sont disponibles sur tous les forfaits — le moteur de protection lui-même reste gratuit.
La version 2.1.10 a corrigé un bug de « hoisting » : le filtre de sécurité pré-WordPress générait une erreur fatale sur tout corps de requête POST — l’inspection du corps de requête à ce niveau s’avérait en réalité une opération sans effet et silencieuse — et a fait en sorte que le module de remplacement respecte les mêmes exceptions que le moteur WordPress. La version 2.1.11 a scindé le champ ambigu « ID de règle ou groupe » en un champ de saisie pour l’ID de règle et une liste déroulante de groupes alimentée par les catégories connues du moteur, afin que l’on sache clairement quoi saisir et d’où provient la valeur.
Le blocage automatique échouait sans avertissement sur les bases de données non UTC
La correction la plus importante de cette version est la 2.1.14. Les horodatages d’expiration et de tentatives sont enregistrés en UTC, mais étaient comparés à l’horloge de session MySQL (NOW() / CURDATE()). Sur un serveur dont le fuseau horaire de la base de données n’est pas UTC, ce décalage empêchait le compteur de tentatives par adresse IP de s’incrémenter correctement au sein de sa fenêtre de temps — de sorte que les seuils de Login ratés et de requêtes XML-RPC n’étaient jamais atteints et qu’aucun contrevenant n’était jamais bloqué — tandis que chaque blocage nouvellement enregistré était considéré comme déjà expiré, laissant la liste de blocage vide pendant une attaque en cours.
Toutes les colonnes de date-heure et toutes les comparaisons sont désormais cohérentes avec l’UTC au niveau de la couche de base de données, du détecteur d’attaques coordonnées, du balayage de récupération des files d’attente, de l’expiration des Trusted Devices et des statistiques quotidiennes. La version 2.1.15 a ensuite permis à l’administrateur d’afficher ces horodatages dans le fuseau horaire du site plutôt qu’en UTC brut, et la version 2.1.18 a aligné les statistiques de l’API sur cette même convention UTC. Si votre base de données fonctionne avec une horloge non UTC, la version 2.1.14 ou ultérieure est celle qui permet au blocage progressif de fonctionner correctement.
Moins de False Positives, moins de bruit dans les journaux, des analyses plus précises
Plusieurs mises à jour ont renforcé les critères de détection, de sorte que le trafic normal ne déclenche plus de blocages. La version 2.1.13 a empêché le Hardening Mode de se déclencher en cas d’attaques par Brute Force courantes en arrière-plan : les détecteurs de Coordinated-Attack Detection comptabilisent désormais les événements individuels failed_login événements sur une fenêtre en temps réel au lieu d’additionner le compteur cumulé de chaque adresse IP, avec des valeurs par défaut réalistes (attaque distribuée : 10 adresses IP distinctes et 50 tentatives en 10 minutes ; rafale : 8 adresses IP et 30 tentatives en une minute). Cette même version a repensé le Dashboard Sécurité pour en faire une vue analytique complète : une bande d’actualités, une chronologie empilée regroupée en sept familles de menaces avec un sélecteur 7/30/90 jours, un graphique en anneau par vecteur d’attaque, un histogramme des groupes de règles WAF, une répartition par gravité et un tableau des principaux attaquants.
En ce qui concerne les faux positifs, la version 2.1.16 a mis fin à une /relay-quota qui pouvait se déclencher sur les chemins critiques (pare-feu, Security Headers, vérification des bots) des milliers de fois par minute. La version 2.1.18 a quant à elle remplacé l’indicateur « API health degraded », qui reposait sur un compteur à durée indéterminée bloqué indéfiniment, par une fenêtre glissante portant sur les 50 derniers appels effectués au cours des 7 derniers jours — et a limité le nombre de api_call_failed à une par minute, de sorte qu’une rafale de défaillances ne puisse plus générer des dizaines de milliers d’entrées de journal. La version 2.1.19 a corrigé une faille de Login cachée pour les sites utilisant des permaliens avec une barre oblique finale et protégés par un cache de pages, où une page de Login mise en cache interrompait silencieusement l’échange de cookies.
Comment effectuer la mise à jour vers Hive 2.1.21
L’outil de vérification des mises à jour intégré interroge GitHub toutes les 12 heures ; les nouvelles versions apparaissent sur votre écran « Plugins » comme n’importe quelle autre mise à jour. Pour télécharger immédiatement la version 2.1.21, ouvrez « Plugins » → « Vérifier les mises à jour ». Il n’y a pas de migration de schéma au-delà de la table « WAF Exceptions » (db_version 10) ajoutée dans la version 2.1.9, et le Setup Wizard guide désormais les nouvelles installations vers l’Extended Protection avec des paramètres par défaut sûrs.