fail2ban Jail Templates for Typical SMB Servers

Brute-force attacks are the background noise of every server with a public IP. Spin up a fresh cloud instance and within minutes you will see the first login attempts from Russia, China and Brazil in the logs. fail2ban has been the proven answer for years: it reads log files, detects attack patterns via regex and blocks the source IP via iptables, nftables or firewalld. Sounds simple — in practice it often fails due to unsuitable defaults, misconfigured backends or the fact that every service has its own log format.

This article delivers production-ready jail templates for the typical services of an SMB server: SSH access, mail server with Postfix and Dovecot, Nextcloud, Vaultwarden and Authentik as identity provider. We also explain the recidive jail for repeat offenders and why combining fail2ban with Cloudflare WAF is more than the sum of its parts.

Base setup and sensible defaults

fail2ban 1.1 (as of 2026) is included in the repos of Debian 13 and Ubuntu 24.04 LTS. Instead of editing the shipped jail.conf, put all customisations into /etc/fail2ban/jail.local — updates will never overwrite that file.

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
banaction = nftables-multiport
banaction_allports = nftables-allports
backend = systemd
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8 192.168.0.0/16
destemail = security@company.com
sender = fail2ban@server.company.com
mta = sendmail
action = %(action_mwl)s

Important: backend = systemd reads logs directly from the journal and is significantly more performant than the old file polling. The ignoreip list should definitely include your static office IPs and the internal management network — otherwise you will eventually lock yourself out.

SSH jail and the port-knocking question

The SSH jail is mandatory. We recommend more aggressive values than the defaults, because legitimate users rarely mistype four times in a row:

[sshd]
enabled  = true
port     = ssh
filter   = sshd
maxretry = 3
findtime = 5m
bantime  = 24h

A common discussion: is fail2ban enough or do you also need port knocking? Our recommendation for SMBs: port knocking is security through obscurity and breaks every serious monitoring setup (uptime checks, Ansible provisioning). Three combined measures work much better: SSH exclusively via public key (PasswordAuthentication no), root login disabled (PermitRootLogin no), and the SSH port hidden behind a WireGuard VPN or a Tailscale tailnet. If you absolutely must expose SSH publicly, fail2ban plus a non-standard port (e.g. 2222) is enough to eliminate 99 % of the background noise.

Mail server: Postfix SASL and Dovecot

Mail servers are the most popular brute-force target after SSH, because a successfully compromised SMTP account can immediately be abused as a spam relay. These two jails belong on every Postfix/Dovecot stack:

[postfix-sasl]
enabled  = true
filter   = postfix-sasl
port     = smtp,465,submission,imap,imaps,pop3,pop3s
maxretry = 3
findtime = 10m
bantime  = 12h

[dovecot]
enabled  = true
filter   = dovecot
port     = pop3,pop3s,imap,imaps,submission,465,sieve
maxretry = 5
findtime = 10m
bantime  = 6h

Make sure Postfix runs with smtpd_sasl_authenticated_header = yes — otherwise fail2ban cannot reliably see the source IP. For Dovecot we recommend also setting auth_failure_delay = 2s in the Dovecot configuration, which slows attacks down even before the ban kicks in.

Nextcloud, Vaultwarden and Authentik

Web applications do not write their login attempts to syslog but to their own JSON or plain-text logs. fail2ban does not ship ready-made filters for most typical SMB services — so we provide them ourselves.

Nextcloud 30 writes failed login attempts to /var/www/nextcloud/data/nextcloud.log. The filter:

# /etc/fail2ban/filter.d/nextcloud.conf
[Definition]
failregex = ^.*Login failed.*Remote IP: '<HOST>'.*$
ignoreregex =

The corresponding jail:

[nextcloud]
enabled  = true
filter   = nextcloud
port     = http,https
logpath  = /var/www/nextcloud/data/nextcloud.log
maxretry = 5
findtime = 10m
bantime  = 6h

Vaultwarden (the Rust implementation of Bitwarden) offers structured logging from version 1.32 onwards. Filter:

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <HOST>\..*$
ignoreregex =

Authentik as a central identity provider has two relevant logs: events.failed_login and admin logins. We recommend forwarding Authentik events via syslog to the host and running a jail there with bantime = 24h and maxretry = 5. If you run Authentik on Kubernetes, you should additionally evaluate CrowdSec — fail2ban is suboptimal for container environments.

Recidive: the jail for repeat offenders

The real added value comes from the recidive jail. It reads fail2ban’s own log and bans IPs that have been flagged by other jails several times within a week — for a significantly longer time.

[recidive]
enabled   = true
filter    = recidive
logpath   = /var/log/fail2ban.log
banaction = nftables-allports
bantime   = 4w
findtime  = 1w
maxretry  = 3

In practice this jail catches the persistent attackers from botnets that go through SSH, SMTP and web forms one after another. Four weeks of all-ports ban is harsh, but for pure attack sources it is justified.

Recommended ban durations at a glance

Jail	maxretry	findtime	bantime	Rationale
sshd	3	5 min	24 h	Primary brute-force target
postfix-sasl	3	10 min	12 h	Spam relay risk
dovecot	5	10 min	6 h	Mobile clients prone to re-auth errors
nextcloud	5	10 min	6 h	Browser cache causes false positives
vaultwarden	4	10 min	12 h	Password vault = high-value target
authentik	5	10 min	24 h	Central SSO requires maximum protection
recidive	3	1 week	4 weeks	Repeat offenders

fail2ban plus Cloudflare WAF: why both

A common assumption: Cloudflare WAF blocks everything anyway, fail2ban is redundant. Not true. Cloudflare only sees the HTTP/HTTPS traffic that actually goes through the Cloudflare proxy. SSH, SMTP, IMAP and all non-Cloudflare subdomains still land directly on your server. Furthermore, the Cloudflare WAF is trained on patterns and bot scoring, while fail2ban targets concrete auth attempts.

The elegant combination: fail2ban detects the attack and reports the IP via the cloudflare-token action to the Cloudflare API. Cloudflare then blocks the IP globally at the edge network — before it even reaches your server. Example action:

[Definition]
actionban = curl -s -X POST "https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules" \
  -H "Authorization: Bearer <CFTOKEN>" \
  -H "Content-Type: application/json" \
  --data '{"mode":"block","configuration":{"target":"ip","value":"<ip>"},"notes":"fail2ban"}'

This saves bandwidth, protects your services beyond the HTTP layer and uses Cloudflare as a global shield. Important: only sensible for actual repeat offenders (recidive jail), not for every single failed attempt.

Conclusion

fail2ban is a 20-year-old tool that has not lost any relevance in 2026 — on the contrary, with the systemd backend and nftables integration it is more performant than ever. With the templates shown here, you protect SSH, mail, Nextcloud, Vaultwarden and Authentik in under an hour of configuration work. Anyone who activates the recidive jail and adds the Cloudflare integration raises the protection level to enterprise standard.

DATAZONE hardens Linux servers for SMBs with individually tailored fail2ban templates, SSH hardening and integration into central SIEM solutions. We support you with Linux administration, backup concepts and integration with your OPNsense firewall. Get in touch: contact us.