A zeromq-based fail2ban clustering solution
Python
Permalink
Failed to load latest commit information.
fail2ban Initial import into github repository. Aug 16, 2015
Changelog Initial import into github repository. Aug 16, 2015
FILES Initial import into github repository. Aug 16, 2015
LICENSE Initial commit Aug 16, 2015
NOTES Initial import into github repository. Aug 16, 2015
README Initial import into github repository. Aug 16, 2015
THANKS Initial import into github repository. Aug 16, 2015
TODO Updated TODO. Also, this is a test commit for new dev machine. Sep 16, 2016
VERSION
configparsing.py Initial import into github repository. Aug 16, 2015
daemon.py Initial import into github repository. Aug 16, 2015
fail2ban-cluster.conf Initial import into github repository. Aug 16, 2015
fail2ban-monitor.py Initial import into github repository. Aug 16, 2015
fail2ban-publisher.py Initial import into github repository. Aug 16, 2015
fail2ban-subscriber.py Initial import into github repository. Aug 16, 2015
monitor.py Initial import into github repository. Aug 16, 2015
publisher.py Initial import into github repository. Aug 16, 2015
subscriber.py
util.py Initial import into github repository. Aug 16, 2015

README

fail2ban-zmq-tools
by Arturo 'Buanzo' Busleiman <buanzo@buanzo.com.ar>

A set of python scripts to be run in parallel to an existing
fail2ban installation to allow multiple instances of fail2ban running in
different servers to 'cluster up', and share blocked IP addresses, for
proactive protection, by means of zeromq message queuing system.

DESIGN:
=======

There are three individual Processes: Monitor, Publisher and Subscriber.
There is ONE central configuration file, with appropiate sections for each
process. You do not need to run all processes, just the ones you want. Keep
reading.

-------------------------------------------
fail2ban-zmq-tools Cluster Subscriber
(started by ./fail2ban-subscriber.py start)
-------------------------------------------

The Subscriber receives messages from the Publisher, and depending on the
subscriberaction configuration option, does one thing or another with the
message. The idea is that the fail2ban instance that is local to the subscriber
will take this message and ban/unban accordingly.

NOTE: You *do not* need to run a Publisher instance (or have access tokens for another
Publisher, just like mine, which is the default one) if you only want to
subscribe to a Publisher.

----------------------------------------
fail2ban-zmq-tools Cluster Monitor
(started by ./fail2ban-monitor.py start)
----------------------------------------

This script monitors /var/log/fail2ban.log (you can change the fail2ban log
location by editing the fail2ban-cluster.conf file). When it detects a new
ban or unban, it transfers this information to the Publisher processes, by
means of a zeromq (www.zeromq.org) REQUEST/REPLY socket.


------------------------------------------
fail2ban-zmq-tools Cluster Publisher
(started by ./fail2ban-publisher.py start)
------------------------------------------

The Publisher receives messages using the aforementioned protocol. When it
gets a message, it replies back with the same message (as a simple ACK),
then broadcasts it to all the connected Subscribers.





NOTE: This software is an adaptation of fail2ban-cluster, a piece of
software I never fully released publicly. The fail2ban-cluster.conf general
configuration file is named in memoriam of that project :)

The "banip" fail2ban-client command was part of that original idea.