Au cœur du pare-feu d'applications Web ReportedIP
ReportedIP propose un pare-feu pour applications Web 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 injections SQL, 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.
The engine and its baseline ruleset are free on every plan. This guide covers how the firewall inspects traffic, where the rules come from, how a bad regex is stopped from taking the site down, how to clear a false positive from the admin, and how the optional pre-WordPress guard works. It reflects Hive as of version 2.1.21, after the 2.1.5–2.1.21 hardening run.
Ce que le pare-feu WordPress vérifie à chaque requête
Le WAF fonctionne sur le init hook de priorité 1, immédiatement après la vérification des blocs d'adresses IP 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 et 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 catégories d'attaques détectées comprennent l'injection SQL, le cross-site scripting, le parcours de chemin, l'injection de commandes et les wrappers LFI, ainsi que le SSRF, Log4Shell/JNDI, l'injection d'objets PHP, l'injection NoSQL, l'XXE, le téléchargement de shells web, le CRLF et l'injection de modèles — chacune disposant de son propre code de motif de blocage.
Cette vérification est en lecture seule et tient compte des faux positifs. 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 vérifiée, et les adresses IP figurant sur la liste blanche sont ignorées. Une requête est bloquée via le même chemin 403 sécurisé pour le cache et codé par référence que celui utilisé par les autres capteurs, ou simplement enregistrée lorsque le mode « rapport uniquement » est activé.
Pourquoi les règles du pare-feu se trouvent sur le serveur et non dans le plugin
La plupart des pare-feu WordPress intègrent leurs signatures de manière fixe, ce qui signifie que chaque mise à jour des règles nécessite la publication d'un nouveau plugin. Hive fonctionne différemment : les signatures proviennent de l'API Rule reportedip.de 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 ainsi disponibles sur toutes les installations 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 indépendante, 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) auparavant lors de son application. 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 clé API ou de faille du protocole TLS.
La version de base est intégrée au plugin ; ainsi, le pare-feu fonctionne entièrement hors ligne en mode Local Shield, sans compte et sans communication sortante. La synchronisation des règles est facultative : elle ne s'effectue qu'en mode Community, à condition qu'une clé API soit configurée.
Accès gratuit à la version de base, fonctionnalités avancées sur la version Pro
La répartition des règles suit le modèle « Paranoia Level » de l'OWASP Core Rule Set, la norme de facto en matière de pare-feu d'application Web (WAF) utilisée par ModSecurity et Cloudflare.
| Niveau de paranoïa | Personnage | Plan de la ruche |
|---|---|---|
| PL1 | La configuration de base, optimisée pour réduire au minimum les faux positifs, couvre le Top 10 de l'OWASP | Gratuit (version de base incluse) |
| PL2 | Une vigilance accrue, mais aussi quelques faux positifs supplémentaires | Contributeur (hebdomadaire) / Professionnel |
| PL3 | Attaques rares, techniques de dissimulation et contournement des pare-feu d'application Web (WAF), faux positifs occasionnels | Professionnel (Synchronisation prioritaire) |
La version gratuite offre un pare-feu efficace avec un faible taux de faux positifs : c'est la protection garantie. La version Professionnelle ajoute les ensembles de règles PL2/PL3 plus poussés 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 modèles 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 1 million par défaut) puis le rétablit par la suite, ce qui limite la durée d'exécution maximale par motif. - Passer en mode « fail-open » en cas d'erreur d'expression régulière. Lorsqu'un modèle atteint sa limite,
preg_match()retoursfalse, pas0ou1— un contournement silencieux si cette option n'est pas cochée. Hive traitefalseen mode « fail-open » et avec enregistrementwaf_pattern_errorévénement. Une règle non respectée ne bloque jamais le trafic légitime et ne rend jamais le site inaccessible : la disponibilité prime sur la rigueur. - Limite de 8 Ko pour le corps. Les corps dont la taille dépasse 8 Ko ignorent les groupes de corps, ce qui permet de limiter la base de retour en arrière.
- Linter côté serveur. Sur reportedip.de, 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 tout simplement jamais publié.
Les modèles personnalisé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.
Clear a false positive from the admin, without touching code
Any signature firewall will occasionally flag a legitimate first-party request — a page builder posting rich HTML, or a security plugin that legitimately ingests attack-like payloads. Since version 2.1.9, Hive handles this the way ModSecurity exclusions and the Wordfence allowlist do: a backend-managed exception list, no code and no report-only detour required.
- One click per log row. Every WAF block in the log carries an Allow action that creates a narrow exception for exactly that rule on that path. The block log records the matched value, the inspected target, the request method, URI, user-agent and paranoia level, so a decision is diagnosable without reproducing the request.
- Scoped, never global. An exception targets a single rule, a rule group, or — for a first-party endpoint — the whole engine on a path, optionally narrowed to an IP or CIDR. A whole-engine exception must carry a path or IP, so the firewall can never be switched off site-wide by accident.
- Network-wide and free. Exceptions are stored as network-wide data (option
reportedip_hive_waf_exceptions, schemadb_version10) and available on every plan — the protection engine itself stays free. - Applies to the pre-WordPress guard too. Extended Protection bakes the same exceptions in and rebakes them whenever the allowlist changes, so a client you allowed in the admin is honoured before WordPress even loads.
The exception form is self-explanatory: the scope selector reveals only the relevant field, and the ambiguous “Rule ID or group” input is split into a Rule ID field and a group dropdown populated from the engine’s known categories. Developers get a code-level escape hatch as well — the reportedip_hive_waf_bypass_routes filter, matched by an anchored str_starts_with test against the resolved REST route, so a bypass token in an unrelated query parameter cannot disable the WAF.
Protection étendue : blocage avant le chargement de WordPress
Le init- Le pare-feu « -hook » s'exécute après le démarrage de WordPress. Pour assurer une protection avant l'exécution du code des plugins, Hive propose un module optionnel qui exécute le WAF via PHP. auto_prepend_file directive — the same approach Wordfence calls Extended Protection. It is off by default and additive to the in-WordPress engine, and it inspects request bodies just like the main engine (a hoisting bug that made body inspection a silent no-op was fixed in 2.1.10).
- Apache obtient un
php_value auto_prepend_fileligne inscrite dans un espace marqué.htaccessbloc. - PHP-FPM — including nginx. Hive detects the PHP-FPM SAPI ahead of the nginx server string and writes a document-root
.user.ini, which PHP-FPM honours for every request regardless of nginxlocationblocks. Since 2.1.17 this covers nginx automatically, with no manual step — earlier versions could only offer a hand-pastedlocationsnippet that protected just the one block it landed in. - Fallback snippet. On stacks without a FastCGI PHP SAPI, Hive still generates a copy-paste php.ini / PHP-FPM-pool line and an nginx
fastcgi_param PHP_VALUEblock; the Server Setup tab surfaces these whenever the auto-written.user.iniis not yet taking effect.
Three safety behaviours make the guard predictable. It skips body inspection for signed-in users — it detects the wordpress_logged_in cookie, so an editor saving a post through admin-ajax.php or the REST API is never tripped by an XSS/SQLi signature (URL and user-agent rules still run, and the in-WordPress engine stays the capability-aware backstop). It self-heals on toggle: disabling the WAF or switching it to report-only neutralises the pre-WordPress guard as well, so the firewall can never keep enforcing after it was switched off. And removal is fail-safe: deactivating the plugin strips the directives Hive controls and leaves an inert placeholder instead of deleting the guard file, so a leftover auto_prepend_file line in an nginx or php.ini config Hive cannot edit can never point at a missing file and 500 the site.
The setup is verifiable: the status reports whether the guard actually executed for the current request — “Setup complete” the moment it works — instead of guessing. The setup wizard walks new installs through it with safe defaults.
Les codes de référence permettent de transformer un bloc erroné en une simple recherche d'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é sous la forme de X-RIP-Ref header. A visitor who is blocked by mistake quotes one short string, and an admin matches it in the logs — then clears it with the one-click Allow action if it was a false positive. The token is a one-way hash of the IP, the reason and the hour, so it exposes no personal data.
Foire aux questions
Le pare-feu pour applications Web est-il gratuit ?
Oui. Le moteur WAF et la configuration de base « OWASP Top 10 – Niveau de paranoïa 1 » sont inclus dans toutes les formules, y compris l'offre gratuite et le mode Local Shield entièrement hors ligne. La formule Professional inclut en outre 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 ?
No. Logged-in administrators are exempt, /wp-admin is never inspected, and the pre-WordPress guard skips body inspection for any signed-in user. If a front-end form or a first-party endpoint does trip a rule, open the WAF log, click Allow on that row to create a narrow exception, and you are done — no code and no report-only detour needed.
Does the firewall run on nginx?
Yes, and since 2.1.17 the pre-WordPress guard configures itself on nginx automatically by writing a document-root .user.ini that PHP-FPM honours for every request. If your stack disables per-directory INI files, the Server Setup tab shows a php.ini or nginx fastcgi_param line to paste instead.
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 base fournie, et relance la synchronisation ultérieurement. Le pare-feu ne nécessite jamais de connexion active pour fonctionner.