Le pare-feu (firewall) demeure la première ligne de défense périmétrique de toute infrastructure connectée à Internet, mais son rôle a profondément changé. Un simple filtre de paquets qui décide selon l'adresse IP et le port ne suffit plus : la surface d'attaque actuelle exige une inspection avec état, un contrôle des applications de couche 7, une protection contre le déni de service et un modèle de confiance zéro. Dans ce guide technique, nous détaillons comment concevoir des règles d'ingress et d'egress robustes, quand ajouter un WAF et comment orchestrer la mitigation du DDoS sans étrangler le trafic légitime.
Types de pare-feu et la pile de filtrage
Un pare-feu opère sur une ou plusieurs couches du modèle OSI, et comprendre laquelle protège quoi évite les configurations redondantes ou, pire, les trous silencieux. Le filtrage de paquets sans état (couches 3 et 4) décide uniquement à partir des en-têtes IP/TCP/UDP ; il est rapide mais aveugle au contexte de la connexion. Le pare-feu avec état (stateful) maintient une table de connexions (conntrack sous Linux) et n'admet que les paquets appartenant à des sessions établies ou liées, ce qui neutralise la plupart du spoofing trivial.
Au-dessus se trouve le pare-feu de nouvelle génération (NGFW), qui ajoute l'inspection en profondeur des paquets (DPI), l'identification de l'application indépendamment du port et, souvent, un IPS intégré. Enfin, le Web Application Firewall (WAF) travaille exclusivement en couche 7 sur HTTP/HTTPS et comprend les paramètres, les en-têtes et les corps de requête. Une erreur fréquente consiste à attendre d'un NGFW qu'il arrête une injection SQL : le trafic est chiffré en TLS et, sans terminaison ni déchiffrement, le NGFW ne voit qu'un flux opaque. Cette fonction revient au WAF.
Conception des règles d'ingress : politique de refus par défaut
La règle d'or est le default deny : tout ce qui n'est pas explicitement autorisé est bloqué. En pratique, cela signifie fermer la chaîne INPUT et n'ouvrir que l'indispensable. Un squelette typique avec nftables serait :
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 uniquement depuis le VPN de l'entreprise
tcp dport { 80, 443 } accept # trafic web public
ip protocol icmp icmp type echo-request limit rate 5/second accept
}
}Trois principes soutiennent cette configuration. Premièrement, le moindre privilège : SSH n'est pas exposé à 0.0.0.0/0 mais à la plage du VPN. Deuxièmement, l'ordre d'évaluation : les règles sont évaluées séquentiellement, de sorte que celles de plus haute fréquence (connexions établies) figurent en tête pour réduire le coût en CPU. Troisièmement, la limitation de débit sur l'ICMP et les nouveaux SYN pour amortir les balayages et les floods. Documenter chaque règle avec sa justification métier est ce qui distingue une politique maintenable d'un fatras que personne n'ose toucher deux ans plus tard.
Egress filtering : le contrôle que presque personne ne configure
La plupart des organisations filtrent le trafic entrant et laissent la sortie entièrement ouverte. C'est une faute grave : le filtrage de l'egress est ce qui rompt la chaîne d'une attaque déjà en cours. Un serveur compromis a besoin de communiquer avec son serveur de commande et de contrôle (C2), d'exfiltrer des données ou de télécharger la deuxième phase du logiciel malveillant ; si la sortie est restreinte aux destinations et ports légitimes, l'attaquant reste confiné.
Une politique d'egress raisonnable pour un serveur d'applications autorise le DNS uniquement vers les résolveurs internes, le HTTPS vers le dépôt de paquets et l'API du fournisseur cloud, et le NTP vers les sources autorisées ; tout le reste est rejeté et journalisé. Bloquer les connexions sortantes vers des ports comme le 6667 (IRC, classique des botnets) ou un trafic TCP/53 inattendu révèle le tunneling DNS. L'egress filtering aide aussi à respecter 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 : protection de la couche applicative
Le WAF inspecte chaque requête HTTP au regard d'un ensemble de règles. Le standard de fait dans le monde ouvert est l'OWASP Core Rule Set (CRS), maintenu par la 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 avec un modèle de notation d'anomalies (anomaly scoring) : chaque correspondance ajoute des points et, lorsqu'un seuil est 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 de mode détection (niveau de paranoïa bas, journalisation seule) avant d'activer le blocage. Activer le CRS directement en production avec un 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 le suivant : déployer en détection, recueillir une semaine de trafic réel, affiner les exclusions par endpoint, et alors seulement passer à un blocage progressif en élevant le niveau de paranoïa.
Mitigation du DDoS par couches
Un pare-feu à lui seul n'arrête pas une attaque volumétrique qui sature le lien avant d'atteindre votre règle. La défense contre le DDoS s'organise selon la couche attaquée. Les attaques volumétriques (UDP flood, amplification NTP/DNS/memcached) se mitigent 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) se contiennent avec les SYN cookies, des limites de connexions par source et la table d'état du pare-feu lui-même. Les attaques de couche applicative (HTTP flood, Slowloris) requièrent le WAF, un rate limiting par session et des défis JavaScript ou CAPTCHA.
L'INCIBE recommande de combiner une protection distribuée en périphérie avec des plans de réponse documentés, car aucune défense unique ne couvre l'ensemble du spectre. Un schéma efficace consiste à déclarer des seuils de débit : par exemple, au maximum 100 nouvelles connexions par seconde et par IP, avec une bascule automatique en mode défi lorsqu'ils sont dépassés.
Segmentation du réseau et le modèle de confiance zéro
Le périmètre traditionnel, où tout ce qui était à l'intérieur était considéré comme de confiance et tout ce qui était à l'extérieur ne l'était pas, est mort 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 maîtresse, mais sa logique change : il cesse de protéger un unique périmètre pour faire appliquer une micro-segmentation entre les charges de travail.
La micro-segmentation divise le réseau en petites zones régies par des politiques strictes entre elles. Un serveur web de la zone démilitarisée (DMZ) peut dialoguer avec le serveur d'applications sur le port 8080, mais pas directement avec la base de données ; seul le serveur d'applications atteint la base de données sur le port 5432. Si le serveur web est compromis, l'attaquant ne peut pas se déplacer latéralement vers la base de données, car la règle est-ouest l'en empêche. Cette défense contre le mouvement latéral est ce qui limite la portée d'une intrusion, et c'est l'un des piliers que recueillent le cadre de cybersécurité du NIST et les contrôles de la famille ISO/IEC 27000 sur la ségrégation dans les réseaux.
Mettre en œuvre la micro-segmentation avec un pare-feu hôte (nftables, 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 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 pour que la politique soit versionnée, révisable et reproductible.
Journalisation, corrélation et réponse
Un pare-feu sans journalisation est un garde qui ne prend pas de notes. Chaque décision pertinente — surtout les rejets — 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 ; cent tentatives depuis la même IP vers cent ports différents en une minute constituent un balayage de ports qui mérite 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 respecter les obligations de traçabilité et de conservation des preuves, il convient de définir une politique de rétention cohérente avec les exigences légales et avec le guide de l'INCIBE sur la gestion des incidents. L'intégration du pare-feu avec le SIEM ferme 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 offensante 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 stateful | 3-4 | Paquets hors session, spoofing | Charges utiles malveillantes valides |
| NGFW / IPS | 3-7 | Signatures connues, applis indésirables | Trafic chiffré sans terminaison |
| WAF | 7 | Injection, XSS, HTTP flood | Attaques volumétriques réseau |
| Scrubbing en amont | 3-4 | DDoS volumétrique (Tbps) | Logique métier |
Erreurs courantes dans la configuration
La première est la règle « tout autoriser » temporaire qui reste pour toujours : une entrée de diagnostic qui ouvre un port à 0.0.0.0/0 et que personne ne révoque. La deuxième consiste à 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 drop, il est impossible d'enquêter sur un incident. La quatrième est le WAF en mode surveillance permanent qui détecte mais ne bloque jamais. Et la cinquième, laisser le plan de gestion (interface d'administration du pare-feu) accessible depuis Internet au lieu d'un réseau de gestion isolé.
Questions fréquentes
Un pare-feu stateful remplace-t-il un WAF ? Non. Ils opèrent sur des couches différentes. Le stateful 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 stateful la laisse passer et seul le WAF l'arrête.
Faut-il filtrer la sortie si je filtre déjà l'entrée ? Oui, ce sont des objectifs différents. L'ingress évite les intrusions ; l'egress contient une machine déjà compromise et empêche l'exfiltration et la communication avec les serveurs C2. C'est une exigence habituelle dans les audits ISO/IEC 27001 et les cadres de conformité.
Convient-il de terminer le TLS sur le pare-feu pour l'inspecter ? Cela dépend. La terminaison permet au WAF de voir le contenu, mais introduit un point où le trafic circule déchiffré et oblige à gérer les certificats avec rigueur. Dans les environnements traitant des données personnelles, il faut évaluer l'impact au regard du RGPD et documenter le traitement.
À quelle fréquence révise-t-on les règles ? Au moins une fois par trimestre, et toujours après des changements d'architecture. Les révisions détectent les règles obsolètes, les chevauchements et les autorisations 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 couches où chaque contrôle fait ce qu'il sait faire : le pare-feu stateful valide la session, l'egress filtering contient la fuite, le WAF protège l'application et le scrubbing en amont absorbe le volume. Le facteur qui décide du résultat n'est pas la technologie, mais la discipline opérationnelle : politique de refus par défaut, journalisation exhaustive des rejets, déploiement du WAF en détection avant le blocage et 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 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 le passage en production.