Lühidalt: Kes soovib pärast turvaintsidenti veebimajutajat vahetada, peaks esmalt tõendid kindlustama ja intsidendi selgitama, seejärel kandma värskelt üles seatud süsteemi üle ainult kontrollitud andmed ning alles siis vana lepingu lõpetama. Uue pakkuja valige turvakriteeriumide järgi: tõendatav paikamisprotsess, klientide eraldatus, ligipääs logidele, varukoopiad ja selged kontaktisikud. Veebimajutaja vahetus on mõttekas, kui usaldus või teenus puudub, kuid see ei asenda puhastamist.
Kui usaldus on kadunud
Pärast PHP2Shelli kogevad paljud ettevõtted oma veebimajutajat esimest korda surve all. Mõned said paigatud seisu kohta kiiresti selge vastuse. Teised ootasid vastust päevi, said ainult üldsõnalisi fraase või avastasid, et nende veebisait töötas aegunud PHP versioonil. Kui lisandub veel intsident, on soov vahetada mõistetav.
Veebimajutaja vahetus ei ole aga intsidendi lahendamise samm, vaid selle järgne ümberkorraldamine. Kes paneb selle vales järjekorras, viib halvimal juhul ründaja kaasa ja kaotab samal ajal jäljed, mis näitavad, mis juhtus.
Õige järjekord vahetuse juures
- Kindlustage jäljed, kuni need olemas on. Vana süsteemi logid, failid ja andmebaas kuuluvad varukoopiasse enne, kui midagi kustutatakse või üles öeldakse. Küsige vanalt veebimajutajalt otsesõnu juurdepääsu- ja vealogisid alates 20. oktoobrist 2026 ning nende säilitusaega. Kuidas sealjuures toimida, kirjeldab artikkel Kindlustage tõendid enne uuesti paigaldamist.
- Piiritlege intsident. Millised süsteemid on mõjutatud, milliseid ligipääse kasutati, milliste andmeteni jõuti? Sellest sõltuvad teavitamiskohustused ja küsimus, mida tohib kaasa võtta.
- Kontrollige teavitamiskohustusi. Kui võivad olla mõjutatud isikuandmed, algab võimaliku IKÜM-i kohase teate tähtaeg intsidendist teadasaamisest, mitte kolimisest. Taust on lehel IKÜM-i teavitamiskohustus: 72 tundi.
- Seadke uus süsteem üles puhtalt. Toetatud PHP versioon, ajakohased paketid, karastatud seadistus enne, kui esimene fail üle kantakse.
- Kandke üle ainult kontrollitud sisu. Kood puhtast allikast, andmebaas ja meedia pärast kontrolli.
- Vahetage kõik ligipääsuandmed. Andmebaas, administraatorikontod, SSH, FTP, API võtmed, ka need, mis on seadistusfailides.
- Lülitage ümber ja jälgige. DNS-i ümberlülitus, seejärel mõnda aega tihedam seire.
- Lõpetage vana leping. Alles siis, kui logid ja varukoopiad on kindlustatud ja uus töö on stabiilne.
Ärge öelge vana lepingut üles enne, kui logid ja varukoopiad on teie käes. Lepingu lõppedes võidakse pakkuja juures kustutada andmeid, mida vajate kindlustajale, ametiasutustele või enda uurimiseks.
Mida te kaasa ei tohiks võtta
Mugav oleks lihtsalt kopeerida kogu veebikataloog või serveri tõmmis. Just see on pärast intsidenti riskantne. Veebishellid maskeerivad end kahjutute failidena, tagauksed peituvad seadistusfailides nagu .htaccess või .user.ini ning sissetoodud kood võib asuda andmebaasi sisus.
Kandke rakenduse kood seetõttu üle puhtast allikast, näiteks sobiva versiooni tootjapaketist või oma versioonihaldussüsteemist. Meedia võtke kaasa ilma käivitatavate failideta, andmebaas pärast silmatorkava sisu ja uute administraatorikontode kontrolli. Mis vanas süsteemis leiti, aitab seda kontrolli teha.
Mõelge ka kõigele, mis vana pakkuja juures lisaks veebisaidile asub. E-postkastid, DNS-kirjed, sertifikaadid ja edasisuunamised unustatakse kolimisel kergesti. Vähendage DNS-kirjete kehtivusaega mõni päev enne ümberlülitust, et muudatus jõuaks külastajateni kiiresti. Kui e-post kolib kaasa, planeerige postkastide vahetus eraldi, sest ka seal võivad pärast intsidenti olla ligipääsuandmed mõjutatud.
Uue veebimajutaja valik turvalisuse järgi
Hind ja salvestusruum on iga pakkumise juures olemas. Otsustavad turvaküsimused peate sageli ise esitama. Järgmine loetelu aitab võrrelda:
| Kriteerium | Küsimus pakkujale | Miks see loeb |
|---|---|---|
| Paikamisprotsess | Kuidas ja millises ajaraamis PHP turvauuendused paigaldatakse ja taaskäivitatakse? | PHP2Shell on näidanud, kui oluline on tõendatav protsess |
| Tõend | Kas saan soovi korral kirjaliku kinnituse paigatud seisu kohta? | Alus teie enda dokumentatsioonile |
| PHP versioonid | Milliseid harusid pakutakse ja kui kaua veel? | Uuendusteta vanad harud on püsiv risk |
| Eraldatus | Kas iga veebisait töötab oma kasutaja ja oma PHP protsessiga? | Piirab kahju, kui naabrit rünnatakse |
| Logid | Kas mul on ligipääs juurdepääsu- ja vealogidele ning kui kaua neid säilitatakse? | Ilma logideta puudub selgitamise võimalus |
| Varukoopiad | Kui sageli, kui kaua, veebiserverist eraldi, taastekatsega? | Taastamine pärast intsidenti |
| Hädaabikontakt | Kuidas jõuan intsidendi korral asjatundliku inimeseni? | Ajal on hädaolukorras kõige vähem varu |
| Andmetöötlus | Kas on olemas IKÜM-i kohane leping ja alltöötlejate nimekiri? | Kohustuslik isikuandmete puhul |
Paikamisseisu küsimise näidise pakub juhend Küsige veebimajutajalt paigatud seisu kohta. See sobib ka pakkujate võrdlemiseks enne lepingu sõlmimist.
Kas teine töömudel on parem vastus?
Mõnikord ei ole probleem niivõrd veebimajutajas kui töömudelis. Kes peab oma serverit ilma korrapärase hoolduseta, on hästi hallatud Managed-pakkumises sageli paremini kaitstud. Vastupidi, oma IT-ga ettevõte võib saada paikamisaegade üle rohkem kontrolli, kui haldab ise. Kaalutluse kirjeldab artikkel Hallatud majutus või oma server?.
Olenemata mudelist kehtib: pange kohustuste jaotus kirja. Kes paigaldab PHP uuendused, kes taaskäivitab, kes kontrollib rakendust, kes võtab hädaolukorras kellegagi ühendust? PHP2Shelli puhul tekkisid paljud viivitused just siin, sest kumbki pool arvas, et teine tegeleb sellega.
Kuidas PHP SOS konkreetselt aitab?
- Kindlustame vana süsteemi logid ja andmed ning selgitame välja, mis intsidendi ajal juhtus.
- Ehitame uue süsteemi karastatult üles ja kanname üle ainult kontrollitud sisu puhastest allikatest.
- Kontrollime uute pakkujate pakkumisi turvakriteeriumide alusel ja esitame õiged küsimused.
- Käimasoleva intsidendi korral töötame oma intsidendile reageerimise raames, kuni intsident on lõpetatud ja dokumenteeritud.
Korduma kippuvad küsimused
Kas peaksin pärast häkkimist veebimajutajat kohe vahetama?
Mitte kohe. Esmalt tuleb jäljed kindlustada, intsident piiritleda ja põhjus selgitada. Kiirustades tehtud kolimine võib kahjuliku koodi kaasa viia ja hävitada vana pakkuja juures tõendeid.
Kas veebimajutaja oli süüdi, kui minu veebisaiti rünnati PHP2Shelli kaudu?
See sõltub lepingust ja ajahetkest. Jagatud majutuse puhul vastutab PHP uuenduste eest tavaliselt veebimajutaja, oma serverite puhul haldaja. Paigad ilmusid 21. oktoobril 2026; kas ja millal need paigaldati, saab selgitada ainult tõenditega. Vastutuse küsimustes pöörduge õigusnõustaja poole.
Milliseid andmeid tohin uuele veebimajutajale kaasa võtta?
Ainult kontrollitud sisu: andmebaas pärast sissetoodud koodi kontrolli, meedia ilma käivitatavate failideta ja kood puhtast allikast, näiteks tootja paketist või teie versioonihaldussüsteemist. Kompromiteeritud süsteemi täielikke serveripilte või veebikatalooge ei tohiks kontrollimata üle kanda.
Kas pean pärast intsidenti kaasama andmekaitse?
Kui võivad olla mõjutatud isikuandmed, võib olla IKÜM-i kohane teavitamiskohustus, üldjuhul 72 tunni jooksul. Uue veebimajutaja juures vajate lisaks andmetöötlusleppe. Selgitage see välja oma andmekaitsespetsialistiga; see ei ole õigusnõu.