Lühidalt: Kas server on PHP2Shelli kaudu häkitud, ei saa üksiku tunnuse järgi öelda. Avaldatud ja kinnitatud kompromiteerimisnäitajaid (Indicators of Compromise) pole; tuvastamine põhineb käitumisanalüüsil. Tüüpilised tunnused on uued PHP failid, tundmatud cron-tööd ja ebatavalised ühendused. Kindlustage kõigepealt logid alates 20. oktoobrist, enne kui midagi muudate.
Kas PHP2Shelli rünnakul on üheselt mõistetavad tunnused?
Ei, ja see on aus vastus. Paljude teadaolevate turvaaukude kohta avaldavad tootjad või turvafirmad konkreetseid jälgi: failinimed, kontrollsummad, IP-aadressid. PHP2Shelli kohta selliseid kinnitatud kompromiteerimisnäitajaid seni ei ole.
Mis on teada: meediateadete kohaselt täheldati esimest ründekatset 17. oktoobril, neli päeva enne 21. oktoobri paike. Cloudflare teatas täiendavatest katsetest. Kinnitatud edukaid laiaulatuslikke rünnakuid BSI esialgu ei teadnud. Kes oli 17. oktoobri ja oma paiga vahel kaitsmata kättesaadav, peaks seetõttu kontrollima, mitte lootma.
Hinnangu jaoks loeb eelkõige ajavahemik. Esimese täheldatud ründekatse 17. oktoobril ja paikade 21. oktoobril vahel ametlikku uuendust ei olnud. Iga avalikult ligipääsetav PHP server oli sel ajal potentsiaalselt ründatav. Kui kaua teie server sellest edasi lahti oli, sõltub sellest, millal uuendus paigaldati ja PHP uuesti käivitati. Mida pikem on see ajavahemik ja mida tundlikumad andmed, näiteks kliendikontod, tellimused või kandideerimised, seda põhjalikumalt peaks kontroll olema.
Tüüpilised tunnused, et server on häkitud
Pärast edukat koodi käivitamist püüavad ründajad tavaliselt kanda kinnitada ja serverit kasutada. Sellest tulenevad tunnused, mis ei ole PHP2Shelli suhtes spetsiifilised, kuid loevad iga sissemurdmise kontrolli juures:
- Uued või muudetud PHP failid, eriti üleslaadimis-, vahemälu- või pildikataloogides, kus muidu PHP faile ei ole.
- Tundmatud cron-tööd või ajastatud ülesanded, näiteks veebiserveri kasutajale.
- Ebatavalised väljaminevad ühendused tundmatutele aadressidele, suur võrgukoormus või e-kirjade saatmine, mille keegi ei algatanud.
- Uued administraatorikontod CMS-is või poes, muudetud paroolid, tundmatud SSH võtmed.
- Silmatorkav koormus: püsivalt kõrge CPU kasutus tundmatute protsesside tõttu, sageli vihje krüptokaevandamisele.
- Nähtavad tagajärjed: ümbersuunamised võõrastele lehtedele, rämpsulehed Google'i registris, hoiatused brauseris või Search Console'is.
Ükski neist tunnustest ei tõenda iseenesest sissemurdmist ja nende puudumine ei tõenda vastupidist. Otsustav on tervikpilt.
Esimesed kontrollid jälgi hävitamata
Enne kui midagi kustutate või uuesti käivitate: kindlustage logid. Erialaajakirjandus soovitab hoida serveri logisid alles alates 20. oktoobrist. Kopeerige veebiserveri, PHP ja süsteemi logid turvalisse kohta väljaspool serverit.
Seejärel aitavad puhtalt lugevad kontrollid. Teed ja kasutajanimed erinevad süsteemiti:
# PHP failid, mida on muudetud alates 17.10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP failid üleslaadimiskataloogides (näide WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# veebiserveri kasutaja ja süsteemsed cron-tööd
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# aktiivsed võrguühendused koos protsessiga
ss -tunp
# viimased sisselogimised
last -n 30
Pange tähele: ründajad võivad failide ajatemplid võltsida. Märkamatu find tulemus ei ole seetõttu õigeksmõistmine. Kuidas logisid sihipäraselt analüüsida, kirjeldab Veebiserveri logide analüüs pärast rünnakut; kuidas tagauksi leida, Veebishellide tuvastamine ja eemaldamine.
Kui leiate konkreetseid viiteid, näiteks tundmatu PHP faili üleslaadimiskaustas: ärge kustutage, ärge seadistage uuesti üles, ärge „kiiresti parandage“ rakendust. Eraldage server võrgust või isoleerige see, kindlustage logid ja süsteemi tõmmis ning alustage struktureeritud intsidendi käsitlemist.
Mida te tegema ei peaks
- Ainult paigata ja edasi minna. Paik ei eemalda juba sisse toodud kahjulikku tarkvara.
- Kahtlasi faile kohe kustutada. Sellega kaovad tõendid selle kohta, mis juhtus ja millised andmed võivad olla mõjutatud.
- Serverit uuesti üles seada, enne kui on kindlustatud. Põhjus jääb ebaselgeks ja tagauks andmebaasis või ligipääsuandmetes elab uuesti paigaldamise üle.
- Vanu varukoopiaid kontrollimata tagasi panna. Ka varukoopia võib tagauksi juba sisaldada.
- Ligipääsuandmed unustada. Pärast koodi käivitamist võivad andmebaasi paroolid, API võtmed ja muud ligipääsuandmed seadistusfailidest välja voolata. Uuendage need pärast puhastamist, mitte enne, et veel aktiivne ründaja uusi kohe kaasa ei loeks.
Kui kahtlus leiab kinnitust
Siis on asi suurem kui tehnika. Selgitage oma andmekaitsespetsialistiga, kas IKÜM-i alusel on teavitamine vajalik; tähtaeg on 72 tundi alates teadasaamisest, üksikasjad lehel IKÜM-i teavitamiskohustus. Teavitage varakult oma küberkindlustajat, kui see on olemas, ja selgitage advokaadiga, kas avaldus tuleks esitada. Anname selle kohta üldisi märkusi, mitte õigusnõu.
Kuidas PHP SOS konkreetselt aitab?
Oma intsidendile reageerimisega (Incident Response) töötame kahtluse struktureeritult läbi:
- Kindlustamine: logid alates 20. oktoobrist ja vajaduse korral süsteemi tõmmis enne, kui midagi muudetakse.
- Uurimine: failide, protsesside, ühenduste ja kontode käitumisanalüüs; vajaduse korral kohtus kasutatavalt IT-forensikaga.
- Puhastamine ja sulgemine: tagauste eemaldamine, PHP uuendamine, ligipääsuandmete uuendamine, serveri karastamine.
- Dokumenteerimine, kuni intsident on lõpetatud ja dokumenteeritud, aluseks andmekaitsele, kindlustusele ja juhtkonnale.
Korduma kippuvad küsimused
Kas PHP uuendus tõendab, et mu server on puhas?
Ei. Paik sulgeb turvaaugu tuleviku jaoks, kuid ei eemalda juba sisse toodud kahjulikku tarkvara. See ei ütle ka midagi selle kohta, kas enne paika on keegi sisse tunginud.
Kas on olemas skanner, mis PHP2Shelli rünnakuid kindlalt tuvastab?
Seni mitte. Avaldatud ja kinnitatud kompromiteerimisnäitajaid (Indicators of Compromise), mille järgi skanner sihipäraselt otsida saaks, pole. Pahavaraskannerid leiavad teadaolevaid veebishelle, kuid serveri hindamine põhineb käitumisanalüüsil.
Kas pean kahtlusest andmekaitseasutusele teatama?
See sõltub sellest, kas võivad olla mõjutatud isikuandmed. IKÜM näeb teavitamisele kuuluvate andmeõnnetuste puhul ette 72-tunnise tähtaja alates teadasaamisest. Selgitage seda varakult oma andmekaitsespetsialisti või advokaadiga; õigusnõu me ei anna.
Kas peaksin häkitud serveri lihtsalt uuesti üles seadma?
Mitte esimese sammuna. Kindlustage kõigepealt logid ja, kui võimalik, süsteemi tõmmis. Kes kohe uuesti üles seab, kaotab jäljed, mis näitavad, mis juhtus ja millised andmed võivad olla mõjutatud.