Stručně: Kdo chce po útoku vyhodnotit access log, nejdřív logy zajistí beze změny a poté pracuje jen s kopiemi. Hledají se požadavky se stavem 200 na neznámé soubory PHP, nápadné požadavky POST, přístupy do adresářů uploadů a časové vzory. Pro PHP2Shell neexistují zveřejněné potvrzené indikátory kompromitace, proto rozhoduje celkový obraz z několika zdrojů logů.
Nejdřív zajistit, pak vyhodnotit
Soubory logů se na většině serverů automaticky rotují a po pevné době mažou. Po útoku je proto prvním krokem zajistit stávající logy dříve, než zmizí. Platí to i tehdy, když si ještě nejste jisti, zda se vůbec něco stalo. K PHP2Shell radí odborný tisk uchovávat logy od 20. 10. 2026.
# Zkopírovat logy s časovými razítky a zaznamenat kontrolní souč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 navíc na jiný systém. Útočník s přístupem k serveru by jinak mohl logy dodatečně změnit. Kontrolní součty později ukážou, že kopie je beze změny. Je-li nutné zajištění použitelné u soudu, například pro trestní oznámení nebo pojišťovnu, mělo by zajištění převzít IT forenzní analýza.
Zkontrolujte rotaci logů (/etc/logrotate.d/) a dočasně prodlužte dobu uchování, aby se během analýzy nemazaly další soubory.
Kde logy leží a jak je řádek postaven
Umístění závisí na distribuci a správním rozhraní. Typické cesty:
| Systém | Access 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 nebo v journalu |
V rozšířeném formátu Combined obsahuje každý řádek adresu klienta, datum a čas, metodu a cestu požadavku, stavový kód, velikost odpovědi v bajtech, referer a user agent. Dávejte pozor na časové pásmo v časovém razítku, zejména když logy porovnáváte s hlášeními v UTC. Záplaty PHP2Shell byly například zveřejněny 21. 10. 2026 ve 14:00 UTC, tedy v 16 hodin německého času.
Pokud je váš web za proxy, CDN nebo load balancerem, může být v logu jen jejich adresa. Skutečná adresa návštěvníka se pak nachází ve zvláštním poli nebo v lozích předřazené služby.
Bez příkazové řádky: logy v panelu nebo u poskytovatele hostingu
Ne každý provozovatel má přístup k shellu. U sdíleného hostingu nebo spravovaných serverů nabízejí správní rozhraní většinou zobrazení logů a stažení logů access a error. Stáhněte soubory za celé dostupné období a bezpečně je uchovejte. Zeptejte se poskytovatele hostingu písemně, jak dlouho se logy uchovávají a zda lze starší stavy zajistit dříve, než vyprší.
Dbejte přitom na ochranu osobních údajů: logy obsahují IP adresy a často další osobní údaje. Kopie ukládejte s ochranou přístupu, předávejte je jen osobám, které je pro objasnění potřebují, a stanovte, kdy se po uzavření incidentu smažou.
Vyhodnocení access logu: nejdůležitější dotazy
Následující příkazy jen čtou a hodí se pro Nginx a Apache ve formátu Combined. Rotované a komprimované soubory prohledáte pomocí zgrep nebo zcat.
LOG=/root/sicherung-logs-2026-10-25/nginx/access.log
# Úspěšné požadavky na soubory PHP, podle četnosti
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40
# Volání PHP ve složkách uploads, cache nebo obrázků
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"
# Požadavky POST podle cíle a adresy
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40
# Chyby 5xx podle hodiny: shluky mohou ukazovat na padající procesy PHP
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c
# Zahrnout rotované logy
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'
U prvního dotazu zajímají zejména názvy souborů, které neznáte nebo které nepatří k aplikaci. Podezřelé soubory porovnejte se souborovým systémem: kdy byly založeny, komu patří, co obsahují? Vodítka dává příručka Jak poznat a odstranit webshell.
Zvláštnosti u PHP2Shell
U PHP2Shell leží zranitelnosti ve zpracování požadavků v samotném PHP. U mod_php byl exploit předveden dříve, než se vůbec spustí kód aplikace. To znamená: může stačit požadavek na zcela normální stránku. V access logu může takový požadavek vypadat nenápadně, protože se v něm obsah těla požadavku neuvádí.
Neexistují zveřejněné potvrzené indikátory kompromitace. Sledujte proto chování a souvislosti, například od 17. 10. 2026, podle zpráv médií prvního pozorovaného pokusu o útok:
- Shluky chyb 500 nebo přerušených odpovědí na běžných stránkách.
- Hlášení o vyčerpané paměti nebo ukončených workerech v error logu a logu PHP-FPM.
- Nové soubory PHP nebo změněné soubory krátce po takových shlucích.
- Nové úlohy cron, procesy nebo odchozí spojení pod uživatelem webového serveru.
Žádný z těchto signálů není sám o sobě důkaz. Spolu s dalšími stopami ale dávají obraz, který odpoví na otázku kompromitace nebo odůvodní hlubší šetření. Přehled příznaků najdete v článku Jsem už kompromitován?.
Další zdroje: error log, PHP-FPM a systémové protokoly
Access log ukazuje jen část. Pro úplný obraz přibereme další zdroje:
# PHP-FPM a webový server v journalu od data
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200
# Přihlášení na server
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100
# Zkontrolovat plánované úlohy všech uživatelů
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
Typické chyby při vyhodnocení jsou prohledávat jen aktuální log místo i rotovaných logů, přehlédnout časové pásmo a považovat jednotlivé nálezy automatizovaných skenerů za úspěšný útok. Stejně riskantní je opak: nenápadný access log pokládat za odvolání poplachu, ačkoli error log a souborový systém ještě nebyly zkontrolovány.
Každý nález si poznamenejte s časem, zdrojem a pozorováním do časové osy. Tato časová osa je později podkladem pro rozhodnutí, pro hlášení úřadům či pojišťovnám a pro závěrečnou zprávu.
Jak konkrétně pomáhá PHP SOS?
- Logy a relevantní soubory zajistíme tak, aby zůstaly dohledatelné pro pozdější kontroly.
- Logy access, error, PHP a systémové vyhodnocujeme společně a vytváříme časovou osu incidentu.
- Při náznacích kompromitace převezmeme reakci na incident se zadržením a vyčištěním.
- Rotaci logů a dobu uchování nastavíme tak, aby při příštím incidentu byla potřebná data k dispozici.
Časté dotazy
Jak dlouho mám logy webového serveru uchovávat?
Tak dlouho, jak dovoluje vaše koncepce ochrany osobních údajů a jak dává smysl analýza. K PHP2Shell radí odborný tisk uchovávat logy od 20. 10. 2026. Zkontrolujte rotaci logů, aby se starší soubory automaticky nemazaly.
Ukazuje access log, zda byl útok úspěšný?
Ne samo o sobě. Ukazuje požadavky, stavové kódy a velikosti odpovědí, ale ne to, jaký kód se na serveru provedl. Spolehlivý obraz vznikne až spolu s error logem, logem PHP-FPM, změnami souborů a systémovými protokoly.
Smím IP adresy z logů předávat třetím stranám?
IP adresy se zpravidla považují za osobní údaje. Pro vyšetření incidentu a trestní oznámení sice existují právní základy, předání by se ale mělo dohodnout s pověřencem pro ochranu osobních údajů.
Proč vidím v logu mnoho útoků, ačkoli se nic nestalo?
Veřejné servery jsou neustále automaticky skenovány. Většina těchto požadavků vyzní do prázdna a skončí kódem 404 nebo 403. Zajímavé jsou hlavně požadavky se stavem 200 na neznámé soubory a vzory, které časově souvisejí s jinými stopami.