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.
Le moteur et son ensemble de règles par défaut sont inclus gratuitement dans toutes les formules. Ce guide explique comment le pare-feu analyse le trafic, d'où proviennent les règles et comment on évite qu'une expression régulière mal conçue ne provoque la mise hors service du site.
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.
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, cette approche correspond à ce que Wordfence appelle la « protection étendue ». Elle est désactivée par défaut et vient s'ajouter au moteur intégré à WordPress.
- Apache obtient un
php_value auto_prepend_fileligne inscrite dans un espace marqué.htaccessbloc. - PHP-FPM obtient un
auto_prepend_fileentrée dans.user.ini, ou une ligne dans le fichier php.ini ou dans le panneau d'hébergement. - nginx ne peut pas être configuré automatiquement (son fichier de configuration se trouve en dehors du répertoire racine du site Web et nécessite un rechargement) ; c'est pourquoi Hive génère un extrait de code prêt à copier-coller dans lequel le chemin absolu actuel est déjà renseigné.
Le module s'ouvre par défaut en cas d'erreur, et sa suppression supprime toujours la directive avant de supprimer le fichier de protection ; ainsi, une préfixation obsolète pointant vers un fichier manquant ne peut jamais entraîner la panne du site. Depuis la version 2.1.4, la configuration est vérifiable : le statut indique si la protection s'est effectivement exécutée pour la requête en cours, au lieu de se contenter d'une supposition.
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 En-tête. Un visiteur bloqué par erreur cite une courte chaîne de caractères, et un administrateur la retrouve dans les journaux. Le jeton est un hachage à sens unique de l'adresse IP, du motif et de l'heure, il ne révèle donc aucune donnée personnelle.
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 ?
Non. Les administrateurs connectés font exception, et /wp-admin n'est jamais vérifié. Si un formulaire côté client déclenche une règle, basculez le WAF en mode « rapport uniquement », identifiez le code d'erreur dans les journaux, puis procédez à l'ajustement à partir de là.
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.