UFW en IPv6: is uw VPS wel echt veilig?

De IPv6-firewallval in één zin

Uw firewall beveiligt IPv4. Uw VPS heeft vrijwel zeker ook een publiek IPv6-adres en veel services luisteren hier standaard op. Als uw firewall alleen IPv4 dekt, of als u vertrouwt op een cloud-firewall die alleen IPv4 filtert, is elk van die services via IPv6 bereikbaar vanaf het hele internet, terwijl uw IPv4-kant beveiligd lijkt. U test een poort met curl, ziet een geweigerde verbinding en waant zich veilig. Een aanvaller verbindt met dezelfde poort via IPv6 en krijgt ongehinderd toegang.

Deze handleiding laat zien waar dit gat vandaan komt op een standaard Ubuntu 24.04 VPS, hoe u precies ziet wat u blootstelt en hoe u dit dicht. UFW is hier niet de boosdoener. Op een moderne Ubuntu-installatie verwerkt UFW IPv6 al. De blootstelling ontstaat door de lagen eromheen en door services waarvan u niet wist dat ze luisterden.

Waarom uw VPS standaard over IPv6 beschikt

Bijna elke VPS wordt tegenwoordig geleverd met een publiek IPv6-adres, vaak een volledig /64, naast het IPv4-adres. Controleer het uwe:

ip -6 addr show scope global

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

Dat 2001:db8:2a::1 is vanaf elk punt op het internet routeerbaar, precies zoals uw IPv4-adres. Kijk nu wat er luistert:

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

Lees de kolom Local Address nauwkeurig. 0.0.0.0:22 betekent "luister op elk IPv4-adres". [::]:22 betekent "luister op elk IPv6-adres". 127.0.0.1:5432 is gebonden aan loopback en is niet publiek toegankelijk, dus de Postgres-regel is veilig. De twee [::]-regels antwoorden aan het hele internet via IPv6, en de docker-proxy-regel is er een die u waarschijnlijk vergeten bent.

De meeste daemons binden standaard aan ::, omdat een ::-socket op Linux meestal ook IPv4 accepteert. De standaardinstelling van een verse server is dus "antwoord op beide stacks, overal". Uw firewall is het enige dat hiervoor staat, en daarom is een firewall die slechts één stack ziet een reëel probleem.

Waar het IPv6-gat daadwerkelijk vandaan komt

Er zijn vier veelvoorkomende oorzaken. Op een specifieke server kunt u last hebben van één of meerdere van deze oorzaken tegelijk.

1. Een cloud-firewall die alleen IPv4 filtert. Veel firewalls en security-group-producten van providers zijn ontwikkeld rondom IPv4 en negeren IPv6, of vereisen aparte IPv6-regels die u handmatig moet toevoegen. Als uw enige firewall die in het dashboard van de provider is en deze IPv6 niet dekt, staan uw [::]-services open, ongeacht wat er over poort 22 op IPv4 wordt vermeld. Lees de firewall-documentatie van uw provider en zoek specifiek naar de term IPv6.

2. Handgeschreven iptables zonder ip6tables. Het iptables-commando bewerkt alleen de IPv4-tabellen. IPv6 heeft een volledig apart commando, ip6tables, met zijn eigen afzonderlijke regels. Als u een firewall-script heeft geschreven vol met iptables -A INPUT ...-regels en nooit de bijbehorende ip6tables-regels heeft toegevoegd, is uw IPv6-firewall leeg. Een lege INPUT-chain met een standaard ACCEPT-beleid staat alles toe:

sudo ip6tables -L INPUT -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Die output toont de volledige valkuil in één overzicht. IPv4 is gefilterd, IPv6 accepteert al het verkeer.

3. Docker publiceert poorten direct langs uw firewall heen. Wanneer u docker run -p 8080:80 uitvoert, voegt Docker zijn eigen regels toe vóór die van UFW. Hierdoor is een gepubliceerde poort bereikbaar, zelfs wanneer ufw status aangeeft dat de poort is geblokkeerd. Bij moderne Docker-versies geldt hetzelfde voor IPv6. Waarom Docker UFW omzeilt en hoe u containerpoorten correct filtert legt het mechanisme en de oplossingen uit. Zie de basis van Docker Compose op een VPS voor informatie over hoe deze gepubliceerde poorten worden gedeclareerd.

4. UFW met IPv6 uitgeschakeld. UFW ondersteunt IPv6, maar alleen als dit expliciet is ingesteld. Controleer de instelling:

grep IPV6 /etc/default/ufw

Moderne Ubuntu-versies gebruiken IPV6=yes, waardoor UFW elke regel op beide stacks toepast. Als u IPV6=no ziet, afkomstig van een oude image of een verouderde handleiding, dan is elke UFW-regel die u heeft geschreven alleen van toepassing op IPv4 en blijft IPv6 onbeheerd.

Controleer exact wat u blootstelt

Gok niet. Meet het vanaf de buitenkant. Maak eerst een lijst van uw listeners en noteer elk exemplaar dat is gebonden aan :::

sudo ss -tlnp | grep '::'

Maak vervolgens vanaf een andere machine verbinding met het publieke IPv6-adres van de server en probeer een poort waarvan u denkt dat deze gesloten is:

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

Als dit een pagina of een banner retourneert, is de poort open op IPv6. Een gesloten poort geeft u Connection refused of een time-out. Deze twee fouten zijn niet hetzelfde signaal, en het verschil tussen geweigerd en time-out vertelt u of de host antwoordde en u wegstuurde, of dat een firewall uw pakket stilletjes heeft gedropt. Scan voor een volledig beeld het IPv6-adres met nmap vanaf een locatie buiten de server:

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

Elke poort die nmap rapporteert als open via IPv6 is een poort die het hele internet kan bereiken, ongeacht wat uw IPv4-scan liet zien. Het naast elkaar leggen van de IPv4- en IPv6-scans is de snelste manier om het gat te vinden: alles wat open staat op -6 maar gesloten is op IPv4, is een service die uw firewall mist.

Het gat dichten

Zorg dat UFW beide stacks dekt en stel standaard weigeren in. Bevestig de wijziging, stel vervolgens een standaardbeleid in om inkomend verkeer te weigeren en sta alleen toe wat u nodig heeft:

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

Als UFW al actief was toen u IPV6=yes omzette, wordt de wijziging pas van kracht nadat u sudo ufw reload uitvoert.

ufw status toont elke regel twee keer: één keer in de basisvorm en één keer met een (v6)-achtervoegsel. Wanneer u de (v6)-regels ziet, filtert UFW IPv6:

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

Als u iptables handmatig beheert, spiegel dan elke regel in ip6tables, of stap over op nftables. De inet-tabellen van nftables dekken IPv4 en IPv6 op één plek en elimineren deze hele categorie fouten. Een enkele nftables inet-filtertabel is de meest overzichtelijke oplossing wanneer u zelf regels schrijft. Als uw VPS op Rocky of AlmaLinux draait in plaats van Ubuntu, is er geen UFW om te configureren en is firewalld de interface die u in plaats daarvan beheert, welke zijn zone-regels tegelijkertijd op beide stacks toepast.

Bind services die niet openbaar hoeven te zijn aan de loopback. Een database, een beheerpaneel of een metrics-endpoint heeft zelden een publiek adres nodig. Bind deze aan 127.0.0.1 en ::1, zodat ze in de eerste plaats nooit op een routeerbaar adres luisteren. Stel voor Postgres listen_addresses = 'localhost' in. Bind een applicatieserver aan 127.0.0.1 en plaats er een reverse proxy voor. Het sluiten van de listener is effectiever dan het firewallen ervan, omdat er dan niets is om te bereiken.

Vertrouw er niet op dat UFW de gepubliceerde poorten van Docker bewaakt. Publiceer containerpoorten naar een specifiek adres in plaats van naar elke interface, bijvoorbeeld -p 127.0.0.1:8080:80, zodat de poort alleen bereikbaar is vanaf de host en alles wat u er bewust naartoe proxied. Wanneer een container echt publiek moet zijn, plaats deze dan achter een Traefik reverse proxy en publiceer alleen de proxy, niet elke app afzonderlijk.

Voeg IPv6-regels toe aan de firewall van uw provider, of accepteer dat dit niet uw firewall voor IPv6 is en laat UFW of nftables op de host die taak uitvoeren.

Controleer of de poort daadwerkelijk gesloten is

Voer na uw wijzigingen opnieuw dezelfde externe test uit:

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

De poort die voorheen antwoordde, zou nu een weigering of een time-out moeten geven. nmap zou de status nu als filtered of closed moeten rapporteren. Als een poort nog steeds open is, doorloop dan opnieuw de vier bovenstaande bronnen: een service die nog steeds gebonden is aan :: zonder actieve regel, een Docker-regel die voor UFW staat, of een firewall van de provider die IPv6 volledig negeert.

Het is nog veiliger om gevoelige services volledig buiten het publieke internet te houden. Plaats SSH en beheerpanelen achter een WireGuard VPN en blokkeer de poorten via de firewall zodat ze alleen reageren via de tunnel; de vraag over IPv6-blootstelling is dan niet langer van toepassing. Om brute-force scans op publieke services te vertragen, kunt u Fail2ban voor SSH inzetten in combinatie met een standaard-deny firewall.

Als het concept van poorten nieuw voor u is, lees dan eerst wat poorten zijn en hoe services luisteren als basisintroductie.

FAQ

Blokkeert UFW standaard IPv6?

Op een moderne Ubuntu 24.04-installatie wel. UFW leest IPV6=yes uit /etc/default/ufw en past elke regel toe op zowel IPv4 als IPv6, en ufw status toont de IPv6-regels met een (v6)-achtervoegsel. De valkuil ontstaat bij IPV6=no (van een oude image of een verouderde handleiding), wanneer u vertrouwt op een firewall van de provider die alleen IPv4 filtert, of wanneer Docker een poort publiceert buiten UFW om. Controleer de instelling met grep IPV6 /etc/default/ufw.

Hoe controleer ik wat mijn VPS blootstelt via IPv6?

Voer sudo ss -tlnp uit en noteer elke luisterende service waarvan het lokale adres begint met [::]; dit betekent dat deze antwoordt op elke IPv6-interface. Test vervolgens vanaf een andere machine het publieke IPv6-adres van de server direct met curl -6 -v http://[YOUR:IPV6::ADDR]:PORT/, of scan het met nmap -6 YOUR:IPV6::ADDR. Elke poort die open is bij de IPv6-scan maar gesloten bij IPv4, vormt een beveiligingslek.

Waarom kan ik de poort van mijn Docker-container bereiken terwijl UFW zegt dat deze geblokkeerd is?

Docker voegt zijn eigen firewallregels toe vóór die van UFW wanneer u een poort publiceert met -p. De gepubliceerde poort is daarom bereikbaar, ook al geeft ufw status aan dat deze is geweigerd. Dit gebeurt bij IPv4, en ook bij IPv6 wanneer de IPv6-ondersteuning van Docker is ingeschakeld. Publiceer naar een specifiek adres zoals -p 127.0.0.1:8080:80, of plaats de container achter een reverse proxy en publiceer alleen de proxy.

Heb ik nog steeds een IPv6-firewall nodig als mijn IPv4-firewall robuust is?

Ja. IPv4 en IPv6 zijn gescheiden netwerkstacks met eigen firewallregels. Een perfecte set IPv4-regels doet niets voor IPv6-verkeer. Als uw VPS een publiek IPv6-adres heeft, en dat hebben bijna alle VPS-servers, dan blijft elke service die luistert op :: bereikbaar via IPv6 totdat een IPv6-firewallregel of een loopback-binding dit blokkeert.

Hoe zorg ik ervoor dat een service alleen luistert op IPv4, of alleen op localhost?

Stel het bind-adres van de service in de eigen configuratie in. Bind aan 127.0.0.1 voor alleen IPv4-loopback, of 0.0.0.0 voor alle IPv4-adressen zonder IPv6-listener. Postgres gebruikt listen_addresses, SSH gebruikt ListenAddress, en de meeste applicatieservers bieden een host- of bind-vlag. Bevestig het resultaat met sudo ss -tlnp en controleer of de Local Address niet langer [::] toont.