UFW är gjort för att en brandvägg ska kunna ställas in med tre kommandon, och det klarar det. Problemet ligger någon annanstans: ufw status visar avsikter, inte resultat. En regel kan stå i listan och ändå inte stänga någonting alls — av tre olika skäl, och alla tre dyker upp regelbundet på riktiga servrar.

En start där du inte låser ute dig själv

Ordningen på kommandona spelar roll. Tillåt SSH först, slå på sedan:

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

ufw enable före SSH-regeln bryter din egen session, och därefter återstår bara hostingleverantörens konsol. Är servern redan uppsatt och du är osäker — håll en andra anslutning öppen, den överlever en misslyckad ändring.

Titta på den utförliga statusen; den korta döljer standardpolicyn:

sudo ufw status verbose

Fel ett: regeln finns, men porten är öppen mot hela världen

Den vanligaste raden i främmande konfigurationer:

sudo ufw allow 3306

Så öppnar man MySQL ”för att kunna ansluta hemifrån” — och öppnar den för hela internet. Det finns två riktiga varianter, och båda är bättre:

sudo ufw allow from 203.0.113.25 to any port 3306

eller, vilket är säkrare, att inte släppa ut tjänsten alls: bind-address = 127.0.0.1 i MySQL-konfigurationen och åtkomst utifrån via en SSH-tunnel. Brandväggen är andra linjen; den första är att tjänsten inte lyssnar på en publik adress. En UFW-regel går att radera av misstag, medan bind-address inte ändrar sig själv.

Fel två: IPv6

En regel av typen ufw allow from 203.0.113.25 gäller enbart IPv4. Har servern en IPv6-adress — och det har de flesta VPS:er, påslagen — förblir tjänsten nåbar över den. Leverantören delade ut adressen, du minns den inte, skannern känner till den.

Kontrollera att v6-filtreringen alls är påslagen (IPV6=yes i /etc/default/ufw) och att tjänsten inte lyssnar på :: i onödan:

ss -tulpn | grep ':::'

Regler med uttrycklig adress måste läggas upp separat för båda protokollversionerna.

Fel tre: Docker

Det mest förargliga. Docker publicerar portar genom att skriva egna regler i iptables-kedjorna före dem som UFW skriver till. Följden är att en container som startats med -p 5432:5432 är nåbar från internet även om UFW visar Status: active och policyn deny incoming. Brandväggen är inte trasig — turen kommer bara aldrig till den.

Det botas inte i UFW utan i hur porten publiceras:

ports:
  - "127.0.0.1:5432:5432"

Bindning till den lokala adressen är den enklaste och pålitligaste lösningen. Utåt ska bara det vetta som faktiskt betjänar besökare: i regel portarna 80 och 443 på en omvänd proxy.

Regelordningen

UFW tillämpar den första regel som passar och stannar där. Därför fungerar inte ett förbud som lagts till efter ett tillstånd: turen kommer aldrig dit. Vi tittar på numreringen och lägger in på rätt plats:

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

Regler raderas efter nummer, men numren flyttas efter varje radering — ta bort en i taget och läs om listan.

Kontroll utifrån

Lokala kommandon visar vad som är inställt. Vad som faktiskt blev av det syns bara från en annan maskin:

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

Vilken annan server eller hemdator som helst duger. Det är den enda kontroll som inte ljuger, och den är värd att göra efter varje märkbar omkonfiguration — särskilt efter att ha installerat något som ”ställer in nätverket åt dig”: Docker, kontrollpaneler, VPN.

Loggarna

Som standard skriver UFW nästan ingenting. Så här slås det på:

sudo ufw logging low

Posterna hamnar i /var/log/ufw.log — men bara om rsyslog finns i systemet. På Debian 12 och Ubuntu 24.04 kanske det inte gör det, och då går allt till systemd-journalen:

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

En tom /var/log/ufw.log betyder i sig ingenting — titta i journalen först.

Vad man ska förvänta sig av en brandvägg

UFW stänger det som inte ska vara nåbart. Den granskar inte innehållet i förfrågningar till det som är öppet: port 443 är öppen för alla, och allt som kommer till sajten kommer fram obehindrat. Det är andra verktygs arbete — WAF på applikationsnivå, IDS på trafiknivå. Brandväggens uppgift är blygsammare och viktigare: att listan över öppna portar stämmer med vad du tror om den. Hur den listan ser ut tillsammans med de aktiva reglerna på en sida visar demonstrationen nedan.