Trumpai: Kas nori po atakos analizuoti prieigos žurnalą, pirmiausia išsaugo žurnalus nepakeistus, o po to dirba tik su kopijomis. Ieškoma užklausų su būsena 200 nežinomiems PHP failams, įtartinų POST užklausų, prieigų prie įkėlimų katalogų ir laiko šablonų. PHP2Shell atveju paskelbtų, patvirtintų kompromitavimo indikatorių (IOC) nėra, todėl lemia bendras vaizdas iš kelių žurnalų šaltinių.
Pirmiausia išsaugoti, tada analizuoti
Daugelyje serverių žurnalo failai automatiškai rotuojami ir po nustatyto laiko ištrinami. Todėl po atakos pirmas žingsnis yra išsaugoti esamus žurnalus, kol jų neištrynė. Tai galioja ir tada, kai dar nesate tikri, ar apskritai kas nors įvyko. Dėl PHP2Shell specializuota spauda pataria žurnalus saugoti nuo 2026-10-20.
# Nukopijuoti žurnalus su laiko žymėmis ir užfiksuoti kontrolines sumas
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"
Kopiją papildomai padėkite kitoje sistemoje. Užpuolikas su prieiga prie serverio kitaip galėtų žurnalus vėliau pakeisti. Kontrolinės sumos vėliau parodo, kad kopija nepakeista. Jei reikalingas teismui tinkamas išsaugojimas, pavyzdžiui, pareiškimui ar draudimui, išsaugojimą turėtų perimti IT forensika.
Patikrinkite žurnalų rotaciją (/etc/logrotate.d/) ir laikinai pailginkite saugojimą, kad analizės metu nebūtų ištrinti kiti failai.
Kur yra žurnalai ir kaip sudaryta eilutė
Saugojimo vietos priklauso nuo distribucijos ir valdymo sąsajos. Tipiniai keliai:
| Sistema | Prieigos ir klaidų žurnalas |
|---|---|
| Debian, Ubuntu su Apache | /var/log/apache2/ |
| RHEL, AlmaLinux, Rocky su Apache | /var/log/httpd/ |
| Nginx | /var/log/nginx/ |
| Plesk | /var/www/vhosts/system/<domain>/logs/ |
| PHP-FPM | /var/log/php*-fpm.log arba žurnale (journal) |
Paplitusiame Combined formate kiekvienoje eilutėje yra kliento adresas, data ir laikas, užklausos metodas ir kelias, būsenos kodas, atsakymo dydis baitais, Referer ir User-Agent. Atkreipkite dėmesį į laiko juostą laiko žymėje, ypač kai žurnalus lyginate su pranešimais UTC. PHP2Shell pataisos, pavyzdžiui, buvo išleistos 2026-10-21 14:00 UTC, t. y. 16 val. Vokietijos laiku.
Jei jūsų svetainė už tarpinio serverio, CDN ar apkrovos balansuotojo, žurnale galbūt matomas tik jo adresas. Tikrasis lankytojo adresas tuomet yra atskirame lauke arba prieš tai esančios paslaugos žurnaluose.
Be komandinės eilutės: žurnalai skydelyje ar pas hostingo teikėją
Ne kiekvienas operatorius turi shell prieigą. Bendrinamame hostinge ar valdomuose serveriuose valdymo sąsajos dažniausiai turi žurnalų rodinį ir prieigos bei klaidų žurnalų atsisiuntimą. Atsisiųskite failus visam prieinamam laikotarpiui ir saugiai juos saugokite. Raštu paklauskite hostingo teikėjo, kiek laiko žurnalai laikomi ir ar senesnę būseną galima išsaugoti prieš jai pasibaigiant.
Atkreipkite dėmesį į duomenų apsaugą: žurnaluose yra IP adresų ir dažnai kitų asmens duomenų. Kopijas saugokite apsaugotas nuo prieigos, perduokite jas tik asmenims, kuriems jų reikia išaiškinimui, ir nustatykite, kada jos bus ištrintos užbaigus incidentą.
Prieigos žurnalo analizė: svarbiausios užklausos
Toliau pateiktos komandos tik skaito ir tinka Nginx bei Apache Combined formatui. Rotuotus ir suspaustus failus peržiūrėkite su zgrep arba zcat.
LOG=/root/sicherung-logs-2026-10-25/nginx/access.log
# Sėkmingos užklausos PHP failams pagal dažnumą
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40
# PHP iškvietimai įkėlimų, talpyklos ar paveikslėlių kataloguose
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"
# POST užklausos pagal tikslą ir adresą
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40
# 5xx klaidos pagal valandą: kaupimasis gali rodyti stringančius PHP procesus
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c
# Įtraukti rotuotus žurnalus
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'
Pirmoje užklausoje ypač įdomūs failų pavadinimai, kurių nepažįstate arba kurie nepriklauso programai. Įtartinus failus palyginkite su failų sistema: kada jie sukurti, kam priklauso, kas juose parašyta? Nuorodų pateikia vadovas Webshell aptikimas ir šalinimas.
PHP2Shell ypatumai
PHP2Shell atveju pažeidžiamumai yra paties PHP užklausų apdorojime. Esant mod_php exploit buvo parodytas dar prieš pradedant vykdyti programos kodą. Tai reiškia: gali pakakti užklausos visiškai įprastam puslapiui. Prieigos žurnale tokia užklausa gali atrodyti neįtartinai, nes užklausos kūno turinio ten nėra.
Paskelbtų, patvirtintų kompromitavimo indikatorių (IOC) nėra. Todėl atkreipkite dėmesį į elgseną ir sąsajas, pavyzdžiui, nuo 2026-10-17, pasak žiniasklaidos pranešimų, pirmojo pastebėto atakos bandymo dienos:
- Klaidų 500 ar nutrauktų atsakymų kaupimasis įprastuose puslapiuose.
- Pranešimai apie išseksusią atmintį ar pasibaigusius darbinius procesus klaidų ir PHP-FPM žurnale.
- Nauji PHP failai ar pakeisti failai netrukus po tokių kaupimosi atvejų.
- Naujos cron užduotys, procesai ar išeinantys ryšiai žiniatinklio serverio naudotojo vardu.
Nė vienas iš šių signalų pats savaime nėra įrodymas. Tačiau kartu su kitais pėdsakais jie sudaro vaizdą, kuris atsako į klausimą apie kompromitavimą arba pagrindžia gilesnį tyrimą. Požymių apžvalgą rasite straipsnyje Ar jau esu kompromituotas?.
Kiti šaltiniai: klaidų žurnalas, PHP-FPM ir sistemos žurnalai
Prieigos žurnalas rodo tik dalį. Pilnam vaizdui pasitelkite kitus šaltinius:
# PHP-FPM ir žiniatinklio serveris žurnale (journal) nuo datos
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200
# Prisijungimai prie serverio
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100
# Patikrinti visų naudotojų suplanuotas užduotis
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
Tipinės analizės klaidos yra ieškoti tik dabartinio, o ne ir rotuotų žurnalų, nepastebėti laiko juostos ir pavienius automatizuotų skenerių radinius palaikyti sėkminga ataka. Taip pat rizikinga priešinga klaida: neįtartiną prieigos žurnalą vertinti kaip atšaukimą, nors klaidų žurnalas ir failų sistema dar nepatikrinti.
Kiekvieną radinį užsirašykite su laiku, šaltiniu ir pastebėjimu laiko juostoje. Ši laiko juosta vėliau yra sprendimų, pranešimų institucijoms ar draudikams ir baigiamosios ataskaitos pagrindas.
Kaip PHP SOS padeda konkrečiai?
- Žurnalus ir svarbius failus išsaugome taip, kad jie vėlesnėms patikroms liktų atsekami.
- Prieigos, klaidų, PHP ir sistemos žurnalus analizuojame kartu ir sudarome incidento laiko juostą.
- Esant kompromitavimo požymiams perimame incidentų valdymą su suvaldymu ir išvalymu.
- Žurnalų rotaciją ir saugojimą nustatome taip, kad per kitą incidentą reikalingi duomenys būtų.
Dažni klausimai
Kiek laiko turėčiau saugoti žiniatinklio serverio žurnalus?
Tiek, kiek leidžia jūsų duomenų apsaugos koncepcija ir kol analizė prasminga. Dėl PHP2Shell specializuota spauda pataria žurnalus saugoti nuo 2026-10-20. Patikrinkite žurnalų rotaciją, kad senesni failai nebūtų ištrinti automatiškai.
Ar prieigos žurnalas parodo, ar ataka buvo sėkminga?
Ne vienas. Jis rodo užklausas, būsenos kodus ir atsakymų dydžius, bet ne tai, koks kodas buvo vykdomas serveryje. Patikimas vaizdas atsiranda tik kartu su klaidų žurnalu, PHP-FPM žurnalu, failų pakeitimais ir sistemos žurnalais.
Ar galiu žurnalų IP adresus perduoti trečiosioms šalims?
IP adresai paprastai laikomi asmens duomenimis. Incidento išaiškinimui ir baudžiamiesiems pareiškimams pagrindų yra, bet perdavimą reikėtų suderinti su duomenų apsaugos pareigūnu.
Kodėl žurnale matau daug atakų, nors nieko neįvyko?
Vieši serveriai nuolat automatizuotai skenuojami. Dauguma šių užklausų baigiasi niekuo ir atsakomos 404 ar 403. Įdomiausios yra užklausos su būsena 200 nežinomiems failams ir šablonai, laiko atžvilgiu sutampantys su kitais pėdsakais.