UFW und IPv6: Offene Ports auf Ihrem VPS schließen

Die IPv6-Firewall-Falle in einem Satz

Ihre Firewall schützt IPv4. Ihr VPS hat mit hoher Wahrscheinlichkeit zusätzlich eine öffentliche IPv6-Adresse, und viele Dienste lauschen standardmäßig darauf. Wenn Ihre Firewall nur IPv4 abdeckt oder Sie sich auf eine Cloud-Firewall verlassen, die nur IPv4 filtert, ist jeder dieser Dienste über IPv6 aus dem gesamten Internet erreichbar, während Ihre IPv4-Seite gesichert wirkt. Sie testen einen Port mit curl, sehen eine abgelehnte Verbindung und fühlen sich sicher. Ein Angreifer verbindet sich über IPv6 mit demselben Port und erhält Zugriff.

Dieser Leitfaden zeigt, wo diese Lücke auf einem normalen Ubuntu-24.04-VPS entsteht, wie Sie genau ermitteln, was Sie erreichbar machen, und wie Sie die Lücke schließen. UFW ist hier nicht der Verursacher. Bei einer modernen Ubuntu-Installation unterstützt UFW IPv6 bereits. Die Erreichbarkeit entsteht durch die umgebenden Ebenen und durch Dienste, von denen Sie nicht wussten, dass sie lauschen.

Warum Ihr VPS überhaupt IPv6 verwendet

Nahezu jeder VPS verfügt heute neben seiner IPv4-Adresse über eine öffentliche IPv6-Adresse, häufig über ein komplettes /64. Prüfen Sie Ihre Adresse:

ip -6 addr show scope global

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet6 2001:db8:2a::1/64 scope global

Dieses 2001:db8:2a::1 ist wie Ihre IPv4-Adresse aus dem gesamten Internet erreichbar. Sehen Sie sich nun an, welche Dienste auf Verbindungen warten:

sudo ss -tlnp

State   Recv-Q  Local Address:Port   Process
LISTEN  0       0.0.0.0:22           sshd
LISTEN  0       [::]:22              sshd
LISTEN  0       127.0.0.1:5432       postgres
LISTEN  0       [::]:8080            docker-proxy

Prüfen Sie die Spalte Local Address genau. 0.0.0.0:22 bedeutet „auf jeder IPv4-Adresse auf Verbindungen warten“. [::]:22 bedeutet „auf jeder IPv6-Adresse auf Verbindungen warten“. 127.0.0.1:5432 ist an das Loopback-Interface gebunden und daher überhaupt nicht öffentlich erreichbar. Die Postgres-Zeile ist deshalb unkritisch. Die beiden [::]-Zeilen nehmen über IPv6 Verbindungen aus dem gesamten Internet an. Die docker-proxy-Zeile gehört zu der Art von Dienst, dessen Start man leicht vergisst.

Die meisten Daemons binden standardmäßig an ::, weil ein ::-Socket unter Linux normalerweise auch IPv4-Verbindungen annimmt. Die Standardeinstellung eines frisch eingerichteten Servers lautet daher: „Auf beiden Protokollstapeln und überall Verbindungen annehmen.“ Ihre Firewall ist die einzige Schutzschicht davor. Deshalb ist eine Firewall, die nur einen Protokollstapel berücksichtigt, ein echtes Problem.

Woher die IPv6-Lücke tatsächlich kommt

Es gibt vier häufige Ursachen. Auf einem bestimmten System kann eine davon oder mehrere gleichzeitig zutreffen.

1. Eine Cloud-Firewall, die nur IPv4 filtert. Viele Provider-Firewalls und Security-Group-Produkte wurden ursprünglich für IPv4 entwickelt. Sie ignorieren IPv6 entweder oder benötigen separate IPv6-Regeln, die Sie manuell hinzufügen müssen. Wenn Ihre einzige Firewall die im Provider-Dashboard ist und IPv6 nicht abdeckt, sind Ihre [::]-Dienste unabhängig von den Angaben zu Port 22 über IPv4 offen. Lesen Sie die Dokumentation zur Firewall Ihres Providers und suchen Sie ausdrücklich nach dem Begriff IPv6.

2. Manuell erstellte iptables-Regeln ohne ip6tables. Der Befehl iptables bearbeitet nur die IPv4-Tabellen. Für IPv6 gibt es den vollständig separaten Befehl ip6tables mit eigenen Regeln. Wenn Ihr Firewall-Skript zahlreiche iptables -A INPUT ...-Zeilen enthält, aber keine entsprechenden ip6tables-Regeln, ist Ihre IPv6-Firewall leer. Eine leere INPUT-Kette mit der Standardrichtlinie ACCEPT lässt sämtlichen Verkehr zu:

sudo ip6tables -L INPUT -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Diese Ausgabe zeigt die gesamte Falle auf einem Bildschirm. IPv4 wird gefiltert, IPv6 akzeptiert den gesamten Verkehr.

3. Docker veröffentlicht Ports direkt an Ihrer Firewall vorbei. Wenn Sie docker run -p 8080:80 ausführen, fügt Docker seine eigenen Regeln vor denen von UFW ein. Dadurch ist ein veröffentlichter Port erreichbar, selbst wenn ufw status angibt, dass dieser Port gesperrt ist. Bei aktuellen Docker-Versionen gilt das auch für IPv6. Warum Docker UFW umgeht und wie Sie Container-Ports korrekt filtern erklärt den Mechanismus und die Lösungen. Unter Die Grundlagen von Docker Compose auf einem VPS erfahren Sie, wie diese veröffentlichten Ports definiert werden.

4. UFW mit deaktivierter IPv6-Unterstützung. UFW unterstützt IPv6, aber nur, wenn diese Funktion aktiviert ist. Prüfen Sie die Einstellung:

grep IPV6 /etc/default/ufw

Aktuelle Ubuntu-Versionen liefern IPV6=yes standardmäßig mit. Dadurch wendet UFW jede Regel auf beide Protokollstacks an. Wenn Sie IPV6=no sehen, stammt das System möglicherweise aus einem alten Image oder einer alten Anleitung. Dann ist jede von Ihnen erstellte UFW-Regel auf IPv4 beschränkt, während IPv6 nicht verwaltet wird.

Sehen Sie genau, was Sie erreichbar machen

Raten Sie nicht. Messen Sie es von außen. Listen Sie zuerst Ihre Listener auf und notieren Sie jeden, der an :: gebunden ist:

sudo ss -tlnp | grep '::'

Stellen Sie anschließend von einem anderen Rechner eine Verbindung zur öffentlichen IPv6-Adresse des Servers her und testen Sie einen Port, den Sie für geschlossen halten:

curl -6 -v http://[2001:db8:2a::1]:8080/

Wenn dabei eine Seite oder ein Banner zurückgegeben wird, ist der Port über IPv6 offen. Ein geschlossener Port liefert Connection refused oder einen Timeout. Diese beiden Fehler sind nicht dasselbe Signal. Der Unterschied zwischen „refused“ und „timed out“ zeigt, ob der Host geantwortet und die Verbindung abgewiesen hat oder ob eine Firewall Ihr Paket still verworfen hat. Für ein vollständiges Bild scannen Sie die IPv6-Adresse mit nmap von außerhalb des Servers:

nmap -6 2001:db8:2a::1

Jeder Port, den nmap über IPv6 als offen meldet, ist für das gesamte Internet erreichbar, unabhängig davon, was Ihr IPv4-Scan gezeigt hat. Vergleichen Sie die IPv4- und IPv6-Scans nebeneinander. So finden Sie die Lücke am schnellsten: Alles, was auf -6 offen, auf IPv4 jedoch geschlossen ist, ist ein Dienst, den Ihre Firewall nicht berücksichtigt.

Die Lücke schließen

Lassen Sie UFW beide Protokollstacks abdecken und verweigern Sie standardmäßig den Zugriff. Bestätigen Sie die Umschaltung. Legen Sie dann eine standardmäßige Deny-Regel für eingehenden Verkehr fest und erlauben Sie nur, was Sie benötigen:

sudo sed -i 's/^IPV6=no/IPV6=yes/' /etc/default/ufw
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

Wenn UFW beim Umschalten von IPV6=yes bereits aktiv war, wird die Änderung erst wirksam, nachdem Sie sudo ufw reload ausgeführt haben.

ufw status listet jede Regel zweimal auf: einmal ohne Zusatz und einmal mit dem Suffix (v6). Wenn die Zeilen mit (v6) angezeigt werden, filtert UFW IPv6:

22/tcp                     ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)

Wenn Sie iptables manuell verwalten, müssen Sie jede Regel in ip6tables übernehmen oder auf nftables umsteigen. Dessen inet-Tabellen decken IPv4 und IPv6 zentral ab und vermeiden diese Fehlerklasse vollständig. Eine einzelne inet-Filtertabelle in nftables ist die sauberste Lösung, wenn Sie die Regeln selbst schreiben. Wenn Ihr VPS statt Ubuntu Rocky oder AlmaLinux verwendet, gibt es kein UFW zu konfigurieren. In diesem Fall verwalten Sie stattdessen firewalld als Frontend. Es wendet seine Zonenregeln gleichzeitig auf beide Protokollstacks an.

Binden Sie Dienste, die nicht öffentlich erreichbar sein sollen, an die Loopback-Schnittstelle. Eine Datenbank, ein Administrationspanel oder ein Metrik-Endpunkt benötigt nur selten überhaupt eine öffentliche Adresse. Binden Sie den Dienst an 127.0.0.1 und ::1, damit er von vornherein nicht an einer routbaren Adresse lauscht. Setzen Sie bei Postgres listen_addresses = 'localhost'. Binden Sie einen Anwendungsserver an 127.0.0.1 und schalten Sie einen Reverse Proxy davor. Den Listener zu schließen ist sicherer als ihn per Firewall zu schützen, weil dann keine erreichbare Schnittstelle vorhanden ist.

Verlassen Sie sich nicht darauf, dass UFW die veröffentlichten Docker-Ports schützt. Veröffentlichen Sie Container-Ports an eine bestimmte Adresse statt an jeder Schnittstelle, zum Beispiel -p 127.0.0.1:8080:80. Dadurch ist der Port nur vom Host und von Diensten erreichbar, an die Sie den Zugriff bewusst per Proxy weiterleiten. Wenn ein Container tatsächlich öffentlich erreichbar sein muss, stellen Sie einen Traefik-Reverse-Proxy davor und veröffentlichen Sie nur den Proxy, nicht jede einzelne Anwendung.

Fügen Sie Ihrem Provider-Firewallregeln für IPv6 hinzu oder akzeptieren Sie, dass diese Firewall IPv6 nicht schützt. Lassen Sie diese Aufgabe stattdessen von UFW oder nftables auf dem Host übernehmen.

Prüfen Sie, ob der Dienst tatsächlich nicht mehr erreichbar ist

Führen Sie denselben externen Test nach den Änderungen erneut aus:

curl -6 -v http://[2001:db8:2a::1]:8080/
nmap -6 2001:db8:2a::1

Der Port, der zuvor geantwortet hat, sollte nun Verbindungen ablehnen oder eine Zeitüberschreitung verursachen. nmap sollte ihn als gefiltert oder geschlossen melden. Wenn ein Port weiterhin offen ist, prüfen Sie die vier oben genannten Quellen erneut: Ein Dienst ist möglicherweise weiterhin an :: gebunden, ohne dass eine Regel davor greift. Möglicherweise steht auch eine Docker-Regel vor UFW. Oder die Firewall des Providers hat IPv6 überhaupt nicht berücksichtigt.

Noch sicherer ist es, sensible Dienste vollständig aus dem öffentlichen Internet herauszuhalten. Platzieren Sie SSH und Administrationsoberflächen hinter einem WireGuard-VPN und konfigurieren Sie ihre Ports so, dass sie nur über den Tunnel erreichbar sind. Damit stellt sich die Frage nach der IPv6-Exponierung für diese Dienste nicht mehr. Um Brute-Force-Scans gegen weiterhin öffentliche Dienste zu verlangsamen, setzen Sie Fail2ban vor SSH zusätzlich zu einer Firewall mit standardmäßigem Deny-Verhalten ein.

Wenn Ports für Sie noch neu sind, lesen Sie zuerst was Ports sind und wie Dienste auf ihnen lauschen.

FAQ

Blockiert UFW IPv6 standardmäßig?

Bei einer aktuellen Ubuntu-24.04-Installation: ja. UFW liest IPV6=yes aus /etc/default/ufw und wendet jede Regel auf IPv4 und IPv6 an. ufw status zeigt die IPv6-Regeln mit dem Suffix (v6) an. Problematisch wird es, wenn IPV6=no auf IPV6=no gesetzt ist, etwa durch ein altes Image oder eine alte Anleitung, wenn Sie sich auf eine Provider-Firewall verlassen, die nur IPv4 filtert, oder wenn Docker einen Port an UFW vorbei veröffentlicht. Prüfen Sie diese Einstellung mit grep IPV6 /etc/default/ufw.

Wie prüfe ich, welche Ports mein VPS über IPv6 veröffentlicht?

Führen Sie sudo ss -tlnp aus. Beachten Sie jeden Listener, dessen lokale Adresse mit [::] beginnt. Das bedeutet, dass er auf jeder IPv6-Schnittstelle Verbindungen annimmt. Testen Sie anschließend von einem anderen Rechner aus die öffentliche IPv6-Adresse des Servers direkt mit curl -6 -v http://[YOUR:IPV6::ADDR]:PORT/ oder scannen Sie sie mit nmap -6 YOUR:IPV6::ADDR. Jeder Port, der beim IPv6-Scan offen und über IPv4 geschlossen ist, stellt eine Lücke dar.

Warum kann ich den Port meines Docker-Containers erreichen, obwohl UFW ihn als blockiert anzeigt?

Docker fügt seine eigenen Firewall-Regeln vor den UFW-Regeln ein, wenn Sie einen Port mit -p veröffentlichen. Deshalb bleibt der veröffentlichte Port erreichbar, obwohl ufw status ihn als abgelehnt aufführt. Das geschieht bei IPv4 und auch bei IPv6, wenn die IPv6-Unterstützung von Docker aktiviert ist. Veröffentlichen Sie den Port an eine bestimmte Adresse wie -p 127.0.0.1:8080:80 oder setzen Sie den Container hinter einen Reverse Proxy und veröffentlichen Sie nur den Proxy.

Benötige ich weiterhin eine IPv6-Firewall, wenn meine IPv4-Firewall sicher konfiguriert ist?

Ja. IPv4 und IPv6 sind getrennte Netzwerkstacks mit getrennten Firewall-Regeln. Ein vollständiger Satz von IPv4-Regeln hat keine Wirkung auf IPv6-Verkehr. Wenn Ihr VPS eine öffentliche IPv6-Adresse besitzt, was bei fast allen VPS der Fall ist, bleibt jeder Dienst, der auf :: lauscht, über IPv6 erreichbar, bis eine IPv6-Firewall-Regel oder eine Bindung an die Loopback-Schnittstelle dies verhindert.

Wie lasse ich einen Dienst nur auf IPv4 oder nur auf localhost lauschen?

Setzen Sie die Bind-Adresse in der Konfiguration des jeweiligen Dienstes. Binden Sie den Dienst an 127.0.0.1, wenn er nur auf dem IPv4-Loopback lauschen soll, oder an 0.0.0.0, wenn er auf allen IPv4-Adressen, aber nicht über IPv6 lauschen soll. Postgres verwendet listen_addresses, SSH verwendet ListenAddress, und die meisten Anwendungsserver bieten dafür eine Host- oder Bind-Option. Bestätigen Sie das Ergebnis mit sudo ss -tlnp und prüfen Sie, dass Local Address nicht mehr [::] anzeigt.