Na kratko: Kdor želi po varnostnem incidentu zamenjati ponudnika gostovanja, naj najprej zavaruje dokaze in razjasni incident, nato na na novo postavljen sistem prenese samo preverjene podatke in šele nato odpove staro pogodbo. Novega ponudnika izberite po varnostnih merilih: dokazljivi postopki popravljanja, ločevanje strank, dostop do dnevnikov, varnostne kopije in jasni kontaktni osebi. Zamenjava ponudnika gostovanja je smiselna, kadar manjka zaupanje ali kakovost storitve, vendar čiščenja ne nadomešča.
Ko zaupanja ni več
Po PHP2Shell so mnoga podjetja svojega ponudnika gostovanja prvič doživela pod pritiskom. Nekateri so hitro dobili jasen odgovor o stanju popravkov. Drugi so na odgovor čakali dneve, dobili samo splošne fraze ali ugotovili, da je njihova spletna stran tekla na zastareli različici PHP. Če se zraven pojavi še incident, je želja po zamenjavi razumljiva.
Zamenjava ponudnika gostovanja pa ni korak pri obvladovanju incidenta, ampak nova postavitev po njem. Kdor jo izvede v napačnem vrstnem redu, v najslabšem primeru s seboj odnese napadalca in hkrati izgubi sledi, ki kažejo, kaj se je zgodilo.
Pravilen vrstni red pri zamenjavi
- Zavarujte sledi, dokler so še tu. Dnevniki, datoteke in podatkovna baza starega sistema sodijo v varnostno kopijo, preden se karkoli izbriše ali odpove. Starega ponudnika izrecno vprašajte po dnevnikih dostopov in napak od 20. oktobra 2026 ter po času njihovega hranjenja. Kako ravnati, opisuje prispevek Zavarujte dokaze, preden začnete znova.
- Omejite incident. Kateri sistemi so prizadeti, kateri dostopi so bili uporabljeni, kateri podatki so bili dosegljivi? Od tega so odvisne obveznosti prijave in vprašanje, kaj smete vzeti s seboj.
- Preverite obveznosti prijave. Če bi bili lahko prizadeti osebni podatki, rok za morebitno prijavo po GDPR začne teči s seznanitvijo z incidentom, ne s selitvijo. Ozadje je na strani Obveznost prijave po GDPR: 72 ur.
- Nov sistem postavite čisto. Podprta različica PHP, aktualni paketi, utrjena konfiguracija, preden se prenese prva datoteka.
- Prenesite samo preverjeno. Koda iz čistega vira, podatkovna baza in mediji po pregledu.
- Zamenjajte vsa dostopna gesla. Podatkovna baza, skrbniški računi, SSH, FTP, ključi API, tudi tisti v konfiguracijskih datotekah.
- Preklopite in opazujte. Sprememba DNS, nato nekaj časa strožji nadzor.
- Odpovejte staro pogodbo. Šele ko so dnevniki in varnostne kopije zavarovani in novo delovanje stabilno teče.
Stare pogodbe ne odpovejte, preden imate dnevnike in varnostne kopije v rokah. S koncem pogodbe lahko ponudnik izbriše podatke, ki jih potrebujete za zavarovalnico, organe ali lastno razjasnitev.
Česa ne smete vzeti s seboj
Udobno bi bilo preprosto kopirati celoten spletni imenik ali sliko strežnika. Prav to je po incidentu tvegano. Webshelli se zamaskirajo v neškodljive datoteke, stranska vrata so skrita v konfiguracijskih datotekah, kot sta .htaccess ali .user.ini, vnesena koda pa je lahko tudi v vsebini podatkovne baze.
Kodo aplikacije zato prenesite iz čistega vira, na primer iz paketa proizvajalca v ustrezni različici ali iz svojega sistema za upravljanje različic. Medije prevzemite brez izvršljivih datotek, podatkovno bazo po pregledu glede sumljivih vsebin in novih skrbniških računov. Kar je bilo najdeno na starem sistemu, pri tem pregledu pomaga.
Pomislite tudi na vse, kar je pri starem ponudniku poleg spletne strani. Poštni predali, vnosi DNS, certifikati in preusmeritve se pri selitvi zlahka pozabijo. Nekaj dni pred preklopom skrajšajte veljavnost vnosov DNS, da sprememba hitro pride do obiskovalcev. Če se selijo tudi e-pošta, menjavo poštnih predalov načrtujte ločeno, saj so lahko tudi tam po incidentu prizadeta dostopna gesla.
Novega ponudnika izberite po varnosti
Cena in prostor na disku sta v vsaki ponudbi. Odločilna varnostna vprašanja morate večinoma zastaviti sami. Naslednji seznam pomaga pri primerjavi:
| Merilo | Vprašanje ponudniku | Zakaj je pomembno |
|---|---|---|
| Postopek popravljanja | Kako in v kakšnem okviru se nameščajo varnostne posodobitve PHP in izvaja ponovni zagon? | PHP2Shell je pokazal, kako pomemben je dokazljiv postopek |
| Dokaz | Ali na zahtevo dobim pisno potrditev stanja popravkov? | Podlaga za vašo dokumentacijo |
| Različice PHP | Katere veje so na voljo in do kdaj? | Stare veje brez posodobitev so stalno tveganje |
| Ločevanje | Ali vsaka spletna stran teče z lastnim uporabnikom in lastnim procesom PHP? | Omeji škodo, če je napaden sosed |
| Dnevniki | Ali imam dostop do dnevnikov dostopov in napak, kako dolgo se hranijo? | Brez dnevnikov ni razjasnitve |
| Varnostne kopije | Kako pogosto, kako dolgo, ločeno od spletnega strežnika, s preizkusom obnovitve? | Obnovitev po incidentu |
| Kontakt za nujne primere | Kako ob incidentu dosežem strokovno osebo? | Čas je v nujnem primeru najredkejši dejavnik |
| Obdelava po naročilu | Ali obstaja pogodba po GDPR in seznam podizvajalcev? | Obveznost pri osebnih podatkih |
Predlogo za vprašanje o stanju popravkov ponuja vodnik Vprašajte ponudnika gostovanja po stanju popravkov. Primeren je tudi za primerjavo ponudnikov pred sklenitvijo pogodbe.
Je boljši odgovor drug model delovanja?
Včasih težava ni toliko pri ponudniku gostovanja kot pri modelu delovanja. Kdor upravlja lasten strežnik brez redne oskrbe, je pogosto bolje na varnem z dobro oskrbovano upravljano ponudbo. Obratno lahko podjetje z lastno IT z lastnim upravljanjem pridobi več nadzora nad časi popravljanja. Presojo opisuje prispevek Upravljano gostovanje ali lasten strežnik?.
Ne glede na model velja: delitev nalog zapišite. Kdo namešča posodobitve PHP, kdo izvede ponovni zagon, kdo preveri aplikacijo, kdo komu sporoči v nujnem primeru? Pri PHP2Shell so se številne zamude pojavile prav tu, ker je vsaka stran mislila, da bo poskrbela druga.
Kako PHP SOS pomaga konkretno?
- Zavarujemo dnevnike in podatke starega sistema ter razjasnimo, kaj se je zgodilo ob incidentu.
- Nov sistem zgradimo utrjeno in prenesemo samo preverjene vsebine iz čistih virov.
- Ponudbe novih ponudnikov preverimo po varnostnih merilih in zastavimo prava vprašanja.
- Pri tekočem incidentu delamo v okviru svojega odziva na incidente, dokler incident ni zaključen in dokumentiran.
Pogosta vprašanja
Ali naj po vdoru takoj zamenjam ponudnika gostovanja?
Ne takoj. Najprej je treba zavarovati sledi, omejiti incident in razjasniti vzrok. Prenagljena selitev morda odnese škodljivo kodo in lahko uniči dokaze pri starem ponudniku.
Ali je bil kriv ponudnik gostovanja, če je bila moja spletna stran napadena prek PHP2Shell?
To je odvisno od pogodbe in časa. Pri skupnem gostovanju je za posodobitve PHP običajno odgovoren ponudnik gostovanja, pri lastnih strežnikih upravljavec. Popravki so izšli 21. oktobra 2026; ali in kdaj so bili nameščeni, je mogoče razjasniti samo z dokazi. Za vprašanja odgovornosti se posvetujte z odvetnikom.
Katere podatke smem vzeti s seboj k novemu ponudniku gostovanja?
Samo preverjene vsebine: podatkovno bazo po pregledu na vneseno kodo, medije brez izvršljivih datotek in kodo iz čistega vira, kot sta paket proizvajalca ali vaš sistem za upravljanje različic. Celotnih slik strežnika ali spletnih imenikov z ogroženega sistema ne prenašajte nepreverjeno.
Ali moram po incidentu vključiti varstvo podatkov?
Če bi bili lahko prizadeti osebni podatki, lahko obstaja obveznost prijave po GDPR, praviloma v 72 urah. Pri novem ponudniku gostovanja potrebujete tudi pogodbo o obdelavi podatkov po naročilu. To razjasnite s svojim pooblaščencem za varstvo podatkov; to ni pravno svetovanje.