Intrusion prevention

Antelao runs Fail2Ban in its own container, watching the nginx logs and banning addresses that behave like attackers.

What is and is not licensed

Running Fail2Ban and the automatic bans it applies are never restricted. Intrusion prevention is baseline protection and is installed with the server at every edition, including unregistered.

Requires the Community edition

Banning an address in a jail by hand. Running the Fail2Ban container and the automatic bans it applies are never restricted - intrusion prevention is baseline protection, installed with the server at every edition. Reading the current jails and bans, LIFTING a ban, and removing Fail2Ban altogether stay available too - an unregistered server must never be locked out of its own remedy.

Available on Community, Developer, Professional, Provider. Below that the operation is refused and nothing is changed.

Reading jails and bans, lifting a ban, and removing Fail2Ban altogether all stay available at every edition. An unregistered server must never be locked out of its own remedy, which is exactly what a gated unban would create.

Working with bans

Remote or localagainst prod-1

# odoocli server fail2ban list --server prod-1

Remote or localagainst prod-1

# odoocli server fail2ban ban 203.0.113.10 odoo-login --server prod-1

Remote or localagainst prod-1

# odoocli server fail2ban unban --ban 203.0.113.10 --server prod-1

Omit --ban and the CLI shows a picker. In the Web UI the same lives on the Intrusion prevention page, which updates live.

Configuration

Whitelist, blacklist, ban duration, search window, retry count and notification recipients are part of the server configuration, set by the server config create wizard and editable afterwards.

The wizard offers to whitelist your current public address. Accept it. Locking yourself out of a server you are configuring remotely is a common and avoidable way to lose an afternoon.

Local only

# odoocli server fail2ban config install

Which instance a ban belongs to

Jails are server-wide, so a ban is not tagged with an instance. Antelao attributes a ban to an instance by the database named in the match that triggered it. That is why a ban's instance column can be empty for jails that do not carry one.

Behind a reverse proxy, bans can block nothing

If something else terminates TLS in front of the managed nginx, every packet arrives from the proxy. Fail2Ban then bans the proxy's address, or bans a client address that no longer appears in the packets at all.

Worse, nginx's real-IP handling rewrites the access log to show the true client address, so the logs look exactly like a directly exposed server and the bans look correct. They are applied perfectly and stop nothing.

The fix is to declare the proxy in the server configuration's trusted proxies list, so the real client address is recovered from the forwarded headers. To confirm bans are actually dropping traffic, check the per-rule packet counters inside the f2b-<jail> chain rather than trusting the ban list.

Removing it

Remote or localagainst prod-1

# odoocli server fail2ban remove --server prod-1

Available at every edition, for the same reason lifting a ban is.

Related

• Users and roles
• Logs