infra / linux-bash

Pare-feu (iptables/nftables)

Leçon 211 exercice

Explication

Chaque paquet réseau qui arrive sur ta machine peut être examiné avant même d'atteindre une application : port de destination, adresse source, état de la connexion. Un pare-feu applique ce filtrage au niveau du système d'exploitation, en acceptant ou rejetant chaque paquet selon des règles précises.

Ce que vous allez apprendre

Configurer une politique de pare-feu "tout refuser par défaut, autoriser explicitement" avec ufw
Comprendre pourquoi l'ordre des règles compte avec iptables
Éviter le piège classique qui coupe l'accès SSH à sa propre machine en verrouillant le pare-feu
Écrire une configuration nftables de base avec tables et chaînes
Diagnostiquer une règle de pare-feu qui bloque du trafic légitime à tort

Dans quel contexte ?

Un administrateur système vient de provisionner un nouveau serveur et veut le durcir avant sa mise en production : ne laisser passer que le SSH (port 22), le HTTP/HTTPS (80/443), et bloquer tout le reste. S'il se trompe dans l'ordre des règles ou oublie d'autoriser les connexions déjà établies, il risque de se couper lui-même l'accès SSH à sa propre machine — un incident classique et particulièrement frustrant à distance.

Ensuite, il faut choisir une posture de départ

La mauvaise approche consiste à bloquer les adresses ou ports suspects un par un, une liste toujours incomplète. La bonne pratique est inverse : sudo ufw default deny incoming refuse tout par défaut, puis on autorise explicitement seulement ce qui est nécessaire, comme sudo ufw allow 22/tcp pour SSH.

Outil	Niveau	Cas d'usage
`ufw`	Surcouche simple	Serveurs Debian/Ubuntu, cas courants
`iptables`	Historique, encore répandu	Contrôle fin, règles NAT
`nftables`	Successeur moderne	Syntaxe unifiée IPv4/IPv6

Piège dangereux

Si tu passes la politique par défaut sur DROP sans d'abord autoriser les connexions déjà établies, tu coupes aussi les réponses aux requêtes que TON propre serveur a initiées, comme une résolution DNS — voire ta propre session SSH en cours. La règle ESTABLISHED,RELATED (sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT) doit TOUJOURS être ajoutée avant sudo iptables -P INPUT DROP, jamais après.

Maintenant que tu connais iptables, voyons son successeur

nftables unifie IPv4 et IPv6 dans une seule syntaxe cohérente, alors qu'iptables les gère séparément avec iptables et ip6tables. Un fichier /etc/nftables.conf décrit des tables et des chaînes (input, forward, output) avec une politique par chaîne, comme policy drop sur la chaîne input.

Bonne pratique

Avant de tester une nouvelle règle de pare-feu sur un serveur distant, ouvre une seconde session SSH en parallèle de celle que tu utilises pour la modifier. Si la règle te bloque, tu gardes un accès de secours pour corriger le tir sans devoir passer par une console physique ou un accès de secours du fournisseur cloud.

Maintenant que tu sais filtrer le trafic entrant et sortant, la prochaine leçon pousse le scripting bash vers des techniques bien plus robustes, pour des scripts destinés à tourner en production sans surveillance.

Commandes & code

Pare-feu : iptables et nftables

# --- ufw : surcouche simple au-dessus d'iptables (Debian/Ubuntu) ---
sudo ufw status verbose
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp             # SSH
sudo ufw allow 80,443/tcp           # HTTP + HTTPS d'un coup
sudo ufw allow from 10.0.0.0/8 to any port 5432   # autorise Postgres uniquement depuis le LAN
sudo ufw delete allow 80/tcp          # retire une règle
sudo ufw enable

# --- iptables : historique, encore très présent en production ---
sudo iptables -L -v -n --line-numbers      # liste les règles avec numéros de ligne
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT     # -A ajoute à la fin de la chaîne
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT                     # autorise le loopback
sudo iptables -P INPUT DROP                                  # policy par défaut : tout refuser
sudo iptables -D INPUT 3                                       # supprime la règle numéro 3
sudo iptables-save > /etc/iptables/rules.v4                      # persiste les règles

# Redirection de port avec iptables (NAT / PAT, voir la leçon dédiée)
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80

# --- nftables : successeur moderne d'iptables (syntaxe unifiée IPv4/IPv6) ---
sudo nft list ruleset                # affiche toutes les règles actives

sudo tee /etc/nftables.conf <<'EOF'
#!/usr/sbin/nft -f
flush ruleset

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

        iif "lo" accept
        ct state established,related accept
        ct state invalid drop

        tcp dport 22 accept
        tcp dport { 80, 443 } accept
        ip saddr 10.0.0.0/8 tcp dport 5432 accept

        # log puis drop, utile en debug pour voir ce qui est bloqué
        limit rate 5/minute log prefix "nft-dropped: " drop
    }

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

    chain output {
        type filter hook output priority 0; policy accept;
    }
}
EOF
sudo systemctl enable --now nftables
sudo nft -f /etc/nftables.conf         # recharge la config

# Diagnostiquer une règle qui bloque à tort
sudo nft add rule inet filter input tcp dport 8443 log prefix "debug8443: " accept
journalctl -k | grep nft-dropped

Résumé

ufw simplifie iptables pour les cas courants ; iptables/nftables pour un contrôle fin.
Toujours autoriser ESTABLISHED,RELATED (ou ct state) et le loopback avant de passer la policy par défaut à DROP.
nftables est le remplaçant recommandé d'iptables : une seule syntaxe pour IPv4 et IPv6.

Exercices pratiques

1 disponible

Mission : durcir le pare-feu sans se couper l'accès

Objectif : Mettre en place une politique de refus par défaut sans jamais perdre l'accès SSH au serveur.

Contexte

Tu dois durcir un nouveau serveur en ne laissant passer que SSH, HTTP et HTTPS, tout en refusant le reste par défaut. Une erreur d'ordre dans les règles peut te couper l'accès SSH à ta propre machine.

Résoudre l’exercice →