Un atac DDoS nu sparge nimic: umple linkul sau ocupă toate resursele serverului până când clienții reali nu mai pot intra. Semnul tipic e un site brusc lent sau inaccesibil, fără nicio eroare în aplicație.
La nivelurile L3 și L4 atacatorul trimite pachete brute: inundații UDP, amplificare prin servere DNS sau NTP deschise, SYN flood. Scopul e să umple linkul sau tabela de conexiuni; nu contează ce rulează pe server. La nivelul L7 atacatorul trimite cereri HTTP care par legitime, dar lovesc paginile costisitoare: căutări, coșuri, autentificări. Un trafic modest poate ocupa toate procesele PHP sau conexiunile la baza de date. Cele două tipuri cer apărări diferite.
Un firewall local decide ce pachete acceptă după ce au ajuns deja pe placa de rețea. Dacă linkul e saturat, decizia vine prea târziu: traficul legitim nu mai încape, indiferent de reguli. Atenuarea volumetrică se face în amonte, în rețeaua furnizorului sau într-un centru de scrubbing care trimite mai departe doar traficul curat. Local rămâi responsabil de L7: limitezi cererile pe IP, servești din cache paginile publice, blochezi boții.
Dacă firma ta intră sub OUG 155/2024, transpunerea NIS2 aprobată prin Legea 124/2025, un DDoS care întrerupe un serviciu esențial poate fi incident semnificativ, cu alertă timpurie la DNSC în 24 de ore, notificare în 72 de ore și raport final într-o lună. Înregistrarea la DNSC, reglementată prin Ordinul 1/2025, e obligația entității, nu a furnizorului de hosting. Indiferent de NIS2, o firmă care emite e-Factura are nevoie de acces la sistemul ANAF în termenul legal, deci disponibilitatea are consecințe fiscale.
| Nivel | Exemplu de atac | Ce epuizează | Cine atenuează |
|---|---|---|---|
| L3 (rețea) | Inundație ICMP, amplificare DNS/NTP | Banda linkului | Furnizorul de hosting, scrubbing, Anycast |
| L4 (transport) | SYN flood, UDP flood | Tabela de conexiuni, banda | Furnizorul de hosting, filtrare în amonte |
| L7 (aplicație) | HTTP flood pe căutare sau login | CPU, procese PHP, conexiuni DB | WAF, CDN, rate limiting, cache pe server |
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
}limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;Un atac L7 pe pagina de căutare a ocupat toate conexiunile la baza de date în ziua cu cele mai multe comenzi. Cache pe rezultatele de căutare și rate limiting pe IP au redus încărcarea, iar filtrarea de boți din WAF a blocat restul.
Un client cu un script defect a generat mii de cereri pe secundă, cu efect identic unui DDoS de aplicație. Limitele per cheie API și răspunsurile 429 au rezolvat problema fără să blocheze restul clienților.
Te uiți la trafic și la conexiuni înainte de a te uita la cod. Un salt brusc de pachete sau de cereri din multe IP-uri, cu servere care răspund lent la orice, indică DDoS. O eroare de aplicație produce de obicei mesaje în loguri și afectează anumite pagini, nu toată mașina.
Un CDN cu protecție absoarbe volumul și filtrează L7 pentru traficul care trece prin el. Dacă IP-ul original al serverului e cunoscut, atacatorul îl lovește direct și ocolește CDN-ul. Restricționezi accesul direct la origin la IP-urile CDN-ului și ai nevoie oricum de protecție L3/L4 la furnizor.
Dacă intri sub OUG 155/2024 și atacul a produs o întrerupere semnificativă, notifici DNSC în termenele legale. Dacă atacul a fost o diversiune pentru un acces la date personale, se aplică și obligațiile GDPR față de ANSPDCP. În toate cazurile, documentezi incidentul intern.
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.