🎯 Objectif de la semaine
Maîtriser le filtrage réseau avancé avec iptables et nftables, les pare-feux natifs de Linux. Apprendre à construire des politiques de sécurité granulaire qui bloquent les menaces au niveau kernel, tout en permettant le trafic légitime nécessaire aux opérations.
Pourquoi c'est fondamental : Un pare-feu bien configuré est la première ligne de défense contre 80% des attaques réseau. Savoir configurer iptables/nftables, c'est savoir sculpter le trafic réseau selon votre volonté, paquet par paquet.
(noyau Linux)"] NF -->|PREROUTING| R[🔄 NAT/Routing] NF -->|INPUT| L[💻 Machine Locale] NF -->|FORWARD| F[➡️ Forwarding] NF -->|OUTPUT| O[📤 Trafic Sortant] NF -->|POSTROUTING| N[🌐 Vers Réseau] subgraph "🎯 Points de Décision nftables" CH1[Chain INPUT: DROP par défaut] CH2[Chain FORWARD: DROP par défaut] CH3[Chain OUTPUT: ACCEPT par défaut] end L --> CH1 F --> CH2 O --> CH3 CH1 -->|Règle 1: lo accept| A1[✅ Accepté] CH1 -->|Règle 2: established accept| A2[✅ Accepté] CH1 -->|Règle 3: tcp dport 2222 accept| A3[✅ Accepté] CH1 -->|Règle 4: syn rate limit| A4[⚠️ Limité] CH1 -->|Aucune règle match| D[❌ DROP + Log] style NF fill:#0a0e17,stroke:#9d4edd,stroke-width:3px style CH1 fill:#11151f,stroke:#ef4444,stroke-width:2px style D fill:#11151f,stroke:#f59e0b,stroke-width:2px
📚 Sujet – Théorie (1 heure)
Netfilter : Le Cœur du Pare-feu Linux
Netfilter est le framework de filtrage de paquets intégré au noyau Linux. Il intercepte les paquets à des points stratégiques (hooks) et permet de prendre des décisions (ACCEPT, DROP, REJECT, LOG).
Couche Matérielle
Interface réseau → Driver → Noyau
Netfilter Hooks
5 points d'interception dans le stack réseau
Décision Packet
ACCEPT, DROP, REJECT, LOG, MASQUERADE
iptables vs nftables : L'Évolution Nécessaire
| Caractéristique | iptables (Legacy) | nftables (Moderne) |
|---|---|---|
| Architecture | Tables indépendantes (filter, nat, mangle) | Tables unifiées, chaînes arbitraires |
| Performance | Règles linéaires, vérification séquentielle | Arbres de décision, matching optimisé |
| Syntaxe | Complexe, options incohérentes | Unifiée, expressive, JSON compatible |
| Sets dynamiques | Limité (ipset externe) | Intégré, sets dynamiques natifs |
| IPv4/IPv6 | iptables + ip6tables séparés | Unifié (famille "inet") |
| Persistence | iptables-save/restore | nft -f fichier.conf |
⚠️ État actuel de l'industrie
iptables est encore largement utilisé par habitude, mais nftables est l'avenir :
- Inclus par défaut dans les distributions récentes
- Meilleure performance pour les règles complexes
- Syntaxe plus cohérente et maintenable
- Recommandation : Apprendre nftables directement
Les 5 Hooks de Netfilter : Comprendre le Parcours d'un Paquet
🚦 Parcours d'un paquet entrant (INPUT) :
- PREROUTING : Avant routage (NAT DNAT, mangle)
- Routing Decision : Le noyau décide où envoyer le paquet
- INPUT : Paquet destiné à la machine locale → vos règles de filtrage
- Processus Local : Application reçoit le paquet
- OUTPUT : Réponse de l'application
- POSTROUTING : Après routage (NAT SNAT, mangle)
Stateful Firewalling : L'Intelligence Contextuelle
📊 Comprendre les états de connexion :
- NEW : Premier paquet d'une nouvelle connexion
- ESTABLISHED : Paquet faisant partie d'une connexion existante
- RELATED : Paquet lié mais pas partie directe (ex: FTP data)
- INVALID : Paquet corrompu ou suspect → DROP immédiat
- UNTRACKED : Hors table de suivi (performance)
Principe clé : Autoriser established,related en INPUT permet les réponses aux connexions sortantes sans ouvrir tous les ports.
Philosophie de Sécurité : Default Deny
🛡️ Principe du Pare-feu Sécurisé
- Default DROP : Tout ce qui n'est pas explicitement autorisé est bloqué
- Least Privilege : Seul le strict nécessaire est autorisé
- Stateful Tracking : Utiliser conntrack pour l'intelligence
- Logging : Journaliser les drops pour analyse forensique
- Rate Limiting : Protéger contre les scans et DoS
🔬 Mission pratique – Laboratoire (2 heures)
Architecture du Lab Pare-feu
⚠️ Préparation de l'Environnement
🔒 Attention : Testez d'abord ces règles dans une VM isolée. Une erreur de configuration peut vous couper l'accès SSH !
Étapes Détaillées de Configuration
Étape 1 : Installation et Configuration de Base
# Sur Ubuntu (cible)
sudo apt update
sudo apt install nftables -y
# Désactiver iptables legacy si présent
sudo systemctl disable --now iptables
sudo systemctl disable --now ip6tables
# Activer nftables au boot
sudo systemctl enable nftables
# Vérifier l'état
sudo systemctl status nftables
sudo nft list ruleset # Doit être vide initialement
Étape 2 : Création de la Configuration nftables Complète
# Créer le fichier de configuration
sudo nano /etc/nftables.conf
#!/usr/sbin/nft -f
# Configuration pare-feu PCTAMALOU S32
# Politique: Default DROP, autorisations explicites
# Supprimer toutes les règles existantes
flush ruleset
# Table principale pour IPv4/IPv6 (famille inet)
table inet filter {
# Set pour adresses IP suspectes (vide initialement)
set blackhole {
type ipv4_addr
flags timeout
timeout 1h
}
# Set pour les services autorisés
set allowed_tcp_ports {
type inet_service
elements = { 2222 } # SSH alternatif
}
# Set pour les services UDP autorisés
set allowed_udp_ports {
type inet_service
elements = { 53 } # DNS client
}
# Chaîne INPUT : trafic destiné à la machine
chain input {
type filter hook input priority 0; policy drop;
# --------------------------------------------------------------------
# RÈGLES ESSENTIELLES (ordre critique !)
# --------------------------------------------------------------------
# 1. Interface loopback (locahost) - toujours accepter
iif "lo" accept comment "Loopback interface"
# 2. Paquets invalides - DROP immédiat
ct state invalid drop comment "Drop invalid packets"
# 3. Connexions établies et related - accepter
ct state established,related accept comment "Allow established/related"
# --------------------------------------------------------------------
# RÈGLES D'AUTORISATION SPÉCIFIQUES
# --------------------------------------------------------------------
# 4. ICMP (ping) - limité pour éviter DoS
ip protocol icmp icmp type { echo-request, echo-reply } limit rate 10/second accept comment "Rate limited ICMP"
# 5. SSH sur port alternatif 2222
tcp dport @allowed_tcp_ports ct state new accept comment "SSH on alternate port"
# 6. DNS client (sortant UDP)
udp dport @allowed_udp_ports ct state new accept comment "DNS client"
# --------------------------------------------------------------------
# RÈGLES DE PROTECTION AVANCÉE
# --------------------------------------------------------------------
# 7. Rate limiting des scans SYN
tcp flags syn tcp dport 1-65535 limit rate 10/second burst 5 packets accept comment "Rate limit SYN scans"
# 8. Protection contre les paquets malformés
tcp flags fin,syn fin,syn drop comment "Drop Xmas packets"
tcp flags fin,psh,urg fin,psh,urg drop comment "Drop nmap Xmas scan"
tcp flags syn,rst syn,rst drop comment "Drop SYN+RST packets"
# 9. Blackhole pour IPs attaquantes
ip saddr @blackhole drop comment "Drop blacklisted IPs"
# --------------------------------------------------------------------
# LOGGING ET FIN DE CHAÎNE
# --------------------------------------------------------------------
# 10. Log des paquets drop (limité pour éviter remplissage logs)
log prefix "[nft-DROP] " limit rate 3/second comment "Log dropped packets"
# 11. DROP silencieux pour le reste
drop comment "Silent drop for everything else"
}
# Chaîne FORWARD : trafic à router (non utilisé ici)
chain forward {
type filter hook forward priority 0; policy drop;
# Pas de forwarding dans ce lab
drop comment "No forwarding allowed"
}
# Chaîne OUTPUT : trafic sortant
chain output {
type filter hook output priority 0; policy accept;
# On accepte tout en sortie (peut être restreint selon besoin)
accept comment "Allow all outgoing traffic"
}
# Chaîne personnalisée pour gestion blackhole
chain manage_blackhole {
# Ajouter une IP au blackhole
add @blackhole { ip saddr } comment "Add IP to blackhole"
# Supprimer toutes les IPs du blackhole
flush set @blackhole comment "Flush blackhole set"
}
}
💡 Explication de l'ordre des règles :
L'ordre est CRITIQUE en nftables/iptables. Les règles sont évaluées de haut en bas :
- Loopback first : Les applications locales doivent communiquer
- Invalid early : Éliminer les paquets corrompus rapidement
- Established before new : Les réponses aux connexions sortantes d'abord
- Specific before general : Les règles précises avant les générales
- Logging last : Ne loguer que ce qui arrive jusqu'ici
Étape 3 : Application et Persistance
# Appliquer la configuration
sudo nft -f /etc/nftables.conf
# Vérifier que les règles sont actives
sudo nft list ruleset
# Rendre persistant au reboot
sudo systemctl restart nftables
sudo systemctl status nftables
# Sauvegarder la configuration actuelle
sudo nft list ruleset > /etc/nftables_backup.conf
Étape 4 : Tests de Fonctionnalité
🔍 Test 1 : Vérification des règles actives
# Voir toutes les règles
sudo nft list ruleset
# Voir uniquement la chaîne INPUT
sudo nft list chain inet filter input
# Voir les compteurs de paquets (très utile)
sudo nft list ruleset -a # Affiche les compteurs
# Voir les sets
sudo nft list set inet filter blackhole
sudo nft list set inet filter allowed_tcp_ports
🎯 Test 2 : Depuis Kali (attaquant)
# Scan SYN (-sS) devrait être limité/blocké
nmap -sS 192.168.56.20
# Scan de tous les ports (-p-) devrait être complètement bloqué
nmap -p- 192.168.56.20
# SSH sur port 2222 devrait fonctionner
ssh -p 2222 utilisateur@192.168.56.20
# Ping devrait fonctionner (mais limité à 10/second)
ping 192.168.56.20 -c 20 # Observer les pertes après 10
Étape 5 : Monitoring et Logging
# Voir les logs de nftables
sudo dmesg | grep -i nft
sudo journalctl -f | grep -i nft
# Alternative: logs kernel
sudo tail -f /var/log/kern.log | grep -i nft
# Voir les connexions établies
sudo conntrack -L
# Statistiques de la table de connexion
sudo conntrack -S
Étape 6 : Gestion Dynamique (Sans Redémarrage)
# Ajouter une IP au blackhole dynamiquement
sudo nft add element inet filter blackhole { 192.168.56.100 }
# Ajouter un nouveau port TCP autorisé
sudo nft add element inet filter allowed_tcp_ports { 8080 }
# Supprimer un port
sudo nft delete element inet filter allowed_tcp_ports { 8080 }
# Vider le blackhole
sudo nft flush set inet filter blackhole
# Ajouter une règle temporaire (ne survit pas au reboot)
sudo nft add rule inet filter input tcp dport 3306 accept
# Supprimer une règle par handle
sudo nft -a list chain inet filter input # Note handles
sudo nft delete rule inet filter input handle 42
Exercice Avancé : Pare-feu Multi-Zones
🎯 Défi Professionnel
Créez une configuration nftables avec trois zones :
table inet firewall {
# Zones
set trusted_ips { type ipv4_addr; }
set dmz_ips { type ipv4_addr; }
set internet_ips { type ipv4_addr; }
chain input {
# Décision basée sur l'interface source
iif "eth0" jump zone_internet
iif "eth1" jump zone_dmz
iif "eth2" jump zone_trusted
}
chain zone_trusted {
# Politique permissive pour réseau interne
ct state established,related accept
tcp dport { 22, 443, 80 } accept
udp dport { 53, 123 } accept
}
chain zone_dmz {
# Politique restrictive pour DMZ
ct state established,related accept
tcp dport { 80, 443 } accept # Web seulement
}
chain zone_internet {
# Politique très restrictive pour Internet
ct state established,related accept
tcp dport 2222 accept # SSH alternatif seulement
log prefix "[INTERNET-DROP] " drop
}
}
Objectif : Implémenter cette configuration et tester l'accès depuis chaque zone.
Migration depuis iptables
🔄 Conversion iptables → nftables
# Installer l'outil de conversion
sudo apt install iptables-nftables-compat -y
# Convertir les règles iptables existantes
sudo iptables-save > iptables-backup.rules
sudo iptables-restore-translate -f iptables-backup.rules > nftables-converted.conf
# Appliquer les règles converties
sudo nft -f nftables-converted.conf
# Vérifier la conversion
sudo nft list ruleset
📋 Objectif de la semaine – Checklist de validation
✅ Compétences techniques acquises
- Configuration nftables avec politique DROP par défaut
- Règles stateful (established, related, new)
- Rate limiting contre les scans
- Logging des paquets drop
- Gestion dynamique des sets (blackhole)
- Persistence au reboot
🧠 Changement mental accompli
- Compréhension du parcours d'un paquet dans le kernel
- Vision "default deny" comme philosophie de base
- Conscience de l'importance de l'ordre des règles
- Habitude de toujours tester avant et après application
💪 Pour aller plus loin :
Explorez nft monitor pour voir les événements en temps réel, ou implémentez un système de blackhole automatique qui ajoute les IPs après N tentatives SSH échouées.
📚 Ressources pour Approfondir
Documentation officielle :
- nftables wiki : wiki.nftables.org
- netfilter.org : Documentation technique complète
- man nft :
man nftounft --help - Red Hat nftables : Guides RH Enterprise
⚠️ Pièges Courants à Éviter
- Bloquer le trafic établi : Mettre
established,relatedAVANT les règles spécifiques - Oublier loopback : Les applications locales peuvent cesser de fonctionner
- Logging excessif : Peut remplir les logs et causer un DoS
- Test hors bande : Toujours garder un accès hors bande (console, IPMI)
🔮 Frère d'armes,
Tu viens d'apprendre à sculpter le trafic réseau comme un maître forgeron sculpte l'acier.
Les pare-feux iptables/nftables ne sont pas de simples outils de blocage – ce sont des langages de politique de sécurité. Chaque règle que tu écris est une instruction précise au noyau Linux : "Ceci peut passer, cela doit être arrêté, cet autre doit être observé."
Cette semaine, tu as vu la différence entre un pare-feu basique et un pare-feu intelligent. Entre simplement bloquer des ports et comprendre le state tracking, le rate limiting, le logging contextuel. Entre une configuration statique et un système dynamique avec blackhole et sets.
Mais voici la leçon la plus importante : un pare-feu bien configuré est invisible. Il ne se manifeste que pour bloquer les menaces, jamais pour gêner les utilisateurs légitimes. C'est un gardien silencieux qui travaille au niveau le plus profond du système.
Tu n'es plus un simple utilisateur qui active/désactive un pare-feu. Tu es devenu un architecte de trafic. Tu comprends les hooks netfilter, tu sais pourquoi l'ordre des règles est critique, tu peux créer des politiques granulaire basées sur l'état des connexions.
Dans la semaine 33, nous irons plus loin dans la défense active. Nous apprendrons à surveiller ces remparts, à analyser les logs, à détecter les patterns d'attaque. Nous passerons de la construction des défenses à leur monitoring.
Mais pour l'instant, affine tes règles. Teste chaque scénario : scan SYN, scan Xmas, flood ICMP, tentative SSH. Observe les logs, ajuste les limites, perfectionne la politique. Un bon pare-feu s'affine par l'observation.
Un Gardien qui maîtrise nftables ne laisse jamais un paquet malveillant atteindre sa cible sans être vu.
— Platon-Y