Stručne: Kto chce po útoku vyhodnotiť access log, najprv zabezpečí logy nezmenené a potom pracuje iba s kópiami. Hľadajú sa požiadavky so stavom 200 na neznáme súbory PHP, nápadné požiadavky POST, prístupy do adresárov s uploadmi a časové vzory. Pre PHP2Shell neexistujú zverejnené, potvrdené Indicators of Compromise, preto rozhoduje celkový obraz z viacerých zdrojov logov.
Najprv zabezpečiť, potom vyhodnotiť
Súbory logov sa na väčšine serverov automaticky rotujú a po pevnom čase mažú. Po útoku je preto prvým krokom zabezpečiť existujúce logy skôr, než zmiznú. Platí to aj vtedy, keď si ešte nie ste istí, či sa vôbec niečo stalo. K PHP2Shell odborná tlač radí uchovávať logy od 20. 10. 2026.
# Skopírovať logy s časovými pečiatkami a zachytiť kontrolné súčty
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"
Zálohu uložte navyše na iný systém. Útočník s prístupom na server by inak mohol logy dodatočne zmeniť. Kontrolné súčty neskôr ukážu, že kópia je nezmenená. Ak je potrebné zabezpečenie použiteľné pred súdom, napríklad pre trestné oznámenie alebo poistenie, malo by zabezpečenie prevziať IT forenzná analýza.
Skontrolujte rotáciu logov (/etc/logrotate.d/) a dočasne predĺžte uchovávanie, aby sa počas analýzy nemazali ďalšie súbory.
Kde logy ležia a ako je zostavený riadok
Miesta uloženia závisia od distribúcie a administračného rozhrania. Typické cesty:
| Systém | Access log a error log |
|---|---|
| Debian, Ubuntu s Apache | /var/log/apache2/ |
| RHEL, AlmaLinux, Rocky s Apache | /var/log/httpd/ |
| Nginx | /var/log/nginx/ |
| Plesk | /var/www/vhosts/system/<domain>/logs/ |
| PHP-FPM | /var/log/php*-fpm.log alebo v žurnáli |
V rozšírenom formáte Combined obsahuje každý riadok adresu klienta, dátum a čas, metódu a cestu požiadavky, stavový kód, veľkosť odpovede v bajtoch, referer a user agent. Dbajte na časové pásmo v časovej pečiatke, najmä ak logy porovnávate s hláseniami v UTC. Záplaty PHP2Shell boli napríklad zverejnené 21. 10. 2026 o 14:00 UTC, teda o 16:00 nemeckého času.
Ak váš web leží za proxy, CDN alebo load balancerom, môže byť v logu uvedená iba jeho adresa. Skutočná adresa návštevníka sa potom nachádza vo vlastnom poli alebo v logoch predradenej služby.
Bez príkazového riadka: logy v paneli alebo u poskytovateľa
Nie každý prevádzkovateľ má prístup k shellu. Pri zdieľanom hostingu alebo spravovaných serveroch ponúkajú administračné rozhrania zvyčajne zobrazenie logov a stiahnutie logov access a error. Stiahnite súbory za celé dostupné obdobie a bezpečne ich uchovajte. Opýtajte sa poskytovateľa hostingu písomne, ako dlho sa logy uchovávajú a či sa dajú staršie stavy zabezpečiť, skôr než vypršia.
Pritom dbajte na ochranu údajov: logy obsahujú adresy IP a často ďalšie osobné údaje. Kópie ukladajte s ochranou prístupu, odovzdávajte ich iba osobám, ktoré ich potrebujú na objasnenie, a určite, kedy sa po uzavretí incidentu zmažú.
Vyhodnotiť access log: najdôležitejšie dotazy
Nasledujúce príkazy iba čítajú a hodia sa pre Nginx a Apache vo formáte Combined. Rotované a komprimované súbory prehľadávajte pomocou zgrep alebo zcat.
LOG=/root/sicherung-logs-2026-10-25/nginx/access.log
# Úspešné požiadavky na súbory PHP, podľa početnosti
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40
# Volania PHP v adresároch s uploadmi, cache alebo obrázkami
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"
# Požiadavky POST podľa cieľa a adresy
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40
# Chyby 5xx za hodinu: nahromadenia môžu naznačovať padajúce procesy PHP
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c
# Zahrnúť rotované logy
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'
Pri prvom dotaze zaujímajú obzvlášť názvy súborov, ktoré nepoznáte alebo ktoré nepatria k aplikácii. Podozrivé súbory porovnajte so súborovým systémom: kedy boli vytvorené, komu patria, čo obsahujú? Pokyny k tomu poskytuje príručka Rozpoznať webshell a odstrániť ju.
Osobitosti pri PHP2Shell
Pri PHP2Shell sú zraniteľnosti v spracovaní požiadaviek v samotnom PHP. Pri mod_php bol exploit predvedený ešte predtým, než sa vôbec spustí kód aplikácie. To znamená: môže stačiť požiadavka na úplne normálnu stránku. V access logu môže takáto požiadavka vyzerať nenápadne, pretože obsah tela požiadavky tam nie je.
Neexistujú zverejnené, potvrdené Indicators of Compromise. Dbajte preto na správanie a súvislosti, napríklad od 17. 10. 2026, podľa správ médií prvého pozorovaného pokusu o útok:
- Nahromadenia chýb 500 alebo prerušených odpovedí na bežné stránky.
- Hlásenia o vyčerpanej pamäti alebo ukončených workeroch v error logu a logu PHP-FPM.
- Nové súbory PHP alebo zmenené súbory krátko po takýchto nahromadeniach.
- Nové cronjoby, procesy alebo odchádzajúce spojenia pod používateľom webového servera.
Žiadny z týchto signálov nie je sám o sebe dôkazom. Spolu s inými stopami však dávajú obraz, ktorý odpovie na otázku kompromitácie alebo odôvodní hlbšie vyšetrenie. Prehľad príznakov nájdete na stránke Som už kompromitovaný?.
Ďalšie zdroje: error log, PHP-FPM a systémové záznamy
Access log ukazuje len časť. Pre úplný obraz pribrať ďalšie zdroje:
# PHP-FPM a webový server v žurnáli od určitého dátumu
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200
# Prihlásenia na server
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100
# Skontrolovať plánované úlohy všetkých používateľov
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
Typickými chybami pri vyhodnotení je prehľadávať len aktuálne namiesto aj rotovaných logov, prehliadnuť časové pásmo a považovať jednotlivé nálezy automatizovaných skenerov za úspešný útok. Rovnako riskantný je opak: nenápadný access log považovať za uvoľnenie, hoci error log a súborový systém ešte nie sú skontrolované.
Každý nález zaznamenajte s časom, zdrojom a pozorovaním do časovej osi. Táto časová os je neskôr podkladom pre rozhodnutia, pre oznámenia úradom alebo poisťovateľom a pre záverečnú správu.
Ako konkrétne pomáha PHP SOS?
- Logy a relevantné súbory zabezpečujeme tak, aby zostali dohľadateľné pre neskoršie kontroly.
- Logy access, error, PHP a systémové vyhodnocujeme spoločne a vytvárame časovú os incidentu.
- Pri indíciách kompromitácie preberáme reakciu na incidenty s ohraničením a vyčistením.
- Rotáciu logov a uchovávanie nastavujeme tak, aby boli pri najbližšom incidente potrebné údaje k dispozícii.
Časté otázky
Ako dlho by som mal uchovávať logy webového servera?
Tak dlho, ako to dovoľuje vaša koncepcia ochrany údajov a ako dáva zmysel analýza. K PHP2Shell odborná tlač radí uchovávať logy od 20. 10. 2026. Skontrolujte rotáciu logov, aby sa staršie súbory automaticky nemazali.
Ukazuje access log, či bol útok úspešný?
Nie samotný. Ukazuje požiadavky, stavové kódy a veľkosti odpovedí, nie to, ktorý kód sa na serveri vykonal. Spoľahlivý obraz vzniká až spolu s error logom, logom PHP-FPM, zmenami súborov a systémovými záznamami.
Smiem adresy IP z logov odovzdávať tretím stranám?
Adresy IP sa spravidla považujú za osobné údaje. Pre objasnenie incidentu a pre trestné oznámenia síce existujú základy, odovzdanie by sa však malo dohodnúť so zodpovednou osobou pre ochranu údajov.
Prečo vidím v logu veľa útokov, hoci sa nič nestalo?
Verejné servery sú neustále automatizovane skenované. Väčšina týchto požiadaviek pôjde nazmar a skončí kódom 404 alebo 403. Zaujímavé sú predovšetkým požiadavky so stavom 200 na neznáme súbory a vzory, ktoré časovo súvisia s inými stopami.