Fail2ban einrichten: Server vor Brute Force schützen

Was ist fail2ban und wie schützt es einen Server?

Fail2ban ist eine quelloffene Software, die Logdateien Ihres Servers liest und IP Adressen mit zu vielen fehlgeschlagenen Anmeldeversuchen vorübergehend über eine Firewall Regel sperrt. Es bremst also Bots, die Passwörter raten. Ein schwaches Passwort oder einen unnötig offenen Dienst behebt es allerdings nicht.

Zunächst: Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hosting Anbieter. Daher folgt dieser Leitfaden der offiziellen Dokumentation und den Projektdateien von fail2ban. Als Inhaber einer Website oder eines Onlineshops verstehen Sie danach die Entscheidung. Wenn Sie Ihren eigenen VPS verwalten, finden Sie außerdem die Befehle Schritt für Schritt.

Die Logik ist einfach. Der Dienst liest das Log Zeile für Zeile, zählt Spuren fehlgeschlagener Anmeldungen und hält die Quelle für eine Weile fern, sobald ein Limit überschritten ist. Danach endet die Sperre. Ein legitimer Nutzer, den es versehentlich trifft, bleibt also nicht dauerhaft ausgesperrt.

Außerdem ist auch das Marketing betroffen. Wenn eine Website mit Werbung oder SEO Investition unter vielen Anmeldeversuchen langsamer wird, springen Besucher ab. Außerdem öffnen Landingpages spät, sobald die Serverressourcen knapp werden. Deshalb hängen Sicherheit, Geschwindigkeit und Konversion direkt zusammen. Die Geschwindigkeitsseite haben wir in unserem Beitrag wie die Ladezeit das SEO beeinflusst behandelt.

Wie arbeiten fail2ban Jail, Filter und Action zusammen?

Konkret arbeitet fail2ban mit drei Begriffen. Ein Jail legt fest, welchen Dienst es beobachtet, welche Logdatei es liest und welche Grenzwerte gelten. Ein Filter besteht aus regulären Ausdrücken, die in einer Logzeile einen fehlgeschlagenen Versuch erkennen. Eine Action ist der Sperrbefehl, der nach Überschreiten des Limits läuft.

• Jail: der Dienst, der Pfad der Logdatei und die Grenzwerte.
• Filter: failregex beschreibt einen fehlgeschlagenen Versuch, ignoreregex die Zeilen, die Sie überspringen wollen.
• Action: In den meisten Setups legt sie eine Sperrregel in der Firewall an.

Zum Beispiel spiegelt die Dateistruktur das wider. Filter liegen in /etc/fail2ban/filter.d/, Actions in action.d. Jail Definitionen schreiben Sie in jail.conf, jail.d und jail.local. Die mitgelieferten Filter decken die meisten gängigen Dienste ab, daher müssen Sie selten bei null anfangen.

Ein Filter liest außerdem die Adresse des Angreifers aus der Zeile. Dafür nutzt er Platzhalter wie <HOST>. Zum Beispiel liest das Jail sshd das SSH Log, ordnet Zeilen über den Filter sshd zu und startet dann die Sperraktion.

Gegen welche Angriffe hilft fail2ban, und gegen welche nicht?

Fail2ban hilft gegen wiederholte Versuche, die aus derselben Quelle im Log landen. Typische Beispiele sind SSH Passwortversuche, Anmeldungen an Admin Oberflächen und Fehler bei der HTTP Basisauthentifizierung. Gegen Angriffe, die nie im Log erscheinen oder von tausenden Quellen kommen, wirkt es kaum.

Die letzten beiden Zeilen sind wichtig. Allerdings installieren viele Website Inhaber fail2ban und fühlen sich danach sicher. Kennt ein Angreifer jedoch das richtige Passwort, zeigt das Log keine fehlgeschlagene Anmeldung. Dann findet fail2ban nichts, worauf es reagieren könnte.

Kurz gesagt ist fail2ban eine Sicherheitsebene, keine Komplettlösung. Lücken auf Anwendungsebene behandeln wir in unserem OWASP Top 10 Leitfaden.

Was unterscheidet Brute Force, Password Spraying und Credential Stuffing?

Diese drei Begriffe werden oft verwechselt, doch jeder verhält sich gegenüber fail2ban anders. OWASP beschreibt sie unter Angriffen auf die Authentifizierung. Also liegt der Unterschied darin, was der Angreifer probiert und wie schnell.

• Brute Force: Der Angreifer probiert viele Passwörter bei einem Konto. Aus einer einzelnen Quelle erkennen Sie das leicht.
• Password Spraying: Der Angreifer probiert wenige gängige Passwörter bei vielen Konten. Die Fehlerzahl pro Konto bleibt niedrig.
• Credential Stuffing: Der Angreifer probiert Paare aus Benutzername und Passwort aus einem anderen Datenleck.

Für den ersten Typ eignet sich fail2ban sehr gut. Bei den beiden anderen drosselt der Angreifer das Tempo oder wechselt die Adresse. Somit bleibt er unter den Grenzwerten. Deshalb schützen eine zweite Bestätigung bei der Anmeldung und einzigartige Passwörter besser als eine Sperre auf Basis von Logdateien.

Was sollten Sie vor der Installation von fail2ban prüfen?

Zunächst klären Sie vor dem Start fünf Dinge. Haben Sie root oder sudo Zugriff? Erreichen Sie die Konsole über das Panel Ihres Anbieters? Welches Firewall Backend läuft auf dem Rechner? Liegen die Logs in Dateien oder im systemd Journal? Kommt der Verkehr direkt an, oder läuft er über ein CDN oder einen Reverse Proxy?

1. Notieren Sie Ihre eigene IP Adresse. Dafür können Sie unser IP Abfrage Tool nutzen.
2. Testen Sie, ob der Konsolen oder Rettungszugang Ihres Anbieters funktioniert.
3. Prüfen Sie, ob Sie Ihr Backup wiederherstellen können. Unsere Website Backup Strategie erklärt das.
4. Probieren Sie die neue Regel zuerst auf einem Testserver oder in einem Wartungsfenster.

Der Konsolenzugang ist der wertvollste Punkt dieser Liste. Denn sperren Sie sich selbst über SSH aus, ist das Panel des Anbieters womöglich der einzige Weg zurück. Andererseits sieht fail2ban nichts, wenn Sie ein Jail schreiben, ohne den Ort der Logs zu kennen, und wiegt Sie in falscher Sicherheit.

Die Liste wirkt vielleicht trocken, denn sie ist es auch. Trotzdem hat fast jeder, der sich aussperrt, einen dieser Schritte übersprungen.

Wie installieren und starten Sie fail2ban?

Das Paket heißt bei den meisten Distributionen fail2ban. In der Debian und Ubuntu Familie reichen die folgenden Befehle. Auf Red Hat basierten Systemen kommt das Paket oft aus einem zusätzlichen Repository, deshalb prüfen Sie die Dokumentation Ihrer Distribution.

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status

Dann listet der letzte Befehl die laufenden Jails auf. Welche Jails nach der Installation aktiv sind, hängt von der Distribution ab. In der offiziellen Datei jail.conf sind Jails standardmäßig aus, und die Datei rät, nur passende zu aktivieren. Prüfen Sie die Liste also selbst.

Läuft der Dienst, lesen Sie danach /var/log/fail2ban.log. Die ersten Zeilen zeigen, welche Jails gestartet sind. Bei Fehlern finden Sie dort meist den ersten Hinweis. Ändern Sie außerdem direkt nach der Installation nichts. Beobachten Sie zunächst den Ist Zustand und gehen Sie dann in kleinen Schritten vor.

Warum bearbeiten Sie bei fail2ban jail.local statt jail.conf?

Die offizielle Dokumentation rät, .conf Dateien unverändert zu lassen. Ein Paketupdate kann sie überschreiben. Ihre Anpassungen legen Sie stattdessen in .local Dateien ab. Fail2ban legt auch die Ladereihenfolge klar fest.

1. jail.conf
2. jail.d/*.conf (in alphabetischer Reihenfolge)
3. jail.local
4. jail.d/*.local (in alphabetischer Reihenfolge)

Dabei überschreibt eine spätere Datei eine frühere. Sie müssen also nur die Zeilen in jail.local schreiben, die Sie ändern wollen. Daher kopieren Sie nicht die ganze Datei. Eine Kopie veraltet mit der Zeit und verursacht nach Updates seltsames Verhalten.

Zum Beispiel schreiben Sie nur eine Zeile, wenn Sie bloß bantime ändern wollen. Kopfzeilen und Kommentare brauchen Sie nicht. Nach der Änderung lädt sudo fail2ban-client reload die Einstellungen neu und meldet Fehler. Außerdem lohnt es sich, die Konfiguration vor dem Einsatz mit sudo fail2ban-client -t zu testen.

Was bedeuten bantime, findtime und maxretry?

Diese drei Einstellungen sind das Herz von fail2ban. Zeiten geben Sie in Sekunden oder in Kurzform wie 10m, 1h und 1d an. In der aktuellen Datei jail.conf lauten die Standardwerte bantime = 10m, findtime = 10m und maxretry = 5.

• bantime: Wie lange eine Sperre dauert.
• findtime: Das Zeitfenster, in dem Fehler zählen.
• maxretry: Wie viele Fehler in diesem Fenster eine Sperre auslösen.

Lesen Sie es so: Häufen sich maxretry Fehler innerhalb der letzten findtime, sperrt fail2ban die Adresse für bantime. Die drei Werte wirken zusammen, daher überdenken Sie die anderen, wenn Sie einen ändern.

Ein kleines Beispiel: Setzen Sie maxretry = 3 und ist findtime sehr kurz, fängt das Tool einen langsamen Angreifer nie. Ist findtime dagegen sehr lang, kann ein legitimer Nutzer, der vor Tagen ein falsches Passwort tippte, ans Limit stoßen. Wählen Sie die Werte also passend zu den Anmeldegewohnheiten Ihres Teams. Teilen sich mehrere Personen ein Konto, halten Sie das Limit etwas lockerer.

Welche fail2ban Einstellungen sind ein sinnvoller Startpunkt?

Der richtige Wert hängt von Ihrem Verkehr und der Arbeitsweise Ihres Teams ab. Die Tabelle unten ist ein Startbereich, keine Garantie. Beobachten Sie Ihre eigenen Logs und passen Sie an.

Beispielrechnung: Angenommen, maxretry = 5 und bantime = 1h. Kehrt ein Bot sofort nach Ablauf der Sperre zurück, durchläuft er höchstens 24 Sperrphasen am Tag. In jeder kann er 5 Versuche machen, die Obergrenze liegt also bei etwa 120 Versuchen. Steigende Sperrzeiten senken diese Zahl weiter, wie Sie unten sehen.

Stattdessen betrachten Sie diese Zahlen als Prüfstand. Starten Sie in der ersten Woche mit einem Profil nahe am Standard, beobachten Sie die Logs und stellen Sie sicher, dass keine Fehlsperren auftreten. Erhöhen Sie die Zeit dann schrittweise. Das klingt langsam, dennoch senkt es das Risiko, das eigene Team zu sperren.

Das strenge Profil gilt nur für Server mit Schlüsselanmeldung. Legitime Nutzer tippen dort nie ein Passwort, deshalb ist die Chance gering, das Limit versehentlich zu überschreiten. Ist die Passwortanmeldung offen, können sehr kurze Limits Ihr eigenes Team sperren.

Wie schützen Sie die SSH Anmeldung mit fail2ban?

Denn SSH ist die Tür, die Angreifer am häufigsten versuchen. Die offizielle Datei jail.conf enthält bereits einen Abschnitt sshd, Sie aktivieren ihn nur und passen die Limits an. Legen Sie die Datei als /etc/fail2ban/jail.local an.

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.10

[sshd]
enabled  = true
port     = ssh
maxretry = 4
findtime = 10m
bantime  = 1h

Haben Sie SSH auf einen anderen Port verlegt, ändern Sie die Zeile port auf denselben Wert. Sonst wendet fail2ban die Sperre auf den falschen Port an. Liegen Ihre Logs im Journal statt in einer Datei, brauchen Sie womöglich backend = systemd. Die meisten Pakete stellen das für Sie ein. Prüfen Sie trotzdem mit sudo fail2ban-client status sshd, ob das Jail wirklich läuft.

Reicht fail2ban für SSH allein aus?

Nein, denn die erste Verteidigung ist, die Passwortanmeldung abzuschalten. Die Optionen PasswordAuthentication und PermitRootLogin in der OpenSSH Datei sshd_config beschreibt die offizielle Man Page. Funktioniert die Schlüsselanmeldung, können Sie die Passwortanmeldung ausschalten.

1. Testen Sie die Schlüsselanmeldung in einer zweiten Sitzung.
2. Prüfen Sie die Konfiguration mit sudo sshd -t.
3. Laden Sie den Dienst neu. Der Dienstname kann ssh oder sshd lauten.
4. Lassen Sie Ihre aktuelle Sitzung offen und testen Sie eine neue Verbindung.

Ändern Sie diese Reihenfolge, sperren Sie sich folglich womöglich aus. Selbst dann bleibt fail2ban als zweite Ebene und dämpft jeden Versuch ohne Schlüssel. Auf einem Server, auf dem nur die Schlüsselanmeldung offen ist, scheitern Bots mit Passwortversuchen ohnehin an der Tür. Trotzdem bleiben die Logs sauber, und der unnötige Ressourcenverbrauch sinkt. Details zu den Optionen finden Sie in der Man Page zu sshd_config.

Wie schützen Sie Web Logins mit fail2ban?

Die offizielle Datei jail.conf enthält fertige Jails wie nginx-http-auth und apache-auth. Sie lesen Fehler der HTTP Basisauthentifizierung aus den Fehlerlogs. Für das eigene Anmeldeformular einer Anwendung wie WordPress schreiben Sie einen eigenen Filter.

Legen Sie zunächst /etc/fail2ban/filter.d/wp-login.conf an. Das Beispiel setzt das kombinierte Format des Zugriffslogs voraus. Weicht Ihr Logformat ab, passen Sie den Ausdruck an.

[Definition]
failregex = ^<HOST> .* "POST /wp-login\.php HTTP/[0-9.]+" 200
ignoreregex =

Fügen Sie danach das Jail zur Datei jail.local hinzu. Der Logpfad hängt von Ihrem Webserver und Ihrer Distribution ab.

[wp-login]
enabled  = true
port     = http,https
filter   = wp-login
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 10m
bantime  = 1h

Dieser Filter zählt nur POST Anfragen mit der Antwort 200. WordPress zeigt das Formular nach einer fehlgeschlagenen Anmeldung erneut und leitet nach einer erfolgreichen meist weiter. Der Ansatz hat allerdings eine Grenze. Greift der Angreifer eine andere Adresse an, sieht der Filter das nicht. XML RPC zum Beispiel braucht einen eigenen Filter. Prüfen Sie es trotzdem auf Ihrer eigenen Website; das Testwerkzeug im nächsten Abschnitt dient genau dazu.

Wie testen Sie einen eigenen Filter für fail2ban vor dem Einsatz?

Testen Sie Ihren Filter vor dem Einsatz mit dem Werkzeug fail2ban-regex. Es nimmt eine Logdatei und eine Filterdatei und meldet, wie viele Zeilen passen. Außerdem zeigt es die Zeilen ohne Treffer, daher lässt sich der Ausdruck leicht korrigieren.

sudo fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wp-login.conf

Liegt die Trefferzahl bei null, gibt es drei mögliche Gründe. Das Logformat weicht von Ihrer Erwartung ab, der Ausdruck ist falsch, oder das Log enthält gar keine fehlgeschlagenen Anmeldungen. Passen dagegen zu viele Zeilen, ist der Ausdruck zu weit gefasst und sperrt womöglich auch legitime Nutzer.

Konkret brauchen Sie für den Test keinen echten Angriff. Vorhandene Logzeilen genügen, denn das Werkzeug schickt sie durch den Filter und zeigt das Ergebnis. Außerdem können Sie den Ausdruck ändern und den Test wiederholen, um Ergebnisse zu vergleichen.

Prüfen Sie also vor dem Einsatz, ob Ihre eigene IP Adresse in der Trefferliste auftaucht. Wenn ja, tragen Sie sie in die Liste ignoreip ein.

Wie prüfen Sie die Sperrliste und den Jail Status bei fail2ban?

Die meiste Alltagsarbeit erledigen Sie mit dem Befehl fail2ban-client. Zudem stammt die Syntax aus der offiziellen Man Page. Die Beispiele unten nutzen nur reservierte IP Blöcke für Dokumentation.

Die Firewall Seite sehen Sie je nach Backend mit sudo iptables -L -n oder sudo nft list ruleset. So bestätigen Sie, dass die Sperre wirklich greift. Achten Sie beim Lesen der Ausgabe auf die Verteilung der Adressen, nicht nur auf die Zahl. Taucht eine Adresse immer wieder auf, sind steigende Sperrzeiten sinnvoll. Sehen Sie viele verschiedene Adressen, ist der Angriff verteilt, und Sperren allein genügen nicht.

Fail2ban schreibt eigene Einträge standardmäßig nach /var/log/fail2ban.log. Wollen Sie wissen, wem eine gesperrte Adresse gehört, hilft unser WHOIS Abfrage Tool.

Wie nutzen Sie steigende Sperrzeiten und das recidive Jail bei fail2ban?

Kehrt dieselbe Adresse nach einer Sperre zurück, können Sie die Zeit mit jeder Runde verlängern. Die offizielle Datei jail.conf beschreibt dafür die Einstellung bantime.increment. Fail2ban sucht frühere Sperren in seiner Datenbank und verlängert die Zeit durch Verdoppeln: 1, 2, 4, 8 und so weiter. Die Einstellung bantime.maxtime legt die Obergrenze fest.

[DEFAULT]
bantime.increment = true
bantime.maxtime   = 604800

Der Wert 604800 Sekunden entspricht einer Woche. Mit bantime.factor wählen Sie außerdem den Wachstumsfaktor, und mit bantime.overalljails entscheiden Sie, ob die Historie aller Jails durchsucht wird.

Alternativ beobachtet das Jail recidive das eigene Log von fail2ban und sperrt Wiederholungstäter lange. Der Abschnitt in der offiziellen Datei enthält bantime = 1w und findtime = 1d. Überlegen Sie vor der Aktivierung, ob diese Werte für Sie zu hart sind.

Wie verringern Sie bei fail2ban das Risiko, sich selbst auszusperren?

Allerdings ist der häufigste Fehler die Sperre der eigenen IP. Mehrfach falsch getippte Passwörter, ein Deploy Skript mit falschem Schlüssel oder Kollegen hinter derselben Büroadresse können dazu führen.

• Haben Sie eine feste IP, tragen Sie sie in die Liste ignoreip ein.
• Halten Sie beim Ändern der Konfiguration eine zweite SSH Sitzung offen.
• Testen Sie den Konsolen oder Rettungszugang Ihres Anbieters vorher.
• Nutzen Sie beim Testen eine kurze bantime und erhöhen Sie sie später.
• Vermuten Sie einen Konfigurationsfehler, testen Sie mit sudo fail2ban-client -t.

Haben Sie sich dennoch ausgesperrt, heben Sie die eigene Sperre über die Konsole mit fail2ban-client set sshd unbanip auf. Fehlt der Konsolenzugang, bleibt womöglich nur der Support des Anbieters. Nennen Sie dem Team dann Ihre Adresse und den Zeitpunkt der Sperre. So kommt die Lösung schneller. Notieren Sie außerdem die Ursache, damit es nicht wieder passiert.

Wie schreiben Sie die fail2ban Whitelist (ignoreip) richtig?

Laut offizieller Dokumentation ist ignoreip die Liste der Adressen, die nie gesperrt werden. Sie können eine einzelne IP, einen CIDR Block oder einen Hostnamen eintragen. Die Einträge trennen Sie mit Leerzeichen.

ignoreip = 127.0.0.1/8 ::1 203.0.113.10 198.51.100.0/24

Deshalb halten Sie die Liste kurz. Tragen Sie ein ganzes Büronetz ein, kann jeder darin unbegrenzt probieren. Nutzen Sie außerdem einen Hostnamen, hängen Sie davon ab, dass die Namensauflösung klappt. Bei dynamischer IP bricht die Regel, sobald sich die Adresse ändert.

Um auf einem laufenden System kurzzeitig eine Adresse hinzuzufügen, gibt es den Befehl fail2ban-client set sshd addignoreip. Diese Änderung bleibt jedoch nicht bestehen, schreiben Sie sie daher dauerhaft in jail.local. Statt dass jedes Teammitglied seine eigene Adresse einträgt, lässt sich außerdem eine sichere VPN Ausgangsadresse leichter verwalten.

Wie verhält sich fail2ban hinter einem CDN oder Reverse Proxy?

Steht ein CDN oder Reverse Proxy vor Ihrer Website, protokolliert der Webserver womöglich die Adresse des Proxys statt die des Besuchers. Dann sperrt fail2ban die falsche Adresse. Schlimmer noch: Tausende legitime Besucher stehen hinter derselben Proxy Adresse.

• Prüfen Sie zunächst, ob das Log die echte Besucheradresse zeigt.
• Zeigt es sie nicht, richten Sie das Real IP Modul des Webservers nach der Dokumentation Ihres Proxy Anbieters ein.
• Oder sperren Sie über die eigenen Sicherheitsregeln des CDN.

Zudem gibt es noch einen feinen Punkt. Läuft der Verkehr über das CDN, stoppt eine Firewall Sperre auf dem Ursprungsserver den Besucher nicht, denn die verbindende Adresse ist das CDN. Klären Sie in diesem Aufbau also zuerst Log und IP Sichtbarkeit, dann schreiben Sie Regeln.

Einfach prüfen können Sie das, indem Sie sich mit Ihrem Handy über mobile Daten anmelden und im Log nachsehen, welche Adresse erscheint. Taucht die Adresse Ihres Handys auf, kommt die echte IP korrekt an.

Kann fail2ban legitime Bots wie Googlebot sperren?

Ja, das kann passieren, denn ein zu weit gefasster Filter fängt mehr, als Sie wollen. Zum Beispiel kann ein Filter, der viele 404 Antworten als Angriff wertet, auch einen Suchmaschinen Bot erwischen. Dann beginnen Crawling Probleme, und Ihre Sichtbarkeit in der Suche leidet.

• Beschränken Sie den Filter auf sensible Adressen wie Login Formulare.
• Meiden Sie breite Regeln wie einen allgemeinen 404 Zähler.
• Wirkt eine gesperrte Adresse wie ein Suchmaschinen Bot, prüfen Sie ihre Identität.

Google beschreibt in der offiziellen Dokumentation, wie Sie Googlebot verifizieren. Details finden Sie in der Anleitung zur Googlebot Verifizierung. Eine verdächtige Adresse können Sie außerdem mit unserem IP Abfrage Tool prüfen. So vermeiden Sie, einen legitimen Bot versehentlich zu sperren.

Reicht fail2ban aus, und wie ergänzen CSF und ModSecurity es?

Allerdings reagiert fail2ban erst nachträglich. Es sieht ein Verhalten, sobald es im Log steht, und sperrt dann. Den Inhalt von Anfragen prüft es nicht. Diese Aufgabe übernimmt eine Web Application Firewall, kurz WAF. CSF ist ein Werkzeug, das die Verwaltung von Firewall Regeln erleichtert.

Gestaffelte Verteidigung können Sie mit einem Mehrfamilienhaus vergleichen. Die Firewall ist die Haustür, die WAF ist die Kamera an der Rezeption, und fail2ban ist der Wächter, der jeden wegschickt, der immer wieder an derselben Tür rüttelt. Keine Ebene schließt allein jedes Risiko. Wer die Aufgabe jeder Ebene kennt, investiert somit an der richtigen Stelle.

CSF Firewall und ModSecurity behandeln wir in eigenen Schwesterbeiträgen, daher wiederholen wir sie hier nicht. Kurz gesagt: Fail2ban schaut auf Verhalten, eine WAF schaut auf den Inhalt der Anfrage, und die Firewall entscheidet, welche Türen offen bleiben.

Dazu brauchen Sie aktuelle Software, starke Passwörter und regelmäßige Backups. Zur HTTPS Seite lesen Sie unseren Leitfaden zum SSL Zertifikat.

Wie beheben Sie Fehler, wenn fail2ban nicht funktioniert?

Dann grenzen Sie das Problem Ebene für Ebene ein. Prüfen Sie zunächst, ob der Dienst läuft, dann ob das Jail geladen ist, ob der Filter Zeilen erkennt und schließlich ob die Sperre die Firewall erreicht. Ändern Sie immer nur eine Sache. Sonst erkennen Sie nicht, welcher Schritt geholfen hat.

1. Prüfen Sie den Dienst mit sudo systemctl status fail2ban.
2. Suchen Sie Fehler in sudo journalctl -u fail2ban und in /var/log/fail2ban.log.
3. Sehen Sie nach, ob Ihr Jail in der Ausgabe von sudo fail2ban-client status erscheint.
4. Fehlt das Jail, prüfen Sie die Zeile enabled = true und suchen Sie Tippfehler.
5. Bestätigen Sie mit fail2ban-regex, dass der Filter wirklich passt.
6. Prüfen Sie logpath und backend für Ihre Distribution.
7. Kontrollieren Sie, ob die Sperrregel in der Firewall existiert. Der Befehl hängt vom Backend ab.

Erscheint keine Sperrregel, schauen Sie auf den Wert banaction. Der offizielle Standard ist iptables-multiport. Nutzt Ihr System eine andere Firewall, wählen Sie die passende Action aus dem Ordner action.d.

Wie überprüfen Sie Ihr fail2ban Setup regelmäßig?

Die Installation ist keine Aufgabe, die Sie einmal erledigen und vergessen. Ein Distributionsupdate, ein Webserver Wechsel oder ein neues Logformat kann Filter ohne Warnung brechen. Richten Sie daher eine kleine Wartungsroutine ein.

1. Prüfen Sie einmal im Monat mit fail2ban-client status, ob die Jails laufen.
2. Sehen Sie die gesperrten Adressen durch und suchen Sie Fehlsperren.
3. Führen Sie nach Updates den Test mit fail2ban-regex erneut aus.
4. Bewahren Sie eine Kopie von jail.local an einem sicheren Ort auf.
5. Entfernen Sie Adressen aus ignoreip, die nicht mehr gelten.

So bemerken Sie ein Problem an einem ruhigen Tag, nicht mitten im Angriff.

Wann überlassen Sie fail2ban besser Ihrem Hosting Anbieter?

Allerdings muss nicht jeder Inhaber das auf dem eigenen Server einrichten. Der ehrliche Test lautet: Können Sie bei einem Fehler zurückrollen? Wenn nicht, überlassen Sie die Aufgabe dem Anbieter.

• Im Shared Hosting haben Sie keinen root Zugriff, daher können Sie fail2ban nicht installieren. Der Anbieter verwaltet die Sicherheit.
• Buchen Sie einen verwalteten VPS oder Serverservice, fragen Sie zuerst den Anbieter, denn kollidierende Regeln machen Ärger.
• Ohne Konsolen oder Rettungszugang gehen Sie das Risiko der Aussperrung nicht ein.
• Ändern Sie einen kritischen Onlineshop nicht ohne Wartungsfenster.
• Können Sie die echte IP Sichtbarkeit hinter einem CDN nicht klären, gehen Sie nicht weiter.

Die richtige Hosting Wahl nimmt Ihnen den Großteil dieser Last ab. Kriterien finden Sie in unserem Leitfaden zur Webhosting Auswahl. Bei Arbeiten an der Software Ihrer Website unterstützen wir Sie mit individueller Softwareentwicklung und Webdesign. Die Serververwaltung überlassen Sie dennoch besser der passenden Fachkraft. Dieser Ansatz schützt Ihre Sicherheit und Ihre Geschäftskontinuität. Außerdem kostet eine falsche Konfiguration meist mehr als die Wartung.

In welcher Reihenfolge gehen Sie mit fail2ban am besten vor?

Zusammengefasst ist hier eine kurze Roadmap. Setzen Sie jeden Schritt nach dem vorherigen um, einzeln und mit Test.

1. Bestätigen Sie Konsolenzugang und Backup.
2. Richten Sie die SSH Schlüsselanmeldung ein und erwägen Sie, die Passwortanmeldung abzuschalten.
3. Installieren Sie fail2ban und schreiben Sie nur nötige Einstellungen in jail.local.
4. Aktivieren Sie zuerst das Jail sshd und bestätigen Sie mit status, dass es läuft.
5. Schreiben Sie bei Bedarf einen eigenen Filter für Web Logins und testen Sie ihn mit fail2ban-regex.
6. Überprüfen Sie steigende Sperrzeiten und die Liste ignoreip.
7. Lesen Sie /var/log/fail2ban.log regelmäßig.

Merken Sie sich noch etwas: Sicherheit ist kein Projekt, das Sie einmal abschließen. Denn Software bekommt Updates, Angriffsmuster ändern sich, und Teams wachsen. Bewahren Sie die Schritte dieses Leitfadens daher als Checkliste auf und überprüfen Sie sie von Zeit zu Zeit. Sind Sie bei einem Schritt unsicher, halten Sie an, lesen Sie die offizielle Dokumentation oder fragen Sie Ihren Anbieter.

Offizielle Quellen finden Sie im Projekt Repository von fail2ban, in der Datei jail.conf und in der Man Page zu jail.conf. Zur Prüfung Ihrer Domain und DNS Einträge hilft außerdem unser DNS Abfrage Tool.