Firewall-ul de rețea decide dacă o conexiune pe portul 443 e permisă. WAF-ul citește ce e înăuntrul acelei conexiuni: URL-ul, antetele, corpul cererii, și blochează tiparele de atac înainte să ajungă la aplicație.
Firewall-ul de rețea lucrează cu adrese IP, porturi și protocoale: permite 443, refuză 3306. Nu știe ce e o cerere HTTP și lasă să treacă orice ajunge pe portul permis, inclusiv o interogare SQL injectată într-un formular de login. WAF-ul se așază în fața aplicației și decodifică cererea: recunoaște un ' OR 1=1 într-un parametru, un script în câmpul de comentariu, o încercare de a citi /etc/passwd prin traversare de directoare. Cele două filtre lucrează împreună, pe niveluri diferite.
Ai nevoie de WAF când aplicația conține cod pe care nu îl controlezi complet, ca plugin-urile WordPress, când vulnerabilitățile publicate sunt exploatate în ore și tu ai nevoie de zile ca să actualizezi, sau când expui un API public. WAF-ul cumpără timp, nu rezolvă cauza: vulnerabilitatea din cod rămâne și un atacator răbdător găsește un payload pe care regula nu îl prinde. Fals-pozitivele sunt costul, de aceea pornești în detecție, citești logurile o săptămână și excluzi regulile care lovesc trafic legitim.
| Tip WAF | Unde rulează | Avantaj principal | Limită |
|---|---|---|---|
| La nivel de hosting | Pe serverul de hosting, pentru toate conturile | Activ implicit, fără configurare | Reguli generice, ajustare limitată |
| Pe server (ModSecurity + OWASP CRS) | În Nginx sau Apache, în fața aplicației | Control complet asupra regulilor | Cere întreținere și citirea logurilor |
| Cloud (schimbare DNS) | În rețeaua furnizorului, înainte de server | Absoarbe și DDoS L7, actualizat central | Traficul trece prin terț; originul trebuie ascuns |
# /etc/modsecurity/modsecurity.conf
SecRuleEngine DetectionOnly
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsec_audit.logSecRule REQUEST_URI "@beginsWith /api/filter" \
"id:10001,phase:1,pass,nolog,ctl:ruleRemoveById=942100"O vulnerabilitate într-un plugin de facturare a fost publicată luni; actualizarea a apărut joi. WAF-ul de la nivel de hosting a blocat între timp încercările de exploatare, vizibile în loguri din marți. Fără WAF, fereastra ar fi fost de trei zile.
Regula generică pentru SQL injection bloca un endpoint legitim care primea interogări de filtrare cu operatorii AND și OR. Echipa a exclus regula doar pentru acel endpoint, a adăugat validare de schemă pe corpul cererii și a păstrat restul setului activ.
Plugin-ul rulează în PHP, deci cererea a ajuns deja la aplicație și consumă resurse. WAF-ul de la nivel de hosting sau din serverul web blochează înainte ca PHP să pornească. Cele două se completează: WAF pentru filtrare, plugin pentru 2FA și limitarea încercărilor de login.
Inspecția adaugă un timp mic la fiecare cerere, de obicei imperceptibil față de timpul aplicației. Un set de reguli foarte mare sau inspecția corpurilor de cereri mari poate deveni vizibilă; excluzi din inspecție încărcările de fișiere și endpoint-urile de volum mare după ce le-ai verificat.
Da, pentru că SQL injection, traversarea de directoare și deserializarea nesigură lovesc la fel de bine un API JSON. Ajustezi regulile pentru formatul tău: excluzi regulile pentru HTML și XSS dacă API-ul nu returnează HTML și adaugi validare de schemă pe corpul cererii.
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.