infra / reseaux-tcp-ip
Pare-feu et filtrage de paquets
Explication
Ce que vous allez apprendre
- Comprendre les trois chaînes de règles d'un pare-feu (INPUT, OUTPUT, FORWARD) et leur rôle respectif
- Distinguer un filtrage stateless d'un filtrage stateful et comprendre pourquoi ce dernier a gagné
- Écrire des règles de pare-feu avec
nftablesen autorisant explicitement ce qui est nécessaire - Limiter le débit d'un type de trafic pour se protéger d'un brute-force ou d'un flood
- Comprendre pourquoi un pare-feu réseau classique ne protège pas contre les attaques applicatives (SQLi, XSS)
Dans quel contexte ?
Un administrateur système durcit un serveur fraîchement provisionné avant sa mise en production. Il doit tout bloquer par défaut, n'autoriser que le strict nécessaire (SSH, HTTP, HTTPS), et limiter le débit sur le port SSH pour se prémunir d'une attaque par force brute automatisée. Une seule règle mal écrite (une politique par défaut à accept au lieu de drop, par exemple) peut laisser toute la surface d'attaque du serveur exposée sans qu'il s'en aperçoive.
Le gardien qui décide qui entre et qui sort
Un pare-feu applique une décision simple pour chaque paquet réseau : le laisser passer ou le rejeter, selon des règles définies à l'avance. C'est le mécanisme de contrôle d'accès le plus fondamental d'une infrastructure réseau, une sorte de videur qui vérifie chaque paquet avant de le laisser entrer, sortir, ou traverser la machine.
| Chaîne | Trafic concerné |
|---|---|
| INPUT | Entrant, destiné à la machine elle-même |
| OUTPUT | Sortant, émis depuis la machine elle-même |
| FORWARD | Traverse la machine (cas d'un routeur/pare-feu réseau) |
Bonne pratique
Configure toujours une politique par défaut restrictive (policy drop) sur la chaîne INPUT, puis autorise explicitement chaque service nécessaire (SSH, HTTP...). C'est bien plus sûr que l'inverse : partir d'une politique permissive en espérant bloquer "ce qu'il faut" au fur et à mesure, au risque d'oublier une règle.
Trois destinations, trois chaînes de règles
Un pare-feu distingue généralement le trafic qui arrive pour la machine elle-même, celui qui en repart, et celui qui ne fait que la traverser (cas d'un routeur ou d'un pare-feu réseau dédié). Cette distinction permet des politiques différentes selon le rôle : une machine peut vouloir tout accepter en sortie mais être très restrictive en entrée, par exemple.
Stateless vs stateful : se souvenir ou pas
Un filtrage "stateless" juge chaque paquet isolément, sans mémoire du contexte — ce qui oblige à écrire des règles pour chaque sens de communication séparément. Un filtrage "stateful" retient l'état des connexions en cours : une réponse à une connexion sortante autorisée est acceptée automatiquement, sans règle supplémentaire. C'est cette approche, bien plus pratique et sécurisée, qui est devenue le standard.
Le pare-feu réseau ne voit pas tout
Un pare-feu classique travaille au niveau IP et port : il ne comprend pas le contenu d'une requête HTTP. Une attaque cachée dans le contenu d'une requête légitime (comme une injection SQL) passera sans problème un pare-feu réseau classique. C'est pour cela qu'un WAF (pare-feu applicatif) intervient à un niveau supérieur, en complément et non en remplacement du pare-feu réseau.
Commandes & code
Pare-feu et filtrage de paquets
# Un pare-feu filtre le trafic selon des règles, en général organisées en 3 chaînes :
# INPUT -> trafic entrant destiné À la machine elle-même
# OUTPUT -> trafic sortant DEPUIS la machine elle-même
# FORWARD -> trafic qui TRAVERSE la machine (cas d'un routeur/pare-feu réseau)
# Deux approches de filtrage
# Stateless : chaque paquet est jugé isolément (rapide, mais rudimentaire)
# Stateful : le pare-feu retient l'état des connexions (une réponse à une connexion
# sortante autorisée est acceptée automatiquement) -> approche moderne standard# Pare-feu stateful avec nftables (voir aussi la leçon Linux dédiée pour un exemple complet)
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input ct state invalid drop
sudo nft add rule inet filter input iif lo accept
sudo nft add rule inet filter input tcp dport 22 accept
sudo nft add rule inet filter input tcp dport { 80, 443 } accept
# Filtrage par zone/interface (pare-feu réseau typique entre LAN, DMZ, WAN)
sudo nft add rule inet filter forward iifname "lan0" oifname "wan0" accept # LAN -> Internet OK
sudo nft add rule inet filter forward iifname "wan0" oifname "lan0" ct state established,related accept
sudo nft add rule inet filter forward iifname "dmz0" oifname "lan0" drop # DMZ ne joint jamais le LAN
# Filtrage applicatif basique (au-delà du simple port) : limiter le débit, éviter un flood
sudo nft add rule inet filter input tcp dport 22 limit rate 5/minute accept # anti brute-force SSH
sudo nft add rule inet filter input icmp type echo-request limit rate 10/second accept # anti ping flood
# WAF / proxy applicatif (couche 7) : filtre le contenu HTTP, pas seulement IP/port
# Exemple : ModSecurity devant nginx, ou un WAF cloud (Cloudflare, AWS WAF)
# -> bloque des patterns d'attaque (injection SQL, XSS) que le pare-feu réseau ne voit pas
# Vérifier les règles actives et compter les paquets matchés (debug)
sudo nft list ruleset -a
sudo nft -a list chain inet filter input # -a affiche le handle de chaque règle (pour la cibler/supprimer)| Type de pare-feu | Couche OSI | Exemple |
|---|---|---|
| Filtrage de paquets stateless | 3-4 | ACL simple sur un routeur |
| Stateful firewall | 3-4 | iptables/nftables, pfSense |
| Proxy applicatif / WAF | 7 | ModSecurity, Cloudflare WAF |
Résumé
- INPUT/OUTPUT/FORWARD couvrent respectivement le trafic reçu, émis, et traversant la machine.
- Un pare-feu stateful (
ct state established,related) est le standard : il évite de devoir écrire une règle pour chaque sens. - Un pare-feu réseau (couches 3-4) ne voit pas le contenu applicatif : un WAF (couche 7) complète pour filtrer le contenu HTTP.
Exercices pratiques
Mission : durcir un serveur fraîchement provisionné
Objectif : Passer d'une politique par défaut permissive à un pare-feu stateful restrictif, en limitant le débit sur les services sensibles.
Contexte
Un serveur fraîchement provisionné a sa chaîne INPUT en politique par défaut accept, avec seulement quelques règles DROP ponctuelles pour bloquer des IP connues comme malveillantes. Avant sa mise en production, tu dois inverser cette logique et protéger le port SSH contre le brute-force.