Skip to main contentSkip to footer

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.

OffreRèglesActualisation
Local Shield, toute offreBase OWASP Top 10 fournie, Paranoia Level 1Avec les mises à jour de l’extension
Free, Community NetworkJeu de règles du serveur au Paranoia Level 1, plus complet que la base fournieToutes les six heures
ContributorPriority Sync : Paranoia Level 2 et les flux de plages d’adresses des botsChaque semaine
Professional et au-delàPriority Sync : Paranoia Level 3, plages des bots, liste en direct des domaines d’adresses jetablesChaque 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 .htaccess ou 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.php l’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_routes exclut 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

Security Focused
Conforme au RGPD
Made in Germany
Retour aux docs