UFW wurde erfunden, damit sich eine Firewall mit drei Befehlen einrichten lässt, und das gelingt ihm. Das Problem liegt woanders: ufw status zeigt Absichten, keine Ergebnisse. Eine Regel kann in der Liste stehen und trotzdem gar nichts schließen — aus drei verschiedenen Gründen, die auf echten Servern alle regelmäßig vorkommen.

Ein Anfang, bei dem Sie sich nicht aussperren

Die Reihenfolge der Befehle ist entscheidend. Zuerst SSH erlauben, dann einschalten:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

ufw enable vor der SSH-Freigabe kappt Ihre eigene Sitzung, und danach bleibt nur die Konsole des Hosters. Ist der Server bereits eingerichtet und Sie unsicher — halten Sie eine zweite Verbindung offen, sie überlebt eine missglückte Änderung.

Sehen Sie sich den ausführlichen Status an; der kurze verbirgt die Standardrichtlinie:

sudo ufw status verbose

Fehler eins: Die Regel steht, und der Port ist für alle offen

Die häufigste Zeile in fremden Konfigurationen:

sudo ufw allow 3306

So wird MySQL geöffnet, „damit ich von zu Hause verbinden kann“ — und damit für das gesamte Internet. Es gibt zwei richtige Varianten, und beide sind besser:

sudo ufw allow from 203.0.113.25 to any port 3306

oder, zuverlässiger, den Dienst gar nicht erst nach außen lassen: bind-address = 127.0.0.1 in der MySQL-Konfiguration, Zugriff von außen über einen SSH-Tunnel. Die Firewall ist die zweite Linie; die erste ist, dass der Dienst nicht auf einer öffentlichen Adresse lauscht. Eine Regel in UFW lässt sich versehentlich löschen, bind-address ändert sich nicht von selbst.

Fehler zwei: IPv6

Eine Regel wie ufw allow from 203.0.113.25 gilt nur für IPv4. Hat der Server eine IPv6-Adresse — und die meisten VPS haben eine, aktiviert —, bleibt der Dienst darüber erreichbar. Der Hoster hat die Adresse vergeben, Sie erinnern sich nicht daran, der Scanner weiß davon.

Prüfen Sie, ob die v6-Filterung überhaupt aktiv ist (IPV6=yes in /etc/default/ufw) und ob der Dienst ohne Not auf :: lauscht:

ss -tulpn | grep ':::'

Regeln mit ausdrücklicher Adressangabe müssen für beide Protokollversionen getrennt angelegt werden.

Fehler drei: Docker

Der ärgerlichste. Docker veröffentlicht Ports, indem es eigene Regeln vor jenen in die iptables-Ketten schreibt, in die UFW schreibt. Dadurch ist ein mit -p 5432:5432 gestarteter Container aus dem Internet erreichbar, auch wenn UFW Status: active und eine deny incoming-Richtlinie meldet. Die Firewall ist dabei nicht kaputt — sie kommt schlicht nicht an die Reihe.

Behoben wird das nicht in UFW, sondern in der Art, wie der Port veröffentlicht wird:

ports:
  - "127.0.0.1:5432:5432"

Die Bindung an die lokale Adresse ist die einfachste und verlässlichste Lösung. Nach außen darf nur zeigen, was tatsächlich Besucher bedient: üblicherweise die Ports 80 und 443 eines Reverse Proxy.

Die Regelreihenfolge

UFW wendet die erste passende Regel an und hört dort auf. Eine Sperre, die nach einer Erlaubnis eingefügt wurde, greift daher nicht: Sie wird nie erreicht. Sehen Sie sich die Nummerierung an und fügen Sie an der richtigen Stelle ein:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 7

Regeln werden nach Nummer gelöscht, aber die Nummern verschieben sich nach jedem Löschen — löschen Sie einzeln und lesen Sie die Liste jeweils neu.

Prüfung von außen

Lokale Befehle zeigen, was eingestellt ist. Was tatsächlich herauskam, sieht man nur von einer anderen Maschine aus:

nmap -Pn -p- 203.0.113.25
nc -zv 203.0.113.25 3306

Ein beliebiger anderer Server oder der heimische Rechner genügt. Das ist die einzige Prüfung, die nicht lügt, und sie lohnt sich nach jeder nennenswerten Umkonfiguration — besonders nach der Installation von etwas, das „das Netzwerk selbst einrichtet“: Docker, Verwaltungspanels, VPNs.

Protokolle

Standardmäßig schreibt UFW fast nichts. Eingeschaltet wird es so:

sudo ufw logging low

Die Einträge landen in /var/log/ufw.log — allerdings nur, wenn rsyslog im System vorhanden ist. Unter Debian 12 und Ubuntu 24.04 kann es fehlen, dann geht alles in das systemd-Journal:

sudo journalctl -k | grep -i '\[UFW'

Ein leeres /var/log/ufw.log bedeutet für sich genommen nichts — sehen Sie zuerst im Journal nach.

Was von einer Firewall zu erwarten ist

UFW schließt, was nicht erreichbar sein soll. Den Inhalt von Anfragen an das Offene prüft es nicht: Port 443 steht allen offen, und was an die Website kommt, kommt ungehindert an. Das ist die Aufgabe anderer Werkzeuge — einer WAF auf Anwendungsebene, eines IDS auf Verkehrsebene. Die Aufgabe der Firewall ist bescheidener und wichtiger: dass die Liste der offenen Ports mit dem übereinstimmt, was Sie darüber glauben. Wie diese Liste zusammen mit den aktiven Regeln auf einer Seite aussieht, zeigt die Demo unten.