First commit

docs/index.md

@@ -0,0 +1,62 @@
+# 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.