Trumpai: Ar serveris nulaužtas per PHP2Shell, pagal vieną požymį nustatyti neįmanoma. Paskelbtų, patvirtintų kompromitavimo rodiklių (Indicators of Compromise) nėra; aptikimas grindžiamas elgsenos analize. Tipiniai požymiai yra nauji PHP failai, nežinomos cron užduotys ir neįprasti ryšiai. Prieš ką nors keisdami pirmiausia išsaugokite žurnalus nuo spalio 20 d.
Ar yra vienareikšmių PHP2Shell atakos požymių?
Ne, ir tai yra sąžiningas atsakymas. Daugeliui žinomų spragų gamintojai ar saugumo bendrovės skelbia konkrečius pėdsakus: failų pavadinimus, kontrolines sumas, IP adresus. PHP2Shell tokių patvirtintų kompromitavimo rodiklių kol kas nėra.
Kas žinoma: pagal žiniasklaidos pranešimus pirmas atakos bandymas pastebėtas spalio 17 d., keturiomis dienomis anksčiau už spalio 21 d. pataisas. Cloudflare pranešė apie tolesnius bandymus. Patvirtintų sėkmingų plataus masto atakų, BSI duomenimis, iš pradžių nebuvo žinoma. Kas laikotarpiu nuo spalio 17 d. iki savo pataisos buvo pasiekiamas neapsaugotas, todėl turėtų tikrinti, o ne tikėtis.
Vertinimui svarbiausias laikotarpis. Tarp pirmojo pastebėto atakos bandymo spalio 17 d. ir pataisų spalio 21 d. oficialaus atnaujinimo nebuvo. Kiekvienas viešai pasiekiamas PHP serveris tuo metu buvo potencialiai atakuojamas. Kiek ilgiau jūsų serveris buvo atviras, priklauso nuo to, kada atnaujinimas įdiegtas ir PHP paleistas iš naujo. Kuo ilgesnis šis laikotarpis ir kuo jautresni duomenys, pavyzdžiui, klientų paskyros, užsakymai ar paraiškos, tuo kruopščiau turėtų vykti patikra.
Tipiniai požymiai, kad serveris nulaužtas
Po sėkmingo kodo vykdymo užpuolikai dažniausiai bando įsitvirtinti ir naudoti serverį. Iš to kyla požymiai, kurie nėra specifiniai PHP2Shell, bet svarbūs kiekvienai įsilaužimo patikrai:
- Nauji ar pakeisti PHP failai, ypač įkėlimų, talpyklos ar paveikslėlių kataloguose, kuriuose kitaip PHP failų nėra.
- Nežinomos cron užduotys ar planuojamos užduotys, pavyzdžiui, žiniatinklio serverio naudotojui.
- Neįprasti išeinantys ryšiai su nežinomais adresais, didelė tinklo apkrova ar laiškų siuntimas, kurio niekas neinicijavo.
- Naujos administratoriaus paskyros CMS ar parduotuvėje, pakeisti slaptažodžiai, nežinomi SSH raktai.
- Neįprasta apkrova: nuolat didelė procesoriaus apkrova dėl nežinomų procesų, dažnai kriptovaliutų kasimo (mining) požymis.
- Matomos pasekmės: peradresavimai į svetimus puslapius, šlamšto puslapiai Google indekse, įspėjimai naršyklėje ar Search Console.
Nė vienas iš šių požymių pats savaime įsilaužimo neįrodo, o jų nebuvimas neįrodo priešingo. Lemia bendras vaizdas.
Pirmosios patikros nesunaikinant pėdsakų
Prieš ką nors ištrindami ar paleisdami iš naujo: išsaugokite žurnalus. Specializuota spauda pataria saugoti serverio žurnalus nuo spalio 20 d. Nukopijuokite žiniatinklio serverio, PHP ir sistemos žurnalus į saugią vietą už serverio ribų.
Po to padeda tik skaitančios patikros. Keliai ir naudotojų vardai skiriasi pagal sistemą:
# PHP failai, pakeisti nuo spalio 17 d.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP failai įkėlimų kataloguose (pavyzdys: WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# žiniatinklio serverio naudotojo ir visos sistemos cron užduotys
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# aktyvūs tinklo ryšiai su procesu
ss -tunp
# paskutiniai prisijungimai
last -n 30
Atkreipkite dėmesį: užpuolikai gali suklastoti failų laiko žymas. Nepastebimas find rezultatas todėl nėra išteisinimas. Kaip tikslingai vertinti žurnalus, aprašo Žiniatinklio serverio žurnalų vertinimas po atakos; kaip rasti užpakalines duris, Webshell atpažinimas ir šalinimas.
Radę konkrečių požymių, pavyzdžiui, nežinomą PHP failą įkėlimų aplanke: netrinkite, neįrenkite iš naujo, „greitai netaisykite“ programos. Serverį atjunkite nuo tinklo ar izoliuokite, išsaugokite žurnalus ir sistemos atvaizdą ir pradėkite struktūruotą incidento tvarkymą.
Ko nedaryti
- Tik pataisyti ir dirbti toliau. Pataisa nepašalina jau įterptos kenkėjiškos programinės įrangos.
- Įtartinus failus iš karto trinti. Su jais išnyksta įrodymai, kas įvyko ir kurie duomenys gali būti paveikti.
- Serverį įrengti iš naujo prieš išsaugant. Priežastis lieka neaiški, o užpakalinės durys duomenų bazėje ar prieigos duomenyse išgyvena naują įrengimą.
- Senas atsargines kopijas atkurti netikrinant. Ir kopijoje jau gali būti užpakalinės durys.
- Pamiršti prieigos duomenis. Po kodo vykdymo duomenų bazės slaptažodžiai, API raktai ir kiti prieigos duomenys galėjo nutekėti iš konfigūracijos failų. Atnaujinkite juos po išvalymo, ne prieš tai, kad vis dar aktyvus užpuolikas naujų nepaskaitytų iš karto.
Kai įtarimas pasitvirtina
Tuomet svarbu daugiau nei technika. Su savo duomenų apsaugos pareigūnu patikrinkite, ar reikia pranešti pagal BDAR; terminas yra 72 valandos nuo sužinojimo, išsamiau puslapyje BDAR pareiga pranešti. Anksti informuokite savo kibernetinio draudimo bendrovę, jei tokią turite, ir su teisininku išsiaiškinkite, ar teikti pareiškimą. Dėl to pateikiame bendras nuorodas, o ne teisines konsultacijas.
Kaip PHP SOS padeda konkrečiai?
Per savo incidentų valdymą (Incident Response) įtarimą išnagrinėjame struktūruotai:
- Išsaugoti: žurnalus nuo spalio 20 d. ir, kur reikia, sistemos atvaizdą, prieš ką nors keičiant.
- Tirti: failų, procesų, ryšių ir paskyrų elgsenos analizė; prireikus teisme priimtinai su IT kriminalistika.
- Išvalyti ir uždaryti: šalinti užpakalines duris, atnaujinti PHP, atnaujinti prieigos duomenis, sustiprinti serverį.
- Dokumentuoti, kol incidentas bus užbaigtas ir dokumentuotas, kaip pagrindą duomenų apsaugai, draudimui ir vadovybei.
Dažni klausimai
Ar PHP atnaujinimas įrodo, kad mano serveris švarus?
Ne. Pataisa uždaro spragą ateičiai, bet nepašalina jau įterptos kenkėjiškos programinės įrangos. Ji taip pat nieko nesako apie tai, ar prieš pataisą kas nors įsilaužė.
Ar yra skaitytuvas, kuris patikimai aptinka PHP2Shell atakas?
Kol kas ne. Paskelbtų, patvirtintų kompromitavimo rodiklių, pagal kuriuos skaitytuvas galėtų tikslingai ieškoti, nėra. Kenkėjiškų programų skaitytuvai randa žinomus webshell, bet serverio vertinimas grindžiamas elgsenos analize.
Ar apie įtarimą turiu pranešti duomenų apsaugos institucijai?
Tai priklauso nuo to, ar gali būti paveikti asmens duomenys. BDAR pranešimo apie duomenų saugumo pažeidimą atveju numato 72 valandų terminą nuo sužinojimo. Anksti išsiaiškinkite tai su savo duomenų apsaugos pareigūnu ar teisininku; teisinių konsultacijų neteikiame.
Ar nulaužtą serverį turėčiau tiesiog įrengti iš naujo?
Ne kaip pirmą žingsnį. Pirmiausia išsaugokite žurnalus ir, jei įmanoma, sistemos atvaizdą. Kas iš karto įrengia iš naujo, praranda pėdsakus, rodančius, kas įvyko ir kurie duomenys galėjo būti paveikti.