UFW und Fail2ban sind für viele Linux-Server der erste sinnvolle Sicherheitsbaustein. UFW steuert, welche eingehenden Ports überhaupt erreichbar sind. Fail2ban reagiert auf verdächtige Wiederholungen in Logs und sperrt auffällige IP-Adressen zeitweise aus. Beide Werkzeuge ergänzen sich, ersetzen aber keine Schlüssel-Anmeldung und keine regelmäßigen Updates.

Der gefährlichste Fehler bei diesem Thema ist nicht ein zu offener Server, sondern ein falsch geschlossener: Wer SSH vergisst, sperrt sich selbst aus. Deshalb folgt diese Anleitung einer festen Reihenfolge. Eine ausführlichere Grundhärtung mit Benutzerkonten und SSH-Daemon-Einstellungen zeigt VPS absichern und härten.

Voraussetzungen

Debian-12/13- oder Ubuntu-22.04/24.04-Server mit sudo-Rechten; UFW und Fail2ban laufen schon mit 1 CPU-Kern und 512 MB RAM
Funktionierender SSH-Zugang und bei gemieteten Servern Zugang zur Web- oder KVM-Konsole des Anbieters als Notzugang
Eine Liste der Dienste, die der Server nach außen anbieten soll (zum Beispiel SSH, HTTP, HTTPS)

Schritt 1: Vor dem Härten den SSH-Zugang absichern

Bevor Sie eine Firewall aktivieren, muss Ihr SSH-Zugang funktionieren. Ideal ist ein bereits getesteter Schlüssel-Login. Dazu passt unsere Anleitung SSH-Key-Authentifizierung einrichten.

Verifizieren: Öffnen Sie eine zweite SSH-Sitzung und prüfen Sie, dass Sie sich neu verbinden können. Lassen Sie die erste Sitzung bis zum Ende dieser Anleitung offen.

Schritt 2: UFW-Grundregeln setzen

sudo apt update
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH

Damit ist eingehender Verkehr standardmäßig gesperrt, ausgehender erlaubt und SSH (Port 22/tcp) freigegeben. Die Regeln greifen erst nach ufw enable in Schritt 3. Läuft SSH auf einem anderen Port, erlauben Sie diesen stattdessen, zum Beispiel sudo ufw allow 2222/tcp.

Verifizieren: sudo ufw show added listet ufw allow OpenSSH. ufw status zeigt vor der Aktivierung nur Status: inactive.

Schritt 3: Nur nötige Dienste freigeben

Öffnen Sie jetzt nur die Ports, die Ihr Server braucht, und aktivieren Sie danach die Firewall.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status numbered

Port 80 und 443 sind typische Webserver-Ports. Datenbank- oder Admin-Ports öffnen Sie nur, wenn sie von außen erreichbar sein müssen. Hinweis: Ports, die Docker-Container veröffentlichen, umgehen UFW, weil Docker eigene Regeln setzt.

Verifizieren: sudo ufw status verbose zeigt Status: active, Default: deny (incoming), allow (outgoing) und nur die erwarteten Freigaben. Eine neue SSH-Sitzung funktioniert weiterhin.

Schritt 4: Fail2ban installieren und für SSH aktivieren

sudo apt install fail2ban
sudo nano /etc/fail2ban/jail.local

Legen Sie jail.local als neue, leere Datei an und tragen Sie nur Ihre Abweichungen ein. Kopieren Sie jail.conf nicht: Die Kopie würde alle Standardwerte festschreiben, und Verbesserungen aus Paket-Updates kämen nicht mehr an. Für den Einstieg reicht die SSH-Jail:

[sshd]
enabled = true
backend = systemd
bantime = 1h
findtime = 10m
maxretry = 5

backend = systemd liest die Anmeldeversuche aus dem Journal. Debian 12 und 13 schreiben ohne zusätzlich installiertes rsyslog keine /var/log/auth.log mehr; mit dem alten Standard-Backend startet die Jail dort nicht.

Danach:

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

Verifizieren: systemctl status fail2ban zeigt active (running). Bei Fehlern nennt sudo fail2ban-client -t die fehlerhafte Zeile.

Schritt 5: Jails und Sperren prüfen

sudo fail2ban-client status
sudo fail2ban-client status sshd

Damit prüfen Sie, ob die SSH-Jail aktiv ist und ob aktuell gesperrte IPs geführt werden. Eine versehentlich gesperrte eigene Adresse geben Sie mit sudo fail2ban-client set sshd unbanip IP-ADRESSE frei.

Verifizieren: sudo fail2ban-client status listet unter Jail list den Eintrag sshd, und status sshd zeigt die Zähler Currently failed und Currently banned.

Schritt 6: Zusammenspiel aus Firewall, SSH und Logs kontrollieren

Kontrollieren Sie abschließend die Logs:

sudo journalctl -u fail2ban -n 50
sudo journalctl -u ssh -f

Auf RHEL-basierten Systemen heißt die SSH-Unit sshd. Mit installiertem rsyslog steht dieselbe Information zusätzlich in /var/log/auth.log.

Wie Sie solche Meldungen systematisch lesen, erklärt unser Grundlagenartikel Logs lesen mit journalctl und /var/log.

Verifizieren: Ein fehlgeschlagener SSH-Login von einem Testgerät erscheint im SSH-Journal als Failed password oder Invalid user, und sudo fail2ban-client status sshd erhöht den Zähler Total failed.

Troubleshooting

SSH geht nach UFW nicht mehr: Die SSH-Regel fehlte beim Aktivieren oder SSH läuft auf einem anderen Port. Melden Sie sich über die Konsole des Anbieters an und führen Sie sudo ufw allow OpenSSH bzw. die Regel für Ihren Port aus.
Fail2ban startet nicht: Meist steckt ein Syntaxfehler in jail.local. sudo fail2ban-client -t zeigt ihn. Meldet das Log „Have not found any log file for sshd jail“, fehlt backend = systemd.
Keine Sperren sichtbar: Es gab noch keine passenden Fehlversuche, oder die Jail liest die falsche Quelle. Prüfen Sie Total failed in status sshd.

Häufige Fragen

Reicht UFW allein aus?

Nein. UFW regelt nur den Netzwerkzugang. Fail2ban ergänzt eine Reaktion auf wiederholte Fehlversuche.

Soll ich alle Ports schließen?

Alle unnötigen Ports ja. Nötige Dienste wie SSH oder HTTPS müssen gezielt offen bleiben.

Kann Fail2ban eine Firewall ersetzen?

Nein. Fail2ban arbeitet ergänzend, nicht statt einer Firewall.

Fazit

UFW und Fail2ban bilden einen ersten Sicherheitsrahmen für Linux-Server. Entscheidend ist die Reihenfolge: erst SSH absichern, dann Ports minimieren, dann Angriffsversuche überwachen und am Ende alles gegen Logs und Status prüfen.

Weiterführende Anleitungen und Quellen

Quellen: ufw(8) Manpage, Fail2ban jail.conf (Hinweise zu jail.local), Debian-Bug 1037437 (sshd-Jail ohne rsyslog).