Pare-feu et WAF
Hive inspecte les requêtes à deux endroits qui se comportent de la même façon : un moteur dans WordPress et une garde optionnelle qui s’exécute avant le chargement de WordPress. Les règles ne sont pas écrites dans l’extension, elles sont livrées signées par reportedip.com, avec une base fournie qui fonctionne toujours hors ligne. Le moteur est gratuit avec toutes les offres.
Le moteur dans WordPress
Sur init avec la priorité 1, le moteur compare le jeu de règles actif à l’URI, aux paramètres, au
corps de la requête (aussi dans une copie décodée) et au user agent : injection SQL, cross-site scripting,
traversée de répertoires, injection de commandes, wrappers d’inclusion de fichiers, SSRF, Log4Shell, injection
d’objets PHP, XXE, téléversement de web shells, CRLF et injection de templates, user agents de scanners. Une
correspondance aboutit à la page de blocage 403 commune.
- Sûr par conception : expressions régulières bornées, une règle mal formée est ignorée, et une erreur laisse passer la requête au lieu de faire tomber le site.
- Pas de fausses alertes pour vos rédacteurs : les utilisateurs connectés autorisés à modifier du contenu, wp-admin, le cron et WP-CLI ne sont pas inspectés par le moteur ; la liste blanche l’emporte toujours.
- Report-only : le pare-feu peut journaliser ce qu’il bloquerait (
waf_would_block) sans bloquer. - Où : moteur, mode et Paranoia Level sous Protection → Firewall & Bots ; synchronisation des règles et exceptions sous Tools → Rules ; le journal du pare-feu sous Activity.
Livraison signée des règles et Priority Sync
Les jeux de règles arrivent versionnés et signés Ed25519 depuis reportedip.com. L’extension vérifie chaque jeu de règles avec une clé publique qu’elle embarque et garde la base fournie si un flux manque, est trop volumineux ou ne se vérifie pas : un flux altéré ne peut donc pas modifier vos règles. Les nouvelles signatures atteignent chaque site connecté en quelques heures, sans nouvelle version de l’extension.
| Offre | Règles | Actualisation |
|---|---|---|
| Local Shield, toute offre | Base OWASP Top 10 fournie, Paranoia Level 1 | Avec les mises à jour de l’extension |
| Free, Community Network | Jeu de règles du serveur au Paranoia Level 1, plus complet que la base fournie | Toutes les six heures |
| Contributor | Priority Sync : Paranoia Level 2 et les flux de plages d’adresses des bots | Chaque semaine |
| Professional et au-delà | Priority Sync : Paranoia Level 3, plages des bots, liste en direct des domaines d’adresses jetables | Chaque jour |
Le Paranoia Level 3 est strict et détecte les charges utiles obscurcies, au prix de davantage de faux positifs ; il s’adresse aux exploitants expérimentés. Contributor est une offre gratuite pour les comptes qui fournissent des données, par exemple via un honeypot ou l’agent Linux.
Extended Protection : la garde avant WordPress
Une garde auto_prepend_file optionnelle applique les mêmes règles, exceptions, liste blanche et blocages
d’IP avant le chargement de WordPress, si bien qu’une requête bloquée ne coûte presque rien. Ses détections sont
écrites dans une file puis importées dans le journal et l’échelle d’escalade ; un blocage posé par l’extension
atteint la garde dans la même requête. La garde est désactivée par défaut et se configure sous Tools →
Server :
- Apache et PHP-FPM (y compris nginx avec PHP-FPM) sont configurés automatiquement via
.htaccessou un.user.inià la racine du site. - Les autres environnements reçoivent la ligne pour php.ini ou le panneau d’hébergement, ou un extrait nginx
fastcgi_param. - Utilisateurs connectés : la garde saute l’inspection du corps lorsqu’un cookie de connexion WordPress est présent, si bien que l’enregistrement de contenu ne la déclenche jamais ; les règles sur l’URL et le user agent s’appliquent toujours.
- Un état fiable : l’onglet Server indique si la garde s’est réellement exécutée pour la requête en cours, et le registre de disponibilité avertit si sa file n’est pas inscriptible.
- Fail-open et sans risque à retirer : toute erreur laisse passer la requête. La désactivation retire les directives que Hive gère et laisse un fichier de remplacement inerte, si bien qu’une ligne oubliée dans une configuration éditée à la main ne pointe jamais vers un fichier manquant. Le mode report-only désactive aussi la garde.
Exceptions pour les faux positifs
Un formulaire qui accepte du HTML, un constructeur de pages qui envoie du balisage brut ou une API qui reçoit des échantillons d’attaques peuvent déclencher une signature de temps à autre. Une exception laisse passer ce cas précis, tandis que le reste reste protégé.
- Où : Tools → Rules → WAF Exceptions, ou Allow sur une ligne du pare-feu dans le journal, qui prépare une exception étroite pour exactement cette règle sur ce chemin.
- Portée : une règle, un groupe de règles ou, pour un point d’accès qui vous appartient, tout le moteur sur un chemin, éventuellement restreint à une adresse ou une plage. Une exception sur tout le moteur exige toujours un chemin ou une adresse, le pare-feu ne peut donc jamais être désactivé globalement par erreur.
- Restez précis : une règle sur un chemin plutôt qu’un groupe, un groupe plutôt que tout le moteur. La ligne du journal affiche la valeur détectée, la partie inspectée, la méthode, l’URI et le user agent, et pour
admin-ajax.phpl’action AJAX. - Les deux couches : les exceptions sont intégrées à la garde et reconstruites à chaque modification de la liste. Sur un réseau, elles s’appliquent à tous les sites. Toutes les offres.
- Dans le code : le filtre
reportedip_hive_waf_bypass_routesexclut des routes REST par un préfixe ancré sur la route résolue ; il agit uniquement dans le moteur.
Codes de référence et page de blocage
Chaque blocage, du pare-feu ou d’un capteur, porte un code comme WAF_SQLI-3F9A2B71 sur la page de
blocage et dans l’en-tête X-RIP-Ref. Un visiteur bloqué par erreur cite ce code, et vous retrouvez la
ligne dans le journal. Le code est une empreinte à sens unique de l’adresse, du motif et de l’heure, il ne révèle
donc rien. Les textes de la page de blocage se remplacent avec le filtre
reportedip_hive_blocked_page_strings.
Caches de pages
La page de blocage définit DONOTCACHEPAGE, DONOTCACHEDB et DONOTCACHEOBJECT
et envoie Cache-Control: no-store, no-cache, must-revalidate, max-age=0, Pragma: no-cache
ainsi que les nocache_headers() de WordPress. WP Rocket, W3 Total Cache, WP Super Cache et LiteSpeed
Cache les respectent, si bien qu’un attaquant bloqué ne laisse jamais une 403 en cache pour les vrais visiteurs.
La vérification des formulaires ne contient rien de propre à une requête, les pages en cache continuent donc de
fonctionner avec elle.
Dernière mise à jour: · Maintenu par l’équipe ReportedIP