Pare-feu, Qui peut parler à qui ?

Votre service est accessible en local mais pas depuis Internet ? Le pare-feu bloque probablement le trafic entrant. Ce module vous apprend à comprendre le filtrage réseau, lire les règles iptables et diagnostiquer les blocages, compétences essentielles pour déployer des applications accessibles.

TL;DR, L'essentiel en 30 secondes

Si vous n'avez que trente secondes, retenez ces quatre points : ils suffisent à orienter un diagnostic. Le deuxième est le plus discriminant, puisque le message d'erreur renvoyé au client indique déjà de quel type de blocage il s'agit.

• Pare-feu = filtre qui décide quel trafic passe (par IP, port, protocole)
• Timeout = pare-feu DROP (silencieux), Refused = pare-feu REJECT ou port fermé
• Cloud : double filtrage (Security Group + pare-feu OS)
• Stateful = les réponses aux connexions sortantes passent automatiquement

3 règles mentales à retenir

Ces trois réflexes suffisent à écarter la majorité des fausses pistes lors d'un incident réseau. Le troisième est le plus rentable au quotidien : la nature du message d'erreur vous dit où chercher avant même d'ouvrir une console sur le serveur.

1. Blocage par défaut : un pare-feu bien configuré bloque tout sauf ce qui est explicitement autorisé
2. Stateful : si vous autorisez une connexion sortante, les réponses rentrent automatiquement
3. Timeout ≠ Refused : timeout = DROP (silencieux), refused = service absent ou REJECT

Je sais que c'est bon si...

Cochez ces trois points avant de passer à la suite. Ils ne portent pas sur la configuration d'un pare-feu mais sur votre capacité à diagnostiquer : c'est la compétence que ce module cherche à installer.

• Je sais distinguer timeout (filtré) de refused (port fermé)
• sudo iptables -L -n me montre les règles actives
• Je pense à vérifier le Security Group en plus du pare-feu OS (cloud)

Commandes minimales à retenir

Trois commandes couvrent la quasi-totalité des situations. La première montre les règles effectivement chargées dans le noyau, pas le fichier de configuration, distinction qui compte quand quelqu'un a modifié les règles à la main. La deuxième distingue un port filtré d'un port fermé grâce au délai d'attente imposé par -w 3. La troisième liste les connexions suivies et prouve que le suivi d'état fonctionne.

# 1. Voir les règles iptables
sudo iptables -L -n --line-numbers

# 2. Tester si un port est filtré ou fermé
nc -zv -w 3 serveur 22

# 3. Voir les connexions suivies (stateful)
sudo conntrack -L 2>/dev/null | head -10

Cloud : double filtrage

Dans le cloud (AWS, GCP, Azure), le trafic passe par deux couches :

1. Security Group / NSG : filtre au niveau de l'hyperviseur
2. Pare-feu OS (iptables/nftables) : filtre dans la VM

Si ça ne marche pas, vérifiez les deux !

Prérequis

• Module 6 complété : vous comprenez TCP/UDP et les ports
• Module 8 complété : vous savez comment une machine obtient son IP (DHCP)
• Accès root sur une machine Linux

Aucun pare-feu à configurer pour suivre

Ce module se concentre sur la compréhension et le diagnostic. Vous n'avez pas besoin de modifier les règles de pare-feu pour suivre les exemples.

Diagnostic rapide (aide-mémoire)

Lisez ce tableau par la colonne Symptôme, c'est la seule information dont vous disposez au début d'un incident. Les deux colonnes d'hypothèses sont classées par probabilité : testez toujours l'hypothèse 1 avant l'hypothèse 2, elle est vraie dans la majorité des cas. La troisième ligne mérite une attention particulière, car « ça marche en local » oriente presque toujours vers un service qui écoute sur 127.0.0.1 plutôt que vers un blocage réseau.

Symptôme	Hypothèse #1	Hypothèse #2	Commandes
Timeout	DROP / Security Group / route	Service down	tcpdump, ss -tlnp, nc -zv -w 5
Connection refused	Service absent	REJECT --reject-with tcp-reset	ss -tlnp, iptables -S
Marche en local, pas remote	Binding sur 127.0.0.1	Pare-feu/SG	ss -tlnp, docker ps, iptables -L
ICMP unreachable	REJECT avec ICMP	Route manquante	traceroute, iptables -S

Glissez pour voir

Ce que vous allez apprendre

• Le rôle d'un pare-feu : filtrer qui peut parler à qui
• Ingress vs egress : trafic entrant vs sortant
• Stateful vs stateless : pare-feu à mémoire de connexion
• Iptables/nftables : les chaînes INPUT, OUTPUT, FORWARD
• Symptômes de blocage : timeout, connection refused, ICMP unreachable
• Diagnostic pratique : tester si un port est filtré

Qu'est-ce qu'un pare-feu ?

Un pare-feu est un filtre de paquets placé sur le chemin du trafic réseau : chaque paquet est comparé à une liste de règles, dans l'ordre, jusqu'à la première qui correspond. Cette règle décide alors du sort du paquet. Les critères de correspondance portent sur :

• L'adresse IP source/destination
• Le port source/destination
• Le protocole (TCP, UDP, ICMP)
• La direction (entrant ou sortant)

Principe de base : tout bloquer par défaut, autoriser seulement ce qui est nécessaire.

Sans pare-feu	Avec pare-feu
Tous les ports accessibles	Seuls les ports autorisés
Vulnérable aux scans	Protection contre les intrusions
Pas de contrôle	Journalisation des tentatives

Glissez pour voir

Ingress vs Egress : la direction du trafic

Le pare-feu distingue deux directions de trafic, et cette distinction structure toute la configuration : une règle n'agit jamais dans les deux sens. Le point de référence est votre serveur, pas Internet, ce qui explique qu'un même flux soit de l'ingress pour la machine qui reçoit et de l'egress pour celle qui émet. Le schéma ci-dessous fixe le vocabulaire avant d'entrer dans le détail de chaque direction.

Ingress (trafic entrant)

Le trafic qui arrive vers votre serveur depuis l'extérieur. C'est la direction que tout le monde configure, parce qu'elle conditionne l'accessibilité du service : un port non ouvert en ingress rend l'application invisible. Sur Linux, ce trafic traverse la chaîne INPUT quand il est destiné à la machine elle-même.

Exemples :

Exemples :

• Un client qui accède à votre site web (port 443)
• Une requête SSH depuis votre poste (port 22)
• Un scan de port malveillant

Egress (trafic sortant)

Le trafic qui part de votre serveur vers l'extérieur, via la chaîne OUTPUT. Cette direction est souvent laissée totalement ouverte, y compris chez les fournisseurs cloud dont les groupes de sécurité autorisent tout l'egress par défaut. C'est pourtant elle qui détermine ce qu'un serveur compromis peut atteindre.

Exemples :

Exemples :

• Votre serveur qui télécharge une mise à jour
• Une requête vers une API externe
• L'envoi d'emails (port 25/587)

Egress souvent négligé

Beaucoup d'administrateurs sécurisent l'ingress mais oublient l'egress. Un serveur compromis peut alors exfiltrer des données ou joindre un serveur de commande (C2).

Bonne pratique : restreindre aussi le trafic sortant au strict nécessaire.

Stateful vs Stateless : avec ou sans mémoire

Pare-feu stateless

Chaque paquet est évalué indépendamment. Le pare-feu ne sait pas si un paquet fait partie d'une connexion établie.

Problème : vous devez créer des règles pour les deux sens (requête ET réponse).

Pare-feu stateful

Le pare-feu mémorise les connexions établies. Si vous autorisez une connexion sortante, les réponses entrantes sont automatiquement autorisées.

Avantage : règles plus simples et plus sécurisées.

┌─────────────────────────────────────────────────────────────┐
│                    PARE-FEU STATEFUL                        │
├─────────────────────────────────────────────────────────────┤
│  Connexion sortante autorisée (port 443)                    │
│     └── Réponse entrante : AUTOMATIQUEMENT acceptée         │
│                                                             │
│  Connexion entrante non sollicitée : BLOQUÉE                │
└─────────────────────────────────────────────────────────────┘

Linux = stateful par défaut

Avec iptables/nftables, l'état ESTABLISHED,RELATED permet d'accepter automatiquement les paquets des connexions déjà établies. C'est le comportement recommandé.

Voir la table d'états (conntrack)

Le comportement stateful repose sur conntrack (connection tracking). Pour voir les connexions suivies :

# Avec conntrack-tools installé
sudo conntrack -L | head -20

# Sans conntrack-tools
sudo cat /proc/net/nf_conntrack | head -20

# Compter les connexions actives
sudo conntrack -C

Exemple de sortie :

tcp      6 431999 ESTABLISHED src=192.168.1.10 dst=93.184.216.34 sport=54321 dport=443
                               src=93.184.216.34 dst=192.168.1.10 sport=443 dport=54321

Cette ligne montre une connexion HTTPS établie : le pare-feu sait que les paquets retour (443 → 54321) font partie de cette connexion.

Pare-feu Linux : iptables et nftables

Linux dispose de deux outils de pare-feu :

• iptables : l'outil historique, encore très répandu
• nftables : le successeur moderne (depuis kernel 3.13)

Les deux utilisent le même sous-système kernel (netfilter). Pour configurer nftables en pratique (tables, chaînes, sets, NAT, ruleset persistant), voir le guide nftables.

iptables legacy vs iptables-nft

Sur les distributions récentes (Debian 11+, Ubuntu 22.04+, RHEL 8+), iptables est souvent un frontend vers nftables (iptables-nft). Les commandes iptables fonctionnent, mais la réalité kernel est nftables.

# Vérifier quelle version est utilisée
iptables -V
# iptables v1.8.9 (nf_tables)  ← backend nftables
# iptables v1.8.4 (legacy)     ← backend legacy

# Sur Debian/Ubuntu : voir l'alternative configurée
sudo update-alternatives --display iptables 2>/dev/null

Impact diagnostic : si vous modifiez les règles avec iptables mais que quelqu'un d'autre utilise nft, vous pouvez avoir des conflits.

Surcouches : UFW et firewalld

En production, beaucoup d'administrateurs n'utilisent pas iptables/nftables directement mais une surcouche :

Distribution	Outil par défaut	Backend
Ubuntu/Debian	ufw	iptables ou nftables
RHEL/Fedora/Rocky	firewalld	nftables

Glissez pour voir

Commandes UFW (Ubuntu/Debian) :

# État et règles
sudo ufw status verbose

# Autoriser un port
sudo ufw allow 22/tcp

# Voir les règles numérotées
sudo ufw status numbered

Commandes firewalld (RHEL/Fedora) :

# État du service
sudo firewall-cmd --state

# Lister toutes les règles de la zone active
sudo firewall-cmd --list-all

# Lister les services autorisés
sudo firewall-cmd --list-services

# Ouvrir un port (temporaire)
sudo firewall-cmd --add-port=8080/tcp

# Ouvrir un port (permanent)
sudo firewall-cmd --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

Diagnostic multi-outils

Si vous ne savez pas quel outil est actif, vérifiez les trois :

sudo iptables -L -n | head -20
sudo nft list ruleset | head -20
sudo ufw status 2>/dev/null || sudo firewall-cmd --state 2>/dev/null

Les chaînes iptables

Un paquet traverse différentes chaînes selon sa destination, et le noyau choisit la chaîne avant d'évaluer la moindre règle. Un paquet destiné à la machine passe par INPUT et ne verra jamais les règles de FORWARD, ce qui explique un grand classique du dépannage : des règles écrites dans la mauvaise chaîne n'ont aucun effet et ne produisent aucun message d'erreur. Sur un serveur applicatif ordinaire, seules INPUT et OUTPUT sont utilisées ; FORWARD ne sert que si la machine route du trafic, ce qui est le cas d'un hôte Docker.

Chaîne	S'applique à	Exemple
INPUT	Trafic destiné à cette machine	Connexion SSH vers ce serveur
OUTPUT	Trafic généré par cette machine	Requête curl vers une API
FORWARD	Trafic qui traverse (routage)	Paquet relayé par un routeur

Glissez pour voir

Actions possibles

Ces trois actions ne se distinguent pas par leur efficacité de blocage, identique pour DROP et REJECT, mais par l'information renvoyée au client. La colonne de droite est donc la plus utile en diagnostic : elle vous permet de remonter du symptôme observé jusqu'à la règle responsable. Retenez qu'un DROP ne consomme aucune bande passante en retour, alors qu'un REJECT génère un paquet de réponse pour chaque tentative, ce qui peut être exploité pour amplifier une attaque.

Action	Comportement	Symptôme côté client
ACCEPT	Paquet autorisé	Connexion établie
DROP	Paquet jeté silencieusement	Timeout (pas de réponse)
REJECT	Paquet refusé avec notification	"Connection refused" ou ICMP

Glissez pour voir

DROP vs REJECT

• DROP : plus discret (le client attend un timeout)
• REJECT : plus explicite (le client sait immédiatement)

En production, DROP est souvent préféré pour ne pas donner d'information aux attaquants.

Voir les règles actuelles

Trois formats d'affichage, trois usages. Le premier, avec -v, ajoute les compteurs de paquets et d'octets par règle : c'est le seul moyen de savoir si une règle est réellement traversée, information décisive quand vous doutez qu'un paquet arrive jusque-là. Le deuxième numérote les règles, ce qui permet ensuite d'en supprimer une précisément. Le troisième restitue les règles sous la forme exacte des commandes qui les ont créées, format à privilégier pour comparer deux serveurs ou archiver une configuration.

# Lister toutes les règles (format lisible)
sudo iptables -L -n -v

# Lister avec numéros de ligne
sudo iptables -L -n --line-numbers

# Voir les règles brutes (format exact)
sudo iptables -S

Exemple de sortie :

Chain INPUT (policy DROP)
num   pkts bytes target     prot opt in     out     source     destination
1     1234   56K ACCEPT     all  --  lo     *       0.0.0.0/0  0.0.0.0/0
2     5678  890K ACCEPT     all  --  *      *       0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
3      123   12K ACCEPT     tcp  --  *      *       0.0.0.0/0  0.0.0.0/0  tcp dpt:22
4       45   2K  ACCEPT     tcp  --  *      *       0.0.0.0/0  0.0.0.0/0  tcp dpt:80
5       89   8K  ACCEPT     tcp  --  *      *       0.0.0.0/0  0.0.0.0/0  tcp dpt:443

Lecture :

• policy DROP : tout ce qui n'est pas explicitement autorisé est bloqué
• Règle 1 : tout trafic sur loopback (lo) est accepté
• Règle 2 : les connexions établies sont acceptées (stateful)
• Règles 3-5 : ports SSH, HTTP et HTTPS autorisés

Équivalent nftables

nft n'affiche pas un tableau mais un ruleset structuré, proche d'un fichier de configuration. Cette présentation est plus dense et surtout plus fidèle : ce que vous lisez correspond exactement à ce que vous pouvez réécrire. Une différence importante avec iptables : il n'existe pas de tables ni de chaînes prédéfinies, tout est créé explicitement, ce qui explique qu'un nft list ruleset puisse ne rien renvoyer sur une machine neuve.

# Lister tout le ruleset
sudo nft list ruleset

# Lister une chaîne spécifique
sudo nft list chain inet filter input

Exemple de sortie nftables :

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif "lo" accept
        ct state established,related accept
        tcp dport 22 accept
        tcp dport { 80, 443 } accept
    }
}

Lecture nftables :

• table inet filter : table filter pour IPv4 et IPv6
• chain input : équivalent de la chaîne INPUT iptables
• policy drop : tout bloquer par défaut
• ct state established,related : connexions établies (stateful)
• tcp dport { 80, 443 } : syntaxe concise pour plusieurs ports

Symptômes de blocage par pare-feu

Quand un pare-feu bloque votre connexion, le symptôme dépend de la règle appliquée, et c'est une bonne nouvelle : le comportement observé côté client vous renseigne sur la configuration côté serveur sans y avoir accès. Les trois cas ci-dessous se distinguent par ce que le serveur renvoie, ou ne renvoie pas. Retenez le raccourci qui fait gagner le plus de temps : un délai d'attente signale un blocage silencieux, une réponse immédiate signale que le paquet est arrivé.

Timeout (DROP)

nc -zv 192.168.1.100 22
# Aucune réponse... attend indéfiniment

Le paquet est jeté silencieusement. Le client attend une réponse qui ne viendra jamais (jusqu'au timeout, souvent 30-60 secondes).

Connection refused (RST TCP)

nc -zv 192.168.1.100 22
# Connection refused

Le serveur envoie un paquet TCP RST (Reset). Cela signifie :

• Aucun service n'écoute sur ce port (RST envoyé par la stack TCP), OU
• Le pare-feu a une règle REJECT --reject-with tcp-reset

Exemple de règle REJECT avec RST :

# Cette règle envoie un RST au lieu de DROP silencieux
iptables -A INPUT -p tcp --dport 8080 -j REJECT --reject-with tcp-reset

RST = paquet arrivé

"Connection refused" signifie que le paquet est arrivé jusqu'au serveur. Ce n'est pas un DROP.

• Timeout → probablement un DROP (pare-feu)
• Refused → le paquet arrive, vérifiez si le service tourne (ss -tlnp)

ICMP unreachable (REJECT avec ICMP)

nc -zv 192.168.1.100 22
# Message selon l'outil et l'OS :
# - "No route to host"
# - "Host unreachable"
# - "Network unreachable"
# - "Administratively prohibited"

Le pare-feu a explicitement rejeté avec un message ICMP. Le message exact dépend du type d'ICMP envoyé et de l'outil utilisé.

Types de REJECT ICMP courants :

# ICMP port-unreachable (défaut)
iptables -A INPUT -p tcp --dport 8080 -j REJECT

# ICMP host-unreachable
iptables -A INPUT -p tcp --dport 8080 -j REJECT --reject-with icmp-host-unreachable

# ICMP admin-prohibited
iptables -A INPUT -p tcp --dport 8080 -j REJECT --reject-with icmp-admin-prohibited

Tableau récapitulatif

La colonne Paquet TCP est celle qui tranche, parce qu'elle décrit ce que l'on observe objectivement avec tcpdump, indépendamment du message affiché par l'outil client. Un paquet de retour, quel qu'il soit, prouve que votre trafic a atteint la machine cible : le problème est alors local au serveur. Aucun paquet de retour signifie que le blocage est en amont, sur le chemin réseau ou dans un filtre de niveau supérieur.

Symptôme	Paquet TCP	Cause probable	Vérification
Timeout	Rien	DROP par pare-feu	tcpdump pour voir si SYN arrive
Connection refused	RST	Pas de service OU REJECT tcp-reset	ss -tlnp sur le serveur
ICMP unreachable	ICMP	REJECT avec ICMP	iptables -S, nft list ruleset
Connexion lente puis échec	SYN sans SYN-ACK	Pare-feu intermédiaire	traceroute, tcpdump

Glissez pour voir

Diagnostiquer un blocage pare-feu

Cette procédure part du service et remonte progressivement vers le réseau. L'ordre n'est pas négociable : la moitié des incidents attribués au pare-feu se révèlent être un service arrêté ou lié à 127.0.0.1, et les étapes 1 et 2 les éliminent en quelques secondes. L'étape 5, la capture avec tcpdump, est celle qui apporte la réponse définitive, puisqu'elle sépare nettement un blocage local d'un blocage en amont.

1. Vérifiez que le service écoute localement

   Sur le serveur, vérifiez que votre service tourne :

   # Le service écoute-t-il ?
   ss -tlnp | grep :80
   # LISTEN  0  128  0.0.0.0:80  *:*  users:(("nginx",pid=1234,fd=6))

   Si rien ne s'affiche, le problème n'est pas le pare-feu mais le service.

2. Testez localement

   curl http://localhost
   # Si ça marche en local, le service fonctionne

3. Testez depuis l'extérieur

   Depuis une autre machine :

   nc -zv <ip-serveur> 80
   # Timeout ? → Probablement le pare-feu

4. Vérifiez les règles pare-feu

   sudo iptables -L -n | grep 80
   # Le port 80 est-il autorisé en INPUT ?

5. Capturez le trafic avec tcpdump

   Sur le serveur, vérifiez si les paquets arrivent :

   sudo tcpdump -i eth0 port 80 -n

   • Paquets visibles : ils arrivent, le pare-feu local les bloque
   • Aucun paquet : bloqué avant (routeur, cloud, etc.)

Diagnostic avancé : SYN / SYN-ACK

Pour un diagnostic précis, capturez les flags TCP :

# Voir uniquement SYN et SYN-ACK
sudo tcpdump -ni eth0 'tcp port 80 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'

Interprétation :

Vous voyez	Signification	Action
SYN entrant, pas de SYN-ACK	Pare-feu local DROP ou service ne répond pas	ss -tlnp, iptables -L
SYN entrant, SYN-ACK sortant	Serveur répond ! Problème sur le chemin retour	SG egress, NACL, route asymétrique
Aucun SYN	Bloqué avant d'arriver	Security Group, NACL, routeur
SYN + RST	REJECT ou service absent	ss -tlnp, iptables -S | grep REJECT

Glissez pour voir

Le piège du chemin retour

Si le SYN-ACK sort mais le client ne le reçoit jamais, le problème est sur le chemin retour :

• Security Group egress (rare, généralement ouvert)
• NACL stateless (AWS) : règles entrantes OK mais sortantes KO
• Route asymétrique

Tester un port depuis l'extérieur

Trois outils répondent à la même question avec des niveaux de détail différents. nc donne un verdict binaire en une commande et convient au dépannage quotidien. nmap va plus loin en distinguant un port fermé d'un port filtré, information que nc ne fournit pas. telnet ne présente d'intérêt que sur une machine ancienne où les deux autres sont absents. Dans tous les cas, lancez le test depuis une machine réellement extérieure : un test depuis le serveur lui-même passe par la boucle locale et ne prouve rien.

nc (netcat)

# Test rapide d'un port TCP
nc -zv <ip> <port>

# Avec timeout de 5 secondes
nc -zv -w 5 <ip> <port>

• -z : mode scan (pas de données envoyées)
• -v : verbose
• -w : timeout

nmap

# Scanner un port spécifique
nmap -p 80 <ip>

# Scanner une plage de ports
nmap -p 1-1000 <ip>

# Détecter le type de filtrage
nmap -sA -p 80 <ip>

Nmap distingue :

• open : port accessible et service actif
• closed : port accessible mais pas de service
• filtered : bloqué par pare-feu (timeout)

telnet

# Test basique
telnet <ip> 80

# Ctrl+] puis quit pour sortir

Fonctionne partout mais moins pratique que nc.

Cas pratiques DevOps

Security Groups (AWS, Azure, GCP)

Dans le cloud, le pare-feu s'appelle Security Group. C'est un pare-feu stateful qui s'applique aux instances.

Exemple AWS :

• Par défaut : tout l'egress autorisé, tout l'ingress bloqué
• Vous devez ajouter des règles pour chaque port à ouvrir

Inbound Rules:
  Type        Protocol  Port   Source
  SSH         TCP       22     Mon IP
  HTTP        TCP       80     0.0.0.0/0
  HTTPS       TCP       443    0.0.0.0/0

Double pare-feu : SG + iptables

Les Security Groups cloud sont en plus d'iptables sur l'instance. Si ça ne marche pas, vérifiez les deux !

Stateful vs Stateless dans le cloud

Une seule ligne de ce tableau pose réellement problème, et c'est la deuxième. Tous les fournisseurs proposent un filtre principal à suivi d'état, où autoriser une connexion entrante suffit à laisser passer les réponses. Les Network ACL d'AWS font exception : elles sont sans état, donc chaque direction doit être autorisée séparément. Ce détail explique des incidents difficiles à diagnostiquer, où la connexion s'établit à moitié avant de rester bloquée.

Cloud	Composant	Comportement	Piège courant
AWS	Security Group	Stateful	Retour auto-autorisé
AWS	Network ACL (NACL)	Stateless	Retour bloqué si egress non configuré
Azure	NSG	Stateful	Retour auto-autorisé
GCP	VPC Firewall Rules	Stateful	Retour auto-autorisé

Glissez pour voir

Le piège NACL (AWS)

Les Network ACLs sont stateless. Si vous autorisez l'ingress sur le port 80, vous devez aussi autoriser l'egress sur les ports éphémères (1024-65535) pour que les réponses passent.

# NACL : règle ingress OK mais egress manquant
Inbound: ALLOW TCP 80 from 0.0.0.0/0    (OK)
Outbound: DENY ALL                       (KO) <- réponses bloquées

Symptôme : SYN arrive, SYN-ACK part, mais le client ne reçoit rien.

Docker et iptables

Docker manipule automatiquement iptables pour le port mapping (-p 8080:80).

Voir les règles Docker :

# Table nat (port mapping)
sudo iptables -t nat -S | grep -E "(DOCKER|PREROUTING|POSTROUTING)"

# Table filter (FORWARD, DOCKER-USER)
sudo iptables -S DOCKER-USER 2>/dev/null
sudo iptables -S FORWARD | head -10

Problème courant : vous ajoutez une règle iptables, Docker la contourne avec ses propres règles.

Solution : utilisez la chaîne DOCKER-USER pour ajouter vos règles :

# Bloquer un IP spécifique vers les conteneurs
sudo iptables -I DOCKER-USER -s 192.168.1.100 -j DROP

Docker : port publié mais inaccessible

Problème fréquent : un port est publié (-p 8080:80) mais inaccessible depuis l'extérieur.

Checklist diagnostic :

# 1. Vérifier le binding (127.0.0.1 vs 0.0.0.0)
docker ps --format "table {{.Names}}\t{{.Ports}}"
# Si vous voyez 127.0.0.1:8080->80/tcp, c'est bindé sur localhost uniquement !

# 2. Vérifier que le service dans le conteneur écoute
docker exec <container> ss -tlnp | grep :80
# Si le process écoute sur 127.0.0.1 dans le conteneur, il ne sera pas accessible

# 3. Vérifier les règles iptables Docker
sudo iptables -L DOCKER -n -v | grep 8080

Causes fréquentes :

Symptôme	Cause	Solution
127.0.0.1:8080->80	Binding localhost	Utiliser -p 8080:80 sans IP
Service écoute sur 127.0.0.1	Config app	Configurer l'app pour écouter sur 0.0.0.0
Pas de règle DOCKER	Docker pas démarré	systemctl status docker

Glissez pour voir

Diagnostic egress (trafic sortant bloqué)

Quand votre serveur ne peut pas joindre un service externe, la difficulté vient du nombre de couches susceptibles d'échouer : résolution de nom, connectivité TCP, négociation TLS, proxy applicatif. Le runbook ci-dessous les teste dans cet ordre, du plus bas au plus haut niveau, pour que le premier échec désigne directement le responsable. Ne sautez pas la première étape : un problème de DNS produit exactement les mêmes symptômes qu'un blocage de port.

Scénarios courants :

• Serveur ne peut pas télécharger depuis un registry Docker
• Application ne peut pas joindre une API externe
• Connexion à une base de données managée qui échoue

Runbook egress :

# 1. Tester la résolution DNS
dig api.externe.com

# 2. Tester la connectivité TCP
nc -zv -w 5 api.externe.com 443

# 3. Tester HTTP
curl -I --connect-timeout 5 https://api.externe.com

# 4. Vérifier les règles OUTPUT
sudo iptables -L OUTPUT -n -v

# 5. Capturer le trafic sortant
sudo tcpdump -ni eth0 'host api.externe.com and tcp port 443'

Causes fréquentes :

Symptôme	Cause probable	Solution
DNS timeout	Egress UDP 53 bloqué	Autoriser DNS sortant
nc timeout	Egress TCP bloqué	Autoriser le port de destination
curl SSL error	Proxy interceptant	Vérifier les variables proxy

Glissez pour voir

Kubernetes NetworkPolicies

Dans Kubernetes, les NetworkPolicies sont l'équivalent des règles pare-feu entre pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

Cette policy autorise uniquement les pods labellisés app: frontend à accéder au port 80 des pods app: nginx.

Travaux pratiques

Ces trois exercices sont non destructifs : ils lisent des règles et testent des ports, sans jamais modifier la configuration de votre machine. Ils demandent en revanche un accès sudo et, pour le deuxième, une seconde machine capable de joindre la première.

TP 1 : Lire les règles iptables

Le but est de savoir lire une configuration existante avant de prétendre en écrire une. Sur un poste de travail ordinaire, attendez-vous à une politique ACCEPT et à très peu de règles ; sur un serveur durci, vous verrez au contraire une politique DROP suivie d'une liste d'autorisations explicites. Les deux formats demandés à l'étape 1 et à l'étape 3 décrivent la même chose, l'exercice consiste à retrouver chaque règle d'une sortie dans l'autre.

1. Affichez les règles actuelles

   sudo iptables -L -n -v

2. Identifiez

   • Quelle est la policy par défaut de INPUT ?
   • Quels ports sont autorisés ?
   • Y a-t-il une règle pour les connexions établies ?

3. Affichez le format brut

   sudo iptables -S

   Comparez avec la sortie précédente.

TP 2 : Tester un port filtré

Ce test met en évidence la différence entre « le service fonctionne » et « le service est joignable ». Le serveur HTTP de Python écoute sur toutes les interfaces, donc un échec depuis une autre machine ne peut venir que du réseau ou du filtrage. Gardez le port 9999 : il n'est associé à aucun service courant, ce qui évite d'interférer avec une application existante.

1. Lancez un serveur de test

   # Terminal 1 : serveur sur port 9999
   python3 -m http.server 9999

2. Testez localement

   # Terminal 2
   curl http://localhost:9999
   # Doit fonctionner

3. Testez depuis une autre machine

   nc -zv <ip-serveur> 9999
   # Timeout si pare-feu bloque

4. Vérifiez avec tcpdump

   # Sur le serveur
   sudo tcpdump -i eth0 port 9999 -n

   Les paquets arrivent-ils ?

TP 3 : Comparer DROP et REJECT

C'est l'exercice le plus utile du module, parce qu'il transforme une notion théorique en réflexe chronométré. Mesurez réellement les temps avec time : un refus arrive en quelques millisecondes, un blocage silencieux consomme toute la durée du délai d'attente. Cet écart est la première information exploitable lors d'un incident, avant même de se connecter au serveur.

1. Testez un port DROP (timeout)

   time nc -zv -w 5 <ip> 12345
   # Attend 5 secondes puis timeout

2. Testez un port sans service (refused)

   time nc -zv -w 5 localhost 12345
   # Immediate "Connection refused"

3. Comparez les temps

   • DROP : attend le timeout
   • Pas de service : réponse immédiate

Testez vos connaissances

Dix questions portant sur les points du module qui se confondent facilement : direction du trafic, suivi d'état, différence entre les symptômes d'un blocage. Le seuil de réussite est fixé à 80 %, volontairement haut, car une erreur d'interprétation sur ces notions coûte du temps de diagnostic en production.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Pare-feu : filtre le trafic selon des règles (IP, port, protocole)
• Ingress : trafic entrant (vers votre serveur)
• Egress : trafic sortant (depuis votre serveur), souvent négligé mais critique
• Stateful : le pare-feu mémorise les connexions (conntrack) ; ESTABLISHED,RELATED accepte les réponses
• iptables vs nftables : sur les distros récentes, iptables est souvent un frontend vers nftables
• UFW/firewalld : surcouches courantes, vérifiez laquelle est active
• Timeout = DROP : paquet jeté silencieusement (pas de RST, pas d'ICMP)
• Connection refused = RST : le paquet arrive, mais pas de service OU règle REJECT tcp-reset
• Cloud = multi-couches : Security Group (stateful) + NACL (stateless sur AWS) + iptables sur l'instance
• Docker DOCKER-USER : seule chaîne pour ajouter vos règles sans être contourné

FAQ : questions fréquentes sur les pare-feu

Ces cinq questions sont celles qui reviennent le plus en formation : ce qui distingue iptables de nftables, comment lire les règles en place, l'arbitrage entre DROP et REJECT, ce que recouvre le filtrage stateful, et le choix entre ufw et firewalld.

Quelle est la différence entre iptables et nftables ?

iptables est l'outil de pare-feu historique de Linux ; nftables est son successeur moderne (noyau 3.13), recommandé pour les nouvelles configs. Sur les distributions récentes, la commande iptables est souvent un frontend vers nftables (iptables-nft).

Comment voir les règles du pare-feu sous Linux ?

Avec nftables : nft list ruleset affiche toutes les tables, chaînes et règles actives. Avec iptables : iptables -L -n -v. Si une surcouche est utilisée, ufw status verbose (Ubuntu/Debian) ou firewall-cmd --list-all (RHEL/Fedora) donnent une vue plus lisible des règles effectives.

Faut-il utiliser DROP ou REJECT dans un pare-feu ?

DROP jette le paquet en silence : l'émetteur attend jusqu'au timeout, ce qui ralentit un scan. REJECT renvoie une erreur (ICMP ou RST TCP) : la connexion échoue tout de suite. On préfère DROP en bordure Internet, REJECT pour le trafic interne.

Qu'est-ce qu'un pare-feu stateful ?

Un pare-feu stateful suit l'état des connexions (NEW, ESTABLISHED, RELATED, INVALID) via le suivi de connexion (conntrack). Il autorise automatiquement le trafic retour d'une connexion déjà acceptée. La règle de base ct state established,related accept évite d'ouvrir chaque flux retour.

ufw ou firewalld : lequel utiliser ?

ufw (Uncomplicated Firewall) est la surcouche par défaut sur Ubuntu/Debian : simple, idéale pour un serveur unique. firewalld est le standard sur RHEL/Fedora : organisé en zones, mieux pour plusieurs interfaces. Les deux pilotent nftables ; choisissez celui de votre distribution.

Prochaines étapes

Configurer nftables Tables, chaînes, sets, NAT et ruleset persistant en pratique

Méthodologie de diagnostic réseau Enchaîner les vérifications dans le bon ordre, du câble à l'application

Retour au parcours Vue d'ensemble de la formation réseau

×

📖 Voir la documentation →