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

• 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

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…

• 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

# 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)

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 gardien qui décide quel trafic réseau peut passer et lequel est bloqué. Il applique des règles basées 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 :

Ingress (trafic entrant)

Le trafic qui arrive vers votre serveur depuis l’extérieur.

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.

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).

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 :

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

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

# 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

# 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 :

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

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

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

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

Plusieurs outils permettent de vérifier si un port est accessible :

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

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

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    ✅
Outbound: DENY ALL                       ❌ ← 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, suivez ce runbook :

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

TP 1 : Lire les règles iptables

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é

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

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

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é

Prochaines étapes

Module 8 : DHCP Revoir l'attribution automatique d'IP

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

×

📖 Voir la documentation →