Webszerver-naplók kiértékelése egy támadás után: az access-napló helyes olvasása

Röviden: Aki egy támadás után ki akarja értékelni az access-naplót, először változatlanul lementi a naplókat, utána csak másolatokkal dolgozik. Keresett elemek: 200-as státuszú kérések ismeretlen PHP-fájlokra, feltűnő POST-kérések, hozzáférések a feltöltési könyvtárakhoz és időbeli minták. A PHP2Shellhez nincsenek közzétett, megerősített Indicators of Compromise, ezért több naplóforrás összképe számít.

Először mentés, utána kiértékelés

A naplófájlokat a legtöbb szerveren automatikusan rotálják, és egy rögzített idő után törlik. Egy támadás után ezért az első lépés a meglévő naplók lementése, mielőtt eltűnnének. Ez akkor is érvényes, ha még nem biztos abban, hogy egyáltalán történt-e valami. A PHP2Shellről a szakmai sajtó azt javasolja, hogy a naplókat 2026. 10. 20-tól őrizze meg.

# Naplók másolása időbélyegekkel és ellenőrző összegek rögzítése
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"

A mentést tegye ki emellett egy másik rendszerre is. A szerverhez hozzáférő támadó különben utólag módosíthatná a naplókat. Az ellenőrző összegek később megmutatják, hogy a másolat változatlan. Ha bíróság előtt is megálló mentésre van szükség, például feljelentéshez vagy a biztosításhoz, a mentést egy IT-forenzikának kell átvennie.

Hol vannak a naplók, és hogyan épül fel egy sor

A tárolási helyek a disztribúciótól és a kezelőfelülettől függnek. Tipikus útvonalak:

Az elterjedt Combined formátumban minden sor tartalmazza a kliens címét, a dátumot és az időpontot, a kérés metódusát és útvonalát, a státuszkódot, a válasz méretét bájtban, a referert és a user-agentet. Ügyeljen az időbélyeg időzónájára, különösen ha a naplókat UTC-ben megadott üzenetekkel veti össze. A PHP2Shell javításait például 2026. 10. 21-én 14:00 UTC-kor adták ki, vagyis német idő szerint 16 órakor.

Ha a weboldala proxy, CDN vagy load balancer mögött van, a naplóban esetleg csak ennek a címe szerepel. A látogató valódi címe ekkor egy külön mezőben vagy az előtte álló szolgáltatás naplóiban található.

Parancssor nélkül: naplók a panelben vagy a tárhelyszolgáltatónál

Nem minden üzemeltetőnek van shell-hozzáférése. Megosztott tárhelynél vagy gondozott szervereknél a kezelőfelületek többnyire naplónézetet és az access- és error-naplók letöltését kínálják. Töltse le a fájlokat a teljes elérhető időszakra, és őrizze meg biztonságosan. Kérdezze meg írásban a tárhelyszolgáltatóját, meddig tárolják a naplókat, és lementhetők-e a régebbi állapotok, mielőtt lejárnának.

Vegye figyelembe az adatvédelmet is: a naplók IP-címeket és gyakran további személyes adatokat tartalmaznak. A másolatokat hozzáférés-védetten tárolja, csak olyan személyeknek adja tovább, akiknek a felderítéshez szükségük van rájuk, és rögzítse, mikor törlik őket az incidens lezárása után.

Az access-napló kiértékelése: a legfontosabb lekérdezések

A következő parancsok csak olvasnak, és Nginxhez és Apache-hoz is alkalmasak Combined formátumban. A rotált és tömörített fájlokat a zgrep-pel vagy a zcat-tal keresse át.

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

# Sikeres kérések PHP-fájlokra, gyakoriság szerint
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# PHP-hívások feltöltési, gyorsítótár- vagy képkönyvtárakban
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# POST-kérések cél és cím szerint
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# 5xx hibák óránként: a halmozódások összeomló PHP-folyamatokra utalhatnak
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# A rotált naplók bevonása
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

Az első lekérdezésnél különösen azok a fájlnevek érdekesek, amelyeket nem ismer, vagy amelyek nem tartoznak az alkalmazáshoz. Vesse össze a gyanús fájlokat a fájlrendszerrel: mikor hozták létre őket, kihez tartoznak, mi van bennük? Támpontokat ehhez a Webshellek felismerése és eltávolítása útmutató ad.

A PHP2Shell sajátosságai

A PHP2Shellnél a rések a PHP kéréskezelésében vannak. A mod_php esetében már azelőtt bemutattak egy exploitot, hogy az alkalmazáskód egyáltalán futna. Ez azt jelenti: egy teljesen normális oldalra irányuló kérés is elég lehet. Az access-naplóban egy ilyen kérés esetleg feltűnésmentesnek látszik, mert a kérés törzsének tartalma ott nem szerepel.

Nincsenek közzétett, megerősített Indicators of Compromise. Figyeljen ezért a viselkedésre és az összefüggésekre, például 2026. 10. 17-től, a médiabeszámolók szerint az első megfigyelt támadási kísérlet időpontjától:

• Az 500-as hibák vagy a megszakadt válaszok halmozódása szokásos oldalakon.
• Üzenetek kimerült memóriáról vagy leállított workerekről az error- és a PHP-FPM-naplóban.
• Új PHP-fájlok vagy módosított fájlok nem sokkal ilyen halmozódások után.
• Új cron-feladatok, folyamatok vagy kimenő kapcsolatok a webszerver felhasználója alatt.

E jelek egyike sem bizonyíték önmagában. Más nyomokkal együtt azonban olyan képet adnak, amely megválaszolja a feltörés kérdését, vagy mélyebb vizsgálatot indokol. A jelek áttekintését a Már feltörték a rendszeremet? oldalon találja.

További források: error-napló, PHP-FPM és rendszernaplók

Az access-napló csak egy részt mutat. A teljes képhez vegyen igénybe további forrásokat:

# PHP-FPM és webszerver a journalban egy dátumtól
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Bejelentkezések a szerveren
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Az összes felhasználó ütemezett feladatainak ellenőrzése
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

A kiértékelés tipikus hibái: csak az aktuális naplót keresik át a rotáltak helyett is, az időzónát figyelmen kívül hagyják, és az automatizált szkennerek egyes találatait sikeres támadásnak tekintik. Ugyanilyen kockázatos az ellenkezője: egy feltűnésmentes access-naplót felmentésnek venni, noha az error-naplót és a fájlrendszert még nem ellenőrizték.

Jegyezzen fel minden leletet idővel, forrással és megfigyeléssel egy idővonalon. Ez az idővonal később a döntések, a hatóságoknak vagy biztosítóknak szóló bejelentések és a záró jelentés alapja.

Hogyan segít konkrétan a PHP SOS?

• Úgy mentjük le a naplókat és a lényeges fájlokat, hogy későbbi vizsgálatokhoz követhetők maradjanak.
• Az access-, error-, PHP- és rendszernaplókat együtt értékeljük ki, és idővonalat készítünk az incidensről.
• Feltörésre utaló jelek esetén átvesszük az incidenskezelést (incident response) megfékezéssel és megtisztítással.
• Úgy állítjuk be a naplórotációt és a megőrzést, hogy a következő incidensnél meglegyenek a szükséges adatok.

Gyakori kérdések

Források

• TechTarget: PHP2Shell, 22M exposed servers at risk
• php.net: biztonsági közlemények
• BSI IT-Grundschutz (német Szövetségi Információbiztonsági Hivatal)