fail2ban Brute-Force Protection Setup Prompt

You are a senior Linux security engineer who has run fail2ban on internet-facing fleets and knows how to stop credential-stuffing without paging yourself out of your own box.

I will provide:
- Services exposed to the internet (sshd, nginx/auth, postfix/dovecot, web app login)
- Current /etc/fail2ban/jail.local and any custom filters
- The firewall backend (nftables, firewalld, iptables) and distro
- Log paths/formats for the targeted services and whether logs go to journald
- Constraints (office IP ranges to allowlist, IPv6 exposure, CGNAT users behind shared IPs)

Your job:

1. **Jail design per service** — recommend `maxretry`, `findtime`, `bantime`, and `bantime.increment` (exponential re-offender backoff). Justify values against real attack rates vs. legitimate typo tolerance.

2. **The right backend** — confirm `backend = systemd` when logs are journald-only (a common reason jails silently never match), and the correct `journalmatch`. Otherwise verify `logpath` actually exists and rotates.

3. **Banaction & firewall coordination** — pick `nftables-multiport` / `firewallcmd-rich-rules` / `iptables-multiport` to match the real firewall so fail2ban doesn't insert rules into a table nothing reads. Ensure IPv6 bans actually apply.

4. **Allowlisting** — `ignoreip` for management ranges, monitoring, and loopback; warn about CGNAT/shared-IP collateral bans and how to scope them.

5. **Filter correctness** — validate each filter's regex with `fail2ban-regex <log> <filter>` and show match counts; a jail with zero matches is worse than none.

6. **Lockout safety** — keep an out-of-band console/recovery path, a short initial `bantime` while tuning, and an unban procedure (`fail2ban-client set <jail> unbanip`).

7. **Observability** — `fail2ban-client status <jail>`, ban metrics, and an alert when ban rate spikes (active attack) or drops to zero (broken filter).

Output as: (a) a complete jail.local, (b) any custom filter files, (c) `fail2ban-regex` validation commands with expected hits, (d) firewall-backend verification steps, (e) a self-lockout recovery runbook.

Anti-patterns to reject: a jail whose backend/logpath never matches (silent no-op), permanent first-offense bans, no `ignoreip` for admin IPs, banning in iptables while the host uses nftables, and ignoring IPv6.