Wie man SSH mit Fail2Ban auf Debian 11 schützt

Einführung

SSH ist die Standardmethode zum Verbinden mit einem Cloud-Server. Es ist robust und erweiterbar – neue Verschlüsselungsstandards können verwendet werden, um neue SSH-Schlüssel zu generieren, was gewährleistet, dass das Kernprotokoll sicher bleibt. Allerdings ist kein Protokoll oder Software-Stack vollkommen foolproof, und da SSH so weit im Internet verbreitet ist, stellt es eine sehr vorhersehbare Angriffsfläche oder Angriffsvektor dar, über den Personen versuchen können, Zugriff zu erlangen.

Jeder Dienst, der dem Netzwerk ausgesetzt ist, ist auf diese Weise ein potentielles Ziel. Wenn Sie die Protokolle für Ihren SSH-Dienst auf einem vielbesuchten Server überprüfen, werden Sie oft wiederholte, systematische Anmeldeversuche sehen, die Brute-Force-Angriffe von Benutzern und Bots gleichermaßen darstellen. Obwohl Sie einige Optimierungen an Ihrem SSH-Dienst vornehmen können, um die Erfolgschance dieser Angriffe nahezu auf Null zu reduzieren, wie z. B. Abschalten der Passwortauthentifizierung zugunsten von SSH-Schlüsseln, können sie dennoch eine geringfügige, fortlaufende Haftung darstellen.

Großangelegte Produktionsbereitstellungen, für die diese Haftung völlig inakzeptabel ist, implementieren in der Regel ein VPN wie WireGuard vor ihrem SSH-Dienst, sodass es unmöglich ist, direkt über den Standard-SSH-Port 22 aus dem externen Internet eine Verbindung herzustellen, ohne zusätzliche Softwareabstraktionen oder Gateways. Diese VPN-Lösungen genießen großes Vertrauen, können jedoch Komplexität hinzufügen und einige Automatisierungen oder andere kleine Softwareanbindungen beeinträchtigen.

Vor oder zusätzlich zur Entscheidung für ein vollständiges VPN-Setup können Sie ein Tool namens Fail2ban implementieren. Fail2ban kann Brute-Force-Angriffe erheblich eindämmen, indem es Regeln erstellt, die automatisch Ihre Firewall-Konfiguration ändern, um bestimmte IPs nach einer bestimmten Anzahl von fehlgeschlagenen Anmeldeversuchen zu sperren. Dadurch kann Ihr Server sich gegen diese Zugriffsversuche absichern, ohne dass Ihr Eingreifen erforderlich ist.

In diesem Leitfaden erfahren Sie, wie Sie Fail2ban auf einem Debian 11 Server installieren und verwenden können.

Voraussetzungen

Um diesen Leitfaden abzuschließen, benötigen Sie:

• Einen Debian 11 Server und einen Nicht-Root-Benutzer mit sudo-Berechtigungen. Informationen dazu, wie Sie einen Benutzer mit diesen Berechtigungen einrichten können, finden Sie in unserem Leitfaden „Erstkonfiguration des Servers mit Debian 11“.

• Optional einen zweiten Server, mit dem Sie sich von Ihrem ersten Server aus verbinden können und den Sie verwenden werden, um absichtlich gesperrt zu werden.

Schritt 1 – Installation von Fail2ban

Fail2ban ist in den Software-Repositories von Debian verfügbar. Beginnen Sie damit, die folgenden Befehle als Nicht-Root-Benutzer auszuführen, um Ihre Paketlisten zu aktualisieren und Fail2ban zu installieren:

sudo apt update
sudo apt install fail2ban

Nach der Installation wird Fail2ban automatisch einen Hintergrunddienst einrichten. Sie können seinen Status mithilfe des Befehls systemctl überprüfen:

systemctl status fail2ban.service

Output
● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled
     Active: active (running) since Tue 2022-06-28 16:23:14 UTC; 17s ago
       Docs: man:fail2ban(1)
    Process: 1942 ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS
   Main PID: 1943 (fail2ban-server)
      Tasks: 5 (limit: 1132)
     Memory: 15.8M
        CPU: 280ms
     CGroup: /system.slice/fail2ban.service
             └─1943 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Sie können Fail2ban weiterhin mit den Standardeinstellungen verwenden, aber zuerst werden einige seiner Funktionen überprüft.

Schritt 2 – Konfiguration von Fail2ban

Der Fail2ban-Dienst speichert seine Konfigurationsdateien im Verzeichnis /etc/fail2ban. Dort befindet sich eine Datei mit Standardeinstellungen namens jail.conf. Gehen Sie zu diesem Verzeichnis und geben Sie die ersten 20 Zeilen dieser Datei mit dem Befehl head -20 aus:

cd /etc/fail2ban
head -20 jail.conf

Output
#
# WARNUNG: stark überarbeitet in der Version 0.9.0. Bitte überprüfen und 
# anpassen Sie die Einstellungen für Ihre Einrichtung.
#
# Änderungen: In den meisten Fällen sollten Sie diese
# Datei nicht ändern, sondern Anpassungen in der jail.local-Datei
# oder separaten .conf-Dateien im Verzeichnis jail.d/ bereitstellen, z. B.:
#
# WIE MAN JAILS AKTIVIERT:
#
# SIE SOLLTEN DIESE DATEI NICHT ÄNDERN.
#
# Sie wird wahrscheinlich überschrieben oder verbessert in einem Verteilungsupdate.
#
# Stellen Sie Anpassungen in einer jail.local-Datei oder einer jail.d/customisation.local-Datei bereit.
# Zum Beispiel, um die Standard-Sperrzeit für alle Jails zu ändern und den
# ssh-iptables-Jail zu aktivieren, würde Folgendes (auskommentiert) in der .local-Datei erscheinen.
# Siehe man 5 jail.conf für Details.
#
# [DEFAULT]

Wie Sie sehen werden, sind die ersten Zeilen dieser Datei auskommentiert – sie beginnen mit #-Zeichen, die anzeigen, dass sie als Dokumentation und nicht als Einstellungen interpretiert werden sollen. Wie Sie ebenfalls sehen werden, weisen diese Kommentare darauf hin, dass Sie diese Datei nicht direkt ändern sollen. Stattdessen haben Sie zwei Optionen: Entweder erstellen Sie einzelne Profile für Fail2ban in mehreren Dateien im Verzeichnis jail.d/, oder erstellen und sammeln Sie alle Ihre lokalen Einstellungen in einer jail.local-Datei. Die jail.conf-Datei wird periodisch aktualisiert, wenn Fail2ban selbst aktualisiert wird, und wird als Quelle für Standardeinstellungen verwendet, für die Sie keine Overrides erstellt haben.

In diesem Tutorial erstellen Sie jail.local. Das können Sie tun, indem Sie jail.conf kopieren:

sudo cp jail.conf jail.local

Jetzt können Sie mit der Konfigurationsänderung beginnen. Öffnen Sie die Datei in nano oder Ihrem bevorzugten Texteditor:

sudo nano jail.local

Während Sie durch die Datei scrollen, wird dieses Tutorial einige Optionen überprüfen, die Sie möglicherweise aktualisieren möchten. Die Einstellungen unter dem Abschnitt [DEFAULT] in der Nähe des Dateianfangs werden auf alle von Fail2ban unterstützten Dienste angewendet. An anderer Stelle in der Datei gibt es Überschriften für [sshd] und für andere Dienste, die dienstspezifische Einstellungen enthalten, die über den Standards liegen.

[DEFAULT]
. . .
bantime = 10m
. . .

Der Parameter bantime legt die Dauer fest, für die ein Client gesperrt wird, wenn er sich nicht korrekt authentifiziert hat. Dies wird in Sekunden gemessen. Standardmäßig ist dies auf 10 Minuten eingestellt.

[DEFAULT]
. . .
findtime = 10m
maxretry = 5
. . .

Die nächsten beiden Parameter sind findtime und maxretry. Diese arbeiten zusammen, um die Bedingungen festzulegen, unter denen ein Client als illegitimer Benutzer angesehen wird, der gesperrt werden soll.

Die Variable maxretry legt die Anzahl der Versuche fest, die ein Client innerhalb eines Zeitfensters von findtime authentifizieren kann, bevor er gesperrt wird. Mit den Standardeinstellungen sperrt der Fail2ban-Dienst einen Client, der innerhalb eines Zeitfensters von 10 Minuten 5 erfolglose Anmeldeversuche unternimmt.

[DEFAULT]
. . .
destemail = root@localhost
sender = root@<fq-hostname>
mta = sendmail
. . .

Wenn Sie E-Mail-Benachrichtigungen erhalten möchten, wenn Fail2ban aktiv wird, sollten Sie die Einstellungen destemail, sendername und mta bewerten. Der Parameter destemail legt die E-Mail-Adresse fest, die Ban-Nachrichten erhalten soll. Der Parameter sendername legt den Wert des Feldes „Von“ in der E-Mail fest. Der Parameter mta konfiguriert den Maildienst, der zum Senden von E-Mails verwendet wird. Standardmäßig ist dies sendmail, aber Sie möchten möglicherweise Postfix oder eine andere E-Mail-Lösung verwenden.

[DEFAULT]
. . .
action = $(action_)s
. . .

Dieser Parameter konfiguriert die Aktion, die Fail2ban ausführt, wenn es eine Sperre einführen möchte. Der Wert action_ ist in der Datei kurz vor diesem Parameter definiert. Die Standardaktion besteht darin, Ihre Firewall-Konfiguration zu aktualisieren, um den Datenverkehr vom betreffenden Host abzulehnen, bis die Sperrzeit abläuft.

Es gibt andere action_-Skripte, die standardmäßig bereitgestellt werden, die Sie durch $(action_) ersetzen können:

…
# Sperre und sende eine E-Mail mit einem Whois-Bericht an die destemail.
action_mw = %(action_)s
            %(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]

# Sperre und sende eine E-Mail mit einem Whois-Bericht und relevanten Protokollzeilen
# an die destemail.
action_mwl = %(action_)s
             %(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]

# Beachten Sie die WICHTIGE Anmerkung in action.d/xarf-login-attack, wann diese Aktion verwendet werden soll
#
# Sperre und sende eine XARF-E-Mail an den Missbrauchskontakt der IP-Adresse und füge relevante Protokollzeilen
# an die destemail.
action_xarf = %(action_)s
             xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]

# Sperre IP auf CloudFlare & sende eine E-Mail mit einem Whois-Bericht und relevanten Protokollzeilen
# an die destemail.
action_cf_mwl = cloudflare[cfuser="%(cfemail)s", cftoken="%(cfapikey)s"]
                %(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
…

Zum Beispiel führt action_mw eine Aktion aus und sendet eine E-Mail, action_mwl führt eine Aktion aus, sendet eine E-Mail und protokolliert sie, und action_cf_mwl führt all dies zusätzlich dazu aus, dass eine Aktualisierung an die Cloudflare-API gesendet wird, die mit Ihrem Konto verbunden ist, um den Übeltäter dort ebenfalls zu sperren.

Einzelfalleinstellungen

Als nächstes folgt der Teil der Konfigurationsdatei, der sich mit einzelnen Diensten befasst. Diese werden durch Abschnittsüberschriften angegeben, wie [sshd].

Jeder dieser Abschnitte muss einzeln aktiviert werden, indem unter der Überschrift eine Zeile enabled = true hinzugefügt wird, zusammen mit ihren anderen Einstellungen.

[jail_to_enable]
. . .
enabled = true
. . .

Standardmäßig ist der SSH-Dienst aktiviert und alle anderen sind deaktiviert.
.
Einige andere Einstellungen, die hier festgelegt sind, sind das filter, das verwendet wird, um zu entscheiden, ob eine Zeile in einem Protokoll einen fehlgeschlagenen Authentifizierungsversuch anzeigt, und der logpath, der fail2ban mitteilt, wo sich die Protokolle für diesen bestimmten Dienst befinden.

Der filter-Wert ist tatsächlich ein Verweis auf eine Datei im Verzeichnis /etc/fail2ban/filter.d, wobei die Erweiterung .conf entfernt wird. Diese Dateien enthalten reguläre Ausdrücke (eine gängige Abkürzung für die Textanalyse), die bestimmen, ob eine Zeile im Protokoll einen fehlgeschlagenen Authentifizierungsversuch darstellt. Wir werden diese Dateien in diesem Leitfaden nicht ausführlich behandeln, da sie recht komplex sind und die vordefinierten Einstellungen gut zu den entsprechenden Zeilen passen.

Sie können jedoch sehen, welche Arten von Filtern verfügbar sind, indem Sie in dieses Verzeichnis schauen:

ls /etc/fail2ban/filter.d

Wenn Sie eine Datei sehen, die mit einem von Ihnen verwendeten Dienst zusammenhängt, sollten Sie sie mit einem Texteditor öffnen. Die meisten Dateien sind recht gut kommentiert, und Sie sollten zumindest erkennen können, gegen welche Art von Bedingung das Skript geschützt werden soll. Die meisten dieser Filter haben entsprechende (deaktivierte) Abschnitte in der Datei jail.conf, die wir bei Bedarf in der Datei jail.local aktivieren können.

Zum Beispiel, stellen Sie sich vor, Sie betreiben eine Website mit Nginx und stellen fest, dass ein passwortgeschützter Bereich Ihrer Website mit Anmeldeversuchen bombardiert wird. Sie können fail2ban anweisen, die Datei nginx-http-auth.conf zu verwenden, um diese Bedingung in der Datei /var/log/nginx/error.log zu überprüfen.

Dies ist tatsächlich bereits in einem Abschnitt namens [nginx-http-auth] in Ihrer Datei /etc/fail2ban/jail.conf eingerichtet. Sie müssten nur den Parameter enabled hinzufügen:

. . .
[nginx-http-auth]

enabled = true
. . .

Wenn Sie mit der Bearbeitung fertig sind, speichern und schließen Sie die Datei. Wenn Sie Änderungen vorgenommen haben, können Sie den Fail2ban-Dienst mit systemctl neu starten:

sudo systemctl restart fail2ban

Im nächsten Schritt werden Sie Fail2ban in Aktion demonstrieren.

Schritt 3 — Testen der Sperrrichtlinien (Optional)

Von einem anderen Server aus, der sich in Zukunft nicht auf Ihren Fail2ban-Server einloggen muss, können Sie die Regeln testen, indem Sie diesen zweiten Server sperren lassen. Melden Sie sich auf Ihrem zweiten Server an und versuchen Sie, eine SSH-Verbindung zum Fail2ban-Server herzustellen. Sie können versuchen, sich mit einem nicht existierenden Namen zu verbinden:

ssh blah@your_server

Geben Sie zufällige Zeichen in die Passwortabfrage ein. Wiederholen Sie dies einige Male. Irgendwann sollte sich die Fehlermeldung von Berechtigung verweigert zu Verbindung abgelehnt ändern. Dies signalisiert, dass Ihr zweiter Server vom Fail2ban-Server gesperrt wurde.

Auf Ihrem Fail2ban-Server können Sie die neue Regel überprüfen, indem Sie Ihre iptables-Ausgabe überprüfen. iptables ist ein Befehl zum Interagieren mit Low-Level-Port- und Firewall-Regeln auf Ihrem Server. Wenn Sie der Anleitung von DigitalOcean zur ersten Servereinrichtung gefolgt sind, verwenden Sie ufw zum Verwalten von Firewall-Regeln auf einer höheren Ebene. Durch Ausführen von iptables -S werden Ihnen alle Firewall-Regeln angezeigt, die ufw bereits erstellt hat:

sudo iptables -S

Output
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N f2b-sshd
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
…

Wenn Sie die Ausgabe von iptables -S an grep weiterleiten, um innerhalb dieser Regeln nach dem String f2b zu suchen, können Sie die Regeln sehen, die von fail2ban hinzugefügt wurden:

sudo iptables -S | grep f2b

Output
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A f2b-sshd -s 134.209.165.184/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN

Die Zeile, die REJECT --reject-with icmp-port-unreachable enthält, wurde von Fail2ban hinzugefügt und sollte die IP-Adresse Ihres zweiten Servers widerspiegeln.

Schlussfolgerung

Sie sollten jetzt in der Lage sein, einige Sperrrichtlinien für Ihre Dienste zu konfigurieren. Fail2ban ist eine nützliche Möglichkeit, jeden Dienst zu schützen, der eine Authentifizierung verwendet. Wenn Sie mehr darüber erfahren möchten, wie fail2ban funktioniert, können Sie unser Tutorial über die Funktionsweise von fail2ban-Regeln und -Dateien lesen.

Für Informationen darüber, wie Sie fail2ban verwenden können, um andere Dienste zu schützen, können Sie über How To Protect an Nginx Server with Fail2Ban und How To Protect an Apache Server with Fail2Ban lesen.