# Vyhodnocení logů webového serveru po útoku: jak číst access log

> Access log po útoku vyhodnoťte správně: nejdřív logy zajistěte, najděte typické stopy, použijte příkazy pro Apache a Nginx a zvláštnosti PHP2Shell.

Zdroj: https://phpsos.de/cs/ratgeber/logfiles-auswerten/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**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.

```bash
# 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](https://phpsos.de/cs/leistungen/it-forensik/).

> **Důležité:**
> 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`.

```bash
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](https://phpsos.de/cs/ratgeber/webshell-erkennen/).

## 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?](https://phpsos.de/cs/php2shell/bin-ich-gehackt-anzeichen/).

## Další zdroje: error log, PHP-FPM a systémové protokoly

Access log ukazuje jen část. Pro úplný obraz přibereme další zdroje:

```bash
# 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](https://phpsos.de/cs/leistungen/incident-response/) 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.

## Zdroje

- [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: bezpečnostní oznámení](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)