Antelao Fail2Ban
Brute-force protection as a service: the fail2ban daemon and a management API in one container, with an optional console.
The products it protects push their own jails into it - they are the ones that know what their logs look like - and it owns the daemon, the firewall rules and the ban state.
Why one container
The API starts the fail2ban daemon as a child process and talks to it over a socket that never
leaves the container. Nothing needs the Docker socket or a shared process namespace, either of which
would be root on the host by another name: the container's power is bounded by the capabilities you
give it, NET_ADMIN and NET_RAW, and by the folders you mount.
Who decides what
| The protected product | What its logs look like, and therefore what a jail matches. It pushes the jail and its filter |
| This service | The daemon, the firewall rules, the ban state, and whether a definition is safe to apply |
You will meet it in two ways: inside the Odoo Host Manager, as the ohm-fail2ban container
behind that product's Threat protection page (see Related below), and on its own, as a
service other things push jails into.
The one deployment mistake that matters
The API container needs NET_ADMIN, NET_RAW and host networking. Without them it starts, reports
itself healthy, writes perfect jails - and blocks nothing.
That is the single worst way this can be deployed, because everything looks right. Installing Fail2Ban tells you the one command that proves otherwise.
Where to start
Install it, then reach the console. When something does not work, start at Troubleshooting.
Related
- Intrusion prevention, in the Odoo Host Manager manual