🔧 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
etOUTPUT
étaient toutes surACCEPT
, sans règle — donciptables
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 aveciptables
.
✅ 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
aveclog
dans les chaînesinput
etforward
:-
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èglesforward
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émarragesystemctl 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ésidusufw
,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 |