Verkkopalvelimen lokien analysointi hyökkäyksen jälkeen: pääsylokin oikea lukeminen

Lyhyesti: Joka haluaa analysoida pääsylokin hyökkäyksen jälkeen, varmistaa lokit ensin muuttumattomina ja työskentelee sen jälkeen vain kopioilla. Etsittäviä ovat pyynnöt tilalla 200 tuntemattomiin PHP-tiedostoihin, huomiota herättävät POST-pyynnöt, käyttö upload-hakemistoihin ja ajalliset mallit. PHP2Shellistä ei ole julkaistu vahvistettuja Indicators of Compromise -tunnisteita, joten ratkaisevaa on useiden lokilähteiden muodostama kokonaiskuva.

Ensin varmistus, sitten analyysi

Lokitiedostot kierrätetään useimmilla palvelimilla automaattisesti ja poistetaan kiinteän ajan kuluttua. Hyökkäyksen jälkeen ensimmäinen vaihe on siksi varmistaa olemassa olevat lokit, ennen kuin ne katoavat. Tämä pätee myös silloin, kun ette ole vielä varma, onko mitään tapahtunut. PHP2Shellistä ammattilehdistö neuvoo säilyttämään lokit 20.10.2026 alkaen.

# Kopioi lokit aikaleimoineen ja kirjaa tarkistussummat
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"

Tallentakaa varmistus lisäksi toiseen järjestelmään. Palvelimelle pääsyn saanut hyökkääjä voisi muuten muuttaa lokeja jälkikäteen. Tarkistussummat osoittavat myöhemmin, että kopio on muuttumaton. Jos tarvitaan oikeuskelpoinen varmistus, esimerkiksi rikosilmoitusta tai vakuutusta varten, varmistuksen pitäisi antaa IT-forensiikan hoidettavaksi.

Missä lokit sijaitsevat ja miten rivi on rakennettu

Sijainnit riippuvat jakelusta ja hallintakäyttöliittymästä. Tyypilliset polut:

Yleisessä Combined-muodossa jokainen rivi sisältää asiakkaan osoitteen, päivämäärän ja kellonajan, pyynnön menetelmän ja polun, tilakoodin, vastauksen koon tavuina, Refererin ja User-Agentin. Kiinnittäkää huomiota aikaleiman aikavyöhykkeeseen, etenkin kun vertaatte lokeja UTC-aikaisiin ilmoituksiin. PHP2Shell-korjaukset julkaistiin esimerkiksi 21.10.2026 kello 14:00 UTC eli kello 16 Saksan aikaa.

Jos verkkosivustonne on välityspalvelimen, CDN:n tai kuormantasaajan takana, lokissa voi näkyä vain sen osoite. Kävijän todellinen osoite löytyy silloin omasta kentästään tai edeltävän palvelun lokeista.

Ilman komentoriviä: lokit paneelissa tai hosting-yrityksellä

Kaikilla ylläpitäjillä ei ole komentoriviyhteyttä. Jaetussa hostingissa tai hallinnoiduilla palvelimilla hallintakäyttöliittymät tarjoavat yleensä lokinäkymän ja pääsy- ja virhelokien latauksen. Ladatkaa tiedostot koko saatavilla olevalta ajalta ja säilyttäkää ne turvallisesti. Kysykää hosting-yritykseltä kirjallisesti, kuinka kauan lokeja säilytetään ja voidaanko vanhempia tiloja varmistaa, ennen kuin ne vanhenevat.

Huomioikaa tällöin tietosuoja: lokit sisältävät IP-osoitteita ja usein muita henkilötietoja. Tallentakaa kopiot pääsysuojattuina, antakaa ne vain henkilöille, jotka tarvitsevat niitä selvitykseen, ja päättäkää, milloin ne poistetaan poikkeaman päätyttyä.

Pääsylokin analysointi: tärkeimmät kyselyt

Seuraavat komennot vain lukevat, ja ne sopivat Nginxille ja Apachelle Combined-muodossa. Kierrätetyt ja pakatut tiedostot käytte läpi komennoilla zgrep tai zcat.

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

# Onnistuneet pyynnöt PHP-tiedostoihin, yleisyysjärjestyksessä
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# PHP-kutsut upload-, välimuisti- tai kuvahakemistoissa
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# POST-pyynnöt kohteen ja osoitteen mukaan
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# 5xx-virheet tunnettain: kasaumat voivat viitata kaatuileviin PHP-prosesseihin
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Ota mukaan kierrätetyt lokit
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

Ensimmäisessä kyselyssä kiinnostavat erityisesti tiedostonimet, joita ette tunne tai jotka eivät kuulu sovellukseen. Verratkaa epäilyttäviä tiedostoja tiedostojärjestelmään: milloin ne on luotu, kenelle ne kuuluvat, mitä niissä on? Vihjeitä antaa opas Web shellien tunnistaminen ja poistaminen.

PHP2Shellin erityispiirteet

PHP2Shellissä haavoittuvuudet ovat PHP:n pyyntöjen käsittelyssä. mod_php:llä on esitetty exploit, ennen kuin sovelluskoodia ajetaan lainkaan. Se tarkoittaa: pyyntö täysin tavalliselle sivulle voi riittää. Pääsylokissa tällainen pyyntö voi näyttää huomaamattomalta, koska pyynnön rungon sisältöä ei siellä ole.

Julkaistuja, vahvistettuja Indicators of Compromise -tunnisteita ei ole. Kiinnittäkää siksi huomiota käyttäytymiseen ja yhteyksiin, esimerkiksi 17.10.2026 alkaen, joka on mediaraporttien mukaan ensimmäinen havaittu hyökkäysyritys:

• Virheiden 500 tai katkenneiden vastausten kasaumat tavallisilla sivuilla.
• Ilmoitukset loppuun käytetystä muistista tai päättyneistä worker-prosesseista virhe- ja PHP-FPM-lokissa.
• Uudet PHP-tiedostot tai muuttuneet tiedostot pian tällaisten kasaumien jälkeen.
• Uudet cron-tehtävät, prosessit tai lähtevät yhteydet verkkopalvelimen käyttäjän alla.

Mikään näistä signaaleista ei yksinään ole todiste. Yhdessä muiden jälkien kanssa niistä muodostuu kuitenkin kuva, joka vastaa kysymykseen vaarantumisesta tai perustelee syvemmän tutkinnan. Merkkien yleiskatsaus löytyy sivulta Onko järjestelmäni jo vaarannettu?.

Muut lähteet: virheloki, PHP-FPM ja järjestelmälokit

Pääsyloki näyttää vain osan. Täydellisen kuvan saamiseksi ottakaa mukaan muita lähteitä:

# PHP-FPM ja verkkopalvelin journalissa tietystä päivästä alkaen
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

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

# Tarkista kaikkien käyttäjien ajastetut tehtävät
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Tyypillisiä virheitä analyysissa ovat nykyisen lokin tutkiminen kierrätettyjen sijaan, aikavyöhykkeen huomaamatta jättäminen ja automaattisten skannerien yksittäisten osumien pitäminen onnistuneena hyökkäyksenä. Yhtä riskialtista on päinvastainen: huomaamattoman pääsylokin tulkitseminen hälytyksen päättymiseksi, vaikka virhelokia ja tiedostojärjestelmää ei ole vielä tarkistettu.

Kirjatkaa jokainen löydös kellonajan, lähteen ja havainnon kera aikajanalle. Tämä aikajana on myöhemmin päätösten, viranomaisille tai vakuutusyhtiölle tehtävien ilmoitusten ja loppuraportin perusta.

Miten PHP SOS auttaa konkreettisesti?

• Varmistamme lokit ja olennaiset tiedostot niin, että ne pysyvät jäljitettävinä myöhempiä tarkistuksia varten.
• Analysoimme pääsy-, virhe-, PHP- ja järjestelmälokit yhdessä ja laadimme poikkeaman aikajanan.
• Vaarantumisen merkkien ilmetessä otamme vastuun poikkeamien hallinnasta rajauksineen ja puhdistuksineen.
• Asetamme lokien kierrätyksen ja säilytyksen niin, että seuraavassa poikkeamassa tarvittavat tiedot ovat käytettävissä.

Usein kysytyt kysymykset

Lähteet

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