# Analiza logova web-poslužitelja nakon napada: ispravno čitanje access loga

> Analiza access loga nakon napada: najprije osigurati logove, pronaći tipične tragove, koristiti naredbe za Apache i Nginx te posebnosti kod PHP2Shella.

Izvor: https://phpsos.de/hr/ratgeber/logfiles-auswerten/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Tko želi analizirati access log nakon napada, najprije osigurava logove nepromijenjene i potom radi samo s kopijama. Traže se zahtjevi sa statusom 200 na nepoznate PHP datoteke, upadljivi POST zahtjevi, pristupi direktorijima za upload i vremenski obrasci. Za PHP2Shell nema objavljenih, potvrđenih Indicators of Compromise, pa je važna cjelovita slika iz više izvora logova.

## Najprije osigurati, zatim analizirati

Log datoteke se na većini poslužitelja automatski rotiraju i nakon određenog vremena brišu. Nakon napada prvi je korak stoga osigurati postojeće logove prije nego nestanu. To vrijedi i ako još niste sigurni je li se uopće nešto dogodilo. Za PHP2Shell stručni mediji savjetuju čuvanje logova od 20.10.2026.

```bash
# Kopirati logove s vremenskim oznakama i zabilježiti kontrolne zbrojeve
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"
```

Sigurnosnu kopiju dodatno pohranite na drugi sustav. Napadač s pristupom poslužitelju inače bi logove mogao naknadno mijenjati. Kontrolni zbrojevi kasnije pokazuju da je kopija nepromijenjena. Ako je potrebna sigurnosna kopija prihvatljiva na sudu, primjerice za prijavu ili osiguranje, osiguranje bi trebala preuzeti [IT forenzika](https://phpsos.de/hr/leistungen/it-forensik/).

> **Važno:**
> Provjerite rotaciju logova (`/etc/logrotate.d/`) i privremeno produljite čuvanje kako se tijekom analize ne bi brisale dodatne datoteke.

## Gdje su logovi i kako je građen jedan redak

Mjesta pohrane ovise o distribuciji i sučelju za upravljanje. Tipične putanje:

| Sustav | Access i error log |
|---|---|
| Debian, Ubuntu s Apacheom | `/var/log/apache2/` |
| RHEL, AlmaLinux, Rocky s Apacheom | `/var/log/httpd/` |
| Nginx | `/var/log/nginx/` |
| Plesk | `/var/www/vhosts/system/<domain>/logs/` |
| PHP-FPM | `/var/log/php*-fpm.log` ili u journalu |

U raširenom Combined formatu svaki redak sadrži adresu klijenta, datum i vrijeme, metodu i putanju zahtjeva, statusni kod, veličinu odgovora u bajtovima, referer i user agent. Pripazite na vremensku zonu u vremenskoj oznaci, osobito kad logove usklađujete s porukama u UTC-u. PHP2Shell zakrpe objavljene su primjerice 21.10.2026. u 14:00 UTC, dakle u 16 sati po njemačkom vremenu.

Ako je Vaša web-stranica iza proxyja, CDN-a ili load balancera, u logu je možda samo njihova adresa. Prava adresa posjetitelja tada se nalazi u zasebnom polju ili u logovima usluge postavljene ispred.

### Bez naredbenog retka: logovi u panelu ili kod pružatelja hostinga

Nema svaki operater pristup shellu. Kod shared hostinga ili upravljanih poslužitelja sučelja za upravljanje obično nude prikaz logova i preuzimanje access i error logova. Preuzmite datoteke za cijelo dostupno razdoblje i sigurno ih pohranite. Pisanim putem pitajte pružatelja hostinga koliko se dugo logovi čuvaju i mogu li se starija stanja osigurati prije nego isteknu.

Pritom imajte na umu zaštitu podataka: logovi sadrže IP adrese i često dodatne osobne podatke. Kopije pohranite uz zaštitu pristupa, dajte ih samo osobama kojima su potrebne za razjašnjavanje i odredite kada se nakon zaključenja incidenta brišu.

## Analiza access loga: najvažniji upiti

Sljedeće naredbe samo čitaju i prikladne su za Nginx i Apache u Combined formatu. Rotirane i komprimirane datoteke pretražujete s `zgrep` ili `zcat`.

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

# Uspješni zahtjevi na PHP datoteke, po učestalosti
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# PHP pozivi u direktorijima za upload, cache ili slike
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# POST zahtjevi po odredištu i adresi
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Pogreške 5xx po satu: nakupine mogu upućivati na PHP procese koji se ruše
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Uključiti rotirane logove
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'
```

Kod prvog upita osobito zanimaju nazivi datoteka koje ne poznajete ili koje ne pripadaju aplikaciji. Sumnjive datoteke usporedite s datotečnim sustavom: kada su stvorene, kome pripadaju, što u njima piše? Napomene o tome daje vodič [Prepoznavanje i uklanjanje webshellova](https://phpsos.de/hr/ratgeber/webshell-erkennen/).

## Posebnosti kod PHP2Shella

Kod PHP2Shella ranjivosti su u obradi zahtjeva u samom PHP-u. Kod mod_php-a exploit je pokazan i prije nego što se uopće izvrši kod aplikacije. To znači: zahtjev na posve normalnu stranicu može biti dovoljan. U access logu takav zahtjev možda izgleda neupadljivo jer sadržaj tijela zahtjeva tamo ne stoji.

Nema objavljenih, potvrđenih Indicators of Compromise. Zato pazite na ponašanje i povezanosti, primjerice od 17.10.2026., prema medijskim izvješćima prvog opaženog pokušaja napada:

- Nakupine pogrešaka 500 ili prekinutih odgovora na obične stranice.
- Poruke o iscrpljenoj memoriji ili prekinutim workerima u error i PHP-FPM logu.
- Nove PHP datoteke ili izmijenjene datoteke ubrzo nakon takvih nakupina.
- Novi cron zadaci, procesi ili odlazne veze pod korisnikom web-poslužitelja.

Nijedan od tih signala sam nije dokaz. Zajedno s drugim tragovima ipak daju sliku koja odgovara na pitanje o kompromitaciji ili opravdava dublje istraživanje. Pregled znakova nalazi se na stranici [Jesam li već kompromitiran?](https://phpsos.de/hr/php2shell/bin-ich-gehackt-anzeichen/).

## Dodatni izvori: error log, PHP-FPM i sistemski zapisi

Access log pokazuje samo dio. Za potpunu sliku uključite dodatne izvore:

```bash
# PHP-FPM i web-poslužitelj u journalu od određenog datuma
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Prijave na poslužitelj
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Provjeriti planirane zadatke svih korisnika
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
```

Tipične pogreške pri analizi su pretraživanje samo aktualnog umjesto i rotiranih logova, previđanje vremenske zone i smatranje pojedinačnih pogodaka automatiziranih skenera uspješnim napadom. Jednako je rizično suprotno: neupadljiv access log shvatiti kao otklanjanje uzbune iako error log i datotečni sustav još nisu provjereni.

Svaki nalaz zabilježite s vremenom, izvorom i opažanjem u vremenskom slijedu. Taj je vremenski slijed kasnije osnova za odluke, za prijave tijelima ili osiguravateljima i za završno izvješće.

## Kako PHP SOS konkretno pomaže?

- Logove i relevantne datoteke osiguravamo tako da za kasnije provjere ostanu sljedivi.
- Access, error, PHP i sistemske logove analiziramo zajedno i izrađujemo vremenski slijed incidenta.
- Kod naznaka kompromitacije preuzimamo [odgovor na incident](https://phpsos.de/hr/leistungen/incident-response/) s obuzdavanjem i čišćenjem.
- Rotaciju i čuvanje logova postavljamo tako da kod sljedećeg incidenta budu dostupni potrebni podaci.


## Česta pitanja

**Koliko dugo trebam čuvati logove web-poslužitelja?**  
Koliko to dopušta Vaš koncept zaštite podataka i koliko je analiza smislena. Za PHP2Shell stručni mediji savjetuju čuvanje logova od 20.10.2026. Provjerite rotaciju logova kako se starije datoteke ne bi automatski brisale.

**Pokazuje li access log je li napad bio uspješan?**  
Ne sam. Pokazuje zahtjeve, statusne kodove i veličine odgovora, ali ne koji je kod izvršen na poslužitelju. Tek zajedno s error logom, PHP-FPM logom, izmjenama datoteka i sistemskim zapisima nastaje pouzdana slika.

**Smijem li IP adrese iz logova davati trećima?**  
IP adrese se u pravilu smatraju osobnim podacima. Za razjašnjavanje incidenta i kaznene prijave doduše postoje osnove, ali dijeljenje treba uskladiti sa službenikom za zaštitu podataka.

**Zašto u logu vidim mnogo napada iako se ništa nije dogodilo?**  
Javni se poslužitelji neprestano automatizirano skeniraju. Većina tih zahtjeva ide u prazno i završava s 404 ili 403. Zanimljivi su ponajprije zahtjevi sa statusom 200 na nepoznate datoteke i obrasci koji se vremenski poklapaju s drugim tragovima.

## Izvori

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