Skip to main content

Bans, and whether they worked

The routes​

RouteWhat it doesLicense
GET /bansThe bans in force, with the log lines that earned themAlways available
POST /bansBans an address by handBlocks when licensed; without a license, logged as WOULD BAN
DELETE /bans/{jail}/{address}Lifts a banNever gated

Each ban carries the log line that earned it, which is the difference between "this address is banned" and "this address is banned for this".

Lifting a ban is never license-gated​

Not at any edition, not in any state, not ever.

A server whose license has lapsed can always let its own administrator back in.

An unlicensed service does not block: its jails detect and log each ban as WOULD BAN, and when a license lapses every current ban is lifted. See Licensing.

A listed ban is not necessarily an enforced ban​

A ban can be listed and still block nothing. There are two causes.

Behind a reverse proxy, bans can block nothing

If something else terminates the connection in front of this service's host, every packet arrives from the proxy. The daemon 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 other cause is the deployment one: without NET_ADMIN, NET_RAW and host networking the daemon writes rules that never reach the kernel. See Installing Fail2Ban.

Both are invisible from the ban list. To know whether a ban is actually dropping traffic, check the per-rule packet counters in the chain rather than trusting the list:

sudo iptables -L f2b-<jail> -n -v

Counters that stay at zero while the ban list grows is the signature of both failures.

Banning by hand, and whether it worked​

fail2ban reports a ban as done as soon as it is recorded. The firewall rule is written afterwards and can fail on its own - no NET_ADMIN, a kernel without the modules, a chain left behind by the other backend - and then the address is on the bans list and in every counter, and not blocked.

So POST /bans, and the console's ban button, wait briefly for the daemon to complain about that jail and that address. A complaint is proof the address is not blocked, and the answer says so in the daemon's own words. Silence is not proof that it is, and the success message does not claim it. Diagnostics on the Options page answers that question properly, by writing a rule; see The firewall.

The log, and restarting the daemon​

The daemon logs to the container's output, so docker logs shows the whole story. The console's Logs page reads the last few thousand lines the service keeps in memory; nothing is written to disk, and the buffer starts when the service does.

A restart asks the daemon to stop rather than killing it, so it saves its bans on the way out and restores them when it returns. Nothing is enforced for the second or two in between, and the console asks twice before doing it. A reload, which a jail or options save already does, stops nothing.

Inside the Odoo Host Manager​

The manager pushes its own jails - ohm-login and ohm-4xx - and surfaces bans on its Threat protection page. Its own manual covers the attribution rules and the same proxy warning from the other side: see Related.

The manager also licenses this service, as a sponsorship. When its own license stops carrying automatic attack blocking it withdraws the sponsorship, and every current ban here is lifted as on any lapse. See Licensing.

Notifications​

The service reports bans by mail when a recipient is configured, on the console's SMTP page. Leave the recipient empty and nothing is sent of its own accord.

  • It sends the mail itself, over SMTP. fail2ban's own mail action has no mail server to hand a message to in this image, so a jail configured with it would run, ban, and never deliver.
  • A ban is noticed whoever issued it: a jail, a ban by hand, the blacklist, or fail2ban restoring its bans after a restart. The first check after a start only learns what is already banned, so a restart does not mail every ban in force.
  • Events are collected and sent as one message, every Smtp__DigestSeconds (five minutes by default). At 0, a host being scanned sends thousands of messages an hour and gets rate-limited by its own relay.
  • Settings saved on the SMTP page replace the environment's entirely, working or not, until they are removed. The password is never shown again; leaving it out of a later save keeps the one in force.
  • Cc and Bcc send copies; Bcc keeps those addresses hidden from the other recipients.
  • Each message names the country of every address in it, as a table, with a plain-text version for mail programs that show no formatting.
  • A daily summary, switched on on the SMTP page, sends one message a day with a world map of where the banned addresses came from and a table of the day's bans. It runs on the Daily ban summary schedule on the Maintenance page and sends nothing on a day without bans.
Last updated on