Trenutno stanje: PHP2Shell. Dve kritični ranljivosti PHP (CVSS 9,2) omogočata izvedbo škodljive kode brez prijave. Popravki od 21. 10. 2026.Kaj je zdaj treba storiti →

Incident response ob napadih na strežnike

Urejena obravnava incidenta ob napadih na spletne strežnike: slika stanja, omejitev, odstranitev, obnova in priprava po incidentu s trdnimi vlogami.

Stanje 4 min branjaStoritve

Na kratko: Če napad zadene več kot eno samo spletno stran, potrebujete izvajalca incident response, ki incident obravnava urejeno. Prevzamemo sliko stanja, omejitev škode, čiščenje in varno obnovo, z jasnimi vlogami in brezhibno dokumentacijo. Odločitve ostanejo vaše, mi poskrbimo za tehnično podlago.

Kaj incident response pomeni ob napadih na strežnike

Incident response je urejena obravnava varnostnega incidenta. Namesto zmedenih posameznih dejanj delo sledi trdnim fazam: prepoznati in oceniti, omejiti, odstraniti, obnoviti, pripraviti po incidentu. Vsak ukrep se zabeleži s časom in obrazložitvijo.

Pri spletnih strežnikih je to še posebej pomembno. Strežnik z aplikacijami PHP pogosto vsebuje dostopne podatke do podatkovnih zbirk, ponudnikov plačil, poštnih strežnikov in vmesnikov. Kdor je tam vdrl, se lahko premika naprej. Stanje po PHP2Shell kaže, kako hitro lahko nastane takšen položaj: izvajanje kode brez avtentikacije, po podatkih Unit 42 več kot 22,6 milijona izpostavljenih instanc in nobenih objavljenih, potrjenih indikatorjev ogroženosti (Indicators of Compromise).

Kdaj potrebujete izvajalca incident response

  • prizadetih je več strežnikov ali aplikacij ali bi lahko bili prizadeti
  • obstaja sum, da so iztekli osebni podatki ali plačilni podatki
  • napadalec je morda še aktiven, na primer prek tekočih povezav ali novih računov
  • obstaja izsiljevanje ali javna napoved napada
  • zavarovalnica, organi ali poslovni partnerji pričakujejo dokumentiran potek

Pri posamezni okuženi spletni strani pogosto zadošča nujna pomoč pri vdrti spletni strani. Prehod na polno obravnavo incidenta z vami obravnavamo, ko se pokaže večji obseg.

Kako konkretno pomaga PHP SOS?

  1. Triaža in slika stanja: razjasnimo, kaj je bilo opaženo, kateri sistemi in podatki so lahko prizadeti in koga je treba vključiti interno. Rezultat je prva pisna slika stanja z odprtimi vprašanji.
  2. Zavarovanje sledi in omejitev: dnevniki, datotečni sistemi in podatkovne zbirke se zavarujejo, preden posežemo. Nato izoliramo prizadete sisteme, blokiramo ogrožene dostope in prekinemo prepoznavne povezave napadalca.
  3. Odstranitev: zapremo vstopno točko, na primer s popravkom na odpravljene različice PHP in ponovnim zagonom vseh workerjev, odstranimo stranska vrata in zamenjamo skrivnosti. Za podrobno analizo po potrebi vključimo specializirane partnerje za IT-forenziko.
  4. Obnova: sistemi se nadzorovano vrnejo v obratovanje, po možnosti iz čistih virov ali na na novo postavljenih strežnikih. Nato jih okrepljeno opazujemo glede ponovnih nepravilnosti.
  5. Priprava po incidentu: prejmete zaključno poročilo s časovnico, vzroki, ukrepi in priporočili. Skupaj zapišemo, kaj naj bo naslednjič hitreje.
Ukrepajte takoj

Ohranite dnevnike strežnika in ne spreminjajte sistemov, dokler ni zavarovano stanje. BSI pri PHP2Shell priporoča, da se spletni strežniki, ki jih ni mogoče takoj popraviti, začasno odklopijo z omrežja.

Vloge in komuniciranje med incidentom

Incident potrebuje jasne odgovornosti. Obnesla se je majhna skupina: oseba s pooblastilom za odločanje, tehnična kontaktna oseba na vaši strani in mi kot tehnično vodstvo. Sestanki o stanju potekajo v rednih presledkih, rezultati se zapišejo.

Vzporedno tečejo naloge, ki jih ne prevzamemo, a zanje zagotovimo dejstva: preverjanje obveznosti prijave po GDPR v 72 urah, obveščanje zavarovalnice, morebitna ovadba in krizno komuniciranje s strankami in partnerji.

Kaj potrebujemo od vas in kaj dobite

Potrebujemo skrbniške dostope do prizadetih sistemov, pregled infrastrukture in izvajalcev, osebo s pooblastilom za odločanje in pripravljenost, da se sistemi po potrebi začasno izklopijo. Koristni so obstoječi načrti za nujne primere, omrežne skice in varnostne kopije z datumom.

Dobite tekoči zapisnik incidenta, redne slike stanja v razumljivem jeziku, zaključno poročilo za vodstvo, pooblaščence za varstvo podatkov in zavarovalnico ter prednostni seznam izboljšav. Kako se bolje pripraviti na naslednji incident, opisuje stran Priprava IT-načrta za nujne primere za spletne strežnike.

Tipične napake v prvih urah

Številni incidenti postanejo težji, ker se v razburjenju dobronamerni koraki izvedejo v napačnem vrstnem redu. Te vzorce pogosto vidimo:

  • Takoj znova postaviti: strežnik se izbriše in znova namesti, preden je bilo kaj zavarovano. Pozneje ni več mogoče razjasniti, ali so podatki iztekli.
  • Gesla spreminjati z okuženega sistema: če ima napadalec še dostop, vidi tudi nova gesla.
  • Izbrisati samo vidno datoteko: webshell je odstranjen, druga stranska vrata v cron opravilu ostanejo.
  • Popravljati brez ponovnega zagona: nove datoteke PHP ležijo na disku, stari workerji pa še naprej tečejo v pomnilniku.
  • Nihče ne vodi zapisnika: pozneje nihče več ne ve, kdo je kdaj kaj spremenil. To otežuje pogovore z zavarovalnico in organi.

Usklajen potek te napake prepreči, ne da bi zakasnil omejitev škode.

Česa ne obljubljamo

Ne obljubljamo, da bo vsak incident v celoti razjasnjen; brez sledi ostanejo vprašanja odprta, kar tudi zapišemo v poročilo. Ne nudimo pravnega svetovanja in ne podajamo izjav o odgovornosti ali zavarovalnem kritju. Naš cilj je jasen konec: na incidentu delamo, dokler ni zaključen in dokumentiran.

Pogosta vprašanja

Kakšna je razlika med incident response in IT-forenziko?

Incident response ima cilj incident omejiti in varno obnoviti delovanje. IT-forenzika podrobno in z dokazno vrednostjo razjasni, kaj se je zgodilo. V praksi se obe prepletata, forenzika pogosto vzporedno zavaruje sledi.

Kdaj naj pritegnem izvajalca incident response?

Takoj ko obstaja sum, da je imel napadalec dostop do sistemov in obsega ne morete zanesljivo oceniti. Čim prej se začne zavarovanje sledi, več je pozneje mogoče dokazati.

Kdo odloča med incidentom?

Odločitve sprejemate vi, na primer o izklopih, komuniciranju ali prijavah. Mi pripravimo tehnične podlage, pokažemo možnosti z njihovimi posledicami in odločitve izvedemo.

Ali moram vključiti policijo?

Ovadba je v številnih primerih smiselna in za nekatere zavarovalnice pomembna. Pristojne so osrednje kontaktne točke za kibernetsko kriminaliteto (Zentrale Ansprechstellen Cybercrime) nemške policije. Ali in kdaj podate ovadbo, odločite z odvetnikom.

Viri

Takojšnji stik

Vsaka ura šteje. Pišite nam zdaj.

Na kratko opišite sistem, različico PHP in opažanje. Odzovemo se, razjasnimo stanje in delamo na daljavo, dokler incident ni zaključen in dokumentiran.

Takojšnja pomoč