Un VPS nou vine cu toate serviciile instalate ascultând pe toate interfețele. Firewall-ul e regula simplă care spune: tot ce nu e web sau SSH rămâne închis spre internet, iar baza de date nu iese niciodată din mașină sau din rețeaua privată.
Când politica e „permite tot, blochează ce știu”, fiecare serviciu nou instalat devine automat public: un Redis fără parolă, un MongoDB cu autentificare oprită, un panou pe 8080. Scanerele le găsesc în minute. Cu „refuză tot, permite ce știu” greșeala se inversează: un serviciu uitat rămâne invizibil până când îl deschizi conștient. UFW face asta cu două comenzi și ține regulile lizibile; sub el rulează nftables sau iptables.
MySQL pe 3306 și PostgreSQL pe 5432 nu au ce căuta expuse pe internet, nici cu parolă. Le configurezi să asculte pe 127.0.0.1 sau pe adresa din rețeaua privată, iar accesul de la distanță îl faci prin tunel SSH sau VPN. Dacă aplicația rulează pe alt server, deschizi portul doar pentru IP-ul acelui server. Docker merită atenție: publicarea unui port cu -p ocolește regulile UFW, deci legi porturile la 127.0.0.1 sau la interfața privată.
O bază de date cu date personale accesibilă de pe internet e exact situația pe care art. 32 GDPR o consideră lipsă de măsuri tehnice adecvate, iar ANSPDCP a sancționat astfel de cazuri în România. Pentru entitățile înregistrate la DNSC sub OUG 155/2024, segmentarea rețelei și controlul accesului intră în măsurile de gestionare a riscului prevăzute de art. 11 din OUG 155/2024. Un firewall documentat, cu reguli explicabile, e o probă simplă în orice audit.
| Port / serviciu | Expunere spre internet | Cum îl accesezi | Regulă UFW |
|---|---|---|---|
| 22 SSH | Da, cu rate limiting și sursă restrânsă | Chei SSH, VPN | ufw limit 22/tcp |
| 80 HTTP | Da, pentru redirect și validare ACME | Public | ufw allow 80/tcp |
| 443 HTTPS | Da | Public | ufw allow 443/tcp |
| 3306 MySQL / 5432 PostgreSQL | Nu | localhost, tunel SSH, rețea privată | ufw allow from 10.0.0.5 to any port 5432 |
| 6379 Redis | Nu | localhost, rețea privată | fără regulă publică |
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbosesudo ufw allow from 10.0.0.5 to any port 5432 proto tcpss -tulpn | grep LISTENUn coleg schimbase listen_addresses pe '*' pentru a se conecta de acasă și uitase să revină. Baza era accesibilă de oriunde, protejată doar de parolă. Firewall-ul cu refuz implicit a acoperit greșeala, iar accesul de la distanță s-a mutat pe tunel SSH.
Redis publicat prin Docker cu -p 6379:6379 a ocolit UFW și a ajuns pe internet fără parolă. A fost găsit de un scaner în aceeași zi, cu sesiunile clienților citibile. Legarea pe 127.0.0.1 și o parolă au închis expunerea.
UFW e o interfață peste nftables sau iptables, suficientă pentru un VPS cu câteva servicii, și ține regulile lizibile. Treci la nftables direct când ai nevoie de seturi mari de adrese, reguli pe interfețe multiple sau performanță la trafic mare. Nu le amesteci pe aceeași mașină.
Poți, cu ufw allow from adresa ta, dar IP-ul de acasă se schimbă și regula rămâne. Mai sigur e tunelul SSH sau VPN-ul: baza de date rămâne pe localhost, iar tu te conectezi prin canalul criptat, cu aceeași cheie pe care o folosești deja pentru SSH.
Da. Firewall-ul din panoul furnizorului filtrează înainte de mașină și e util ca prim strat. Cel de pe server știe ce ascultă efectiv, protejează și traficul din rețeaua privată și rămâne cu tine dacă muți serverul. Le configurezi coerent, cu aceeași listă de porturi.
Un server de producție e atacat automat din primele minute după ce primește IP public, indiferent cât de mic e proiectul. Ghidul ordonează controalele după impact, de la accesul SSH până la răspunsul la incident, cu legislația din România care se aplică. Fiecare temă are o pagină dedicată, cu răspuns scurt, exemple și configurări.