Warum die Basis-Konfiguration allein oft nicht reicht
Eine Standard-Fail2ban-Installation schützt vor allem den SSH-Login. Web-Anwendungen (Nginx, WordPress) haben eigene Angriffsmuster — Brute-Force gegen /wp-login.php, automatisierte Scans nach verwundbaren Pfaden, XML-RPC-Missbrauch. Ohne eigene Jails dafür läuft Fail2ban zwar, schützt aber nur einen Teil der tatsächlichen Angriffsfläche.
Fail2ban Basis-Konfiguration
apt install -y fail2ban
# /etc/fail2ban/jail.local — niemals jail.conf direkt bearbeiten,
# das wird bei Paket-Updates überschrieben
cat > /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
maxretry = 5
findtime = 600
bantime = 3600
destemail = [email protected]
sendername = Fail2ban
mta = sendmail
action = %(action_mwl)s
ignoreip = 127.0.0.1/8 192.168.0.0/24
[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
maxretry = 3
bantime = 86400
EOF
systemctl restart fail2ban
ignoreip ist der wichtigste Eintrag in der ganzen Konfiguration — wer die eigene Büro-IP oder das VPN-Subnetz vergisst, kann sich bei einem Tippfehler im eigenen Login selbst aussperren, und zwar für die volle bantime.
Nginx-Schutz
cat >> /etc/fail2ban/jail.local << 'EOF'
[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
[nginx-botsearch]
enabled = true
filter = nginx-botsearch
port = http,https
logpath = /var/log/nginx/access.log
maxretry = 2
[nginx-noscript]
enabled = true
port = http,https
filter = nginx-noscript
logpath = /var/log/nginx/access.log
maxretry = 6
EOF
nginx-botsearch fängt automatisierte Scans nach typischen Angriffszielen ab (/wp-admin, /.env, /phpmyadmin auf Servern, die das gar nicht hosten) — mit maxretry = 2 bewusst aggressiv eingestellt, da ein einzelner solcher Zugriffsversuch schon ein starkes Bot-Signal ist.
WordPress Brute-Force-Schutz
cat > /etc/fail2ban/filter.d/wordpress.conf << 'EOF'
[Definition]
failregex = ^<HOST> .* "POST /(wp-login|xmlrpc)\.php HTTP.*" (200|403)
ignoreregex =
EOF
cat >> /etc/fail2ban/jail.local << 'EOF'
[wordpress]
enabled = true
filter = wordpress
port = http,https
logpath = /var/log/nginx/access.log
maxretry = 3
findtime = 300
bantime = 86400
EOF
systemctl reload fail2ban
xmlrpc.php gehört mit in den Filter, nicht nur wp-login.php — XML-RPC erlaubt bei älteren WordPress-Konfigurationen Multicall-Angriffe, bei denen hunderte Passwort-Versuche in einer einzigen HTTP-Anfrage stecken und einen naiven, nur auf wp-login.php beschränkten Filter komplett umgehen.
Status und Verwaltung
fail2ban-client status
fail2ban-client status nginx-http-auth
fail2ban-client status wordpress
# IP manuell sperren oder entsperren
fail2ban-client set sshd banip 1.2.3.4
fail2ban-client set sshd unbanip 1.2.3.4
# Gesperrte IPs einsehen
iptables -L f2b-sshd -n --line-numbers
journalctl -u fail2ban -f
Der unbanip-Befehl ist häufiger nötig, als man denkt — legitime Nutzer mit dynamischer IP oder mobiler Verbindung landen gelegentlich in denselben IP-Bereichen wie zuvor gesperrte Angreifer.
Recidive Jail — Wiederholungstäter dauerhaft sperren
cat >> /etc/fail2ban/jail.local << 'EOF'
[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = iptables-allports
bantime = 604800
findtime = 86400
maxretry = 5
EOF
systemctl reload fail2ban
Das Recidive-Jail beobachtet die Fail2ban-eigenen Logs: Wer innerhalb von 24 Stunden fünfmal in irgendeinem anderen Jail gesperrt wurde, bekommt eine Woche Vollsperre über alle Ports. Vor der Aktivierung unbedingt ausgiebig mit den regulären Jails testen — ein zu aggressiv konfiguriertes Recidive-Jail kann auch legitime, aber fehlerhaft konfigurierte Clients (z.B. ein Monitoring-Tool mit falschem Passwort) versehentlich langfristig aussperren.
FAQ
Kann Fail2ban legitime Benutzer sperren?
Ja — deshalb ist ignoreip für eigene IPs und VPN-Subnetze Pflicht, nicht optional. Recidive sollte erst nach ausgiebigem Test der Basis-Jails aktiviert werden.
Ersetzt Fail2ban eine Web Application Firewall?
Nein — Fail2ban reagiert reaktiv auf Log-Muster (nach mehreren Fehlversuchen), eine WAF wie ModSecurity oder Cloudflare filtert proaktiv auf Request-Ebene. Beide ergänzen sich, ersetzen sich nicht gegenseitig.
Fazit
Fail2ban mit erweiterten Jails für Nginx und WordPress schließt eine reale Lücke, die die reine SSH-Basiskonfiguration offen lässt — automatisierte IP-Sperrung ohne manuell gepflegte Blacklists.
Ich richte Fail2ban und weitere Server-Härtungsmaßnahmen für Unternehmen in Heidelberg und der Rhein-Neckar-Region ein. Anfragen.