Na kratko: Če je bila vaša spletna stran vdrta, vam ta kontrolni seznam pomaga, da ničesar ne pozabite: najprej zajeziti in zavarovati dokaze, nato najti vzrok in očistiti, potem obnoviti vse dostope, preveriti obveznosti in incident dokumentirano zaključiti. Vrstni red je pomemben, saj kdor najprej briše, izgubi sledi, kdor samo čisti, ne da bi zaprl ranljivost, pa bo znova napaden.
Za kaj velja ta kontrolni seznam, ko je spletna stran vdrta
Kontrolni seznam je namenjen vodstvu, lastnikom in odgovornim za IT po potrjenem ali verjetnem napadu na spletno stran, spletno trgovino ali spletni strežnik PHP. Primeren je tudi po PHP2Shell, če je bil strežnik pred posodobitvijo dosegljiv in obstajajo namigi na kompromitacijo.
Vsaka točka ne ustreza vsakemu okolju. Seznam kljub temu v celoti preglejte in pri vsaki točki zabeležite, ali je opravljena, neuporabna ali odprta. Ta zapisnik je pozneje dragocen za zavarovalnico, varstvo podatkov in interno obravnavo.
Pri vsakem koraku vpišite datum, uro, odgovorno osebo in rezultat. Če je udeleženih več oseb, določite eno, ki seznam vodi in beleži odločitve.
1. faza: takojšnja zajezitev in zavarovanje
- Omejite škodo: Spletno stran postavite v način vzdrževanja ali jo odklopite z omrežja, če so obiskovalci ogroženi ali bi lahko podatki odtekali. BSI (nemški zvezni urad za informacijsko varnost) pri PHP2Shell priporoča, da se nepopravljeni spletni strežniki začasno odklopijo z omrežja, če posodobitev ni takoj mogoča.
- Ničesar ne brišite: Ne odstranjujte datotek, strežnika ne postavljajte znova in ne praznite dnevnikov, preden so sledi zavarovane.
- Zavarujte dnevnike: Dnevnike dostopov, napak, PHP-FPM in sistemske dnevnike kopirajte na drug sistem in zabeležite kontrolne vsote. Za PHP2Shell strokovni tisk svetuje hranjenje dnevnikov od 20. 10. 2026.
- Zavarujte sliko stanja: Kopijo datotek in podatkovne zbirke, pri virtualnih strežnikih posnetek (snapshot), ustvarite kot dokazno stanje in je ne spreminjajte.
- Obvestite odgovorne: Zgodaj vključite vodstvo, pooblaščenca za varstvo podatkov, ponudnika gostovanja in, če obstaja, zavarovanje za kibernetska tveganja. Številna zavarovanja imajo obveznosti prijave.
2. faza: iskanje vzroka in čiščenje
- Ugotovite vstopno točko: Ovrednotite dnevnike, spremembe datotek in različice. Preverite sam PHP, CMS, teme, razširitve, dostopne podatke in storitve strežnika. Brez znanega vzroka tveganje ponovnega napada ostaja.
- Zaprite ranljivost: PHP posodobite na odpravljeno različico (8.5.12, 8.4.27, 8.3.36 ali 8.2.35 oziroma potrjen backport ponudnika), posodobite CMS in razširitve, znova zaženite vse workerje PHP.
- Omejite obdobje: Določite najzgodnejši trenutek sumljive dejavnosti. Ta odloča, katere varnostne kopije so lahko čiste in kateri podatki so lahko prizadeti.
- Odstranite stranska vrata: Preverite in odstranite webshelle, tuje datoteke PHP v mapah za nalaganje in predpomnilnik, spremenjene jedrne datoteke, cron opravila, ključe SSH in sistemske storitve. Jedrne datoteke zamenjajte iz čistega vira.
- Očistite podatkovno zbirko: Odstranite neznane skrbniške račune, vnesene skripte v vsebinah in nastavitvah ter vsebine s spamom.
- Razmislite o ponovni postavitvi: Pri globoki kompromitaciji strežnika je ponovna postavitev na svežem, popravljenem sistemu s preverjenimi podatki pogosto zanesljivejša pot kot čiščenje v delujočem sistemu.
3. faza: obnova dostopov in utrjevanje
- Spremenite gesla: Za CMS, račun pri ponudniku gostovanja, panel, podatkovno zbirko, FTP, SFTP, SSH in e-pošto, in sicer s čiste naprave.
- Zamenjajte ključe in žetone: Znova ustvarite ključe API, vmesnike za plačilne in dostavne storitve, ključe aplikacije CMS-ja, ključe SSH in certifikate, ki so ležali na strežniku.
- Končajte seje: Odjavite vse aktivne prijave v CMS in pri storitvah ter preverite registrirane naprave za dvofaktorsko prijavo.
- Aktivirajte dvofaktorsko prijavo: Za vse skrbniške dostope, vključno z gostovanjem, domeno in DNS.
- Utrdite strežnik: Preverite in dokumentirajte nastavitve PHP, pravice datotek, blokade izvajanja v mapah za nalaganje, požarni zid in varnostne glave.
4. faza: obveznosti, komunikacija in zaključek
- Preverite obveznosti prijave: Če so lahko prizadeti osebni podatki, je lahko potrebna prijava po 33. členu GDPR v 72 urah. Oceno opravi pooblaščenec za varstvo podatkov ali odvetnik. Panožne obveznosti, na primer po NIS2, preverite posebej.
- Razmislite o ovadbi: Osrednje kontaktne točke za kibernetsko kriminaliteto (Zentrale Ansprechstellen Cybercrime, ZAC) nemške policije sprejemajo ovadbe podjetij. Zavarovani dnevniki so za to pomembna podlaga.
- Obvestite stranke in Google: Prizadete obvestite stvarno in usklajeno. Če Google prikazuje opozorilo, po čiščenju zahtevajte ponovni pregled, kot je opisano v vodniku Odstranitev Googlovega opozorila.
- Dokumentirajte zaključek in nadzorujte: V poročilu zapišite vzrok, obdobje, ukrepe in odprte točke, izpeljite spoznanja za načrt za nujne primere in sisteme v naslednjih tednih okrepljeno nadzorujte.
Pogoste napake pri nadaljnji obravnavi
Številni incidenti se zavlečejo, ker se v prvem navalu prihrani na napačnem mestu ali ukrepa prehitro. Te napake se izogibajte:
- Odstranitev samo vidnega: Izbrisana stran s spamom ali odstranjena preusmeritev ni dokaz za čisto spletno stran. Stranska vrata pogosto ostanejo neopažena.
- Spreminjanje gesel s prizadetega sistema: Če na računalniku ali strežniku še teče škodljiva programska oprema, lahko novi dostopni podatki takoj znova odtečejo.
- Slepo obnavljanje varnostne kopije: Brez zaprte ranljivosti in brez preverjanja varnostne kopije napadalec hitro spet stoji pri vratih.
- Razumevanje popravka kot razrešnice: Posodobitev na odpravljeno različico PHP ne dokazuje, da prej ni bilo nič narobe, in vnesene škodljive programske opreme ne odstrani.
- Prepozno preverjanje obveznosti: Roki začnejo teči z seznanitvijo z incidentom, ne s koncem čiščenja.
- Brez dokumentacije: Brez zapisnika je na vprašanja zavarovalnice, organov ali strank pozneje komaj mogoče odgovoriti.
Ta kontrolni seznam ne nadomešča pravnega svetovanja. Pri vprašanjih o obveznostih prijave, odgovornosti ali zavarovanju se obrnite na pooblaščenca za varstvo podatkov, odvetnika ali zavarovalnico.
Kako PHP SOS pomaga konkretno?
- Prevzamemo strukturirani odziv na incident in kontrolni seznam z vami izvedemo, točko za točko z zapisnikom.
- Dnevnike in stanja sistema zavarujemo tako, da ostanejo uporabna za zavarovalnico, organe in morebitno IT-forenziko.
- Zapremo ranljivost, očistimo ali na novo postavimo ter dostope obnovimo v pravem vrstnem redu.
- Dostavimo zaključno poročilo z vzrokom, ukrepi in priporočili ter sisteme na željo po tem še naprej nadzorujemo.
Pogosta vprašanja
Kaj naj naredim najprej, če je bila moja spletna stran vdrta?
Ohranite mirno kri, ničesar ne brišite in omejite škodo. Spletno stran po potrebi odklopite z omrežja ali jo postavite v način vzdrževanja ter zavarujte dnevnike in datoteke, preden začnete čistiti. Nato sledita iskanje vzroka in čiščenje.
Ali zadošča, da spletno stran obnovim iz varnostne kopije?
Praviloma ne. Varnostna kopija lahko že vsebuje škodljivo kodo, ranljivost, prek katere je napadalec prišel, pa je po obnovitvi še odprta. Najprej zaprite vzrok, nato preverjeno, čisto stanje namestite na posodobljen sistem.
Ali moram vdor prijaviti organu za varstvo podatkov?
Če so lahko prizadeti osebni podatki, 33. člen GDPR načeloma predvideva prijavo v 72 urah po seznanitvi, če tveganje za prizadete osebe ni malo verjetno. Oceno opravi vaš pooblaščenec za varstvo podatkov ali odvetnik.
Kdaj je incident res zaključen?
Ko je vzrok zaprt, so vsa znana stranska vrata odstranjena, dostopi obnovljeni, obveznosti izpolnjene in ukrepi dokumentirani. Zraven sodi tudi obdobje okrepljenega nadzora po tem, da se prepoznajo spregledane sledi.