Segmentarea rețelei și firewall în România

Ce închidem și ce lăsăm deschis

Pornim de la inventar: ce ascultă acum pe fiecare server și de ce. Aproape întotdeauna găsim servicii expuse din obișnuință, nu din necesitate: un port de bază de date deschis pentru un client care nu mai există, un panou de administrare accesibil din orice țară, un port de management uitat după o migrare. Lăsăm public doar 80 și 443, mutăm restul pe interfața privată sau în spatele VPN-ului, apoi confirmăm din exterior.

• Inventar al porturilor care ascultă, pe fiecare server
• Public rămân doar 80 și 443; SSH trece pe VPN sau pe bastion
• PostgreSQL, MySQL, Redis și MongoDB legate pe adresa privată
• Ieșiri filtrate, ca un server compromis să nu poată contacta orice destinație

Bune practici pe care le aplicăm pe firewall

Regulile de firewall se strică în timp, pe măsură ce echipele adaugă excepții temporare care rămân apoi permanente, uitate după o depanare. De aceea lucrăm cu o listă fixă și cu verificări repetate din exterior, nu cu o configurare făcută o singură dată. Lista rămâne în documentația ta, împreună cu rezultatul primei scanări, ca să ai o referință clară față de care se compară lunile următoare.

• Refuz implicit la intrare și ieșiri restrânse la destinațiile necesare
• Segmentare pe niveluri: margine, aplicație, date, fără traversare directă
• Nicio bază de date, Redis sau MongoDB pe IP public, în niciun mediu
• Audit automat de porturi din exterior, cu alertă la orice abatere
• Jurnalizare, blocare progresivă a tentativelor și reguli pe țară sau rețea unde se justifică

Segmentare pe niveluri, nu VLAN de birou

Materialele în română despre segmentare vorbesc de obicei de rețeaua de acasă sau de VLAN-uri de birou. Pe servere, împărțirea este alta: nivelul de margine, care primește trafic din internet, nivelul aplicație, care nu are voie să fie apelat direct din afară, și nivelul de date, care acceptă conexiuni doar de la aplicație. Fiecare trecere între niveluri este o regulă explicită, nu o consecință a faptului că mașinile sunt în același subnet.

• Marginea: proxy invers și terminare TLS, singura expusă public
• Aplicația: accesibilă doar dinspre margine, cu porturi interne
• Datele: acceptă conexiuni doar de la aplicație și de la administrare prin VPN

DDoS, blocări automate și orele incluse

Protecția DDoS L3/L4 este inclusă la nivel de rețea, deci volumetria nu îți ajunge la server. Pentru abuzurile la nivel de aplicație punem blocare progresivă cu Fail2ban sau CrowdSec și limite de cereri. Hardeningul și auditul de porturi intră în orele lunare: 1–8 ore pe VPS, 5–10 ore pe servere dedicate, în funcție de plan, și 10 ore pe GPU, cerute din panoul de client. Orele nu se reportează, iar ce trece peste cotă se facturează separat.

Cum lucrăm

1. Ceri lucrarea din panou

   Deschizi o cerere la Servicii DevOps, spui ce servere ai și ce trebuie să rămână accesibil din internet, apoi propui un termen.

2. Stabilim scopul și termenul

   Facem inventarul porturilor, scanăm din exterior, îți arătăm ce este expus fără motiv și convenim ordinea închiderilor.

3. Livrăm fără să rupem producția

   Aplicăm regulile pe niveluri, cu fereastră de revenire, mutăm serviciile pe adrese private, apoi rescanăm și comparăm rezultatele.

4. Predăm cu documentație

   Primești regulile aplicate, harta nivelurilor, raportul scanării din exterior și procedura pentru deschiderea unei excepții.

Cazuri de utilizare

Tehnologii

• nftables
• UFW
• Fail2ban
• CrowdSec
• nmap
• WireGuard
• Suricata
• Prometheus

Întrebări frecvente

• Cum securizez un VPS Linux?

  În ordine: actualizări automate de securitate, SSH pe chei și scos de pe internet, refuz implicit în firewall, servicii legate pe adresa privată, blocare progresivă a tentativelor și monitorizare. Apoi verifici din exterior ce mai răspunde, pentru că lista de porturi de pe server nu spune tot.

• Cum găsesc porturile deschise pe serverul meu?

  Local vezi ce ascultă cu ss sau lsof, dar imaginea reală o dă o scanare din afară, cu nmap, de pe altă rețea. Diferența dintre cele două liste este exact ceea ce filtrează, sau nu filtrează, firewallul. Noi facem scanarea la fiecare audit și îți lăsăm raportul.

• Ce este segmentarea rețelei și de ce contează?

  Este împărțirea infrastructurii în zone care comunică doar prin reguli explicite. Contează pentru că limitează consecințele: un atacator care compromite componenta publică nu ajunge automat la baza de date, ci se oprește la prima trecere între niveluri.

• Trebuie baza de date sau Redis să fie pe IP public?

  Nu, în niciun scenariu obișnuit. Aplicația le accesează pe adresa privată, iar administratorii prin VPN. O instanță Redis sau MongoDB fără parolă pe un IP public este găsită de scanere automate în câteva ore și folosită imediat.

• UFW sau nftables?

  UFW este un strat simplu peste nftables, bun pentru un server cu reguli puține. nftables direct îți dă control fin: seturi de adrese, filtrare pe ieșiri, contorizare, reguli per interfață. Pe configurațiile cu mai multe niveluri lucrăm în nftables, versionat ca orice altă configurație.

• Cum știu că regulile nu s-au relaxat între timp?

  Cu audit automat: scanăm periodic din exterior, comparăm cu lista aprobată și trimitem alertă la orice diferență. Așa se prind excepțiile temporare rămase deschise după o depanare, care sunt cauza cea mai frecventă a expunerilor accidentale.