UFW er lavet, for at en firewall kan sættes op med tre kommandoer, og det klarer det. Problemet ligger et andet sted: ufw status viser hensigter, ikke resultat. En regel kan stå på listen og alligevel ikke lukke noget som helst — af tre forskellige grunde, og alle tre dukker jævnligt op på virkelige servere.

En start hvor du ikke låser dig selv ude

Rækkefølgen af kommandoerne betyder noget. Tillad SSH først, slå til bagefter:

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

ufw enable før SSH-reglen afbryder din egen session, og så er der kun hostingudbyderens konsol tilbage. Er serveren allerede sat op, og du er usikker — hold en anden forbindelse åben, den overlever en mislykket ændring.

Se på den detaljerede status; den korte skjuler standardpolitikken:

sudo ufw status verbose

Fejl et: reglen findes, men porten er åben mod hele verden

Den hyppigste linje i fremmede opsætninger:

sudo ufw allow 3306

Sådan åbner man MySQL »for at kunne forbinde hjemmefra« — og åbner den for hele internettet. Der findes to rigtige varianter, og begge er bedre:

sudo ufw allow from 203.0.113.25 to any port 3306

eller, hvilket er sikrere, slet ikke at lukke tjenesten ud: bind-address = 127.0.0.1 i MySQL-konfigurationen og adgang udefra via en SSH-tunnel. Firewallen er anden linje; den første er, at tjenesten ikke lytter på en offentlig adresse. En UFW-regel kan slettes ved et uheld, mens bind-address ikke ændrer sig selv.

Fejl to: IPv6

En regel af typen ufw allow from 203.0.113.25 gælder kun IPv4. Har serveren en IPv6-adresse — og det har de fleste VPS'er, slået til — forbliver tjenesten tilgængelig over den. Udbyderen uddelte adressen, du husker den ikke, scanneren kender til den.

Kontrollér, at v6-filtreringen overhovedet er slået til (IPV6=yes i /etc/default/ufw), og at tjenesten ikke lytter på :: unødvendigt:

ss -tulpn | grep ':::'

Regler med udtrykkelig adresse skal oprettes separat for begge protokolversioner.

Fejl tre: Docker

Den mest ærgerlige. Docker publicerer porte ved at skrive egne regler i iptables-kæderne før dem, UFW skriver til. Følgen er, at en container startet med -p 5432:5432 er tilgængelig fra internettet, selv om UFW viser Status: active og politikken deny incoming. Firewallen er ikke i stykker — turen kommer bare aldrig til den.

Det afhjælpes ikke i UFW, men i måden porten publiceres på:

ports:
  - "127.0.0.1:5432:5432"

Binding til den lokale adresse er den enkleste og mest pålidelige løsning. Udad skal kun det vende, der rent faktisk betjener besøgende: som regel portene 80 og 443 på en omvendt proxy.

Regelrækkefølgen

UFW anvender den første regel, der passer, og standser der. Derfor virker et forbud tilføjet efter en tilladelse ikke: turen kommer aldrig dertil. Vi ser på nummereringen og indsætter det rigtige sted:

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

Regler slettes efter nummer, men numrene forskydes efter hver sletning — fjern én ad gangen, og læs listen forfra.

Kontrol udefra

Lokale kommandoer viser, hvad der er sat op. Hvad der rent faktisk blev af det, ses kun fra en anden maskine:

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

Enhver anden server eller hjemmecomputer duer. Det er den eneste kontrol, der ikke lyver, og den er værd at udføre efter hver mærkbar omkonfiguration — især efter at have installeret noget, der »sætter netværket op for dig«: Docker, kontrolpaneler, VPN.

Logfilerne

Som standard skriver UFW næsten ingenting. Sådan slås det til:

sudo ufw logging low

Posterne havner i /var/log/ufw.log — men kun hvis rsyslog findes i systemet. På Debian 12 og Ubuntu 24.04 gør det måske ikke det, og så går alt til systemd-journalen:

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

En tom /var/log/ufw.log betyder i sig selv ingenting — se i journalen først.

Hvad man skal forvente af en firewall

UFW lukker det, der ikke skal være tilgængeligt. Den undersøger ikke indholdet af forespørgsler til det, der er åbent: port 443 er åben for alle, og alt, hvad der kommer til hjemmesiden, kommer uhindret frem. Det er andre værktøjers arbejde — en WAF på applikationsniveau, en IDS på trafikniveau. Firewallens opgave er mere beskeden og vigtigere: at listen over åbne porte stemmer med det, du tror om den. Hvordan den liste ser ud sammen med de aktive regler på én side, viser demonstrationen nedenfor.