Pare-feu applicatif WordPress : comment Hive bloque les attaques
Le pare-feu WordPress de ReportedIP Hive vérifie chaque requête à la recherche d’injections, de cross-site scripting et de path traversal avant qu’une extension ou un thème ne puisse la traiter. Ce guide explique ce qu’il inspecte, d’où viennent les règles, comment corriger un faux positif sans toucher au code et quand l’Extended Protection optionnelle, avant WordPress, vaut la peine d’être activée.
À quoi sert un pare-feu applicatif pour WordPress ?
Un pare-feu applicatif web (WAF) lit le contenu d’une requête, pas seulement son origine. Là où un blocage d’IP demande « qui frappe à la porte ? », le WAF demande « qu’est-ce qui est envoyé ? ». Une requête qui contient UNION SELECT dans un paramètre ou ../../wp-config.php dans un nom de fichier est refusée, même si personne n’a encore signalé l’adresse.
Cela comble l’intervalle entre une nouvelle faille dans une extension et sa mise à jour. La plupart des attaques contre WordPress visent des failles connues d’extensions et utilisent les mêmes quelques techniques que le OWASP Top 10 recense depuis des années. Un pare-feu qui reconnaît ces techniques protège un site même pendant qu’une mise à jour est en attente.
Ce que le pare-feu de Hive inspecte à chaque requête
Le pare-feu est l’un des 16 capteurs de ReportedIP Hive et s’exécute très tôt pendant le chargement de WordPress. Les adresses déjà bloquées sont refusées avant lui, il n’inspecte donc que ce qui reste. Il vérifie l’adresse de la requête avec sa chaîne de requête, le corps de la requête y compris le JSON, et le user agent. L’interface de Hive est en anglais, les libellés cités dans ce guide restent donc en anglais.
La base gratuite livrée avec l’extension couvre sept catégories d’attaque :
- Injection SQL
- Cross-site scripting, y compris l’injection HTML
- Path traversal
- Injection de commandes
- Tentatives d’accès à des fichiers sensibles comme des sauvegardes de configuration
- User agents de scanners connus
- Abus du point d’accès batch de l’API REST
Avec Priority Sync, à partir de la formule Professional, d’autres catégories arrivent par le flux de règles, parmi lesquelles la falsification de requêtes côté serveur, Log4Shell, l’injection d’objets PHP, les entités externes XML, le dépôt de web shells, l’injection CRLF et l’injection de templates.
Les utilisateurs connectés qui peuvent modifier des articles, du contributeur à l’administrateur, ne sont pas inspectés, car les constructeurs de pages et les éditeurs envoient légitimement du balisage et du code. L’administration est également exclue, à une exception près : les requêtes anonymes vers les points d’accès AJAX et de formulaire sont tout de même vérifiées. Les IP en liste blanche, les tâches cron et WP-CLI passent sans inspection.
Ce qui se passe quand une requête correspond à une règle
Une correspondance termine la requête avec la page de blocage de Hive et un code de référence comme WAF_SQLI-3F9A2B71. La page est compatible avec le cache : une extension de cache ne peut pas servir à l’attaquant une copie stockée d’une page normale. Le code est aussi envoyé dans l’en-tête X-RIP-Ref. Il est calculé à partir de l’IP, du motif et de l’heure par une empreinte à sens unique et ne contient aucune donnée personnelle.
Des correspondances répétées depuis la même adresse mènent à un blocage d’IP via l’échelle de blocage progressive. Les attaques sans ambiguïté, comme le path traversal, l’injection de commandes ou le dépôt d’un web shell, bloquent l’adresse dès la première correspondance. L’injection SQL et le cross-site scripting nécessitent plusieurs correspondances, car ils produisent le plus de faux positifs. En mode Community Network, le blocage est partagé avec la communauté.
Chaque correspondance apparaît dans l’Event Log sous ReportedIP Hive > Activity, avec la règle, le groupe de règles, le texte détecté, la méthode et le user agent. Si vous voulez observer avant de bloquer, activez Firewall report-only dans la carte Firewall & Bots : les correspondances sont alors journalisées comme « WAF Match (report-only) » et la requête passe.
D’où viennent les règles du pare-feu
Les règles de base font partie de l’extension, le pare-feu fonctionne donc entièrement hors ligne en mode Local Shield, sans compte. En mode Community Network avec une clé, Hive peut aussi récupérer des jeux de règles depuis la Rule API de reportedip.com. Il y en a cinq : signatures WAF, identités de robots vérifiés, domaines d’e-mail jetables, chemins sondés par les scanners et nœuds de sortie Tor. Vous les voyez avec leur version, leur nombre de règles et leur source sous ReportedIP Hive > Tools, onglet Rules.
Chaque jeu de règles est signé. Hive vérifie la signature avec une clé enregistrée dans l’extension avant d’appliquer la moindre règle. Un flux manipulé ou endommagé est rejeté, le dernier jeu vérifié reste actif, et s’il n’y en a pas, la base prend le relais. Le pare-feu ne dépend jamais d’une connexion en direct.
La profondeur des règles suit le modèle des niveaux de paranoïa de l’OWASP Core Rule Set :
| Niveau | Caractère | Formule |
|---|---|---|
| 1 | Base avec peu de faux positifs | Toutes les formules, y compris Free |
| 2 | Plus strict, plus de catégories | À partir de Professional |
| 3 | Attaques rares et masquées, sur option | À partir de Professional |
Les niveaux 2 et 3 nécessitent Priority Sync, qui livre chaque jour les jeux de règles complets. Le niveau se règle avec Firewall paranoia level dans la carte Firewall & Bots de la page Protection.
Comment une règle défectueuse ne met pas le site à terre
Des règles venues d’un flux présentent un risque propre : une expression régulière mal écrite peut occuper le processeur d’un serveur pendant des secondes à chaque requête. Hive s’en protège de plusieurs façons. Chaque règle s’exécute dans un budget de temps fixe. Une règle qui échoue laisse passer la requête au lieu de la bloquer, et l’extension journalise un avertissement. Les corps de requête volumineux ne sont lus que jusqu’à une limite. Enfin, côté serveur, chaque nouvelle règle est automatiquement vérifiée à la recherche de motifs dangereux avant d’être signée et livrée.
Corriger un faux positif sans code
Tout pare-feu à signatures signale de temps en temps une requête légitime, par exemple un formulaire de recherche qui accepte des extraits de code ou votre propre API qui reçoit des échantillons d’attaque. Hive règle cela avec les exceptions WAF, disponibles dans toutes les formules.
Étape 1 : trouver l’événement
Demandez au visiteur le code de référence et l’heure. Ouvrez ReportedIP Hive > Activity, Event Log, filtrez sur le type d’événement WAF Block et retrouvez l’entrée grâce à l’IP, l’heure et la règle. Le code de référence lui-même n’est pas enregistré dans le journal.
Étape 2 : autoriser la règle
Cliquez sur le bouton en forme de bouclier de la ligne, dont l’info-bulle indique « Allow this rule on this path (WAF exception) ». Hive crée une exception pour cette règle précise. Le chemin n’est inclus que si le journal l’a enregistré, ce qui n’est pas le cas tant que Minimal logging est activé, le réglage par défaut. Sans chemin, l’exception s’applique à tout le site : restreignez-la donc à l’étape suivante.
Étape 3 : vérifier l’exception
Toutes les exceptions figurent dans la carte WAF Exceptions sous Tools > Rules. Vous pouvez aussi y en ajouter une à la main. Le champ Scope décide de sa portée : une règle, un groupe de règles ou tout le moteur. Une exception pour tout le moteur doit porter un préfixe de chemin ou une plage d’IP, pour que le pare-feu ne puisse pas être coupé par erreur sur tout le site. Le menu Tools apparaît en Expert mode ; sans lui, le bouton Manage rules and exceptions de la carte Firewall & Bots y mène.
Extended Protection : bloquer avant le chargement de WordPress
Le pare-feu normal s’exécute à l’intérieur de WordPress. L’Extended Protection ajoute une petite garde que PHP exécute avant WordPress et avant tout code d’extension. Elle refuse les requêtes correspondantes et les IP bloquées plus tôt et avec moins de charge serveur. Elle est désactivée par défaut et gratuite dans toutes les formules.
Vous l’activez sous ReportedIP Hive > Tools, onglet Server, avec Enable extended protection. Sur Apache et sur PHP-FPM, ce qui inclut la plupart des configurations nginx, Hive écrit lui-même le réglage serveur nécessaire. Là où ce n’est pas possible, le Server Setup affiche une ligne à coller dans le php.ini ou dans la configuration nginx. Le statut indique Running dès que la garde s’est exécutée pour une requête, vous n’avez donc pas à deviner si l’installation a fonctionné.
Trois points diffèrent du pare-feu normal. La garde ne voit pas les rôles WordPress, seulement si quelqu’un est connecté ; avec Leave the request body of signed-in users alone, activé par défaut, elle ignore le corps des requêtes des utilisateurs connectés, pour qu’un rédacteur qui enregistre un article ne soit pas refusé. La garde applique les mêmes exceptions et le même niveau de paranoïa que le pare-feu normal. Et un visiteur qu’elle refuse voit une page sobre avec le mot « Forbidden », sans la page de blocage mise en forme, sans code de référence ni bouton de contact. La correspondance apparaît quand même dans l’Event Log avec la règle, l’heure et l’IP.
La désactivation de l’extension supprime les réglages que Hive a écrits lui-même et laisse un fichier de remplacement inoffensif, afin qu’un réglage serveur ajouté à la main ne puisse pas casser le site. Retirez vous-même une telle ligne après la désinstallation.
Questions sur le pare-feu WordPress
Le pare-feu applicatif de Hive est-il gratuit ?
Le moteur du pare-feu, les règles de base pour sept catégories d’attaque, les exceptions WAF et l’Extended Protection sont gratuits dans toutes les formules et fonctionnent hors ligne en mode Local Shield. La formule Professional ajoute Priority Sync avec des jeux de règles complets chaque jour, des niveaux de paranoïa plus stricts et d’autres catégories comme SSRF, Log4Shell et XXE.
Le pare-feu bloque-t-il les rédacteurs qui travaillent dans WordPress ?
Le pare-feu normal n’inspecte pas les utilisateurs connectés qui peuvent modifier des articles, et l’administration est exclue. Avec l’Extended Protection, le corps des requêtes des utilisateurs connectés est ignoré par défaut. Si un formulaire public ou votre propre point d’accès déclenche une règle, une exception WAF pour cette règle et ce chemin règle le problème sans code.
Le pare-feu fonctionne-t-il avec nginx ?
Le pare-feu normal fonctionne sur tous les serveurs, car il s’exécute à l’intérieur de WordPress. Pour l’Extended Protection sous nginx avec PHP-FPM, Hive écrit automatiquement le réglage serveur. Si votre hébergeur ne le permet pas, le Server Setup affiche une ligne pour le php.ini ou la configuration nginx, à ajouter à la main.
Que se passe-t-il si le serveur de règles est injoignable ?
Rien ne cesse de fonctionner. Hive garde le dernier jeu de règles vérifié et revient aux règles de base de l’extension s’il n’y en a aucun. La synchronisation suivante réessaie. Comme chaque jeu de règles est signé et vérifié avant usage, un flux manipulé ne peut pas non plus modifier les règles.
À lire ensuite
- Les 16 capteurs d’attaque
- Chemins leurres contre les scanners
- Durcissement face aux vagues d’attaques
La documentation de Hive détaille le pare-feu et la livraison des règles ainsi que les exceptions WAF. Toutes les autres fonctions sont expliquées dans les guides de ReportedIP Hive.