Am securizat propriul site dupa un audit real: ce am schimbat si de ce.

Bypaul.gheorghe

Idee / punct de vedere

Nu e un ghid generic „10 sfaturi Cloudflare” copiat de pe alte 50 de site-uri — e auditul real, cu rezultate reale, al propriului meu site. Punctul ăsta de vedere nu poate fi replicat de alt blog, pentru că e literalmente povestea configurației mele.

Draft

Am neglijat blogul ăsta multă vreme. Când m-am hotărât să-l reiau, primul lucru pe care mi l-am dorit n-a fost un articol nou, ci o verificare simplă: e sigură, de fapt, configurația din spatele lui? Domeniul e pe Cloudflare de câțiva ani, dar n-am mai verificat setările de securitate de la configurarea inițială. Așa că am făcut un audit complet — și am găsit atât lucruri bune, cât și câteva găuri despre care nu știam.

Ce am verificat

Am pornit de la ce e vizibil din exterior, fără să ating nimic:

  • Înregistrările DNS (A, AAAA, MX, TXT, NS) — ce rezolvă efectiv domeniul, la nivel public.
  • Comportamentul real al site-ului la o cerere HTTP simplă vs. HTTPS.
  • Header-ele de răspuns trimise de server (inclusiv cele de securitate).

Abia după asta am intrat în contul de Cloudflare, ca să confirm ce vedeam din exterior și să văd ce nu se vede public (certificate, reguli WAF, ruleset-uri).

Ce am găsit că funcționează deja bine

  • SSL activ și valid — certificat wildcard, emis automat, acoperă și subdomeniile.
  • Protecție de bază activă — regulile WAF gestionate de Cloudflare pentru planul gratuit, plus un ruleset de atenuare DDoS la nivel L7. Nu sunt configurate manual de mine, dar sunt active.
  • Autentificare email existentă — SPF și DKIM sunt valide, iar înregistrarea DMARC există (deși e setată pe modul doar raportare p=none, deci nu blochează activ spoofing-ul, reprezintă o bază bună).

Concluzia asta singură a meritat auditul: uneori „nu m-am atins de asta de mult” nu înseamnă „e nesigur” — dar nici nu poți ști fără să verifici.

Ce nu funcționa cum credeam

Aici au fost surprizele:

  1. http:// nu redirecționa spre https://. Un vizitator care tasta adresa fără „https” primea site-ul direct pe conexiune necriptată, în loc să fie redirecționat automat. Asta înseamnă că oricine intercepta acea primă cerere (rețea publică, Wi-Fi nesigur) putea vedea traficul necriptat, măcar pentru un moment.
  2. Niciun header HSTS. Fără Strict-Transport-Security, browserul nu „ține minte” să folosească mereu HTTPS pentru domeniul meu — deci protecția depindea complet de faptul că redirecționarea funcționa corect de fiecare dată (și, cum am văzut la punctul 1, nu funcționa).
  3. Adresa IP reală a serverului era vizibilă public. Deși site-ul principal are proxy-ul Cloudflare activ (deci IP-ul lui e ascuns), două înregistrări DNS conexe — cele pentru mail și FTP — nu pot trece prin proxy-ul Cloudflare (sunt protocoale pe care Cloudflare nu le rutează). Rezultat: oricine face un simplu lookup DNS pe acele subdomenii găsește adresa IP reală a serverului meu — și, cunoscând-o, poate încerca să se conecteze direct la server, ocolind complet protecția Cloudflare.

Ce am reparat

Primele două probleme au fost rezolvate direct din dashboard-ul Cloudflare, în câteva minute:

  • Always Use HTTPS — activat. Acum orice cerere HTTP primește un răspuns 301 către versiunea HTTPS.
  • HSTS — activat, dar nu cu setările maxime recomandate din prima. Am pornit cu o durată scurtă (o lună), fără să includ subdomeniile și fără preload. HSTS e genul de setare care, greșit configurată, poate face site-ul inaccesibil pentru vizitatori pe o perioadă lungă — deci pornești conservator, confirmi că totul merge stabil, și abia apoi crești durata treptat.

Ce am ales, conștient, să nu repar (încă)

A treia problemă — IP-ul expus prin mail/FTP — rămâne. Soluția corectă din punct de vedere tehnic ar fi ca serverul însuși să accepte conexiuni doar dinspre Cloudflare (fie printr-un certificat de validare — „Authenticated Origin Pulls” — fie printr-un firewall care permite doar IP-urile Cloudflare). Problema: asta necesită acces la nivelul serverului (WHM/root), pe care nu-l am — contul meu de găzduire e doar cPanel. Ar trebui să cer asta explicit de la furnizorul de găzduire.

Am decis să las asta pentru altă dată. Nu pentru că nu contează, ci pentru că am vrut să fiu sincer aici despre cum arată o decizie reală de securitate: nu totul se repară imediat, unele lucruri necesită cooperare din partea unui terț, și uneori alegi conștient să accepți un risc rezidual în loc să-l ignori sau să te prefaci că nu există.

Checklist — verifică și tu, dacă îți administrezi propriul site prin Cloudflare

  • [ ] curl -I [http://domeniul-tau.ro](http://domeniul-tau.ro) — primești un 301 către https://? Dacă nu, activează Always Use HTTPS din SSL/TLS → Edge Certificates.
  • [ ] curl -I [https://domeniul-tau.ro](https://domeniul-tau.ro) — există header-ul Strict-Transport-Security? Dacă nu, activează HSTS, dar pornește cu o durată scurtă.
  • [ ] Verifică toate subdomeniile din DNS (nu doar domeniul principal) — care au proxy Cloudflare activ și care nu? Cele fără proxy (de obicei mail, FTP) îți expun IP-ul real al serverului.
  • [ ] Dacă găsești IP-ul expus și ai acces WHM/root sau suport de la host, ia în calcul Authenticated Origin Pulls sau restricționarea firewall-ului la IP-urile Cloudflare.
  • [ ] Nu activa Preload pentru HSTS decât după ce ești complet sigur că totul funcționează stabil pe HTTPS — e o decizie greu reversibilă.

Notă privind datele și securitatea:

Securizarea conexiunilor prin Cloudflare face parte dintr-un efort mai larg de protejare a site-ului și a vizitatorilor noștri. Pentru a afla mai multe despre modul în care colectăm, stocăm și protejăm datele conform reglementărilor GDPR, te invităm să citești și noua noastră Politica de Confidențialitate.

Similar Posts