Un pare-feu bien configuré combine un filtrage à état avec une politique d'entrée de refus par défaut (default-deny), un filtrage de sortie pour contenir les hôtes déjà compromis, un WAF exécutant l'OWASP Core Rule Set au niveau de la couche applicative, et une mitigation DDoS en couches. Aucun contrôle n'en remplace un autre : le filtrage à état laisse passer une injection SQL puisque seul le WAF inspecte le HTTP ; les règles doivent être révisées au moins chaque trimestre.
Le pare-feu reste la première ligne de défense périmétrique de toute infrastructure connectée à internet, mais son rôle a profondément évolué. Un filtre de paquets qui décide uniquement sur la base de l'adresse IP et du port ne suffit plus : la surface d'attaque actuelle exige une inspection à état, un contrôle applicatif de couche 7, une protection contre le déni de service et un modèle zero trust. Dans ce guide technique, nous expliquons comment concevoir des règles d'entrée et de sortie robustes, quand ajouter un WAF et comment orchestrer la mitigation DDoS sans étouffer le trafic légitime.
Types de pare-feu et pile de filtrage
Un pare-feu opère à un ou plusieurs niveaux du modèle OSI, et comprendre lequel protège quoi évite les configurations redondantes ou, pire, des failles silencieuses. Le filtrage de paquets sans état (couches 3 et 4) décide uniquement sur la base des en-têtes IP/TCP/UDP ; il est rapide mais aveugle au contexte de la connexion. Le pare-feu à état maintient une table de connexions (conntrack sous Linux) et n'admet que les paquets appartenant à des sessions établies ou associées, ce qui neutralise la plupart des usurpations triviales.
Au-dessus, on trouve le pare-feu de nouvelle génération (NGFW), qui ajoute une inspection approfondie des paquets (DPI), une identification des applications indépendante du port et, souvent, un IPS intégré. Enfin, le Web Application Firewall (WAF) agit exclusivement au niveau de la couche 7, sur HTTP/HTTPS, et comprend les paramètres, en-têtes et corps des requêtes. Une erreur fréquente est d'attendre d'un NGFW qu'il arrête une injection SQL : le trafic circule chiffré en TLS et, sans terminaison ni déchiffrement, le NGFW ne voit qu'un flux opaque. Cette tâche revient au WAF.
Concevoir les règles d'entrée : la politique default-deny
La règle d'or est le default deny (refus par défaut) : tout ce qui n'est pas explicitement autorisé est bloqué. En pratique, cela signifie fermer la chaîne INPUT et n'ouvrir que l'essentiel. Un squelette type avec nftables serait le suivant :
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
iif "lo" accept
ct state invalid drop
tcp dport 22 ip saddr 203.0.113.0/24 accept # SSH only from the corporate VPN
tcp dport { 80, 443 } accept # public web traffic
ip protocol icmp icmp type echo-request limit rate 5/second accept
}
}Trois principes sous-tendent cette configuration. D'abord, le moindre privilège : le SSH n'est pas exposé à 0.0.0.0/0 mais à la plage VPN. Ensuite, l'ordre d'évaluation : les règles sont évaluées séquentiellement, donc les plus fréquentes (connexions établies) sont placées en tête pour réduire le coût CPU. Enfin, la limitation de débit (rate limiting) sur l'ICMP et les nouveaux paquets SYN pour amortir les balayages et les inondations. Documenter chaque règle avec sa justification métier est ce qui distingue une politique maintenable d'un enchevêtrement que personne n'ose plus toucher deux ans plus tard.
Le filtrage de sortie : le contrôle que presque personne ne configure
La plupart des organisations filtrent le trafic entrant et laissent la direction sortante complètement ouverte. C'est une faille sérieuse : le filtrage de sortie est ce qui coupe la chaîne d'une attaque déjà en cours. Un serveur compromis a besoin de communiquer avec son serveur de commande et contrôle (C2), d'exfiltrer des données ou de télécharger la deuxième étape du malware ; si le trafic sortant est restreint à des destinations et des ports légitimes, l'attaquant est contenu.
Une politique de sortie raisonnable pour un serveur applicatif n'autorise le DNS que vers les résolveurs internes, le HTTPS vers le dépôt de paquets et l'API du fournisseur cloud, et le NTP vers des sources autorisées ; tout le reste est rejeté et journalisé. Bloquer les connexions sortantes vers des ports tels que 6667 (IRC, un classique des botnets) ou un trafic TCP/53 inattendu révèle du tunneling DNS. Le filtrage de sortie contribue aussi à satisfaire le principe de minimisation de la norme ISO/IEC 27001 dans son contrôle de sécurité des communications (A.8.20 et suivants de l'Annexe A de la révision 2022).
WAF : protéger la couche applicative
Le WAF inspecte chaque requête HTTP selon un ensemble de règles. La norme de facto dans le monde open source est l'OWASP Core Rule Set (CRS), maintenue par l'OWASP Foundation, qui couvre les catégories de l'OWASP Top 10 : injection, cross-site scripting, désérialisation non sécurisée, etc. Le CRS fonctionne sur un modèle de scoring d'anomalies : chaque correspondance ajoute des points et, une fois un seuil dépassé, la requête est bloquée. Cela réduit les faux positifs par rapport à un blocage règle par règle.
Le déploiement d'un WAF doit toujours passer par une phase en mode détection (niveau de paranoïa bas, journalisation uniquement) avant d'activer le blocage. Activer le CRS directement en production au niveau de paranoïa 4 garantit des tickets de support dès le premier jour, car des requêtes légitimes contenant des caractères spéciaux sont rejetées. Le flux correct est : déployer en détection, collecter une semaine de trafic réel, affiner les exclusions par endpoint, et ensuite seulement passer à un blocage progressif en augmentant le niveau de paranoïa.
Mitigation DDoS en couches
Un pare-feu seul n'arrête pas une attaque volumétrique qui sature le lien avant même d'atteindre votre règle. La défense DDoS s'organise par la couche attaquée. Les attaques volumétriques (UDP flood, amplification NTP/DNS/memcached) sont mitigées en amont, chez le fournisseur ou dans un service de scrubbing dont la capacité d'absorption se mesure en Tbps. Les attaques de protocole (SYN flood, Ping of Death) sont contenues avec des cookies SYN, des limites de connexions par source et la propre table d'état du pare-feu. Les attaques de couche applicative (HTTP flood, Slowloris) nécessitent le WAF, une limitation de débit par session et des défis JavaScript ou CAPTCHA.
INCIBE recommande de combiner une protection distribuée en périphérie avec des plans de réponse documentés, car aucune défense isolée ne couvre l'ensemble du spectre. Un schéma efficace consiste à déclarer des seuils de débit : par exemple, un maximum de 100 nouvelles connexions par seconde et par IP, avec une escalade automatique vers un mode défi lorsqu'ils sont dépassés.
Segmentation réseau et modèle zero trust
Le périmètre traditionnel, où tout ce qui se trouvait à l'intérieur était considéré comme fiable et tout ce qui était à l'extérieur ne l'était pas, a disparu avec le cloud hybride et le télétravail. Le modèle Zero Trust part d'un principe différent : ne jamais faire confiance, toujours vérifier. Chaque requête, d'où qu'elle vienne, est authentifiée et autorisée comme si elle provenait d'un réseau hostile. Le pare-feu reste une pièce clé, mais sa logique change : il cesse de protéger un périmètre unique et commence à appliquer la microsegmentation entre les charges de travail.
La microsegmentation divise le réseau en petites zones avec des politiques strictes entre elles. Un serveur web situé dans la zone démilitarisée (DMZ) peut communiquer avec le serveur applicatif sur le port 8080, mais pas directement avec la base de données ; seul le serveur applicatif accède à la base de données sur le port 5432. Si le serveur web est compromis, l'attaquant ne peut pas rebondir latéralement vers la base de données, car la règle est-ouest l'en empêche. Cette défense contre les mouvements latéraux est ce qui limite la portée d'une intrusion, et c'est l'un des piliers énoncés dans le cadre de cybersécurité du NIST et dans les contrôles de la famille ISO/IEC 27000 relatifs à la ségrégation réseau.
Mettre en œuvre la microsegmentation avec un pare-feu hôte (nftables, la Windows Filtering Platform) ou avec des politiques réseau dans les orchestrateurs de conteneurs permet d'appliquer la règle du moindre privilège au niveau du processus, et pas seulement au niveau du sous-réseau. Le coût est la complexité opérationnelle : maintenir des centaines de règles est-ouest exige de l'automatisation et de l'infrastructure as code afin que la politique soit versionnée, révisable et reproductible.
Journalisation, corrélation et réponse
Un pare-feu sans journalisation est un gardien qui ne prend aucune note. Chaque décision pertinente — en particulier les rejets (drops) — doit être envoyée à un système centralisé de gestion des événements de sécurité (SIEM), où elle est corrélée avec d'autres sources. Une seule tentative de connexion bloquée ne signifie rien ; une centaine de tentatives depuis la même IP vers une centaine de ports différents en une minute est un balayage de ports qui justifie une alerte. La corrélation est ce qui transforme le bruit en renseignement exploitable.
Les journaux doivent inclure un horodatage synchronisé par NTP, l'IP source et destination, le port, le protocole, la règle appliquée et l'action. Pour répondre aux obligations de traçabilité et de conservation des preuves, il est conseillé de définir une politique de rétention conforme aux exigences légales et aux recommandations de l'INCIBE en matière de gestion des incidents. Intégrer le pare-feu au SIEM referme la boucle : détection, alerte et, dans les architectures matures, réponse automatisée qui met à jour dynamiquement les règles pour bloquer une IP fautive pendant une attaque en cours.
Tableau comparatif : où agit chaque contrôle
| Contrôle | Couche OSI | Arrête | N'arrête pas |
|---|---|---|---|
| Filtre de paquets | 3-4 | IP/port non autorisés | Attaques applicatives |
| Pare-feu à état | 3-4 | Paquets hors session, usurpation | Charges utiles malveillantes valides |
| NGFW / IPS | 3-7 | Signatures connues, applications indésirables | Trafic chiffré sans terminaison |
| WAF | 7 | Injection, XSS, HTTP flood | Attaques réseau volumétriques |
| Scrubbing en amont | 3-4 | DDoS volumétrique (Tbps) | Logique métier |
Erreurs de configuration courantes
La première est la règle temporaire « allow all » qui reste pour toujours : une entrée de diagnostic qui ouvre un port vers 0.0.0.0/0 et que personne ne révoque. La deuxième est de se fier uniquement à l'IP source pour authentifier, en ignorant qu'elle peut être usurpée ou provenir d'un proxy. La troisième est de ne pas journaliser les rejets : sans journaux des règles de rejet, il est impossible d'investiguer un incident. La quatrième est le WAF en mode surveillance permanente qui détecte mais ne bloque jamais. Et la cinquième est de laisser le plan de gestion (l'interface d'administration du pare-feu) accessible depuis internet au lieu de le placer sur un réseau de gestion isolé.
Questions fréquentes
Un pare-feu à état remplace-t-il un WAF ? Non. Ils opèrent à des niveaux différents. Le pare-feu à état valide que la connexion est légitime au niveau réseau et transport ; le WAF analyse le contenu HTTP. Une injection SQL voyage à l'intérieur d'une connexion TCP parfaitement valide, donc le pare-feu à état la laisse passer et seul le WAF l'arrête.
Dois-je filtrer le trafic sortant si je filtre déjà le trafic entrant ? Oui, ce sont des objectifs différents. Le filtrage entrant prévient les intrusions ; le filtrage sortant contient un hôte déjà compromis et empêche l'exfiltration et la communication avec des serveurs C2. C'est une exigence courante des audits ISO/IEC 27001 et des référentiels de conformité.
Est-il utile de terminer le TLS au niveau du pare-feu pour l'inspecter ? Cela dépend. La terminaison permet au WAF de voir le contenu, mais elle introduit un point où le trafic circule déchiffré et vous oblige à gérer les certificats rigoureusement. Dans les environnements traitant des données personnelles, vous devez évaluer l'impact au regard du RGPD et documenter le traitement.
À quelle fréquence faut-il réviser les règles ? Au moins chaque trimestre, et toujours après un changement d'architecture. Les révisions détectent les règles obsolètes, les chevauchements et les permissions trop larges qui s'accumulent avec le temps.
Conclusion
Configurer un pare-feu aujourd'hui ne consiste pas à écrire une liste de ports ouverts, mais à orchestrer une défense en profondeur où chaque contrôle fait ce qu'il fait de mieux : le pare-feu à état valide la session, le filtrage de sortie contient la fuite, le WAF protège l'application et le scrubbing en amont absorbe le volume. Le facteur qui détermine le résultat n'est pas la technologie mais la discipline opérationnelle : une politique default-deny, une journalisation exhaustive des rejets, le déploiement du WAF en détection avant blocage, et des révisions périodiques qui élaguent les règles mortes. Un pare-feu bien gouverné est transparent pour l'utilisateur légitime et un mur infranchissable pour tous les autres. Chez Summum Marketing, nous concevons et déployons ces politiques adaptées à chaque architecture, en mesurant toujours l'impact sur le trafic réel avant la mise en production.