Fail2Ban – Schutz vor Brute-Force-Angriffen

Dank WordPress ist es heute ein Kinderspiel, seinen eigenen Blog zu betreiben. Ein virtueller Server ist schnell gemietet und WordPress ist häufig bereits vorinstalliert. Doch Vorsicht! Hacker und Skriptkiddies durchsuchen tagtäglich das Internet nach möglichen Angriffszielen und ein virtueller Server mit SSH-Zugang oder der Login zum Adminbereich des WordPress-Blogs sind gern gesehene Angriffsziele. Wenn die Angreifer keine Sicherheitslücken finden, die Sie sofort ausnutzen können, probieren sie es mit der Brechstange. Beim sogenannten Brute-Force-Angriff werden einfach so lange Zugangsdaten ausprobiert, bis man durch Zufall den “admin”-Account geknackt hat. Angesichts billig verfügbarer Rechenleistung ist so ein virtueller Einbruch schnell passiert, wenn man keine sicheren Passwörter verwendet. Die Sicherheitssoftware Fail2Ban, die in diesem Artikel im Mittelpunkt steht, bietet darüber hinaus zusätzlichen Schutz. Nach einer kurzen Zusammenfassung der Funktionsweise von Fail2Ban erklären wir die Konfiguration von Fail2Ban für die zwei Webdienste WordPress und Odoo. Für eine eher allgemeinen Beschreibung der Funktionsweise von Fail2Ban empfehlen wir den Artikel F2B: Automatisches System zur Erkennung und Verhinderung von Systemeinbrüchen.

Wie wird Fail2Ban eingesetzt?

Jeder Loginversuch auf einer Webseite oder über SSH wird in einem Linux-System in Log-Dateien protokolliert. Für WordPress wird z.B. folgender Log-Eintrag dokumentiert:

91.127.182.18 - - [01/Jul/2015:00:31:26 +0200] "POST /wissen/wp-login.php HTTP/1.1" 200 
1556 "https://www.ionas.com/wissen/wp-login.php"
"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0"

Diese Zeile besagt, dass jemand am 1. Juli 2015 von der IP-Adresse 91.127.182.18 auf die Seite “wp-login.php” zugegriffen hat. Der Aufruf erfolgte mit einem Firefox Browser der Version 38.

Fail2Ban macht sich diese Log-Dateien zunutze. Es überwacht die Logs und blockiert (englisch “banned”) weitere Zugriffe des Angreifers, wenn eine definierte Anzahl an nicht-erfolgreichen Zugriffen überschritten wird. Die Anzahl der zulässigen Zugriffsversuche und die “Ban”-Dauer lässt sich frei konfigurieren. Fail2Ban ist somit ein automatisches System zum Erkennen und Verhindern von Systemeinbrüchen durch die Analyse von Log-Dateien.

Warum Fail2Ban?

Wir von datamate nutzen selbst WordPress, um die Seite, die Sie gerade lesen, zu verwalten. Dessen Adminbereich soll über das Internet verfügbar sein, damit wir von jedem Ort mit Internetzugang an der Webseite arbeiten und neue Artikel schreiben zu können. Damit ist unsere WordPress-Instanz akut von Brute-Force-Angriffen bedroht.

Wir haben uns mehrere Sicherungsmöglichkeiten angesehen. Neben Fail2Ban gibt es z.B. mit Stockade, Denyhosts und OSSEC weitere Dienste, die ähnliche Funktionen bieten. Erstere beiden sind leider nicht zu empfehlen, weil sie seit Jahren nicht mehr weiter entwickelt werden. OSSEC macht auf den ersten Blick einen guten Eindruck und bietet eine ausführliche Dokumentation. Dass wir uns für Fail2Ban entschieden haben, liegt an dessen großer Robustheit und Verbreitung. Beim Ubuntu-Server lässt sich Fail2Ban auch direkt aus den offiziellen Paketquellen installieren.

Allgemeines Vorgehen mit Fail2Ban

Egal, ob WordPress, Odoo (ehemals OpenERP) oder ein anderer Dienst mit Fail2Ban geschützt werden soll, die folgenden vier Schritte sind durchzuführen:

• Identifikation der Log-Datei der zu sichernden Applikation
• Erstellung einer Fail2Ban-Filterregel
• Test der Filterregel
• Aktivierung der Filterregel

Um diese graue Theorie zu verdeutlichen, zeigen wir das Vorgehen für WordPress und Odoo.

Schutz von WordPress mit Fail2Ban

Webserver wie nginx oder Apache dokumentieren grundsätzlich alle Zugriffe auf WordPress. Sie unterscheiden im Logging jedoch nicht zwischen erfolgreichen und fehlerhaften Logins unterschieden. Der Nachteil: Fail2Ban kann nur die Anzahl aller Loginversuche überwachen, nicht nur der erfolglosen. Das kann schon mal dazu führen, dass auch legitime Nutzer ge-“banned” werden.

Dieses Manko wird mit der Installation des WP-Plugins WP Fail2Ban beseitigt. Nach der Installation dieses Plugins werden alle Zugriffsversuche in die Log-Datei /var/log/auth.log geschrieben und es wird zwischen erfolgreichen und abgelehnten Zugriffen unterschieden:

Jul  1 09:59:55 www wordpress(www.ionas-server.com)[19713]: Authentication failure for MrX from 37.148.137.78
Jul  1 10:00:08 www wordpress(www.ionas-server.com)[19731]: Accepted password for ChristophDyllick from 37.148.137.78

Nun muss die Fail2Ban-Filterregel so erstellt, dass die Log-Einträge richtig erfasst werden. In dem Fall machen wir es uns einfach und laden einfach eine passende Regel herunter. (Am Odoo-Beispiel weiter unten zeigen wir, wie man eine Filterregel selbst schreiben kann.)

$ cd /etc/fail2ban/filter.d
$ wget https://plugins.svn.wordpress.org/wp-fail2ban/trunk/filters.d/wordpress-hard.conf

Nach der Vorbereitung nun zur Action! Wir prüfen, ob die Filterregel greift. Der Befehl hierfür lautet:

$ fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/wordpress.conf

Der Befehl ist quasi selbsterklärend: Der Befehl prüft die auth.log mit der Filterregel wordpress.conf. Die Ausgabe wiederum ist nicht so selbsterklärend. Dennoch: Am Ende sollte folgende Zeile stehen:

Success, the total number of match is 1

Fail2Ban kann die Filterregel also interpretieren. Um ganz sicher zu gehen, dass alles richtig funktioniert, sollte ein fehlerhafter Login provoziert und dann der regex-Befehl erneut ausgeführt werden. Die Anzahl der Treffer sollte dann logischerweise um 1 angestiegen sein.

Nun ist die Filterregel definiert. Was noch fehlt ist die Instruktion an Fail2Ban, die Regel auch anzuwenden. Dafür dienen die sogenannten Jails. Diese legt man in der Datei /etc/fail2ban/jail.conf mit dem Editor der Wahl an:

[wordpress]
enabled = true                   
filter = wordpress               
logpath = /var/log/auth.log      
port = http,https                
maxretry = 5                      
findtime = 10800                                                   
bantime = 86400          

Individuell anpassbar sind die Parameter maxretry, findtime und bantime:

• maxretry: Anzahl der zulässigen Zugriffsversuche
• findtime: überwachte Zeitdauer in Sekunden
• bantime: Sperrzeit in Sekunden bei einem Ban

Mit der obigen Beispielregel werden also Zugriffe von einer IP-Adresse für 86400 Sekunden (=24h) gesperrt, wenn innerhalb von 10800 Sekunden (=3h) fünf nicht-autorisierte Logins von dieser erfolgen. Nach einem Neustart von Fail2Ban wird die neue Filterregel aktiviert.

$ /etc/init.d/fail2ban restart
$ /etc/init.d/fail2ban status
$ tail -f /var/log/fail2ban.log

Nach Ausführung des Befehls enthält die Log-Datei von Fail2Ban die folgende Meldung:

2015-07-01 10:28:32,666 fail2ban.jail   : INFO   Jail 'wordpress' started

WordPress profitiert nun vom wachsamen Auge von Fail2Ban.

Schutz des CRM-Systems Odoo 11

Als nächstes wollen wir das Open-Source CRM-System Odoo (ehemals OpenERP) mit Fail2Ban absichern. Auch hier gehen wir nach dem benannten Schema vor.

Für Odoo gibt es leider kein Plugin, welches die fehlgeschlagenen Zugriffsversuche detailliert in die /var/log/auth.log schreibt. Daher ist es notwendig, nginx oder Apache so zu konfigurieren, dass die Zugriffsversuche entsprechend geloggt werden. Unter nginx reicht dazu der folgende Eintrag in die dazugehörige CONF-Datei unter /etc/nginx/sites-available:

access_log    /var/log/nginx/odoo.access.log;

Bei jeden Zugriffsversuch (egal ob erfolgreich oder nicht-erfolgreich) wird nun folgender Log-Eintrag erzeugt:

93.241.204.176 - - [09/Sep/2018:13:28:05 +0200] "POST /web/login HTTP/1.1" 303 215 "https:/datamate.org/web/login" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/2010
0101 Firefox/62.0"

Fail2Ban muss also per Filterdatei nach /web/login suchen. Die folgende odoo.conf unter /etc/fail2ban/filter.d tut das:

# fail2ban filter configuration for odoo (on nginx)
[Definition]

failregex =  .* /web/login .*
ignoreregex =

# Author: Ralf Dyllick-Brenzinger (www.datamate.org)

Schauen wir uns den Aufbau der Filterdatei von Fail2Ban nochmals etwas genauer an: Hinter fail2regex definieren wir mittels eines oder mehrerer regulärer Ausdrücke (jeweils in einer neuen Zeile) die Regeln, die auf einen fehlerhaften Loginversuch verweisen. Mit ignoreregex können wir dementsprechend ebenfalls via regulärer Ausdrücke definieren, welche Einträge zu ignorieren sind. Wichtig ist, dass mit <HOST> Fail2Ban mitgeteilt wird, wo es in dem Log-Eintrag die IP findet, die es sperren soll. Weitere Information zur Definition der Filterregeln gibts im Manual von Fail2Ban.

Hinweis: Bei anderen Odoo Versionen können die Logs anders aussehen. Dann muss logischerweise die Filterregel auch anders aussehen.

Als nächstes aktivieren wir die Filterregel in Fail2Ban durch Einfügen in die jail.conf von Fail2Ban:

[nginx-odoo]
enabled = true
port    = http,https
filter  = odoo
logpath = /var/log/nginx/odoo.access.log
maxretry = 30
findtime = 1200                                                   
bantime = 6000        

Nach einem systemctl restart fail2ban ist auch Odoo 11 mit Hilfe von Fail2Ban vor Brute-Force-Angriffen geschützt. Den Regeltest, den wir hier übersprungen haben, können wir nun direkt über den Weblogin von Odoo nachholen. Nach der im Parameter maxretry definierten Anzahl an Login-Versuchen sollte Odoo nicht mehr reagieren und keine weiteren Zugriffe ermöglichen.

Achtung: Fail2Ban hinter Proxys oder Zugriffe aus einem Büro

Fail2Ban merkt sich Zugriffsversuche und ordnet diese einer IP-Adresse zu. Bei Einsatz eines vorgeschalteten Proxy sollte Fail2Ban nicht verwendet werden. Der Proxy würde dafür sorgen, dass alle Zugriffe mit der IP des Proxys gespeichert werden und sobald in Summe zu viele fehlgeschlagene Zugriffsversuche aufgetreten sind, ist das Gesamtsystem für alle Anwender gesperrt. Die Seite wäre dann nicht mehr erreichbar.

Ähnlich verhält es sich, wenn mehrere Mitarbeiter über die gleiche externe IP auf ein System zugreifen. Die Problematik wird an einem typischen Szenario deutlich: 10 Mitarbeiter loggen sich morgens zum Arbeitsbeginn in Odoo ein. Dies wären 10 Zugriffe von ein und derselben IP-Adresse. Aus diesem Grund bietet Fail2Ban eine Whitelisting-Möglichkeit. Dazu lassen sich in der Datei /etc/fail2ban/jail.conf IP-Adressen definieren, die von Fail2Ban ignoriert werden. Mit dem Paramater ignoreip können entweder Subnetzwerke oder einzelne IPs von der Prüfung ausnehmen. Mehrere IP-Adressen werden durch Leerzeichen getrennt eingegeben.

ignoreip = 127.0.0.1 192.168.1.0/24 8.8.8.8

Wie Sie sehen ist Fail2Ban ein sehr einfaches und mächtiges Tool um Linux-Systeme vor Brute-Force-Angriffen zu schützen. Dies ist der Grund warum wir bei datamate Fail2Ban auf Homie und Fellow standardmässig einsetzen, um die installierten Webdienste vor unerlaubten Zugriffen zu schützen.

Fragen oder Probleme bei der Einrichtung und Konfiguration von Fail2Ban? Wir helfen gerne an 365 Tagen im Jahr von 9 bis 19 Uhr. Unsere Telefonnummer: +49 (0)6131 3270777.