Firewall : Votre Première Ligne de Défense

Firewall : La Porte d'Entrée Protégée

Un firewall est comme un gardien à l'entrée de votre site. Il examine chaque visiteur (requête HTTP) avant de le laisser entrer :

• D'où venez-vous ? (IP)
• Que tentez-vous de faire ? (URL, type de requête)
• Comment vous comportez-vous ? (modèle d'accès)

Sur la base de ces questions, le firewall décide : autoriser, défier (CAPTCHA), ou bloquer.

Sélection du Mode

Le Firewall propose différents modes de fonctionnement selon vos besoins de sécurité. Chaque mode détermine quand le firewall bloque le trafic et quand il autorise l'accès.

Comment Choisir le Bon Mode ?

Le choix du mode dépend de votre situation spécifique :

• Tout juste installé : Commencez en Monitoring pour observer
• En production : Protection est le mode standard
• En crise : Strict pour une protection maximale
• En développement : Off pour ne pas affecter le travail

Processus Recommandé

1. OFF → MONITOR: Premiers jours pour observer sans rien bloquer
2. MONITOR → PROTECTION: Mode standard permanent, une fois confirmé l'absence de faux positifs
3. PROTECTION → STRICT: Seulement si nécessaire

Alerte de Baisse de Protection

Juste sous l'interrupteur principal de cet écran se trouve un second interrupteur, plus petit : "Me prévenir si le Firewall est désactivé ou si la protection baisse". Désactivé par défaut.

Activez-le et vous recevez un email immédiat —pas besoin d'attendre le rapport de sécurité périodique—, au moment précis où le niveau de protection du Firewall baisse :

• Block ou Strict → Monitor (arrête de bloquer, se contente d'enregistrer)
• N'importe quel mode → Off (le Firewall est entièrement désactivé)

N'alerte que lorsque la protection baisse. Augmenter la protection (par exemple passer de Monitor à Block) ne déclenche jamais d'alerte —cela n'aurait aucun sens de vous déranger pour avoir renforcé la sécurité.

L'email indique clairement l'état précédent et le nouveau, avec la date et l'heure, ainsi qu'un lien direct pour vérifier le Firewall. Chaque alerte arrive comme un email à part entière (la date et l'heure figurent dans l'objet) afin que plusieurs alertes consécutives ne se regroupent pas dans un même fil et n'en masquent pas la plus récente.

S'active et se désactive instantanément depuis ce même interrupteur —pas besoin d'enregistrer ni de recharger la page.

Modes de Fonctionnement du Firewall

Le Firewall dispose de différents "modes" selon vos besoins. Chaque mode change quand il bloque.

1. Mode OFF (Désactivé)

Ce qu'il fait : Rien. Le firewall n'est pas actif.

Quand l'utiliser : Jamais en production. Uniquement pendant le développement initial.

2. Mode MONITOR (Observer)

Ce qu'il fait : Enregistre l'activité suspecte mais NE bloque PAS. Il surveille seulement.

Comportement : Tout le monde accède, mais le firewall enregistre "ceci aurait été bloqué si..."

Quand l'utiliser :

• Premiers jours après l'installation de SeenSecure
• Pour apprendre ce qui est normal vs suspect sur votre site
• Avant de passer à un mode plus agressif

3. Mode PROTECTION (Protection Normale)

Ce qu'il fait : Équilibre : bloque les attaques réelles mais autorise le trafic légitime.

Comportement : Les attaques sont bloquées, le trafic normal passe.

Quand l'utiliser : Sites en production normale. Défense standard.

4. Mode STRICT (Strict)

Ce qu'il fait : Protection maximale. Bloque tout ce qui est même légèrement suspect.

Comportement : Peut produire des faux positifs (utilisateurs légitimes bloqués).

Quand l'utiliser :

• Site sous attaque active
• Site très critique (banque, santé)
• Après avoir été piraté

Que Protège le Firewall ?

Chacun des éléments suivants est un type d'attaque réel et fréquent contre les sites WordPress — ce ne sont pas des cas hypothétiques, ce sont les techniques que les scanners automatiques testent contre pratiquement n'importe quel site public, le vôtre y compris, tous les jours. Pour chacune, nous expliquons à quoi sert la protection, pourquoi l'attaquant la tente (ce qu'il gagne si ça marche), et comment le pare-feu agit pour l'empêcher.

SQL Injection (SQLi)

À quoi sert cette protection : votre site stocke tout — utilisateurs, mots de passe chiffrés, articles, commandes — dans une base de données qui parle un langage appelé SQL. Quand vous remplissez un formulaire (un champ de recherche, une connexion, un commentaire), ce texte finit généralement par faire partie d'une instruction SQL exécutée sur le serveur. L'injection SQL consiste à écrire, dans ce même champ, non pas la donnée attendue, mais des fragments de code SQL — pour que le serveur ne se contente pas de stocker votre texte, mais exécute aussi la commande que vous y avez glissée.

Pourquoi un attaquant la tente : si l'injection fonctionne, l'attaquant peut lire des données qu'il ne devrait pas voir (mots de passe chiffrés, e-mails de clients, clés API stockées dans la base de données), les modifier (transformer son propre compte en administrateur), voire supprimer des tables entières. C'est l'un des moyens les plus directs de voler une base de données complète sans avoir besoin d'aucun mot de passe.

Comment le pare-feu l'arrête : SeenSecure analyse le contenu de chaque champ avant qu'il n'atteigne WordPress, en recherchant des motifs de syntaxe SQL typiques là où il ne devrait y avoir que du texte normal (guillemets isolés suivis de mots-clés SQL comme OR, UNION, DROP, SELECT dans des combinaisons qui n'ont aucun sens en tant que texte légitime). S'il détecte le motif, il bloque toute la requête avant même que ce texte ne soit construit en requête SQL — la base de données ne voit jamais l'attaque.

Cross-Site Scripting (XSS)

À quoi sert cette protection : quand quelqu'un laisse un commentaire, remplit un profil ou soumet un formulaire, ce texte est souvent réaffiché plus tard sur la page — pour vous, pour d'autres visiteurs, ou pour l'administrateur lors de l'examen des commentaires en attente. Le XSS consiste à insérer, dans ce texte, du vrai code JavaScript au lieu de texte normal, pour que ce code s'exécute dans le navigateur de quiconque le consulte ensuite.

Pourquoi un attaquant la tente : la cible est presque toujours le navigateur de quelqu'un d'autre — pas celui de l'attaquant, mais celui d'un visiteur ou, meilleur cas pour l'attaquant, celui de l'administrateur. Si le script s'exécute dans le navigateur d'un admin connecté, il peut voler sa session (cookie de connexion) et agir à sa place — sans jamais avoir besoin de son mot de passe. C'est aussi utilisé pour rediriger les visiteurs vers des sites de phishing ou pour superposer du faux contenu au vrai site.

Comment le pare-feu l'arrête : le pare-feu examine chaque donnée envoyée à la recherche de balises HTML/JavaScript exécutables (<script>, attributs onerror=, onclick=, schémas javascript: dans les liens, etc.) là où il ne devrait y avoir que du texte brut, et bloque la requête s'il les trouve — avant que ce contenu ne soit jamais stocké ou montré à qui que ce soit.

Path Traversal

À quoi sert cette protection : certaines parties de votre site demandent, directement dans l'URL, le nom d'un fichier à afficher (une image, un PDF téléchargeable, un fichier de langue de modèle). Le Path Traversal consiste à écrire, au lieu d'un nom de fichier normal, un chemin qui "remonte" hors du dossier autorisé grâce à des ../ répétés, pour atteindre des fichiers complètement différents sur le serveur.

Pourquoi un attaquant la tente : la cible typique est la lecture de fichiers de configuration contenant des secrets — surtout wp-config.php, qui stocke les identifiants d'accès à la base de données en texte clair. Avec ces identifiants, l'attaquant peut contourner entièrement WordPress et se connecter directement à la base de données.

Comment le pare-feu l'arrête : il bloque toute requête dont les paramètres contiennent des séquences "remonter d'un dossier" (../ ou sa forme encodée %2e%2e%2f) combinées à des tentatives de pointer vers des chemins hors du répertoire attendu, et protège explicitement l'accès direct à des fichiers sensibles comme wp-config.php.

Remote & Local File Inclusion (RFI / LFI)

À quoi sert cette protection : certains plugins ou thèmes mal codés chargent dynamiquement un fichier PHP à partir d'un paramètre d'URL (par exemple, pour choisir quel modèle de langue afficher). Le RFI consiste à faire pointer ce paramètre non pas vers un fichier local, mais vers une URL externe contrôlée par l'attaquant ; le LFI consiste à pointer vers un fichier local du serveur lui-même qui ne devrait normalement pas être exécuté directement.

Pourquoi un attaquant la tente : s'il parvient à faire exécuter par le serveur son propre fichier PHP (hébergé sur son propre serveur, en RFI) ou un fichier local manipulable (en LFI, souvent combiné au téléversement préalable d'un fichier malveillant déguisé en image), il obtient une exécution de code complète sur votre serveur — l'objectif ultime de la plupart des attaques web sérieuses.

Comment le pare-feu l'arrête : il bloque les paramètres contenant des URLs complètes (http://, https://, ftp:// ou des protocoles de flux comme php://, data://) là où un nom de fichier local est attendu, et applique les mêmes protections anti-Path-Traversal pour empêcher un paramètre de fichier de "s'échapper" vers des chemins système qu'il ne devrait pas toucher.

Directory Listing

À quoi sert cette protection : lorsque vous visitez un dossier de site web sans fichier index.php ou index.html à l'intérieur, certains serveurs affichent par défaut automatiquement la liste complète de tous les fichiers de ce dossier — comme si vous aviez ouvert l'explorateur de fichiers du serveur directement depuis le navigateur.

Pourquoi un attaquant la tente : ce n'est pas une attaque en soi, mais de la reconnaissance — l'étape précédant une véritable attaque. Un attaquant parcourant les dossiers de plugins et thèmes peut découvrir exactement quelle version vous utilisez (pour rechercher des vulnérabilités connues déjà publiées pour cette version), des fichiers de sauvegarde oubliés (.sql, .zip), ou des fichiers de configuration qui n'auraient jamais dû être téléversés sur le serveur.

Comment le pare-feu l'arrête : il bloque directement toute requête vers la racine d'un dossier de plugin ou de thème qui ne demande pas un fichier précis, renvoyant une erreur au lieu de la liste — combiné à la protection des fichiers sensibles, qui empêche l'accès direct aux sauvegardes et fichiers de configuration même si quelqu'un en connaît le nom exact.

Command Injection

À quoi sert cette protection : certains plugins (redimensionnement d'images, génération de PDF, conversion de fichiers) exécutent parfois des commandes du système d'exploitation du serveur en arrière-plan, en utilisant une partie des données que vous envoyez comme partie de cette commande. L'injection de commandes consiste à insérer, dans ces données, des caractères spéciaux que le système d'exploitation interprète comme "fin de cette commande, en commencer une nouvelle".

Pourquoi un attaquant la tente : c'est l'équivalent, au niveau du système d'exploitation, de l'injection SQL au niveau de la base de données — si ça fonctionne, l'attaquant exécute des commandes arbitraires directement sur le serveur (lister les fichiers, créer des utilisateurs système, télécharger et installer des malwares), avec le même niveau d'accès que le serveur web lui-même.

Comment le pare-feu l'arrête : il bloque les requêtes dont les paramètres contiennent les caractères spéciaux que le système d'exploitation utilise pour enchaîner ou séparer des commandes (;, &&, |, accents graves) dans des contextes où ces caractères n'ont aucun sens légitime.

XML External Entity (XXE)

À quoi sert cette protection : certaines fonctions de WordPress et certains plugins traitent des fichiers au format XML (par exemple lors de l'importation de contenu, du traitement de certains flux, ou de formats de documents comme .docx/.xlsx, qui sont en interne du XML). Le format XML permet de définir des "entités" — des raccourcis qui se développent en un autre contenu — et certaines de ces entités peuvent pointer vers des fichiers locaux du serveur ou des adresses réseau internes.

Pourquoi un attaquant la tente : en définissant une entité malveillante dans un fichier XML téléversé ou importé, il peut amener le serveur lui-même à lire et renvoyer le contenu de fichiers locaux (comme wp-config.php) dans la réponse, ou utiliser le serveur comme intermédiaire pour atteindre des services réseau internes qui ne devraient pas être accessibles depuis l'extérieur.

Comment le pare-feu l'arrête : en plus de la protection des téléversements qui bloque les fichiers au contenu XML suspect, SeenSecure s'assure que le traitement XML du serveur lui-même a le chargement d'entités externes désactivé — la cause profonde qui rend cette attaque possible — de sorte que même si un XML malveillant venait à être traité, cette partie dangereuse du format n'est tout simplement pas interprétée.

Type d'Attaque	Gravité	Mode minimum pour bloquer
SQL Injection	⭐⭐⭐⭐⭐	Protection+
XSS	⭐⭐⭐⭐	Protection+
RFI / LFI	⭐⭐⭐⭐⭐	Protection+
Command Injection	⭐⭐⭐⭐⭐	Protection+
XXE	⭐⭐⭐⭐	Protection+
Path Traversal	⭐⭐⭐	Protection+
Directory Listing	⭐⭐	Protection+

Comment Activer et Configurer le Firewall

Étape 1 : Choisir le Mode

Firewall > Mode > choisissez Monitoring, Protection ou Strict > Enregistrer

Recommandation : Commencez avec Monitoring pendant 48 heures. L'interrupteur général du module Firewall & WAF (pour le désactiver entièrement) se trouve dans la liste des modules du Dashboard de SeenSecure.

Étape 2 : Vérifier les Journaux

Firewall > Traffic Log

Voyez-vous beaucoup de faux positifs ? Des utilisateurs légitimes bloqués ? Ajustez les paramètres de la protection concernée.

Étape 3 : Configurer la Sensibilité

Dans Firewall → Anti-Injection & RCP, le Bouclier Anti-Injection (SQLi/XSS/LFI/Commandes/XXE/SSRF) dispose de deux réglages propres, indépendants du Mode global :

• Action : Off, Défi, Bloquer, Bloquer uniquement la requête (403 sans enregistrer l'IP), ou Monitor (enregistrement seul)
• Sensibilité : Basse, Moyenne (recommandée) ou Haute — plus la sensibilité est élevée, plus de schémas sont bloqués, mais avec un risque accru de faux positifs

Étape 4 : Définir des Exclusions (Optionnel)

Si le Bouclier Anti-Injection bloque des requêtes à tort, ajoutez dans le même onglet :

• Chemins dans la liste blanche (un chemin ou fragment d'URL par ligne)
• Paramètres dans la liste blanche (par nom de champ/paramètre)

Étape 5 : Passer en Mode Production

• Jour 1-3 : MONITOR
• Semaine 2+ : PROTECTION (recommandé de façon permanente)

Meilleures Pratiques

Activation Progressive

1. Installez SeenSecure
2. Firewall OFF pendant 1 jour (valider la fonctionnalité)
3. Firewall MONITOR pendant 1 semaine (observer sans bloquer)
4. Firewall PROTECTION indéfiniment

Surveillance Continue

• Vérifiez les journaux 2-3 fois par semaine au début
• Ensuite, 1 fois par semaine
• Si vous voyez un nouveau modèle, enquêtez

Ajustements Selon le Type de Site

• Blog Simple : PROTECTION avec sensibilité moyenne
• E-commerce : PROTECTION avec sensibilité élevée sur /checkout
• SaaS : PROTECTION avec sensibilité très élevée
• Critique : STRICT pendant les heures d'exploitation

Communication aux Utilisateurs

Si le Firewall bloque un utilisateur légitime :

1. Il reçoit un message d'erreur descriptif
2. Cela explique qu'il a été bloqué pour des raisons de sécurité
3. Cela propose un contact de support

🔧 Résolution de Problèmes

Le Firewall a bloqué quelque chose de légitime (un plugin, un formulaire, un webhook)

Confirmez d'abord dans Firewall → Traffic Log que le blocage vient bien du Firewall (colonne "PROTECTION") et non d'une autre protection — le détail de cette ligne indique exactement quel motif a déclenché le blocage. Une fois confirmé :

• Si c'est un chemin ou un paramètre récurrent (un webhook, un endpoint de plugin) : ajoutez-le à la liste d'autorisation par chemin exact ou nom de paramètre, plutôt que de baisser la sensibilité générale — le reste de votre site reste ainsi tout aussi protégé.
• Si c'est un motif qui se déclenche trop souvent sur des formulaires normaux : baissez d'abord la Sensibilité d'un cran avant d'envisager de baisser le Mode global.
• Si vous devez vérifier sans risquer de bloquer quelqu'un pendant votre enquête : basculez temporairement le Mode global sur MONITOR — il continue à tout enregistrer dans le Traffic Log exactement pareil, mais ne bloque rien pendant que vous trouvez le bon réglage.

Je dois débloquer quelqu'un immédiatement

Ajoutez-le directement dans Firewall → Listes d'IP (liste blanche) : une IP en liste blanche a priorité absolue et contourne entièrement le Firewall, sans attendre l'expiration d'aucun blocage.

Questions Fréquentes

Quelle est la différence entre MONITOR et LEARNING ? Aucun des deux ne bloque : les deux se contentent d'enregistrer dans le Traffic Log ce qu'ils auraient bloqué. C'est la même phase d'observation avant de passer à PROTECTION.

PROTECTION et STRICT ne sont-ils pas identiques ? Non : STRICT applique une validation plus exigeante que PROTECTION, pour les sites à haut risque, au prix d'un risque de faux positif plus élevé si votre site a beaucoup de trafic ou des formulaires inhabituels.

Comment savoir si c'est le Firewall ou la Protection Anti-Bot qui a bloqué quelque chose ? Regardez la colonne "PROTECTION" dans le Traffic Log — elle indique exactement quel module a agi, pas besoin de deviner.

Puis-je avoir le Firewall dans un mode différent uniquement pour une partie du site (ex. /checkout) ? La liste d'autorisation fonctionne par chemin ou paramètre spécifique au sein du mode global actif, pas comme un mode indépendant par section du site.