UFW-Firewall unter Ubuntu einrichten

Ein Server, der mit dem Internet verbunden ist, wird schon wenige Minuten nach dem Start von automatisierten Scannern abgeklopft. Eine Host-Firewall ist Ihre einfachste erste Verteidigungslinie: Sie entscheidet, welche Ports von außen überhaupt erreichbar sind, bevor ein Dienst den Datenverkehr zu Gesicht bekommt. Unter Ubuntu erledigt das UFW (Uncomplicated Firewall) – eine komfortable Oberfläche für das nftables/iptables-Backend des Kernels, die gängige Regeln zum Einzeiler macht.

Diese Anleitung richtet UFW unter Ubuntu 24.04 LTS auf die sichere Art ein. Das größte Risiko bei der Firewall-Konfiguration auf einem entfernten Server ist, sich selbst auszusperren, indem man die Firewall aktiviert, bevor SSH freigegeben ist. Wir geben deshalb zuerst SSH frei, setzen sinnvolle Standardrichtlinien, öffnen nur die wirklich benötigten Ports, ergänzen Rate-Limiting und prüfen jede Regel vor und nach dem Aktivieren.

Voraussetzungen

• Ein System mit Ubuntu 24.04 LTS.
• Ein Benutzer mit sudo-Rechten.
• Bei einer SSH-Verbindung: Wissen, auf welchem Port der SSH-Dienst lauscht (Standard ist 22).

Schritt 1: Prüfen, ob UFW installiert ist

UFW ist bei Ubuntu standardmäßig dabei. Prüfen Sie den aktuellen Status:

sudo ufw status verbose

Auf einem frischen System erscheint:

Status: inactive

Fehlt der Befehl, installieren Sie ihn nach:

sudo apt update
sudo apt install ufw

Schritt 2: SSH freigeben, bevor Sie irgendetwas anderes tun

Diese Regel bewahrt Sie vor dem Aussperren. Legen Sie sie jetzt an, solange die Firewall noch inaktiv ist:

sudo ufw allow OpenSSH

Das Anwendungsprofil OpenSSH öffnet TCP-Port 22. Lauscht Ihr SSH-Daemon auf einem abweichenden Port – etwa 2222 –, geben Sie diesen ausdrücklich frei:

sudo ufw allow 2222/tcp

Die bekannten Anwendungsprofile listen Sie so auf:

sudo ufw app list

Schritt 3: Standardrichtlinien festlegen

Eine gute Firewall verbietet sämtlichen eingehenden Verkehr, erlaubt ausgehenden Verkehr und öffnet eingehend nur das Nötigste. Setzen Sie diese Standards:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Schritt 4: Nur die tatsächlich genutzten Dienste freigeben

Öffnen Sie die Ports der Dienste, die dieser Host bereitstellt. Für einen Webserver:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

UFW kennt auch benannte Profile, die Pakete wie Nginx mitbringen:

sudo ufw allow 'Nginx Full'

Um einen Port auf eine einzige vertrauenswürdige Quelle zu beschränken – etwa PostgreSQL nur von einem App-Server:

sudo ufw allow from 10.0.0.5 to any port 5432 proto tcp

Für ein ganzes Subnetz:

sudo ufw allow from 10.0.0.0/24 to any port 3306 proto tcp

Schritt 5: SSH gegen Brute-Force drosseln

UFW kann wiederholte Verbindungsversuche bremsen. Die Regel limit sperrt eine IP, die mehr als sechs Verbindungen in 30 Sekunden aufbaut – ein leichter Gewinn gegen Brute-Force-Scanner:

sudo ufw limit OpenSSH

Bei einem eigenen SSH-Port drosseln Sie diesen: sudo ufw limit 2222/tcp. Beachten Sie: limit ersetzt das einfache allow für diesen Port – beide zugleich brauchen Sie nicht.

Schritt 6: Regeln vor dem Aktivieren prüfen

Sehen Sie sich die vorgemerkten Regeln an. Da die Firewall noch inaktiv ist, zeigt dies, was später greifen wird:

sudo ufw show added

Stellen Sie sicher, dass SSH in der Liste steht. Dies ist Ihre letzte Gelegenheit, einen Fehler zu bemerken, bevor Sie scharfschalten.

Schritt 7: Firewall aktivieren

sudo ufw enable

UFW warnt, dass der Befehl bestehende SSH-Verbindungen unterbrechen könnte, und fragt nach. Weil Sie SSH in Schritt 2 freigegeben haben, überlebt Ihre aktuelle Sitzung. Tippen Sie y und drücken Sie ENTER.

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Schritt 8: Aktives Regelwerk überprüfen

sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To                         Action      From

22/tcp (OpenSSH)           LIMIT       Anywhere
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere

Öffnen Sie jetzt – während Ihre erste Sitzung noch aktiv ist – eine zweite SSH-Sitzung zum Server. Klappt die neue Verbindung, sind Ihre Regeln korrekt. Schließen Sie nie Ihre einzige funktionierende Sitzung, bevor eine neue nachweislich verbindet.

Regeln später verwalten

Regeln nummeriert anzeigen, um sie per Index zu löschen:

sudo ufw status numbered

Eine Regel über ihre Nummer löschen:

sudo ufw delete 3

Oder durch Angabe der ursprünglichen Regel:

sudo ufw delete allow 80/tcp

Alles auf die Standardwerte zurücksetzen (dies deaktiviert die Firewall und löscht die Regeln):

sudo ufw reset

Häufige Stolperfallen und Fehlerbehebung

• UFW vor der SSH-Freigabe aktivieren. Der Klassiker beim Aussperren. Führen Sie immer zuerst ufw allow OpenSSH aus. Sperren Sie sich doch aus, brauchen Sie Konsolen- oder Out-of-Band-Zugriff.
• Falscher SSH-Port. Lauscht sshd auf einem eigenen Port, hilft das Profil OpenSSH (Port 22) nicht. Prüfen Sie mit sudo ss -tlnp | grep ssh und geben Sie den richtigen Port frei.
• Docker umgeht UFW. Docker schreibt eigene iptables-Regeln und veröffentlicht Container-Ports direkt, an UFW vorbei. Binden Sie Container an 127.0.0.1 oder nutzen Sie einen dedizierten Ansatz auf einem Firewall-Host.
• IPv6 vergessen. Stellen Sie sicher, dass IPV6=yes in /etc/default/ufw steht (Standard), damit Regeln auch für IPv6 gelten.
• Logs prüfen. Geblockte Pakete werden protokolliert. Beobachten Sie sie mit sudo tail -f /var/log/ufw.log.

Fazit

Eine Host-Firewall mit standardmäßig blockiertem Eingang, einer Freigabe für SSH, Rate-Limiting und nur den Ports, die Ihre Dienste benötigen, gehört auf jeden Ubuntu-Server. UFW macht das zur Fünf-Minuten-Aufgabe und hält das Regelwerk lesbar – auch Monate später, wenn Sie vergessen haben, warum Port 8443 offen ist.

Eine Firewall ist nur eine Ebene. Ergänzen Sie sie um automatisches Sperren von Brute-Force-Angreifern – siehe unsere Anleitung zu fail2ban gegen Brute-Force-Angriffe – für gestaffelte Sicherheit. Dasselbe Modell skaliert in die Cloud: In OpenStack ersetzen Security Groups und Keypairs die Firewall pro Host und greifen einheitlich über alle Instanzen hinweg. Wenn Sie Regeln nicht Host für Host pflegen möchten: clouditiv betreibt eine gehärtete, nach ISO 27001 / BSI C5 zertifizierte souveräne Cloud, in der Netzwerkrichtlinien zentral durchgesetzt werden und Ihre Daten in Deutschland bleiben.