SSH-Angriffe mit Fail2ban automatisch blockieren: Ubuntu-Server sicher konfigurieren¶
Veröffentlicht am 2. November 2026 · Geschätzte Lesezeit: 7 Minuten
Fail2ban überwacht fehlgeschlagene SSH-Anmeldungen und lässt eine Firewall Quelladressen nach mehreren Fehlversuchen zeitweise sperren. So ergänzt du einen bereits mit SSH-Schlüsseln und Firewall abgesicherten Ubuntu-Server um eine zusätzliche Schutzschicht. Plane etwa 20 bis 30 Minuten ein; ein echter Sperrtest von einer zweiten IP-Adresse braucht zusätzliche Zeit. Die Einrichtung wurde mit der offiziellen Fail2ban-Konfiguration und Ubuntu-Manpage sowie einem aktuellen Praxisleitfaden abgeglichen.[1][2][4]
Voraussetzungen
- Ein Ubuntu-Server mit Internetzugang und einem Benutzerkonto mit
sudo-Rechten - Ein funktionierender SSH-Zugang, vorzugsweise bereits ausschließlich mit Schlüsseln
- Eine zweite offene SSH-Sitzung und bei einem VPS getesteter Zugriff auf die Anbieter-Konsole
- Eine aktive Firewall, deren Technik mit der von Fail2ban verwendeten Sperraktion zusammenarbeitet
1. SSH-Port und Zugang prüfen¶
Lass dir zunächst den tatsächlich wirksamen SSH-Port anzeigen. Verwende den ausgegebenen Wert später anstelle von <SSH-PORT>; nimm nicht automatisch Port 22 an.
Öffne danach eine zweite SSH-Verbindung und prüfe, dass du darin sudo verwenden kannst. Lass beide Sitzungen offen, bis Fail2ban eingerichtet und geprüft ist. Bei einem Server im Internet solltest du außerdem sicherstellen, dass du die Anbieter-Konsole tatsächlich öffnen kannst.
2. Paket installieren und vorhandene Konfiguration sichern¶
Aktualisiere den Paketindex und installiere Fail2ban aus den konfigurierten Ubuntu-Paketquellen:
Sichere anschließend die Paketkonfiguration in ein datiertes Archiv unter /root. Der Befehl verändert die Konfiguration nicht; er bewahrt den Zustand vor deiner lokalen Anpassung.
Die Ausgabe verrät den erzeugten Dateinamen. Notiere ihn für den Rückweg. Falls /etc/fail2ban nicht existiert oder der Paketmanager einen Fehler meldet, halte hier an und behebe zuerst die Installation.
3. Updatefeste SSH-Regel anlegen¶
Fail2ban liefert allgemeine Vorgaben in .conf-Dateien aus. Überschreibe sie nicht direkt: eigene Anpassungen gehören in lokale Dateien, die Paketupdates nicht ersetzen sollen.[1][2]
Erstelle ein kleines lokales Jail für den SSH-Dienst:
sudo tee /etc/fail2ban/jail.d/sshd.local >/dev/null <<'EOF'
[sshd]
enabled = true
port = <SSH-PORT>
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
EOF
Ersetze vor dem Ausführen <SSH-PORT> durch die Zahl aus Schritt 1, zum Beispiel 22 oder 2222. Die Werte bedeuten: Nach fünf Fehlversuchen innerhalb von zehn Minuten wird die erkannte Adresse eine Stunde gesperrt. Das sind vorsichtige Startwerte, keine universell optimalen Einstellungen. Das Jail verbindet einen Filter, eine Protokollquelle und eine Sperraktion.[1][2]
Mit backend = systemd liest Fail2ban SSH-Ereignisse aus dem systemd-Journal. Setze dazu keinen logpath: beim systemd-Backend wird das Journal statt einer Logdatei verwendet.[3]
Firewall-Aktion vorher berücksichtigen
Fail2ban sperrt über eine Firewall-Aktion. Systeme mit UFW, nftables, Docker oder mehreren Firewall-Werkzeugen können unterschiedliche Regeln verwalten. Prüfe die vorhandene Firewall und die installierten Fail2ban-Vorgaben, statt zusätzlich eigene Regeln oder eine ungeprüfte banaction einzutragen. Eine Sperre kann auch legitime Admin-Verbindungen treffen.
4. Konfiguration prüfen, bevor der Dienst startet¶
Lass Fail2ban die Konfiguration zunächst nur auf Syntaxfehler prüfen:
Fahre nur fort, wenn der Test erfolgreich endet. Bei einem Fehler kontrolliere insbesondere, ob der Port-Platzhalter ersetzt wurde und ob du beim systemd-Backend versehentlich logpath ergänzt hast. Weitere Konfigurationsoptionen beschreibt die Ubuntu-Manpage.[2]
5. Dienst starten und SSH-Jail kontrollieren¶
Aktiviere den Dienst für den Systemstart und starte ihn jetzt:
Prüfe den Dienststatus und die geladenen Jails:
Die erste Abfrage sollte active ausgeben; in der Jail-Liste sollte sshd erscheinen. Prüfe anschließend den Status des SSH-Jails:
Am Anfang können die Zähler für fehlgeschlagene und gesperrte Adressen auf null stehen. Das ist normal, solange keine passenden Ereignisse eingegangen sind. Die Statusabfrage zeigt außerdem das aktuell geladene Jail und seine Zähler.[1][2]
6. Journal und Fehlerprotokoll prüfen¶
Wenn das Jail geladen ist, aber keine Ereignisse erkennt, prüfe zuerst, ob SSH-Anmeldungen im Journal erscheinen:
Der genaue Unit-Name kann je nach System abweichen. Falls ssh keine passenden Einträge zeigt, ermittle vorhandene SSH-Units, statt blind einen Logpfad einzutragen:
Fehler des Fail2ban-Dienstes findest du im Journal:
7. Optional eine feste Admin-Adresse ausnehmen¶
Eine feste und vertrauenswürdige Verwaltungsadresse kann mit ignoreip von Sperren ausgenommen werden. Nutze das nur, wenn die Quelladresse wirklich stabil und ausschließlich dir zugeordnet ist. Lass die Einstellung weg, wenn du eine wechselnde Heim-IP, ein gemeinsam genutztes VPN oder ein ganzes Netz nicht sicher einschätzen kannst.
Öffne die lokale Datei:
Ergänze innerhalb des Abschnitts [sshd] eine Zeile. Ersetze <STATISCHE-ADMIN-IP> durch genau deine feste öffentliche IPv4-Adresse; /32 bezeichnet eine einzelne IPv4-Adresse. Für IPv6 gelten andere Netzmasken.
Speichere die Datei, führe erneut sudo fail2ban-client -t aus und starte Fail2ban erst nach erfolgreicher Prüfung neu:
8. Sperre kontrolliert testen und wieder aufheben¶
Ein echter Sperrtest sollte ausschließlich von einer kontrollierten zweiten öffentlichen IP-Adresse erfolgen – niemals von deiner einzigen Admin-Verbindung. Wiederholte Fehlanmeldungen können dich aussperren und fremde Systeme dürfen nicht getestet werden. Für eine produktive Maschine ist es sicherer, den Test auszulassen und zunächst nur Syntax, Dienst und Jail-Status zu prüfen.
Wenn du einen kontrollierten Test durchführst, stelle von der Test-IP einige absichtlich falsche SSH-Anmeldungen her, während die separate Admin-Sitzung geöffnet bleibt. Kontrolliere danach den Jail-Status:
Ersetze <TEST-IP> durch die tatsächliche Adresse des eigenen Testrechners und entferne eine Test-Sperre anschließend sofort:
Verifiziere nochmals mit sudo fail2ban-client status sshd, dass die Testadresse nicht mehr in der Liste der gesperrten Adressen steht. Wenn du nicht sicher bist, welche öffentliche Adresse dein Testrechner verwendet, rate sie nicht – überspringe den Sperrtest.
Backup und Rückweg¶
Halte die zweite SSH-Sitzung offen. Um die lokale Regel zu deaktivieren, benenne sie um und starte Fail2ban neu:
sudo mv /etc/fail2ban/jail.d/sshd.local /etc/fail2ban/jail.d/sshd.local.disabled
sudo systemctl restart fail2ban
Wenn der Dienst weiterhin Probleme macht, stoppe und deaktiviere Fail2ban vorübergehend:
Ersetze den Platzhalter <BACKUP-DATEI> durch den vollständigen Archivnamen, den Schritt 2 beim Sichern ausgegeben hat. Das Archiv enthält die Dateien unter /etc/fail2ban; ein Entpacken stellt sie an diesen Ort zurück. Die folgende Eingabeaufforderung speichert den Pfad in BACKUP, damit du ihn nicht in einem Befehl mit Sonderzeichen ersetzen musst.
Wenn du den Rückweg über eine SSH-Verbindung nicht mehr erreichst, nutze die Provider-Konsole oder den physischen Konsolenzugang. Entferne dort die lokale Datei, prüfe die Konfiguration mit sudo fail2ban-client -t und starte den Dienst erst danach erneut.
Nicht ohne Rückweg testen
Verwende keinen Test von deiner einzigen Admin-IP und sperre keine unbekannte Adresse aus einer Statusliste aus. Eine Fehlkonfiguration oder eine zu großzügige Sperrregel kann legitime Verbindungen blockieren.
Risiken und typische Fehler¶
- Jail
sshdfehlt: Prüfe Dateipfad, Abschnitt[sshd], Dateiendung und Ausgabe vonsudo fail2ban-client -t. - Syntaxfehler beim Start: Lies
sudo journalctl -u fail2ban --since "15 minutes ago" --no-pager; ändere nicht die paketgeliefertejail.confdirekt.[1][2] - Keine Ereignisse sichtbar: Kontrolliere den tatsächlichen SSH-Unit-Namen und ob Fehlanmeldungen im Journal ankommen.
backend = systemdbenötigt keinenlogpath.[1][2] - Eigener Port wird ignoriert: Ersetze
<SSH-PORT>durch den tatsächlich aktiven Port aussshd -T. - Keine gesperrten Adressen: Ohne passende fehlgeschlagene Anmeldungen ist eine leere Sperrliste normal.
- Firewall-Regel greift anders als erwartet: Prüfe, welches Werkzeug die aktive Firewall verwaltet und ob die geladene Fail2ban-Sperraktion dazu passt. Vermeide parallele, ungeprüfte Regelwerke.
- Admin-IP versehentlich gesperrt: Nutze die zweite Sitzung oder Konsole und entsperre ausschließlich deine bekannte Test-IP mit
fail2ban-client set sshd unbanip.
Fail2ban ergänzt eine sichere SSH-Konfiguration, ersetzt aber weder Schlüsselanmeldung noch Firewall-Regeln und verhindert nicht jeden Angriff. Die offiziellen Projektunterlagen, die Ubuntu-Manpage und der Praxisleitfaden von Hetzner wurden am 2. November 2026 geprüft.[1][2][4]
Als ergänzende Video-Einführung ist das öffentlich auffindbare Video „Securing a server with FAIL2BAN (Ubuntu + SSH)“ verfügbar.[5]
Fertig¶
Die Einrichtung ist abgeschlossen, wenn fail2ban-client -t ohne Fehler endet, systemctl is-active fail2ban active meldet und sudo fail2ban-client status das Jail sshd aufführt. Eine anfänglich leere Sperrliste ist kein Fehler. Falls du einen kontrollierten Sperrtest ausgeführt hast, prüfe zusätzlich, dass die Test-IP danach wieder entsperrt ist.
Sources¶
[1] https://github.com/fail2ban/fail2ban/blob/master/config/jail.conf — Fail2ban upstream jail.conf [2] https://manpages.ubuntu.com/manpages/jammy/man5/jail.conf.5.html — Ubuntu jail.conf manual [3] https://community.hetzner.com/tutorials/secure-ssh-with-ufw-and-fail2ban-on-ubuntu — Hetzner Community: Securing SSH on Ubuntu with UFW and Fail2ban [4] https://www.youtube.com/watch?v=mUwbxqcACpM — Securing a server with FAIL2BAN (Ubuntu + SSH)