🚦 Séance 2 : iptables, nftables et micro-segmentation

B2 3h30 C2.3.5
FormationBTS SIO option SISR — IRIS Mediaschool
BlocB2 — Administration Systèmes & Réseaux
ModuleM2.3 — Infrastructure Réseau Avancée
CompétenceB2.2 / Lien B3.3
Durée3h30
PrérequisAvoir complété la Séance 1 (ACLs Cisco)

Introduction (10 min)

Une commande fréquente mais dangereuse est iptables -F (flush) exécutée par erreur en production sans sauvegarde préalable : toutes les règles sont effacées et des services internes deviennent instantanément exposés. Nous commencerons par les bonnes pratiques (sauvegarde iptables-save, tests en laboratoire), puis apprendrons à administrer iptables, migrer vers nftables et intégrer ces politiques aux firewalls hôtes (Windows).

🎯 Objectifs

  • Expliquer les tables (filter, nat, mangle, raw) et chaînes (INPUT/OUTPUT/FORWARD) d'iptables et écrire des règles de filtrage de base.
  • Configurer et persister des règles iptables sur Debian, puis migrer/écrire des règles équivalentes en nftables et les sauvegarder.
  • Mettre en place une politique de micro-segmentation combinant VLANs, ACLs routeur et firewall hôte (Windows/Linux) pour limiter le mouvement latéral.

📖 1. iptables (70 min)

iptables est l'outil historique pour gérer le filtrage au niveau hôte ou routeur sous Linux. Il repose sur plusieurs tables :

  • filter : table par défaut (chaînes INPUT, FORWARD, OUTPUT)
  • nat : NAT (PREROUTING, POSTROUTING, OUTPUT)
  • mangle : modification des paquets (TTL, marquage)
  • raw : exemptions du suivi de connexion (conntrack)

Chaînes importantes :

  • INPUT : paquets destinés à la machine locale
  • FORWARD : paquets transitant par la machine (routage)
  • OUTPUT : paquets générés localement

Cibles courantes : ACCEPT, DROP, REJECT, LOG.

Commandes essentielles

# Autoriser SSH depuis le réseau Admin
iptables -A INPUT -p tcp --dport 22 -s 192.168.10.0/24 -j ACCEPT

# Autoriser les paquets déjà établis (connexion établie)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# En dernier recours, bloquer tout le reste
iptables -A INPUT -j DROP

# Lister les règles avec compteurs et numéros de ligne
iptables -L -v -n --line-numbers

# Sauvegarder la configuration (Debian) -> fichier persistant
iptables-save > /etc/iptables/rules.v4

# Restaurer
iptables-restore < /etc/iptables/rules.v4
💡 Bonnes pratiques iptables
  • Toujours iptables-save avant des modifications risquées.
  • Utiliser -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT en début d'INPUT pour permettre les retours de connexions.
  • Tester progressivement et conserver un accès d'urgence (console ou gestion hors-bande) avant de déployer.

📖 2. nftables (70 min)

nftables est le successeur moderne d'iptables, unifiant IPv4/IPv6 et proposant une syntaxe plus puissante (sets, maps, expressions).

Commandes de base

# Créer une table inet et une chaîne input avec politique par défaut DROP
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0\; policy drop\; }

# Autoriser SSH depuis le réseau Admin
nft add rule inet filter input tcp dport 22 ip saddr 192.168.10.0/24 accept

# Autoriser les états établis/relatifs
nft add rule inet filter input ct state established,related accept

# Lister la ruleset
nft list ruleset

# Vider toute la ruleset
nft flush ruleset

Sauvegarde et intégration systemd

Écrire la configuration finale dans /etc/nftables.conf puis charger avec :

nft -f /etc/nftables.conf
systemctl enable --now nftables   # le service nftables charge /etc/nftables.conf au démarrage
nft list ruleset > /etc/nftables.conf  # méthode simple d'export
💡 Avantages de nftables

Facilité de maintenance, expressions plus lisibles, meilleure performance et management unifié IPv4/IPv6. nftables remplace à terme iptables, ip6tables, arptables et ebtables en un seul outil.

📖 3. Windows Firewall (20 min)

Sur environnements Windows Server, le firewall intégré peut être piloté en ligne de commande avec netsh ou via PowerShell. Exemple : bloquer l'accès RDP depuis l'extérieur, sauf depuis le réseau Admin :

netsh advfirewall firewall add rule name="Block-RDP-External" protocol=TCP dir=in localport=3389 remoteip=!192.168.10.0/24 action=block

Explication : remoteip=!192.168.10.0/24 signifie « bloquer toutes les adresses qui ne sont PAS dans 192.168.10.0/24 ».

📖 4. Micro-segmentation et défense en profondeur (20 min)

Principe Zero-Trust : "ne jamais faire confiance, vérifier toujours". La micro-segmentation consiste à multiplier les points d'application des politiques de sécurité :

  • Isolation logique par VLANs (couche 2)
  • ACLs routeur pour restreindre inter-VLAN (couche 3)
  • Firewalls hôtes (iptables/nftables, Windows Firewall) sur chaque serveur/poste
  • Contrôles additionnels : NAC, authentification forte, journaux centralisés

Architecture de référence

   Internet
     │
   [Routeur/ISR]
     │
  -------------------
  |   CORE SWITCH    |
  |  (trunks 802.1Q) |
  -------------------
   /    |      \
VLAN10 VLAN20 VLAN30
 Admin  Users  DMZ
  |       |      |
[win]  [poste] [deb-srv]
  ^       ^      ^
  |       |      |
 Host firewall + ACLs (routeur) => defense-in-depth

En cumulant ces couches, on réduit fortement le risque de mouvement latéral.

📖 5. Mouvement latéral — scénario d'attaque et défense (10 min)

Scénario : un poste compromis dans VLAN Users (192.168.20.0/24) cherche à atteindre la base de données située dans VLAN Admin (192.168.10.0/24). Grâce aux ACLs routeur (séance 1) et à un firewall hôte strict (nftables) sur le serveur Admin, les connexions initiales sont bloquées et consignées.

Les alertes générées par les log-input du routeur et les logs nftables permettent de déclencher une réponse : isolation du poste, recherche d'IOC, réimagerie si nécessaire.

💻 Travaux Pratiques TP S2 (70 min)

Contexte

Vous êtes administrateur du serveur debian-srv01 (192.168.10.10) chez InnovatTech. Le serveur doit continuer à fournir ses services tout en réduisant la surface d'attaque : SSH n'est autorisé qu'à partir du réseau Admin (192.168.10.0/24), le serveur doit pouvoir sortir vers Internet pour mises à jour (HTTP/HTTPS), et tout autre trafic entrant doit être journalisé puis bloqué.

Objectif

Remplacer les règles iptables existantes par une configuration nftables claire, persistante et documentée.

Prérequis techniques

  • Accès root sur debian-srv01 (Debian 12)
  • Sauvegarde des règles iptables actuelles
  • Outils : nft, nftables.service, tcpdump, curl, ssh

Étapes détaillées

Étape 1 — Sauvegarde obligatoire des règles iptables existantes

sudo iptables-save > /root/iptables-backup-$(date +%F).rules

Étape 2 — Installer nftables et désactiver iptables-persistent

sudo apt update
sudo apt install -y nftables
sudo systemctl enable --now nftables

Étape 3 — Fichier /etc/nftables.conf à créer

#!/usr/sbin/nft -f

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

        # loopback
        iifname "lo" accept

        # états établis
        ct state established,related accept

        # SSH depuis réseau Admin seulement
        tcp dport 22 ip saddr 192.168.10.0/24 accept

        # Autoriser ICMP pour diagnostic
        ip protocol icmp accept

        # Log des paquets rejetés avant drop
        log prefix "NFT_DROP_IN: " flags all counter
        drop
    }

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

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100;
        # oif "eth0" masquerade  # décommenter si ce serveur fait NAT
    }
}

Étape 4 — Appliquer et activer la persistance

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

Étape 5 — Tests de validation

# Test SSH depuis Admin (192.168.10.x) — devrait réussir
ssh admin@192.168.10.10

# Test depuis poste Users (192.168.20.x) — devrait être bloqué
ssh admin@192.168.10.10

# Test connectivité Internet depuis le serveur
curl -I https://deb.debian.org

# Vérifier logs
sudo journalctl -u nftables --since "5 minutes ago"
# Ou vérifier /var/log/kern.log pour les préfixes NFT_DROP_IN

Étape 6 — Vérifier la persistance

sudo nft list ruleset > /etc/nftables.conf
sudo systemctl status nftables

Livrable attendu

  • /etc/nftables.conf complet déposé sur debian-srv01 et dans le dépôt pédagogique.
  • Capture de tests (logs SSH, sortie curl, preuves de blocage depuis VLAN Users).
  • Courte documentation d'une page expliquant les règles et la procédure de restauration.

Critères de réussite

  • ☐ SSH accessible uniquement depuis 192.168.10.0/24.
  • ☐ Le serveur peut effectuer des requêtes HTTP/HTTPS sortantes pour mises à jour.
  • ☐ Les paquets non autorisés sont journalisés et visibles via journalctl ou /var/log/kern.log.

🔖 Synthèse (10 min)

Nous avons comparé iptables et nftables, mis en pratique la migration et la persistance sur Debian, et rappelé l'importance d'une sauvegarde avant toute modification (iptables-save). La micro-segmentation combine des contrôles au niveau réseau (VLANs, ACLs) et au niveau hôte (nftables, Windows Firewall) pour réduire le mouvement latéral. La défense en profondeur exige que chaque couche soit testée et documentée.

💡 À retenir

iptables repose sur des tables (filter, nat, mangle, raw) et des chaînes (INPUT, FORWARD, OUTPUT) — toujours sauvegarder avant modification. nftables unifie IPv4/IPv6 avec une syntaxe plus lisible et s'intègre à systemd via /etc/nftables.conf. La micro-segmentation Zero-Trust multiplie les barrières : VLANs → ACLs routeur → firewalls hôtes → journaux centralisés.

Quiz gamifié — Auto-évaluation (5 questions)

  1. Q1 (QCM) : Quelle table iptables est utilisée par défaut pour le filtrage du trafic (INPUT, FORWARD, OUTPUT) ?

  2. Q2 (QCM) : Quelle commande permet de sauvegarder les règles iptables de façon persistante sur Debian ?

  3. Q3 (V/F) : "La commande nft flush ruleset supprime l'intégralité des règles nftables en mémoire."

  4. Q4 (QCM) : Que représente la micro-segmentation dans une approche Zero-Trust ?

  5. Q5 (Libre) : Dans une chaîne INPUT nftables avec policy drop, expliquez en une phrase pourquoi la règle ct state established,related accept est indispensable.

Le plugin de quiz vous donnera un score et enregistrera vos points pour le leaderboard.

📝 Afficher les corrections
  1. A) filter — La table filter est la table par défaut d'iptables ; elle contient les chaînes INPUT, FORWARD et OUTPUT utilisées pour accepter, rejeter ou dropper les paquets.
  2. B) iptables-save > /etc/iptables/rules.v4 — Cette commande exporte toutes les règles iptables actuelles dans un fichier que iptables-restore peut recharger au démarrage (via iptables-persistent).
  3. Vrainft flush ruleset efface toutes les tables et règles nftables en mémoire vive ; les fichiers de configuration sur disque ne sont pas supprimés.
  4. C) — La micro-segmentation Zero-Trust combine plusieurs couches de contrôle : isolation VLAN (L2), ACLs inter-VLAN sur le routeur (L3) et firewalls hôtes (nftables, Windows Firewall) sur chaque machine, réduisant le mouvement latéral.
  5. Correction indicative : Sans ct state established,related accept, les réponses aux connexions légitimes initiées par le serveur (ex. mises à jour HTTP) seraient bloquées par la politique DROP, car les paquets retour n'ont pas été initiés depuis l'INPUT local.
← C2.3.5 Séance 1 — ACLs Cisco C2.4.1 Séance 1 — SNMP et Nagios fondements →