ADMIN

2021

05

2021-05-01T12:00:00

Hybrid Cloud

PRAXIS

040

Hybrid Cloud

Cloud

SSH-Server mit fail2ban absicher

Unerwünschte Besucher fernhalten

von Thorsten Scherf

Veröffentlicht in Ausgabe 05/2021 - PRAXIS

Um den eigenen SSH-Server gegen unbefugte Zugriffe abzusichern, kann neben einer sicheren OpenSSH-Konfiguration das Werkzeug fail2ban weiterhelfen. Dieses durchsucht unter anderem die Logdateien "auth.log" und "secure", um anhand bestimmter Muster zu erkennen, ob nicht-autorisierte Zugriffsversuche stattfinden. Es unterbindet den Zugang bereits auf der Netzwerkschicht, indem es IP-Pakete von verdächtigen Systemen verwirft.

IT-Systeme, die ungeschützt im Internet stehen, sind grundsätzlich immer einer Gefahr ausgesetzt. Auch wenn sie vielleicht keine allgemein öffentlichen Dienste anbieten und eventuell nicht einmal über einen DNS-Namen verfügen: die Rechner werden trotzdem gefunden. Tagtäglich laufen endlose Scans im globalen Netzwerk, die jeden Rechner identifizieren und nach Schwachstellen absuchen – angefangen bei einfachen Brute-Force-Attacken bis hin zu komplexeren Zugriffsversuchen, bei denen Angreifer Schwachstellen abklopfen in der Hoffnung, Schadcode auf einem System auszuführen. Die folgenden Beispiele zeigen, wie Sie den eigenen OpenSSH-Server gegen ungewollte Zugriffe absichern beziehungsweise die Hürden für Angreifer möglichst erhöhen.
Zusätzliche OpenSSH-Konfigurationsdateien einlesen
Die Konfiguration des OpenSSH-Servers erfolgt in der Datei "sshd_config", die zumeist im Verzeichnis "/etc/ssh/" liegt. Seit der OpenSSH-Version 8.2 besteht allerdings die Möglichkeit, zusätzliche Dateien zur Konfiguration zu verwenden [1]. Diese können Sie ganz einfach mit einer Include-Anweisung in der Datei "sshd_config" einlesen. Hier ein Beispiel:
Include /etc/ssh/sshd_config.d/*.conf
Hiermit werden nach einem Neustart des Servers sämtliche Dateien aus dem Verzeichnis "/etc/ssh/sshd_config.d/" beachtet, die auf ".conf" enden. Unterstützt Ihre OpenSSH-Server-Version dieses neue Feature noch nicht, speichern Sie die jeweiligen Konfigurationsanweisungen einfach wie gewohnt in der Datei "sshd_config".
IT-Systeme, die ungeschützt im Internet stehen, sind grundsätzlich immer einer Gefahr ausgesetzt. Auch wenn sie vielleicht keine allgemein öffentlichen Dienste anbieten und eventuell nicht einmal über einen DNS-Namen verfügen: die Rechner werden trotzdem gefunden. Tagtäglich laufen endlose Scans im globalen Netzwerk, die jeden Rechner identifizieren und nach Schwachstellen absuchen – angefangen bei einfachen Brute-Force-Attacken bis hin zu komplexeren Zugriffsversuchen, bei denen Angreifer Schwachstellen abklopfen in der Hoffnung, Schadcode auf einem System auszuführen. Die folgenden Beispiele zeigen, wie Sie den eigenen OpenSSH-Server gegen ungewollte Zugriffe absichern beziehungsweise die Hürden für Angreifer möglichst erhöhen.
Zusätzliche OpenSSH-Konfigurationsdateien einlesen
Die Konfiguration des OpenSSH-Servers erfolgt in der Datei "sshd_config", die zumeist im Verzeichnis "/etc/ssh/" liegt. Seit der OpenSSH-Version 8.2 besteht allerdings die Möglichkeit, zusätzliche Dateien zur Konfiguration zu verwenden [1]. Diese können Sie ganz einfach mit einer Include-Anweisung in der Datei "sshd_config" einlesen. Hier ein Beispiel:
Include /etc/ssh/sshd_config.d/*.conf
Hiermit werden nach einem Neustart des Servers sämtliche Dateien aus dem Verzeichnis "/etc/ssh/sshd_config.d/" beachtet, die auf ".conf" enden. Unterstützt Ihre OpenSSH-Server-Version dieses neue Feature noch nicht, speichern Sie die jeweiligen Konfigurationsanweisungen einfach wie gewohnt in der Datei "sshd_config".
Sichere Standardkonfigurationen
Es gibt eine Vielzahl von Grundeinstellungen, die jeder OpenSSH-Server verwenden sollte. Dazu zählt beispielsweise, dass ein Root-Login grundsätzlich nicht möglich ist und Anwender sich stattdessen mit Ihrem regulären Account anmelden müssen. Zur Administration des Systems kommt dann sudo zum Einsatz, wodurch sämtliche administrativen Aktivitäten auf dem System leicht nachvollziehbar sind.
Weiterhin sollte die Anmeldung mit Passwörtern nicht gestattet sein und stattdessen auf SSH-Keys, Kerberos oder Multifaktor-Authentifizierung (MFA) gesetzt werden. Der Zugang lässt sich weiter einschränken, wenn Sie den Login auf bestimmte Personenkreise begrenzen, indem Sie die Benutzer oder Gruppen explizit aufführen. Die folgenden Konfigurationsanweisungen für den OpenSSH-Server setzten diese Anforderungen entsprechend um:
AllowUsers <Benutzernamen>
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Nach einem Neustart des Servers sind diese dann auch direkt aktiv. Zu beachten ist, dass ab diesem Zeitpunkt ein passwortbasiertes Login nicht mehr möglich ist. Sie sollten also zuvor eine andere Authentifizierungsmethode eingerichtet haben. Mittels ssh-keygen erzeugen Sie beispielsweise ein SSH-Schlüsselpaar und mit ssh-copy-id kopieren Sie den öffentlichen Schlüssel dann auf den Server. Wichtig ist, dass Sie diesen Schritt durchführen, bevor Sie die passwortbasierte Anmeldung deaktivieren.
Allein durch die Wahl der passenden Konfigurationsoptionen für den OpenSSH-Server können Sie das Sicherheitsniveau deutlich steigern. Wollen Sie noch einen Schritt weiter gehen, lohnt sich ein Blick auf die Software fail2ban [2].
Aktionen ausführen
Fail2Ban nimmt zum Beispiel Logdateien wie "/var/log/secure", "/var/log/auth.log" und "/var/log/apache2/error.log" unter die Lupe und erkennt anhand von bestimmten Mustern, ob nicht-autorisierte Zugriffsversuche stattfinden. Darauf basierend lassen sich dann unterschiedliche Aktionen einleiten. Beispielsweise können Sie das Tool anweisen, dynamische Paketfilterregeln zu erzeugen, um die IP-Adressen von ungewollten Gästen für eine bestimmte Zeit in eine Blacklist aufzunehmen. Somit blockieren Sie Anfragen von diesen Systemen direkt auf der Netzwerkschicht.
Mithilfe vorgefertigter Templates können Sie sich per E-Mail über nicht reguläre Zugriffsversuche informieren lassen. Ob dies bei der Masse an zufälligen Scans, die tagtäglich stattfinden, hilfreich ist, bleibt Ihnen überlassen. Die Software basiert im Kern aus Filtern, Aktionen und sogenannten Jails. Mittels der Filter erkennt fail2ban bestimmte Muster in Logdateien, mithilfe von Aktionen können Sie auf gefundene Muster entsprechend reagieren und mit Jails verbinden Sie eben genau diese Muster mit den gewünschten Aktionen. Ein Jail betrachtet dabei typischerweise einen bestimmten Service, wie beispielsweise SSH, und verknüpft ein Muster mit einer oder mehreren Aktionen, die ausgeführt werden sollen, sobald das Muster in den Logs auftritt.
Zu den typischen Aktionen von fail2ban zählt das Hinterlegen einer verdächtigen IP-Adresse in einer Netfilter-Regel. Somit verwirft das Tool weitere IP-Pakete von dieser Adresse direkt. Nachfolgend finden Sie hierfür einige Beispiele, die alle auf der fail2ban-Version 0.11 auf einem CentOS-7.9-Host basieren. Die Software steht über die Repositories vieler Linux-Distributionen zur Verfügung und ist ebenfalls im EPEL-Repository (Extra Packages for Enterprise Linux) [3] enthalten. Bei Bedarf können Sie die Pakete auch über GitHub [4] beziehen.
fail2ban konfigurieren
Die Konfigurationsdateien liegen standardmäßig im Verzeichnis "/etc/fail2ban". Hier finden Sie Dateien, die auf ".conf" oder ".local" enden. Erstere enthalten die Standardkonfigurationen. Die Vorgaben aus diesen Dateien können Sie jedoch durch das Anlegen von gleichnamigen Dateien mit der Endung ".local" überschreiben.
Hier nun ein konkretes Beispiel. Für den OpenSSH-Server finden Sie im Verzeichnis "filter.d" die Datei "sshd.conf". Diese enthält typische Muster, die auf einen nicht-autorisierten Zugriffsversuch auf den SSH-Server schließen lassen. Wollen Sie die Muster erweitern oder ändern, legen Sie hierfür einfach eine Datei "sshd.local" im gleichen Verzeichnis ab. Die vordefinierten Anweisungen, um ungewollte Besucher mithilfe eines Paketfilters auszusperren, sind in der Datei "firewallcmd-ipset.conf" im Verzeichnis "action.d" hinterlegt.
Standardmäßig reagiert fail2ban auf nichtgewünschte IP-Pakete, indem es diese mit einer ICMP-Fehlermeldung beantwortet. Stattdessen können Sie Pakete natürlich auch einfach verwerfen lassen. Hierzu erzeugen Sie wieder im gleichen Verzeichnis die Datei "firewallcmd-ipset.local" mit folgendem Inhalt:
action.d/firewallcmd-ipset.local
[Init]
blocktype = DROP
Schließlich fehlt noch das eigentliche Jail. Die Standardkonfiguration für sämtliche Services ist in der Datei "jail.conf" hinterlegt. Einige Einstellungen können Sie nun durch das Anlegen der Datei "jail.local" wie folgt überschreiben:
jail.local
[DEFAULT]
bantime = 3600
backend = systemd
action = %(action_mwl)s
banaction = firewallcmd-ipset
maxretry = 3
ignoreip = 127.0.0.1/8 192.168.1.0/24
Für den OpenSSH-Server soll die folgende Konfiguration zum Einsatz kommen:
jail.d/ssh-jail.local
[sshd]
enabled = true
mode = aggressive
bantime = 1d
Das Kommando fail2ban-client status sshd listet die blockierten IP-Adressen auf.
Hiermit weiß fail2ban nun also, wie verdächtige Muster beim Zugriff auf den SSH-Server aussehen ("filter.d/sshd"), dass es IP-Pakete, von denen diese Muster gesendet wurden, stillschweigend verwirft ("action.d/firewallcmd-ipset.local") und dass die IP-Pakete in einem IPSet zusammengeführt werden, das fail2ban dann in einer Paketfilterregel einsetzten kann. IPSets [5] sind ein Feature des Linux-Kernels, mit dem Sie sehr einfach IP- oder MAC-Adressen sowie Netzwerkports in einer Tabelle verwalten. Diese besitzt einen Namen, den Sie als Referenz verwenden können – beispielsweise aus einer iptables-Regel heraus.
Stellen Sie im Anschluss sicher, dass fail2ban einmal neu gestartet wird und auch das Paketfilter-Frontend "firewalld" aktiv ist. Dieses kommuniziert über das dbus-Interface mit fail2ban, sodass sich Regeln im Paketfilter dynamisch aktualisieren lassen.
Den aktuellen Stand des SSH-Jails sehen Sie mithilfe des fail2ban-Clients. In dem Beispiel im Bild ist zu erkennen, dass die Software bereits zwei IP-Adressen auf der Blockliste für den SSH-Service führt.
Listing 1: Ausgabe von ipset list
Name: f2b-sshd Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem 65536 timeout 600 Size in memory: 408 References: 1 Number of entries: 3 Members: 45.155.205.225 timeout 86291 46.80.34.167 timeout 86291 222.186.136.150 timeout 86291
Das IPSet können Sie sich natürlich ebenfalls mit dem Tool "ipset" anzeigen lassen, wie in Listing 1 zu erkennen ist. In der Ausgabe des Listings sehen Sie auch den Namen der IPSet-Tabelle. Im Beispiel lautet er "f2b-sshd". Der Name wird nun in einer iptables-Regel verwendet, um sämtliche IP-Adressen aus der Tabelle mithilfe der iptables-Anweisung "DROP" zu verwerfen, wie Ihnen Listing 2 zeigt.
In Listing 2 ist zu erkennen, dass sich der Einsatz von fail2ban schon gelohnt hat, da bereits eine Vielzahl ungewollter Zugriffsversuche unterbunden wurde.
Listing 2: Augabe von iptables -vL INPUT_direct
Chain INPUT_direct (1 references) pkts           bytes;            target            prot            opt            in            out           source            destination 1877          87K              DROP            tcp              --              any          any          anywhere       anywhere           multiport dports ssh                                                                                                                                                                                   match-set f2b-sshd src
Fazit
Ist ein SSH-Server direkt aus dem Internet erreichbar, müssen Sie diesen möglichst gut absichern, um ungewollten Besuchern den Zugang zu verweigern. Dies fängt mit der sicheren Konfiguration der OpenSSH-Software an. Ein zusätzliches Tool wie fail2ban kann dabei helfen, den Zugang bereits auf der Netzwerkschicht zu unterbinden, indem IP-Pakete von Systemen, die verdächtige Zugriffsmuster senden, einfach verworfen werden. Um die Ressourcen von Angreifern langfristig zu binden, lassen sich Teerfallen wie beispielsweise endlessh einsetzen.
(jm)
Link-Codes
[1] OpenSSH-Konfiguration anpassen: https://bugzilla.mindrot.org/show_bug.cgi?id=2468/
[3] Extra Packages for Enterprise Linux: https://fedoraproject.org/wiki/EPEL/
[4] EPEL auf GitHub: https://github.com/topics/epel/