Fail2Ban Jails ​
A jail is the unit that makes Fail2Ban act. It ties a log file, a filter, thresholds, and an action into one rule that watches a service and bans the addresses that abuse it.
Overview ​
URL: /admin/settings/fail2ban-jails
Open it from Settings > Security > Fail2Ban in the sidebar, then pick the Jails tab. The tab carries a counter showing how many jails exist.
The page has two lists: the jails this panel manages at the top, and the jails present on the server below.
Shipped jails ​
AdminBolt ships jails for the services it manages, and their bans are enforced by the server firewall:
| Jail | Protects |
|---|---|
sshd | SSH logins. |
postfix | The mail server. |
apache-bad-traffic, apache-connect-abuse | The web server. |
bolt-panel | Panel logins. Repeated failed sign-ins are banned, covering admin, reseller, and client sign-in alike. Since panel 1.9.0 the ban applies to the panel port only and lasts a limited time. A banned address can still reach SSH, websites, and mail, open SSH sessions stay connected, and the ban follows a change of the panel port. |
bolt-dovecot | IMAP and POP3 logins, since panel 1.9.3. Repeated failed mailbox logins ban the address on the IMAP, IMAPS, POP3, and POP3S ports. See Mail login jails. |
bolt-roundcube | Webmail (Roundcube) logins, since panel 1.9.3. Repeated failed webmail logins ban the address on HTTP, HTTPS, and the panel port, and the ban follows a change of the panel port. See Mail login jails. |
cpguard-lfd | Only on a server with CPGuard, since panel 1.9.3. Blocks, on every port, the addresses CPGuard's login failure daemon bans, so those blocks show on the Fail2Ban pages and can be lifted there. It is added with CPGuard's login daemon and removed with CPGuard. |
The bolt-panel jail is installed on new servers and added to existing installations when they are upgraded. Existing installations also pick up the enforcing ban action on upgrade, and any tuning you made to the shipped jails is kept. Upgrading to 1.9.0 moves a bolt-panel jail that still uses the shipped ban action to the panel port; a jail whose action you changed yourself is left as it is, and the thresholds are never changed.
Mail login jails ​
Since panel 1.9.3, the bolt-dovecot and bolt-roundcube jails ban addresses after repeated failed mailbox and webmail logins. New installations get both. Updating to 1.9.3 adds whichever is missing on a server whose Fail2Ban profiles were applied, and installing Roundcube later adds bolt-roundcube. A jail you already have keeps your settings.
The two jails never ban the server's own addresses, its active Network IPs, or the addresses on the Fail2Ban whitelist. When you add, change, or remove a Network IP or a whitelist entry, the jails follow on their own.
Cloud servers behind NAT ​
On a cloud server behind NAT, the network interface holds only a private address and the public one is not on the server. On AWS, Google Cloud, and Azure the panel reads the server's public IPv4 address from the cloud provider and keeps it out of both jails.
While a server holds only private addresses and its public address is not known, both jails are paused so they cannot ban the server itself. The page then shows Mail login jails are paused, and Health raises the same warning. Add the server's public IP as a Network IP, and the jails resume on their own.
The webmail jail and Roundcube ​
The bolt-roundcube jail counts the failed logins that Roundcube 0.1.11 and later record. Updating the panel to 1.9.3 updates an older Roundcube. Until a newer Roundcube is installed, the page shows Failed webmail logins are not counted yet; update Roundcube in Modules, and the jail starts counting right after the update.
Before the webmail jail loads, the panel checks the log it reads. While that log cannot be used, for example because something else was put in its place, the jail stays switched off and the page shows The webmail jail is not running with the reason and the next step. The panel checks again regularly, and right away when you save the bolt-roundcube jail, and turns the jail back on by itself once the log is in order. When the panel cannot check the log at all, it keeps the jail off the same way and says so.
While the webmail jail has to stay off, a change to another jail that reloads Fail2Ban is not applied to the server if switching the webmail jail off did not work. The message says so; try again in a minute.
The jail list ​
Each row shows:
- Name - the jail name (sortable).
- Port - the ports it watches, for example
http, httpsorssh(sortable). - Filter - the filter it matches lines with (sortable).
- Action - what happens on a ban. Empty means the default ban action from Fail2Ban Settings (sortable).
- Log Path - the file it reads, for example
/var/log/secure(sortable). - Enabled - a switch. Turning it applies the change on the server, not only in the panel (sortable). Since panel 1.9.3, when the server refuses the change, the switch goes back to its previous position and the notification gives the reason. See When the server refuses a jail change.
Row actions are Edit, Statistics (a read-only view of that jail's counters, with a message that fits the jail's state, for example that a disabled jail has to be enabled first), and Delete. A search box filters by name, and the page size can be set to 5, 10, 25, 50, or All.
The lower list, Local Jails, is the read-only set of jails present in the server's own configuration, with its own search box.
When the server refuses a jail change ​
Since panel 1.9.3 creating, editing, deleting, and switching a jail on or off reach Fail2Ban first, and the panel records the change only once Fail2Ban has applied it. When the server refuses, the notification says "Nothing was saved, because the change was not applied to Fail2Ban.", followed by the cause and a correlation ID, and the jail stays as it was. A refused change therefore never shows in the jail list as applied. A mail login jail you switched on stays on in the list while the panel pauses it on the server, so it runs again once the cause is cleared: see Cloud servers behind NAT and The webmail jail and Roundcube.
Jails Status ​
Since panel 1.9.0 the page carries a Jails Status block with the counters of every jail Fail2Ban runs on the server, including jails the panel did not create:
- Total Failed - failed attempts counted by the jail.
- Total Banned - addresses the jail has banned.
- Currently Banned - addresses banned right now.
The totals count from the last start of the jail and reset when Fail2Ban or the jail restarts. The block loads on its own after the page opens, so the list is usable at once. If the counters cannot be read, the block says so; reload the page to try again. When no jail is reported at all, Fail2Ban may be stopped or no jail is enabled.
The old Fail2Ban Status address, /admin/fail2ban-status, leads to this page.
Creating a jail ​
New Jail opens Create Jail at /admin/settings/fail2ban-jails/create. The form is grouped into General, Detection, and Thresholds & Backend.