Versions

ReportedIP Hive 2.1.72 : blocages de groupe et page Protection en cinq onglets

9 octobre 2026 · Patrick Schlesinger

ReportedIP Hive 2.1.72 permet à plusieurs sites WordPress de partager leurs blocages d’IP au sein d’un groupe, reconstruit la page Protection en cinq onglets et empêche un site de signaler le serveur sur lequel il tourne. Elle clôt six versions publiées entre le 28 septembre et le 9 octobre 2026, avec deux règles contre l’injection SQL désormais livrées dans la base hors ligne du pare-feu et plus de vingt corrections pour les réseaux Multisite, les formulaires et la connexion masquée.

Mettez à jour depuis l’administration WordPress ou téléchargez le ZIP actuel sur la page produit de Hive. Le précédent article de version portait sur Hive 2.1.66 et la protection des formulaires ; celui-ci recense ce qui a changé depuis. L’interface du plugin est en anglais, les libellés sont donc cités en version originale.

Qu’est-ce qui a changé entre Hive 2.1.66 et 2.1.72 ?

Version	Date	Changement principal
2.1.67	28 septembre 2026	Blocages de groupe, son propre serveur n’est plus signalé, formulaire de commentaire qui refuse les bots
2.1.68	29 septembre 2026	Deux règles d’injection SQL dans la base, Priority Sync dès Contributor
2.1.69	30 septembre 2026	Page Protection en cinq onglets, user agents entre guillemets traités comme des bots
2.1.70	2 octobre 2026	Empreintes de flotte plus calmes, formulaires de l’administration réseau corrigés
2.1.71	5 octobre 2026	Un Multisite à plusieurs domaines ne bloque plus l’administrateur
2.1.72	9 octobre 2026	Adresses jetables refusées dans les commentaires et les formulaires

Comment fonctionnent les blocages de groupe dans Hive 2.1.67 ?

Une Community Access Key peut rejoindre un groupe dans votre compte reportedip.com. Chaque adresse signalée par un membre est alors bloquée chez tous les autres membres pendant la fenêtre de blocage du groupe. Hive reproduit la liste du groupe sous forme de blocages d’un type propre, group : une entrée reste bloquée jusqu’à l’expiration indiquée par le service et est levée dès qu’elle quitte la liste.

• La liste blanche l’emporte. Votre propre liste blanche prime toujours sur chaque entrée du groupe, et un blocage posé à la main n’est jamais touché.
• La liste blanche du groupe atteint chaque membre. Les adresses et plages mises en liste blanche pour le groupe arrivent dans la liste blanche de chaque site avec l’origine Group, en IPv4 comme en IPv6.
• Rien de périmé ne subsiste. Quand la clé quitte le groupe, que l’offre ne couvre plus les groupes ou que le site passe en Local Shield, tout ce que le groupe avait posé est levé.
• Visible là où vous travaillez. Le tableau de bord affiche une carte de groupe, et Activity > IP Lists contient un onglet Group avec chaque adresse listée, le membre qui l’a signalée et ce que ce site en a fait.

Les groupes sont inclus à partir de l’offre Professional. Les membres peuvent être des sites WordPress équipés de Hive et des serveurs Linux équipés de l’agent, mélangés dans un même groupe. La mise en place et les captures d’écran figurent dans le guide Partager les blocages d’IP entre sites WordPress ; les limites par offre et les webhooks sont sur la page de documentation des groupes.

Pourquoi un site ne signale-t-il plus son propre serveur ?

wp-cron, les requêtes REST vers le site lui-même et le préchargement des caches partent de l’adresse publique de l’hôte, ce qui ressemble à un visiteur extérieur. Cinq capteurs signalent directement et sautaient la vérification de cette adresse, si bien que des sites ont signalé l’IPv6 publique de leur propre serveur. Cela consommait le quota de signalements du compte et plaçait le serveur sur la liste communautaire que lisent les autres sites.

Depuis 2.1.67, cette limite se trouve aux deux endroits par lesquels passe chaque décision : la file des signalements et l’appel de blocage, à côté des vérifications des adresses privées et de la liste blanche. Un hôte retient aussi son adresse dans les deux familles, IPv4 et IPv6, dès qu’il répond pour la première fois sur chacune. Un blocage posé à la main fonctionne toujours.

À quoi ressemble la nouvelle page Protection ?

Depuis 2.1.69, la page Protection compte cinq onglets au lieu de quinze cartes : Core protection, Forms, Firewall & Bots, Advanced et Operations, chacun avec un indicateur d’état. Un interrupteur tient sur une ligne, avec une phrase claire à gauche et le bouton à droite. Un interrupteur que votre offre n’inclut pas indique l’offre nécessaire au lieu d’apparaître grisé.

• Les réglages experts de chaque zone se trouvent derrière Show technical details ; le mode expert les ouvre par défaut.
• Chaque onglet a un seul Save changes et un seul Restore defaults, qui écrit la recommandation pour votre offre.
• Un bouton Check protection à côté de la bannière d’état relance la vérification de configuration et compte les problèmes et conseils ouverts.
• 2.1.72 réunit Extended Protection dans une seule carte avec un seul badge d’état et un seul bouton.

Le registre des réglages, le schéma distant pour MainWP et la flotte cloud, ainsi que chaque lien vers la page, n’ont pas changé. La checklist de durcissement passe les interrupteurs en revue dans l’ordre.

Quelles règles de pare-feu et anti-spam sont devenues plus strictes ?

Deux règles d’injection SQL rejoignent la base hors ligne

L’injection basée sur les erreurs extrait des données du message d’erreur de la base via EXTRACTVALUE() ou UPDATEXML(), et une injection de second ordre voyage dans le corps d’un trackback pour se déclencher plus tard. Les deux règles n’arrivaient jusqu’ici que par Rule Sync. Depuis 2.1.68, elles sont livrées dans la base fournie, si bien qu’un site en mode Local Shield est lui aussi couvert, dans le moteur intégré à WordPress comme dans la garde placée avant WordPress. La classe d’attaque est décrite dans la fiche OWASP sur l’injection SQL.

Priority Sync commence avec l’offre Contributor

Contributor reçoit désormais le jeu de règles WAF de Paranoia Level 2 et les listes de plages IP des bots, mis à jour chaque semaine. Le niveau 3 et la mise à jour quotidienne restent réservés à Professional. Le moteur applique lui-même ce plafond, et un passage à une offre inférieure revient aussitôt au niveau de base.

Le formulaire de commentaire refuse un bot comme tous les autres formulaires

Un commentaire envoyé par un client qui n’avait jamais exécuté le script de la page gagnait quelques points de spam et pouvait tout de même atteindre la file de modération. Depuis 2.1.67, il est refusé d’emblée, avec la même formulation et la même ligne de journal que le formulaire d’inscription et les six plugins de formulaire. Un lien dans le texte du commentaire compte désormais comme un lien dans le champ site web : mesuré sur 349 vrais commentaires de spam, le taux de détection des bots qui passent le contrôle du script est passé de 42 à 50 pour cent.

User agents entre guillemets et adresses jetables

Aucun navigateur n’entoure son user agent de guillemets, un client headless mal configuré le fait. Depuis 2.1.69, un tel envoi est refusé, bloqué et signalé immédiatement, et la nouvelle règle de base waf_ua_quoted arrête ce même client dans les deux couches du pare-feu. Depuis 2.1.72, les commentaires et chaque formulaire protégé demandent à un expéditeur doté d’une adresse jetable une adresse permanente ; le réglage propose Block, Monitor et Off, Block étant la valeur par défaut.

Qu’est-ce qui change pour les réseaux Multisite et les flottes gérées ?

• Plusieurs domaines, un administrateur. Avec Hide Login activé, un administrateur qui suivait My Sites vers un autre domaine du réseau tombait sur la page de blocage. Depuis 2.1.71, ces liens pointent vers la connexion de ce domaine, avec la page d’administration comme redirect_to.
• Les formulaires de l’administration réseau fonctionnent. WordPress ne fournit pas de admin-post.php pour le réseau, si bien que la fermeture des notices, la synchronisation du groupe et les actions 2FA répondaient 404. Corrigé dans 2.1.70, et l’enregistrement de la page Protection y ramène dans l’administration réseau depuis 2.1.69.
• Plus de fausse dérive après une mise à jour. L’empreinte des réglages transmise à MainWP et à la flotte reportedip.com ne couvre plus que les valeurs qui diffèrent des valeurs par défaut. Une version qui ajoute un réglage ne marque donc plus chaque site comme modifié.
• Groupes de cases à cocher dans les tableaux de bord. Les rôles, les méthodes 2FA et les groupes de déclencheurs du journal d’audit s’affichent en cases à cocher dans MainWP et dans la flotte au lieu d’un champ JSON brut.

Les deux voies de gestion sont décrites dans la section MainWP et la section Multisite de la documentation de Hive.

Quels bugs les six versions ont-elles corrigés ?

• Un crawler vérifié n’est plus bloqué pour un chemin de scanner. Une adresse prouvée par la plage publiée du crawler ou par un reverse DNS confirmé par résolution directe (FCrDNS) conserve son exemption. Un user agent seul ne suffit toujours pas (2.1.72).
• Un formulaire resté ouvert longtemps est accepté. Le script de la page renouvelle sa réponse avant qu’elle n’expire, quand l’onglet redevient visible et au moment de l’envoi (2.1.72).
• Les actions groupées fonctionnent après un filtre. Supprimer ou relancer des éléments de la file, des journaux, des blocages ou des entrées de liste blanche ne faisait rien après un filtrage (2.1.72).
• La connexion masquée affiche de nouveau la vraie erreur. Une session expirée ou un cookie bloqué n’apparaît plus comme « Invalid credentials. » (2.1.67).
• Une session expirée ne bloque plus tout un bureau. Une visite de wp-admin sans être connecté est toujours refusée et journalisée, mais elle n’alimente plus l’échelle de blocage (2.1.67).
• Hide Login et son slug s’activent ensemble. Les valeurs sont désormais écrites avant les interrupteurs sur chaque canal, MainWP et la flotte compris (2.1.69).
• Les pieds de page des e-mails nomment le site par son adresse. Un texte de lien qui nomme autre chose que sa cible est un signal de phishing pour Microsoft 365 et Gmail (2.1.72).
• Les installations sont de nouveau comptées sur wordpress.org. Les mises à jour arrivent toujours uniquement par le canal de versions de ReportedIP (2.1.70).

Depuis 2.1.68, le journal d’audit suit lui aussi l’interrupteur Log user agents, désactivé par défaut, comme le journal de sécurité l’a toujours fait. La section RGPD liste ce que Hive enregistre.

Questions sur Hive 2.1.72

Quelle offre inclut les blocages de groupe dans Hive ?

Les blocages de groupe nécessitent l’offre Professional ou supérieure. Une clé sur une offre inférieure reçoit une notice, et la synchronisation continue de demander, donc une montée en gamme ne demande aucune action sur le site. Une clé sans groupe ne voit aucun changement. Dès que l’offre couvre les groupes et que la clé n’appartient à aucun groupe, le tableau de bord propose une étape suivante avec un lien vers la section Groups de votre compte.

Mes réglages de protection changent-ils avec la nouvelle page à cinq onglets ?

Vos réglages enregistrés restent exactement tels qu’ils étaient. La page à cinq onglets lit et écrit le même registre que les anciennes cartes, et MainWP comme la flotte cloud utilisent le même schéma distant. Seul Restore defaults écrit de nouvelles valeurs, et uniquement pour l’onglet où vous cliquez dessus. Un nouveau réglage arrive activé : depuis 2.1.72, les adresses e-mail jetables sont refusées dans les commentaires et les formulaires protégés, réglable dans l’onglet Forms.

Que vérifier après la mise à jour vers 2.1.72 ?

Ouvrez la page Protection et cliquez sur Check protection pour voir les points ouverts. Dans l’onglet Forms, choisissez le traitement des adresses e-mail jetables ; Block est la valeur par défaut. Si plusieurs de vos sites partagent les mêmes attaquants, créez un groupe dans votre compte et ajoutez-y leurs clés.

Pour aller plus loin

• Blocages de groupe dans Hive
• Pare-feu et livraison des règles
• Bots, e-mails jetables et spam de commentaires
• Fonctions par offre

Vous gérez aussi des serveurs Linux à côté de WordPress ? La version 0.3.48 du Linux Agent apporte les mêmes groupes au pare-feu du noyau. Versions précédentes de Hive : Hive 2.1.62 avec le journal d’audit et Hive 2.1.57 avec l’administration reconstruite.