fail2ban Jail-Templates für typische KMU-Server

Brute-Force-Angriffe gehören zum Hintergrundrauschen jedes Servers mit öffentlicher IP. Wer einen frischen Cloud-Server hochfährt, sieht in den Logs binnen Minuten die ersten Anmeldeversuche aus Russland, China und Brasilien. fail2ban ist die seit Jahren bewährte Antwort: Es liest Log-Dateien, erkennt Angriffsmuster per Regex und sperrt die Quell-IP per iptables, nftables oder firewalld. Klingt simpel — in der Praxis scheitert es aber oft an unpassenden Defaults, falsch konfigurierten Backends oder daran, dass jeder Dienst seine eigenen Log-Formate hat.

Dieser Artikel liefert produktionsreife Jail-Templates für die typischen Dienste eines KMU-Servers: SSH-Zugang, Mailserver mit Postfix und Dovecot, Nextcloud, Vaultwarden und Authentik als Identity-Provider. Zusätzlich erklären wir die Recidive-Jail für Wiederholungstäter und warum die Kombination aus fail2ban und Cloudflare WAF mehr ist als die Summe ihrer Teile.

Basis-Setup und sinnvolle Default-Werte

fail2ban 1.1 (Stand 2026) liegt in den Repos von Debian 13 und Ubuntu 24.04 LTS vor. Statt die mitgelieferte jail.conf zu ändern, legen Sie sämtliche Anpassungen in /etc/fail2ban/jail.local ab — Updates überschreiben dann nichts.

[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@firma.de
sender = fail2ban@server.firma.de
mta = sendmail
action = %(action_mwl)s

Wichtig: backend = systemd liest Logs direkt aus dem Journal und ist deutlich performanter als das alte Polling auf Dateien. Die ignoreip-Liste sollte unbedingt Ihre statischen Büro-IPs und das interne Management-Netz enthalten — sonst sperren Sie sich irgendwann selbst aus.

SSH-Jail und die Port-Knocking-Frage

Die SSH-Jail ist Pflicht. Wir empfehlen aggressivere Werte als die Defaults, weil legitime Nutzer sich selten viermal vertippen:

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

Häufige Diskussion: Reicht fail2ban oder braucht es zusätzlich Port-Knocking? Unsere Empfehlung für KMU: Port-Knocking ist Security through Obscurity und bricht jedes seriöse Monitoring (Uptime-Checks, Ansible-Provisionierung). Wesentlich besser sind drei Maßnahmen kombiniert: SSH ausschließlich per Public-Key (PasswordAuthentication no), Root-Login gesperrt (PermitRootLogin no), und der SSH-Port hinter ein WireGuard-VPN oder ein Tailscale-Tailnet gestellt. Wer SSH dennoch öffentlich exponieren muss, dem reicht fail2ban plus ein nicht-standardmäßiger Port (z. B. 2222), um 99 % des Hintergrundrauschens zu eliminieren.

Mailserver: Postfix SASL und Dovecot

Mailserver sind das beliebteste Brute-Force-Ziel nach SSH, weil ein erfolgreich übernommener SMTP-Account sofort als Spam-Relay missbraucht werden kann. Diese zwei Jails gehören auf jeden 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

Achten Sie darauf, dass Postfix mit smtpd_sasl_authenticated_header = yes läuft — sonst sieht fail2ban die Quell-IP nicht zuverlässig. Bei Dovecot empfehlen wir parallel auth_failure_delay = 2s in der Dovecot-Konfiguration, das verlangsamt Angriffe schon vor dem Ban.

Nextcloud, Vaultwarden und Authentik

Web-Anwendungen schreiben ihre Login-Versuche nicht in syslog, sondern in eigene JSON- oder Klartext-Logs. fail2ban bringt für die meisten KMU-typischen Dienste keine fertigen Filter mit — wir liefern sie selbst.

Nextcloud 30 schreibt Login-Fehlversuche nach /var/www/nextcloud/data/nextcloud.log. Der Filter:

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

Die zugehörige Jail:

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

Vaultwarden (die Rust-Implementierung von Bitwarden) bietet ab Version 1.32 strukturiertes Logging. Filter:

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

Authentik als zentraler Identity-Provider hat zwei relevante Logs: events.failed_login und Admin-Logins. Wir empfehlen, Authentik-Events per syslog an den Host zu schicken und dort eine Jail mit bantime = 24h und maxretry = 5 zu fahren. Wer Authentik in Kubernetes betreibt, sollte zusätzlich CrowdSec evaluieren — fail2ban ist für Container-Umgebungen suboptimal.

Recidive: die Jail für Wiederholungstäter

Der eigentliche Mehrwert kommt aus der Recidive-Jail. Sie liest das fail2ban-eigene Log und sperrt IPs, die innerhalb einer Woche mehrfach in anderen Jails aufgefallen sind — für deutlich längere Zeit.

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

In der Praxis fängt diese Jail die hartnäckigen Angreifer aus Botnetzen ab, die nacheinander SSH, SMTP und Webformulare durchprobieren. Vier Wochen Allports-Ban ist hart, aber für reine Angriffsquellen vertretbar.

Empfohlene Ban-Zeiten im Überblick

Jail	maxretry	findtime	bantime	Begründung
sshd	3	5 min	24 h	Brute-Force ist primäres Ziel
postfix-sasl	3	10 min	12 h	Spam-Relay-Risiko
dovecot	5	10 min	6 h	Mobile Clients neigen zu Re-Auth-Fehlern
nextcloud	5	10 min	6 h	Browser-Cache verursacht False Positives
vaultwarden	4	10 min	12 h	Passwort-Tresor = Hochwertziel
authentik	5	10 min	24 h	Zentrales SSO erfordert höchsten Schutz
recidive	3	1 Woche	4 Wochen	Wiederholungstäter

fail2ban plus Cloudflare WAF: warum beides

Eine gängige Annahme lautet: Cloudflare WAF blockt sowieso alles, fail2ban ist überflüssig. Das stimmt nicht. Cloudflare sieht nur den HTTP/HTTPS-Verkehr, der auch wirklich über das Cloudflare-Proxy läuft. SSH, SMTP, IMAP und alle nicht-Cloudflare-Subdomains landen weiterhin direkt bei Ihrem Server. Außerdem ist die Cloudflare WAF auf Pattern und Bot-Scoring trainiert, fail2ban dagegen auf konkrete Auth-Versuche.

Die elegante Kombination: fail2ban erkennt den Angriff und meldet die IP per cloudflare-token Action an die Cloudflare-API. Cloudflare blockt die IP dann global im Edge-Netzwerk — bevor sie überhaupt zu Ihrem Server gelangt. Beispiel-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"}'

Damit sparen Sie Bandbreite, schützen Ihre Dienste auch außerhalb der HTTP-Ebene und nutzen Cloudflare als globalen Schutzschild. Wichtig: nur sinnvoll bei tatsächlichen Wiederholungstätern (Recidive-Jail), nicht bei jedem einzelnen Fehlversuch.

Fazit

fail2ban ist ein 20 Jahre altes Werkzeug, das in 2026 nichts an Relevanz verloren hat — im Gegenteil, mit systemd-Backend und nftables-Integration ist es performanter als je zuvor. Mit den hier gezeigten Templates schützen Sie SSH, Mail, Nextcloud, Vaultwarden und Authentik in unter einer Stunde Konfigurationsaufwand. Wer die Recidive-Jail aktiviert und die Cloudflare-Integration ergänzt, hebt das Schutzniveau auf Enterprise-Standard.

DATAZONE härtet Linux-Server für KMU mit individuell angepassten fail2ban-Templates, SSH-Hardening und Integration in zentrale SIEM-Lösungen. Wir unterstützen Sie bei der Linux-Administration, Backup-Konzepten und der Anbindung an Ihre OPNsense-Firewall. Sprechen Sie uns an: Kontakt aufnehmen.