Einführung
SSH ist die Standardmethode zum Verbinden mit einem Cloud-Server. Es ist robust und erweiterbar – wenn neue Verschlüsselungsstandards entwickelt werden, können sie verwendet werden, um neue SSH-Schlüssel zu generieren, wodurch sichergestellt wird, dass das Kernprotokoll sicher bleibt. Allerdings ist kein Protokoll oder Software-Stack vollständig foolproof, 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 erhalten.
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, werden Sie oft wiederholte, systematische Anmeldeversuche sehen, die Brute-Force-Angriffe von Benutzern und Bots darstellen. Obwohl Sie einige Optimierungen an Ihrem SSH-Dienst vornehmen können, um die Wahrscheinlichkeit dieser erfolgreichen 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 auf den Standard-SSH-Port 22 aus dem externen Internet zuzugreifen, ohne zusätzliche Softwareabstraktionen oder Gateways. Diese VPN-Lösungen genießen weitgehendes Vertrauen, können jedoch Komplexität hinzufügen und einige Automatisierungen oder andere kleine Softwareanbindungen beeinträchtigen.
Vor oder zusätzlich zur Umsetzung 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 Ihre Firewall-Konfiguration automatisch ändern, um bestimmte IPs nach einer bestimmten Anzahl von fehlgeschlagenen Anmeldeversuchen zu sperren. Dadurch kann sich Ihr Server gegen diese Zugriffsversuche ohne Ihr Eingreifen absichern.
In einem anderen Tutorial haben wir Wie man SSH mit Fail2ban schützt diskutiert. In diesem Leitfaden werden wir ausführlicher erläutern, wie Fail2ban tatsächlich funktioniert und wie Sie dieses Wissen nutzen können, um das Verhalten dieses Dienstes zu ändern oder zu erweitern.
Die Grundlagen von Fail2ban
Ziel von Fail2ban ist es, die Protokolle gängiger Dienste zu überwachen, um Muster bei Authentifizierungsfehlern zu erkennen.
Wenn fail2ban so konfiguriert ist, dass es die Protokolle eines Dienstes überwacht, betrachtet es ein Filter, das speziell für diesen Dienst konfiguriert wurde. Der Filter ist darauf ausgelegt, Authentifizierungsfehler für diesen spezifischen Dienst mithilfe komplexer regulärer Ausdrücke zu identifizieren. Reguläre Ausdrücke sind eine übliche Vorlagensprache, die für die Mustererkennung verwendet wird. Es definiert diese regulären Ausdrucksmuster in eine interne Variable namens failregex.
Standardmäßig enthält Fail2ban Filterdateien für gängige Dienste. Wenn ein Protokoll von einem beliebigen Dienst, wie einem Webserver, mit dem failregex in seinem Filter übereinstimmt, wird eine vordefinierte Aktion für diesen Dienst ausgeführt. Die Aktion ist eine Variable, die konfiguriert werden kann, um je nach den Vorlieben des Administrators viele verschiedene Dinge zu tun.
Die Standardaktion besteht darin, den verstoßenden Host/IP-Adresse zu sperren, indem die lokalen Firewall-Regeln geändert werden. Sie können diese Aktion erweitern, um beispielsweise eine E-Mail an Ihren Systemadministrator zu senden.
Standardmäßig wird eine Aktion ausgeführt, wenn drei Authentifizierungsfehler in 10 Minuten erkannt wurden, und die Standard-Sperrzeit beträgt 10 Minuten. Dies ist konfigurierbar.
Beim Verwenden der Standard-iptables-Firewall erstellt fail2ban eine neue Reihe von Firewall-Regeln, auch Kette genannt, wenn der Dienst gestartet wird. Es fügt eine neue Regel zur EINGABE-Kette hinzu, die den gesamten TCP-Verkehr, der auf Port 22 gerichtet ist, an die neue Kette sendet. In der neuen Kette wird eine einzelne Regel eingefügt, die zur EINGABE-Kette zurückkehrt. Die Kette und die zugehörigen Regeln werden entfernt, wenn der Fail2ban-Dienst gestoppt wird.
Erkunden der Fail2ban-Diensteinstellungen
Fail2ban wird über mehrere Dateien konfiguriert, die sich in einer Hierarchie unter dem Verzeichnis /etc/fail2ban/ befinden.
Die Datei fail2ban.conf konfiguriert einige operationelle Einstellungen wie die Art und Weise, wie das Daemon Informationen protokolliert, sowie den Socket und die PID-Datei, die verwendet werden sollen. Die Hauptkonfiguration wird jedoch in den Dateien festgelegt, die die „Jails“ pro Anwendung definieren.
Standardmäßig wird Fail2ban mit einer Datei jail.conf ausgeliefert. Diese kann jedoch bei Updates überschrieben werden, daher sollten Sie diese Datei in eine jail.local-Datei kopieren und dort Anpassungen vornehmen.
Wenn Sie bereits eine jail.local-Datei haben, öffnen Sie sie mit nano oder Ihrem bevorzugten Texteditor:
Wenn Sie keine jail.local-Datei haben oder die von Ihnen geöffnete Datei leer war, kopieren Sie die jail.conf-Datei und öffnen Sie dann die neue Datei:
Wir werden uns die hier verfügbaren Optionen ansehen und sehen, wie diese Datei mit anderen Konfigurationsdateien auf dem System interagiert.
Der Standardabschnitt
Der erste Teil der Datei wird die Standardwerte für die Fail2ban-Richtlinie definieren. Diese Optionen können in jedem einzelnen Konfigurationsabschnitt des Dienstes überschrieben werden.
Ohne Kommentare sieht der gesamte Standardbereich wie folgt aus:
[DEFAULT]
ignoreip = 127.0.0.1/8
bantime = 10m
findtime = 10m
maxretry = 3
backend = auto
usedns = warn
destemail = root@localhost
sendername = Fail2Ban
banaction = iptables-multiport
mta = sendmail
protocol = tcp
chain = INPUT
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s", sendername="%(sendername)s"]
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s", sendername="%(sendername)s"]
action = %(action_)s
Lassen Sie uns über einige dieser Bedeutungen sprechen:
- ignoreip: Dieser Parameter identifiziert IP-Adressen, die vom Sperrsystem ignoriert werden sollen. Standardmäßig ist dies nur so eingestellt, dass der Datenverkehr vom eigenen Gerät ignoriert wird, damit Sie Ihre eigenen Protokolle nicht füllen oder sich selbst aussperren.
- bantime: Dieser Parameter legt die Länge eines Verbots in Sekunden fest. Die Standardeinstellung beträgt 10 Minuten.
- findtime: Dieser Parameter legt das Zeitfenster fest, auf das Fail2ban achten wird, wenn es nach wiederholten fehlgeschlagenen Authentifizierungsversuchen sucht. Die Standardeinstellung beträgt 10 Minuten, was bedeutet, dass die Software die Anzahl der fehlgeschlagenen Versuche in den letzten 10 Minuten zählt.
- maxretry: Dies legt die Anzahl der fehlgeschlagenen Versuche fest, die innerhalb des
findtime-Zeitfensters toleriert werden, bevor ein Verbot verhängt wird. - backend: Dieser Eintrag legt fest, wie Fail2ban Logdateien überwacht. Die Einstellung von
autobedeutet, dass Fail2ban versuchen wird,pyinotify, danngaminund dann einen Polling-Algorithmus basierend auf dem Verfügbarkeitsstatus zu verwenden.inotifyist eine integrierte Funktion des Linux-Kernels zum Verfolgen von Dateizugriffen, undpyinotifyist eine Python-Schnittstelle zuinotify, die von Fail2ban verwendet wird. - usedns: Dies definiert, ob Reverse-DNS verwendet wird, um das Implementieren von Sperren zu unterstützen. Wenn Sie dies auf „nein“ setzen, werden die IPs selbst gesperrt, anstatt ihre Domain-Namen zu sperren. Die Einstellung
warnwird versuchen, einen Hostnamen nachzuschlagen und auf diese Weise zu sperren, aber die Aktivität wird protokolliert und überprüft. - destemail: Dies ist die Adresse, an die Benachrichtigungsmails gesendet werden, wenn Sie Ihre Aktion zur Mailbenachrichtigung konfiguriert haben.
- sendername: Dies wird im Feld „Von“ der generierten Benachrichtigungs-E-Mails verwendet
- banaction: Dies legt die Aktion fest, die ausgeführt wird, wenn der Schwellenwert erreicht ist. Dies ist tatsächlich ein Pfad zu einer Datei im Verzeichnis
/etc/fail2ban/action.d/namensiptables-multiport.conf. Dies behandelt die tatsächliche Manipulation deriptables-Firewall zum Sperren einer IP-Adresse. Wir werden uns dies später ansehen. - mta: Dies ist der Mail-Transfer-Agent, der zum Senden von Benachrichtigungs-E-Mails verwendet wird.
- protocol: Dies ist der Typ des Datenverkehrs, der abgewiesen wird, wenn eine IP-Sperre implementiert wird. Dies ist auch der Typ des Datenverkehrs, der an die neue iptables-Kette gesendet wird.
- chain: Dies ist die Kette, die mit einer Sprungregel konfiguriert wird, um den Datenverkehr an den Fail2ban-Trichter zu senden.
Die restlichen Parameter definieren verschiedene Aktionen, die angegeben werden können. Sie geben einige der oben definierten Parameter mithilfe der Variablenersetzung innerhalb von Textzeichenfolgen wie dieser weiter:
%(var_name)s
Die Zeile oben würde durch den Inhalt von var_name ersetzt werden. Auf diese Weise können wir feststellen, dass die action-Variable standardmäßig auf die action_-Definition gesetzt ist (nur Sperren, keine E-Mail-Benachrichtigungen).
Dies wird wiederum konfiguriert, indem die iptables-multiport-Aktion mit einer Liste von Parametern (Dienstname, Port, Protokoll und Kette) aufgerufen wird, die benötigt werden, um das Verbot durchzuführen. Der __name__ wird durch den Namen des Dienstes ersetzt, wie unten in den Abschnittsüberschriften angegeben.
Abschnitte für spezifische Dienste
Unterhalb des Standardabschnitts gibt es Abschnitte für spezifische Dienste, die verwendet werden können, um die Standardeinstellungen zu überschreiben. Dies folgt einer Konvention, nur die Parameter zu ändern, die sich von den normalen Werten unterscheiden (Konvention über Konfiguration).
Jede Abschnittsüberschrift ist wie folgt angegeben:
[Dienstname]
Jeder Abschnitt, der die Zeile enabled = true hat, wird gelesen und aktiviert.
In jedem Abschnitt werden die Parameter konfiguriert, einschließlich der Filterdatei, die zum Analysieren der Protokolle verwendet werden soll (ohne Dateierweiterung) und des Speicherorts der Protokolldateien selbst.
Unter Berücksichtigung dessen sieht der Abschnitt, der die Aktionen für den SSH-Dienst spezifiziert, wie folgt aus:
[SSH]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
Dies aktiviert diesen Abschnitt und setzt den Port auf den Standard-„ssh“-Port (Port 22). Es sagt Fail2ban, dass es das Protokoll unter /var/log/auth.log für diesen Abschnitt betrachten soll und das Protokoll mithilfe der Filtermechanismen analysieren soll, die in dem Verzeichnis /etc/fail2ban/filters.d in einer Datei namens sshd.conf definiert sind.
Alle anderen benötigten Informationen werden aus den in der [DEFAULT]-Sektion definierten Parametern übernommen. Zum Beispiel wird die Aktion auf action_ gesetzt, die die IP-Adresse des Übeltäters mithilfe der iptables-multiport Banaction sperrt, die auf eine Datei namens iptables-multiport.conf verweist, die in /etc/fail2ban/action.d gefunden wird.
Wie Sie sehen können, sollten die Aktionen in der [DEFAULT]-Sektion allgemein und flexibel sein. Die Verwendung von Parameterersetzungen zusammen mit Parametern, die sinnvolle Standardwerte bieten, ermöglicht es, Definitionen bei Bedarf zu überschreiben.
Überprüfen der Filterdatei
Um zu verstehen, was in unserer Konfiguration passiert, müssen wir die Filter- und Aktionsdateien verstehen, die den Großteil der Arbeit erledigen.
Die Filterdatei bestimmt die Zeilen, nach denen fail2ban in den Protokolldateien sucht, um verstoßende Merkmale zu identifizieren. Die Aktionsdatei implementiert alle erforderlichen Aktionen, von der Erstellung einer Firewall-Struktur beim Start des Dienstes über das Hinzufügen und Löschen von Regeln bis hin zum Abbau der Firewall-Struktur beim Beenden des Dienstes.
Lassen Sie uns die Filterdatei betrachten, die unser SSH-Dienst in der obigen Konfiguration aufgerufen hat:
[INCLUDES]
before = common.conf
[Definition]
_daemon = sshd
failregex = ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error) for .* from <HOST>( via \S+)?\s*$
^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$
^%(__prefix_line)sFailed \S+ for .*? from <HOST>(?: port \d*)?(?: ssh\d*)?(: (ruser .*|(\S+ ID \S+ \(serial \d+\) CA )?\S+ %(__md5hex)s(, client user ".*", client host ".*")?))?\s*$
^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$
^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because listed in DenyUsers\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because not in any group\s*$
^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because a group is listed in DenyGroups\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$
ignoreregex =
Der Abschnittskopf [INCLUDES] gibt an, welche anderen Filterdateien vor oder nach dieser Datei gelesen werden. In unserem Beispiel wird die Datei common.conf eingelesen und vor den anderen Zeilen in dieser Datei platziert. Dadurch werden einige Parameter eingerichtet, die wir in unserer Konfiguration verwenden werden.
Dann haben wir einen Abschnitt [Definition], der die tatsächlichen Regeln für unsere Filterübereinstimmungen definiert. Zuerst setzen wir den Namen des Daemons, den wir überwachen, mit dem Parameter _daemon.
Danach gehen wir durch die tatsächliche Definition von failregex, die die Muster festlegt, die ausgelöst werden, wenn eine übereinstimmende Zeile in der Protokolldatei gefunden wird. Dies sind reguläre Ausdrücke, die basierend auf den verschiedenen Fehlern und Fehlschlägen übereinstimmen, die auftreten können, wenn ein Benutzer sich nicht korrekt authentifiziert.
Teile der Zeile wie %(__prefix_line)s werden durch den Wert eines Parameters ersetzt, der in der von uns eingebundenen Datei common.conf eingerichtet ist. Dies wird verwendet, um die unterschiedlichen führenden Informationen anzupassen, die Betriebssysteme in Protokolldateien schreiben, wenn sie Standardmethoden verwenden. Zum Beispiel könnten einige Zeilen aus der Datei /var/log/auth.log wie folgt aussehen:
May 6 18:18:52 localhost sshd[3534]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=101.79.130.213
May 6 18:18:54 localhost sshd[3534]: Failed password for invalid user phil from 101.79.130.213 port 38354 ssh2
May 6 18:18:54 localhost sshd[3534]: Received disconnect from 101.79.130.213: 11: Bye Bye [preauth]
Der markierte Abschnitt ist ein Standardmuster, das das Betriebssystem einfügt, um mehr Kontext bereitzustellen. Danach gibt es verschiedene Möglichkeiten, wie der iptables-Firewall-Dienst Fehlerversuche in das Protokoll schreibt.
Wir sehen zwei separate Fehler in den ersten beiden Zeilen oben (einen PAM-Authentifizierungsfehler und einen Passwortfehler). Die in der Filterdatei definierten regulären Ausdrücke sind so konzipiert, dass sie zu einer der möglichen Fehlerzeilen passen. Sie sollten keine dieser Zeilen anpassen müssen, aber Sie sollten sich der Notwendigkeit bewusst sein, alle Protokolleinträge zu erfassen, die einen unbefugten Benutzungsfehler für die von Ihnen zu schützende Anwendung anzeigen, falls Sie jemals eine Filterdatei selbst erstellen müssen.
Unten sehen Sie einen ignoreregex-Parameter, der derzeit leer ist. Dies kann verwendet werden, um spezifischere Muster auszuschließen, die normalerweise eine Fehlerbedingung darstellen würden, falls Sie den Auslöser für Fail2Ban für bestimmte Szenarien negieren möchten. Wir werden dies nicht anpassen.
Speichern Sie die Datei und schließen Sie sie, wenn Sie fertig sind.
Prüfen der Aktionsdatei
Werfen wir nun einen Blick auf die Aktionsdatei. Diese Datei ist dafür verantwortlich, die Firewall mit einer Struktur einzurichten, die Änderungen ermöglicht, um bösartige Hosts zu sperren, und um diese Hosts bei Bedarf hinzuzufügen und zu entfernen.
Die Aktion, die unser SSH-Dienst aufruft, heißt iptables-multiport. Öffnen Sie die zugehörige Datei jetzt:
Mit den Kommentaren entfernt, sieht diese Datei etwa so aus:
[INCLUDES]
before = iptables-blocktype.conf
[Definition]
actionstart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
actionstop = iptables -D <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
actioncheck = iptables -n -L <chain> | grep -a 'fail2ban-<name>[ \t]'
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j <blocktype>
actionunban = iptables -D fail2ban-<name> -s <ip> -j <blocktype>
[Init]
name = default
port = ssh
protocol = tcp
chain = INPUT
Die Datei beginnt mit der Einbindung einer anderen Aktionsdatei namens iptables-blocktype.conf, die den blocktype-Parameter definiert, der die Einschränkung festlegt, die gesetzt wird, wenn ein Client gesperrt wird. Standardmäßig ist der blocktype auf das Zurückweisen von Paketen und das Antworten auf Pings gesetzt, die von gesperrten Clients gesendet werden, mit einer Ablehnungsnachricht, dass der Port nicht erreichbar ist. Wir werden dies in unseren Sperrregeln unten verwenden.
Als nächstes kommen wir zu den Regeldefinitionen selbst. Die actionstart-Aktion richtet die iptables-Firewall ein, wenn der fail2ban-Dienst gestartet wird. Es erstellt eine neue Kette, fügt dieser Kette eine Regel hinzu, um zur aufrufenden Kette zurückzukehren, und fügt dann eine Regel am Anfang der INPUT-Kette ein, die den Datenverkehr, der zu den korrekten Protokoll- und Zielportzielen passt, an die neue Kette weiterleitet.
Dies geschieht, indem die Werte verwendet werden, die wir mit der action übergeben haben, die wir in unserer jail.local-Datei definiert haben. Der Name wird aus der Abschnittsüberschrift für jeden Dienst entnommen. Die Kette, das Protokoll und der Port werden aus der action-Zeile selbst in dieser Datei entnommen.
Hier werden alle Parameter, die von der anderen Datei gesetzt sind, referenziert, indem der Parametername in spitzen Klammern eingeschlossen wird:
<param_name>
Wenn wir zur Begleiterdefinition von actionstop gehen, können wir sehen, dass die Firewall-Befehle eine Umkehrung der actionstart-Befehle implementieren. Wenn der Fail2ban-Dienst stoppt, entfernt er sauber alle Firewall-Regeln, die er hinzugefügt hat.
Eine weitere Aktion namens actioncheck stellt sicher, dass die entsprechende Kette erstellt wurde, bevor versucht wird, Sperrregeln hinzuzufügen.
Als nächstes kommen wir zur tatsächlichen Sperrregel namens actionban. Diese Regel funktioniert, indem eine neue Regel zu unserer erstellten Kette hinzugefügt wird. Die Regel stimmt mit der Quell-IP-Adresse des betreffenden Clients überein – dieser Parameter wird aus den Autorisierungsprotokollen gelesen, wenn das maxretry-Limit erreicht ist. Es setzt den Block gemäß des blocktype-Parameters um, den wir im [INCLUDE]-Abschnitt oben in der Datei bezogen haben.
Die Regel actionunban entfernt diese Regel. Dies geschieht automatisch durch fail2ban, wenn die Sperrzeit abgelaufen ist.
Zum Schluss kommen wir zum [Init]-Abschnitt. Dieser bietet nur einige Standardeinstellungen, falls die Aktionsdatei aufgerufen wird, ohne alle entsprechenden Werte zu übergeben.
Wie der Fail2ban-Dienst Konfigurationsdateien verarbeitet, um Sperren zu implementieren
Nachdem wir die Einzelheiten gesehen haben, gehen wir nun über den Prozess, der stattfindet, wenn fail2ban gestartet wird.
Das Laden der Initialkonfigurationsdateien
Zuerst wird die Hauptdatei fail2ban.conf gelesen, um die Bedingungen zu bestimmen, unter denen der Hauptprozess arbeiten soll. Es erstellt die Socket-, PID- und Protokolldateien, falls erforderlich, und beginnt, sie zu verwenden.
Anschließend liest fail2ban die Datei jail.conf für Konfigurationsdetails. Es folgt dem Lesen, in alphabetischer Reihenfolge, aller Dateien im Verzeichnis jail.d, die mit .conf enden. Es fügt die in diesen Dateien gefundenen Einstellungen seiner internen Konfiguration hinzu und gibt neuen Werten den Vorzug gegenüber den Werten, die in der Datei jail.conf beschrieben sind.
Dann sucht es nach einer Datei jail.local und wiederholt diesen Vorgang, indem es die neuen Werte anpasst. Schließlich durchsucht es erneut das Verzeichnis jail.d, liest Dateien in alphabetischer Reihenfolge ein, die mit .local enden.
In unserem Fall haben wir nur eine Datei jail.conf und eine Datei jail.local. In unserer jail.local-Datei müssen wir nur die Werte definieren, die sich von der jail.conf-Datei unterscheiden. Der fail2ban-Prozess hat nun einen Satz von Direktiven im Speicher geladen, die eine Kombination aller gefundenen Dateien darstellen.
Es überprüft jeden Abschnitt und sucht nach einer enabled = true Anweisung. Wenn es eine findet, verwendet es die unter diesem Abschnitt definierten Parameter, um eine Richtlinie zu erstellen und zu entscheiden, welche Aktionen erforderlich sind. Alle Parameter, die im Abschnitt des Dienstes nicht gefunden werden, verwenden die in der [DEFAULT]-Sektion definierten Parameter.
Parsen der Aktionsdateien zur Bestimmung der Startaktionen
Fail2ban sucht nach einer action-Anweisung, um herauszufinden, welches Aktionsskript aufgerufen werden soll, um die Sperr-/Entsperrrichtlinien umzusetzen. Wenn eine nicht gefunden wird, greift es auf die oben festgelegte Standardaktion zurück.
Die Aktion-Anweisung besteht aus dem Namen der Aktionsdatei(en), die gelesen werden sollen, sowie einem Schlüssel-Wert-Dictionary, das die von diesen Dateien benötigten Parameter übergibt. Die Werte dieser nehmen oft die Form von Parameterersetzungen an, indem sie auf die in Abschnitt des Dienstes konfigurierten Einstellungen verweisen. Der Schlüssel „name“ erhält normalerweise den Wert der speziellen __name__-Variablen, die auf den Wert des Abschnittsheaders festgelegt wird.
Fail2ban verwendet diese Informationen dann, um die zugehörigen Dateien im action.d-Verzeichnis zu finden. Es sucht zuerst nach der zugehörigen Aktionsdatei mit der Endung .conf und ergänzt dann die dort gefundenen Informationen um alle Einstellungen, die in einer begleitenden .local-Datei enthalten sind, die sich ebenfalls im action.d-Verzeichnis befindet.
Es analysiert diese Dateien, um die Aktionen zu bestimmen, die es ausführen muss. Es liest den Wert actionstart, um die Aktionen zu sehen, die es ausführen soll, um die Umgebung einzurichten. Dies umfasst oft das Erstellen einer Firewall-Struktur, um zukünftige Sperrregeln aufzunehmen.
Die in dieser Datei definierten Aktionen verwenden die ihr übergebenen Parameter des action-Befehls. Diese Werte werden dann verwendet, um dynamisch die entsprechenden Regeln zu erstellen. Wenn eine bestimmte Variable nicht gesetzt war, kann es die in der Aktionsdatei festgelegten Standardwerte verwenden, um die Lücken zu füllen.
Filterdateien analysieren, um Filterregeln zu bestimmen
Die Parameter für den Dienst in den jail.*-Dateien enthalten auch den Speicherort der Protokolldatei sowie den Abfragemechanismus, der verwendet werden soll, um die Datei zu überprüfen (dies wird durch den backend-Parameter definiert). Es enthält auch einen Filter, der verwendet werden soll, um festzustellen, ob eine Zeile im Protokoll einen Fehler darstellt.
Fail2ban sucht im Verzeichnis filter.d nach der passenden Filterdatei, die mit .conf endet. Es liest diese Datei, um die Muster zu definieren, die verwendet werden können, um beleidigende Zeilen abzugleichen. Anschließend wird nach einer passenden Filterdatei gesucht, die mit .local endet, um zu sehen, ob irgendwelche Standardparameter überschrieben wurden.
Es verwendet die regulären Ausdrücke, die in diesen Dateien definiert sind, während es die Protokolldatei des Dienstes liest. Es versucht jede failregex-Zeile, die in den filter.d-Dateien definiert ist, gegen jede neue Zeile, die in die Protokolldatei des Dienstes geschrieben wird.
Wenn der reguläre Ausdruck eine Übereinstimmung zurückgibt, überprüft es die Zeile gegen die regulären Ausdrücke, die durch die ignoreregex definiert sind. Wenn dies ebenfalls übereinstimmt, ignoriert fail2ban es. Wenn die Zeile einem Ausdruck in der failregex entspricht, aber keinem Ausdruck in der ignoreregex entspricht, wird ein interner Zähler für den Client inkrementiert, der die Zeile verursacht hat, und ein zugehöriger Zeitstempel für das Ereignis wird erstellt.
Wenn das Zeitfenster, das durch den findtime-Parameter in den jail.*-Dateien festgelegt ist (wie durch den Ereigniszeitstempel bestimmt), erreicht ist, wird der interne Zähler wieder dekrementiert und das Ereignis wird nicht mehr als relevant für die Sperrrichtlinie betrachtet.
Wenn im Laufe der Zeit zusätzliche Authentifizierungsfehler protokolliert werden, wird bei jedem Versuch der Zähler inkrementiert. Wenn der Zähler innerhalb des konfigurierten Zeitfensters den Wert erreicht, der durch den maxretry-Parameter festgelegt ist, führt fail2ban eine Sperrung durch, indem es die actioncheck-Aktion für den Dienst aufruft, wie sie in den action.d/-Dateien für den Dienst definiert ist. Dies dient dazu festzustellen, ob die actionstart-Aktion die erforderliche Struktur eingerichtet hat. Anschließend ruft es die actionban-Aktion auf, um den beanstandeten Client zu sperren. Es setzt auch einen Zeitstempel für dieses Ereignis.
Wenn die vom bantime-Parameter angegebene Zeit abgelaufen ist, hebt fail2ban die Sperrung des Clients auf, indem es die actionunban-Aktion aufruft.
Zusammenfassung
Zu diesem Zeitpunkt haben Sie ein ziemlich tiefgehendes Verständnis dafür, wie fail2ban funktioniert. Wenn Sie von der Standardkonfiguration abweichen, ist es hilfreich zu wissen, wie fail2ban funktioniert, um sein Verhalten auf vorhersehbare Weise zu manipulieren.
Um mehr darüber zu erfahren, wie Sie andere Dienste mit fail2ban schützen können, können Sie lesen Wie Sie einen Nginx-Server mit Fail2Ban unter Ubuntu 22.04 schützen.