🔧 Rapport d’intervention – Configuration réseau, pare-feu et sécurité Fail2Ban

Distribution : Debian 11 Bullseye
Services principaux : Docker, Fail2Ban, nftables
Objectif : Corriger les problèmes de connectivité des conteneurs, assurer une configuration cohérente et moderne du pare-feu, éliminer les résidus d’iptables, et s’assurer du bon fonctionnement de Fail2Ban.


🔍 1. Diagnostic initial

🔹 Présence d'iptables sans règles effectives

                sudo iptables -L

              

➤ Les chaînes INPUT, FORWARD et OUTPUT étaient toutes sur ACCEPT, sans règle — donc iptables n'était plus en usage actif.

🔹 Fail2Ban installé, configuré pour nftables, mais comportant des erreurs

  • banaction = nftables-multiport était bien défini.

  • Cependant, au démarrage :

                        ERROR No section: 'Definition'
    
                      

    causé par certains fichiers dans /etc/fail2ban/action.d/*.conf dépourvus de section [Definition] :

                        helpers-common.conf
    firewallcmd-common.conf
    smtp.py
    nftables.conf
    badips.py
    mail-whois-common.conf
    
                      

Ces fichiers ont été inspectés mais non supprimés, car certains sont appelés en tant que dépendance par d'autres actions, ou hérités de paquets tiers.


🧱 2. Consolidation du pare-feu : nftables

❌ Ancienne situation

  • Aucun ruleset actif autre que celui temporairement injecté par fail2ban.

  • Docker injecte ses propres règles via iptables, ce qui est non compatible avec un pare-feu nftables actif sans pont avec iptables.

✅ Nouvelle configuration

Un fichier /etc/nftables.conf a été mis en place avec le contenu suivant :

                #!/usr/sbin/nft -f

flush ruleset

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

    ct state established,related accept
    iifname "lo" accept
    tcp dport 22 ct state new accept
    tcp dport {80, 443} ct state new accept
    ip protocol icmp icmp type echo-request accept

    counter log prefix "[nftables] INPUT DROP: " flags all level warn
    reject
  }

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

    iifname "br-+" oifname "eth0" ct state new,established,related accept
    iifname "eth0" oifname "br-+" ct state established,related accept

    counter log prefix "[nftables] FORWARD DROP: " flags all level warn
    reject
  }

  chain output {
    type filter hook output priority 0; policy accept;
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority 100; policy accept;

    ip saddr 172.17.0.0/16 oifname "eth0" masquerade
    ip saddr 172.18.0.0/16 oifname "eth0" masquerade
  }
}

              

🛡️ Journalisation active

  • Ajout de compteurs counter avec log dans les chaînes input et forward :

    • Préfixes personnalisés : [nftables] INPUT DROP: et [nftables] FORWARD DROP:

    • Niveau : warn pour éviter de polluer les logs système avec trop de bruit tout en conservant une traçabilité exploitable.

    • But : Permet de repérer les paquets rejetés et d’ajuster les règles si besoin.


🐳 3. Docker et l’accès réseau

Problème constaté

  • Conteneurs ne pouvaient pas atteindre Internet :

                        curl -I https://google.com → Failed to connect
    ping 8.8.8.8 → Destination Port Unreachable
    
                      
  • Les paquets sortants ne quittaient même pas l’interface eth0 (tcpdump confirmé).

Analyse technique

  • Le NAT (masquerade) était bien défini mais les règles forward bloquaient le routage des conteneurs vers Internet.

  • La règle manquante : iifname "br-+" oifname "eth0" ct state new,established,related accept

Une fois corrigé et appliqué, les conteneurs ont regagné l’accès au réseau public :

                docker exec erplibre-ERPLibre-1 ping -c 3 8.8.8.8 → OK
docker exec erplibre-ERPLibre-1 curl -I https://google.com → OK

              

🧯 4. Services et démarrage automatique

  • nftables vérifié : activé au démarrage

                        systemctl enable nftables
    systemctl status nftables
    
                      
  • fail2ban : aussi activé

                        systemctl enable fail2ban
    systemctl status fail2ban
    
                      
  • Vérification de la présence de iptables-persistent : non installé
    Aucune trace de résidus ufw, shorewall, firewalld.

  • iptables laissé installé mais non utilisé — aucune règle ni démon actif.


🧪 5. Tests de validation

Test Résultat
nft list ruleset ✅ Affiche bien les trois tables (filter, nat, f2b-table)
Connexion SSH, HTTP/HTTPS depuis Internet ✅ Fonctionnel
Ping du serveur vers l’extérieur ✅ OK (ICMP autorisé)
Ping depuis un conteneur Docker ✅ OK
Résolution DNS dans un conteneur Docker ✅ OK
Rejet et journalisation d’un port non autorisé ✅ Confirmé dans les logs
fail2ban-client status ✅ 10 prisons actives, aucune erreur

✅ Résumé des corrections

Problème détecté Correction apportée
Connexions bloquées dans Docker Règles forward et nat ajoutées
Pas de journalisation pare-feu Règles log + counter insérées
Redondance iptables/nftables Nettoyage logique, vérification des dépendances
Erreurs Fail2Ban au démarrage Audit de action.d, règles banaction corrigées
Docker bridge non pris en compte Règles avec wildcard br-+ dans nftables
Accès sortant NAT manquant Ajout des règles masquerade ciblant 172.17 et 172.18
Démarrage automatique nftables et fail2ban activés via systemd