Document généré automatiquement depuis /home/jerome/pub/docs/06-pare-feu-et-fail2ban.md sur kimsufi3, le 11 September 2026 à 14:03. Toute modification faite ici sera écrasée à la prochaine régénération : éditer le fichier source.
Posé le 10 septembre 2026 par scripts/durcir-reseau.sh, aligné sur k4.
Configuration
UFW — entrant refusé par défaut, sortant autorisé :
| Port | Action | Motif |
|---|---|---|
| 22103/tcp depuis k4 | ALLOW | réplication et administration, sans limitation |
| 22103/tcp ailleurs | LIMIT | 6 tentatives par 30 s et par adresse |
| 80/tcp | ALLOW | Traefik, qui tourne en permanence pour noteback |
| 443/tcp | ALLOW | idem |
fail2ban — jail sshd, paramètres identiques à k4 :
- 3 tentatives en 60 minutes
- bannissement permanent (
bantime = -1) - backend
systemd ignoreip: k4 (37.187.74.187) et k3 (37.59.39.138), pour qu’un incident de réplication ne bannisse jamais le pair
Ce qui a été vérifié, et non supposé
| Contrôle | Résultat |
|---|---|
| Les échecs SSH sont-ils journalisés là où la jail regarde ? | oui, sous _SYSTEMD_UNIT=ssh.service, malgré la socket activation |
| Le bannissement pose-t-il une vraie règle ? | oui, dans nftables — Ubuntu 26.04 n’utilise plus iptables |
ignoreip protège-t-il le pair ? |
oui en détection automatique : l’échec provoqué depuis k4 n’a pas été compté |
ignoreip bloque-t-il un banip manuel ? |
non. Comportement normal de fail2ban : la liste blanche ne vaut que pour la détection |
Deux pièges traités
ufw limit bloque la réplication — constaté, pas supposé
Première version de la configuration : limit sur 22103 pour tout le monde. Résultat immédiat le 10/09/2026 : au bout de six commandes lancées depuis k4, la connexion est refusée. L’ordre de redémarrage n’est jamais parti, et uptime a révélé que la machine n’avait pas bougé.
Le problème n’est pas l’administration mais la réplication : une passe ouvre plusieurs connexions SSH — rôle du pair, horodatage, puis un rsync par arborescence. Elle aurait été bloquée en silence.
La correction est une règle ALLOW pour les adresses du parc, posée avant le limit général : UFW évalue ses règles dans l’ordre, et une règle spécifique placée après un limit ne serait jamais atteinte.
Activer UFW à distance peut couper l’accès
Le script autorise le port SSH avant toute activation, et pose un filet : un ufw disable temporisé à 5 minutes, désarmé seulement une fois vérifié que SSH répond encore. Sur une machine distante, c’est la précaution qui évite le recours au mode rescue.
UFW ne filtre pas les ports publiés par Docker
Docker insère ses règles dans nat/PREROUTING, en amont du filtrage d’UFW : un conteneur qui publie un port est joignable même si UFW le refuse. Ce n’est pas une erreur de configuration, c’est le fonctionnement de Docker.
La démonstration est sur k4, où UFW est actif et où les ports 80, 443, 25, 465, 587, 110, 143, 995, 4190 et 22310 sont pourtant tous exposés.
UFW protège donc les services de l’hôte, pas les conteneurs. Quand k3 deviendra actif, mailcow ouvrira ses ports sans qu’UFW n’y puisse rien — c’est son conteneur netfilter qui assure ce blocage, et il fait très bien ce travail. Filtrer les conteneurs demanderait des règles dans la chaîne DOCKER-USER, ce qui sort du cadre de ce projet.
L’appairage doit commencer par les listes blanches
Constaté le 10/09/2026, aux dépens de la mise en service. Le mécanisme de rôle installé sur k3 avant que sa clé ne soit autorisée sur k4 : role.sh a tenté trois connexions, et k4 a banni k3 définitivement.
11:33:27 [sshd] Found 37.59.39.138
11:38:53 [sshd] Found 37.59.39.138
11:39:11 [sshd] Found 37.59.39.138
11:39:11 [sshd] Ban 37.59.39.138L’action nftables-fwd de la jail zzz-forward-ban bannit sur toutes les chaînes : le port 443 de k4, ouvert au monde entier, devenait injoignable depuis k3. Symptôme trompeur — un « Connection refused » sur tous les ports ressemble à une panne réseau, pas à un bannissement.
Deux causes de bannissement du pair, indépendantes :
- La réplication ouvre plusieurs connexions SSH par passe — rôle du pair, horodatage, puis un
rsyncpar arborescence. Un incident quelconque (clé pas encore posée, pair en cours de redémarrage) suffit à atteindre les 3 échecs. Avecbantime = -1, c’est irrévocable sans intervention. - La sonde externe
sonde-chabod.sh, qui tourne sur k3 toutes les 15 minutes, déclenchetraefik-4xx-floodsur k4 — traces à 08:45 et 09:00 ce matin-là, avant même ce projet.
Règle à appliquer
Poser les listes blanches des DEUX côtés avant la première tentative de connexion. Pas après, pas « on verra » : avec un bannissement permanent, la première erreur est définitive.
Sur k4, un fragment unique zzz-pair-dockersync.conf remplace les cinq déclarations ignoreip concurrentes qui s’y trouvaient — c’est la dernière lue qui gagnait, ce qui rendait l’ensemble illisible.
Portée réelle de fail2ban ici
PasswordAuthentication no étant posé, aucune attaque par mot de passe n’est possible sur k3 : fail2ban n’y ajoute donc pas de protection contre l’intrusion. Son intérêt est ailleurs, et reste réel — il coupe court aux scans répétés, allège le journal, et évite qu’une adresse hostile occupe des connexions. C’est un réducteur de bruit plus qu’un rempart, et il vaut mieux le savoir que de s’en croire protégé.
Commandes utiles
sudo bash /root/dockersync/durcir-reseau.sh --etat # état complet
sudo fail2ban-client status sshd # jail
sudo fail2ban-client set sshd unbanip <IP> # débannir
sudo ufw status verbose # règles
Leave a Reply