← Accueil

PCTAMALOU

Semaine 32 : Les Remparts Avancés – Pare-feux avec iptables/nftables

Par Platon-Y – pctamalou.fr & e-of-h.fr

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

flowchart TD P[🌐 Paquet Réseau] --> NIC[🔌 Interface Réseau] NIC --> NF["🔍 Netfilter Hooks
(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) :

  1. PREROUTING : Avant routage (NAT DNAT, mangle)
  2. Routing Decision : Le noyau décide où envoyer le paquet
  3. INPUT : Paquet destiné à la machine locale → vos règles de filtrage
  4. Processus Local : Application reçoit le paquet
  5. OUTPUT : Réponse de l'application
  6. POSTROUTING : Après routage (NAT SNAT, mangle)

Stateful Firewalling : L'Intelligence Contextuelle

🆕 NEW
→
📡 ESTABLISHED
→
🔗 RELATED
→
✋ INVALID

📊 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é

  1. Default DROP : Tout ce qui n'est pas explicitement autorisé est bloqué
  2. Least Privilege : Seul le strict nécessaire est autorisé
  3. Stateful Tracking : Utiliser conntrack pour l'intelligence
  4. Logging : Journaliser les drops pour analyse forensique
  5. Rate Limiting : Protéger contre les scans et DoS

🔬 Mission pratique – Laboratoire (2 heures)

Architecture du Lab Pare-feu

flowchart LR K["🔴 Kali Linux Attaquant\n192.168.56.100"] -->|Scans/Attaques| U["🛡️ Ubuntu Durci\nCible\n192.168.56.20"] U -->|Trafic légitime| I["🌐 Internet\n(si bridge)"] subgraph "🔧 Configuration Ubuntu Durcie" NF["🔥 nftables\nPolitique: DROP par défaut"] S["🔑 SSH sur port 2222"] W["🌐 Web interne only"] L["📜 Logging syslog drops"] end K -->|"Nmap -sS stealth scan"| NF K -->|"Brute SSH -p 2222"| S NF -->|DROP scans non autorisés| D["❌ Paquets rejetés\n(silencieux)"] NF -->|ACCEPT trafic SSH légitime| S NF -->|LOG drops suspects| L style NF fill:#0a0e17,stroke:#9d4edd,stroke-width:4px,color:#fff style K fill:#11151f,stroke:#ef4444,stroke-width:4px,color:#fff style U fill:#166534,stroke:#22c55e,stroke-width:3px,color:#fff style D fill:#450a0a,stroke:#dc2626,stroke-width:3px,color:#fff style L fill:#1e293b,stroke:#64748b,stroke-width:2px,color:#fff

⚠️ 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 :

  1. Loopback first : Les applications locales doivent communiquer
  2. Invalid early : Éliminer les paquets corrompus rapidement
  3. Established before new : Les réponses aux connexions sortantes d'abord
  4. Specific before general : Les règles précises avant les générales
  5. 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 nft ou nft --help
  • Red Hat nftables : Guides RH Enterprise

⚠️ Pièges Courants à Éviter

  • Bloquer le trafic établi : Mettre established,related AVANT 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