Az UFW azért készült, hogy a tűzfal három paranccsal beállítható legyen, és ezt teljesíti is. A gond máshol van: az ufw status a szándékokat mutatja, nem az eredményt. Egy szabály szerepelhet a listán, és közben semmit nem zár le — három különböző okból, és mindhárom rendszeresen előfordul valódi szervereken.

Olyan indulás, amelynél nem zárod ki magad

A parancsok sorrendje számít. Előbb engedélyezd az SSH-t, aztán kapcsold be:

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

Az ufw enable az SSH engedélyezése előtt megszakítja a saját munkamenetedet, és utána már csak a szolgáltató konzolja marad. Ha a szerver már be van állítva, és bizonytalan vagy, tarts nyitva egy második kapcsolatot, az túléli a sikertelen módosítást.

A részletes állapotot kell nézni, a rövid elrejti az alapértelmezett irányelvet:

sudo ufw status verbose

Első hiba: a szabály megvan, a port viszont az egész világnak nyitva áll

A leggyakoribb sor idegen konfigurációkban:

sudo ufw allow 3306

Így nyitják meg a MySQL-t „hogy otthonról is lehessen csatlakozni” — és megnyitják az egész internetnek. Két helyes változat van, és mindkettő jobb:

sudo ufw allow from 203.0.113.25 to any port 3306

vagy, ami megbízhatóbb, egyáltalán ne engedd ki a szolgáltatást: bind-address = 127.0.0.1 a MySQL konfigurációjában, a kívülről való hozzáférés pedig SSH-alagúton keresztül. A tűzfal a második vonal; az első az, hogy a szolgáltatás ne figyeljen nyilvános címen. Egy UFW-szabály véletlenül törölhető, a bind-address viszont magától nem változik meg.

Második hiba: IPv6

Az ufw allow from 203.0.113.25 típusú szabály csak az IPv4-re vonatkozik. Ha a szervernek van IPv6-címe — és a legtöbb VPS-nek van, méghozzá bekapcsolva —, a szolgáltatás azon keresztül elérhető marad. A szolgáltató kiosztotta a címet, te nem emlékszel rá, a szkenner viszont tud róla.

Ellenőrizd, hogy a v6-szűrés egyáltalán be van-e kapcsolva (IPV6=yes az /etc/default/ufw fájlban), és hogy a szolgáltatás nem figyel-e feleslegesen a :: címen:

ss -tulpn | grep ':::'

A kifejezett címet tartalmazó szabályokat mindkét protokollverzióhoz külön kell létrehozni.

Harmadik hiba: Docker

A legbosszantóbb. A Docker úgy publikál portokat, hogy saját szabályait az iptables-láncokba korábban írja be, mint ahová az UFW ír. Ennek eredményeként a -p 5432:5432 kapcsolóval indított konténer elérhető az internetről, akkor is, ha az UFW Status: active állapotot és deny incoming irányelvet mutat. A tűzfal közben nem hibás — csak nem kerül rá sor.

Ezt nem az UFW-ben kell orvosolni, hanem abban, ahogyan a portot publikálod:

ports:
  - "127.0.0.1:5432:5432"

A helyi címhez kötés a legegyszerűbb és legmegbízhatóbb megoldás. Kifelé csak annak szabad néznie, ami valóban a látogatókat szolgálja ki: általában egy fordított proxy 80-as és 443-as portja.

A szabályok sorrendje

Az UFW az első illeszkedő szabályt alkalmazza, és ott meg is áll. Ezért az engedélyezés után hozzáadott tiltás nem hat: odáig nem jut el a sor. Megnézzük a számozást, és a megfelelő helyre szúrjuk be:

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

A szabályokat szám szerint törlöd, de a számok minden törlés után elcsúsznak — egyesével törölj, és olvasd újra a listát.

Ellenőrzés kívülről

A helyi parancsok azt mutatják, mi van beállítva. Hogy ebből valójában mi lett, az csak másik gépről látszik:

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

Bármely másik szerver vagy otthoni gép megteszi. Ez az egyetlen ellenőrzés, amely nem hazudik, és minden észrevehetőbb átkonfigurálás után érdemes elvégezni — különösen olyasmi telepítése után, ami „magától beállítja a hálózatot”: Docker, vezérlőpanelek, VPN.

Naplók

Alapból az UFW szinte semmit nem ír. Így kapcsolható be:

sudo ufw logging low

A bejegyzések a /var/log/ufw.log fájlba kerülnek — de csak akkor, ha van a rendszerben rsyslog. Debian 12-n és Ubuntu 24.04-en lehet, hogy nincs, és akkor minden a systemd naplózójába megy:

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

Egy üres /var/log/ufw.log önmagában semmit nem jelent — előbb a naplózóba nézz.

Mit várj a tűzfaltól

Az UFW azt zárja le, aminek nem szabad elérhetőnek lennie. A nyitva hagyottakra érkező kérések tartalmát nem vizsgálja: a 443-as port mindenki előtt nyitva áll, és minden, ami a webhelyre érkezik, akadály nélkül megérkezik. Ez más eszközök dolga — WAF alkalmazásszinten, IDS forgalmi szinten. A tűzfal feladata szerényebb és fontosabb: hogy a nyitott portok listája megegyezzen azzal, amit róla gondolsz. Hogy néz ki ez a lista az aktív szabályokkal együtt egyetlen oldalon, azt az alábbi bemutató mutatja.