emoticon-1611718_640-or8

Sicherheit erhöhen – fail2ban installieren und einrichten

WIr haben in den vorherigen Beiträgen (SSH-Schlüssel einrichten und HTTPS und Authentifizierung) schon einiges getan, um ungebetene Gäste von unserem Raspberry Pi fernzuhalten. Leider gibt es in dem großen Haifischbecken namens Internet immer wieder auch Personen, die offenbar nichts besseres zu tun haben, als aus den unterschiedlichsten Gründen in fremde Computersysteme einzudringen. Sei es, um Informationen zu extrahieren und damit die eigene Webseite zu schmücken oder um den Onlineshop der Konkurrenz nach Preisen abzufragen und damit die eigenen Preise auf dem Laufenden zu halten oder auch einfach nur um zu testen, wie gut oder schlecht ein System abgesichert ist. All diese Dinge werden üblicherweise von sogenannten Bots, also Computerprogrammen, die, einmal programmiert, automatisch auf die Suche gehen und nach Opfern suchen, ausgeführt.

Was wir also brauchen ist ein Werkzeug, das solche ungebetenen Gäste von den gewünschten anhand ihres Verhaltens oder auch ihrer Kennung unterscheiden und aussperren kann. Solch ein Werkzeug gibt es. Es heißt fail2ban.

Nach dem obligatorischen Update des Betriebssystems auf den neuesten Stand mittels

können wir fail2ban installieren:

Danach erstellen wir eine Kopie der Konfigurationsdatei jail.conf und benennen sie um zu jail.local:

Nun sollten wir diese Konfigurationsdatei im Editor öffnen und an die eigenen Bedürfnisse anpassen:

In der Sektion Default sind ein paar grundsätzliche Sachen definiert. Da wäre als erstes der Punkt

Damit wird definiert, das Aktionen von diesen Adressen bzw. Adressbereichen ignoriert werden. 127.0.0.1 ist die eigene Adresse und unter 192.168…/24 sollte man den Adressbereich seines internen Netzes einsetzen. Nichts ist ärgerlicher, als wenn man sich selbst aussperrt. Dann müsste man warten, bis die Sperre wieder automatisch aufgehoben wird.

Als nächstes wird der Standardwert gesetzt, wie lange eine Adresse vom weiteren Zutritt gesperrt werden soll. Dieser Wert wird in Sekunden angegeben. Ein Wert von 1200 bedeutet also, dass eine einmal auffällig gewordene Adresse für 20 Minuten für weitere Aktionen gesperrt wird:

Als nächstes wird definiert, wieviele Fehlversuche in welchem Zeitrahmen erlaubt sind. Im folgenden Beispiel hat man innerhalb von 20 Minuten (1200 Sekunden) 3 Versuche, sich erfolgreich anzumelden:

Nun scrollen wir in der Datei noch weiter nach unten, bis zum Abschnitt

Hier folgen jetzt verschiedene sogenannte Sektionen, die einzeln zu- und abschaltbar sind und sich um die verschiedenen Zugangsprotokolle wie SSH oder HTTP(S) und diverse andere kümmern. Da wir auf unserem Raspberry Pi bisher nur den SSH-Zugang und den HTTPS-Zugang nutzen, brauchen wir auch nur diese beiden Protokolle in fail2ban aktivieren.

Wir setzen also in der Sektion SSH den Wert enabled von false auf true. Das sieht dann folgendermaßen aus:

Wie zu sehen, habe ich hier den Standardwert bei maxretry von 3 auf 6 erhöht. Kann man machen, muss man aber nicht.

Nun scrollen wir noch weiter nach unten, bis zum Abschnitt

Da wir nicht wie sonst üblich den Apache als Webserver einsetzen, sondern nginx, müssen wir hier einen eigenen neuen Eintrag in folgender Form machen:

Damit werden schon mal alle bösen Buben ausgesperrt, die mehrfach probiert haben, sich auf unserem Server anzumelden, ohne das richtige Passwort bzw. den passenden SSH-Schlüssel vorweisen zu können.

Bots ausperren

Kommen wir nun noch zu den am Anfang erwähnten Bots, die wir gar nicht erst zu Besuch haben wollen.

Dazu erstellen wir uns eine Datei bots.map unter /etc/nginx/conf.d/bots.map mit folgendem Inhalt (kann später individuell angepasst werden, indem man die jeweiligen useragents aus der access.log von nginx übernimmt):

Das nginx-Modul map verantwortet die Zuweisung der Variable $is_bot, die je nach Treffer einen Wert von 0 (default = kein Bot) und 1 (Bot erkannt) aufweist.

Nun müssen wir diese Datei noch in unserer nginx-Konfigurationsdatei /etc/nginx/nginx.conf bekannt machen:

Jetzt fügen wir in unsere nginx-Server-Konfigurationsdatei unter /etc/nginx/sites-available/meine_domain.tld folgende Zeilen am Ende des ersten virtuellen Server-Eintrags ein:

so dass dann da steht:

Innerhalb der virtuellen Server findet die eigentliche Abfrage auf die von nginx gesetzte Variable $is_bot statt. Im Positivfall sendet der Webserver einen HTTP-Statuscode 444 aus: Die Verbindung zum Client wird geschlossen, ohne eine Antwort zu senden.

Diese Technik erlaubt es uns, jegliche Bot-Zugriffe zu lokalisieren und Verbindungen zu beenden – der Webserver bleibt von der Generierung und Auslieferung der Daten verschont.

Perfekt ist die Abwehrlösung erst dann, wenn bereits abgewiesene Bots durch fail2ban auf Dauer gesperrt werden: Die (Aus)Filterung der Anfragen erfolgt auf der Firewall-Ebene des Servers.

Für diesen Zweck überwacht fail2ban aktuelle Accesslogs des Webservers auf den Fehlercode 444: Quittiert nginx eine Anfrage mit 444 (= ist Bot), bekommt fail2ban dies via Accesslog-Eintrag mit und merkt die IP bzw. den Host in der Firewall-Blacklist vor.

Im fail2ban-Ordner filter.d wird jetzt eine weitere Datei nginx-bots.conf angelegt. Dort die folgende Definition der Erkennungsregel einfügen. Der reguläre Ausdruck innerhalb der Regel überwacht das Accesslog auf das Vorkommen des 444-Statuscodes mit Null Bytes als Rückgabewert.

Als letztes müssen wir noch einmal unsere bereits anfangs erstellte und editierte nginx-Konfigurationsdatei jail.local erweitern um folgende Einträge:

Die lokale fail2ban-Konfigurationsdatei jail.local enthält nun eine Referenz zum soeben angelegten Filter (Filtername = Dateiname des Filters). Dazu einige fail2ban-Eigenschaften, die dafür Sorge tragen, dass erkannte Bots bis auf Weiteres abgelehnt werden.

Nun fehlt noch der letzte Schritt. Damit die vorgenommenen Änderungen wirksam werden, müssen sowohl der Webserver nginx als auch fail2ban neu gestartet werden:

Damit sollte unser Raspberry Pi vor ungebetenen Gästen ausreichend geschützt sein und man kann ihn ohne große Sorgen ins Internet stellen. Ab und zu sollte man natürlich die nginx-Accesslogs durchsehen, ob es neue Kennungen von unerwünschten Bots gibt und die Datei bot.map entsprechend anpassen.

* Teile dieser Anleitung wurden aus einem Beitrag von Sergej Müller entnommen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.