Analiza dnevnikov spletnega strežnika po napadu: pravilno branje dnevnika dostopov

Na kratko: Kdor želi po napadu analizirati dnevnik dostopov, najprej zavaruje dnevnike nespremenjene in nato dela samo s kopijami. Išče se zahteve s statusom 200 na neznane datoteke PHP, sumljive zahteve POST, dostope do map za nalaganje in časovne vzorce. Za PHP2Shell ni objavljenih, potrjenih Indicators of Compromise, zato šteje celotna slika iz več virov dnevnikov.

Najprej zavarujte, nato analizirajte

Dnevniške datoteke se na večini strežnikov samodejno rotirajo in po določenem času izbrišejo. Po napadu je zato prvi korak, da obstoječe dnevnike zavarujete, preden izginejo. To velja tudi, če še niste prepričani, ali se je sploh kaj zgodilo. Za PHP2Shell strokovni tisk svetuje hranjenje dnevnikov od 20. 10. 2026.

# Dnevnike kopirajte s časovnimi žigi in zabeležite kontrolne vsote
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"

Varnostno kopijo dodatno shranite na drug sistem. Napadalec z dostopom do strežnika bi sicer lahko dnevnike naknadno spremenil. Kontrolne vsote pozneje pokažejo, da je kopija nespremenjena. Če je potrebna sodno uporabna zavarovanje, na primer za ovadbo ali zavarovalnico, naj zavarovanje prevzame IT-forenzika.

Kje ležijo dnevniki in kako je zgrajena vrstica

Mesta shranjevanja so odvisna od distribucije in upravljalnega vmesnika. Tipične poti:

V razširjeni obliki Combined vsaka vrstica vsebuje naslov odjemalca, datum in uro, metodo in pot zahteve, statusno kodo, velikost odgovora v bajtih, referer in user agent. Bodite pozorni na časovno območje v časovnem žigu, še posebej pri primerjavi dnevnikov z navedbami v UTC. Popravki PHP2Shell so bili na primer objavljeni 21. 10. 2026 ob 14.00 UTC, torej ob 16.00 po nemškem času.

Če je vaša spletna stran za proxyjem, CDN ali load balancerjem, je v dnevniku morda samo njegov naslov. Pravi naslov obiskovalca je tedaj v lastnem polju ali v dnevnikih predhodne storitve.

Brez ukazne vrstice: dnevniki v panelu ali pri ponudniku gostovanja

Vsak upravljavec nima dostopa do lupine. Pri shared hostingu ali upravljanih strežnikih upravljalni vmesniki običajno ponujajo pogled dnevnikov in prenos dnevnikov dostopov in napak. Datoteke prenesite za celotno razpoložljivo obdobje in jih varno hranite. Pisno vprašajte svojega ponudnika gostovanja, kako dolgo se dnevniki hranijo in ali je mogoče starejša stanja zavarovati, preden potečejo.

Pri tem upoštevajte varstvo podatkov: dnevniki vsebujejo naslove IP in pogosto druge osebne podatke. Kopije shranite z zaščito dostopa, posredujte jih samo osebam, ki jih potrebujejo za razjasnitev, in določite, kdaj se po zaključku incidenta izbrišejo.

Analiza dnevnika dostopov: najpomembnejše poizvedbe

Naslednji ukazi samo berejo in so primerni za Nginx in Apache v obliki Combined. Rotirane in stisnjene datoteke preiščete z zgrep ali zcat.

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

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

# Klici PHP v mapah za nalaganje, predpomnilnik ali slike
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# Zahteve POST po cilju in naslovu
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Napake 5xx po urah: kopičenja lahko kažejo na sesuvajoče se procese PHP
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Vključite rotirane dnevnike
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

Pri prvi poizvedbi so posebej zanimiva imena datotek, ki jih ne poznate ali ne sodijo k aplikaciji. Sumljive datoteke primerjajte z datotečnim sistemom: kdaj so bile ustvarjene, komu pripadajo, kaj je v njih? Napotke daje vodnik Prepoznavanje in odstranitev webshellov.

Posebnosti pri PHP2Shell

Pri PHP2Shell sta ranljivosti v obdelavi zahtev v samem PHP. Pri mod_php je bil exploit prikazan, še preden sploh teče koda aplikacije. To pomeni: lahko zadošča zahteva na povsem običajno stran. V dnevniku dostopov je taka zahteva morda videti neopazna, ker vsebine telesa zahteve tam ni.

Objavljenih, potrjenih Indicators of Compromise ni. Zato bodite pozorni na vedenje in povezave, na primer od 17. 10. 2026, po poročilih medijev prvega opaženega poskusa napada:

• Kopičenja napak 500 ali prekinjenih odgovorov na običajne strani.
• Sporočila o izčrpanem pomnilniku ali končanih workerjih v dnevniku napak in dnevniku PHP-FPM.
• Nove datoteke PHP ali spremenjene datoteke kmalu po takih kopičenjih.
• Novi cron opravila, procesi ali odhodne povezave pod uporabnikom spletnega strežnika.

Noben od teh signalov sam ni dokaz. Skupaj z drugimi sledmi pa dajo sliko, ki odgovori na vprašanje o kompromitaciji ali utemelji globlji pregled. Pregled znakov najdete na strani Ali sem že kompromitiran?.

Dodatni viri: dnevnik napak, PHP-FPM in sistemski dnevniki

Dnevnik dostopov pokaže samo del. Za popolno sliko dodajte druge vire:

# PHP-FPM in spletni strežnik v journalu od datuma
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

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

# Preverite načrtovana opravila vseh uporabnikov
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Tipične napake pri analizi so, da se preišče samo aktualni namesto tudi rotiranih dnevnikov, da se spregleda časovno območje in da se posamezni zadetki samodejnih skenerjev štejejo za uspešen napad. Enako tvegano je nasprotno: neopazen dnevnik dostopov šteti za razrešnico, čeprav dnevnik napak in datotečni sistem še nista preverjena.

Vsako najdbo zapišite s časom, virom in opažanjem v časovnico. Ta časovnica je pozneje podlaga za odločitve, za prijave organom ali zavarovalnicam in za zaključno poročilo.

Kako PHP SOS pomaga konkretno?

• Dnevnike in pomembne datoteke zavarujemo tako, da ostanejo sledljivi za poznejša preverjanja.
• Dnevnike dostopov, napak, PHP in sistemske dnevnike ovrednotimo skupaj in izdelamo časovnico incidenta.
• Ob namigih na kompromitacijo prevzamemo odziv na incident z zajezitvijo in čiščenjem.
• Rotacijo dnevnikov in hranjenje uredimo tako, da so ob naslednjem incidentu potrebni podatki na voljo.

Pogosta vprašanja

Viri

• TechTarget: PHP2Shell, 22M exposed servers at risk
• php.net: varnostna obvestila
• BSI IT-Grundschutz