Găzduire cu WAF: ghid complet, atacuri reale și SLA

Există o întrebare pe care o auzim aproape la fiecare client nou: „De ce m-ar ataca cineva pe mine? Am doar un site mic.” Răspunsul sincer este că nimeni nu te atacă pe tine. Te atacă un script. Un script care nu știe cine ești, nu știe ce vinzi, nu știe câți vizitatori ai și nici nu îl interesează. Știe doar că pe adresa ta rulează WordPress, că ai un anumit plugin într-o anumită versiune și că versiunea aceea are o vulnerabilitate publicată de câteva zile.

Articolul acesta este un ghid complet despre găzduirea cu WAF (Web Application Firewall): cum arată un atac real în 2026, ce se întâmplă efectiv pe server în timpul unei compromiteri, ce poate și ce nu poate face un firewall de aplicații, cum se citește un SLA de remediere și cum îți dai seama dacă un furnizor de hosting te protejează cu adevărat sau doar are cuvântul „securitate” pe pagina de prezentare.

Nu scriem din manual. Scriem din ce am văzut în ultimele luni pe serverele pe care le administrăm: webshell-uri ascunse în subdomenii uitate, plugin-uri de donații transformate în uși din spate, conturi de administrator care au supraviețuit unei schimbări de parolă și zeci de conturi false create peste noapte de boți. Numele clienților rămân confidențiale, dar detaliile tehnice sunt reale. Dacă vrei direct ofertele, le găsești pe pagina Găzduire cu Securitate WAF. Dacă vrei să înțelegi de ce există, citește mai departe.

Cum arată, de fapt, un atac asupra unui site WordPress în 2026

Imaginea clasică a unui hacker care stă noaptea în fața ecranului și încearcă să intre pe site-ul tău nu mai are aproape nicio legătură cu realitatea. Marea majoritate a compromiterilor pe care le remediem sunt complet automatizate. Nimeni nu a ales site-ul respectiv. A fost pur și simplu pe o listă.

Ciclul de viață al unei vulnerabilități

Totul pornește de la o vulnerabilitate descoperită într-un plugin, o temă sau, mai rar, în nucleul WordPress. Un cercetător de securitate o găsește, o raportează dezvoltatorului, iar dezvoltatorul publică o versiune corectată. Până aici, totul e în regulă. Problema începe în momentul în care vulnerabilitatea devine publică: apare într-o bază de date de CVE-uri, într-un raport de securitate sau într-un articol tehnic.

Din acel moment începe o cursă. De o parte sunt proprietarii de site-uri, care trebuie să afle că există o actualizare, să o instaleze și să verifice că site-ul funcționează în continuare. De cealaltă parte sunt atacatorii, care citesc aceleași rapoarte, scriu un exploit (de multe ori în câteva ore), îl integrează într-un scanner automat și îl lansează asupra a milioane de adrese IP. În practică, atacatorii câștigă cursa aproape întotdeauna, pentru că ei au nevoie de câteva ore, iar un proprietar de site obișnuit are nevoie de zile sau săptămâni ca să ajungă la butonul de actualizare.

Am văzut asta concret în vara acestui an. O vulnerabilitate critică într-un plugin de donații foarte folosit a fost publicată la sfârșitul lui august. În primele patru zile după publicare, pe un singur site pe care îl găzduiam au fost create automat 63 de conturi de utilizator false, fiecare fiind o încercare a unui scanner de a verifica dacă exploit-ul funcționează. Nu era un atac țintit. Era internetul întreg testat metodic, adresă cu adresă.

Ce caută boții

Un scanner automat modern nu mai încearcă la întâmplare. Are o listă de verificări foarte precise: ce versiune de WordPress rulează site-ul, ce plugin-uri sunt instalate (se pot deduce ușor din codul sursă al paginii și din căile fișierelor CSS și JavaScript), ce temă este activă, dacă formularul de login răspunde la cereri, dacă există fișiere de configurare lăsate accidental la vedere, dacă API-ul REST expune numele utilizatorilor. Pe baza acestor informații, scannerul decide în câteva milisecunde ce exploit să încerce.

Tocmai de aceea mărimea site-ului nu contează. Un blog personal cu 30 de vizitatori pe zi și un magazin online cu zeci de mii de comenzi pe lună apar identic în ochii unui scanner: o adresă, o versiune de plugin, un răspuns „vulnerabil” sau „nevulnerabil”.

Ce vor atacatorii de la site-ul tău

Dacă nu te vizează personal, ce câștigă atacatorul din compromiterea unui site mic? Destul de mult, de fapt. Site-ul tău are câteva lucruri valoroase pentru el:

• Reputația domeniului în Google. Un domeniu vechi, cu istoric curat, este perfect pentru a găzdui pagini de spam SEO. Atacatorul injectează mii de pagini cu produse contrafăcute, cazinouri sau farmacii online și profită de încrederea pe care Google o acordă domeniului tău.
• Resursele serverului. Procesorul poate fi folosit pentru minare de criptomonede, iar conexiunea la internet pentru a lansa atacuri asupra altor site-uri.
• Adresa de email și reputația serverului de mail. Un site compromis poate trimite zeci de mii de mesaje de phishing, iar blocarea care urmează lovește toate emailurile tale legitime.
• Datele vizitatorilor. Adrese de email, date de contact, iar în cazul magazinelor, tentative de interceptare a datelor introduse în formularele de plată.
• Un punct de sprijin. Un webshell pe site-ul tău este o ușă prin care atacatorul poate reveni oricând, poate vinde accesul altcuiva sau îl poate folosi ca punct de plecare către alte conturi de pe același server.

Niciunul dintre aceste scopuri nu depinde de cât de important ești. Toate depind de un singur lucru: dacă site-ul tău poate fi compromis.

Trei incidente reale, spuse din interior

Cea mai bună modalitate de a înțelege de ce găzduirea cu WAF administrat arată așa cum arată este să vezi ce se întâmplă atunci când lipsește sau atunci când un singur strat de apărare nu este suficient. Mai jos sunt trei incidente pe care le-am investigat și remediat în ultimele luni. Detaliile tehnice sunt reale; datele de identificare ale clienților au fost eliminate.

Incidentul 1: formularul de contact care a devenit poartă de intrare

Totul a început cu o alertă din scanarea automată pe care o rulăm în fiecare noapte pe servere. Scriptul găsise, pe 24 de conturi de găzduire diferite, același fișier: un panou de control PHP care servea drept instrument de SEO cloaking. Pe scurt, cloaking înseamnă că site-ul arată normal pentru tine și pentru vizitatorii tăi, dar le arată altceva roboților Google: pagini de spam, linkuri către site-uri dubioase, texte în limbi pe care nu le vorbește nimeni din firmă. Proprietarul nu observă nimic. Află abia când traficul organic se prăbușește sau când cineva îi trimite o captură de ecran cu rezultatele din Google pline de caractere japoneze sub numele firmei lui.

Primul lucru pe care l-am verificat a fost dacă avem de-a face cu un singur cont compromis care se răspândea în celelalte. Nu era cazul: conturile aparțineau unor proprietari diferiți, fără legătură între ei. Numitorul comun era altul: majoritatea site-urilor afectate foloseau același constructor de pagini popular, în versiunea Pro. Investigând mai departe, am găsit o vulnerabilitate critică de tip arbitrary file upload în widgetul de formular al acelui plugin, exploatată în masă începând cu jumătatea lui august. Formularul de contact, cel pe care clienții tăi îl folosesc ca să îți ceară o ofertă, putea fi folosit pentru a încărca pe server un fișier PHP executabil.

Aici apare prima lecție importantă. La momentul investigației, majoritatea site-urilor erau deja actualizate la versiunea corectată. Proprietarii făcuseră, tehnic vorbind, „ce trebuia”. Numai că actualizarea închide ușa pentru viitor, dar nu scoate afară pe cine a intrat deja. Webshell-urile fuseseră plantate în fereastra de câteva zile dintre publicarea vulnerabilității și instalarea actualizării și au rămas pe server, liniștite, după ce plugin-ul a fost reparat.

A doua lecție a venit câteva săptămâni mai târziu. O scanare extinsă a găsit aceeași familie de panouri de cloaking și în locuri pe care nu le verificasem inițial: subdomenii cu directoare proprii, în afara folderului principal al site-ului. Un subdomeniu de test uitat, o instalare veche de monitorizare, o versiune de dezvoltare a unui site pe care nimeni nu o mai deschisese de un an. Atacatorii iubesc exact aceste colțuri, pentru că nu le verifică nimeni. Am modificat imediat scanarea ca să citească directoarele reale ale fiecărui domeniu și subdomeniu direct din configurația serverului, nu doar folderul standard.

Ce ar fi schimbat un WAF în acest scenariu? În fereastra critică, o regulă care inspectează fișierele încărcate prin formulare și blochează orice conținut PHP deghizat (un fișier „imagine” care conține de fapt cod executabil) ar fi oprit exploit-ul înainte ca fișierul să ajungă pe disc, indiferent dacă plugin-ul fusese sau nu actualizat. Acesta este conceptul de virtual patching, despre care vorbim pe larg mai jos.

Incidentul 2: plugin-ul de donații și cele 63 de conturi fantomă

Al doilea caz a pornit tot de la o alertă automată: pe un site al unei organizații care folosea un plugin popular de donații online, apăreau la fiecare câteva ore foldere ascunse cu nume care imitau un instrument legitim de administrare WordPress. Numele aveau sufixe aleatorii, diferite de fiecare dată. În interiorul lor, fișiere PHP cu nume banale, gen „log” sau „compat-loader”, care păreau parte din sistem.

Nu erau. Erau webshell-uri bazate pe eval: primeau o comandă codificată hexazecimal prin prima variabilă a unei cereri POST, o decodificau și o executau direct pe server. Unul dintre ele se dădea drept componentă a unui alt sistem de management de conținut, ca să pară inofensiv la o privire superficială.

Cauza a fost o vulnerabilitate de execuție de cod de la distanță, fără autentificare, cu scorul maxim de gravitate (10 din 10), în plugin-ul de donații. Adică oricine de pe internet, fără cont și fără parolă, putea rula cod pe server. Iar pe lângă webshell-urile vizibile, atacatorul lăsase ceva mult mai sofisticat:

• Un plugin fals, deghizat într-un „monitor de operațiuni al site-ului”, care oferea autentificare ca administrator cu un singur click, execuție de comenzi de sistem, forjarea cookie-urilor de administrator, amprentarea serverului și chiar o funcție de auto-ștergere pentru a acoperi urmele.
• Un keylogger deghizat în fișier JPG, care captura datele introduse în formularul de autentificare. Cu alte cuvinte, dacă administratorul ar fi schimbat parola după incident, atacatorul ar fi primit-o pe cea nouă.
• Un jurnal cu 63 de conturi de utilizator nedorite, create automat în patru zile de scanere din întreaga lume care testau exploit-ul.

Un detaliu mic a făcut diferența: niciunul dintre cele 63 de conturi nu a reușit să obțină drepturi de administrator. Motivul este un strat de protecție pe care îl rulăm pe toate site-urile găzduite, un modul care blochează la nivel de nucleu WordPress crearea de utilizatori cu privilegii ridicate prin căi neautorizate. Exploit-ul reușea să creeze contul, dar contul rămânea fără putere. Este un exemplu clasic de apărare în adâncime: un strat a cedat (plugin-ul vulnerabil), dar stratul următor a limitat pagubele.

Curățenia a presupus o copie completă a contului păstrată ca dovadă criminalistică, eliminarea plugin-ului fals, a keylogger-ului, a tuturor folderelor și fișierelor malițioase, ștergerea celor 63 de conturi, resetarea parolei de administrator și schimbarea parolei bazei de date. Apoi am actualizat scanarea nocturnă ca să recunoască automat toată această familie de tehnici: foldere care imită instrumente legitime, plugin-uri cu sufixe hexazecimale, imagini care conțin cod ascuns și versiuni vulnerabile ale plugin-ului respectiv.

Incidentul 3: parola schimbată care nu l-a dat afară pe atacator

Al treilea caz este poate cel mai instructiv pentru orice proprietar de site, pentru că demontează o credință foarte răspândită: „dacă am fost spart, schimb parola și gata”.

Un site construit cu un constructor de pagini și câteva extensii premium funcționase luni de zile fără nicio întreținere. Când proprietarul ne-a contactat, două subdomenii nu mai funcționau corect. Diagnosticul inițial a arătat plugin-uri depășite și conflicte între versiuni, dar în timpul curățeniei am găsit ceva mult mai grav: Application Passwords suspecte pe conturile de utilizator.

Application Passwords este o funcție legitimă a WordPress, gândită pentru ca aplicațiile externe (aplicația mobilă, un instrument de publicare, o integrare) să se poată conecta la site fără parola principală. Problema este că aceste parole de aplicație ocolesc complet formularul de login și autentificarea în doi pași. Și, mai important, supraviețuiesc unei resetări a parolei principale. Un atacator care a reușit o singură dată să intre pe un cont de administrator își creează o parolă de aplicație și de atunci are acces permanent prin API, indiferent de câte ori schimbi tu parola.

De atunci, verificarea parolelor de aplicație pe toate conturile, nu doar pe cel despre care știm că a fost compromis, a devenit un pas standard în orice curățenie pe care o facem.

Bonus: managerul de fișiere care nu trebuia să existe

Un tipar pe care l-am întâlnit de mai multe ori: după ce obțin acces de administrator, atacatorii instalează un plugin de tip file manager. De acolo pot răsfoi, edita și încărca fișiere pe server direct din panoul WordPress, fără FTP și fără alte urme evidente. Răspunsul nostru a fost să menținem permanent activă, pe site-urile administrate, setarea care interzice instalarea și modificarea plugin-urilor și temelor din panoul de administrare. Actualizările se fac controlat, din exterior, iar setarea este dezactivată doar temporar, pe durata ferestrei de actualizare, un site pe rând. Chiar dacă cineva ajunge administrator, nu poate instala nimic nou.

Toate cele trei incidente au ceva în comun: niciunul nu ar fi fost rezolvat de un singur instrument. Un plugin de securitate nu ar fi văzut webshell-urile din subdomenii. O actualizare la timp nu ar fi scos atacatorul care intrase deja. O parolă nouă nu ar fi anulat parola de aplicație. Protecția reală vine din mai multe straturi care se acoperă unul pe altul, iar WAF-ul este primul dintre ele.

Ce face un WAF, strat cu strat

Am explicat în articolul de lansare ce este un Web Application Firewall la nivel general: un filtru care stă între vizitatori și site și analizează fiecare cerere înainte să ajungă la WordPress. Acum intrăm în detalii. Un WAF bine administrat nu este o singură regulă magică, ci un set de mecanisme diferite, fiecare specializat pe un tip de amenințare.

1. Inspecția cererilor după semnături de atac

Cel mai vechi și cel mai cunoscut mecanism. Fiecare cerere HTTP (adresa accesată, parametrii din URL, datele trimise prin formulare, cookie-urile, antetele) este comparată cu un set de tipare cunoscute de atac. O cerere care conține fragmente tipice de SQL injection (tentativa de a manipula baza de date prin câmpurile unui formular), de cross-site scripting (injectarea de cod JavaScript care va rula în browserul altor vizitatori) sau de path traversal (încercarea de a citi fișiere din afara directorului site-ului, cum ar fi fișierul de configurare cu parola bazei de date) este blocată înainte să atingă aplicația.

Diferența dintre un WAF bun și unul mediocru stă în calitatea și actualitatea acestor reguli. Reguli prea permisive lasă atacuri să treacă. Reguli prea stricte blochează vizitatori legitimi: un client care scrie în formularul de contact o frază care seamănă întâmplător cu o comandă SQL, un editor care salvează un articol cu cod în el, un plugin care trimite date într-un format neobișnuit. De aceea un WAF are nevoie de administrare activă, nu doar de instalare.

2. Virtual patching: protecție înainte ca plugin-ul să fie reparat

Acesta este, probabil, cel mai valoros mecanism pentru un site WordPress. Când apare o vulnerabilitate nouă într-un plugin popular, se cunoaște de obicei foarte precis ce cerere o exploatează: la ce adresă, cu ce parametri, în ce format. Pe baza acestor informații se poate scrie o regulă care blochează exact acel tip de cerere, fără să atingi codul plugin-ului.

Practic, vulnerabilitatea există în continuare în cod, dar nimeni din exterior nu mai poate ajunge la ea. Asta cumpără timp: timp ca dezvoltatorul să publice un patch, timp ca actualizarea să fie testată, timp ca site-ul să fie actualizat fără grabă și fără riscul de a strica ceva. În incidentul cu formularul de contact descris mai sus, o regulă de virtual patching pentru acea vulnerabilitate ar fi închis ușa în fereastra de câteva zile în care au fost plantate webshell-urile.

Virtual patching nu înlocuiește actualizările. Le completează, acoperind intervalul periculos dintre momentul în care o vulnerabilitate devine publică și momentul în care site-ul tău este efectiv actualizat.

3. Limitarea ratei și protecția anti-brute-force

Un om normal nu încearcă 500 de parole pe minut pe formularul de autentificare. Nu trimite 200 de cereri pe secundă către pagina de căutare. Nu accesează secvențial toate cele 40.000 de ID-uri de produs dintr-un magazin. Un WAF urmărește ritmul cererilor pe fiecare adresă IP și pe fiecare tip de resursă și intervine când tiparul nu mai arată a comportament uman.

Contează mai ales pentru punctele sensibile ale unui site WordPress: pagina de autentificare, fișierul XML-RPC (o interfață veche, încă activă implicit, foarte iubită de boții de brute-force pentru că permite testarea mai multor parole într-o singură cerere), endpoint-urile API care expun numele utilizatorilor și formularele de contact folosite pentru spam.

4. Reputația adreselor IP și filtrarea boților

O parte importantă din traficul malițios vine de la adrese IP deja cunoscute: servere compromise, rețele de proxy folosite pentru atacuri, centre de date din care nu vine niciodată un vizitator real. Un WAF conectat la liste de reputație actualizate poate bloca sau provoca (de exemplu, cu o verificare suplimentară) aceste adrese înainte să facă vreo cerere relevantă.

La fel de important este să nu blochezi boții buni: crawlerele Google și Bing, instrumentele de monitorizare a disponibilității, serviciile de plată care confirmă tranzacții, integrările cu platformele de curierat. Un WAF prost configurat care blochează Googlebot îți poate face mai mult rău SEO decât un atac.

5. Inspecția fișierelor încărcate

Formularele care acceptă fișiere (CV-uri, fotografii, documente, avatare) sunt una dintre cele mai frecvente căi de compromitere. Tehnica clasică este fișierul „poliglot”: arată ca o imagine validă, are extensie de imagine și chiar se deschide ca imagine, dar conține în interior cod PHP care poate fi executat în anumite condiții. Un WAF care inspectează conținutul fișierelor încărcate, nu doar extensia, oprește această categorie de atacuri la intrare.

6. Protecția la nivel de infrastructură împotriva DDoS

Atacurile de tip Distributed Denial of Service încearcă să copleșească site-ul cu trafic, până nu mai poate răspunde vizitatorilor reali. Există două mari categorii. Atacurile volumetrice trimit pur și simplu mai mult trafic decât poate duce conexiunea; se opresc la nivel de rețea, înainte să ajungă la server. Atacurile aplicative sunt mai subtile: trimit cereri aparent legitime, dar către paginile cele mai costisitoare de generat (căutări complexe, filtre de produse cu zeci de combinații, coșul de cumpărături). Aici intervine WAF-ul, care recunoaște tiparul și filtrează cererile înainte ca PHP și baza de date să fie puse la muncă.

De ce contează unde se face filtrarea

Toate aceste mecanisme ar putea teoretic să ruleze și într-un plugin WordPress. Diferența este momentul în care intervin. Un plugin de securitate se încarcă după ce WordPress a pornit: serverul web a primit cererea, a pornit procesul PHP, a încărcat nucleul WordPress, s-a conectat la baza de date, a încărcat celelalte plugin-uri și abia apoi pluginul de securitate decide dacă cererea e bună sau rea. Sub un atac cu zeci de mii de cereri, fiecare dintre acești pași consumă resurse, chiar dacă cererea este respinsă la final.

Un WAF la nivel de server decide înainte de toate acestea. Cererea malițioasă este respinsă din primele milisecunde, fără să consume nimic din resursele alocate site-ului tău. De aceea site-urile protejate astfel rămân rapide chiar și în timpul unui atac, iar în combinație cu serverul web LiteSpeed și stocarea SSD NVMe, diferența se simte inclusiv în zilele obișnuite.

Ce NU face un WAF (și de ce trebuie să știi asta)

Ar fi ușor să prezentăm WAF-ul ca pe o soluție universală. Nu este, și orice furnizor care îl vinde așa îți face un deserviciu. Iată limitele reale:

Nu repară o parolă slabă sau furată. Dacă cineva are parola corectă a contului de administrator (obținută prin phishing, reutilizată de pe alt site compromis sau pur și simplu ghicită pentru că era „admin123”), cererile lui arată perfect legitime. WAF-ul poate încetini tentativele repetate, dar nu poate ști că persoana care introduce parola corectă nu ești tu. Aici ajută autentificarea în doi pași și eliminarea conturilor generice de tip „admin”.

Nu curăță un site deja infectat. Dacă webshell-ul este deja pe server, WAF-ul poate bloca unele încercări de a-l folosi, dar nu îl șterge. Iar un atacator care are deja un punct de sprijin găsește de obicei o cale să-l folosească. De aceea, în planurile noastre, primul pas la preluarea unui site nu este activarea WAF-ului, ci auditul și curățenia completă.

Nu vede ce se întâmplă în interiorul serverului. Un WAF inspectează traficul care vine din exterior. Nu vede un fișier modificat de un proces intern, un job cron adăugat de un atacator, un utilizator creat direct în baza de date sau o parolă de aplicație generată printr-o sesiune legitimă. Pentru toate acestea e nevoie de scanare și monitorizare pe server.

Nu înlocuiește actualizările. Virtual patching acoperă vulnerabilitățile cunoscute și suficient de bine documentate pentru a scrie o regulă. Nu acoperă totul și nu pentru totdeauna. Un site cu plugin-uri vechi de trei ani rămâne un site riscant, cu sau fără WAF.

Nu protejează împotriva greșelilor de configurare. Un director de backup lăsat public, un fișier de export al bazei de date uitat în rădăcina site-ului, un subdomeniu de test cu o instalare WordPress veche, abandonată: WAF-ul poate atenua unele riscuri, dar sursa problemei este configurația, nu traficul.

Concluzia nu este că WAF-ul e inutil. Dimpotrivă: este primul și cel mai eficient strat, cel care oprește marea majoritate a atacurilor automate înainte să conteze. Dar este un strat. Protecția serioasă vine din ce se construiește în jurul lui.

Apărarea în adâncime: straturile din jurul WAF-ului

Conceptul de apărare în adâncime vine din strategia militară și este simplu: nu te bazezi pe un singur zid. Dacă primul cedează, al doilea încetinește atacatorul, al treilea limitează pagubele, al patrulea te anunță că ceva s-a întâmplat. Iată cum arată aceste straturi pe infrastructura pe care o administrăm.

Stratul 1: sistemul de operare și nucleul, actualizate fără repornire

Vulnerabilitățile nu apar doar în WordPress. Apar și în nucleul Linux, în serverul web, în bibliotecile de sistem. Un server care rulează un nucleu vulnerabil poate fi compromis complet, indiferent cât de bine e protejat WordPress-ul de pe el. Folosim actualizare live a nucleului, care aplică patch-urile de securitate fără repornirea serverului. Asta înseamnă că o vulnerabilitate critică la nivel de kernel poate fi corectată pe toată flota de servere în aceeași zi, fără ca site-urile tale să fie oprite nicio secundă.

Stratul 2: izolarea conturilor

Pe un server de găzduire rulează mai multe site-uri. Întrebarea critică este: dacă unul dintre ele este compromis, ce se întâmplă cu celelalte? Pe serverele noastre, fiecare cont rulează într-un mediu izolat, cu resurse proprii garantate (CPU, memorie, procese simultane) și cu un sistem de fișiere virtualizat în care nu vede fișierele celorlalte conturi. Un site infectat nu poate citi configurația altui site, nu îi poate consuma resursele și nu se poate răspândi în restul serverului. Și reciproc: dacă un vecin de server are o problemă, site-ul tău nu o simte.

Stratul 3: scanare zilnică de malware, cu reguli scrise din incidente reale

Pe lângă scanerul de malware comercial care rulează pe toate serverele, rulăm în fiecare noapte un set propriu de verificări, scris și actualizat de echipa noastră după fiecare incident. Aici intră exact tiparele descrise mai sus: foldere care imită instrumente legitime, plugin-uri cu nume aleatorii, imagini care conțin cod, panouri de cloaking în directoare de subdomenii, payload-uri specifice unor vulnerabilități recente, versiuni vulnerabile ale plugin-urilor populare. Fiecare incident nou devine o regulă nouă, iar regula protejează apoi toți clienții.

Un detaliu care pare minor, dar nu este: scanarea nu doar șterge, ci și păstrează dovezi. Un fișier malițios eliminat este copiat într-o zonă de carantină, cu calea completă și momentul exact al detectării, pentru a putea reconstitui ulterior cum a intrat atacatorul. Fără această informație, curățenia tratează simptomul, nu cauza.

Stratul 4: întărirea WordPress la nivel de configurare

Câteva setări simple reduc dramatic suprafața de atac: interzicerea editării fișierelor și a instalării de plugin-uri din panoul de administrare, blocarea creării neautorizate de utilizatori cu drepturi ridicate, dezactivarea execuției PHP în directorul de încărcări, restricționarea accesului la fișierele de configurare. Niciuna dintre ele nu afectează felul în care folosești site-ul zi de zi, dar fiecare închide o ușă pe care atacatorii o folosesc frecvent.

Stratul 5: actualizări controlate

Actualizarea automată a tuturor plugin-urilor imediat ce apare o versiune nouă sună bine în teorie. În practică, o actualizare poate strica un site: incompatibilitate cu tema, conflict cu alt plugin, schimbare de comportament într-un formular. Planurile WAF includ actualizări pentru WordPress, teme și plugin-uri, făcute controlat, cu backup înainte și verificare după, iar actualizările de securitate critice au prioritate.

Stratul 6: backup extern, zilnic, păstrat 30 de zile

Ultima linie de apărare. Dacă toate celelalte straturi cedează, backup-ul este cel care te readuce la o stare curată. Două detalii fac diferența între un backup util și unul inutil. Primul: trebuie păstrat în afara serverului. Un backup pe același server cu site-ul poate fi criptat de ransomware, șters de atacator sau pierdut împreună cu serverul la o defecțiune hardware. Al doilea: trebuie păstrat suficient de mult. Multe infecții sunt descoperite abia după săptămâni. Dacă ai doar backup-ul de ieri și site-ul e infectat de trei săptămâni, backup-ul tău conține deja malware-ul. Retenția de 30 de zile îți permite să revii la un punct dinaintea infecției.

Stratul 7: monitorizarea listelor negre

Uneori primul semn al unei compromiteri nu vine de pe server, ci din exterior: Google Safe Browsing marchează site-ul ca periculos, un furnizor de email pune domeniul pe o listă de spam, un antivirus începe să blocheze accesul. Monitorizăm aceste liste și, dacă site-ul apare într-una, curățăm cauza și solicităm delistarea. Fiecare zi petrecută pe o listă neagră înseamnă vizitatori care văd un avertisment roșu în locul site-ului tău.

Stratul 8: oamenii

Toate straturile de mai sus generează alerte. Alertele sunt inutile dacă nu le citește nimeni. Ultimul strat, și poate cel mai important, este echipa care urmărește zilnic buletinele de securitate pentru WordPress și pentru cele mai folosite plugin-uri, care investighează fiecare alertă, care adaptează regulile după fiecare incident și care intervine în timpul garantat prin SLA. Diferența dintre „avem un scanner” și „avem pe cineva care se uită la ce găsește scannerul” este diferența dintre o problemă descoperită azi și una descoperită peste o lună.

SLA de remediere: ce înseamnă 6 ore, 3 ore sau 1 oră

SLA vine de la Service Level Agreement și este, pe scurt, o promisiune măsurabilă. Multe oferte de hosting vorbesc despre „uptime 99,9%”, dar puține spun ce se întâmplă atunci când site-ul este compromis. Planurile noastre WAF au un SLA de remediere: timpul maxim în care intervenim și rezolvăm un incident de securitate după ce a fost detectat sau raportat.

Diferența dintre cele trei planuri stă tocmai aici. Planul Basic WAF Platform are un SLA de 6 ore, planul Business WAF Platform de 3 ore, iar planul Ecommerce WAF Platform de o oră. Toate celelalte elemente (WAF-ul, scanarea, backup-ul, actualizările, chatbotul AI, resursele) sunt identice.

De ce timpul contează mai mult decât pare

Un site compromis nu produce pagube într-un singur moment. Pagubele se acumulează în timp, iar ritmul lor crește:

În primele minute, vizitatorii pot fi redirecționați către pagini de phishing sau de spam. Fiecare vizitator redirecționat este un potențial client pierdut și, mai grav, o persoană care asociază numele firmei tale cu o experiență dubioasă.

În primele ore, roboții motoarelor de căutare pot indexa conținutul injectat. Paginile de spam apar în rezultatele Google sub numele domeniului tău. Serverul poate începe să trimită emailuri de spam, iar reputația adresei de email scade.

În prima zi, crește riscul ca site-ul să fie marcat de Google Safe Browsing. Din acel moment, orice vizitator care folosește Chrome, Firefox sau Safari vede un avertisment roșu pe tot ecranul înainte să ajungă la tine. Delistarea este posibilă, dar durează.

În zilele următoare, pagubele devin structurale: poziții SEO pierdute care se recuperează în săptămâni sau luni, emailuri ale firmei care ajung în spam la clienți și parteneri, iar pentru magazine online, potențiale probleme legate de datele clienților și obligațiile de raportare care decurg din GDPR.

Un SLA scurt nu înseamnă doar că site-ul revine mai repede. Înseamnă că oprești incidentul înainte să treacă în etapa următoare.

Cum îți calculezi costul unei ore de downtime

Recomandarea noastră pentru alegerea planului pornește de la o întrebare simplă: cât te costă o oră în care site-ul nu funcționează sau funcționează greșit? Iată cum poți face un calcul aproximativ.

Pentru un magazin online: împarte vânzările online lunare la numărul de ore dintr-o lună (aproximativ 720) și ajustează pentru orele de vârf. Un magazin care vinde 30.000 € pe lună are o medie de peste 40 € pe oră, dar în orele de seară sau în perioadele de campanie valoarea poate fi de trei-patru ori mai mare. La aceasta se adaugă coșurile abandonate, clienții care nu mai revin și bugetul de reclame plătite care trimite trafic către un site nefuncțional. Diferența de preț dintre planul Business și planul Ecommerce este de 100 € pe lună. Dacă o singură oră de indisponibilitate într-o seară de Black Friday te costă mai mult decât atât, calculul este simplu.

Pentru o firmă de servicii: gândește-te câte cereri de ofertă, programări sau apeluri vin lunar prin site și ce valoare medie are un client nou. Dacă site-ul aduce zece clienți pe lună, fiecare cu o valoare medie de 500 €, o zi de indisponibilitate într-o perioadă aglomerată poate însemna un client pierdut. Iar un site marcat ca periculos în Google poate însemna săptămâni de cereri pierdute.

Pentru un site de prezentare sau un blog: costul direct este mai mic, dar costul reputațional nu. Un site de prezentare cu avertismentul roșu al Google sau cu pagini de spam indexate sub numele tău spune ceva despre firmă oricui caută informații înainte de o întâlnire. Pentru acest profil, planul Basic, cu SLA de 6 ore, este de obicei echilibrul corect între cost și risc.

Și nu uita de costul curățeniei. O intervenție de urgență pentru un site compromis, fără contract de mentenanță, costă de obicei cât câteva luni de protecție, iar rezultatul depinde de câte straturi de persistență a lăsat atacatorul în urmă. Un singur incident evitat plătește, în multe cazuri, un an de protecție.

Cum evaluezi un furnizor de găzduire cu protecție WAF: 10 întrebări

„Securitate” a devenit un cuvânt pe care îl folosesc toți furnizorii de hosting. Iată zece întrebări care separă protecția reală de marketing. Le poți pune oricărui furnizor, inclusiv nouă.

1. Unde rulează WAF-ul? La nivel de server sau rețea, înainte ca cererea să ajungă la WordPress, sau ca plugin în interiorul site-ului? Răspunsul determină dacă protecția rezistă sub un atac volumetric.

2. Cine administrează regulile? Există o echipă care le ajustează când apar vulnerabilități noi sau când blochează trafic legitim, ori sunt reguli generice, lăsate pe pilot automat?

3. Oferă virtual patching pentru plugin-urile WordPress? Și, concret, cât de repede după publicarea unei vulnerabilități critice apare regula care o blochează?

4. Ce se întâmplă dacă site-ul este deja compromis? Curățenia este inclusă sau se plătește separat, la tarif de urgență? Include căutarea mecanismelor de persistență (conturi ascunse, parole de aplicație, joburi cron, fișiere în afara directorului principal) sau doar ștergerea fișierelor vizibile?

5. Există un SLA de remediere scris? Nu „răspundem rapid”, ci un număr concret de ore, asumat contractual.

6. Unde sunt păstrate backup-urile și cât timp? Pe același server sau extern? O zi, o săptămână sau o lună?

7. Cum sunt izolate conturile de pe același server? Dacă un vecin este compromis, poate atacatorul să ajungă la fișierele tale? Poate un vecin să îți consume resursele?

8. Cum se aplică patch-urile de securitate pentru server? Cât de repede este corectată o vulnerabilitate critică la nivel de sistem de operare? Necesită oprirea serverului?

9. Primești un raport? Ce ai de văzut ca proprietar: câte atacuri au fost blocate, ce actualizări s-au făcut, ce a găsit scanarea? Un furnizor care nu raportează nimic nu are nimic de raportat sau nu se uită.

10. Cine răspunde când ceva nu merge? Un singur furnizor pentru găzduire și securitate sau doi, care își pasează responsabilitatea unul altuia?

Dacă primești răspunsuri vagi la mai mult de două-trei dintre aceste întrebări, protecția oferită este probabil mai subțire decât pare pe pagina de prezentare.

Primele 30 de zile: cum arată trecerea la un plan WAF

Mulți proprietari de site-uri amână mutarea la un alt furnizor de teama complicațiilor. Iată, pas cu pas, ce se întâmplă concret când alegi unul dintre planurile noastre WAF.

Ziua 1: preluarea și auditul

Ne dai acces la găzduirea actuală (sau la un backup complet al site-ului). Primul lucru pe care îl facem nu este mutarea, ci auditul: scanare completă pentru malware, verificarea integrității fișierelor nucleului WordPress, analiza utilizatorilor și a rolurilor acestora, verificarea parolelor de aplicație, căutarea fișierelor suspecte în afara directorului principal, verificarea prezenței domeniului în listele negre, inventarul plugin-urilor și al versiunilor lor.

Zilele 1–3: curățenie și întărire

Dacă auditul găsește probleme, le rezolvăm înainte de migrare. Nu are rost să muți un site infectat pe un server curat. Eliminăm malware-ul, închidem ușile de acces, actualizăm componentele vulnerabile și aplicăm setările de întărire. Dacă site-ul are plugin-uri abandonate de dezvoltatori, îți spunem și îți propunem alternative.

Zilele 2–5: migrarea fără întrerupere

Copiem site-ul, baza de date, conturile de email și configurațiile pe noul server. Verificăm că totul funcționează identic, inclusiv formularele, plățile, emailurile trimise de site și certificatul SSL, înainte să schimbăm DNS-ul. Vizitatorii nu observă nicio întrerupere. Migrarea este inclusă gratuit în toate planurile.

După migrare: activarea protecției și calibrarea

WAF-ul se activează, iar primele zile sunt de calibrare: urmărim ce blochează regulile și ne asigurăm că niciun vizitator legitim, nicio integrare (procesatorul de plăți, curierul, platforma de facturare) și niciun robot util (Google, Bing) nu este afectat. Tot acum configurăm chatbotul AI inclus în plan, antrenat pe conținutul site-ului tău.

Ziua 30: primul raport

La sfârșitul primei luni primești raportul de securitate: ce s-a blocat, ce s-a actualizat, ce a găsit scanarea. Tot în această perioadă poți decide dacă serviciul este ce aveai nevoie: nu există perioadă contractuală minimă, iar în primele 30 de zile ai garanția banii înapoi.

Ce rămâne responsabilitatea ta

Chiar și cu cea mai bună protecție la nivel de server, câteva lucruri depind exclusiv de tine. Sunt simple, dar ignorarea lor anulează o parte din munca celorlalte straturi.

• Parole unice pentru fiecare cont. Parola de administrator WordPress nu trebuie folosită nicăieri altundeva. Un manager de parole rezolvă problema în câteva minute.
• Autentificare în doi pași pe toate conturile de administrator și editor.
• Fără conturi generice. Un utilizator numit „admin” este prima țintă a oricărui atac de tip brute-force. Fiecare persoană are contul ei, cu numele ei, cu drepturile minime de care are nevoie.
• Curățenie la plecări. Când un colaborator, o agenție sau un freelancer nu mai lucrează la site, contul lui se șterge sau i se retrag drepturile în aceeași zi.
• Atenție la plugin-urile „gratuite” de pe site-uri dubioase. Versiunile piratate ale plugin-urilor premium vin foarte des cu uși din spate incluse. Am găsit chiar și plugin-uri de formulare care redirecționau verificarea licenței către servere necunoscute. Economia de câțiva zeci de euro nu merită.
• Semnalează orice comportament ciudat. O pagină care arată diferit, un email de la site pe care nu l-ai trimis, un utilizator pe care nu îl recunoști, o scădere bruscă de trafic. Cu cât aflăm mai repede, cu atât intervenția e mai simplă.

Întrebări frecvente despre găzduirea cu WAF

Am deja un plugin de securitate. De ce aș avea nevoie de WAF la nivel de server?

Pentru că pluginul intervine prea târziu. Până să ia o decizie, cererea a trecut deja prin serverul web, PHP, WordPress și baza de date. Sub atac, serverul se încarcă chiar dacă pluginul blochează tot. În plus, pluginul nu vede ce se întâmplă în afara WordPress-ului: subdomenii, fișiere din alte directoare, procese de pe server. Poți păstra pluginul ca strat suplimentar, dar nu te baza doar pe el.

WAF-ul poate bloca clienți reali?

Un WAF prost configurat, da. De aceea regulile sunt administrate și calibrate activ. Dacă vreodată un client îți spune că nu poate trimite un formular sau finaliza o comandă, ne semnalezi, analizăm cererea blocată și ajustăm regula în timpul prevăzut de SLA.

Ce se întâmplă cu emailul firmei la migrare?

Migrăm și conturile de email, cu tot cu mesajele existente. Planurile WAF includ conturi de email nelimitate. Schimbarea DNS-ului se face abia după ce totul a fost verificat, deci nu se pierde niciun mesaj.

Am un site care nu este WordPress. Mă ajută WAF-ul?

Da. Regulile generale (SQL injection, cross-site scripting, brute-force, reputația IP, protecția DDoS) funcționează pentru orice aplicație web. Partea de virtual patching și de scanare specializată este cea mai detaliată pentru WordPress, pentru că acolo apar cele mai multe atacuri automate, dar protecția de bază se aplică oricărui site.

Pot păstra agenția care îmi face site-ul?

Sigur. Agenția sau dezvoltatorul tău lucrează în continuare pe site ca până acum. Noi ne ocupăm de infrastructură, de protecție, de backup și de actualizări, iar pentru modificările de conținut sau de design colaborăm cu ei când e nevoie.

Cât de repede aflu dacă site-ul meu a fost atacat?

Atacurile blocate de WAF (care sunt zilnice pentru orice site) apar în raportul lunar. Incidentele reale, adică orice situație în care ceva a trecut de primul strat, sunt tratate imediat, iar tu ești anunțat. Nu trebuie să afli de la clienți sau de la Google.

Ce e chatbotul AI inclus și ce legătură are cu securitatea?

Chatbotul nu este o funcție de securitate, ci un beneficiu inclus în toate planurile: un asistent antrenat pe conținutul site-ului tău, care răspunde vizitatorilor 24 de ore din 24. L-am inclus pentru că vrem ca un plan de găzduire premium să aducă valoare și în zilele în care nu se întâmplă nimic rău.

Pot să schimb planul mai târziu?

Oricând, fără penalizări. Mulți clienți încep cu Basic și trec la Business sau Ecommerce când site-ul devine mai important pentru afacere, de exemplu la lansarea unui magazin online sau înaintea unui sezon de vânzări.

Concluzie: securitatea nu e un plugin, e un proces

Dacă ar fi să rezumăm tot ce am văzut în ultimele luni într-o singură idee, ar fi aceasta: site-urile nu sunt compromise pentru că proprietarii lor sunt neglijenți, ci pentru că apărarea lor are un singur strat. Un plugin actualizat, dar fără cineva care să caute ce a rămas în urmă. O parolă schimbată, dar fără verificarea parolelor de aplicație. Un scanner instalat, dar care nu se uită în subdomenii. Un backup făcut, dar pe același server.

Găzduirea cu WAF administrat înseamnă că toate aceste straturi există, sunt conectate între ele și sunt urmărite zilnic de oameni care au curățat exact tipurile de atacuri de care încerci să te protejezi. Iar SLA-ul de remediere îți spune, negru pe alb, cât de repede intervenim dacă totuși ceva trece.

Dacă vrei să vezi ce include fiecare plan, le găsești pe pagina Găzduire cu Securitate WAF. Dacă nu ești sigur de ce nivel ai nevoie sau vrei ca site-ul tău actual să fie verificat înainte de orice decizie, scrie-ne. Îți spunem sincer ce am găsi și ce plan are sens pentru tine, fără upsell inutil.

Vezi planurile WAF Platform →