Ein frisch aufgesetzter Linux-Server ist binnen Minuten Ziel automatisierter Angriffe. Login-Versuche auf den SSH-Port laufen rund um die Uhr. Mit zwei Bordmitteln bekommst du das in den Griff: UFW (Uncomplicated Firewall) regelt, welche Ports überhaupt erreichbar sind, und Fail2ban sperrt IP-Adressen automatisch aus, sobald sie sich an Logins versuchen. Diese Anleitung zeigt dir die komplette Standalone-Härtung eines Debian-12- oder Ubuntu-24.04-Servers mit copy-paste-fertigen Befehlen und Konfigdateien.

Kurzfassung: Erst ufw allow OpenSSH, dann ufw default deny incoming plus ufw enable (sonst Lockout). Webports mit ufw allow 80/tcp und 443/tcp öffnen, SSH per allow from IP auf deine Admin-IP einschränken. Danach Fail2ban installieren, eine /etc/fail2ban/jail.local mit aktiviertem sshd-Jail und backend = systemd anlegen (Pflicht auf Debian 12 / Ubuntu 24.04), Status mit fail2ban-client status sshd prüfen. Beides ersetzt keine SSH-Key-Authentifizierung.

Voraussetzungen

Ein Server mit Debian 12 (Bookworm) oder Ubuntu 24.04 LTS (Noble), frisch installiert oder bereits in Betrieb.
Ein Benutzer mit sudo-Rechten und eine bestehende SSH-Verbindung. Halte diese Sitzung offen, bis die Firewall sicher funktioniert.
Deine eigene öffentliche IP-Adresse als Admin-IP (ermittelbar z. B. mit curl ifconfig.me vom Arbeitsplatz). Bei DSL ohne feste IP nutzt du dein Subnetz oder verzichtest auf die IP-Einschränkung.
Idealerweise bereits eingerichtete SSH-Key-Authentifizierung statt Passwort. Wie das geht, zeigt die verlinkte Anleitung am Ende.

Alle Befehle laufen als normaler Nutzer mit vorangestelltem sudo. Auf einem reinen Root-Login lässt du sudo weg.

Schritt 1: Standard-Richtlinien für UFW setzen

UFW ist auf Ubuntu vorinstalliert, auf Debian installierst du es bei Bedarf nach. Das Grundprinzip einer sicheren Firewall lautet: alles eingehende blockieren, alles ausgehende erlauben. So ist nur erreichbar, was du explizit freigibst.

# Auf Debian ggf. nachinstallieren (Ubuntu hat UFW bereits)
sudo apt update
sudo apt install ufw

# Grundregeln: eingehend sperren, ausgehend erlauben
sudo ufw default deny incoming
sudo ufw default allow outgoing

Wichtig: Aktiviere die Firewall jetzt noch nicht. Mit deny incoming würdest du dich sofort selbst aussperren, weil auch dein SSH-Zugang blockiert wäre. Erst die SSH-Regel im nächsten Schritt macht den Weg frei.

Schritt 2: SSH freigeben (vor dem Aktivieren)

Das ist der kritischste Schritt. Bevor du UFW einschaltest, musst du SSH explizit erlauben. UFW bringt dafür ein App-Profil mit, das aus /etc/ufw/applications.d stammt und den Standard-SSH-Port abdeckt.

# Variante A: App-Profil (Standardport 22)
sudo ufw allow OpenSSH

# Variante B: gleichbedeutend per Portangabe
sudo ufw allow 22/tcp

Beide Varianten erlauben eingehende SSH-Verbindungen. Welche du nimmst, ist Geschmackssache. Das App-Profil OpenSSH ist lesbarer in der Statusausgabe, die Portangabe ist explizit. Hast du SSH auf einen anderen Port verlegt, gibst du diesen statt 22 an.

Welche App-Profile dein System kennt, zeigt:

sudo ufw app list

Schritt 3: Webports und weitere Dienste öffnen

Betreibt der Server eine Website, einen Reverse Proxy oder eine API, brauchst du HTTP und HTTPS. Öffne nur die Ports, die du wirklich nutzt.

# HTTP und HTTPS freigeben
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Alternativ als App-Profil, falls ein Webserver installiert ist
# sudo ufw allow 'Nginx Full'

Weitere Dienste gibst du nach demselben Muster frei, etwa sudo ufw allow 25/tcp für SMTP. Faustregel: Jeder offene Port ist eine potenzielle Angriffsfläche. Datenbanken (MySQL 3306, PostgreSQL 5432) gehören in den seltensten Fällen offen ins Internet.

Schritt 4: SSH auf deine Admin-IP einschränken

SSH für die ganze Welt zu öffnen ist die häufigste Quelle für Brute-Force-Lärm. Wenn du eine feste IP-Adresse hast, schränkst du den Zugang auf diese ein. Damit verschwinden die meisten Angriffe schon, bevor Fail2ban überhaupt eingreifen muss.

# SSH nur von einer bestimmten IP erlauben
sudo ufw allow from 203.0.113.5 to any port 22 proto tcp

# Oder ein ganzes Subnetz erlauben (z. B. Firmen-LAN/VPN)
sudo ufw allow from 192.168.1.0/24

Reihenfolge beachten: Setzt du eine eingeschränkte SSH-Regel, solltest du die offene Regel aus Schritt 2 später entfernen (siehe Schritt 6). Sonst bleibt SSH trotzdem für alle erreichbar, weil bei UFW die erste passende Regel gewinnt. Die breite allow OpenSSH würde greifen, bevor die spezifische Regel überhaupt geprüft wird.

Hast du keine feste IP (typisch bei DSL daheim), überspringe diesen Schritt und verlasse dich auf SSH-Keys plus Fail2ban. Sperre dich nicht versehentlich mit einer falschen IP aus.

Schritt 5: Firewall aktivieren und prüfen

Jetzt erst, mit gesetzter SSH-Regel, schaltest du UFW scharf. UFW warnt, dass bestehende SSH-Verbindungen unterbrochen werden könnten. Solange deine SSH-Regel korrekt ist, bleibt die laufende Sitzung bestehen.

# Firewall einschalten
sudo ufw enable

# Status ausführlich anzeigen (Default-Policies und Regeln)
sudo ufw status verbose

# Logging aktivieren (Treffer landen in /var/log/ufw.log)
sudo ufw logging on

Die Ausgabe von ufw status verbose sollte Default: deny (incoming), allow (outgoing) sowie deine Allow-Regeln zeigen. Mach jetzt den Test: Öffne ein zweites Terminal und baue eine neue SSH-Verbindung auf. Klappt sie, ist alles korrekt. Schlägt sie fehl, korrigierst du die Regeln über die noch offene erste Sitzung.

Schritt 6: Regeln verwalten, einfügen und löschen

Im Alltag musst du Regeln anpassen. Die wichtigste Ansicht ist die nummerierte Liste, denn gelöscht wird über die Nummer.

# Regeln nummeriert anzeigen
sudo ufw status numbered

# Regel Nr. 3 löschen (z. B. die alte offene SSH-Regel)
sudo ufw delete 3

# Eine Deny-Regel an Position 1 einfügen (zuerst geprüft)
sudo ufw insert 1 deny from 198.51.100.7

Mit insert steuerst du die Reihenfolge gezielt. Da die erste passende Regel gewinnt, müssen spezifische Deny-Regeln (z. B. das Sperren einer einzelnen IP) über breiteren Allow-Regeln stehen. Eine deny-Regel ganz unten ist wirkungslos, wenn weiter oben bereits ein passendes allow greift.

Die UFW-Konfiguration liegt unter /etc/ufw/ (die Regeln), die Default-Policies und IPv6-Einstellungen in /etc/default/ufw, die App-Profile in /etc/ufw/applications.d. Diese Dateien bearbeitest du im Normalfall nicht von Hand, sondern steuerst alles über den ufw-Befehl.

Schritt 7: Fail2ban installieren und konfigurieren

UFW entscheidet, welche Ports offen sind. Wer durch einen offenen Port (typisch SSH) immer wieder falsche Logins versucht, wird davon aber nicht gestoppt. Genau das übernimmt Fail2ban: Es liest die Logs, zählt Fehlversuche und sperrt auffällige IPs zeitweise per Firewall-Regel.

# Fail2ban installieren und starten
sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Die zentrale Regel: Bearbeite niemals jail.conf. Diese Datei wird bei jedem Update überschrieben. Eigene Einstellungen gehören in /etc/fail2ban/jail.local oder in einzelne Dateien unter /etc/fail2ban/jail.d. Schlüssel aus .local überschreiben die Vorgaben aus .conf.

Lege die jail.local an:

sudoedit /etc/fail2ban/jail.local

Trage folgenden Inhalt ein. Ersetze 203.0.113.5/32 durch deine Admin-IP, damit du dich nie selbst aussperrst:

[DEFAULT]
# Eigene IPs/Netze, die nie gebannt werden (Leerzeichen-getrennt)
ignoreip = 127.0.0.1/8 ::1 203.0.113.5/32

# Sperrdauer und Erkennungsfenster
bantime  = 1h
findtime = 10m
maxretry = 5

# Sperren fuer Wiederholungstaeter automatisch verlaengern
bantime.increment = true

[sshd]
enabled  = true
# Pflicht auf Debian 12 / Ubuntu 24.04: Logs liegen im journald
backend  = systemd
port     = ssh
maxretry = 3
bantime  = 1h

Was bedeuten die Werte? Fail2ban sperrt eine IP, wenn innerhalb von findtime (hier 10 Minuten) mehr als maxretry Fehlversuche auftreten. Im sshd-Jail sind das 3 Versuche, danach folgt eine Sperre von bantime (1 Stunde). Mit bantime.increment = true wird die Sperre bei jedem erneuten Auffliegen länger. Der Standard von Fail2ban 1.x wäre bantime und findtime von je 10 Minuten und maxretry = 5, hier ziehen wir die SSH-Schraube etwas fester an.

Der entscheidende Stolperstein auf Debian 12 und Ubuntu 24.04: Diese Systeme schreiben SSH-Logins nicht mehr nach /var/log/auth.log, sondern in das systemd-journald. Ohne backend = systemd findet Fail2ban keine Logzeilen und bannt schlicht nie. Das ist der häufigste Grund, warum Fail2ban scheinbar nicht funktioniert.

Schritt 8: Fail2ban testen und Bans verwalten

Nach jeder Änderung an der Konfiguration prüfst du erst die Syntax und lädst dann neu. So merkst du Tippfehler, bevor sie den Dienst lahmlegen.

# Konfiguration testen
sudo fail2ban-client -t

# Konfiguration neu laden
sudo fail2ban-client reload

# Alle aktiven Jails anzeigen
sudo fail2ban-client status

# Details und Bans des sshd-Jails
sudo fail2ban-client status sshd

Die Ausgabe von status sshd zeigt unter anderem die Anzahl der gefundenen Fehlversuche und die aktuell gebannten IP-Adressen. Eine versehentlich gesperrte Adresse holst du so zurück, eine bekannte Angreifer-IP sperrst du manuell:

# IP aus dem sshd-Jail entsperren
sudo fail2ban-client set sshd unbanip 203.0.113.5

# IP manuell im sshd-Jail sperren
sudo fail2ban-client set sshd banip 198.51.100.7

Fail2ban arbeitet über die banaction (Standard iptables bzw. nftables) und legt eigene Firewall-Ketten an. Es läuft damit parallel zu UFW, nicht innerhalb davon. Das hat eine wichtige Konsequenz für die Praxis: Fail2ban-Bans tauchen nicht in ufw status auf. Geprüft werden sie ausschließlich über fail2ban-client status sshd.

Schritt 9: SSH-Key-Authentifizierung als Fundament

UFW und Fail2ban reduzieren die Angriffsfläche, ersetzen aber keine sichere Authentifizierung. Ein erratenes Passwort schlägt jede Firewall. Deshalb gehört zur Härtung zwingend die Umstellung auf SSH-Keys und das Abschalten der Passwort-Anmeldung.

# SSH-Konfiguration bearbeiten
sudoedit /etc/ssh/sshd_config

Setze beziehungsweise prüfe diese beiden Werte:

PasswordAuthentication no
PermitRootLogin prohibit-password

Danach lädst du den SSH-Dienst neu. Stelle vorher sicher, dass dein SSH-Key funktioniert, sonst sperrst du dich aus.

sudo systemctl reload ssh

Mit deaktivierter Passwort-Anmeldung laufen die meisten Brute-Force-Angriffe ohnehin ins Leere. Fail2ban fängt dann vor allem die hartnäckigen Bots ab, UFW hält den Rest fern. Die vollständige Einrichtung der Schlüssel findest du in der verlinkten Key-Anleitung.

Troubleshooting

Ich habe mich nach ufw enable ausgesperrt. Das passiert, wenn vor dem Aktivieren keine SSH-Allow-Regel existierte. Über die Server-Konsole des Providers (KVM, VNC, Rescue-System) meldest du dich lokal an und führst sudo ufw allow OpenSSH aus oder schaltest die Firewall mit sudo ufw disable ab.

Fail2ban bannt nie, obwohl Angriffe laufen. Der Klassiker auf Debian 12 / Ubuntu 24.04: Es fehlt backend = systemd im sshd-Jail, oder die Datei /var/log/auth.log ist leer beziehungsweise existiert gar nicht. Trage das Backend ein, führe fail2ban-client -t und fail2ban-client reload aus und prüfe mit fail2ban-client status sshd.

Das sshd-Jail erscheint nicht in fail2ban-client status. Dann fehlt enabled = true im Jail-Block, oder die Konfiguration wurde nach der Änderung nicht neu geladen. Ohne enabled = true bleibt ein Jail inaktiv.

Eine Deny-Regel in UFW greift nicht. Bei UFW gewinnt die erste passende Regel. Steht über deiner Deny-Regel ein breiteres allow, wird die Sperre nie erreicht. Verschiebe die Deny-Regel mit ufw insert 1 ... nach oben und kontrolliere die Reihenfolge mit ufw status numbered.

Container-Ports sind trotz UFW-Sperre erreichbar. Docker umgeht UFW, weil der Docker-Daemon eigene iptables-Regeln in der DOCKER-Kette schreibt. Eine UFW-Deny-Regel hilft hier nicht. Binde Container-Ports an 127.0.0.1 (z. B. 127.0.0.1:8080:80) oder setze einen Reverse Proxy davor, statt Ports direkt nach außen zu veröffentlichen.

Häufige Fragen

Brauche ich überhaupt UFW, wenn ich schon Fail2ban habe?

Ja, beide ergänzen sich. UFW entscheidet grundsätzlich, welche Ports erreichbar sind, und schließt alles Unnötige. Fail2ban schützt die wenigen offenen Dienste vor wiederholten Login-Versuchen. Ohne UFW stünden Dienste offen, die niemand von außen braucht.

Wie finde ich heraus, ob meine IP aktuell gesperrt ist?

Mit sudo fail2ban-client status sshd siehst du die Liste der gebannten Adressen. Taucht deine IP dort auf, entsperrst du sie mit sudo fail2ban-client set sshd unbanip DEINE-IP. Damit das nicht wieder passiert, trägst du sie unter ignoreip in der jail.local ein.

Was bedeutet `bantime.increment = true` genau?

Normalerweise wird eine IP für die feste bantime gesperrt. Mit aktiviertem Increment verlängert Fail2ban die Sperrdauer bei jedem erneuten Auffliegen derselben IP. Wiederholungstäter werden so progressiv länger ausgesperrt, einmalige Fehlversuche dagegen mild behandelt.

Funktioniert das auch in einem Docker-Container?

Fail2ban läuft im Container, braucht aber Zugriff auf die Host-Logs und passende Capabilities, um Firewall-Regeln zu setzen. In der Praxis härtest du meist den Docker-Host selbst mit UFW und Fail2ban. Beachte dabei, dass Docker eigene iptables-Regeln schreibt und UFW-Sperren für veröffentlichte Container-Ports unterlaufen kann.

Reichen UFW und Fail2ban als kompletter Schutz?

Sie sind eine solide Basis, aber kein Rundumschutz. SSH-Key-Authentifizierung ist Pflicht, regelmäßige Updates ebenso. Für Admin-Zugänge lohnt zusätzlich eine Zwei-Faktor-Authentifizierung. Sicherheit ist immer ein Zusammenspiel mehrerer Schichten.

Fazit

Mit UFW und Fail2ban härtest du einen Linux-Server in unter einer Stunde spürbar ab. Die Reihenfolge ist entscheidend: erst SSH erlauben, dann die Firewall scharf schalten, sonst droht der Lockout. Fail2ban ergänzt das, indem es Brute-Force-IPs automatisch sperrt. Auf Debian 12 und Ubuntu 24.04 ist backend = systemd der eine Eintrag, an dem die meisten scheitern. Trage deine Admin-IP unter ignoreip ein, schränke SSH nach Möglichkeit auf feste IPs ein, und kombiniere alles mit SSH-Key-Authentifizierung. Dann ist dein Server gegen den alltäglichen Angriffslärm aus dem Internet gut gewappnet.

Weiterführende Anleitungen und Quellen

SSH-Key-Authentifizierung einrichten (Linux und Windows) – das Fundament jeder Server-Härtung, ergänzt UFW und Fail2ban.
Logs lesen mit journalctl und /var/log unter Linux – nützlich, um Fail2ban-Treffer und SSH-Logins im journald nachzuvollziehen.
Zwei-Faktor-Authentifizierung (2FA/MFA) einführen – zusätzliche Schicht für besonders schützenswerte Admin-Zugänge.
Weitere Anleitungen aus der Kategorie Sicherheit

Quellen: