Buitengesloten door ufw: zo herstelt u de toegang

Toegang herstellen

Als ufw u heeft buitengesloten van uw VPS, is de enige weg naar binnen de console van uw provider of de rescue-modus, aangezien er geen SSH-gebaseerde oplossing bestaat zodra de blokkeringsregel actief is. De kernel verwerpt uw pakket voordat sshd het ooit ziet, dus er is geen mogelijkheid om in te loggen of iets via het netwerk te herstellen. Open de console in het configuratiescherm van uw provider, log in bij de prompt en voer één commando uit.

sudo ufw disable

U zou Firewall stopped and disabled on system startup moeten zien. Nieuwe SSH-verbindingen werken binnen een seconde of twee weer. Niets van wat u heeft geconfigureerd gaat verloren: disable verwijdert de regels uit de kernel en schrijft ENABLED=no naar /etc/ufw/ufw.conf, terwijl uw regels op schijf blijven staan in /etc/ufw/user.rules, in afwachting van de volgende ufw enable.

Start niet opnieuw op in de hoop dat het probleem is opgelost. ufw start zichzelf bij het opstarten, dus ENABLED=yes betekent dat dezelfde regelset opnieuw wordt geladen voordat het netwerk actief is. Een herstart verandert niets aan een ufw-blokkering.

De console vereist een wachtwoord dat u mogelijk niet heeft

De webconsole (VNC of serieel) fungeert als een fysiek toetsenbord dat op de machine is aangesloten. Dit is geen netwerkpad, dus geen enkele firewallregel kan de toegang blokkeren. Er is echter een lokale login vereist, en dit is waar configuraties die uitsluitend op sleutels vertrouwen tekortschieten: als u nooit een wachtwoord heeft ingesteld voor uw sudo-gebruiker en root-login is vergrendeld, toont de console een prompt waarop u niet kunt reageren. Stel dit wachtwoord nu in, terwijl u nog toegang heeft via SSH: sudo passwd yourname. De meeste beheerpanelen kunnen ook het root-wachtwoord resetten, wat doorgaans een herstart vereist.

Als de console onbruikbaar is, start dan het rescue-systeem van uw provider op. Dit draait een afzonderlijk besturingssysteem waarbij uw schijf niet is aangekoppeld, waardoor u ufw van buitenaf kunt uitschakelen.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Voer eerst lsblk uit, omdat de root-partitie niet altijd /dev/vda1 is. Start opnieuw op naar het normale systeem; ufw blijft uitgeschakeld totdat u het handmatig weer inschakelt.

De minimale herstelprocedure

Werk in deze volgorde. De eerste vier stappen zijn veilig. De stap daarna is dat niet.

1. sudo ufw disable om de regels te verwijderen en uw toegang te herstellen.
2. sudo ufw show added om de toegevoegde regels weer te geven in de vorm van de commando's waarmee ze zijn aangemaakt. Dit werkt terwijl ufw inactief is, wat bij ufw status niet het geval is.
3. sudo sshd -T | grep -i '^port' om te bevestigen op welke poort sshd daadwerkelijk luistert. Dit geeft port 22 weer, tenzij u dit heeft gewijzigd.
4. sudo ufw allow 22/tcp, met gebruik van uw werkelijke poort, zodat de volgende inschakeling niet opnieuw tot een blokkade leidt.
5. sudo ufw enable, waarbij eerst een rollback wordt ingepland. Dit staat verderop op deze pagina.

Wat ufw reset daadwerkelijk doet

ufw reset is het laatste redmiddel, niet de eerste stap. Het schakelt de firewall uit, maakt een back-up van elk regelbestand en herstelt de standaardinstellingen naar het weigeren van inkomend verkeer en het toestaan van uitgaand verkeer. Het toont één back-upregel per bestand:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Na een reset zijn er geen toegangsregels meer actief. Voer dit commando daarom uit vanaf de console in plaats van via SSH, en voeg de SSH-regel toe voordat u de firewall opnieuw inschakelt. Deze back-ups zijn leesbare tekstbestanden. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 toont wat de oude regels waren; op deze manier kunt u een regelset herstellen die u niet had willen verwijderen.

Waar ufw zijn regels bewaart

Het lezen van de bestanden is betrouwbaarder dan vertrouwen op uw geheugen. Vijf paden bevatten de volledige status:

• /etc/ufw/user.rules en /etc/ufw/user6.rules: de regels die u heeft toegevoegd, in de volgorde waarin ze worden geëvalueerd.
• /etc/ufw/before.rules en /etc/ufw/after.rules, plus de 6-varianten: het framework dat ufw om uw regels heen plaatst, inclusief de accept-regel voor tot stand gebrachte verbindingen en de loopback-regels.
• /etc/default/ufw: het standaardbeleid en de IPV6-schakelaar.
• /etc/ufw/ufw.conf: ENABLED en het logniveau.
• /var/log/ufw.log: wat er is geblokkeerd, zodra logging is ingeschakeld.

ufw schrijft een kopie met tijdstempel van een bestand voordat het dit overschrijft, waardoor ls /etc/ufw/ volloopt met namen zoals user.rules.20260813_101500. Dat is uw ongedaan-maakgeschiedenis, en het is de moeite waard om deze te lezen voordat u wijzigingen ongedaan begint te maken.

Gebruik sudo ufw show raw, of sudo iptables -S en sudo ip6tables -S om te zien wat er in de kernel is geladen in plaats van wat er op de schijf staat. Op Ubuntu 22.04 en 24.04 zijn deze commando's de nft-gebaseerde versies, dus sudo nft list ruleset toont dezelfde regels in de nieuwere syntaxis.

Waarom verbrak het inschakelen van ufw mijn SSH-sessie?

Het standaardbeleid voor inkomend verkeer is deny. Het inschakelen van ufw zonder regel voor uw SSH-poort blokkeert elke nieuwe verbinding. ufw geeft u hiervoor een waarschuwing: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Het beantwoorden van y zonder dat er een SSH-toestemmingsregel is ingesteld, is de meest voorkomende oorzaak van alle problemen op deze pagina.

Het verwarrende aspect is de vertraging. /etc/ufw/before.rules accepteert pakketten met de status ESTABLISHED,RELATED voordat uw eigen regels worden bereikt, waardoor de sessie waarin u het commando typte normaal blijft werken. De blokkade treedt pas op bij de volgende verbinding, wat uren later kan zijn; tegen die tijd voelt de firewallwijziging niet meer gerelateerd aan het probleem. Open daarom altijd een tweede SSH-sessie en controleer of deze werkt voordat u de eerste sessie sluit.

Waarom werkten apt en DNS niet meer na een beleidswijziging?

sudo ufw default deny outgoing blokkeert uitgaande DNS-queries (domain name system) en uitgaand HTTP, waardoor naamresolutie stopt en pakketupdates falen. apt update rapporteert Temporary failure resolving 'archive.ubuntu.com'. Inkomende SSH werkt nog steeds, omdat de antwoorden daarop als ESTABLISHED worden gemarkeerd en door de firewallregels worden toegelaten. Hierdoor lijkt de firewall onschuldig, terwijl deze de oorzaak is.

Als u een beleid voor het weigeren van uitgaand verkeer wilt hanteren, sta dan toe wat de machine daadwerkelijk nodig heeft:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Zonder de laatste regel loopt de klok uit de pas. Een onjuiste tijd verstoort de validatie van TLS-certificaten (transport layer security), waardoor curl fouten geeft op basis van datums in plaats van poorten. Dit symptoom treedt pas dagen na de wijziging op. Daarom is een beleid voor het weigeren van uitgaand verkeer alleen geschikt voor machines die u actief monitort, niet voor een server die u eenmalig inricht.

Waarom komt mijn ufw-regel nooit overeen?

ufw evalueert gebruikersregels in volgorde en stopt bij de eerste overeenkomst. Een deny die na een algemene allow is toegevoegd, wordt nooit uitgevoerd, omdat de allow-regel het pakket al heeft afgehandeld. Toon de volgorde met nummers en voeg de regel vervolgens op de gewenste positie in.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp toont de regels die zouden worden geschreven zonder wijzigingen door te voeren. Dit is de veilige manier om een regel te controleren voordat deze actief wordt.

Een ander knelpunt bevindt zich in de applicatieprofielen. sudo ufw allow OpenSSH gebruikt het profiel in /etc/ufw/applications.d/openssh-server, en dat profiel staat voor poort 22. Als sshd luistert op 2222, opent de regel een poort die door niets wordt gebruikt. Hierdoor kunt u buitengesloten raken met een regelset die er correct uitziet. Gebruik het poortnummer zodra u de poort heeft verplaatst. De rest van de syntaxis wordt behandeld in de basisprincipes van de ufw-firewall voor een VPS.

Waarom verklaren de IPv4-regels niet wat ik zie?

Omdat de helft van het verkeer geen IPv4 is. Ubuntu levert IPV6=yes in /etc/default/ufw, en ufw onderhoudt vervolgens een parallelle v6-regelset in /etc/ufw/user6.rules. Een regel die is geschreven met een IPv4-adres, zoals ufw allow from 203.0.113.10 to any port 22, maakt helemaal geen v6-regel aan. Als uw VPS een AAAA-record heeft, geeft uw client de voorkeur aan IPv6 en treedt er een time-out op, terwijl ufw status een regel toont die correct lijkt. Test het verschil met ssh -4 user@host tegenover ssh -6 user@host. Als de eerste werkt en de tweede niet, dan zit het gat in de v6-regelset.

Het omgekeerde geval is slechter voor de beveiliging. Met IPV6=no beheert ufw ip6tables helemaal niet, waardoor het v6-beleid op de kernel-standaardwaarde ACCEPT blijft staan. Een poort waarvan u denkt dat deze gesloten is, reageert op het IPv6-adres, en geen enkel ufw-commando zal dit ooit vermelden. Controleer dit met sudo ip6tables -S en ss -tlnp, en lees hoe ufw omgaat met IPv6-poorten voor het volledige overzicht.

Waarom staat een Docker-poort open terwijl ufw deze blokkeert?

Docker publiceert een poort door DNAT-regels (destination network address translation) naar de nat-tabel te schrijven en een eigen chain in FORWARD in te voegen. De regels van ufw bevinden zich in het INPUT-pad. Verkeer naar een container wordt doorgestuurd in plaats van afgeleverd bij de host, waardoor het nooit de chain bereikt waarin uw deny-regel staat. docker run -p 5432:5432 is bereikbaar vanaf het internet, zelfs als ufw actief is en alles blokkeert.

sudo iptables -t nat -S DOCKER

De eenvoudigste oplossing is publiceren op de loopback-interface: -p 127.0.0.1:5432:5432 bindt de host-zijde aan 127.0.0.1, waardoor externe toegang onmogelijk is, ongeacht de instellingen in ufw. Docker-poorten publiceren met ufw behandelt de gevallen waarin de service wel publiek toegankelijk moet zijn.

Plan de rollback voordat u de regel toepast

Dit is de gewoonte die het werken met firewalls beheersbaar maakt. Plan vóór elke risicovolle wijziging de ongedaan-actie. Als de wijziging u buitensluit, herstelt de machine zichzelf binnen vijf minuten en hoeft u nooit de console te openen.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd voert Running timer as unit: ufw-rollback.timer uit. Voer nu uw wijziging door. Als u daarna nog steeds een nieuwe SSH-sessie kunt openen, annuleert u de rollback:

sudo systemctl stop ufw-rollback.timer

Als u die sessie niet kunt openen, wacht dan af. ufw wordt vanzelf uitgeschakeld en uw volgende poging zal verbinding maken. De klassieke shutdown -r +5-truc helpt niet bij ufw, omdat ufw bij het opstarten dezelfde regelset opnieuw laadt.

Zorg voor een tweede toegangsmethode

• Meld u eenmalig aan bij de console van de provider voordat u deze nodig heeft en controleer of het wachtwoord werkt. Een console die u nooit heeft getest, is geen back-up.
• Houd een tweede sudo-gebruiker aan met een eigen sleutel, zodat één beschadigd authorized_keys-bestand niet het einde van uw toegang betekent.
• Controleer of uw provider een netwerkfirewall in het paneel aanbiedt, los van ufw. Deze blokkeert dezelfde poorten en ufw status zal hier nooit melding van maken.
• Maak ufw allow from <your home address> niet uw enige SSH-regel als dat adres dynamisch is. Uw provider wijzigt dit 's nachts en u bent buitengesloten.

Het goedkoopste moment om dit alles te regelen is op een nieuwe server, gelijktijdig met de overige configuratiewerkzaamheden in de eerste tien minuten op een nieuwe VPS.

Refused of timed out geeft aan welke laag faalde

Connection refused betekent dat een pakket de server bereikte en dat er een TCP-reset werd teruggestuurd. Het netwerkpad is in orde, dus sshd is gestopt of luistert op een andere poort. Een firewall is zelden de oorzaak, omdat ufw standaard pakketten negeert (drop) in plaats van ze af te wijzen (reject).

Connection timed out betekent dat er helemaal geen reactie kwam. Dit is het kenmerk van een drop: ufw, een netwerkfirewall van de provider of een onjuist adres. Het correct interpreteren van deze twee fouten bespaart een uur aan giswerk, en het verschil tussen connection refused en timed out behandelt de overige gevallen.

Schakel logging in vóór de volgende wijziging

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Een geblokkeerd pakket ziet er als volgt uit:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 met uw eigen adres in SRC= is het bewijs dat ufw de blokkade veroorzaakt, en niet het netwerk of sshd. Op een minimale image zonder rsyslog bestaat /var/log/ufw.log niet en zijn dezelfde regels afkomstig van sudo journalctl -k | grep UFW. ufw past rate limiting toe op zijn eigen logregels; een ontbrekende regel is dus geen bewijs dat een pakket werd toegestaan.

Als u regels vindt die u nooit heeft toegevoegd

Een ruleset die uit zichzelf is gewijzigd, is geen firewallprobleem. Iemand met root-rechten heeft deze geschreven. Voer sudo grep ufw /var/log/auth.log uit om te zien welke sudo-commando's zijn uitgevoerd en onder welk account, en gebruik daarna last voor de aanmeldingen rond dat tijdstip. Als de accounts niet overeenkomen met iemand die u kent, stop dan met het debuggen van de firewall en doorloop in plaats daarvan een checklist voor een gecompromitteerde VPS. Het opnieuw inschakelen van een firewall op een server die door iemand anders wordt beheerd, verbergt het probleem alleen maar.

Alles weer herstellen

Zodra u de oorzaak kent, schakelt u ufw weer in op een manier die buitensluiting voorkomt. Sta uw werkelijke SSH-poort toe, plan de rollback, schakel de firewall in, open vervolgens een nieuwe SSH-sessie vanaf een andere terminal en controleer of de verbinding tot stand komt. Sluit de huidige sessie pas af nadat de nieuwe sessie succesvol is geopend. Laat logging een dag ingeschakeld; het logbestand toont u veel sneller wat u vergeten bent toe te staan dan het lezen van user.rules.

FAQ

Verwijdert ufw disable mijn regels?

Nee. disable verwijdert de ruleset uit de kernel en schrijft ENABLED=no naar /etc/ufw/ufw.conf. Uw regels blijven behouden in /etc/ufw/user.rules en /etc/ufw/user6.rules, en sudo ufw show added toont deze terwijl de firewall inactief is. ufw reset is het commando dat de regels wist; dit maakt eerst een back-up van elk bestand en toont een regel zoals Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Maakt een reboot van mijn VPS een ufw-lockout ongedaan?

Nee. ufw start bij het opstarten vanuit ENABLED=yes in /etc/ufw/ufw.conf, waardoor dezelfde regels worden geladen voordat het netwerk actief is en u opnieuw wordt buitengesloten. Een reboot helpt alleen nadat u ufw heeft uitgeschakeld, of nadat u dat bestand vanuit de rescue-modus heeft bewerkt met de schijf aangekoppeld. Gebruik de console van uw provider en voer daar sudo ufw disable uit.

Waarom is mijn Docker-container bereikbaar als ufw de poort blokkeert?

Docker schrijft zijn eigen DNAT- en FORWARD-regels voor elke gepubliceerde poort. Dat verkeer wordt doorgestuurd naar de container in plaats van afgeleverd bij de host, waardoor het nooit door de INPUT-chain gaat waar uw ufw deny-regel actief is. Publiceer op loopback met -p 127.0.0.1:5432:5432 als de poort alleen voor de host bedoeld is, en inspecteer wat Docker heeft geïnstalleerd met sudo iptables -t nat -S DOCKER.

Ik heb geen consolewachtwoord en geen rescue-modus. Wat zijn mijn opties?

De resterende opties liggen bij uw provider: een wachtwoordreset via het configuratiescherm, wat meestal de server herstart, of het koppelen van de schijf aan een andere instantie zodat u /etc/ufw/ufw.conf vanaf daar kunt bewerken. Neem contact op met de supportafdeling voordat u de server opnieuw installeert, aangezien een herinstallatie alle gegevens op de server wist. Zodra u weer toegang heeft, voert u sudo passwd yourname uit en test u de console-login eenmaal, zodat de volgende lockout u slechts twee minuten kost.