Brute-Force-Angriffe mit Fail2ban verhindern - Haus mit Hüter

Lesezeit
4 Minuten
Bis jetzt gelesen

Brute-Force-Angriffe mit Fail2ban verhindern - Haus mit Hüter

07.11.2012 - 12:28
Veröffentlicht in:

Wer denkt, mit dem Schließen aller Ports außer SSH wäre es getan, irrt. Brute-Force-Angriffe darauf sind trivial und gelingen häufig in kurzer Zeit. Fail2ban schiebt einen Riegel vor.

Es gibt nur wenige kleine Skripte, die sich so fundamental auf den Betrieb eines Servers auswirken wie Fail2ban. Deshalb haben vermutlich auch die meisten schon einmal davon gehört. Wer Fail2ban nicht kennt, beschäftigt sich vermutlich eher mit anderen Bereichen der Systemadministration oder ist ein relativer Neueinsteiger.

Die Skriptsammlung arbeitet mit den üblichen Firewall-Paketen zusammen und sperrt IP-Adressen nach einigen gescheiterten Login-Versuchen aus. Das klingt vielleicht nicht besonders aufregend, aber die Wunder dieses leistungsfähigen Tools stecken im Detail.

Ich selbst habe Fail2ban vorwiegend für fehlgeschlagene SSH-Logins verwendet, was vermutlich die häufigste Anwendung ist, bevor ich davon genervt war, dass die Webserver-Logfiles voll mit den Spuren von Angriffsversuchen waren. Überall fanden sich Spuren davon, versteckte Verzeichnisse oder verwundbare Content-Management-Systeme zu finden. Außerdem hatte ich einige Mailserver, die das Relaying mit SASL-Passwort-Authentifizierung [1] gegen Benutzer-Accounts per PAM erlaubten. Die SASL-Accounts waren so eingerichtet, dass man sich damit nicht auf dem System einloggen konnte, aber trotzdem barg die Authentifizierung noch ein Restrisiko. Mit Fail2ban konnte ich einfach die betreffende IP-Adresse sperren, wenn ein Username dreimal das falsche Passwort verwendete.

Transparenz

Wie Fail2ban [2] arbeitet, ist leicht erklärt. Es beobachtet die Logdateien und führt eine vordefinierte Aktion aus, wenn es ein bestimmtes Muster findet. Wie man diese Filter und Aktionen definiert, wird schnell klar, wenn Fail2bain installiert ist.

Der erwähnte Einsatz von Fail2ban, Brute-Force-Attacken auf SSG zu stoppen, ist auf jeden Fall sehr sinnvoll. Er reduziert nicht nur das Rauschen in den Log-Dateien, es ist auch ein Sicherheitsrisiko, beliebig viele Versuche bei einem solchen Login zu erlauben. Viele Angriffe durch Bots lassen sich zusätzlich verhindern, wenn man den Port ändert, auf dem SSH läuft. Wer es sich erlauben kann, etwa weil Anwender immer dieselben IP-Adressen verwenden, sichert SSH zusätzlich ab, indem er das Login per TCP-Wrapper auf bestimmte IP-Adressen beschränkt [3]. Man sollte daran denken, dass automatisierte Angriffe äußerst effizient ablaufen und einige Male pro Sekunde ablaufen können. Damit können Angreifer in wenigen Minuten eine ganze Menge populärer Passwörter ausprobieren. Abbildung 1 zeigt eine Logdatei, die fehlgeschlagene Logins wiedergibt.

Abbildung 1: So tauchen fehlgeschlagene Login-Versuche in einer Logdatei auf.
Abbildung 1: So tauchen fehlgeschlagene Login-Versuche in einer Logdatei auf.

 

Glücklicherweise gibt es bereits einigen nützliche Skripts, die bei der Installation von Fail2ban auf der Festplatte landen. Dabei gibt es einige Abkürzungen, sogenannte Tags, die man in eigenen Skripts verwenden kann, zum Beispiel HOST. Das folgende Fragment trifft auf ein fehlgeschlagenes SSH-Login zu und findet sich auf einem Debian-Rechner in /etc/fail2ban/filter.d/sshd.conf:

failregex = ^%(__prefix_line)sFailed (?:password|publickey) for .* from <HOST>(?: port \d*)?(?: ssh\d*)?$

Die Regular Expression trifft auf Zeilen zu, wie sie in Abbildung 1 zu sehen sind und passt gleichermaßen auf fehlgeschlagene Logins per Username/Passwort und Public/Private Key. Die dritte Zeile macht von dem erwähnten Host-Tag Gebrauch.

Was die Logfile-Einträge betrifft, die sich von System zu System zum Teil erheblich unterscheiden, ist Fail2ban recht flexibel. Selbst in der Standard-Konfigurationsdatei für SSH haben die Fail2ban-Entwickler eine ganze Reihe von Formulierungen für die failregex vorgesehen, von denen eine für den jeweiligen Einsatzort passen sollte. Die Beispiel in Listing 1 sind normalerweise auskommentiert.

Listing 1

Failregex-Beispiele

01 failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from <HOST>\s*$
02             ^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from<HOST>\s*$
03             ^%(__prefix_line)sFailed (?:password|publickey) for .* from <HOST>(?: port \d*)?(?: ssh\d*)?$
04             ^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$
05             ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
06             ^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers$
07             ^%(__prefix_line)sauthentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=<HOST>(?:\s+user=.*)?\s*$
08             ^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$
09             ^%(__prefix_line)sAddress <HOST> .* POSSIBLE BREAK-IN ATTEMPT!*\s*$
10             ^%(__prefix_line)sUser .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$

Regulär geprüft

Wie erwähnt, kann Fail2ban auch Angriffe auf den Mailserver abwehren, etwa Login-Versuchen per SASL. Die Failregex dafür in /etc/fail2ban/filter.d/sasl.conf sieht etwa so aus:

failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: authentication failure

Diese Regular Expression trifft auf die fehlgeschlagenen SASL-Logins zu, die im Logfile /var/log/mail.log so auftauchen. Der Ausdruck (?i) weist Fail2ban an, nicht auf die Groß- und Kleinschreibung der Strings zu achten (case insensitive). Die Syntax gehorcht den Regeln der Python Regular Expressions.

Layout

Die bisher erwähnten Konfigurationsdateien liegen im Unterverzeichnis filter.d, wo sich auch noch eine Reihe weiterer Anwendungen findet. Wenn sie nicht hundertprozentig auf das eigene Betriebssystem zutreffen, muss man sie gegebenenfalls anpassen. Auf der Fail2ban-Site gibt es für einige Services noch spezifische Howto-Dokumente, die weiterhelfen.

Die Haupt-Konfigurationsdatei heißt jail.conf und enthält viele nützliche Hinweise. So lässt sich mit ignoreip eine IP-Adresse oder eine ganzes Netz einstellen, das von der Blockade ausgenommen ist, damit sich der Admin nicht versehentlich selbst aussperrt. Außerdem enthält die Datei Default-Einstellungen, die für alle Dienste gelten, solange diese sie nicht überschreiben, etwa:

bantime = 3600
maxretry = 3

Hiermit hat jeder Anwender drei Versuche frei, sein Glück zu versuchen. Das ist recht restriktiv und vielleicht zu restriktiv für viele Situationen. Die bantime legt in Sekunden fest, wie lange eine IP-Adresse ausgesperrt bleibt.

Auch der Backend-Daemon, der die Logdateien überprüft, lässt sich festlegen. Hier ist gamin eine gute Wahl, denn hiermit wird Fail2ban über Änderungen unterrichtet und das System somit weniger belastet als durch eine ständige Überprüfung. Laut Fail2ban-Dokumentation ist diese Einstellung auf Fedora- und Red-Hat-Systemen sogar obligatorisch, weil der Logscanner sonst in Konflikt mit SE-Linux gerät.

Im Verzeichnis actions.d sind schließlich die Maßnahmen aufgeführt, die Fail2ban ergreift. Der Rest der Datei jails.conf besteht aus jeweils einer kurzen Defintion für den zu überwachenden Dienst, der sich über die Anweisung enabled ein- und ausschalten lässt:

[sasl]
enabled = true
port = smtp
filter = sasl
logpath = /var/log/mail.log

Statt konkrete Gegenmaßnahmen zu starten, kann Fail2ban auch nur einen Trigger auslösen. Die komplette Breitseite feuert dagegen Listing 2 ab, das den mutmaßlichen Angreifer blockiert und eine E-Mail mit den Logdaten und einem Whois-Auszug der IP-Adresse verschickt.

Listing 2

Aktionen: Sperren und Mailen

01 # ban the IP & send an e-mail with whois report and include relevant log lines to the destemail
02 action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
03              %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s]

Die eigentliche Blockade wird von der jeweiligen Firewall-Software ausgeführt, im Beispiel-Fall ist dies Linux-IPTables. In der Datei /etc/fail2ban/action.d/iptables-multiport.conf finden sich dafür die Einstellungen:

Actionban: actionban = iptables -I fail2ban-Name 1 -s IP -j DROP
Actionunban: actionunban = iptables -D fail2ban-Name -s IP -j DROP

Mit der ersten Zeile wird ein Eintrag in der Firewall vorgenommen, der die IP-Adresse IP sperrt, die aus dem Muster der Failregex stammt.

Fazit

Fail2ban kann helfen, Brute-Force-Attacken auf alle möglichen Dienste zu verhindern oder zumindest wesentlich zu bremsen. Vorausgesetzt wird vernünftiges Logging des jeweiligen Service und Kenntnisse von Regular Expressions auf Seiten des Administrators. Nach der Installation sollte man gelegentlich einen Blick in /var/log/fail2ban.log werfen und die Erfolgsquote des neuen Wächters überprüfen. (ofr)

Autor:  Artikel aus dem Admin Magazin Ausgabe 6/2012: Gestapelt Seite 86

Ähnliche Beiträge

So bleibt IT-Sicherheit auch für den Mittelstand bezahlbar Redaktion IT-A… Mi., 27.03.2024 - 09:16
IT-Sicherheit darf keine Kostenfrage sein. Dennoch nennen viele Unternehmen die Investitions- und Betriebskosten als Hauptgrund für ihre Zurückhaltung beim Thema Sicherheit. Doch wie viel Wahrheit steckt dahinter? Warum handeln deutsche Unternehmen (noch) nicht? Und warum ist ITSicherheit überlebenswichtig? Und welche Rolle spielt dabei NIS2? Diesen Fragen und möglichen Lösungsansätzen gehen wir in unserem Artikel auf den Grund.

Künstliche Intelligenz nutzen und datenschutzkonform agieren

Künstliche Intelligenz ist ein Meilenstein für die Technologiebranche, ihr volles Potenzial aber noch nicht ausgeschöpft. Es zeigt sich jedoch, dass KI-Anwendungen eine intensive Datennutzung und menschliches Eingreifen erfordern – nicht zuletzt um Datenschutz zu gewährleisten und mögliche neue Sicherheitsrisikien zu vermeiden. Organisationen müssen daher analysieren, wie sie KI in ihre Strategie zum Datenmanagement integrieren können.

Mehr Datensicherheit durch ganzheitliche Plattformen

Die Folgen von Cyberangriffen sind für Unternehmen verheerend. Dies gilt vor allem für Attacken auf hybride IT-Umgebungen, die Datenverluste auf mehreren Plattformen zur Folge haben. Deshalb lohnt es sich, auf ganzheitliche Werkzeuge für eine sichere Kommunikation und Datenübertragung zu setzen. Welchen maßgeblichen Beitrag Produktivitätsplattformen in den Bereichen Verwaltung, Kosteneffizienz und Reaktionsschnelligkeit leisten, erklärt unser Artikel.