In der Theorie ist es einfach: Wer zu viele 404-Fehler (Seite nicht gefunden) oder 403-Fehler (Zugriff verweigert) auf einem Webserver produziert, ist wahrscheinlich ein Bot und gehört ausgesperrt. Doch ein kleiner Fehler im regulären Ausdruck (Regex) kann dazu führen, dass völlig legitime Nutzer plötzlich vor verschlossenen Türen stehen.

Wie man generell 404/403-Fehler durch Fail2ban berücksichtigt wird in dem Beitrag beschrieben: Fail2ban & WordPress: Bots aussperren

In einem aktuellen Fall wurde ein Redakteur einer WordPress-Multisite-Umgebung (Apache Webserver) ständig gebannt, obwohl er nur ganz normal im Backend arbeitete. Die Log-Analyse zeigte das Paradoxon:

www.beispiel-seite.de 203.0.113.1 - - [22/Apr/2026:09:00:08 +0200] "GET /wp-includes/js/thickbox/thickbox.js HTTP/1.1" 200 4032 ...

Obwohl der Statuscode 200 (Erfolg) war, schlug Fail2ban zu. Warum? Der Filter suchte nach (404|403|400). Da die Dateigröße der übertragenen JavaScript-Datei zufällig 4032 Bytes betrug, fand der Regex die Ziffernfolge „403“ und wertete dies als bösartigen Zugriff.

Die Gefahren von Overblocking

• Aussperren von Administratoren: Da Redakteure oft viele Anfragen im Backend erzeugen, erreichen sie das Limit (maxretry) zuerst.
• Störung von WordPress-Diensten: WordPress nutzt oft die REST-API oder AJAX. Ein falsch konfigurierter Filter blockiert diese Prozesse.
• Frustrierte Nutzer: Ein automatischer Ban von 24 Stunden für einen Tippfehler ist für echte Nutzer nicht akzeptabel.

Überarbeitung bzw. Präzision in der Konfiguration

Um dieses Problem zu lösen, muss der Regex sicherstellen, dass nur echte HTTP-Statuscodes gefunden werden.

1. Den Filter schärfen

In der Datei /etc/fail2ban/filter.d/apache-404-403.conf wird der Regex so angepasst, dass nach der Zahl zwingend ein Leerzeichen folgen muss. Damit wird aus der 403 in 4032 kein Treffer mehr.

Vorher (Fehlerhaft):

failregex = ^\S+ <HOST> - - \[.*\] "(GET|POST|HEAD) .* HTTP/.*" (404|403|400)

Nachher (Sicher):

# Das Leerzeichen nach der Klammer ist der entscheidende "Anker"
failregex = ^\S+ <HOST> - - \[.*\] "(GET|POST|HEAD) \S+ HTTP\/\d(?:\.\d)?" (404|403|400) 

2. WordPress-Ausnahmen definieren

Um die Stabilität im Backend zu erhöhen, ignorieren wir typische WordPress-Pfade, die oft harmlose Fehler produzieren können.

ignoreregex = /wp-admin/admin-ajax.php
              /wp-json/.*
              .*robots.txt.*
              .*favicon.ico.*

3. Die Jail-Parameter anpassen

Ein 24-Stunden-Ban für 404-Fehler ist oft zu hart. Wir haben den Beobachtungszeitraum (findtime) verkürzt, um echten Angriffen (viele Fehler in kurzer Zeit) immer noch das Handwerk zu legen, aber Gelegenheits-Fehler zu verzeihen.

Fail2ban ist ein mächtiges Werkzeug, aber es ist nur so schlau wie sein Regex. Am besten man Testet die Filter immer mal mit fail2ban-regex gegen echte Logzeilen, um sicherzustellen, dass Sie nur die relevanten Ereignisse erwischen und reguläre Redakteure ungestört arbeiten können.