🔧 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

---