# DDoS sau atac hacker? Cum încadrați corect atacurile

> DDoS sau atac hacker? Semne tipice în comparație, primele comenzi de verificare pe server și ce ar trebui să faceți concret în primele ore.

Sursa: https://phpsos.de/ro/ratgeber/ddos-oder-exploit/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** Dacă este DDoS sau atac hacker se vede din urme. Un DDoS generează foarte multe cereri și face site-ul lent sau inaccesibil, dar nu modifică nimic. Un exploit are nevoie adesea de puține cereri și lasă fișiere, conturi, procese sau conexiuni noi. Încadrarea corectă decide dacă trebuie să respingeți sarcina sau să circumscrieți un incident.

## Diferența în cuvinte simple

Un **atac DDoS** (Distributed Denial of Service) este ca o mulțime care blochează intrarea într-un magazin. Nimeni nu intră, dar în magazin nu se fură nimic. Scopul este să supraîncarce site-ul sau serverul dumneavoastră, pentru ca clienții reali să nu mai ajungă.

Un **exploit** este, în schimb, o intruziune printr-o ușă deschisă. Atacatorul folosește o slăbiciune, de exemplu în PHP, în CMS sau într-o extensie, pentru a executa cod pe serverul dumneavoastră. Aceasta se poate petrece discret, fără ca site-ul să devină mai lent. Consecințele merg de la pagini de spam și furt de date până la preluarea serverului.

Pentru conducere, diferența este decisivă: un DDoS este o problemă de disponibilitate, care se încheie odată cu atacul. Un exploit reușit este un incident de securitate, care rămâne până când este găsit, curățat și documentat.

## DDoS sau atac hacker: semnele în comparație

Tabelul următor ajută la prima încadrare. Nu înlocuiește o analiză, dar arată unde ar trebui să priviți mai întâi.

| Trăsătură | Mai degrabă DDoS | Mai degrabă exploit sau intruziune |
|---|---|---|
| Accesibilitate | lent sau indisponibil | adesea normală |
| Cereri în log | foarte multe, adesea uniforme | puține, cereri țintite |
| Fișiere | nemodificate | fișiere PHP noi sau modificate |
| Conturi | nemodificate | admini noi, parole schimbate |
| Procese | serverul web și PHP la sarcină maximă | procese necunoscute, minare, trimitere de spam |
| Rețea | mult trafic de intrare | conexiuni ieșite neobișnuite |
| După încheiere | totul ca înainte | urmele rămân |

Atenție la suprapuneri: scanarea în masă după o vulnerabilitate poate arăta ca un mic DDoS. Exact asta era de așteptat în jurul PHP2Shell, când atacatorii căutau servere vulnerabile. O sarcină mare poate însemna deci și că cineva încearcă chiar acum să pătrundă.

## Primele verificări pe server

Comenzile următoare nu modifică nimic în sistem și oferă o imagine rapidă. La suspiciunea unei intruziuni, salvați logurile înainte de a face intervenții mai mari.

```bash
# Sarcina și timpul de funcționare
uptime

# Conexiuni rezumate și cele mai frecvente contrapărți
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# Cele mai frecvente adrese de client din logul de acces (adaptați calea)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Fișiere PHP modificate în ultimele 7 zile
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

# Procesele cu cea mai mare sarcină CPU
ps aux --sort=-%cpu | head -15
```

În prezentarea conexiunilor, a patra coloană arată contrapartea. Multe conexiuni de la puține adrese sau o creștere de câteva ori peste valoarea normală indică supraîncărcare. Fișierele PHP noi din directoarele de încărcări sau de cache, procesele cu nume străine sub utilizatorul serverului web sau conexiunile ieșite către destinații necunoscute indică mai degrabă o intruziune. O listă detaliată găsiți la [Semne de compromitere după PHP2Shell](https://phpsos.de/ro/php2shell/bin-ich-gehackt-anzeichen/).

## De ce o sarcină mare poate fi și o manevră de diversiune

Se întâmplă ca atacatorii să provoace o supraîncărcare în timp ce pătrund simultan în mod țintit. Echipa este atunci ocupată cu accesibilitatea, iar urmele reale se pierd în zgomotul din loguri. De aceea se aplică: chiar dacă un DDoS este evident, verificați după încheierea lui fișierele, conturile și conexiunile ieșite.

În cazul PHP2Shell se adaugă faptul că, potrivit php.net și firmelor de securitate, nu există Indicators of Compromise publicați și confirmați. Detecția se bazează pe analiza comportamentului. Un server care a fost nepatchuit în perioada de scanare, de la mijlocul lunii octombrie, ar trebui de aceea verificat indiferent de sarcina observată.

O altă variantă sunt e-mailurile de șantaj, în care se amenință cu un atac DDoS dacă nu se plătește. Păstrați asemenea mesaje, nu plătiți fără consultare cu specialiști și evaluați o [sesizare la Zentrale Ansprechstelle Cybercrime](https://phpsos.de/ro/compliance/anzeige-polizei-zac/). Informați în paralel furnizorul de hosting, pentru ca măsurile de protecție să poată fi pregătite. Cum evaluați logurile pentru aceasta se află în ghidul [Cum analizați logurile serverului web după un atac](https://phpsos.de/ro/ratgeber/logfiles-auswerten/).

## Ce ar trebui să faceți în primele ore

**La suspiciune de DDoS:**

- Informați furnizorul de hosting sau centrul de date; acolo există adesea filtre în fața serverului.
- Activați sau întăriți un serviciu de protecție din față ori un [WAF cu patching virtual](https://phpsos.de/ro/leistungen/waf-virtuelles-patching/).
- Setați rate limits în serverul web și protejați în mod special paginile costisitoare, precum căutarea sau coșul de cumpărături.
- Păstrați logurile, pentru ca atacul să poată fi urmărit ulterior.

**La suspiciune de intruziune:**

- Nu ștergeți nimic și nu reinstalați serverul înainte ca logurile și fișierele afectate să fie salvate.
- Actualizați PHP la o versiune corectată și reporniți toți workerii, dacă aceasta nu s-a întâmplat încă.
- Dacă actualizarea nu este posibilă imediat, scoateți temporar site-ul din rețea, așa cum recomandă BSI.
- Reînnoiți datele de acces de pe un dispozitiv curat, nu de pe serverul eventual afectat.
- Lăsați să se verifice dacă pot fi afectate date cu caracter personal; atunci pot curge termene de notificare.

În ambele cazuri ajută o notă scurtă și factuală pentru furnizorul de hosting și prestatori: de când există problema, ce site-uri sunt afectate, ce ați observat și ce s-a schimbat deja. Consemnați, de asemenea, cine a luat ce decizie. Această cronologie economisește timp în analiză și este valoroasă ulterior pentru asigurare, protecția datelor și evaluarea internă. Dacă nu este clar că există un atac, tratați situația preventiv ca pe un incident, până când se dovedește contrariul.

## Cum ajută PHP SOS concret?

- Încadrăm situația remote, pe baza sarcinii, logurilor, fișierelor și conexiunilor, și vă spunem cu ce aveți probabil de-a face.
- La supraîncărcare aplicăm filtre, rate limits și reguli de protecție din față, până când atacul se atenuează.
- La suspiciune de intruziune preluăm [răspunsul structurat la incidente](https://phpsos.de/ro/leistungen/incident-response/): salvare, circumscriere, găsirea cauzei, curățare.
- La final documentăm ce s-a întâmplat și ce măsuri au fost aplicate, până la închiderea incidentului.


## Întrebări frecvente

**Poate un atac DDoS să fure date?**  
Un atac DDoS pur vizează accesibilitatea, nu datele. Nu modifică fișiere și nu citește baze de date. Poate însă apărea simultan cu o încercare de intruziune, de aceea merită totuși o privire asupra fișierelor și conturilor.

**Cum recunosc că site-ul meu a fost hackuit?**  
Indicii tipice sunt fișiere PHP noi sau modificate, conturi de admin necunoscute, redirecționări către site-uri străine, conexiuni ieșite neașteptate și procese care nu se potrivesc aplicației dumneavoastră. Un singur semn nu este o dovadă, mai multe împreună sunt un semnal serios.

**Ajută un CDN sau un WAF împotriva ambelor tipuri de atac?**  
Împotriva atacurilor bazate pe volum, un serviciu din față ajută de obicei bine. Împotriva exploit-urilor, regulile acționează doar dacă recunosc tiparul. La PHP2Shell, Cloudflare însuși atrage atenția că regulile bazate doar pe datele cererii nu sunt suficiente.

**Trebuie să raportez un atac DDoS?**  
Depinde de cazul concret și de domeniul dumneavoastră. Fără acces la date cu caracter personal, obligația de notificare din RGPD nu se aplică de regulă, dar pot exista obligații specifice domeniului. Clarificați acest lucru cu responsabilul dumneavoastră cu protecția datelor sau cu un avocat.

## Surse

- [BSI: situație și recomandări](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: anunțuri de securitate](https://www.php.net/)