ModSecurity în cPanel reprezintă unul dintre nivelurile de protecție utilizate pentru filtrarea cererilor HTTP suspecte înainte ca acestea să ajungă la aplicația website-ului.
Pe infrastructura NameBox, această protecție lucrează împreună cu tehnologii precum LiteSpeed Web Server, Imunify360, CloudLinux și cPanel pentru a reduce riscul exploatării vulnerabilităților și al accesului neautorizat.
În anumite situații, însă, o cerere legitimă poate semăna cu un atac și poate fi blocată. Unul dintre simptomele întâlnite este eroarea 403 Forbidden.
În acest articol explicăm ce este ModSecurity, cum funcționează într-un server cPanel cu LiteSpeed și Imunify360, cum identifici un posibil false positive și de ce nu este recomandată dezactivarea permanentă a protecției.
Ce este ModSecurity?
ModSecurity este o tehnologie de tip Web Application Firewall – WAF utilizată pentru analizarea traficului HTTP și HTTPS care ajunge la website.
În loc să permită automat fiecare request, sistemul îl poate compara cu un set de reguli de securitate.
Procesul poate fi reprezentat simplificat astfel:
Vizitator ↓ Request HTTP / HTTPS ↓ LiteSpeed + ModSecurity / WAF ↓ Reguli de securitate ↓ Request permis sau blocat ↓ Website / WordPress / magazin online
Dacă o cerere corespunde unei reguli considerate periculoase, aceasta poate fi blocată înainte ca aplicația să o proceseze.
Ce tipuri de atacuri poate identifica ModSecurity?
Capacitatea exactă depinde de regulile instalate pe server, însă un WAF bazat pe ModSecurity poate analiza cereri asociate unor atacuri precum:
- SQL Injection;
- Cross-Site Scripting – XSS;
- Command Injection;
- Local File Inclusion;
- Remote File Inclusion;
- request-uri HTTP construite anormal;
- anumite încercări de exploatare a aplicațiilor web;
- upload-uri sau payload-uri suspecte.
ModSecurity nu „știe” automat dacă un utilizator este atacator. Acesta analizează request-ul pe baza regulilor de securitate existente.
Ce este un WAF?
WAF – Web Application Firewall este un sistem de protecție poziționat între utilizator și aplicația web.
Un firewall de rețea și un WAF nu sunt același lucru.
Un firewall clasic poate controla conexiuni și porturi precum:
22 → SSH 25 → SMTP 80 → HTTP 443 → HTTPS
Un WAF analizează ceea ce se transmite efectiv prin HTTP sau HTTPS.
De exemplu, două request-uri pot ajunge ambele pe portul 443, însă unul poate fi o accesare normală a unei pagini, iar celălalt poate conține un payload specific unui SQL Injection.
Cum funcționează ModSecurity împreună cu LiteSpeed?
Serverele shared NameBox utilizează LiteSpeed Web Server.
LiteSpeed include propriul motor de procesare compatibil cu regulile ModSecurity, astfel încât protecția WAF poate funcționa și într-un mediu LiteSpeed.
LiteSpeed este compatibil cu seturi de reguli precum:
- OWASP;
- Imunify360;
- Comodo;
- Atomicorp;
- reguli personalizate.
Într-un server cPanel, regulile ModSecurity sunt administrate în mod normal prin integrarea disponibilă în WHM, fără să fie necesară configurarea lor separat în interfața LiteSpeed.
Unde intervine Imunify360?
Imunify360 este o platformă de securitate pentru serverele de hosting și oferă mai multe componente de protecție.
Printre acestea se numără:
- Web Application Firewall;
- reguli de protecție pentru aplicațiile web;
- scanare malware;
- protecție împotriva anumitor atacuri automate;
- monitorizarea evenimentelor de securitate;
- protecție la nivelul fișierelor;
- mecanisme de reputație și filtrare.
Imunify360 poate utiliza un ruleset compatibil ModSecurity pentru identificarea request-urilor periculoase.
Astfel, într-o configurație cu LiteSpeed, fluxul poate fi simplificat astfel:
Internet ↓ LiteSpeed ↓ WAF / ModSecurity ↓ Reguli Imunify360 ↓ Aplicația website-ului
LiteSpeed procesează request-ul, iar regulile de securitate pot decide dacă acesta trebuie permis sau blocat.
ModSecurity și Imunify360 sunt același lucru?
Nu.
ModSecurity reprezintă motorul sau mecanismul prin care pot fi evaluate regulile WAF.
Imunify360 este o platformă mai complexă de securitate care poate furniza și utiliza reguli WAF, dar include și alte componente precum scanarea malware.
O comparație simplificată ar fi:
ModSecurity = motor de analiză WAF Imunify360 = platformă de securitate + reguli WAF + malware scanner + alte mecanisme
În infrastructurile moderne, motorul exact care execută regulile poate varia. Important pentru utilizator este că request-urile sunt analizate înainte de a ajunge la aplicație.
Ce rol are CloudLinux?
CloudLinux are un rol diferit față de ModSecurity și Imunify360.
Pe serverele shared NameBox, CloudLinux ajută la izolarea conturilor de găzduire și la controlul resurselor utilizate de fiecare cont.
De exemplu, poate controla sau monitoriza resurse precum:
- CPU;
- memorie RAM;
- I/O;
- IOPS;
- Entry Processes;
- numărul de procese.
CloudLinux nu înlocuiește ModSecurity.
Cele două tehnologii rezolvă probleme diferite:
LiteSpeed → server web și performanță ModSecurity → filtrarea request-urilor web Imunify360 → securitate WAF + anti-malware CloudLinux → izolare conturi și control resurse cPanel → administrarea serviciilor
Cum poate ModSecurity genera eroarea 403?
Atunci când o regulă consideră că request-ul reprezintă un risc, serverul poate răspunde cu:
403 Forbidden
Acest lucru înseamnă că serverul a înțeles cererea, dar accesul a fost refuzat.
De exemplu, o cerere de tip POST poate conține un text asemănător cu o comandă SQL:
SELECT * FROM users
Într-un formular destinat programatorilor sau într-un articol tehnic, acest text poate fi perfect legitim.
Totuși, într-un alt context poate semăna cu o tentativă SQL Injection.
Dacă o regulă este foarte strictă, request-ul legitim poate fi blocat. Această situație este cunoscută sub numele de:
false positive.
Ce este un false positive?
Un false positive apare atunci când sistemul de securitate identifică o activitate legitimă drept potențial atac.
De exemplu, problema poate apărea atunci când:
- salvezi un articol cu fragmente de cod;
- trimiți un formular care conține anumite caractere speciale;
- un plugin trimite un request POST complex;
- un page builder salvează cantități mari de HTML sau JavaScript;
- un API transmite JSON cu anumite expresii;
- un import trimite date care coincid cu o regulă de securitate.
Acest lucru nu înseamnă că ModSecurity trebuie dezactivat complet.
Trebuie identificată regula care a blocat request-ul și analizat dacă este într-adevăr un false positive.
Nu orice eroare 403 este cauzată de ModSecurity
Este foarte important să nu presupunem automat că fiecare eroare 403 este provocată de ModSecurity.
Un 403 Forbidden poate apărea și din alte motive.
Printre acestea se numără:
- permisiuni incorecte ale fișierelor;
- reguli .htaccess;
- restricții configurate în aplicație;
- blocarea adresei IP;
- protecții Imunify360;
- firewall;
- reguli personalizate de securitate;
- accesarea unui director protejat;
- pluginuri WordPress de securitate.
Din acest motiv trebuie analizată cauza înainte de modificarea configurației.
Cum îți dai seama dacă ModSecurity blochează request-ul?
Un indiciu important este modul în care apare problema.
De exemplu:
- website-ul funcționează normal;
- wp-admin funcționează;
- poți naviga între pagini;
- dar o anumită operațiune produce 403.
Exemplu:
Accesezi wp-admin → funcționează Editezi articolul → funcționează Apeși Update → 403 Forbidden
Într-o asemenea situație este posibil ca request-ul POST utilizat la salvare să fi fost blocat de o regulă WAF.
Totuși, confirmarea trebuie realizată în logurile serverului.
ModSecurity în cPanel
Dacă furnizorul permite această funcție, utilizatorul poate găsi ModSecurity în:
cPanel → Security → ModSecurity
Interfața permite activarea sau dezactivarea protecției pentru domeniile asociate contului.
cPanel recomandă explicit menținerea ModSecurity activ pentru toate domeniile și dezactivarea acestuia doar temporar atunci când este necesară depanarea unei probleme.
Este recomandat să dezactivezi ModSecurity?
Nu permanent.
Dezactivarea ModSecurity elimină regulile WAF aplicate domeniului și reduce nivelul de protecție al website-ului.
Dacă suspectezi un false positive, dezactivarea poate fi utilizată temporar ca test.
Un scenariu de diagnostic poate fi:
Operațiunea produce 403
↓
ModSecurity este dezactivat temporar
↓
Operațiunea este repetată
↓
Funcționează
↓
ModSecurity este reactivat
↓
Se verifică regula care a produs blocarea
Dacă problema dispare doar atunci când ModSecurity este dezactivat, avem un indiciu puternic că o regulă WAF trebuie investigată.
După test, protecția trebuie reactivată.
De ce nu trebuie lăsat ModSecurity dezactivat?
Un website poate conține vulnerabilități despre care administratorul nu știe încă.
De exemplu, un plugin WordPress poate avea o vulnerabilitate care permite trimiterea unui request malițios.
Un WAF poate bloca anumite tentative înainte ca acestea să ajungă la plugin.
Dacă ModSecurity este dezactivat permanent, acest nivel suplimentar de protecție nu mai există.
Din acest motiv, soluția corectă pentru un false positive este identificarea regulii și aplicarea unei excepții cât mai precise, nu dezactivarea întregului sistem de securitate.
Cum este identificată regula care a blocat request-ul?
La nivel de server, evenimentele ModSecurity pot fi analizate din WHM.
Administratorul serverului poate utiliza:
WHM → Security Center → ModSecurity Tools
Interfața permite verificarea evenimentelor generate de reguli.
Într-un astfel de eveniment pot exista informații precum:
- Rule ID;
- domeniul;
- URL-ul solicitat;
- IP-ul clientului;
- data și ora;
- motivul blocării;
- regula care a fost declanșată.
Aceste informații sunt mult mai utile decât dezactivarea aleatorie a protecțiilor.
Ce este Rule ID?
Fiecare regulă ModSecurity poate avea un identificator.
De exemplu:
Rule ID: 123456
Dacă o anumită regulă produce un false positive, administratorul poate analiza exact regula respectivă.
În funcție de situație, se poate decide:
- că request-ul este într-adevăr malițios;
- că aplicația trebuie modificată;
- că regula trebuie ajustată;
- că este necesară o excepție specifică.
Nu este recomandat să dezactivezi reguli fără să înțelegi ce protecție oferă.
Ce informații sunt utile când raportezi o eroare 403?
Dacă un request este blocat pe un serviciu NameBox, pentru identificarea rapidă a cauzei sunt utile următoarele informații:
- domeniul afectat;
- URL-ul exact unde apare problema;
- data și ora aproximativă;
- adresa IP de la care ai realizat operațiunea;
- operațiunea realizată înainte de apariția erorii;
- mesajul complet de eroare sau o captură de ecran.
Adresa IP poate fi verificată accesând:
https://ip.namebox.ro/
Ora exactă este foarte importantă deoarece permite corelarea request-ului cu evenimentul din logurile serverului.
Exemplu: WordPress afișează 403 când salvezi o pagină
Să presupunem că utilizezi WordPress și Elementor.
Poți:
- intra în wp-admin;
- deschide pagina;
- edita conținutul;
dar în momentul în care apeși:
Update
primești:
403 Forbidden
Nu trebuie să concluzionezi imediat că Elementor este defect.
Request-ul transmis de editor poate conține:
- HTML;
- CSS;
- JavaScript;
- JSON;
- URL-uri;
- fragmente de cod.
Una dintre aceste valori poate coincide cu o regulă de securitate.
Administratorul poate verifica Rule ID-ul asociat request-ului și poate stabili dacă avem un false positive.
Exemplu: formularul de contact returnează 403
Un alt scenariu poate apărea atunci când un utilizator introduce într-un formular un text care conține anumite expresii tehnice.
De exemplu:
Avem problema cu SELECT * FROM users
Pentru utilizator este doar text.
Pentru o regulă WAF poate semăna cu un fragment SQL.
Dacă regula consideră request-ul periculos, formularul poate fi blocat.
Acesta este motivul pentru care regulile trebuie analizate în context, nu eliminate fără verificare.
Imunify360 poate bloca și alte tipuri de activitate
Este important să nu asociem toate blocările cu ModSecurity.
Imunify360 include mai multe componente de securitate, iar o adresă IP sau un request poate fi afectat și de alte mecanisme.
Din acest motiv, atunci când investigăm un incident trebuie să diferențiem:
Request blocat de WAF IP blocat Fișier identificat ca malware Login brute force Regulă aplicație Firewall
Fiecare situație necesită o verificare diferită.
Ce legătură are Imunify360 cu fișierele infectate?
ModSecurity analizează în principal request-urile web.
Imunify360 include și un malware scanner care poate verifica fișierele din conturile de găzduire.
Astfel, cele două componente oferă protecție în puncte diferite:
Request malițios
↓
WAF / ModSecurity
↓
Website
Fișier malițios existent în cont
↓
Imunify360 Malware Scanner
Un website poate avea ModSecurity activ și totuși să fie compromis printr-o vulnerabilitate necunoscută, o parolă furată sau un plugin vulnerabil.
De aceea securitatea trebuie realizată pe mai multe niveluri.
LiteSpeed Cache nu este o funcție de securitate
LiteSpeed și LiteSpeed Cache sunt asociate frecvent cu website-urile WordPress, însă trebuie făcută o diferență importantă.
LiteSpeed Web Server este serverul web care poate procesa inclusiv regulile WAF.
LiteSpeed Cache este o soluție de cache și optimizare a performanței.
LSCache nu înlocuiește ModSecurity sau Imunify360.
Rolurile sunt diferite:
LiteSpeed Web Server → server web LSCache → cache și performanță ModSecurity / WAF → filtrare request-uri Imunify360 → protecție și malware CloudLinux → izolare și resurse
CloudLinux poate provoca eroare 403?
În mod obișnuit, atingerea limitelor CloudLinux nu generează un 403 ModSecurity.
Limitările de CPU, memorie, I/O sau Entry Processes pot duce mai degrabă la încetinirea website-ului, întreruperi temporare sau alte erori asociate resurselor.
Dacă primești 403, trebuie verificată separat cauza și nu trebuie presupus automat că limita de CPU sau RAM este responsabilă.
Cum verifici dacă problema este de la permisiuni?
O eroare 403 poate apărea și atunci când permisiunile fișierelor sau directoarelor sunt incorecte.
Pentru configurațiile obișnuite cPanel sunt utilizate frecvent:
Fișiere → 0644 Directoare → 0755
Dacă ai acces SSH, poți verifica un fișier cu:
ls -l fisier.php
sau un director cu:
ls -ld public_html
Permisiunile trebuie verificate înainte de a modifica ModSecurity.
Verifică și fișierul .htaccess
Regulile din:
.htaccess
pot limita accesul anumitor IP-uri, directoare sau URL-uri.
De exemplu, pot exista reguli precum:
Require all denied
sau alte condiții care generează un răspuns 403.
Din acest motiv, atunci când ModSecurity nu apare în loguri trebuie verificată și configurația aplicației.
Protecția pe mai multe niveluri în infrastructura NameBox
Pe infrastructura de găzduire NameBox sunt utilizate mai multe tehnologii care au roluri complementare.
| Tehnologie | Rol principal |
|---|---|
| LiteSpeed | Server web și procesarea traficului HTTP/HTTPS |
| ModSecurity / WAF | Analizarea și filtrarea request-urilor web |
| Imunify360 | WAF, protecție activă și scanare malware |
| CloudLinux | Izolarea conturilor și controlul resurselor |
| cPanel | Administrarea website-urilor și serviciilor |
| JetBackup / Synconix | Backup și restaurarea datelor |
| Arbor Networks | Protecție la nivel de infrastructură împotriva traficului DDoS |
Aceste tehnologii nu se înlocuiesc între ele. Fiecare protejează o componentă diferită a serviciului.
De ce este important backup-ul dacă avem Imunify360?
Nicio soluție de securitate nu poate garanta blocarea tuturor incidentelor.
Un website poate fi compromis din cauze precum:
- plugin vulnerabil;
- parolă compromisă;
- cont WordPress compromis;
- cod custom vulnerabil;
- acces FTP sau SSH compromis;
- vulnerabilitate nouă pentru care nu există încă o regulă.
Din acest motiv, backup-ul reprezintă un nivel separat de protecție.
Infrastructura NameBox utilizează soluții de backup precum JetBackup și Synconix, care permit restaurarea datelor atunci când există un punct de backup disponibil.
Ce să faci dacă ModSecurity blochează o operațiune legitimă?
Dacă suspectezi un false positive, nu dezactiva permanent protecția.
Urmează această ordine:
- notează URL-ul unde apare eroarea;
- notează ora exactă;
- verifică adresa IP de pe care ai realizat operațiunea;
- repetă operațiunea o singură dată pentru a reproduce problema;
- verifică dacă eroarea este 403;
- transmite informațiile echipei tehnice;
- administratorul verifică evenimentul și Rule ID-ul;
- dacă este false positive, se analizează o excepție specifică.
Este preferabilă eliminarea unei singure reguli pentru situația justificată sau configurarea unei excepții precise decât dezactivarea întregului WAF.
Ce să NU faci când apare un 403?
Nu recomandăm să:
- dezactivezi permanent ModSecurity;
- setezi permisiuni 777;
- ștergi reguli .htaccess fără să știi ce fac;
- dezactivezi Imunify360;
- adaugi IP-uri în whitelist fără să verifici motivul blocării;
- dezactivezi toate pluginurile de securitate fără diagnostic;
- modifici simultan mai multe sisteme de protecție.
Dacă modifici cinci componente simultan și problema dispare, nu vei mai ști care dintre acestea era cauza.
ModSecurity protejează și WordPress?
Da. ModSecurity funcționează la nivelul serverului web și poate analiza request-urile înainte ca acestea să ajungă la WordPress.
Prin urmare, protecția nu depinde de instalarea unui plugin WordPress.
Acest lucru este util deoarece un request malițios poate fi blocat înainte ca WordPress sau pluginul vulnerabil să îl proceseze.
Totuși, ModSecurity nu înlocuiește actualizarea platformei.
WordPress, pluginurile și temele trebuie menținute actualizate.
ModSecurity protejează și magazinele online?
Da. Request-urile către WooCommerce, PrestaShop sau alte platforme sunt analizate în același mod.
În cazul magazinelor online există însă multe operațiuni dinamice:
- checkout;
- plăți;
- API-uri;
- importuri;
- webhook-uri;
- administrarea produselor;
- filtre complexe.
Acest lucru înseamnă că este cu atât mai important să nu dezactivezi arbitrar regulile WAF.
Dacă apare un false positive, trebuie identificată exact cererea și regula care o blochează.
ModSecurity este doar o componentă a securității
Un website sigur nu se bazează pe o singură tehnologie.
Protecția corectă presupune mai multe niveluri:
HTTPS ↓ LiteSpeed ↓ WAF / ModSecurity ↓ Imunify360 ↓ Aplicație actualizată ↓ Parole sigure + 2FA ↓ CloudLinux ↓ Backup
Dacă unul dintre aceste niveluri nu este configurat corespunzător, celelalte pot reduce riscul, dar nu îl pot elimina complet.
ModSecurity trebuie menținut activ
ModSecurity în cPanel reprezintă un nivel important de protecție pentru website-urile găzduite pe server.
Împreună cu LiteSpeed și regulile de securitate Imunify360, acesta poate analiza request-urile HTTP și HTTPS și poate bloca anumite tentative înainte ca acestea să ajungă la aplicație.
Uneori poate apărea un false positive și o operațiune legitimă poate primi eroarea 403. În această situație, soluția corectă nu este dezactivarea permanentă a ModSecurity, ci identificarea request-ului și a regulii care a declanșat blocarea.
Pe infrastructura NameBox utilizăm cPanel, LiteSpeed, CloudLinux și Imunify360, alături de sisteme de backup și protecție la nivelul infrastructurii, astfel încât securitatea website-urilor să fie realizată pe mai multe niveluri.
Dacă un website găzduit la NameBox primește eroarea 403 Forbidden în timpul unei anumite operațiuni, transmite echipei tehnice URL-ul, ora apariției problemei și adresa IP de pe care ai realizat accesarea. Aceste informații ne ajută să verificăm logurile și să identificăm dacă blocarea provine de la ModSecurity sau de la o altă componentă de securitate.