🔥 Firewall — types, NAT et règles de filtrage

Introduction (10 min)

En 2019, la fuite de données chez Capital One a montré que même des protections en apparence avancées (WAF, contrôles cloud) sont inefficaces si elles sont mal configurées ou si des privilèges sont trop larges. Une mauvaise règle applicative ou un rôle IAM trop permissif ont permis l'exfiltration d'environ 106 millions d'enregistrements clients. Cette séance pose les fondements techniques : quels types de firewalls existent, pourquoi adopter une politique default-deny et comment NAT/PAT et règles de filtrage s'articulent pour limiter la surface d'attaque. Nous illustrerons chaque concept par des exemples concrets applicables à la PME fil rouge InnovatTech.

🎯 Objectifs de la séance

• Expliquer et différencier les types de firewalls (stateless, stateful, NGFW, WAF) et leur mode d'action.
• Concevoir des règles de filtrage basées sur la 5-tuple et le principe default-deny, et les traduire en commandes iptables/nftables.
• Écrire et vérifier un jeu de règles nftables fonctionnel sur Debian 12 pour un serveur de production.

1. Types de firewalls (70 min)

Les firewalls se distinguent par le niveau d'inspection et l'état qu'ils conservent.

1.1 Stateless packet filter

Le pare-feu stateless examine chaque paquet indépendamment : il compare les champs (5-tuple) au moment de la réception et applique une règle ACCEPT/DROP sans conserver d'historique de connexion. C'est simple et rapide mais inadapté aux protocoles qui utilisent des ports dynamiques ou aux sessions nécessitant un suivi d'état.

# Autoriser HTTP entrant (stateless) — ne gère pas les connexions établies
sudo iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT

1.2 Stateful inspection (connection tracking)

Le pare-feu stateful conserve une table d'état (connection tracking) qui enregistre les connexions avec leurs états : NEW / ESTABLISHED / RELATED / INVALID. Cela permet par exemple d'autoriser les réponses aux connexions initiées depuis l'intérieur (ESTABLISHED) tout en bloquant les tentatives d'initiation non autorisées depuis l'extérieur.

# Autoriser paquets liés/établis
sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Autoriser SSH nouveau depuis le VLAN Administration
sudo iptables -A INPUT -p tcp -s 192.168.10.0/24 --dport 22 -m conntrack --ctstate NEW -j ACCEPT

# Politique par défaut : drop
sudo iptables -P INPUT DROP

La table de connexion peut être consultée (si conntrack-tools est installé) :

sudo conntrack -L  # liste les connexions suivies

1.3 NGFW / UTM (Next-Generation Firewall / Unified Threat Management)

Les NGFW combinent inspection au niveau réseau et applicatif : contrôle applicatif, identification des utilisateurs, Deep Packet Inspection (DPI) pour analyser le contenu (HTTP, TLS), et parfois IPS intégré pour bloquer des signatures réseau. Ils opèrent souvent inline (bloquent en temps réel) et peuvent effectuer du TLS inspection (avec impact sur la confidentialité).

Cas d'usage : blocage d'exfiltration via détection de patterns dans le payload, limitation d'applications cloud par utilisateur ou device.

1.4 WAF (Web Application Firewall)

Le WAF opère au niveau applicatif (couche 7) : il analyse les requêtes HTTP(S) pour détecter injections SQL, XSS, path traversal, etc. Un WAF mal configuré (règles trop permissives) peut laisser passer des requêtes malveillantes — c'est précisément ce qui a contribué à l'incident Capital One.

Comparaison récapitulative

2. Principe "default-deny" et logging (20 min)

Le principe default-deny consiste à refuser tout trafic sauf les exceptions explicitement autorisées. Sur un firewall moderne, on applique une politique par défaut DROP (ou REJECT si on souhaite notifier l'émetteur) et l'on pose des règles de moindre privilège.

• Avantages : réduction de la surface d'attaque, traces exploitables dans les logs.
• Inconvénients : nécessité d'une bonne transition en production (test progressif, monitoring des logs avant activation).

# Accepter les paquets liés/établis
sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Autoriser SSH depuis le VLAN Administration
sudo iptables -A INPUT -p tcp -s 192.168.10.0/24 --dport 22 -m conntrack --ctstate NEW -j ACCEPT

# Loguer les paquets restants avant drop (limiter le débit de logs)
sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "FW DROP: " --log-level 4

# Politique par défaut
sudo iptables -P INPUT DROP

Les logs apparaissent ensuite dans /var/log/kern.log ou via journalctl -k | grep "FW DROP" selon la configuration système.

3. NAT / PAT (30 min)

NAT (Network Address Translation) traduit des adresses entre réseaux. Les usages courants :

• Source NAT (SNAT) / Masquerade : traduire l'adresse source des hôtes internes en une IP publique pour accéder à Internet.
• PAT (Port Address Translation) : forme de SNAT many-to-one où les connexions de plusieurs hôtes partagent une même IP publique via des ports source différents (souvent réalisé automatiquement par MASQUERADE).
• Destination NAT (DNAT) / port forwarding : rediriger un port public vers une IP privée (publication de services).

# Masquerade (PAT) : LAN → Internet (IP publique dynamique)
sudo iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE

# SNAT avec IP publique fixe
sudo iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j SNAT --to-source 91.208.45.12

# DNAT / port forward HTTP depuis l'IP publique vers un serveur en DMZ
sudo iptables -t nat -A PREROUTING -p tcp -d 91.208.45.12 --dport 80 -j DNAT --to-destination 192.168.30.5:80
sudo iptables -A FORWARD -p tcp -d 192.168.30.5 --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Vérification des règles NAT :

sudo iptables -t nat -L -n -v
sudo iptables -L -n -v

4. Règles de filtrage : la 5-tuple et direction (30 min)

Une règle de filtrage repose sur la 5-tuple : protocole, adresse source, port source, adresse destination, port destination. À cela s'ajoutent des critères pratiques : interface d'entrée (ingress) ou de sortie (egress), VLAN source, et état de connexion.

# Accepter les connexions TCP du VLAN Utilisateurs (20) vers le serveur web en DMZ
sudo iptables -A FORWARD \
  -p tcp \
  -s 192.168.20.0/24 --sport 1024:65535 \
  -d 192.168.30.5    --dport 80 \
  -m conntrack --ctstate NEW,ESTABLISHED \
  -j ACCEPT

Ingress vs Egress

Logging avant DROP

Ajouter une règle LOG avant la règle DROP permet d'analyser les tentatives bloquées :

sudo iptables -A INPUT -m limit --limit 3/min -j LOG --log-prefix "IN DROP: " --log-level 4
sudo iptables -A INPUT -j DROP

5. Concepts iptables (10 min)

• Tables principales : filter (filtrage), nat (translation d'adresses), mangle (modifications spéciales), raw (pré-traitement pour conntrack).
• Chaînes usuelles : INPUT (paquets destinés à la machine locale), OUTPUT (paquets générés localement), FORWARD (paquets transitant par la machine).
• Cibles : ACCEPT, DROP, REJECT, LOG, DNAT, SNAT.

Extrait de iptables-save (exemple commenté) :

# iptables-save output (extrait)
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -s 192.168.10.0/24 --dport 22 -m conntrack --ctstate NEW -j ACCEPT
COMMIT

🗺️ Schéma : placement d'un firewall / DMZ

          Internet
             │
         [pfSense]  ← 91.208.45.12 (WAN)
          /   \
    DMZ /     \ LAN
192.168.30.0/24  192.168.10.0/24
  [debian-srv02]   [debian-srv01]
  192.168.30.5      192.168.10.10

🔧 Travaux Pratiques (70 min)

Contexte

Vous êtes technicien chez InnovatTech SARL. Le responsable vous demande de renforcer la posture d'un serveur de services (debian-srv01, bastion) en écrivant un jeu de règles strictes au niveau hôte pour limiter la surface d'attaque.

Objectif

Rédiger et appliquer un jeu de règles nftables sur debian-srv01 qui :

• Autorise SSH uniquement depuis le VLAN Administration (192.168.10.0/24).
• Autorise les connexions HTTP/HTTPS sortantes (ports 80 et 443).
• Autorise ICMP (ping) entrant et sortant.
• Logue et DROPpe tout le reste.

Prérequis techniques

• Accès root à debian-srv01 (192.168.10.10) via console ou SSH depuis le VLAN Admin.
• Debian 12, package nftables installé (apt install nftables).

Étape 1 — Sauvegarder la configuration existante

sudo cp /etc/nftables.conf /etc/nftables.conf.bak || true
sudo nft list ruleset > ~/nft-ruleset-before.txt

Étape 2 — Créer /etc/nftables.conf

sudo tee /etc/nftables.conf > /dev/null <<'EOF'
#!/usr/sbin/nft -f

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Autoriser connexions liées/établies
        ct state established,related accept

        # Loopback
        iif "lo" accept

        # SSH depuis VLAN Admin uniquement
        ip saddr 192.168.10.0/24 tcp dport 22 ct state new accept

        # ICMP (ping)
        ip protocol icmp accept

        # Log et drop le reste
        log prefix "NFT-INPUT-DROP: " flags all
        drop
    }

    chain output {
        type filter hook output priority 0; policy drop;

        oif "lo" accept

        # HTTP/HTTPS sortant
        ip daddr 0.0.0.0/0 tcp dport {80,443} ct state new,established accept

        # ICMP sortant
        ip protocol icmp accept

        # Log et drop le reste
        log prefix "NFT-OUTPUT-DROP: " flags all
        drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}
EOF

Étape 3 — Activer et recharger nftables

sudo systemctl enable --now nftables
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

Étape 4 — Vérifications

• Depuis une machine du VLAN Admin (192.168.10.0/24) :
  ssh admin@192.168.10.10 doit réussir.
• Depuis une machine hors VLAN Admin :
  ssh admin@192.168.10.10 doit être refusé (connexion impossible).
• HTTP/HTTPS sortant sur debian-srv01 :
  curl -I https://example.com doit retourner un code 200/3xx.
• Consulter les logs :
  sudo journalctl -k | grep NFT-INPUT-DROP ou sudo dmesg | grep NFT-INPUT-DROP
• Lister les règles :
  sudo nft list ruleset

Livrable attendu

• /etc/nftables.conf complet sur debian-srv01 (copie dans le dépôt de TP ou archive).
• Un court rapport (1 page) indiquant les commandes de vérification exécutées et captures de sorties (ssh réussi/échoué, curl, nft list ruleset, logs montrant des DROP).

Critères de réussite

• SSH accessible uniquement depuis 192.168.10.0/24.
• HTTP/HTTPS sortant fonctionnel depuis debian-srv01.
• ICMP autorisé (entrant et sortant).
• Règles listées via nft list ruleset et logs attestant des paquets droppés.

✅ Synthèse de séance (10 min)

Cette séance a présenté la variété des pare-feux et leurs niveaux d'inspection, l'importance du principe default-deny, et la manière dont NAT/PAT permettent de publier des services tout en limitant l'exposition. Vous savez maintenant traduire des politiques de sécurité en règles iptables/nftables et vérifier leur effet par des commandes de diagnostic.

🎮 Quiz — Testez vos connaissances