Veebiserveri logide analüüs pärast rünnakut: juurdepääsulogi õige lugemine

Lühidalt: Kes soovib pärast rünnakut juurdepääsulogi analüüsida, turvab logid esmalt muutmata kujul ja töötab seejärel ainult koopiatega. Otsitakse päringuid olekuga 200 tundmatutele PHP failidele, kahtlaseid POST-päringuid, juurdepääse üleslaadimiskataloogidele ja ajalisi mustreid. PHP2Shelli kohta ei ole avaldatud kinnitatud kompromiteerimisnäitajaid (Indicators of Compromise), seetõttu loeb mitme logiallika üldpilt.

Esmalt turvata, siis analüüsida

Logifaile rotatsioonitakse enamikus serverites automaatselt ja kustutatakse kindla aja järel. Pärast rünnakut on seetõttu esimene samm olemasolevad logid turvata, enne kui need kaovad. See kehtib ka siis, kui te ei ole veel kindel, kas üldse midagi juhtus. PHP2Shelli kohta soovitab erialaajakirjandus logisid säilitada alates 20.10.2026.

# Logid ajatemplitega kopeerida ja kontrollsummad fikseerida
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"

Hoidke varukoopiat lisaks teises süsteemis. Serveris juurdepääsuga ründaja võiks logisid muidu tagantjärele muuta. Kontrollsummad näitavad hiljem, et koopia on muutmata. Kui on vaja kohtukõlblikku turvamist, näiteks avalduse või kindlustuse jaoks, peaks turvamise üle võtma IT-forensika.

Kus logid asuvad ja kuidas rida on üles ehitatud

Salvestuskohad sõltuvad distributsioonist ja haldusliidesest. Tüüpilised teed:

Levinud Combined-vormingus sisaldab iga rida kliendi aadressi, kuupäeva ja kellaaja, päringu meetodit ja teed, olekukoodi, vastuse suurust baitides, Refererit ja User-Agenti. Pöörake tähelepanu ajatempli ajavööndile, eriti kui võrdlete logisid UTC-s olevate teadetega. PHP2Shelli paigad avaldati näiteks 21.10.2026 kell 14:00 UTC ehk Saksamaa aja järgi kell 16.

Kui teie veebisait asub proksi, CDN-i või koormusjaoturi taga, on logis võib-olla ainult selle aadress. Külastaja tegelik aadress asub siis eraldi väljal või eelneva teenuse logides.

Ilma käsureata: logid paneelis või veebimajutaja juures

Mitte igal haldajal ei ole shelli juurdepääsu. Jagatud veebimajutuses või hallatavates serverites pakuvad haldusliidesed enamasti logivaadet ja juurdepääsu- ning vealogide allalaadimist. Laadige failid alla kogu saadaoleva perioodi kohta ja hoidke neid turvaliselt. Küsige oma veebimajutajalt kirjalikult, kui kaua logisid säilitatakse ja kas vanemaid seise saab turvata, enne kui need aeguvad.

Pidage seejuures silmas andmekaitset: logid sisaldavad IP-aadresse ja sageli muid isikuandmeid. Salvestage koopiad juurdepääsukaitsega, edastage neid ainult isikutele, kes neid selgitamiseks vajavad, ja määrake, millal need pärast intsidendi lõppu kustutatakse.

Juurdepääsulogi analüüs: tähtsaimad päringud

Järgmised käsud ainult loevad ja sobivad Nginxile ning Apache'ile Combined-vormingus. Rotatsioonitud ja pakitud faile otsite käskudega zgrep või zcat.

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

# Õnnestunud päringud PHP failidele, sageduse järgi
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# PHP väljakutsed üleslaadimis-, vahemälu- või pildikataloogides
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# POST-päringud sihtmärgi ja aadressi järgi
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Vead 5xx tunni kaupa: kuhjumised võivad viidata kokku jooksvatele PHP protsessidele
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Kaasata rotatsioonitud logid
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

Esimese päringu puhul huvitavad eelkõige failinimed, mida te ei tunne või mis ei kuulu rakenduse juurde. Võrrelge kahtlaseid faile failisüsteemiga: millal need loodi, kellele kuuluvad, mis neis seisab? Vihjeid annab juhend Veebishellide tuvastamine ja eemaldamine.

PHP2Shelli eripärad

PHP2Shelli puhul asuvad turvaaugud PHP enda päringutöötluses. mod_php puhul näidati ärakasutust enne, kui rakenduse kood üldse käivitub. See tähendab: päring täiesti tavalisele lehele võib piisata. Juurdepääsulogis võib selline päring paista märkamatuna, sest päringu keha sisu seal ei ole.

Avaldatud kinnitatud kompromiteerimisnäitajaid ei ole. Pöörake seetõttu tähelepanu käitumisele ja seostele, näiteks alates 17.10.2026, meediaraportite kohaselt esimesest täheldatud rünnakukatsest:

• Vigade 500 või katkestatud vastuste kuhjumised tavalistel lehtedel.
• Teated ammendunud mälu või lõpetatud töötajate kohta vealogis ja PHP-FPM-i logis.
• Uued PHP failid või muudetud failid varsti pärast selliseid kuhjumisi.
• Uued cron-ülesanded, protsessid või väljaminevad ühendused veebiserveri kasutaja all.

Ükski neist signaalidest ei ole üksi tõend. Koos teiste jälgedega annavad need aga pildi, mis vastab kompromiteerimise küsimusele või põhjendab sügavamat uurimist. Tunnuste ülevaate leiate lehelt Kas mind on juba kompromiteeritud?.

Muud allikad: vealogi, PHP-FPM ja süsteemilogid

Juurdepääsulogi näitab ainult osa. Täieliku pildi saamiseks kasutage lisaks muid allikaid:

# PHP-FPM ja veebiserver žurnaalis alates kuupäevast
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Sisselogimised serverisse
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Kõigi kasutajate ajastatud ülesannete kontroll
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Tüüpilised vead analüüsil on otsida ainult praegust, mitte ka rotatsioonitud logisid, ajavööndi märkamata jätmine ja automatiseeritud skannerite üksikute tabamuste pidamine õnnestunud rünnakuks. Sama riskantne on vastupidine: märkamatut juurdepääsulogi pidada hoiatuse tühistamiseks, kuigi vealogi ja failisüsteem on veel kontrollimata.

Märkige iga leid kellaaja, allika ja tähelepanekuga ajajoonele. See ajajoon on hiljem aluseks otsustele, teavitustele ametiasutustele või kindlustajale ja lõpparuandele.

Kuidas PHP SOS konkreetselt aitab?

• Turvame logid ja asjakohased failid nii, et need jäävad hilisemate kontrollide jaoks jälgitavaks.
• Analüüsime juurdepääsu-, vea-, PHP- ja süsteemilogisid koos ning koostame intsidendi ajajoone.
• Kompromiteerimise vihjete korral võtame üle intsidendile reageerimise koos piiramise ja puhastamisega.
• Seame logide rotatsiooni ja säilituse nii, et järgmise intsidendi korral on vajalikud andmed olemas.

Korduma kippuvad küsimused

Allikad

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