Răspuns la incidente de securitate: Ce faceți când site-ul dumneavoastră este atacat

Răspuns la incidente de securitate: Ce faceți când site-ul dumneavoastră este atacat, în ordinea în care contează, fiindcă primele decizii determină cât costă incidentul. Am răspuns la zeci de astfel de situații pentru clienți, de la site-uri cu redirecționări spre farmacii până la un portal cu un webshell în dosarul de fișiere încărcate; greșelile se repetă (ștergerea dovezilor, restaurarea peste infecție, parolele neschimbate) și le puteți evita cu un plan de o pagină, scris înainte.

Ghidul urmează etapele standard ale răspunsului la incidente, adaptate unui site sau unui cont de găzduire: detectare, izolare, dovezi, curățare, restaurare, cauză, notificare, învățăminte.

Răspuns la incidente de securitate: Ce faceți când site-ul dumneavoastră este atacat

Semnele

• Redirecționări spre alte site-uri, uneori doar pe mobil sau doar din Google.
• Pagini străine în index (căutarea site:domeniu.ro), conținut sau legături pe care nu le-ați pus.
• Avertisment în browser sau în Search Console (Security issues); e-mail de la furnizor despre spam sau despre fișiere infectate.
• Administratori, module, sarcini cron, conturi FTP sau de e-mail necunoscute.
• Consum de resurse brusc, procese cu nume străine, fișiere noi în dosarele de încărcare.
• Clienți care primesc e-mailuri „de la dumneavoastră” pe care nu le-ați trimis.

Primele 30 de minute: izolare, nu investigare

1. Puneți site-ul în mentenanță: un răspuns 503 cu pagină statică și datele de contact vizibile, sau restricția accesului la adresa IP proprie din .htaccess. Un site care distribuie malware sau redirecționează vizitatorii nu rămâne public.
2. Nu ștergeți nimic încă. Fișierele străine, jurnalele și baza de date sunt dovezile din care aflați cum a intrat atacatorul.
3. Schimbați parola cPanel (sau a serverului) și a contului de client la furnizor, cu al doilea factor activat, ca atacatorul să nu poată reveni prin panou în timp ce lucrați.
4. Notați ora la care ați observat, ce ați observat și ce ați făcut; jurnalul incidentului începe acum.
5. Anunțați persoana responsabilă de decizii (proprietarul, directorul) și, dacă site-ul prelucrează date personale, persoana responsabilă de protecția datelor; termenul de 72 de ore pentru notificarea autorității curge de la constatare.

Ora 1-2: dovezile

Copiați tot, așa cum este: fișierele (arhivă a dosarului personal), baza de date (export), jurnalele de acces și de erori (inclusiv arhivele lunare din Raw Access), lista de cronuri, lista utilizatorilor. Salvați copia în afara serverului, cu data și ora. Este copia „infectată”, pe care nu o restaurați niciodată, dar din care faceți analiza; o ștergeți după închiderea incidentului, dacă nu există obligații legale de păstrare. Copiile de siguranță anterioare le puneți deoparte, ca să nu fie suprascrise de rotație în timpul incidentului.

Ora 2-6: analiza

Trei întrebări: ce a făcut atacatorul, când a intrat și pe unde. Uneltele:

find ~/public_html -type f -newermt "2026-09-01" -not -path "*/cache/*" | sort   # fișiere modificate de la o dată
find ~/public_html -name "*.php" -path "*upload*"                                   # PHP unde nu are ce căuta
grep -rlE "base64_decode|eval\(|gzinflate|str_rot13" ~/public_html --include="*.php"
grep "POST" ~/access-logs/exemplu.ro | grep -v "wp-admin\|wp-login\|admin-ajax" | awk '{print $1, $4, $7}' | sort | uniq -c | sort -rn | head

Fișierele modificate dau data infecției; cererile POST spre fișiere PHP neobișnuite din zilele de dinainte dau punctul de intrare și adresa atacatorului; cauzele frecvente sunt un modul cu vulnerabilitate publicată, o parolă ghicită, un formular de încărcare fără validare sau un site vechi din același cont. Verificarea sumelor de control (wp core verify-checksums) separă fișierele modificate de cele originale. Metoda de citire a jurnalelor este în ghidul despre jurnalele de erori și acces. Dacă nu găsiți punctul de intrare în câteva ore, continuați cu curățarea, dar presupuneți ce e mai rău: toate credențialele compromise, tot contul.

Ora 6-12: curățarea și restaurarea

Regula: nu curățați peste infecție; înlocuiți. Fie restaurați dintr-o copie de dinaintea datei infecției (și abia apoi aduceți la zi conținutul, verificat), fie reinstalați aplicația din surse originale, păstrând doar conținutul și fișierele încărcate, după verificarea lor. Pentru WordPress, pașii exacți sunt în ghidul despre detectarea și eliminarea malware-ului; pentru alte aplicații, principiul e același. Verificați și baza de date (utilizatori, opțiuni, conținut cu scripturi), .htaccess-urile din tot contul, cronurile, redirecționările de e-mail și celelalte site-uri din cont, fiindcă un cont compromis înseamnă toate site-urile lui. Dacă aveți server propriu și există semne de acces la nivel de sistem (utilizatori noi, procese ca root, chei SSH străine), reinstalați serverul; curățarea unui sistem cu rootkit nu se termină cu certitudine, cum arătăm în ghidul despre securitatea AlmaLinux 9.

Ora 12-24: credențialele și întărirea

• Toate parolele: administratori ai aplicației, baza de date (și în fișierul de configurare), cPanel, FTP, SSH, e-mail, tokenuri API, chei de securitate ale aplicației.
• Al doilea factor pe cPanel și pe administratorii aplicației, după ghidul despre autentificarea în doi pași.
• Închiderea punctului de intrare: actualizarea sau eliminarea modulului vulnerabil, validarea încărcărilor, ștergerea site-urilor vechi.
• Permisiuni corecte, .htaccess anti-PHP în dosarele scriibile, ModSecurity activ, după ghidul despre securitatea contului cPanel.
• Verificarea calculatoarelor administratorilor: un program care fură parole face inutilă orice curățare a serverului.

Ziua 2-3: Google, e-mail, reputație

Cererea de revizuire din Security issues (Search Console), cu descrierea măsurilor; raportul de indexare pentru paginile străine (după ștergere dau 404 și ies din index; cererea de eliminare temporară grăbește); verificarea domeniului în listele de spam pentru e-mail și cererile de scoatere; monitorizarea Safe Browsing. Dacă vizitatorii au văzut avertismente sau redirecționări, o notă scurtă pe site și pe rețele („am avut un incident, l-am rezolvat, iată ce am făcut”) protejează încrederea mai bine decât tăcerea.

GDPR: când notificați

Dacă incidentul a putut expune date personale (baza de date accesibilă atacatorului, formulare interceptate, conturi de utilizatori), evaluați riscul pentru persoane și, dacă există, notificați ANSPDCP în 72 de ore de la constatare, cu ce s-a întâmplat, ce date, câte persoane, ce măsuri; informați persoanele afectate dacă riscul este ridicat (date de plată, parole în clar, date sensibile). Documentați evaluarea și în cazul în care decideți că nu notificați. Detaliile sunt în ghidul despre GDPR și securitatea datelor. Furnizorii de servicii (găzduire, procesator de plăți) se anunță și ei, ca să își facă propriile verificări.

Săptămâna 1-2: învățămintele

1. Raportul incidentului: cronologie, cauză, impact, măsuri, cost; o pagină, păstrată.
2. Ce a lipsit: actualizări, al doilea factor, copii, monitorizare, inventar; fiecare lipsă devine o sarcină cu termen.
3. Monitorizare care ar fi prins incidentul mai devreme: verificarea săptămânală a sumelor de control, alerte pe fișiere noi în dosarele de încărcare, monitorizare externă a conținutului paginii principale (nu doar a codului 200).
4. Repetarea scanărilor la două și la patru săptămâni; reinfectarea apare când punctul de intrare nu a fost închis.

Trei incidente, trei lecții

Un portal de clienți pe Perfex, cu un webshell încărcat prin formularul de fișiere: curățat, credențiale rotite, dosarul de încărcări protejat cu .htaccess anti-PHP. A doua zi, al doilea webshell, în rădăcina docroot, pe care scanerul nu îl detectase și pe care regula nu îl acoperea. Lecția: protejați toate dosarele scriibile, nu doar cel prin care a intrat prima dată, și verificați manual rădăcina.

Un site WordPress „curățat” de trei ori de un colaborator, reinfectat de fiecare dată în două săptămâni: modulul vulnerabil fusese actualizat, dar utilizatorul administrator creat de atacator rămăsese, cu parola lui. Lecția: lista de administratori face parte din curățare, iar credențialele se rotesc toate.

Un laptop de administrator cu un miner instalat, descoperit după consumul de procesor: parolele salvate în browser și în clientul FTP au fost considerate compromise, iar lista de conturi de rotit (peste 40) a durat o zi, fiindcă nu exista dinainte. Lecția: inventarul credențialelor, cu locul unde se schimbă fiecare, este parte din plan.

Când chemați pe cineva

Dacă nu găsiți punctul de intrare în câteva ore, dacă incidentul implică date de plată sau date sensibile, dacă serverul este al dumneavoastră și există semne de acces la sistem, sau dacă site-ul se reinfectează: un specialist costă mai puțin decât a treia curățare. Cereți-i, înainte de orice, să păstreze dovezile și să scrie raportul; un specialist care „curăță” fără raport vă lasă exact unde erați.

Planul de o pagină, scris înainte

Cine observă și cui raportează; cine decide oprirea site-ului; unde sunt copiile și cum se restaurează (testat); lista conturilor de rotit, cu unde se schimbă fiecare; contactele: furnizor de găzduire, registrar, procesator de plăți, responsabil cu datele, autoritatea; textul de mentenanță pregătit; și pagina cu comenzile de mai sus. Un plan pe care îl citiți în primele cinci minute face diferența dintre o zi și o săptămână. Prevenirea, care face planul rar necesar, este descrisă în ghidul despre securizarea unui site WordPress, iar scanările periodice care prind vulnerabilitățile înainte de atac, în cel despre WPScan și Nikto.

Surse

• Ajutor Search Console, raportul Probleme de securitate: tipurile de probleme și cererea de revizuire după curățare.
• Documentația WordPress, securizarea WordPress: măsurile de întărire după un incident.