# Cum analizați logurile serverului web după un atac: citirea corectă a logului de acces

> Analizați logul de acces după un atac: salvați mai întâi logurile, găsiți urmele tipice, folosiți comenzi pentru Apache și Nginx și particularitățile PHP2Shell.

Sursa: https://phpsos.de/ro/ratgeber/logfiles-auswerten/  
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:** Cine vrea să analizeze logul de acces după un atac salvează mai întâi logurile nemodificate și lucrează apoi doar cu copii. Se caută cereri cu stare 200 către fișiere PHP necunoscute, cereri POST suspecte, accesări ale directoarelor de încărcări și tipare temporale. Pentru PHP2Shell nu există Indicators of Compromise publicați și confirmați, de aceea contează imaginea de ansamblu din mai multe surse de log.

## Mai întâi salvați, apoi analizați

Pe majoritatea serverelor, fișierele de log sunt rotite automat și șterse după un timp fix. După un atac, primul pas este de aceea să salvați logurile existente, înainte să dispară. Aceasta se aplică și dacă nu sunteți încă sigur că s-a întâmplat ceva. Pentru PHP2Shell, presa de specialitate recomandă păstrarea logurilor începând cu 20.10.2026.

```bash
# Copiați logurile cu mărci de timp și consemnați sumele de control
ZIEL=/root/sicherung-logs-$(date +%F)
mkdir -p "$ZIEL"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$ZIEL"/ 2>/dev/null
cp -a /var/log/auth.log* /var/log/syslog* "$ZIEL"/ 2>/dev/null
find "$ZIEL" -type f -exec sha256sum {} + > "$ZIEL.sha256"
```

Depuneți salvarea suplimentar pe alt sistem. Un atacator cu acces la server ar putea altfel modifica ulterior logurile. Sumele de control arată mai târziu că copia este nemodificată. Dacă este necesară o salvare cu valoare probatorie în instanță, de exemplu pentru o sesizare sau pentru asigurare, ar trebui ca [criminalistica IT](https://phpsos.de/ro/leistungen/it-forensik/) să preia salvarea.

> **Important:**
> Verificați rotația logurilor (`/etc/logrotate.d/`) și prelungiți temporar păstrarea, pentru ca în timpul analizei să nu fie șterse alte fișiere.

## Unde se află logurile și cum este construită o linie

Locurile de stocare depind de distribuție și de interfața de administrare. Căi tipice:

| Sistem | Log de acces și de erori |
|---|---|
| Debian, Ubuntu cu Apache | `/var/log/apache2/` |
| RHEL, AlmaLinux, Rocky cu Apache | `/var/log/httpd/` |
| Nginx | `/var/log/nginx/` |
| Plesk | `/var/www/vhosts/system/<domain>/logs/` |
| PHP-FPM | `/var/log/php*-fpm.log` sau în jurnal |

În formatul Combined, răspândit, fiecare linie conține adresa clientului, data și ora, metoda și calea cererii, codul de stare, dimensiunea răspunsului în octeți, Referer și User-Agent. Acordați atenție fusului orar din marca de timp, mai ales dacă comparați logurile cu mesaje în UTC. Patchurile PHP2Shell au fost publicate, de exemplu, la 21.10.2026, ora 14:00 UTC, adică ora 16:00 în Germania.

Dacă site-ul dumneavoastră se află în spatele unui proxy, CDN sau load balancer, în log poate apărea doar adresa acestuia. Adresa reală a vizitatorului se găsește atunci într-un câmp propriu sau în logurile serviciului din față.

### Fără linie de comandă: loguri în panou sau la furnizorul de hosting

Nu orice operator are acces shell. La shared hosting sau la servere administrate, interfețele de administrare oferă de obicei o vizualizare a logurilor și o descărcare a logurilor de acces și de erori. Descărcați fișierele pentru întreaga perioadă disponibilă și păstrați-le în siguranță. Întrebați în scris furnizorul de hosting cât timp sunt păstrate logurile și dacă stările mai vechi pot fi salvate înainte să expire.

Țineți cont aici de protecția datelor: logurile conțin adrese IP și adesea alte date cu caracter personal. Stocați copiile cu acces protejat, transmiteți-le doar persoanelor care au nevoie de ele pentru clarificare și stabiliți când sunt șterse după încheierea incidentului.

## Analiza logului de acces: cele mai importante interogări

Comenzile următoare doar citesc și se potrivesc pentru Nginx și Apache în formatul Combined. Fișierele rotite și comprimate le căutați cu `zgrep` sau `zcat`.

```bash
LOG=/root/sicherung-logs-2026-10-25/nginx/access.log

# Cereri reușite către fișiere PHP, după frecvență
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Apeluri PHP în directoare de încărcări, cache sau imagini
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# Cereri POST după destinație și adresă
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Erori 5xx pe oră: acumulările pot indica procese PHP care se prăbușesc
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Includerea logurilor rotite
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'
```

La prima interogare interesează în special numele de fișiere pe care nu le cunoașteți sau care nu aparțin aplicației. Comparați fișierele suspecte cu sistemul de fișiere: când au fost create, cui aparțin, ce conțin? Indicii oferă ghidul [Cum recunoașteți și eliminați un webshell](https://phpsos.de/ro/ratgeber/webshell-erkennen/).

## Particularități la PHP2Shell

La PHP2Shell, vulnerabilitățile se află în procesarea cererilor de către PHP însuși. La mod_php a fost demonstrat un exploit înainte ca vreun cod al aplicației să ruleze. Aceasta înseamnă: o cerere către o pagină complet obișnuită poate fi suficientă. În logul de acces, o asemenea cerere poate arăta neremarcabil, deoarece conținutul corpului cererii nu apare acolo.

Nu există Indicators of Compromise publicați și confirmați. Acordați de aceea atenție comportamentului și legăturilor, de exemplu începând cu 17.10.2026, prima tentativă de atac observată potrivit rapoartelor din presă:

- Acumulări de erori 500 sau de răspunsuri întrerupte la pagini obișnuite.
- Mesaje despre memorie epuizată sau workeri terminați în logul de erori și în cel PHP-FPM.
- Fișiere PHP noi sau fișiere modificate la scurt timp după asemenea acumulări.
- Cronjoburi, procese sau conexiuni ieșite noi sub utilizatorul serverului web.

Niciunul dintre aceste semnale nu este singur o dovadă. Împreună cu alte urme dau însă o imagine care răspunde la întrebarea privind o compromitere sau justifică o investigație mai profundă. O prezentare a semnelor găsiți la [Am fost deja compromis?](https://phpsos.de/ro/php2shell/bin-ich-gehackt-anzeichen/).

## Alte surse: logul de erori, PHP-FPM și jurnalele de sistem

Logul de acces arată doar o parte. Pentru o imagine completă, apelați la alte surse:

```bash
# PHP-FPM și serverul web în jurnal, de la o dată
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Autentificări pe server
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Verificarea sarcinilor programate ale tuturor utilizatorilor
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
```

Greșeli tipice la analiză sunt căutarea doar în logul curent, nu și în cele rotite, trecerea cu vederea a fusului orar și luarea unor rezultate individuale ale scannerelor automate drept atac reușit. La fel de riscant este opusul: considerarea unui log de acces fără anomalii drept semnal de liniștire, deși logul de erori și sistemul de fișiere nu au fost încă verificate.

Consemnați fiecare constatare cu ora, sursa și observația într-o cronologie. Această cronologie este ulterior baza deciziilor, a notificărilor către autorități sau asigurători și a raportului final.

## Cum ajută PHP SOS concret?

- Salvăm logurile și fișierele relevante astfel încât să rămână verificabile pentru controale ulterioare.
- Evaluăm împreună logurile de acces, de erori, PHP și de sistem și întocmim o cronologie a incidentului.
- La indicii de compromitere preluăm [răspunsul la incidente](https://phpsos.de/ro/leistungen/incident-response/), cu circumscriere și curățare.
- Configurăm rotația și păstrarea logurilor astfel încât la următorul incident datele necesare să existe.


## Întrebări frecvente

**Cât timp ar trebui să păstrez logurile serverului web?**  
Atât timp cât permite conceptul dumneavoastră de protecție a datelor și cât are sens o analiză. Pentru PHP2Shell, presa de specialitate recomandă păstrarea logurilor începând cu 20.10.2026. Verificați rotația logurilor, pentru ca fișierele mai vechi să nu fie șterse automat.

**Arată logul de acces dacă un atac a reușit?**  
Nu singur. Arată cereri, coduri de stare și dimensiuni ale răspunsurilor, dar nu ce cod a fost executat pe server. Abia împreună cu logul de erori, logul PHP-FPM, modificările de fișiere și jurnalele de sistem rezultă o imagine solidă.

**Am voie să transmit adrese IP din loguri către terți?**  
Adresele IP sunt considerate, de regulă, date cu caracter personal. Pentru clarificarea unui incident și pentru plângeri penale există temeiuri, dar transmiterea ar trebui coordonată cu responsabilul cu protecția datelor.

**De ce văd în log multe atacuri, deși nu s-a întâmplat nimic?**  
Serverele publice sunt scanate automatizat în permanență. Cele mai multe dintre aceste cereri nu duc nicăieri și se încheie cu 404 sau 403. Interesante sunt mai ales cererile cu stare 200 către fișiere necunoscute și tiparele care coincid în timp cu alte urme.

## Surse

- [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/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)