UFW a fost creat pentru ca un firewall să se configureze din trei comenzi, și cu asta se descurcă. Problema este în altă parte: ufw status arată intențiile, nu rezultatul. O regulă poate figura în listă și totuși să nu închidă absolut nimic — din trei motive diferite, și toate trei apar regulat pe servere reale.

Un început în care nu te blochezi singur

Ordinea comenzilor contează. Mai întâi permite SSH, apoi activează:

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

ufw enable înainte de permiterea SSH îți rupe propria sesiune, iar apoi rămâne doar consola furnizorului. Dacă serverul este deja configurat și nu ești sigur, ține deschisă o a doua conexiune, ea supraviețuiește unei modificări nereușite.

Trebuie privită starea detaliată, cea scurtă ascunde politica implicită:

sudo ufw status verbose

Prima greșeală: regula există, dar portul este deschis pentru toată lumea

Cea mai frecventă linie din configurațiile străine:

sudo ufw allow 3306

Așa se deschide MySQL „ca să te poți conecta de acasă” — și se deschide pentru tot internetul. Variantele corecte sunt două și amândouă sunt mai bune:

sudo ufw allow from 203.0.113.25 to any port 3306

sau, ceea ce este mai sigur, să nu scoți serviciul deloc în afară: bind-address = 127.0.0.1 în configurația MySQL, iar accesul din exterior printr-un tunel SSH. Firewallul este a doua linie; prima este ca serviciul să nu asculte pe o adresă publică. O regulă din UFW poate fi ștearsă din greșeală, în timp ce bind-address nu se schimbă de la sine.

A doua greșeală: IPv6

O regulă de tipul ufw allow from 203.0.113.25 se referă doar la IPv4. Dacă serverul are adresă IPv6 — iar majoritatea VPS-urilor o au și este activă — serviciul rămâne accesibil pe ea. Furnizorul a alocat adresa, tu nu ți-o amintești, scanerul știe de ea.

Verifică dacă filtrarea v6 este în general activată (IPV6=yes în /etc/default/ufw) și dacă serviciul nu ascultă inutil pe :::

ss -tulpn | grep ':::'

Regulile cu adresă indicată explicit trebuie create separat pentru ambele versiuni de protocol.

A treia greșeală: Docker

Cea mai supărătoare. Docker publică porturi scriindu-și propriile reguli în lanțurile iptables înaintea celor în care scrie UFW. Rezultatul este că un container pornit cu -p 5432:5432 este accesibil din internet, chiar dacă UFW arată Status: active și politica deny incoming. Firewallul nu este stricat — pur și simplu nu se ajunge la el.

Asta nu se rezolvă în UFW, ci în modul în care se publică portul:

ports:
  - "127.0.0.1:5432:5432"

Legarea la adresa locală este soluția cea mai simplă și mai sigură. În afară trebuie să dea doar ceea ce deservește cu adevărat vizitatorii: de obicei porturile 80 și 443 ale unui proxy invers.

Ordinea regulilor

UFW aplică prima regulă potrivită și se oprește acolo. De aceea o interdicție adăugată după o permisiune nu are efect: nu se ajunge la ea. Ne uităm la numerotare și inserăm în locul potrivit:

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

Regulile se șterg după număr, dar numerele se deplasează după fiecare ștergere — șterge câte una și recitește lista.

Verificarea din exterior

Comenzile locale arată ce este configurat. Ce a ieșit de fapt se vede doar de pe altă mașină:

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

Este suficient orice alt server sau calculatorul de acasă. Este singura verificare care nu minte și merită făcută după fiecare reconfigurare importantă — mai ales după instalarea a ceva care „își configurează singur rețeaua”: Docker, panouri de control, VPN.

Jurnalele

Implicit, UFW nu scrie aproape nimic. Se activează astfel:

sudo ufw logging low

Înregistrările ajung în /var/log/ufw.log — dar numai dacă în sistem există rsyslog. Pe Debian 12 și Ubuntu 24.04 s-ar putea să nu existe, și atunci totul merge în jurnalul systemd:

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

Un /var/log/ufw.log gol nu înseamnă nimic în sine — uită-te mai întâi în jurnal.

Ce se poate aștepta de la un firewall

UFW închide ceea ce nu trebuie să fie accesibil. Nu analizează conținutul cererilor către ceea ce este deschis: portul 443 este deschis tuturor, iar tot ce ajunge la site ajunge nestingherit. Aceasta este treaba altor instrumente — WAF la nivel de aplicație, IDS la nivel de trafic. Sarcina firewallului este mai modestă și mai importantă: ca lista porturilor deschise să coincidă cu ce crezi tu despre ea. Cum arată această listă împreună cu regulile active pe o singură pagină arată demonstrația de mai jos.