UFW er laget for at en brannmur skal kunne settes opp med tre kommandoer, og det klarer det. Problemet ligger et annet sted: ufw status viser hensikter, ikke resultat. En regel kan stå i listen og likevel ikke stenge noe som helst — av tre ulike grunner, og alle tre dukker opp jevnlig på virkelige servere.

En start der du ikke låser deg selv ute

Rekkefølgen på kommandoene betyr noe. Tillat SSH først, slå på etterpå:

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

ufw enable før SSH-regelen bryter din egen økt, og da gjenstår bare hostingleverandørens konsoll. Er serveren allerede satt opp og du er usikker — hold en andre forbindelse åpen, den overlever en mislykket endring.

Se på den detaljerte statusen; den korte skjuler standardpolicyen:

sudo ufw status verbose

Feil én: regelen finnes, men porten er åpen mot hele verden

Den vanligste linjen i fremmede oppsett:

sudo ufw allow 3306

Slik åpner man MySQL «for å kunne koble til hjemmefra» — og åpner den for hele internett. Det finnes to riktige varianter, og begge er bedre:

sudo ufw allow from 203.0.113.25 to any port 3306

eller, som er sikrere, å ikke slippe tjenesten ut i det hele tatt: bind-address = 127.0.0.1 i MySQL-konfigurasjonen og tilgang utenfra via en SSH-tunnel. Brannmuren er andre linje; den første er at tjenesten ikke lytter på en offentlig adresse. En UFW-regel kan slettes ved et uhell, mens bind-address ikke endrer seg selv.

Feil to: IPv6

En regel av typen ufw allow from 203.0.113.25 gjelder bare IPv4. Har serveren en IPv6-adresse — og det har de fleste VPS-er, påslått — forblir tjenesten tilgjengelig over den. Leverandøren delte ut adressen, du husker den ikke, skanneren kjenner til den.

Kontroller at v6-filtreringen i det hele tatt er på (IPV6=yes i /etc/default/ufw) og at tjenesten ikke lytter på :: unødvendig:

ss -tulpn | grep ':::'

Regler med uttrykkelig adresse må legges opp separat for begge protokollversjonene.

Feil tre: Docker

Den mest ergerlige. Docker publiserer porter ved å skrive egne regler i iptables-kjedene før dem UFW skriver til. Følgen er at en container startet med -p 5432:5432 er tilgjengelig fra internett selv om UFW viser Status: active og policyen deny incoming. Brannmuren er ikke ødelagt — turen kommer bare aldri til den.

Det bøtes ikke i UFW, men i måten porten publiseres på:

ports:
  - "127.0.0.1:5432:5432"

Binding til den lokale adressen er den enkleste og mest pålitelige løsningen. Utover skal bare det vende som faktisk betjener besøkende: som regel portene 80 og 443 på en omvendt proxy.

Regelrekkefølgen

UFW bruker den første regelen som passer, og stopper der. Derfor virker ikke et forbud som er lagt til etter en tillatelse: turen kommer aldri dit. Vi ser på nummereringen og setter inn på riktig sted:

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

Regler slettes etter nummer, men numrene forskyves etter hver sletting — fjern én om gangen og les listen på nytt.

Kontroll utenfra

Lokale kommandoer viser hva som er satt opp. Hva som faktisk ble av det, ses bare fra en annen maskin:

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

Hvilken som helst annen server eller hjemmemaskin duger. Det er den eneste kontrollen som ikke lyver, og den er verdt å gjøre etter hver merkbar omkonfigurering — særlig etter å ha installert noe som «setter opp nettverket for deg»: Docker, kontrollpaneler, VPN.

Loggene

Som standard skriver UFW nesten ingenting. Slik slås det på:

sudo ufw logging low

Oppføringene havner i /var/log/ufw.log — men bare hvis rsyslog finnes i systemet. På Debian 12 og Ubuntu 24.04 gjør det kanskje ikke det, og da går alt til systemd-journalen:

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

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

Hva man skal vente seg av en brannmur

UFW stenger det som ikke skal være tilgjengelig. Den gransker ikke innholdet i forespørsler til det som er åpent: port 443 er åpen for alle, og alt som kommer til nettstedet, kommer uhindret fram. Det er andre verktøys arbeid — en WAF på applikasjonsnivå, en IDS på trafikknivå. Brannmurens oppgave er mer beskjeden og viktigere: at listen over åpne porter stemmer med det du tror om den. Hvordan den listen ser ut sammen med de aktive reglene på én side, viser demonstrasjonen nedenfor.