Fail2banMqttActionBanishment/docs/index.md

Fail2banActionBanishment

Système distribué de bannissement d'hôtes malveillants basé sur fail2ban et iptables, avec propagation des événements par MQTT.

Chaque noeud détecte et bannit localement (fail2ban + iptables), publie l'événement sur un broker Mosquitto local, puis relaie l'information vers un broker master privé (mTLS). Le master centralise la décision (corrélation multi-noeuds, récidive globale, réputation partagée) et republie les actions à exécuter vers l'ensemble des noeuds abonnés.

Machine cible : VPS Debian 13.

Architecture (résumé)

[noeud] fail2ban/iptables → mosquitto local (1883) → mosquitto master (8883, TLS)
                                                              │
                                                    décision / corrélation
                                                              │
[noeud] ◄──────────────── action MQTT (BAN, SYNC_BAN, UNBAN, ...) ◄──────────

Un tableau de bord Django (temps réel, WebSocket) tourne sur chaque noeud et sur le master, avec une vue agrégée multi-noeuds côté master.

Cas d'usage

Le modèle master/noeuds ne suppose aucun lien d'appartenance entre les serveurs protégés — seulement qu'ils partagent une même autorité de décision. Ça rend l'architecture pertinente au-delà d'un opérateur unique sur ses propres VPS :

• Un ensemble de sites (plusieurs VPS d'un même opérateur, chacun hébergeant un ou plusieurs services) : une IP qui attaque un site est bannie partout via SYNC_BAN, sans surveillance manuelle site par site.
• Une communauté (plusieurs administrateurs indépendants, chacun responsable de son propre serveur, qui acceptent de mutualiser leurs détections) : chaque membre garde son propre noeud et son propre fail2ban local — seule la propagation des bans est partagée via le master commun. Aucun accès aux serveurs des autres membres n'est requis ni accordé.
• Une société de services informatiques qui gère les sites de plusieurs clients : un master centralisé donne une vue agrégée (compteurs jail/pays, historique par noeud, alias par client) sans mélanger les données de client à client — chaque noeud ne voit que ses propres événements, le master voit tout.

Dans les trois cas, un nouveau serveur rejoint l'ensemble sans jamais donner accès SSH aux autres : une auto-inscription par jeton à usage unique suffit — pertinent en particulier pour la communauté et la société de services, où les serveurs appartiennent à des tiers différents.

Pour aller plus loin

• Installation — mise en route en développement, premier noeud en production.
• Déploiement en production — master, auto-inscription d'un noeud, bases de données, reverse proxy, alternatives à systemd.
• Référence — topics MQTT, commandes du master, jails fail2ban personnalisées.