Au cœur du Web Application Firewall ReportedIP Hive
ReportedIP Hive propose un Web Application Firewall qui analyse chaque requête avant que WordPress ne la traite. Il compare l’URL, la chaîne de requête, le corps de la requête et l’agent utilisateur à un ensemble de règles signées, bloquant ainsi les SQL Injection, les attaques XSS, les traversées de chemin, les injections de commandes et une douzaine d’autres types d’attaques — et les règles se mettent à jour automatiquement, sans qu’il soit nécessaire de publier un nouveau plugin.
Le moteur et son ensemble de règles par défaut sont gratuits dans toutes les formules. Ce guide explique comment le pare-feu inspecte le trafic, d’où proviennent les règles, comment empêcher une expression régulière mal formulée de mettre le site hors service, comment supprimer un False Positive depuis l’interface d’administration, et comment fonctionne la protection optionnelle « pré-WordPress ». Il reflète l’état de Hive à la version 2.1.21, après la campagne de renforcement de sécurité menée entre les versions 2.1.5 et 2.1.21.
Ce que le pare-feu de WordPress vérifie à chaque requête
Le WAF s’exécute sur le init hook de priorité 1, immédiatement après la vérification des blocs d’adresses IP effectuée par Hive. Une requête provenant d’une adresse IP déjà bloquée n’atteint jamais le pare-feu, ce qui évite tout travail inutile. Tout le reste est inspecté : l’URI de la requête, la chaîne de requête, le corps de la requête et l’agent utilisateur sont aplatis puis comparés au jeu de règles actif.
Le coût s’élève à environ 4 microsecondes de CPU par requête, sans aucune requête supplémentaire vers la base de données lorsqu’un cache d’objets persistant est présent. Les classes d’attaques détectées comprennent la SQL Injection, le cross-site scripting, le parcours de chemin, l’injection de commande et les wrappers LFI, ainsi que le SSRF, Log4Shell/JNDI, l’injection d’objets PHP, l’injection NoSQL, l’XXE, les téléchargements de web-shells, le CRLF et l’injection de modèles — chacune disposant de son propre code de motif de blocage.
Le contrôle est en lecture seule et tient compte des False Positives. Les administrateurs connectés en sont exemptés (les administrateurs collent légitimement du code SQL et du code dans les éditeurs), /wp-admin n’est jamais inspecté, et les adresses IP figurant sur la liste blanche sont ignorées. Une détection est bloquée via le même chemin 403, sans impact sur le cache et codé par référence, que celui utilisé par les autres capteurs, ou simplement consignée dans le journal lorsque le Report-Only Mode est activé.
Pourquoi les Firewall Rules se trouvent sur un serveur et non dans le plugin ?
La plupart des pare-feu WordPress intègrent leurs signatures de manière fixe, ce qui implique que chaque mise à jour des règles nécessite la publication d’une nouvelle version du plugin. Hive adopte une approche inverse : les signatures proviennent de la Rule API de reportedIP sous forme d’ensembles de règles versionnés, signés avec Ed25519 et échelonnés par niveaux, synchronisés toutes les six heures. Les nouvelles signatures d’attaques sont transmises à chaque installation en quelques heures.
Il existe quatre ensembles de règles — waf, bot_signatures, disposable_domains et scan_paths. Chacun est signé à l’aide d’une signature Ed25519 détachée, et le plugin la vérifie par rapport à un ensemble de clés publiques intégré (la clé actuelle et la suivante, en vue de la rotation) avant de l’appliquer. Si la vérification échoue, si le flux est trop volumineux ou si le serveur est inaccessible, Hive revient à un ensemble de règles de base intégré. Un flux altéré ou détourné ne peut pas corrompre les règles — même en cas de fuite d’une API Key ou de faille du protocole TLS.
La configuration de base est intégrée au plugin ; ainsi, le pare-feu fonctionne entièrement hors ligne en mode « Local Shield », sans compte ni communications sortantes. Le Rule Sync est facultatif : il ne s’effectue qu’en mode « Community » lorsqu’une API Key est configurée.
Accès gratuit à la version de base, fonctionnalités avancées sur la version « Professional »
La stratégie d’échelonnement des règles suit le modèle « Paranoia Level » de l’OWASP Core Rule Set, la norme de facto en matière de WAF utilisée par ModSecurity et Cloudflare.
| Paranoia Level | Personnage | Plan de la ruche Hive |
|---|---|---|
| PL1 | La configuration de base, optimisée pour réduire au minimum les False Positives, couvre le Top 10 de l’OWASP | Free (version de base incluse) |
| PL2 | Une vigilance accrue, quelques False Positives supplémentaires | Contributor (hebdomadaire) / Professional |
| PL3 | Attaques rares, techniques de dissimulation et couverture du contournement des pare-feu d’applications Web (WAF), False Positives occasionnels | Professional (Priority Sync) |
La version gratuite offre un pare-feu efficace générant peu de False Positives : c’est la promesse de protection. La version Professional ajoute les ensembles de règles PL2/PL3 plus approfondis et fréquemment mis à jour via Priority Sync, ainsi que les flux en temps réel sur les plages d’adresses IP des bots et les domaines jetables.
Comment Hive empêche une règle mal configurée de mettre votre site hors service
Comme les motifs proviennent d’un flux, une expression régulière mal formée représente un risque majeur : un retour en arrière catastrophique (ReDoS) a déjà mis Stack Overflow hors ligne pendant 34 minutes. Hive s’en prémunit à plusieurs niveaux :
- Limite inférieure de retour en arrière. Avant la boucle d’inspection, Hive définit
pcre.backtrack_limità 100 000 (contre la valeur par défaut de 1 million) et la rétablit par la suite, limitant ainsi la durée d’exécution maximale par motif. - Comportement « fail-open » en cas d’erreur d’expression régulière. Lorsqu’un motif atteint la limite,
preg_match()renvoiefalse, et non0ou1— un contournement silencieux si cette option n’est pas cochée. Hive traitefalsecomme un comportement « fail-open » accompagné d’unwaf_pattern_error. Une règle défectueuse ne bloque jamais le trafic légitime et ne verrouille jamais l’accès au site : la disponibilité prime sur la rigueur. - Limite de 8 Ko pour le corps. Les corps dont la taille dépasse 8 Ko sont ignorés, ce qui permet de limiter la base de retour en arrière.
- Linter côté serveur. Sur reportedIP.com, chaque modèle est vérifié afin de détecter tout retour en arrière catastrophique avant d’être signé — un modèle dangereux n’est jamais diffusé.
Les motifs sélectionnés privilégient également les groupes atomiques et les quantificateurs possessifs, qui ne nécessitent pas de retour en arrière, et le JIT de PCRE (activé par défaut dans WordPress) accélère la recherche de correspondances.
Supprimer un False Positive depuis l’interface d’administration, sans modifier le code
Tout pare-feu basé sur les signatures peut parfois signaler une requête légitime provenant du site lui-même — par exemple, un éditeur de pages envoyant du code HTML enrichi, ou un plugin de sécurité qui traite légitimement des Payloads ressemblant à des attaques. Depuis la version 2.1.9, Hive gère cela de la même manière que les exclusions de ModSecurity et l’Allowlist de Wordfence : une liste d’exceptions gérée en arrière-plan, sans code ni détournement vers un mode « rapport uniquement ».
- Un clic par ligne du journal. Chaque blocage WAF consigné dans le journal s’accompagne d’une action « Autoriser » qui crée une exception ciblée pour cette règle précise sur ce chemin d’accès. Le journal des blocages enregistre la valeur correspondante, la cible inspectée, la méthode de requête, l’URI, l’agent utilisateur et le Paranoia Level, ce qui permet d’analyser la décision sans avoir à reproduire la requête.
- Limité à un périmètre précis, jamais global. Une exception cible une seule règle, un groupe de règles ou — pour un Endpoint propriétaire — l’ensemble du moteur sur un chemin, éventuellement restreint à une adresse IP ou à un CIDR. Une exception portant sur l’ensemble du moteur doit comporter un chemin ou une adresse IP, afin que le pare-feu ne puisse jamais être désactivé par inadvertance à l’échelle du site.
- À l’échelle du réseau et gratuit. Les exceptions sont stockées en tant que données à l’échelle du réseau (option
reportedip_hive_waf_exceptions, schémadb_version10) et accessibles avec tous les forfaits — le moteur de protection lui-même reste gratuit. - Cela s’applique également au filtre pré-WordPress. Extended Protection intègre ces mêmes exceptions et les réintègre à chaque modification de l’Allowlist ; ainsi, un client que vous avez autorisé dans l’interface d’administration est pris en compte avant même que WordPress ne se charge.
Le formulaire d’exception est intuitif : le sélecteur de portée n’affiche que le champ pertinent, et le champ de saisie ambigu « ID de règle ou groupe » est divisé en un champ « ID de règle » et un menu déroulant « Groupe » alimenté par les catégories connues du moteur. Les développeurs disposent également d’une porte de secours au niveau du code : le reportedip_hive_waf_bypass_routes filtre, mis en correspondance par un test d’ancrage str_starts_with test ancré sur la route REST résolue, de sorte qu’un jeton de contournement présent dans un paramètre de requête sans rapport ne puisse pas désactiver le WAF.
Extended Protection : blocage avant le chargement de WordPress
Le initpare-feu « -hook » s’exécute après le démarrage de WordPress. Pour assurer une protection avant l’exécution de tout code de plugin, Hive propose un module optionnel prêt à l’emploi qui exécute le WAF via la directive auto_prepend_file — la même approche que Wordfence appelle « Extended Protection ». Désactivée par défaut, elle vient s’ajouter au moteur intégré à WordPress et inspecte le corps des requêtes exactement comme le moteur principal (un bug de hoisting qui rendait l’inspection du corps de la requête inopérante sans message d’erreur a été corrigé dans la version 2.1.10).
- Apache reçoit une
php_value auto_prepend_fileligne écrite dans un bloc marqué.htaccessbloc marqué. - PHP-FPM — y compris nginx. Hive détecte la SAPI PHP-FPM avant la chaîne du serveur nginx et définit un répertoire racine
.user.ini, que PHP-FPM respecte pour chaque requête, quels que soient leslocation. Depuis la version 2.1.17, cela prend automatiquement en charge nginx, sans aucune intervention manuelle — les versions antérieures ne proposaient qu’unlocationqui ne protégeait que le bloc dans lequel il était inséré. - Extrait de code de secours. Sur les environnements ne disposant pas d’une SAPI PHP FastCGI, Hive génère tout de même une ligne à copier-coller dans le fichier php.ini / PHP-FPM-pool ainsi qu’un bloc nginx
fastcgi_param PHP_VALUE; l’onglet « Configuration du serveur » les affiche dès que la configuration générée automatiquement.user.inin’est pas encore prise en compte.
Trois comportements de sécurité rendent le système de sécurité prévisible. Il ne procède pas à la vérification d’identité des utilisateurs connectés — il détecte le wordpress_logged_in cookie ; ainsi, un éditeur qui enregistre un article via admin-ajax.php ou via la REST API ne sera jamais bloqué par une signature XSS/SQLi (les règles relatives aux URL et aux user-agents continuent de s’appliquer, et le moteur interne de WordPress reste le dispositif de sécurité tenant compte des capacités). Il s’auto-réinitialise lors de la désactivation : désactiver le WAF ou le basculer en mode « rapport uniquement » neutralise également le garde pré-WordPress, de sorte que le pare-feu ne peut jamais continuer à s’appliquer après avoir été désactivé. Et la suppression est à sécurité intégrée : la désactivation du plugin supprime les directives contrôlées par Hive et laisse un espace réservé inerte au lieu de supprimer le fichier de protection ; ainsi, une ligne résiduelle auto_prepend_file ligne résiduelle dans une configuration nginx ou php.ini que Hive ne peut pas modifier ne pourra jamais pointer vers un fichier manquant et provoquer une erreur 500 sur le site.
La configuration est vérifiable : le statut indique si la protection s’est effectivement déclenchée pour la requête en cours — « Configuration terminée » dès que cela fonctionne — au lieu de se contenter d’une estimation. Le Setup Wizard guide les nouveaux utilisateurs tout au long du processus en proposant des paramètres par défaut sûrs.
Les codes de référence permettent de transformer un bloc erroné en une simple recherche sur une ligne
Chaque bloc comporte un code de référence permettant de l’identifier, tel que WAF_SQLI-3F9A2B71, affiché sur la page du bloc et envoyé dans l’ X-RIP-Ref en-tête. Un visiteur bloqué par erreur cite une courte chaîne de caractères, et un administrateur la retrouve dans les journaux — puis l’efface à l’aide de l’action « Autoriser » en un clic s’il s’agissait d’un False Positive. Le jeton est un hachage unidirectionnel de l’adresse IP, du motif et de l’heure, il ne révèle donc aucune donnée personnelle.
Foire aux questions
Le Web Application Firewall est-il gratuit ?
Oui. Le moteur WAF et la configuration de base « OWASP Top 10 – Paranoia Level 1 » sont inclus dans toutes les formules, y compris la formule Free tier et le mode « Local Shield » entièrement hors ligne. La formule « Professional » ajoute des ensembles de règles plus avancés (niveaux 2 et 3) ainsi que des flux en temps réel via Priority Sync.
Le pare-feu va-t-il bloquer mes propres tâches d’administration ?
Non. Les administrateurs connectés sont exemptés, /wp-admin n’est jamais inspecté, et le filtre pré-WordPress ignore l’inspection du corps de la requête pour tout utilisateur connecté. Si un formulaire côté client ou un Endpoint propriétaire déclenche une règle, ouvrez le journal du WAF, cliquez sur « Autoriser » sur cette ligne pour créer une exception ciblée, et le tour est joué — aucun code ni détour par un rapport n’est nécessaire.
Le pare-feu fonctionne-t-il sous Nginx ?
Oui, et depuis la version 2.1.17, le « pre-WordPress guard » se configure automatiquement sur Nginx en définissant un répertoire racine .user.ini que PHP-FPM respecte pour chaque requête. Si votre pile désactive les fichiers INI par répertoire, l’onglet « Configuration du serveur » affiche une ligne php.ini ou nginx fastcgi_param à insérer à la place.
Que se passe-t-il si le serveur de règles est inaccessible ?
Rien ne tombe en panne. Le plugin continue d’utiliser le dernier ensemble de règles validé, ou la configuration de référence fournie, et réessaie la synchronisation ultérieurement. Le pare-feu ne dépend jamais d’une connexion active pour fonctionner.