Trumpai: jei po saugumo incidento norite keisti hostingo teikėją, pirmiausia išsaugokite įrodymus ir išsiaiškinkite incidentą, tada perkelkite tik patikrintus duomenis į naujai sukurtą sistemą ir tik po to nutraukite seną sutartį. Naują teikėją rinkitės pagal saugumo kriterijus: įrodomą pataisų procesą, klientų atskyrimą, prieigą prie žurnalų, atsargines kopijas ir aiškius kontaktinius asmenis. Hostingo teikėjo keitimas prasmingas, kai trūksta pasitikėjimo ar kokybės, tačiau jis nepakeičia išvalymo.
Kai pasitikėjimas dingęs
Po PHP2Shell daugelis įmonių pirmą kartą pajuto savo hostingo teikėją esant spaudimui. Vieni greitai gavo aiškų atsakymą apie pataisų būseną. Kiti dienas laukė atsakymo, gavo tik bendras frazes arba nustatė, kad jų svetainė veikė su pasenusia PHP versija. Jei dar įvyksta incidentas, noras keisti teikėją suprantamas.
Tačiau hostingo teikėjo keitimas nėra incidento įveikimo žingsnis, tai persitvarkymas po jo. Kas jį atlieka netinkama tvarka, blogiausiu atveju pasiima su savimi užpuoliką ir kartu praranda pėdsakus, rodančius, kas įvyko.
Teisinga keitimo eilės tvarka
- Išsaugokite pėdsakus, kol jie yra. Senos sistemos žurnalai, failai ir duomenų bazė turi būti išsaugoti atsarginėje kopijoje prieš ką nors ištrinant ar nutraukiant sutartį. Aiškiai paklauskite seno hostingo teikėjo apie prieigos ir klaidų žurnalus nuo 2026 m. spalio 20 d. ir jų saugojimo trukmę. Kaip tai daryti, aprašo straipsnis Įrodymų išsaugojimas prieš diegiant iš naujo.
- Apribokite incidentą. Kurios sistemos paveiktos, kokios prieigos buvo naudojamos, kokie duomenys buvo pasiekiami? Nuo to priklauso pranešimo pareigos ir tai, ką galima perkelti.
- Patikrinkite pranešimo pareigas. Jei gali būti paveikti asmens duomenys, galimo pranešimo pagal BDAR terminas pradeda tekėti nuo sužinojimo apie incidentą, o ne nuo perkėlimo. Pagrindą rasite puslapyje Pranešimo pareiga pagal BDAR: 72 valandos.
- Sukurkite švarią naują sistemą. Palaikoma PHP versija, naujausi paketai, sutvirtinta konfigūracija, dar prieš perkeliant pirmąjį failą.
- Perkelkite tik patikrintą turinį. Kodą iš švaraus šaltinio, duomenų bazę ir medijos failus po patikros.
- Pakeiskite visus prisijungimo duomenis. Duomenų bazės, administratorių paskyrų, SSH, FTP, API raktų, taip pat esančių konfigūracijos failuose.
- Perjunkite ir stebėkite. DNS perjungimas, po to kurį laiką griežtesnė stebėsena.
- Nutraukite seną sutartį. Tik kai žurnalai ir atsarginės kopijos išsaugoti, o naujas veikimas stabilus.
Nenutraukite senos sutarties, kol neturite rankose žurnalų ir atsarginių kopijų. Pasibaigus sutarčiai teikėjas gali ištrinti duomenis, kurių jums reikia draudikams, institucijoms ar savo tyrimui.
Ko neturėtumėte pasiimti
Patogu būtų tiesiog nukopijuoti visą žiniatinklio katalogą ar serverio atvaizdą. Būtent tai po incidento rizikinga. Webshell užsimaskuoja kaip nekenksmingi failai, užpakalinės durys slepiasi konfigūracijos failuose, tokiuose kaip .htaccess ar .user.ini, o įterptas kodas gali būti duomenų bazės turinyje.
Todėl programos kodą perkelkite iš švaraus šaltinio, pavyzdžiui, gamintojo paketo tinkamos versijos ar savo versijų valdymo sistemos. Medijos failus perimkite be vykdomųjų failų, duomenų bazę po patikros dėl įtartino turinio ir naujų administratorių paskyrų. Ką radote senojoje sistemoje, padeda atliekant šią patikrą.
Pagalvokite ir apie viską, kas šalia svetainės yra pas seną teikėją. El. pašto dėžutės, DNS įrašai, sertifikatai ir peradresavimai persikeliant lengvai užmirštami. Sumažinkite DNS įrašų galiojimo laiką keliomis dienomis prieš perjungimą, kad pakeitimas greitai pasiektų lankytojus. Jei kartu kelsis ir el. paštas, dėžučių keitimą planuokite atskirai, nes ir ten po incidento gali būti paveikti prisijungimo duomenys.
Naują hostingo teikėją rinkitės pagal saugumą
Kaina ir disko vieta nurodyta kiekviename pasiūlyme. Lemiamus saugumo klausimus dažniausiai tenka uždavinėti patiems. Šis sąrašas padeda palyginti:
| Kriterijus | Klausimas teikėjui | Kodėl tai svarbu |
|---|---|---|
| Pataisų procesas | Kaip ir kokiu režimu diegiami PHP saugumo atnaujinimai ir paleidžiama iš naujo? | PHP2Shell parodė, kaip svarbus įrodomas procesas |
| Įrodymas | Ar paprašius gausiu rašytinį patvirtinimą apie pataisų būseną? | Pagrindas jūsų pačių dokumentacijai |
| PHP versijos | Kokios šakos siūlomos ir kiek dar laiko? | Senos šakos be atnaujinimų yra nuolatinė rizika |
| Atskyrimas | Ar kiekviena svetainė veikia su savo naudotoju ir savo PHP procesu? | Riboja žalą, jei užpulamas kaimynas |
| Žurnalai | Ar turiu prieigą prie prieigos ir klaidų žurnalų, kiek laiko jie saugomi? | Be žurnalų nėra tyrimo |
| Atsarginės kopijos | Kaip dažnai, kiek laiko, atskirai nuo žiniatinklio serverio, ar išbandomas atkūrimas? | Atkūrimas po incidento |
| Avarinis kontaktas | Kaip incidento metu susisiekti su kompetentingu asmeniu? | Ištikus nelaimei laikas yra didžiausias trūkumas |
| Duomenų tvarkymas | Ar yra sutartis pagal BDAR ir pagalbinių duomenų tvarkytojų sąrašas? | Privaloma esant asmens duomenims |
Pataisų būsenos klausimo šabloną pateikia vadovas Paklausti hostingo teikėjo apie pataisų būseną. Jis tinka ir teikėjams palyginti prieš sudarant sutartį.
Ar kitas veikimo modelis yra geresnis atsakymas?
Kartais problema ne tiek hostingo teikėjas, kiek veikimo modelis. Kas eksploatuoja nuosavą serverį be reguliarios priežiūros, dažnai geriau jaučiasi su gerai prižiūrimu valdomu pasiūlymu. Ir atvirkščiai, įmonė su savo IT, administruodama pati, gali įgyti daugiau kontrolės pataisų diegimo momentui. Svarstymą aprašo straipsnis Valdomas hostingas ar nuosavas serveris?.
Nepriklausomai nuo modelio galioja: užrašykite užduočių pasidalijimą. Kas diegia PHP atnaujinimus, kas paleidžia iš naujo, kas tikrina programą, kas ir kam praneša avariniu atveju? Per PHP2Shell daug vėlavimų atsirado būtent čia, nes kiekviena pusė manė, kad kita pasirūpins.
Kaip PHP SOS padeda konkrečiai?
- Išsaugome senosios sistemos žurnalus ir duomenis bei išsiaiškiname, kas incidento metu įvyko.
- Naują sistemą sukuriame sutvirtintą ir perkeliame tik patikrintą turinį iš švarių šaltinių.
- Naujų teikėjų pasiūlymus tikriname pagal saugumo kriterijus ir uždavinėjame tinkamus klausimus.
- Vykstančio incidento atveju dirbame pagal savo incidentų valdymą (Incident Response), kol incidentas baigiamas ir dokumentuojamas.
Dažni klausimai
Ar po įsilaužimo turėčiau iš karto keisti hostingo teikėją?
Ne iš karto. Pirmiausia reikia išsaugoti pėdsakus, apriboti incidentą ir išsiaiškinti priežastį. Skubotas perkėlimas gali pernešti kenkėjišką kodą ir sunaikinti senojo teikėjo turimus įrodymus.
Ar kaltas hostingo teikėjas, jei mano svetainė buvo užpulta per PHP2Shell?
Tai priklauso nuo sutarties ir laiko. Bendrinamame hostinge už PHP atnaujinimus dažniausiai atsako hostingo teikėjas, nuosavuose serveriuose operatorius. Pataisos pasirodė 2026 m. spalio 21 d.; ar ir kada jos buvo įdiegtos, galima išsiaiškinti tik su įrodymais. Dėl atsakomybės klausimų kreipkitės į advokatą.
Kokius duomenis galiu perkelti pas naują hostingo teikėją?
Tik patikrintą turinį: duomenų bazę po patikros dėl įterpto kodo, medijos failus be vykdomųjų failų ir kodą iš švaraus šaltinio, pavyzdžiui, gamintojo paketo ar jūsų versijų valdymo sistemos. Visų serverio atvaizdų ar žiniatinklio katalogų iš pažeistos sistemos nepatikrintų perkelti nereikėtų.
Ar po incidento reikia įtraukti duomenų apsaugą?
Jei gali būti paveikti asmens duomenys, gali kilti pareiga pranešti pagal BDAR, paprastai per 72 valandas. Pas naują hostingo teikėją, be to, reikia duomenų tvarkymo sutarties. Išsiaiškinkite tai su savo duomenų apsaugos pareigūnu; tai nėra teisinė konsultacija.