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 sicherstellt, dass das Kernprotokoll sicher bleibt. Allerdings ist kein Protokoll oder Software-Stack völlig narrensicher, und da SSH so weit verbreitet im Internet eingesetzt wird, stellt es eine sehr vorhersehbare Angriffsfläche oder Angriffsvektor dar, über den Personen versuchen können, Zugang zu erlangen.
Jeder Dienst, der dem Netzwerk ausgesetzt ist, ist auf diese Weise ein potenzielles Ziel. Wenn Sie die Protokolle für Ihren SSH-Dienst auf einem stark frequentierten Server überprüfen, sehen Sie oft wiederholte, systematische Anmeldeversuche, 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 vollkommen 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 Internet eine Verbindung herzustellen, ohne zusätzliche Software-Abstraktionen oder Gateways. Diese VPN-Lösungen genießen weitreichendes Vertrauen, können jedoch die Komplexität erhöhen und einige Automatisierungen oder andere kleine Software-Hooks beeinträchtigen.
Vor oder zusätzlich zur Durchführung eines vollständigen VPN-Setups 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 erfolgloser Anmeldeversuche zu sperren. Dies ermöglicht es Ihrem Server, sich gegen diese Zugriffsversuche abzusichern, ohne Ihr Eingreifen.
In dieser Anleitung erfahren Sie, wie Sie Fail2ban auf einem Rocky Linux 8 Server installieren und verwenden können.
Voraussetzungen
Um diese Anleitung abzuschließen, benötigen Sie:
-
Ein Rocky Linux 8-Server und ein nicht-root-Benutzer mit sudo-Berechtigungen. Weitere Informationen zum Einrichten eines Benutzers mit diesen Berechtigungen finden Sie in unserem Leitfaden zum Erstkonfiguration des Servers mit Rocky Linux 8. Sie sollten auch
firewalld
auf dem Server ausgeführt haben, was in unserem Leitfaden zur Erstkonfiguration des Servers behandelt wird. -
Optional ein zweiter Server, von dem aus Sie sich mit Ihrem ersten Server verbinden können, den Sie verwenden werden, um absichtlich gesperrt zu werden.
Schritt 1 — Installieren von Fail2ban
Fail2ban ist nicht in den Standard-Software-Repositories von Rocky verfügbar. Es ist jedoch im EPEL-Repository, oder Erweiterte Pakete für Enterprise Linux, verfügbar, das häufig für Drittanbieterpakete auf Red Hat und Rocky Linux verwendet wird. Wenn Sie EPEL noch nicht zu Ihren Systempaketen hinzugefügt haben, können Sie das Repository mit dnf
hinzufügen, wie Sie es bei der Installation eines anderen Pakets tun würden:
Der dnf
-Paketmanager überprüft nun EPEL zusätzlich zu Ihren Standardpaketquellen beim Installieren neuer Software. Fahren Sie mit der Installation von Fail2ban fort:
Fail2ban wird nach der Installation automatisch einen Hintergrunddienst einrichten. Er ist jedoch standardmäßig deaktiviert, da einige seiner Standard-Einstellungen unerwünschte Effekte verursachen können. Sie können dies mit dem Befehl systemctl
überprüfen:
Output○ fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled
Active: inactive (dead)
Docs: man:fail2ban(1)
Sie könnten Fail2ban sofort aktivieren, aber zuerst werden Sie einige seiner Funktionen überprüfen.
Schritt 2 – Konfiguration von Fail2ban
Der Fail2ban-Dienst speichert seine Konfigurationsdateien im Verzeichnis /etc/fail2ban
. Es gibt eine Datei mit den Standardeinstellungen namens jail.conf
. Gehen Sie zu diesem Verzeichnis und geben Sie die ersten 20 Zeilen dieser Datei mit dem Befehl head -20
aus:
Output#
# WARNUNG: stark überarbeitet in Version 0.9.0. Bitte überprüfen und
# passen Sie die Einstellungen für Ihre Konfiguration an.
#
# Änderungen: In den meisten Fällen sollten Sie diese Datei nicht ändern,
# sondern Anpassungen in der jail.local-Datei vornehmen,
# oder separate .conf-Dateien im Verzeichnis jail.d/ erstellen, z. B.:
#
# AKTIVIERUNG VON JAILS:
#
# SIE SOLLTEN DIESE DATEI NICHT ÄNDERN.
#
# Sie wird wahrscheinlich überschrieben oder verbessert bei einem Distributionsupdate.
#
# Stellen Sie Anpassungen in einer jail.local-Datei oder einer jail.d/customisation.local-Datei bereit.
# Zum Beispiel, um die Standard-Sperrdauer für alle Jails zu ändern und den
# ssh-iptables-Jail zu aktivieren, würden die folgenden (auskommentierten) Zeilen in der .local-Datei erscheinen.
# Siehe man 5 jail.conf für Details.
#
# [DEFAULT]
Wie Sie sehen werden, sind die ersten Zeilen dieser Datei auf Kommentarbasis auskommentiert – sie beginnen mit #
-Zeichen, was darauf hinweist, dass sie als Dokumentation und nicht als Einstellungen zu lesen sind. 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 Sie erstellen und sammeln alle Ihre lokalen Einstellungen in einer jail.local
-Datei. Die jail.conf
-Datei wird regelmäßig aktualisiert, wenn Fail2ban selbst aktualisiert wird, und wird als Quelle für Standard-Einstellungen verwendet, für die Sie keine Überschreibungen erstellt haben.
In diesem Tutorial erstellen Sie jail.local
. Sie können dies tun, indem Sie jail.conf
kopieren:
Jetzt können Sie mit der Konfigurationsänderung beginnen. Öffnen Sie die Datei in vi
oder Ihrem bevorzugten Texteditor:
Während Sie durch die Datei blättern, wird dieses Tutorial einige Optionen überprüfen, die Sie möglicherweise aktualisieren möchten. Die Einstellungen unter dem Abschnitt [DEFAULT]
am Anfang der Datei 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 Standardeinstellungen liegen.
[DEFAULT]
. . .
bantime = 10m
. . .
Der Parameter bantime
legt die Dauer fest, für die ein Client gesperrt wird, wenn er sich nicht ordnungsgemäß 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, mit denen sich ein Client innerhalb eines Zeitfensters, das durch findtime
definiert ist, authentifizieren kann, bevor er gesperrt wird. Mit den Standardeinstellungen sperrt der Fail2ban-Dienst einen Clienten, der innerhalb eines 10-minütigen Zeitfensters 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 für destemail
, sendername
und mta
überprüfen. Der Parameter destemail
legt die E-Mail-Adresse fest, an die Sperrmeldungen gesendet werden sollen. Mit sendername
wird der Wert im Feld „Von“ in der E-Mail festgelegt. Der Parameter mta
konfiguriert den Maildienst, der zum Senden von E-Mails verwendet wird. Standardmäßig ist dies sendmail
, aber Sie können auch Postfix oder eine andere Mail-Lösung verwenden.
[DEFAULT]
. . .
action = $(action_)s
. . .
Dieser Parameter konfiguriert die Aktion, die Fail2ban durchführt, wenn es eine Sperre einführen möchte. Der Wert Aktion_
ist kurz vor diesem Parameter in der Datei definiert. Die Standardaktion besteht darin, die Firewall-Konfiguration zu aktualisieren, um den Datenverkehr vom betroffenen Host abzulehnen, bis die Sperrzeit abläuft.
Es gibt andere Aktion_
-Skripte, die standardmäßig bereitgestellt werden, die Sie mit $(Aktion_)
oben ersetzen können:
…
# Sperre & senden Sie eine E-Mail mit 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 & senden Sie eine E-Mail mit 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 Sie diese Aktion verwenden sollten
#
# Sperre & senden Sie eine Xarf-E-Mail an den Missbrauchskontakt der IP-Adresse und fügen Sie 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 bei CloudFlare & senden Sie eine E-Mail mit 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 nimmt action_mw
Aktion und sendet eine E-Mail, action_mwl
nimmt Aktion, sendet eine E-Mail und enthält Logging, und action_cf_mwl
tut all das zusätzlich dazu, dass es auch eine Aktualisierung an die Cloudflare-API sendet, die mit Ihrem Konto verbunden ist, um den Täter auch dort zu sperren.
Einstellungen für individuelle Gefängnisse
Als nächstes folgt der Teil der Konfigurationsdatei, der sich mit individuellen Diensten befasst. Diese werden durch Abschnittsüberschriften wie [sshd]
angegeben.
Jeder dieser Abschnitte muss individuell aktiviert werden, indem unter der Überschrift eine Zeile enabled = true
hinzugefügt wird, zusammen mit ihren anderen Einstellungen.
[jail_to_enable]
. . .
enabled = true
. . .
Für dieses Tutorial aktivieren Sie das SSH-Gefängnis. Es sollte oben in den Einstellungen für individuelle Gefängnisse stehen. Die Standardparameter funktionieren sonst, aber Sie müssen eine Konfigurationszeile hinzufügen, die unter der Überschrift [sshd]
sagt enabled = true
.
#
# JAILS
#
#
# SSH-Server
#
[sshd]
# Um aggressivere sshd-Modi zu verwenden, setzen Sie den Filterparameter "mode" in jail.local:
# normal (Standard), ddos, extra oder aggressive (kombiniert alle).
# Siehe "tests/files/logs/sshd" oder "filter.d/sshd.conf" für Beispiele und Details zur Verwendung.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
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 Wert des filter
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 häufig verwendete Kurzschreibweise für Textanalysen), die bestimmen, ob eine Zeile im Protokoll einen fehlgeschlagenen Authentifizierungsversuch darstellt. Wir werden diese Dateien in diesem Leitfaden nicht im Detail behandeln, da sie ziemlich 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:
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 ziemlich 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 Teil Ihrer Website mit Login-Versuchen überlastet 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.
Das ist 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 vi
verwenden, verwenden Sie :x
, um zu speichern und zu beenden. An diesem Punkt können Sie Ihren Fail2ban-Dienst aktivieren, damit er ab sofort automatisch ausgeführt wird. Führen Sie zuerst systemctl enable
aus:
Dann starten Sie ihn manuell zum ersten Mal mit systemctl start
:
Sie können überprüfen, ob er läuft, mit systemctl status
:
Output● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: disabled
Active: active (running) since Mon 2022-06-27 19:25:15 UTC; 3s ago
Docs: man:fail2ban(1)
Main PID: 39396 (fail2ban-server)
Tasks: 5 (limit: 1119)
Memory: 12.9M
CPU: 278ms
CGroup: /system.slice/fail2ban.service
└─39396 /usr/bin/python3.6 -s /usr/bin/fail2ban-server -xf start
Jun 27 19:25:15 fail2ban22 systemd[1]: Started Fail2Ban Service.
Jun 27 19:25:15 fail2ban22 fail2ban-server[39396]: Server ready
Im nächsten Schritt werden Sie Fail2ban in Aktion sehen.
Schritt 3 — Testen der Sperrrichtlinien (optional)
Von einem anderen Server, der sich in Zukunft nicht auf Ihrem Fail2ban-Server anmelden muss, können Sie die Regeln testen, indem Sie diesen zweiten Server sperren lassen. Melden Sie sich nach dem Einloggen auf Ihrem zweiten Server an und versuchen Sie, eine SSH-Verbindung zum Fail2ban-Server herzustellen. Sie können versuchen, sich mit einem nicht vorhandenen Namen anzumelden:
Geben Sie zufällige Zeichen in das Passwortfeld ein. Wiederholen Sie dies einige Male. Irgendwann sollte sich der Fehler, den Sie erhalten, von Permission denied
zu Connection refused
ä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 die Ausgabe von fail2ban-client
überprüfen. fail2ban-client
ist ein zusätzliches Befehl, der von Fail2ban bereitgestellt wird, um die laufende Konfiguration zu überprüfen.
OutputStatus
|- Number of jail: 1
`- Jail list: sshd
Wenn Sie fail2ban-client status sshd
ausführen, können Sie die Liste der IPs sehen, die von SSH gesperrt wurden:
OutputStatus for the jail: sshd
|- Filter
| |- Currently failed: 2
| |- Total failed: 7
| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 134.209.165.184
Der Inhalt der Gesperrten IP-Liste
sollte die IP-Adresse Ihres zweiten Servers widerspiegeln.
Abschluss
Sie sollten nun in der Lage sein, einige Sperrrichtlinien für Ihre Dienste zu konfigurieren. Fail2ban ist eine nützliche Möglichkeit, um 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 zum Thema wie fail2ban-Regeln und -Dateien funktionieren überprüfen.
Für Informationen darüber, wie Sie fail2ban verwenden können, um andere Dienste zu schützen, können Sie lesen über Wie man einen Nginx-Server mit Fail2Ban schützt und Wie man einen Apache-Server mit Fail2Ban schützt.
Source:
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-rocky-linux-8