Logins mit Fail2ban zusätzlich absichern

Letzte Aktualisierung 21.05.2024

Webanwendungen sollten gegen Brute-Force-Angriffe auf den Login geschützt sein. Mit Fail2ban kann eine zusätzliche Schutzschicht geschaffen werden, die Bots abwehrt und die Last von der Webanwendung nimmt. Fail2ban analysiert Log-Dateien und blockiert IP-Adressen nach mehreren fehlgeschlagenen Login-Versuchen.

Beispiel: Shopware 6 Login für den Administrationsbereich

In Shopware 6 gibt der Login-Endpunkt im Administrationsbereich bei einer fehlgeschlagenen Anmeldung den Statuscode 400 Bad Request zurück. Dadurch kann Fail2ban leicht konfiguriert werden, um diese fehlgeschlagenen Logins zu erkennen und zu blockieren.

Ein typischer Log-Eintrag sieht so aus:

127.0.0.1 - - [26/Mar/2024:14:42:00 +0100] "POST /api/oauth/token HTTP/2.0" 400 101 "http://localhost/admin" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0" 551 506

Wichtig sind die IP-Adresse, der Zeitstempel, die Request-Methode (POST), der Pfad und der Statuscode.

Filter-Datei erstellen

Erstelle eine Filter-Datei namens apache-shopware-access.conf im Ordner config/filter.d mit folgendem Inhalt:

[INCLUDES]
before = apache-common.conf

[Definition]
failregex = ^<HOST> \S+ \S+ \[[^\"]*\] "POST /api/oauth/token HTTP/\d(\.\d)?" 400

datepattern = ^[^\[]*\[({DATE})

Jail-Konfiguration

Die Filter werden über sogenannte „Jails“ gesteuert. Erstelle eine Jail-Datei im Ordner config/jail.d mit folgendem Inhalt:

[apache-shopware-access]
enabled  = true
port     = http,https
logpath  = %(apache_access_log)s
maxretry = 10
findtime = 10m
bantime  = 15m

Hier wird der Name des Filters angegeben, die zu blockierenden Ports, der Pfad zu den Log-Dateien und die Bedingungen für das Blockieren (maxretry, findtime, bantime).

Testen des Jails

Zum Testen kann die Aktion dummy verwendet werden, die zu sperrende IP-Adressen nur in eine Logdatei schreibt:

banaction = dummy[target=/usr/local/apache2/fail2ban.sw-access.txt]

Pfade überschreiben

Falls der Pfad %(apache_access_log)s nicht funktioniert, können die Pfade in der Datei paths-overrides.local angepasst werden:

[DEFAULT]
apache_access_log = /home/users/*/logs/*/access.log
apache_error_log = /home/users/*/logs/*/error.log

Fazit

Mit einfachen Filter-Regeln kann ein zusätzlicher Schutz für den Login von Webanwendungen realisiert werden. Da diese Filter auf Log-Dateien zugreifen, können die verfügbaren Daten manchmal nicht ausreichen, um eine genaue Erkennung zu gewährleisten. Bei WordPress liefert der Login-Endpunkt beispielsweise immer den Statuscode 200, unabhängig vom Erfolg des Logins. In solchen Fällen müssen die Einstellungen in der Jail-Konfiguration möglicherweise lockerer gehalten werden.

Weitere Informationen:

https://www.vps-mart.com/blog/prevent-ssh-brute-force-attacks-on-linux-using-fail2ban
https://matthewsetter.com/bruteforce-protection-with-fail2ban/
https://www.nixtree.com/blog/fail2ban-security-feature/