Kurz gesagt: Fail2ban liest Logdateien und sperrt Adressen in der Firewall, die innerhalb eines Zeitfensters zu oft auffallen. Für Nginx und Apache bringt es fertige Jails wie nginx-botsearch oder apache-noscript mit; eigene Filter testen Sie mit fail2ban-regex. Einstellungen gehören in die jail.local, Ihre eigenen Adressen in ignoreip, Wiederholungstäter fängt das recidive-Jail. Gegen einzelne gezielte Angriffe hilft Fail2ban nicht, gegen Massenscans schon.
Wenn die Logs voller Scanner sind
Wer in diesen Tagen die Zugriffsprotokolle seiner Webserver ansieht, findet sie oft voll mit Anfragen auf Pfade, die es gar nicht gibt: alte Admin-Oberflächen, Testdateien, bekannte Schwachstellen anderer Produkte. In einer Lage wie PHP2Shell kommt gezielte Suche nach verwundbaren Servern hinzu: Cloudflare und Patchstack berichteten von Angriffsversuchen, Unit 42 zählte mehr als 22,6 Millionen exponierte, potenziell verwundbare Instanzen.
Fail2ban ist ein bewährtes Werkzeug gegen diese Masse. Es liest Logdateien, erkennt mit Filtern auffällige Einträge und sperrt die Absenderadresse für eine festgelegte Zeit in der Firewall. Das entlastet den Server, verringert das Lograuschen und macht systematisches Durchprobieren aus einer Quelle mühsamer.
Was Fail2ban nicht kann, ist ebenso wichtig: Eine einzelne Anfrage, die eine Lücke ausnutzt, wird nicht verhindert. Gegen PHP2Shell hilft nur das PHP-Update. Wie automatisierte Angriffe ablaufen, beschreibt Massenscans nach ungepatchtem PHP.
Fail2ban für Nginx und Apache: die mitgelieferten Jails
Ein Jail verbindet einen Filter mit einer Logdatei und einer Sperraktion. Die mitgelieferte jail.conf enthält bereits Jails für Webserver. Sie sind standardmässig abgeschaltet und werden einzeln aktiviert.
| Jail | Webserver | Erkennt |
|---|---|---|
nginx-http-auth |
Nginx | fehlgeschlagene HTTP-Basic-Anmeldungen |
nginx-limit-req |
Nginx | Anfragen, die das Rate-Limit von Nginx überschreiten |
nginx-botsearch |
Nginx | Suche nach typischen, nicht vorhandenen Pfaden |
nginx-bad-request |
Nginx | fehlerhafte Anfragen |
apache-auth |
Apache | fehlgeschlagene Anmeldungen |
apache-badbots |
Apache | bekannte schädliche Bot-Kennungen |
apache-noscript |
Apache | Aufrufe nicht vorhandener Skripte |
apache-overflows |
Apache | überlange Anfragen |
apache-botsearch |
Apache | Suche nach typischen, nicht vorhandenen Pfaden |
php-url-fopen |
beide | bestimmte Muster von URL-Einbindungsversuchen |
recidive |
beide | Adressen, die Fail2ban wiederholt gesperrt hat |
Die Standardwerte der mitgelieferten Konfiguration sind eher mild: Sperre für 10 Minuten nach 5 Treffern in 10 Minuten. Für Webserver mit viel Scan-Verkehr lohnt eine längere Sperre und ein ansteigender Faktor für Wiederholungen.
Die Grundkonfiguration in der jail.local
Die jail.conf sagt selbst, dass sie nicht verändert werden soll, weil Updates sie ersetzen. Eigene Werte gehören in /etc/fail2ban/jail.local. Das folgende Beispiel für Nginx setzt sinnvolle Standards und aktiviert passende Jails:
# /etc/fail2ban/jail.local
[CHFAULT]
# Eigene feste Adressen eintragen (Beispieladresse ersetzen)
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
bantime = 1h
findtime = 10m
maxretry = 5
bantime.increment = true
[nginx-http-auth]
enabled = true
[nginx-botsearch]
enabled = true
[recidive]
enabled = true
bantime = 1w
findtime = 1d
Für Apache aktivieren Sie stattdessen etwa apache-auth, apache-noscript und apache-botsearch. Die Logpfade bringt Fail2ban je Distribution mit; weichen Ihre Pfade ab, setzen Sie logpath im jeweiligen Jail. Liest Ihr System Logs nur über das Journal, hilft backend = systemd.
Ein eigener Filter für Massenanfragen auf PHP-Dateien
Ein typisches Muster in der aktuellen Lage sind viele Anfragen in kurzer Zeit auf PHP-Dateien, die es nicht gibt. Ein eigener Filter erkennt das am Statuscode 404. Er beschreibt nur, was in Ihrem eigenen Log steht:
# /etc/fail2ban/filter.d/nginx-php-404.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST|HEAD) [^"]*\.php[^"]*" 404
ignoreregex =
# Ergänzung in /etc/fail2ban/jail.local
[nginx-php-404]
enabled = true
port = http,https
filter = nginx-php-404
logpath = /var/log/nginx/access.log
maxretry = 20
findtime = 1m
bantime = 1h
Bevor Sie den Filter aktivieren, prüfen Sie ihn gegen das echte Log. So sehen Sie, wie viele Zeilen er trifft und ob legitime Zugriffe dabei sind:
fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-php-404.conf
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status nginx-php-404
# Eine versehentlich gesperrte Adresse freigeben
sudo fail2ban-client set nginx-php-404 unbanip 203.0.113.25
Wählen Sie die Schwelle grosszügig. Ein Crawler, der veraltete Links abarbeitet, oder ein Monitoring-Dienst darf nicht in der Sperre landen.
Die häufigsten Fallen
Fail2ban ist schnell installiert, aber leicht falsch eingesetzt. Diese Punkte sollten Sie vor dem produktiven Einsatz prüfen:
- Selbstaussperrung: Büro-, VPN- und Monitoring-Adressen gehören in
ignoreip, bevor Jails aktiv werden. - Vorgeschaltete Dienste: Hinter CDN oder Load Balancer sieht Fail2ban ohne Anpassung nur deren Adressen. Mehr dazu im Ratgeber Admin-Logins gegen Brute Force schützen.
- Logrotation: Nach dem Wechsel der Logdatei muss Fail2ban die neue Datei lesen. Prüfen Sie nach der ersten Rotation, ob die Jails weiter Treffer zählen.
- Firewall-Zusammenspiel: Fail2ban trägt Sperren in die Firewall ein. Wer seine Firewall mit einem vollständigen Neuladen des Regelwerks verwaltet, kann diese Einträge dabei löschen. Wie Sie die Firewall selbst aufbauen, steht unter Firewall für Webserver: Nur nötige Ports öffnen.
- IPv6: Angriffe kommen auch über IPv6. Prüfen Sie, ob Ihre Sperraktion beide Protokolle abdeckt.
Werten Sie die Sperrlisten regelmässig aus. Häufen sich Sperren aus bestimmten Netzen oder auf bestimmte Pfade, ist das ein Hinweis auf gezielte Suche und ein Anlass, die betroffene Anwendung genauer anzusehen.
Fazit: Ein Werkzeug gegen Masse, nicht gegen alles
Fail2ban ist schnell eingerichtet und nimmt Webservern einen Teil des Dauerbeschusses ab. Die mitgelieferten Jails decken typische Muster ab, eigene Filter lassen sich mit fail2ban-regex gefahrlos gegen echte Logs testen, und das recidive-Jail sorgt dafür, dass hartnäckige Quellen länger draussen bleiben.
Überschätzen sollten Sie es nicht. Fail2ban reagiert auf Wiederholung, nicht auf den ersten Treffer, und es sieht nur, was in den Logs steht. Gegen eine Lücke wie PHP2Shell hilft allein das Update, gegen verteilte Angriffe aus vielen Adressen hilft Fail2ban kaum. Seinen Wert entfaltet es als eine Schicht unter mehreren: neben einer schlanken Firewall, einer gehärteten Webserver-Konfiguration, Zwei-Faktor-Anmeldung und einer Überwachung, die Auffälligkeiten nicht nur sperrt, sondern auch meldet.
Wie hilft PHP SOS konkret?
- Logs auswerten: Wir sehen uns an, welche Muster in Ihren Zugriffsprotokollen auftreten, und wählen passende Jails aus.
- Einrichten und testen: Wir richten Fail2ban mit eigenen Filtern ein, testen jeden Filter gegen echte Logs und tragen Ihre festen Adressen als Ausnahme ein.
- Zusammenspiel klären: CDN, Load Balancer, Firewall und Logrotation stimmen wir so ab, dass Sperren die richtigen Adressen treffen.
- Beobachten: Im Rahmen des Security-Monitorings werten wir Sperren und Auffälligkeiten laufend aus.
Häufige Fragen
Schützt Fail2ban vor PHP2Shell?
Nein. Fail2ban reagiert erst, nachdem eine Adresse mehrfach in den Logs aufgefallen ist. Ein einzelner erfolgreicher Angriff wird dadurch nicht verhindert. Fail2ban senkt aber die Last durch Scanner und macht wiederholte Versuche aus derselben Quelle teurer.
Warum soll ich jail.conf nicht direkt ändern?
Die Datei wird bei Paket-Updates ersetzt, und sie sagt das selbst. Eigene Einstellungen gehören in eine jail.local oder in Dateien unter jail.d. Dort überschreiben sie die Standardwerte gezielt.
Was ist das recidive-Jail?
Ein Jail, das das Protokoll von Fail2ban selbst auswertet. Wer immer wieder gesperrt wird, erhält eine deutlich längere Sperre. In der mitgelieferten Konfiguration beträgt sie eine Woche.
Funktioniert Fail2ban hinter Cloudflare oder einem Load Balancer?
Nur mit zusätzlicher Konfiguration. Ohne sie steht in den Logs die Adresse des vorgeschalteten Dienstes, und eine Sperre träfe alle Besucher. Der Webserver muss dann die echte Besucheradresse übernehmen, und Sperren werden besser beim vorgeschalteten Dienst gesetzt.