Protecție DDoS pentru website-uri: Metode eficiente pentru proprietarii de site-uri

Protecție DDoS pentru website-uri: Metode eficiente pentru proprietarii de site-uri, scris pentru firme mici și mijlocii care nu au echipă de securitate, dar au un site de care depind. Atacurile de indisponibilitate au devenit ieftine (servicii de „stres” la zeci de euro) și frecvente; în România, DNSC raportează atacuri zilnice asupra instituțiilor și firmelor, iar site-urile mici sunt lovite ca daune colaterale sau ca șantaj. Vestea bună: pentru majoritatea atacurilor care ating un site mic, protecția gratuită sau ieftină este suficientă, dacă e configurată înainte.

Ghidul explică tipurile de atac, cum recunoașteți unul, ce configurați dinainte (Cloudflare, cache, limitare, firewall), ce faceți în timpul atacului și ce ține de furnizorul de găzduire.

Protecție DDoS pentru website-uri: Metode eficiente pentru proprietarii de site-uri

Tipurile de atac, pe scurt

• Volumetrice (nivelul 3 și 4): inundă legătura de rețea a serverului cu pachete; se măsoară în Gbps. Nu le puteți opri de pe server; le oprește rețeaua din față (Cloudflare, furnizorul).
• De protocol: exploatează TCP (SYN flood) și epuizează tabelele de conexiuni; parțial atenuate de nucleu și firewall, complet de un serviciu din față.
• La nivelul aplicației (nivelul 7): mii de cereri HTTP „legitime” spre paginile cele mai costisitoare (căutare, filtre, coș, wp-login.php, xmlrpc.php); serverul cade din cauza procesorului și a bazei de date, nu a rețelei. Sunt cele mai frecvente pe site-urile mici și cele pe care le puteți combate și dumneavoastră.

Atac sau vârf de trafic?

Un atac de nivel 7 arată, în jurnalul de acces, ca sute de cereri pe secundă spre aceleași adrese, de la multe adrese IP sau de la puține, cu user agent identic sau aleatoriu, fără referer, fără să încarce imaginile și stilurile paginii (un browser real le cere). Un vârf de trafic real (o mențiune în presă, o campanie) vine cu referer, cu resurse încărcate, cu adrese IP din România și cu pagini diverse. Cum citiți jurnalul este în ghidul despre jurnalele de erori și acces; Resource Usage din cPanel arată limita atinsă, iar instantaneele arată adresele cerute.

Ce configurați dinainte

1. Cloudflare, planul gratuit

Cloudflare pune rețeaua sa între vizitatori și server: schimbați nameserverele domeniului, activați proxy-ul (norul portocaliu) pe înregistrările A și CNAME ale site-ului, și traficul trece prin Cloudflare, care absoarbe atacurile volumetrice și de protocol fără limită, inclusiv pe planul gratuit. Condiții: adresa IP reală a serverului nu trebuie să fie vizibilă (înregistrări DNS neproxyate precum mail sau ftp o expun; un atacator care o știe ocolește Cloudflare), iar serverul ar trebui să accepte trafic web doar de la adresele Cloudflare (regulă în firewall). Configurarea cu cPanel este în ghidul despre Cloudflare și cPanel. Atenție la setarea implicită care blochează roboții AI și la modul de securitate care poate afișa verificări roboților legitimi; ambele se ajustează.

2. Cache pentru pagini

Un atac de nivel 7 costă serverul doar dacă fiecare cerere rulează PHP și baza de date. Cu cache de pagină (pe server, prin LiteSpeed Cache sau un modul, și la Cloudflare, prin reguli de cache pentru HTML), o cerere spre o pagină cache-uită costă aproape nimic, iar serverul rezistă la de zece ori mai multe cereri. Paginile care nu pot fi cache-uite (coș, cont, căutare) sunt cele de protejat cu limitare de ritm. Configurarea cache-ului pentru WordPress este în ghidul despre configurarea cache-ului WordPress.

3. Limitarea ritmului (rate limiting)

Cloudflare oferă, și pe planul gratuit, o regulă de limitare: de exemplu, cel mult 10 cereri în 10 secunde de la aceeași adresă spre /wp-login.php, /xmlrpc.php, /?s= sau spre paginile de căutare și filtre; peste, blocare temporară. Pe server, ModSecurity și modulele de securitate fac același lucru pentru autentificare; fail2ban, pe servere proprii, blochează adresele după jurnal, cum arătăm în ghidul despre fail2ban.

4. Reguli de firewall la Cloudflare

Regulile personalizate (WAF Custom Rules, cinci gratuite) blochează sau verifică traficul după țară, după user agent, după cale. Combinații pe care le folosim: verificare (challenge) pentru cererile spre autentificare din afara României; blocare pentru user agent-uri goale sau de biblioteci (python-requests, curl) pe paginile publice; verificare pentru orice cerere spre căutarea internă peste un prag. Nu blocați țări întregi pe paginile publice ale unui site care vrea clienți din străinătate.

5. Dezactivarea a ce nu folosiți

XML-RPC (ținta clasică pentru amplificare pe WordPress), API-ul REST pentru utilizatori neautentificați acolo unde nu e nevoie, paginile de căutare internă indexabile, endpoint-urile de export. Fiecare este o pagină costisitoare pe care un atacator o poate cere de mii de ori; măsurile sunt în ghidul despre protecția paginii de autentificare și în cel despre dezactivarea funcțiilor WordPress inutile.

6. Serverul și firewall-ul lui

Pe servere proprii: SYN cookies active (implicit pe distribuțiile moderne), limite de conexiuni pe adresă în Nginx sau Apache (limit_conn, mod_evasive), firewall care acceptă trafic web doar de la Cloudflare dacă îl folosiți, și resurse dimensionate cu rezervă. Ce nu ajută: „mai mult RAM” pe un server care cade din cauza PHP-ului; ajută cache-ul.

În timpul atacului

1. Confirmați (jurnal, Resource Usage sau htop): ce adrese, ce pagini, cât.
2. Dacă aveți Cloudflare: activați Under Attack Mode din pagina de prezentare a zonei. Fiecare vizitator primește o verificare de câteva secunde; roboții simpli nu trec. Dezactivați-l când atacul se oprește, fiindcă afectează și vizitatorii reali și roboții de indexare.
3. Adăugați o regulă de firewall pentru tiparul atacului (calea, user agent-ul, țara), dacă e clar.
4. Fără Cloudflare: blocați adresele sau intervalele din IP Deny Manager sau din firewall, cum arătăm în ghidul despre limitarea accesului pe IP; pentru sute de adrese, nu ține, și treceți la pasul următor.
5. Anunțați furnizorul de găzduire, cu ora, adresele și paginile; are unelte de rețea pe care nu le aveți.
6. Puneți o pagină statică în locul celor costisitoare (coș, căutare) dacă atacul le vizează, până trece.
7. Notați totul: ora de început și de sfârșit, volumul, tiparul, ce a funcționat. Următorul atac seamănă cu acesta.

Nu plătiți „răscumpărarea” cerută în e-mailurile de amenințare cu DDoS; majoritatea sunt cacealma, iar plata invită la următoarea cerere. Raportați la DNSC și la poliție dacă atacul are cerere de bani.

Ce ține de furnizorul de găzduire

Protecția de rețea (filtrarea volumetrică în centrul de date), izolarea conturilor (un atac asupra altui cont de pe același server vă afectează și pe dumneavoastră, fără izolare), regulile globale ale firewall-ului de aplicație și limitele pe cont. Întrebați furnizorul ce protecție DDoS are, dacă e inclusă și ce se întâmplă cu contul dumneavoastră în timpul unui atac asupra serverului (unii suspendă contul atacat „ca să protejeze serverul”, exact ce vrea atacatorul). Un furnizor care nu poate răspunde este un motiv de mutare, la fel ca cel descris în articolul despre licențele cPanel frauduloase.

Un atac văzut de aproape

Un magazin online, într-o marți la 11 dimineața: site-ul răspundea în 20 de secunde, apoi deloc. Resource Usage arăta procesele PHP la limită; jurnalul, 400 de cereri pe secundă spre pagina de căutare internă, cu termeni aleatorii, de la aproximativ 900 de adrese IP din toată lumea, user agent de Chrome vechi, fără resurse încărcate. Site-ul avea Cloudflare, dar căutarea nu era cache-uită (nici nu putea fi). Under Attack Mode a oprit valul în două minute; apoi o regulă de limitare pe /?s= (5 cereri pe 10 secunde) și una de verificare pentru user agent-ul respectiv au permis dezactivarea modului de atac după o oră. Atacul a continuat, ineficient, încă șase ore. Fără Cloudflare configurat dinainte, aceeași după-amiază ar fi însemnat mutarea DNS-ului sub atac, cu ore de propagare.

Greșeli care fac atacurile ușoare

• Adresa IP a serverului expusă prin înregistrări DNS neproxyate sau prin antete de e-mail; atacatorul lovește direct.
• Paginile costisitoare (căutare, filtre, calendar) accesibile fără limită și indexabile.
• Serverul care acceptă trafic web de la oricine, deși Cloudflare e în față.
• Under Attack Mode lăsat pornit săptămâni: roboții de indexare și o parte din vizitatori sunt blocați.
• Nicio monitorizare: atacul e descoperit de clienți.

Planul pentru site-uri care nu își permit să cadă

• Cloudflare Pro sau Business: firewall de aplicație gestionat, limitare avansată, protecție de nivel 7 automată.
• Server cu rezervă de resurse și cache agresiv; separarea aplicației de baza de date.
• Monitorizare externă cu alertă la un minut și o persoană de contact la furnizor.
• Pagina de mentenanță statică pregătită, cu datele de contact, servită de la Cloudflare când serverul nu răspunde.
• Copii de siguranță curente, fiindcă atacurile DDoS însoțesc uneori o tentativă de intruziune.
• Un exercițiu pe an: cine face ce în prima oră.

Contextul atacurilor din România și cifrele DNSC sunt în articolul despre atacurile DDoS zilnice în România, iar pașii de după orice incident, de la dovezi la comunicare, în ghidul despre răspunsul la incidente de securitate. Pentru un site obișnuit, cele șase configurări de mai sus, făcute într-o după-amiază, acoperă ce vedem în practică.

Surse

• Documentația Cloudflare, fundamente: configurarea zonei, proxy-ul, modul Under Attack și regulile de firewall.
• Documentația cPanel, ModSecurity: firewall-ul de aplicație pe conturile cPanel.