Configurer le Pare-feu 8G
Le pare-feu 8G dispose de 7 réglages qui permettent d’ajuster finement son comportement.
[rank_math_breadcrumb]
Tableau des réglages
| Réglage | Type | Défaut | Recommandation |
|---|---|---|---|
| Filtrer les Query Strings | Case à cocher | Activé | Laisser activé |
| Filtrer les URI | Case à cocher | Activé | Laisser activé |
| Filtrer les User Agents | Case à cocher | Activé | Laisser activé |
| Filtrer les Referrers | Case à cocher | Activé | Laisser activé |
| Filtrer les méthodes HTTP | Case à cocher | Activé | Laisser activé |
| Action en cas de détection | Sélecteur | Bloquer la requête (403) | Bloquer en production |
| IPs en liste blanche | Zone de texte | Vide | Ajouter vos services tiers |
Détail de chaque réglage
Filtrer les Query Strings
Analyse les paramètres passés dans l’URL (tout ce qui suit le ?). Détecte les tentatives d’injection SQL, les scripts XSS et les commandes système cachées dans les paramètres.
💡 Conseil : Ne désactivez ce filtre que si un service légitime est bloqué et que l’ajout de son IP en liste blanche ne résout pas le problème.
Filtrer les URI
Analyse l’adresse demandée pour détecter les tentatives d’accès à des fichiers sensibles (fichiers de configuration, sauvegardes, fichiers PHP isolés) et les extensions dangereuses (.sql, .bak, .log, etc.).
Filtrer les User Agents
Analyse l’identifiant du navigateur ou de l’outil utilisé pour envoyer la requête. Bloque les scanners de vulnérabilités, les bots malveillants connus et les navigateurs automatisés utilisés pour les attaques.
Filtrer les Referrers
Analyse la page d’origine déclarée par la requête. Bloque le spam de referrers et les requêtes provenant de domaines suspects.
Filtrer les méthodes HTTP
Bloque les méthodes HTTP non standard (TRACE, TRACK, CONNECT, DELETE, etc.) qui ne sont pas utilisées par les navigateurs classiques mais qui peuvent être exploitées dans certaines attaques.
Action en cas de détection
Détermine ce qui se passe quand une requête malveillante est détectée :
| Option | Comportement |
|---|---|
| Bloquer la requête (403) | La requête est bloquée, l’IP reçoit une erreur 403, et l’événement est enregistré dans le journal d’audit |
| Journaliser uniquement | La requête est autorisée mais l’événement est enregistré dans le journal d’audit |
💡 Conseil : Utilisez le mode « Journaliser uniquement » pendant quelques jours après l’installation pour vérifier qu’aucun service légitime n’est bloqué. Consultez ensuite le journal d’audit, puis passez en mode « Bloquer » une fois satisfait.
IPs en liste blanche
Saisissez les adresses IP qui ne doivent jamais être filtrées par le pare-feu, une par ligne. La notation CIDR est supportée pour les plages d’adresses.
Exemples :
203.0.113.50
198.51.100.0/24
2001:db8::1
💡 Conseil : Ajoutez les adresses IP de vos services tiers (CDN, outils de monitoring, API partenaires) pour éviter les faux positifs. Si vous utilisez un CDN comme Cloudflare, ajoutez les plages d’IP de Cloudflare.
Cas pratiques
Le pare-feu bloque un plugin ou un service légitime
- Consultez le journal d’audit (Samaritain > Tableau de bord > Événements récents) pour identifier la requête bloquée
- Notez l’adresse IP et le type de blocage
- Si c’est un service externe : ajoutez son IP dans la liste blanche du pare-feu
- Si c’est une requête interne : identifiez le filtre responsable (Query Strings, URI, etc.) et envisagez de le désactiver temporairement pour confirmer
Tester le pare-feu sans risque
- Passez l’action en « Journaliser uniquement »
- Naviguez sur votre site normalement pendant 2-3 jours
- Consultez le journal d’audit pour vérifier les détections
- Si aucun faux positif : repassez en « Bloquer la requête »
ℹ️ Note : Le pare-feu ne filtre jamais les pages d’administration (
wp-admin), les tâches planifiées (wp-cron), l’API REST (wp-json) et la page de connexion. Vous ne pouvez pas vous bloquer accidentellement.
