# 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](deployment.md#auto-inscription-dun-noeud-recommandé) 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](installation.md) — mise en route en développement, premier
  noeud en production.
- [Déploiement en production](deployment.md) — master, auto-inscription
  d'un noeud, bases de données, reverse proxy, alternatives à systemd.
- [Référence](reference.md) — topics MQTT, commandes du master, jails
  fail2ban personnalisées.