mirror of
https://github.com/deunix-educ/Fail2banMqttActionBanishment.git
synced 2026-08-24 03:11:58 +02:00
63 lines
3.0 KiB
Markdown
63 lines
3.0 KiB
Markdown
# 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.
|