Le principe qui gouverne tout le reste
Tout ce qui n’est pas explicitement autorisé doit être interdit. C’est la politique par défaut de tout dispositif de filtrage réseau sérieux, et le fil conducteur de cette note.
Ce qu’il faut savoir avant de configurer
Les pare-feu classiques filtrent surtout aux couches 3/4 (IP/port) ; les NGFW inspectent jusqu’à la couche 7 (application, protocole). Sur TCP, l’état de connexion (SYN, SYN/ACK, ACK) et les ports éphémères se suivent dans une table d’états (conntrack) ; UDP, n’ayant pas d’état natif, ne peut être suivi que par un pseudo-état reconstruit à partir du chronométrage et des flux observés.
L’ordre des règles compte : du plus spécifique au plus général, en pensant toujours au sens du flux et, en filtrage sans état, à la règle de retour. Le NAT, enfin, ne sécurise rien par lui-même — il faut séparer la politique de traduction d’adresses de la politique de sécurité proprement dite. Sur la fragmentation, la prudence s’impose : les fragments IP sont un vecteur d’évasion classique, et il faut ajuster la MSS dans tout tunnel pour l’éviter.
Les grandes familles de pare-feu
Stateless (ACL, filtres)
Un pare-feu stateless compare chaque paquet indépendamment des autres, selon une liste de règles. Sans machine à états, un filtrage fin devient difficile, et il faut explicitement ouvrir les ports de retour pour laisser passer les réponses. On le rencontre surtout sur des routeurs ou des systèmes legacy, en amont d’un dispositif plus intelligent — typiquement pour « dégrossir » le trafic avant une inspection plus poussée (des security groups simples, par exemple, avant une inspection profonde).
Stateful
Un pare-feu stateful garde en mémoire l’état des connexions, et n’autorise les paquets de réponse que s’ils appartiennent à un flux connu. Commercialisé dès 1993 (Check Point), c’est aujourd’hui la base de tout déploiement sérieux — plus sûr, avec une traçabilité pertinente, au prix d’un coût et d’une latence légèrement supérieurs au stateless.
NGFW (Next-Generation Firewall)
Le NGFW va au-delà des ports et protocoles : DPI (Deep Packet Inspection, inspection jusqu’à la couche applicative), reconnaissance applicative indépendante du port, IPS intégré, politiques fondées sur l’identité (utilisateur, groupe, emplacement, contenu), inspection TLS, et intégration de renseignement sur les menaces (flux tiers, partage communautaire).
Trois points méritent une attention particulière. Le User-ID permet des politiques par utilisateur, et non plus seulement par IP. L’inspection TLS/SSL est gourmande en CPU — il faut la dimensionner (cartes dédiées, déchiffrement sélectif, exclusions pour la banque et la santé). L’IPS intégré détecte et bloque des motifs et comportements suspects, par signatures ou heuristique.
WAF (Web Application Firewall)
Le WAF est spécialisé HTTP/HTTPS, placé devant une application web. Il examine requêtes et réponses selon des politiques (OWASP Top 10, injection, XSS), peut terminer le TLS, chiffrer les cookies, et prévenir les fuites de données. Il s’implémente en logiciel (ModSecurity) ou en appliance.
Un rappel volontairement provocateur
« Si tu vois un WAF, c’est que les développeurs n’ont pas fait leur travail ! » — la morale n’est pas de se passer de WAF, mais de comprendre qu’il complète la sécurité applicative, il ne la remplace jamais.
Ses fonctions typiques : prise en charge de l’OWASP Top 10, modes bloquer/autoriser/alerter/journaliser, prévention de l’exfiltration, terminaison TLS, protection des jetons de session, gestion des certificats. Il protège notamment contre l’injection SQL, le cross-site scripting, l’inclusion de fichiers et le cross-site request forgery.
DMZ, IDS et IPS
La zone démilitarisée
L’objectif d’une DMZ est de protéger le LAN : un serveur en DMZ ne doit presque jamais initier de connexion vers le LAN — pas de SSH ou d’accès hors bande direct. Si un accès à une base interne est indispensable, on le limite idéalement à la lecture seule ; si une écriture est nécessaire, elle passe par des flux dédiés, une authentification forte, un WAF ou un proxy en frontal, des ACL très fines, et une journalisation systématique.
IDS contre IPS
L’IDS détecte et alerte ; l’IPS bloque en ligne. Dans un NGFW moderne, l’IPS est généralement intégré.
Déploiement et bonnes pratiques
Tous ces dispositifs existent en appliance (périmètre) ou en logiciel (poste de travail) — mais un pare-feu logiciel n’est pas un WAF : il ne faut pas confondre le plan réseau et la logique applicative.
Les principes qui structurent un déploiement solide : default-deny impératif, micro-segmentation, journaux horodatés, règles nommées et commentées, revues périodiques. Sur le déchiffrement TLS, commencer petit (groupes pilotes), prévoir un contournement pour les flux sensibles (banque, santé), et planifier la capacité de traitement en conséquence. Le change management suppose des fenêtres de mise en production, un plan de retour arrière, une sauvegarde des configurations, et des tests de non-régression. Enfin, la surveillance continue — compteurs de correspondance, latence, CPU, raisons de rejet, qualité d’ouverture et de fermeture des sessions — est ce qui distingue un pare-feu correctement exploité d’un pare-feu simplement déployé.
flowchart LR C[Clients Internet] --> RP[Reverse Proxy/WAF en DMZ] RP --> APP1[App 1] RP --> APP2[App 2] APP1 -."flux contrôlés".- DB[(Base interne)]
Pour une publication web typique, on retiendra : reverse proxy avec terminaison TLS, WAF sur les routes sensibles (/login, /api), mTLS vers le backend le plus critique, HSTS, et limitation de débit.