Trumpai: Jei jūsų svetainė nulaužta, šis kontrolinis sąrašas padeda nieko nepamiršti: pirmiausia suvaldyti ir išsaugoti įrodymus, paskui rasti priežastį ir išvalyti, po to atnaujinti visas prieigas, patikrinti pareigas ir dokumentuotai užbaigti incidentą. Eilė svarbi, nes kas pirmiausia trina, praranda pėdsakus, o kas tik valo neuždaręs spragos, bus atakuojamas vėl.
Kam šis kontrolinis sąrašas skirtas, kai svetainė nulaužta
Kontrolinis sąrašas skirtas vadovybei, savininkams ir IT vadovams po patvirtintos ar tikėtinos atakos prieš svetainę, parduotuvę ar PHP žiniatinklio serverį. Jis tinka ir po PHP2Shell, kai serveris prieš atnaujinimą buvo pasiekiamas ir yra kompromitavimo požymių.
Ne kiekvienas punktas tinka kiekvienai aplinkai. Vis dėlto peržiūrėkite sąrašą pilnai ir prie kiekvieno punkto pažymėkite, ar jis atliktas, netaikomas ar atviras. Šis protokolas vėliau vertingas draudimui, duomenų apsaugai ir vidiniam aptarimui.
Prie kiekvieno žingsnio įrašykite datą, laiką, atsakingą asmenį ir rezultatą. Kai dalyvauja keli asmenys, paskirkite vieną, kuris tvarko sąrašą ir fiksuoja sprendimus.
1 etapas: nedelsiant suvaldyti ir išsaugoti
- Apriboti žalą: svetainę perjungti į techninės priežiūros režimą arba atjungti nuo tinklo, jei lankytojams gresia pavojus ar gali nutekėti duomenys. Dėl PHP2Shell BSI rekomenduoja nepataisytus žiniatinklio serverius laikinai atjungti nuo tinklo, jei atnaujinti iš karto neįmanoma.
- Nieko netrinti: nešalinti failų, neįdiegti serverio iš naujo ir neišvalyti žurnalų, kol neišsaugoti pėdsakai.
- Išsaugoti žurnalus: prieigos, klaidų, PHP-FPM ir sistemos žurnalus nukopijuoti į kitą sistemą ir užfiksuoti kontrolines sumas. Dėl PHP2Shell specializuota spauda pataria žurnalus saugoti nuo 2026-10-20.
- Išsaugoti atvaizdą: failų ir duomenų bazės kopiją, virtualiuose serveriuose momentinę kopiją (snapshot), sukurti kaip įrodymų būseną ir jos nekeisti.
- Informuoti atsakinguosius: anksti įtraukti vadovybę, duomenų apsaugos pareigūną, hostingo teikėją ir, jei yra, kibernetinį draudimą. Daugelis draudimų turi pranešimo pareigų.
2 etapas: rasti priežastį ir išvalyti
- Nustatyti įėjimo vartus: išanalizuoti žurnalus, failų pakeitimus ir versijas. Patikrinkite patį PHP, CMS, temas, plėtinius, prisijungimo duomenis ir serverio tarnybas. Be žinomos priežasties pakartotinės atakos rizika išlieka.
- Uždaryti spragą: PHP atnaujinti iki ištaisytos versijos (8.5.12, 8.4.27, 8.3.36 ar 8.2.35 arba teikėjo patvirtintas backport), atnaujinti CMS ir plėtinius, iš naujo paleisti visus PHP darbinius procesus.
- Apriboti laikotarpį: nustatyti anksčiausią įtartinos veiklos momentą. Jis lemia, kurios atsarginės kopijos gali būti švarios ir kurie duomenys galėjo būti paveikti.
- Pašalinti užpakalines duris: patikrinti ir pašalinti webshell, svetimus PHP failus įkėlimų ir talpyklos aplankuose, pakeistus branduolio failus, cron užduotis, SSH raktus ir sistemos tarnybas. Branduolio failus pakeisti iš švaraus šaltinio.
- Išvalyti duomenų bazę: pašalinti nežinomas administratoriaus paskyras, turinyje ir nustatymuose įterptus skriptus bei šlamšto turinį.
- Apsvarstyti naują įdiegimą: esant gilesniam serverio kompromitavimui naujas įdiegimas šviežioje, pataisytoje sistemoje su patikrintais duomenimis dažnai yra patikimesnis kelias nei išvalymas veikiančioje sistemoje.
3 etapas: atnaujinti prieigas ir sutvirtinti
- Pakeisti slaptažodžius: CMS, hostingo paskyros, skydelio, duomenų bazės, FTP, SFTP, SSH ir el. pašto, ir tai daryti iš švaraus įrenginio.
- Pakeisti raktus ir žetonus: iš naujo sukurti API raktus, mokėjimų ir pristatymo paslaugų sąsajas, CMS programos raktus, SSH raktus ir sertifikatus, kurie buvo serveryje.
- Užbaigti sesijas: atjungti visus aktyvius prisijungimus CMS ir paslaugose ir patikrinti užregistruotus dviejų veiksnių įrenginius.
- Įjungti dviejų veiksnių autentifikaciją: visoms administratoriaus prieigoms, įskaitant hostingą, domeną ir DNS.
- Sutvirtinti serverį: patikrinti ir dokumentuoti PHP nustatymus, failų teises, vykdymo draudimus įkėlimų aplankuose, ugniasienę ir saugumo antraštes.
4 etapas: pareigos, komunikacija ir užbaigimas
- Patikrinti pranešimo pareigas: jei gali būti paveikti asmens duomenys, gali prireikti BDAR 33 str. pranešimo per 72 valandas. Vertinimas priklauso duomenų apsaugos pareigūnui ar advokatui. Sektoriui specifines pareigas, pavyzdžiui, pagal NIS2, tikrinti atskirai.
- Apsvarstyti pareiškimą: policijos Zentrale Ansprechstellen Cybercrime priima įmonių pareiškimus. Išsaugoti žurnalai tam yra svarbus pagrindas.
- Informuoti klientus ir Google: paveiktuosius informuoti dalykiškai ir suderintai. Jei Google rodo įspėjimą, po išvalymo paprašyti peržiūros, kaip aprašyta puslapyje Google įspėjimo pašalinimas.
- Dokumentuoti užbaigimą ir stebėti: priežastį, laikotarpį, priemones ir atviras problemas užfiksuoti ataskaitoje, išvadas perkelti į avarinį planą ir kitas savaites sistemas stebėti sustiprintai.
Dažnos tolesnių veiksmų klaidos
Daug incidentų užtrunka, nes pirmojo susijaudinimo metu taupoma netinkamoje vietoje arba veikiama per greitai. Šių klaidų reikėtų vengti:
- Pašalinti tik matomą dalį: ištrintas šlamšto puslapis ar pašalintas peradresavimas nėra švarios svetainės įrodymas. Užpakalinės durys dažnai lieka nepastebėtos.
- Slaptažodžius keisti iš paveiktos sistemos: jei kompiuteryje ar serveryje dar veikia kenkėjiška programinė įranga, nauji prisijungimo duomenys gali iškart nutekėti.
- Aklai atkurti atsarginę kopiją: be uždarytos spragos ir be kopijos patikros užpuolikas greitai vėl stovi duryse.
- Pataisą laikyti atšaukimu: atnaujinimas iki ištaisytos PHP versijos neįrodo, kad anksčiau nieko neįvyko, ir nepašalina įterptos kenkėjiškos programinės įrangos.
- Per vėlai tikrinti pareigas: terminai prasideda nuo incidento sužinojimo, o ne nuo išvalymo pabaigos.
- Jokios dokumentacijos: be protokolo draudimo, institucijų ar klientų klausimai vėliau vargu ar atsakomi.
Šis kontrolinis sąrašas nepakeičia teisinės konsultacijos. Dėl pranešimo pareigų, atsakomybės ar draudimo klausimų kreipkitės į savo duomenų apsaugos pareigūną, advokatą ar draudiką.
Kaip PHP SOS padeda konkrečiai?
- Perimame struktūruotą incidentų valdymą ir kontrolinį sąrašą vykdome kartu su jumis, punktas po punkto su protokolu.
- Žurnalus ir sistemos būsenas išsaugome taip, kad jie liktų tinkami draudimui, institucijoms ir galimai IT forensikai.
- Uždarome spragą, išvalome arba įdiegiame iš naujo ir atnaujiname prieigas teisinga eile.
- Pateikiame baigiamąją ataskaitą su priežastimi, priemonėmis ir rekomendacijomis ir pageidaujant po to toliau stebime sistemas.
Dažni klausimai
Ką pirmiausia daryti, jei mano svetainė nulaužta?
Išlaikyti ramybę, nieko netrinti ir apriboti žalą. Prireikus atjunkite svetainę nuo tinklo arba perjunkite į techninės priežiūros režimą ir prieš valydami išsaugokite žurnalus bei failus. Po to eina priežasties paieška ir išvalymas.
Ar pakanka svetainę atkurti iš atsarginės kopijos?
Dažniausiai ne. Kopija jau gali turėti kenkėjiško kodo, o spraga, per kurią užpuolikas pateko, po atkūrimo vis dar atvira. Pirmiausia uždarykite priežastį, tada patikrintą, švarią būseną įdiekite į atnaujintą sistemą.
Ar apie įsilaužimą turiu pranešti duomenų apsaugos institucijai?
Jei gali būti paveikti asmens duomenys, BDAR 33 str. iš esmės numato pranešimą per 72 valandas nuo sužinojimo, jei rizika susijusiems asmenims nėra mažai tikėtina. Vertinimas priklauso jūsų duomenų apsaugos pareigūnui ar advokatui.
Kada incidentas iš tiesų užbaigtas?
Kai priežastis uždaryta, visos žinomos užpakalinės durys pašalintos, prieigos atnaujintos, pareigos įvykdytos ir priemonės dokumentuotos. Prie to priklauso ir po to sustiprinta stebėsena, kad būtų pastebėti praleisti pėdsakai.