fail2ban, A Ban That Exists In The Kernel
fail2ban from EPEL on EL 10, banning into nftables, with the jails and the server settings as .local files beside the package's own. The live test drives a jail past its limit and reads the ban out of nft rather than out of a status page, unbans it and reads the rule's absence, and checks that the same burst from an address in ignoreip is never banned. Original role, live-tested on Rocky Linux 10.
Verification
Live-testedReally deployed to a container sandbox, proven idempotent (a second run changes nothing), verified against the role’s assertions, then torn down.
Conformance
- Static validation (yamllint · ansible-lint)
Provenance
- SHA-256 checksum
- Signature (pending)
Functional
- Live-tested - applied, verified, destroyed
Last verified 2026-09-26 · podman 4.9.3 · ansible 2.21.4 · how we verify
Cite it in your README
badge · attributionPaste this beside the module in the repository that uses it. The badge is rendered from this artifact's verification record, so it reads live-tested because the record says so, and the link lands on this page.
[](https://www.iac-bazaar.com/catalog/ansible-fail2ban?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)
Ansible role 1.0.0, live-tested on IaC Bazaar: [fail2ban, A Ban That Exists In The Kernel](https://www.iac-bazaar.com/catalog/ansible-fail2ban?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)
```yaml
# fail2ban, A Ban That Exists In The Kernel: https://www.iac-bazaar.com/catalog/ansible-fail2ban (download from your IaC Bazaar account)
```Preview:
Documentation
fail2ban
Bans that exist in the kernel, not just in a status page. The role installs
fail2ban with the nftables action, writes the server settings and the jails as
.local files beside the package's own, and enables the unit the distribution
ships. The live test drives a jail past its limit and then reads the ban out of
nft, unbans it, and reads the rule's absence.
No download, and no version to pin. fail2ban is packaged in EPEL, so the role enables the repository and installs it by name, taking the filters and the unit the distribution ships. What the role owns is the policy: which jails, how many tries, how long a ban lasts, who is never banned, and the proof that a ban reaches the kernel.
.local, never the package's .conf. fail2ban is designed to be configured
in jail.local and fail2ban.local, which the package's files include: an
upgrade replaces jail.conf and leaves this role's policy untouched. The filters
are the package's own, so a fail2ban update improves them without a new release
of this role.
The live test needs CAP_NET_ADMIN. The container the lane boots carries
it, and without it the kernel refuses the very call this role exists to make,
so the test would pass having changed nothing. The lane is therefore run as
live-ansible.sh ... --cap-add=NET_ADMIN, and the receipt records it: a pass
under an added capability is not the same claim as a pass without one.
The sshd jail reads the journal, and that is correct. The package's
jail.conf sets the sshd jail's backend to systemd, which is where sshd on EL 10
logs; /var/log/secure exists only on a host that also runs rsyslog, so a jail
pointed at it would silently watch an empty file. This role leaves that alone,
and proves the filter with the tool fail2ban ships for it: fail2ban-regex
against a real failure line reports "1 matched, 0 missed".
The ban path is driven through the recidive jail, which reads fail2ban's own
log and is therefore file-backed. It is a jail worth having in its own right - it
catches the addresses that come back after a ban expires - and it exercises the
same filter, jail, action and unban path as every other jail.
A log line without a date is invisible to fail2ban. The jail reads the file, matches nothing, and reports a healthy zero, which looks identical to "no attacks yet". The live test dates every line it injects for exactly this reason.
The ban is asserted in the kernel and after the unban. A jail's own counter
moving proves fail2ban decided to ban; it does not prove anything reached
netfilter. The verify reads nft -j list ruleset for the address in
f2b-table, and then checks the unban removed it - a released address that
stays blocked is the failure nobody notices.
The ignore configuration is tested through the filter, not through banip. A
manual fail2ban-client set <jail> banip bans an address in ignoreip anyway,
so it proves nothing. The live test writes the same burst for 127.0.0.1 into
the watched log and asserts no ban appears - that is what decides whether a fleet
rollout locks out the operator who performed it.
There are TWO settings doing that work, and a mutation check found it.
Removing 127.0.0.1/8 from ignoreip changes nothing on its own, because
ignoreself still covers every address the host holds. Both are variables here,
and the test's control turns off both: a claim that only one of them protects the
operator would have been untrue.
License
Commercial - IaC Bazaar EULA. (c) IaC Bazaar.
Usage code & full reference need an account
The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.
- Variables
- Test
Related modules
ansible-aide
AIDE from AppStream on EL 10: a watched tree, a baseline database built once, and the oneshot unit and timer the package does not ship. The live test passes on an unchanged host, FAILS when a file appears inside a watched path and names it, ignores one inside an excluded path, and passes again once the change is gone. Original role, live-tested on Rocky Linux 10.
ansible-authelia
Authelia from the upstream release (sha256-verified) as a hardened system service on loopback with file users and sqlite; its secrets are generated once on the host and reach the service as AUTHELIA_*_FILE variables. The live test hashes a password with Authelia's hasher, logs in, sees a wrong password refused and an anonymous visitor sent to the portal. Original role, live-tested on Rocky 10.
ansible-bandit
bandit on EL 10 from PyPI into a venv of its own with a link in the PATH; the live test runs pip check, then scans a module that passes a string to subprocess.call with shell=True (B602, High, exit 1) and a clean module (exit 0). Pinned. Original role, live-tested on Rocky Linux 10.
ansible-base-hardening
An SSH hardening drop-in sshd reads back: root login and password authentication off, MaxAuthTries 4, idle timeouts. A sysctl security profile under /etc/sysctl.d that a boot applies, and chrony installed with the distribution preset enabling it. The evidence is sshd's own effective configuration, read with sshd -T on Rocky Linux 10.
ansible-boundary
boundary on EL 10 from releases.hashicorp.com; SHA256SUMS is signature-checked against HashiCorp's key before get_url trusts it, the live test re-checks both, then runs authenticate against a dead address ('connection refused') and database init with a throwaway config (parsed, root key loaded, then the database refused). Pinned. Original role, live-tested on Rocky Linux 10.
ansible-dockle
dockle on EL 10 from the GitHub release; get_url refuses it unless its SHA-256 is in the vendor's checksums file, and the live test re-checks it, then scans a one-layer image whose config names no user, expecting CIS-DI-0001 in the output, exit code 1 with --exit-level warn, and the warning counted in the JSON form. Pinned. Original role, live-tested on Rocky Linux 10.