{"id":70,"date":"2026-06-12T16:21:34","date_gmt":"2026-06-12T16:21:34","guid":{"rendered":"https:\/\/shattered.io\/at\/2026\/06\/12\/fail2ban-einrichten\/"},"modified":"2026-06-12T16:23:04","modified_gmt":"2026-06-12T16:23:04","slug":"fail2ban-einrichten","status":"publish","type":"post","link":"https:\/\/shattered.io\/at\/2026\/06\/12\/fail2ban-einrichten\/","title":{"rendered":"Fail2ban einrichten: SSH-Schutz in 12 Schritten [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Jeder Linux-Server mit einem offenen SSH-Port wird angegriffen, und zwar permanent. Sobald eine \u00f6ffentliche IPv4-Adresse erreichbar ist, beginnen automatisierte Botnetze innerhalb von Minuten, Benutzernamen und Passw\u00f6rter durchzuprobieren. Eine gro\u00dfe SSH-Honeypot-Studie protokollierte insgesamt rund 11 Milliarden Angriffsversuche, davon etwa 7,9 Milliarden reine Brute-Force-Versuche auf Passw\u00f6rter und Schl\u00fcssel. F\u00fcr einen einzelnen, frisch aufgesetzten Root-Server in einem Wiener Rechenzentrum bedeutet das in der Praxis hunderte bis tausende fehlgeschlagene Login-Versuche pro Tag.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Fail2ban<\/strong> ist die seit Jahren etablierte Antwort darauf. Das Open-Source-Werkzeug liest Ihre Logdateien, erkennt Muster fehlgeschlagener Anmeldungen und sperrt die verantwortlichen IP-Adressen automatisch \u00fcber die Firewall. Diese Anleitung f\u00fchrt Sie in 12 Schritten von der Installation bis zur produktionsreifen Konfiguration. Sie brauchen daf\u00fcr rund 30 Minuten, einen Linux-Server und grundlegende Kommandozeilen-Kenntnisse. Am Ende l\u00e4uft auf Ihrem System ein Schutz, der Brute-Force-Angriffe auf SSH, Webserver und Mailserver eigenst\u00e4ndig abwehrt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wir arbeiten mit der aktuellen stabilen Fail2ban-Version 1.1.0 und zeigen die Konfiguration f\u00fcr Debian 12 und Ubuntu 24.04 LTS. Alle Befehle, Konfigurationsdateien und Ausgabebeispiele sind so gehalten, dass Sie sie direkt \u00fcbernehmen k\u00f6nnen. Am Schluss finden Sie ein komplettes, kommentiertes Beispielprojekt zum Kopieren, eine Troubleshooting-Tabelle und einen Vergleich mit den Alternativen CrowdSec und sshguard.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"was-ist-fail2ban-und-wie-funktioniert-der-brute-force-schutz\">Was ist Fail2ban und wie funktioniert der Brute-Force-Schutz?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Fail2ban ist ein in Python geschriebener Hintergrunddienst, der kontinuierlich Logdateien und Systemd-Journale \u00fcberwacht. Es funktioniert nach einem einfachen, aber wirksamen Prinzip: Ein <strong>Filter<\/strong> beschreibt per regul\u00e4rem Ausdruck, wie eine verd\u00e4chtige Zeile aussieht (etwa &#8220;Failed password for root from 203.0.113.5&#8221;). Ein <strong>Jail<\/strong> verkn\u00fcpft diesen Filter mit einer Logquelle und einer Aktion. \u00dcberschreitet eine IP-Adresse innerhalb eines Zeitfensters die erlaubte Anzahl an Fehlversuchen, schreibt Fail2ban eine Sperrregel in die Firewall.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Drei Parameter steuern dieses Verhalten. <strong>maxretry<\/strong> legt fest, wie viele Fehlversuche erlaubt sind. <strong>findtime<\/strong> bestimmt das Beobachtungsfenster, innerhalb dessen diese Versuche gez\u00e4hlt werden. <strong>bantime<\/strong> gibt an, wie lange die Sperre gilt. Ein Beispiel: Bei maxretry 5, findtime 10 Minuten und bantime 1 Stunde wird eine IP gesperrt, sobald sie innerhalb von 10 Minuten f\u00fcnfmal scheitert, und bleibt eine Stunde ausgesperrt. Genau diese Werte sind die Standardvorgaben in der mitgelieferten jail.conf.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der entscheidende Punkt: Fail2ban ersetzt keine starken Passw\u00f6rter und keine SSH-Schl\u00fcssel, sondern reduziert die Angriffsfl\u00e4che und entlastet Ihre Logs. Wer Brute-Force-Angriffe vollst\u00e4ndig ausschlie\u00dfen will, deaktiviert die Passwort-Authentifizierung und nutzt ausschlie\u00dflich Schl\u00fcssel. Fail2ban bleibt trotzdem sinnvoll, weil es Bots fr\u00fchzeitig blockt, Ihre Logdateien sauber h\u00e4lt und auch andere Dienste wie Webserver-Loginformulare sch\u00fctzt. Mehr Hintergrund zu sicheren Passw\u00f6rtern und Hashing lesen Sie in unserem Leitfaden zur <a href=\"\/at\/passwortsicherheit\/\">Passwortsicherheit<\/a>.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Begriff<\/th><th>Bedeutung<\/th><th>Beispiel<\/th><\/tr><\/thead><tbody><tr><td>Filter<\/td><td>Regul\u00e4rer Ausdruck, der eine verd\u00e4chtige Logzeile erkennt<\/td><td>filter.d\/sshd.conf<\/td><\/tr><tr><td>Jail<\/td><td>Verkn\u00fcpfung aus Filter, Logquelle und Aktion<\/td><td>[sshd]<\/td><\/tr><tr><td>Action<\/td><td>Was bei einer Sperre passiert (Firewall, E-Mail)<\/td><td>nftables-multiport<\/td><\/tr><tr><td>maxretry<\/td><td>Erlaubte Fehlversuche vor der Sperre<\/td><td>5<\/td><\/tr><tr><td>findtime<\/td><td>Beobachtungsfenster f\u00fcr die Fehlversuche<\/td><td>10m<\/td><\/tr><tr><td>bantime<\/td><td>Dauer der Sperre<\/td><td>1h<\/td><\/tr><tr><td>recidive<\/td><td>Spezial-Jail f\u00fcr Wiederholungst\u00e4ter<\/td><td>1 Woche<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"voraussetzungen-diese-versionen-und-zugaenge-brauchen-sie\">Voraussetzungen: Diese Versionen und Zug\u00e4nge brauchen Sie<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bevor Sie loslegen, stellen Sie sicher, dass die folgenden Komponenten bereitstehen. Die Anleitung ist auf Debian- und Ubuntu-Systeme zugeschnitten, funktioniert aber mit minimalen Anpassungen auch unter Fedora, Rocky Linux oder Arch Linux. Wichtig ist vor allem, dass Sie Root-Rechte besitzen und einen zweiten Zugang zum Server haben, falls Sie sich versehentlich selbst aussperren.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Komponente<\/th><th>Empfohlene Version<\/th><th>Zweck<\/th><\/tr><\/thead><tbody><tr><td>Linux-Server<\/td><td>Debian 12 oder Ubuntu 24.04 LTS<\/td><td>Zielsystem<\/td><\/tr><tr><td>Fail2ban<\/td><td>1.1.0 (oder Distro-Paket 1.0.2)<\/td><td>Brute-Force-Schutz<\/td><\/tr><tr><td>Python<\/td><td>3.9 oder neuer<\/td><td>Laufzeitumgebung<\/td><\/tr><tr><td>systemd<\/td><td>252+ (Journal als Logquelle)<\/td><td>Log-Backend<\/td><\/tr><tr><td>nftables<\/td><td>1.0+ (Standard ab Debian 12)<\/td><td>Firewall-Backend<\/td><\/tr><tr><td>OpenSSH-Server<\/td><td>9.x<\/td><td>Zu sch\u00fctzender Dienst<\/td><\/tr><tr><td>Root-Zugang<\/td><td>sudo oder root<\/td><td>Installation und Konfiguration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Pr\u00fcfen Sie zuerst, welche Distribution und welcher Kernel laufen. Das stellt sicher, dass die nachfolgenden Pfade und Befehle zu Ihrem System passen.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Distribution und Version anzeigen\ncat \/etc\/os-release | grep PRETTY_NAME\n# Beispielausgabe:\n# PRETTY_NAME=\"Debian GNU\/Linux 12 (bookworm)\"\n\n# Pruefen, ob systemd das Journal bereitstellt\nsystemctl --version | head -n 1\n# systemd 252 (252.30-1~deb12u2)\n\n# Aktiven SSH-Dienst kontrollieren\nsystemctl is-active ssh\n# active<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ein zweiter, paralleler SSH-Zugang ist die wichtigste Versicherung dieser Anleitung. \u00d6ffnen Sie ein zweites Terminalfenster und melden Sie sich erneut am Server an, bevor Sie Sperrregeln aktivieren. So bleiben Sie handlungsf\u00e4hig, falls eine Fehlkonfiguration Ihre eigene IP-Adresse aussperrt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-1-fail2ban-installieren\">Schritt 1: Fail2ban installieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Fail2ban liegt in den Standard-Paketquellen aller gro\u00dfen Distributionen. Unter Debian und Ubuntu installieren Sie es mit einem einzigen apt-Befehl. Aktualisieren Sie zuerst die Paketlisten, damit Sie die neueste verf\u00fcgbare Version erhalten.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Debian \/ Ubuntu\nsudo apt update\nsudo apt install -y fail2ban\n\n# Fedora \/ Rocky \/ AlmaLinux\nsudo dnf install -y fail2ban\n\n# Arch Linux\nsudo pacman -S fail2ban\n\n# Installierte Version pruefen\nfail2ban-client --version\n# Fail2Ban v1.1.0<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die installierte Version h\u00e4ngt von Ihrer Distribution ab. Debian 12 liefert je nach Aktualisierungsstand 1.0.2 oder \u00fcber die Backports 1.1.0 aus, Ubuntu 24.04 ebenfalls die 1.0.2-Reihe. F\u00fcr diese Anleitung spielt der genaue Unterschied keine Rolle, da alle gezeigten Optionen ab Version 0.11 unterst\u00fctzt werden. Wenn Sie unbedingt die allerneueste Version brauchen, finden Sie die offiziellen Releases auf der <a href=\"https:\/\/github.com\/fail2ban\/fail2ban\/releases\" target=\"_blank\" rel=\"noopener\">GitHub-Releaseseite des Projekts<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-2-den-dienst-starten-und-den-status-pruefen\">Schritt 2: Den Dienst starten und den Status pr\u00fcfen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Auf Debian und Ubuntu startet und aktiviert der Paketmanager Fail2ban meist automatisch. Stellen Sie sicher, dass der Dienst l\u00e4uft und beim Systemstart geladen wird. Das Kommando <code>enable --now<\/code> erledigt beides in einem Schritt.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Dienst starten und fuer den Bootvorgang aktivieren\nsudo systemctl enable --now fail2ban\n\n# Laufstatus kontrollieren\nsudo systemctl status fail2ban --no-pager\n# fail2ban.service - Fail2Ban Service\n#      Loaded: loaded (\/lib\/systemd\/system\/fail2ban.service; enabled)\n#      Active: active (running) since Thu 2026-06-11 09:14:02 CEST\n\n# Server-Status ueber den Client abfragen\nsudo fail2ban-client status\n# Status\n# |- Number of jail:      1\n# `- Jail list:           sshd<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Standardm\u00e4\u00dfig ist auf vielen Systemen bereits das sshd-Jail aktiv, weil Debian eine Datei <code>\/etc\/fail2ban\/jail.d\/defaults-debian.conf<\/code> mitliefert. Lassen Sie sich davon nicht verwirren. In den folgenden Schritten \u00fcberschreiben wir diese Vorgaben mit einer sauberen, eigenen Konfiguration, die Sie vollst\u00e4ndig kontrollieren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-3-eine-eigene-jail-local-statt-jail-conf-anlegen\">Schritt 3: Eine eigene jail.local statt jail.conf anlegen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die zentrale Konfigurationsdatei <code>\/etc\/fail2ban\/jail.conf<\/code> wird bei jedem Paket-Update \u00fcberschrieben. Wer hier \u00c4nderungen eintr\u00e4gt, verliert sie beim n\u00e4chsten Upgrade. Die richtige Vorgehensweise ist deshalb eine Datei <code>jail.local<\/code>, die Vorrang vor jail.conf hat und bei Updates unangetastet bleibt. Fail2ban liest beide Dateien und l\u00e4sst die lokalen Einstellungen gewinnen.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Niemals direkt jail.conf bearbeiten. Stattdessen eine eigene Datei anlegen:\nsudo nano \/etc\/fail2ban\/jail.local\n\n# Die Verzeichnisstruktur im Ueberblick:\n# \/etc\/fail2ban\/jail.conf      &lt;- Vorlage, nicht bearbeiten\n# \/etc\/fail2ban\/jail.local     &lt;- Ihre Einstellungen (Vorrang)\n# \/etc\/fail2ban\/jail.d\/        &lt;- Distro-Ergaenzungen\n# \/etc\/fail2ban\/filter.d\/      &lt;- Filter (Regex-Muster)\n# \/etc\/fail2ban\/action.d\/      &lt;- Aktionen (Firewall, Mail)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Diese Trennung zwischen Vorlage und lokaler Konfiguration ist das wichtigste Muster im Umgang mit Fail2ban. Sie gilt nicht nur f\u00fcr Jails, sondern auch f\u00fcr Filter und Aktionen: Eigene Filter legen Sie in <code>filter.d<\/code> mit einem neuen Namen ab, eigene Aktionen analog in <code>action.d<\/code>. Eine vollst\u00e4ndige Referenz aller Parameter findet sich in der <a href=\"https:\/\/manpages.debian.org\/bookworm\/fail2ban\/jail.conf.5.en.html\" target=\"_blank\" rel=\"noopener\">offiziellen jail.conf-Manpage von Debian<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-4-globale-grundeinstellungen-festlegen\">Schritt 4: Globale Grundeinstellungen festlegen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Im Abschnitt <code>[DEFAULT]<\/code> Ihrer jail.local setzen Sie die Werte, die f\u00fcr alle Jails gelten, solange ein Jail sie nicht \u00fcberschreibt. Tragen Sie hier zuerst die Grundparameter und Ihre eigene IP-Adresse als Ausnahme ein. Die <code>ignoreip<\/code>-Liste sch\u00fctzt Sie davor, sich selbst auszusperren, und sollte Ihre Heim- oder B\u00fcro-IP sowie das lokale Netz enthalten.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[DEFAULT]\n# Eigene und vertrauenswuerdige IPs niemals sperren\nignoreip = 127.0.0.1\/8 ::1 192.168.0.0\/16 203.0.113.7\n\n# Sperrdauer: 1 Stunde\nbantime  = 1h\n\n# Beobachtungsfenster: 10 Minuten\nfindtime = 10m\n\n# Erlaubte Fehlversuche\nmaxretry = 5\n\n# Logquelle: systemd-Journal\nbackend  = systemd\n\n# Firewall-Aktion (modernes Debian\/Ubuntu)\nbanaction = nftables-multiport<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ersetzen Sie <code>203.0.113.7<\/code> durch Ihre tats\u00e4chliche \u00f6ffentliche IP-Adresse. Diese ermitteln Sie an Ihrem eigenen Rechner mit <code>curl ifconfig.me<\/code>. Wenn Sie eine dynamische IP von Ihrem \u00f6sterreichischen Provider beziehen, tragen Sie stattdessen das lokale Netz ein und verlassen sich auf einen zweiten Zugangsweg, etwa die KVM-Konsole Ihres Hosters. Setzen Sie <code>ignoreip<\/code> nie zu gro\u00dfz\u00fcgig, denn jede dort gelistete Adresse umgeht den kompletten Schutz.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-5-das-sshd-jail-aktivieren\">Schritt 5: Das sshd-Jail aktivieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Jetzt aktivieren Sie den eigentlichen Schutz f\u00fcr SSH. H\u00e4ngen Sie den folgenden Abschnitt an Ihre jail.local an. Mit <code>enabled = true<\/code> schalten Sie das Jail scharf, <code>port = ssh<\/code> bezieht sich auf den Standardport 22. Falls Sie SSH auf einen anderen Port verlegt haben, tragen Sie hier die konkrete Portnummer ein.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[sshd]\nenabled  = true\nport     = ssh\nfilter   = sshd\nbackend  = systemd\nmaxretry = 4\nfindtime = 10m\nbantime  = 1h<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Werte im Jail \u00fcberschreiben die globalen Vorgaben aus <code>[DEFAULT]<\/code>. Hier setzen wir maxretry bewusst auf 4, weil SSH-Logins selten versehentlich viermal scheitern. Wer einen exponierten Server in einem Rechenzentrum betreibt, kann maxretry sogar auf 3 senken. Achten Sie darauf, dass <code>backend = systemd<\/code> gesetzt ist, wenn Ihr System Logs ausschlie\u00dflich im Journal f\u00fchrt und keine klassische <code>\/var\/log\/auth.log<\/code> mehr schreibt. Das ist bei aktuellen Ubuntu- und Debian-Installationen zunehmend der Fall.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-6-das-richtige-log-backend-waehlen\">Schritt 6: Das richtige Log-Backend w\u00e4hlen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Fail2ban kann seine Informationen aus zwei Quellen beziehen: aus klassischen Logdateien wie <code>\/var\/log\/auth.log<\/code> oder direkt aus dem systemd-Journal. Auf modernen Systemen ist das Journal die zuverl\u00e4ssigere Wahl, weil viele Distributionen das Schreiben in separate Logdateien standardm\u00e4\u00dfig abgeschaltet haben. Steht das Backend falsch, findet Fail2ban keine Eintr\u00e4ge und sperrt niemanden, obwohl der Dienst scheinbar l\u00e4uft.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Pruefen, ob das Journal SSH-Ereignisse enthaelt\njournalctl -u ssh --since \"10 min ago\" | grep -i \"failed password\"\n\n# Falls die klassische Logdatei existiert, ist auch dieses Backend moeglich:\nls -l \/var\/log\/auth.log\n\n# Im Jail dann entweder:\n#   backend = systemd\n# oder, bei vorhandener Datei:\n#   backend = auto\n#   logpath = \/var\/log\/auth.log<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Im Zweifel ist <code>backend = systemd<\/code> die robusteste Einstellung f\u00fcr Debian 12 und Ubuntu 24.04. Sie funktioniert unabh\u00e4ngig davon, ob klassische Logdateien existieren, und kommt mit der Log-Rotation ohne zus\u00e4tzliche Konfiguration zurecht. Genau deshalb haben wir sie schon in Schritt 4 und 5 gesetzt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-7-konfiguration-testen-und-neu-laden\">Schritt 7: Konfiguration testen und neu laden<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bevor Sie die neue Konfiguration aktivieren, pr\u00fcfen Sie sie auf Syntaxfehler. Fail2ban bringt daf\u00fcr einen Testmodus mit, der die Filter gegen Beispieldaten laufen l\u00e4sst, ohne den Dienst zu st\u00f6ren. Erst wenn der Test sauber durchl\u00e4uft, laden Sie die Konfiguration neu.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Gesamte Konfiguration auf Fehler pruefen\nsudo fail2ban-client -t\n# OK: configuration test is successful\n\n# Den sshd-Filter gegen das Journal testen\nsudo fail2ban-regex systemd-journal \/etc\/fail2ban\/filter.d\/sshd.conf\n# Beispielausgabe:\n# Running tests\n# ...\n# Lines: 1430 lines, 0 ignored, 58 matched, 1372 missed\n\n# Konfiguration ohne Neustart neu einlesen\nsudo fail2ban-client reload<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der Befehl <code>fail2ban-client reload<\/code> ist dem harten <code>systemctl restart<\/code> vorzuziehen, weil er bestehende Sperren erh\u00e4lt und keine L\u00fccke \u00f6ffnet. Schl\u00e4gt der Test mit einer Fehlermeldung fehl, korrigieren Sie die genannte Zeile in jail.local und wiederholen Sie den Test. Aktivieren Sie nie eine ungetestete Konfiguration auf einem Produktivsystem, vor allem nicht, wenn Sie nur per SSH Zugang haben.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-8-sperren-pruefen-mit-fail2ban-client\">Schritt 8: Sperren pr\u00fcfen mit fail2ban-client<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Sobald Fail2ban l\u00e4uft, ist <code>fail2ban-client<\/code> Ihr wichtigstes Werkzeug zur \u00dcberwachung. Mit dem Status-Kommando sehen Sie, wie viele IP-Adressen aktuell gesperrt sind und wie viele Fehlversuche insgesamt registriert wurden. Auf einem \u00f6ffentlich erreichbaren Server f\u00fcllt sich diese Liste oft schon nach wenigen Minuten.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Detailstatus des sshd-Jails\nsudo fail2ban-client status sshd\n# Status for the jail: sshd\n# |- Filter\n# |  |- Currently failed: 3\n# |  |- Total failed:     1847\n# |  `- File list:        systemd-journal\n# `- Actions\n#    |- Currently banned: 12\n#    |- Total banned:     143\n#    `- Banned IP list:   45.143.200.18 193.32.162.7 218.92.0.34<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Zeile <code>Total banned<\/code> zeigt eindrucksvoll, wie viel Datenverkehr ein einzelner Server abwehrt. Werte im Hunderter- oder Tausenderbereich pro Woche sind f\u00fcr eine exponierte IP v\u00f6llig normal und kein Grund zur Sorge, sondern der Beweis, dass Fail2ban arbeitet. Wie sich diese Bedrohungslage in \u00d6sterreich entwickelt, ordnen wir in unserer Analyse zur <a href=\"\/at\/cyberkriminalitaet-oesterreich-2026\/\">Cyberkriminalit\u00e4t in \u00d6sterreich<\/a> ein.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-9-ip-adressen-entsperren\">Schritt 9: IP-Adressen entsperren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Fr\u00fcher oder sp\u00e4ter sperrt Fail2ban eine IP, die Sie eigentlich durchlassen wollten, etwa weil ein Kollege sein Passwort zu oft falsch eingegeben hat. Das manuelle Entsperren ist mit einem einzigen Befehl erledigt. Sie k\u00f6nnen eine Adresse aus einem bestimmten Jail oder global aus allen Jails entfernen.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Eine IP aus dem sshd-Jail entsperren\nsudo fail2ban-client set sshd unbanip 203.0.113.42\n\n# Dieselbe IP aus allen Jails entsperren (ab Version 0.11)\nsudo fail2ban-client unban 203.0.113.42\n\n# Alle Sperren eines Jails auf einen Schlag aufheben\nsudo fail2ban-client set sshd unban --all\n\n# Eine IP sofort manuell sperren\nsudo fail2ban-client set sshd banip 198.51.100.23<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Wollen Sie verhindern, dass eine bestimmte Adresse jemals gesperrt wird, geh\u00f6rt sie in die <code>ignoreip<\/code>-Liste aus Schritt 4 und nicht in ein wiederholtes manuelles Entsperren. Der <code>banip<\/code>-Befehl ist n\u00fctzlich, wenn Sie eine bekannte Angreifer-IP aus einem anderen Report sofort blockieren m\u00f6chten, ohne auf die n\u00e4chsten Fehlversuche zu warten.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-10-ban-eskalation-mit-dem-recidive-jail\">Schritt 10: Ban-Eskalation mit dem recidive-Jail<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hartn\u00e4ckige Angreifer kommen nach Ablauf der Sperre einfach wieder. Hier setzt das <code>recidive<\/code>-Jail an: Es \u00fcberwacht das Fail2ban-eigene Log und sperrt IP-Adressen, die bereits mehrfach gesperrt wurden, f\u00fcr eine deutlich l\u00e4ngere Zeit. So eskalieren Sie von einer Stunde auf eine Woche oder l\u00e4nger, ohne legitime Nutzer dauerhaft auszusperren.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[recidive]\nenabled   = true\nlogpath   = \/var\/log\/fail2ban.log\nbanaction = nftables-allports\n# Wer 5 Sperren in 1 Tag kassiert ...\nfindtime  = 1d\nmaxretry  = 5\n# ... wird 1 Woche gesperrt\nbantime   = 1w<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Eine elegante Alternative oder Erg\u00e4nzung ist die automatische Ban-Eskalation \u00fcber <code>bantime.increment<\/code>. Aktiviert verl\u00e4ngert Fail2ban die Sperrdauer bei jedem R\u00fcckfall automatisch, etwa mit dem Faktor 2. Tragen Sie dazu im <code>[DEFAULT]<\/code>-Abschnitt <code>bantime.increment = true<\/code> und <code>bantime.factor = 2<\/code> ein. Beim zweiten Versto\u00df wird aus einer Stunde dann zwei, beim dritten vier und so weiter. Diese Funktion macht das recidive-Jail in vielen F\u00e4llen \u00fcberfl\u00fcssig.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-11-weitere-dienste-wie-nginx-und-postfix-schuetzen\">Schritt 11: Weitere Dienste wie Nginx und Postfix sch\u00fctzen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Fail2ban sch\u00fctzt l\u00e4ngst nicht nur SSH. Jeder Dienst, der Fehlversuche protokolliert, l\u00e4sst sich absichern. Besonders verbreitet sind Jails f\u00fcr Webserver-Logins (etwa HTTP-Basic-Auth hinter Nginx) und f\u00fcr Mailserver wie Postfix oder Dovecot. Die passenden Filter liegen bereits in <code>filter.d<\/code>, Sie m\u00fcssen sie nur \u00fcber ein Jail aktivieren.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Schutz fuer HTTP-Basic-Auth hinter Nginx\n[nginx-http-auth]\nenabled  = true\nport     = http,https\nfilter   = nginx-http-auth\nlogpath  = \/var\/log\/nginx\/error.log\nmaxretry = 5\n\n# Schutz gegen Bot-Anfragen auf nicht existente URLs\n[nginx-botsearch]\nenabled  = true\nport     = http,https\nfilter   = nginx-botsearch\nlogpath  = \/var\/log\/nginx\/access.log\nmaxretry = 2\n\n# Schutz fuer den Postfix-Mailserver\n[postfix]\nenabled  = true\nport     = smtp,submission\nfilter   = postfix\nbackend  = systemd\nmaxretry = 5<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn Sie einen Webserver mit TLS betreiben, geh\u00f6rt der Brute-Force-Schutz zur Grundausstattung, erg\u00e4nzt aber nie eine saubere Verschl\u00fcsselung. Wie HTTPS und TLS technisch funktionieren und warum das Schloss im Browser nur die halbe Miete ist, erkl\u00e4ren wir im Beitrag <a href=\"\/at\/https-und-tls\/\">HTTPS und TLS<\/a>. F\u00fcr jeden neuen Dienst gilt: Erst den passenden Filter mit <code>fail2ban-regex<\/code> gegen echte Logs testen, dann das Jail aktivieren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-12-e-mail-benachrichtigungen-einrichten\">Schritt 12: E-Mail-Benachrichtigungen einrichten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Im letzten Schritt lassen Sie sich bei jeder Sperre per E-Mail informieren. Das ist optional, aber hilfreich, um die Bedrohungslage im Blick zu behalten. Voraussetzung ist ein funktionierender Mail-Versand auf dem Server, etwa \u00fcber <code>msmtp<\/code> oder ein lokales Postfix. Aktivieren Sie dann die Aktion, die Sperre und Benachrichtigung kombiniert.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Im [DEFAULT]-Abschnitt der jail.local ergaenzen:\ndestemail = admin@example.at\nsender    = fail2ban@example.at\nmta       = sendmail\n\n# Aktion: sperren UND eine kurze Info-Mail senden\naction = %(action_mw)s\n\n# Variante mit Logauszug der verdaechtigen Zeilen:\n# action = %(action_mwl)s<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Aktion <code>action_mw<\/code> sendet eine kurze Mail mit Whois-Informationen zur gesperrten IP, <code>action_mwl<\/code> h\u00e4ngt zus\u00e4tzlich die passenden Logzeilen an. \u00dcbertreiben Sie es nicht: Auf stark frequentierten Servern kann das hunderte Mails pro Tag bedeuten. In der Praxis gen\u00fcgt es oft, nur das recidive-Jail mit Mailversand zu konfigurieren, damit Sie ausschlie\u00dflich \u00fcber hartn\u00e4ckige Wiederholungst\u00e4ter informiert werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"haeufige-fehler-und-wie-sie-sie-vermeiden\">H\u00e4ufige Fehler und wie Sie sie vermeiden<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die meisten Probleme mit Fail2ban entstehen nicht durch die Software, sondern durch typische Konfigurationsfehler. Diese f\u00fcnf Stolpersteine sehen wir in der Praxis am h\u00e4ufigsten.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>jail.conf direkt bearbeiten:<\/strong> \u00c4nderungen verschwinden beim n\u00e4chsten Update spurlos. Nutzen Sie immer jail.local. Das ist der mit Abstand h\u00e4ufigste Anf\u00e4ngerfehler.<\/li><li><strong>Falsches Backend:<\/strong> Steht <code>backend = auto<\/code>, findet Fail2ban auf reinen Journal-Systemen ohne <code>\/var\/log\/auth.log<\/code> keine Eintr\u00e4ge und sperrt niemanden. Setzen Sie <code>backend = systemd<\/code>.<\/li><li><strong>Eigene IP vergessen:<\/strong> Ohne Eintrag in <code>ignoreip<\/code> sperren Sie sich bei eigenen Tippfehlern selbst aus. Halten Sie immer einen zweiten Zugang bereit.<\/li><li><strong>Ge\u00e4nderter SSH-Port nicht angepasst:<\/strong> L\u00e4uft SSH auf Port 2222, das Jail aber auf <code>port = ssh<\/code> (22), greift die Sperre ins Leere. Tragen Sie den echten Port ein.<\/li><li><strong>restart statt reload:<\/strong> Ein harter Neustart l\u00f6scht laufende Sperren und \u00f6ffnet kurz ein Fenster. Verwenden Sie <code>fail2ban-client reload<\/code>.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Ein sechster, oft \u00fcbersehener Fehler betrifft NAT und Reverse-Proxys. Steht ein Cloudflare- oder Nginx-Proxy vor Ihrem Server, sieht Fail2ban nur die IP des Proxys und sperrt im schlimmsten Fall den Proxy selbst. In diesem Fall m\u00fcssen Sie die echte Client-IP aus den Headern (etwa <code>X-Forwarded-For<\/code>) auswerten und den Proxy in <code>ignoreip<\/code> aufnehmen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"troubleshooting-die-haeufigsten-probleme-loesen\">Troubleshooting: Die h\u00e4ufigsten Probleme l\u00f6sen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn Fail2ban nicht wie erwartet arbeitet, liegt die Ursache fast immer in einer der folgenden Kategorien. Diese Tabelle fasst die acht h\u00e4ufigsten Symptome mit ihrer jeweiligen L\u00f6sung zusammen.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Symptom<\/th><th>Wahrscheinliche Ursache<\/th><th>L\u00f6sung<\/th><\/tr><\/thead><tbody><tr><td>Niemand wird gesperrt<\/td><td>Falsches Backend oder falscher logpath<\/td><td><code>backend = systemd<\/code> setzen, Journal mit <code>journalctl -u ssh<\/code> pr\u00fcfen<\/td><\/tr><tr><td>Dienst startet nicht<\/td><td>Syntaxfehler in jail.local<\/td><td><code>fail2ban-client -t<\/code> ausf\u00fchren und genannte Zeile korrigieren<\/td><\/tr><tr><td>Eigene IP gesperrt<\/td><td>ignoreip unvollst\u00e4ndig<\/td><td>\u00dcber KVM-Konsole entsperren, IP in ignoreip eintragen<\/td><\/tr><tr><td>Filter findet nichts<\/td><td>Logformat passt nicht zum Regex<\/td><td>Mit <code>fail2ban-regex<\/code> gegen echte Logs testen<\/td><\/tr><tr><td>Sperre wirkt nicht<\/td><td>nftables\/iptables-Backend passt nicht<\/td><td>banaction auf vorhandene Firewall abstimmen<\/td><\/tr><tr><td>Sperren verschwinden<\/td><td>restart statt reload genutzt<\/td><td>Immer <code>fail2ban-client reload<\/code> verwenden<\/td><\/tr><tr><td>IPv6 wird nicht gesperrt<\/td><td>allowipv6 deaktiviert<\/td><td><code>allowipv6 = auto<\/code> in fail2ban.local setzen<\/td><\/tr><tr><td>Hohe CPU-Last<\/td><td>Zu viele aktive Jails auf gro\u00dfen Logs<\/td><td>Journal-Backend nutzen, Jails reduzieren<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr die Fehlersuche ist das Fail2ban-eigene Logfile die erste Anlaufstelle. Es protokolliert jeden Start, jede Sperre und jeden Fehler im Detail.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Live in das Fail2ban-Log schauen\nsudo tail -f \/var\/log\/fail2ban.log\n\n# Oder, auf reinen Journal-Systemen:\nsudo journalctl -u fail2ban -f\n\n# Typische erfolgreiche Sperrzeile:\n# NOTICE  [sshd] Ban 45.143.200.18\n\n# Den Debug-Loglevel temporaer erhoehen:\nsudo fail2ban-client set loglevel DEBUG<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fortgeschrittene-tipps-fuer-den-produktiven-einsatz\">Fortgeschrittene Tipps f\u00fcr den produktiven Einsatz<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"nftables-statt-iptables-nutzen\">nftables statt iptables nutzen<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Auf Debian 12 und Ubuntu 24.04 ist nftables die Standard-Firewall. Setzen Sie deshalb <code>banaction = nftables-multiport<\/code> statt der \u00e4lteren iptables-Variante. Fail2ban legt dann eine eigene nftables-Tabelle an und verwaltet die Sperren sauber getrennt von Ihren \u00fcbrigen Regeln. Mischen Sie iptables- und nftables-Aktionen nicht, sonst k\u00f6nnen sich Sperren widersprechen oder ins Leere laufen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ipv6-nicht-vergessen\">IPv6 nicht vergessen<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Fail2ban unterst\u00fctzt IPv6 seit Version 0.10 vollst\u00e4ndig. Trotzdem ist der Schutz nur dann wirksam, wenn Ihre Firewall-Aktion auch IPv6 abdeckt. Auf einem Dual-Stack-Server in \u00d6sterreich mit IPv6-Anbindung greifen Angreifer zunehmend \u00fcber IPv6 an. Setzen Sie <code>allowipv6 = auto<\/code> in <code>\/etc\/fail2ban\/fail2ban.local<\/code> und kontrollieren Sie mit <code>fail2ban-client status sshd<\/code>, ob auch IPv6-Adressen in der Sperrliste auftauchen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ssh-zusaetzlich-haerten\">SSH zus\u00e4tzlich h\u00e4rten<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Fail2ban ist eine Erg\u00e4nzung, kein Ersatz f\u00fcr eine geh\u00e4rtete SSH-Konfiguration. Die wirksamste Ma\u00dfnahme bleibt das Abschalten der Passwort-Authentifizierung zugunsten von SSH-Schl\u00fcsseln. Tragen Sie in <code>\/etc\/ssh\/sshd_config<\/code> die Werte <code>PasswordAuthentication no<\/code> und <code>PermitRootLogin prohibit-password<\/code> ein. Kombinieren Sie das mit einem verschl\u00fcsselten Schl\u00fcsselspeicher, etwa \u00fcber <a href=\"\/at\/keepassxc-einrichten\/\">KeePassXC<\/a>, und mit einem VPN-Zugang wie in unserer Anleitung zu <a href=\"\/at\/wireguard-einrichten\/\">WireGuard<\/a> beschrieben. Brute-Force-Angriffe laufen dann komplett ins Leere, weil ohne g\u00fcltigen Schl\u00fcssel gar kein Login m\u00f6glich ist.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sicherheit-cve-2025-45311-und-updates-ernst-nehmen\">Sicherheit: CVE-2025-45311 und Updates ernst nehmen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Auch ein Sicherheitswerkzeug kann selbst eine Schwachstelle enthalten. Ende 2025 wurde <strong>CVE-2025-45311<\/strong> ver\u00f6ffentlicht, eine Sicherheitsl\u00fccke in <code>fail2ban-client<\/code> der Version 0.11.2. Unsichere Berechtigungen konnten es einem Nutzer mit eingeschr\u00e4nkten sudo-Rechten erm\u00f6glichen, beliebige Operationen mit Root-Rechten auszuf\u00fchren. Die Details dokumentiert der offizielle <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2025-45311\" target=\"_blank\" rel=\"noopener\">CVE-Eintrag<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die praktische Konsequenz ist einfach: Halten Sie Fail2ban aktuell und vergeben Sie sudo-Rechte f\u00fcr <code>fail2ban-client<\/code> nur sehr restriktiv. Auf einem gepflegten Debian- oder Ubuntu-System erhalten Sie Sicherheitsupdates automatisch \u00fcber die Distributionsquellen. Aktivieren Sie unbeaufsichtigte Sicherheitsupdates mit <code>unattended-upgrades<\/code>, dann landen auch Fail2ban-Patches zeitnah auf Ihrem System.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Automatische Sicherheitsupdates aktivieren (Debian\/Ubuntu)\nsudo apt install -y unattended-upgrades\nsudo dpkg-reconfigure -plow unattended-upgrades\n\n# Installierte Fail2ban-Version und Sicherheitsstand pruefen\napt list --installed 2>\/dev\/null | grep fail2ban\nfail2ban-client --version<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fail2ban-vs-crowdsec-vs-sshguard-im-vergleich\">Fail2ban vs. CrowdSec vs. sshguard im Vergleich<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Fail2ban ist nicht das einzige Werkzeug seiner Art. Zwei prominente Alternativen sind CrowdSec, das auf eine gemeinschaftliche Bedrohungsdatenbank setzt, und sshguard, ein besonders schlankes, in C geschriebenes Pendant. Welches Werkzeug passt, h\u00e4ngt von Ihren Anforderungen ab.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Merkmal<\/th><th>Fail2ban<\/th><th>CrowdSec<\/th><th>sshguard<\/th><\/tr><\/thead><tbody><tr><td>Sprache<\/td><td>Python<\/td><td>Go<\/td><td>C<\/td><\/tr><tr><td>Ressourcenbedarf<\/td><td>Mittel<\/td><td>H\u00f6her<\/td><td>Sehr gering<\/td><\/tr><tr><td>Gemeinschafts-Blocklist<\/td><td>Nein<\/td><td>Ja<\/td><td>Nein<\/td><\/tr><tr><td>Gesch\u00fctzte Dienste<\/td><td>Sehr viele (Filter)<\/td><td>Viele (Szenarien)<\/td><td>Vor allem SSH<\/td><\/tr><tr><td>Konfiguration<\/td><td>Logdateien, Jails<\/td><td>YAML, zentral<\/td><td>Minimal<\/td><\/tr><tr><td>Reife<\/td><td>Sehr hoch, etabliert<\/td><td>Modern, wachsend<\/td><td>Hoch, schlank<\/td><\/tr><tr><td>Ideal f\u00fcr<\/td><td>Klassische Einzelserver<\/td><td>Flotten, zentrale Sicht<\/td><td>Minimalsysteme<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr den klassischen Anwendungsfall, einen oder wenige Linux-Server selbst abzusichern, bleibt Fail2ban die beste Wahl: ausgereift, breit dokumentiert und mit Filtern f\u00fcr praktisch jeden Dienst. CrowdSec spielt seine St\u00e4rken aus, sobald Sie viele Server zentral verwalten und von einer geteilten Blocklist profitieren wollen. sshguard ist die richtige Wahl, wenn jedes Megabyte RAM z\u00e4hlt und Sie ausschlie\u00dflich SSH absichern. Eine ausf\u00fchrliche Projekt\u00fcbersicht zu Fail2ban finden Sie auf der <a href=\"https:\/\/www.fail2ban.org\/wiki\/index.php\/Main_Page\" target=\"_blank\" rel=\"noopener\">offiziellen Projektseite<\/a> und im <a href=\"https:\/\/github.com\/fail2ban\/fail2ban\" target=\"_blank\" rel=\"noopener\">GitHub-Repository<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"komplettes-beispielprojekt-eine-produktionsreife-jail-local\">Komplettes Beispielprojekt: Eine produktionsreife jail.local<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Zum Abschluss f\u00fcgen wir alle Schritte zu einer vollst\u00e4ndigen, kommentierten Konfiguration zusammen. Diese jail.local sch\u00fctzt SSH, einen Nginx-Webserver und eskaliert hartn\u00e4ckige Angreifer \u00fcber das recidive-Jail. Kopieren Sie sie nach <code>\/etc\/fail2ban\/jail.local<\/code>, passen Sie IP-Adresse und E-Mail an und laden Sie Fail2ban neu.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[DEFAULT]\n# --- Vertrauenswuerdige Adressen niemals sperren ---\nignoreip = 127.0.0.1\/8 ::1 192.168.0.0\/16 203.0.113.7\n\n# --- Globale Schwellenwerte ---\nbantime  = 1h\nfindtime = 10m\nmaxretry = 5\n\n# --- Progressive Eskalation bei Rueckfall ---\nbantime.increment = true\nbantime.factor    = 2\nbantime.maxtime   = 1w\n\n# --- Log- und Firewall-Backend (Debian 12 \/ Ubuntu 24.04) ---\nbackend   = systemd\nbanaction = nftables-multiport\n\n# --- Benachrichtigung ---\ndestemail = admin@example.at\nsender    = fail2ban@example.at\nmta       = sendmail\naction    = %(action_mw)s\n\n[sshd]\nenabled  = true\nport     = ssh\nfilter   = sshd\nmaxretry = 4\nbantime  = 2h\n\n[nginx-http-auth]\nenabled  = true\nport     = http,https\nfilter   = nginx-http-auth\nlogpath  = \/var\/log\/nginx\/error.log\nmaxretry = 5\n\n[recidive]\nenabled   = true\nlogpath   = \/var\/log\/fail2ban.log\nbanaction = nftables-allports\nfindtime  = 1d\nmaxretry  = 5\nbantime   = 1w<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code># Konfiguration testen, neu laden und pruefen\nsudo fail2ban-client -t\nsudo fail2ban-client reload\nsudo fail2ban-client status\n\n# Erwartete Ausgabe:\n# Status\n# |- Number of jail:      3\n# `- Jail list:           nginx-http-auth, recidive, sshd<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Mit dieser Konfiguration l\u00e4uft auf Ihrem Server ein mehrstufiger Brute-Force-Schutz: SSH-Angreifer werden nach vier Fehlversuchen f\u00fcr zwei Stunden gesperrt, Nginx-Login-Angriffe nach f\u00fcnf, und wer wiederholt auff\u00e4llt, kassiert \u00fcber das recidive-Jail eine Wochensperre. Die progressive Eskalation verl\u00e4ngert jede weitere Sperre automatisch. Damit ist die Grundabsicherung gegen automatisierte Angriffe abgeschlossen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fail2ban-in-docker-und-container-umgebungen\">Fail2ban in Docker- und Container-Umgebungen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Immer mehr Dienste laufen in Containern, und das ver\u00e4ndert die Logik von Fail2ban. Ein im Container laufender Webserver schreibt seine Logs in den Container, nicht auf den Host. Fail2ban geh\u00f6rt in dieser Architektur fast immer auf den <strong>Host<\/strong>, nicht in den Container, weil nur der Host die Firewall-Regeln \u00fcber nftables setzen kann. Der Container stellt seine Logs bereit, der Host wertet sie aus und sperrt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die saubere L\u00f6sung f\u00fchrt die Container-Logs in das systemd-Journal des Hosts. Docker bietet daf\u00fcr den Logging-Treiber <code>journald<\/code>, der die Ausgaben jedes Containers direkt ins Journal schreibt. Fail2ban liest dann wie gewohnt \u00fcber <code>backend = systemd<\/code> mit. Achten Sie darauf, dass Docker eigene iptables- beziehungsweise nftables-Ketten anlegt: Sperren m\u00fcssen vor den Docker-Regeln greifen, sonst leitet Docker den Verkehr trotzdem an den Container weiter.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Container-Logs in das Host-Journal schreiben\ndocker run --log-driver=journald --name web nginx\n\n# Auf dem Host pruefen, ob die Logs ankommen\njournalctl CONTAINER_NAME=web --since \"5 min ago\"\n\n# Jail auf dem Host, das die Container-Logs auswertet\n[nginx-docker]\nenabled  = true\nbackend  = systemd\nfilter   = nginx-http-auth\njournalmatch = CONTAINER_NAME=web\nmaxretry = 5<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Wer einen vollst\u00e4ndig containerisierten Stack betreibt, sollte zus\u00e4tzlich pr\u00fcfen, ob nicht ein vorgelagerter Reverse-Proxy ohnehin alle echten Client-IPs maskiert. In dem Fall f\u00fchrt kein Weg an der Auswertung des <code>X-Forwarded-For<\/code>-Headers vorbei, wie schon im Abschnitt zu den h\u00e4ufigen Fehlern beschrieben. Halten Sie die Zahl der Jails auf containerisierten Hosts bewusst niedrig, denn jede zus\u00e4tzliche Journal-Abfrage kostet Ressourcen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sperren-langfristig-auswerten-und-ueberwachen\">Sperren langfristig auswerten und \u00fcberwachen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein produktiver Server liefert \u00fcber die Zeit ein aussagekr\u00e4ftiges Bild der Angriffslage. Fail2ban bringt mit <code>fail2ban-client<\/code> bereits eine einfache Statistik mit, doch f\u00fcr die langfristige Auswertung lohnt sich ein Blick in das Logfile. So erkennen Sie, aus welchen Netzen die meisten Angriffe kommen und ob bestimmte Dienste besonders im Visier stehen.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Die zehn am haeufigsten gesperrten IPs ermitteln\nsudo zgrep -h \"Ban\" \/var\/log\/fail2ban.log* \\\n  | grep -oE \"[0-9]+\\.[0-9]+\\.[0-9]+\\.[0-9]+\" \\\n  | sort | uniq -c | sort -rn | head -10\n\n# Anzahl aller Sperren pro Tag\nsudo grep \"Ban\" \/var\/log\/fail2ban.log \\\n  | awk '{print $1}' | sort | uniq -c<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Diese einfachen Auswertungen gen\u00fcgen f\u00fcr den Hausgebrauch. Wer mehrere Server betreibt, exportiert die Daten besser an ein zentrales System. Es gibt Prometheus-Exporter, die die Fail2ban-Statistiken als Metriken bereitstellen, sodass Sie Sperren in einem Grafana-Dashboard visualisieren k\u00f6nnen. F\u00fcr den Einstieg reicht jedoch die regelm\u00e4\u00dfige Kontrolle per <code>fail2ban-client status<\/code> v\u00f6llig aus. Behalten Sie vor allem das recidive-Jail im Auge: Taucht dort dieselbe IP immer wieder auf, lohnt sich eine dauerhafte Sperre auf Firewall-Ebene.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Fail2ban ist damit ein wichtiger Baustein, aber eben nur einer. Eine wirksame Absicherung kombiniert den reaktiven Brute-Force-Schutz mit pr\u00e4ventiven Ma\u00dfnahmen: starken Zugangsdaten, Schl\u00fcssel-Authentifizierung, einer restriktiven Firewall und regelm\u00e4\u00dfigen Updates. Wie diese Bausteine zusammenspielen, ordnet unser \u00dcberblick zur <a href=\"\/at\/security-hub\/\">Online-Sicherheit<\/a> ein.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"haeufige-fragen-zu-fail2ban\">H\u00e4ufige Fragen zu Fail2ban<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ersetzt-fail2ban-eine-firewall\">Ersetzt Fail2ban eine Firewall?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Nein. Fail2ban steuert die Firewall, ist aber selbst keine. Es schreibt dynamische Sperrregeln in nftables oder iptables, setzt also eine funktionierende Firewall voraus. Betreiben Sie weiterhin eine Basis-Firewall, die nur ben\u00f6tigte Ports \u00f6ffnet, und nutzen Sie Fail2ban als zus\u00e4tzliche, reaktive Schicht dar\u00fcber.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"verlangsamt-fail2ban-meinen-server\">Verlangsamt Fail2ban meinen Server?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Im Normalbetrieb ist die Last vernachl\u00e4ssigbar. Fail2ban liest Logzeilen und gleicht sie mit regul\u00e4ren Ausdr\u00fccken ab. Erst bei dutzenden aktiven Jails auf sehr gro\u00dfen Logdateien kann die CPU-Last steigen. Das systemd-Journal als Backend ist hier effizienter als das Einlesen riesiger Textdateien.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wie-sehe-ich-welche-ips-aktuell-gesperrt-sind\">Wie sehe ich, welche IPs aktuell gesperrt sind?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Mit <code>sudo fail2ban-client status sshd<\/code> sehen Sie die komplette Liste der aktuell gesperrten Adressen f\u00fcr ein Jail, inklusive der Gesamtzahl aller jemals registrierten Fehlversuche und Sperren.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"funktioniert-fail2ban-mit-ipv6\">Funktioniert Fail2ban mit IPv6?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja, seit Version 0.10. Wichtig ist, dass die gew\u00e4hlte banaction IPv6 abdeckt und <code>allowipv6 = auto<\/code> gesetzt ist. Auf Dual-Stack-Servern sollten Sie unbedingt pr\u00fcfen, ob auch IPv6-Adressen in der Sperrliste erscheinen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ich-habe-mich-selbst-ausgesperrt-was-tun\">Ich habe mich selbst ausgesperrt. Was tun?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Verbinden Sie sich \u00fcber die KVM- oder Webkonsole Ihres Hosters mit dem Server und f\u00fchren Sie <code>sudo fail2ban-client unban IHRE-IP<\/code> aus. Tragen Sie Ihre Adresse danach in <code>ignoreip<\/code> ein, damit sich der Fehler nicht wiederholt. Genau daf\u00fcr sollten Sie immer einen zweiten Zugangsweg bereithalten.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"brauche-ich-fail2ban-wenn-ich-nur-ssh-schluessel-nutze\">Brauche ich Fail2ban, wenn ich nur SSH-Schl\u00fcssel nutze?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Streng genommen verhindert die reine Schl\u00fcssel-Authentifizierung Brute-Force-Logins bereits vollst\u00e4ndig. Fail2ban bleibt trotzdem n\u00fctzlich, weil es Bots fr\u00fchzeitig blockt, Ihre Logs sauber h\u00e4lt und andere Dienste wie Webserver oder Mailserver sch\u00fctzt, bei denen Passw\u00f6rter im Spiel sind.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wie-unterscheidet-sich-bantime-increment-vom-recidive-jail\">Wie unterscheidet sich bantime.increment vom recidive-Jail?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>bantime.increment<\/code> verl\u00e4ngert die Sperrdauer derselben IP bei jedem R\u00fcckfall automatisch. Das recidive-Jail \u00fcberwacht dagegen das Fail2ban-Log und sperrt IPs, die in mehreren Jails oder mehrfach auff\u00e4llig wurden, geb\u00fcndelt f\u00fcr eine lange Zeit. Beide lassen sich kombinieren, in der Praxis gen\u00fcgt oft schon die Eskalation \u00fcber bantime.increment.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"auf-welchen-distributionen-laeuft-fail2ban\">Auf welchen Distributionen l\u00e4uft Fail2ban?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Auf praktisch allen. Debian, Ubuntu, Fedora, Rocky Linux, AlmaLinux und Arch Linux liefern Fail2ban in ihren Paketquellen. Die Konfiguration ist identisch, lediglich Installationsbefehl und einzelne Logpfade unterscheiden sich. Diese Anleitung verwendet Debian 12 und Ubuntu 24.04 LTS als Referenz.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"related-coverage\">Related Coverage<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/at\/wireguard-einrichten\/\">WireGuard einrichten: VPN-Server in 12 Schritten<\/a><\/li><li><a href=\"\/at\/keepassxc-einrichten\/\">KeePassXC einrichten: Passwort-Tresor in 12 Schritten<\/a><\/li><li><a href=\"\/at\/passwortsicherheit\/\">Passwortsicherheit: starke Passw\u00f6rter, Hashing und 2FA<\/a><\/li><li><a href=\"\/at\/https-und-tls\/\">HTTPS und TLS: Wie das Schloss im Browser Sie sch\u00fctzt<\/a><\/li><li><a href=\"\/at\/cyberkriminalitaet-oesterreich-2026\/\">Cyberkriminalit\u00e4t \u00d6sterreich: Die Lage 2026<\/a><\/li><li><a href=\"\/at\/security-hub\/\">Online-Sicherheit verst\u00e4ndlich erkl\u00e4rt<\/a><\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Stand: Juni 2026. Die gezeigten Befehle und Konfigurationen wurden f\u00fcr Debian 12 und Ubuntu 24.04 LTS mit Fail2ban 1.1.0 als Referenz beschrieben. Pr\u00fcfen Sie Versionsnummern und Pfade immer gegen Ihr konkretes System.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Jeder Linux-Server mit einem offenen SSH-Port wird angegriffen, und zwar permanent. Sobald eine \u00f6ffentliche IPv4-Adresse erreichbar ist, beginnen automatisierte Botnetze innerhalb von Minuten, Benutzernamen und Passw\u00f6rter durchzuprobieren. Eine gro\u00dfe SSH-Honeypot-Studie\u2026<\/p>\n","protected":false},"author":9,"featured_media":71,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-70","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/posts\/70","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/comments?post=70"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/posts\/70\/revisions"}],"predecessor-version":[{"id":72,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/posts\/70\/revisions\/72"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/media\/71"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/media?parent=70"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/categories?post=70"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/tags?post=70"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}