Na kratko: Ste prizadeti? Pokličite nas. Pomagamo. Če sumite, da je bil vaš strežnik vdrt, je najprej pomembna ena stvar: ohraniti sledi. Od prvega sporočila na daljavo prevzamemo oceno stanja, zavarovanje, zajezitev, čiščenje in dokumentacijo, dokler incident ni zaključen.
Zdaj ničesar ne brišite in ničesar ne postavljajte znova. Tudi varnostne kopije ne obnavljajte, preden je vse zavarovano. Kdor pospravlja, uniči prav tiste sledi, ki kažejo, kako je napadalec prišel noter. Prijavite nujni primer, nato nadaljujemo skupaj.
Ste prizadeti? Znaki, da je bil strežnik vdrt
Za prijavo zadošča sum. Napada vam ni treba dokazati. Tipični znaki so:
- Spletni strežnik ali PHP-FPM zaganja procese, kot sta
shalibash. To je močan opozorilni znak, ki ga pojasnjujemo na strani Spletni strežnik zažene lupino. - V mapah za nalaganje, predpomnilnik ali začasne datoteke ležijo nove ali neznane datoteke PHP.
- Obstajajo opravila cron, ki jih ni ustvaril nihče, ali ključi SSH, ki jih nihče ne zna pripisati.
- Obremenitev je brez vidnega razloga visoka ali strežnik vzpostavlja nenavadne odhodne povezave.
- Pošta z vašega strežnika pristane med nezaželeno ali je zavrnjena.
- Ponudnik gostovanja, stranka ali opozorilo v brskalniku sporoča škodljivo kodo.
- V CMS-ju se pojavijo skrbniški računi, ki jih ni ustvaril nihče.
Več znakov najdete v prispevku Ali sem že ogrožen?. Če ustreza več točk, strežnik obravnavajte kot vdrt, dokler ni dokazano nasprotno.
Strežnik vdrt: kaj storite takoj
- Ohranite mirnost in ničesar ne spreminjajte. Ne brišite datotek, ne delajte »hitrih popravil«, ne nameščajte znova čez staro stanje.
- Zabeležite čas. Zapišite, kaj ste kdaj opazili in kdo je nazadnje spreminjal sistem.
- Ohranite dnevnike. Dnevniki dostopa, napak in sistemski dnevniki se ne smejo rotirati ali prepisovati. Pri PHP2Shell strokovni tisk svetuje hrambo strežniških dnevnikov od 20. 10. 2026 naprej.
- Zmanjšajte napadalno površino. Strežnik odklopite z javnega omrežja ali ga zaprite s požarnim zidom, če bi lahko podatki uhajali. Ne ugašajte ga kar tako.
- Zberite dostope. Kdo ima dostop prek SSH, upravljalne plošče, FTP, CMS-ja in zbirke podatkov? Gesla zamenjajte šele po dogovoru in samo s čiste naprave.
- Določite kontaktno osebo. Dosegljiva naj bo oseba s pooblastilom za odločanje, tudi o ugašanju in ponovnih zagonih.
- Javite se zdaj. Pokličite ali pišite po WhatsAppu. Vse nadaljnje z vami razjasnimo korak za korakom.
Odklopiti z omrežja ali pustiti delovati?
To je najpogostejše vprašanje v prvih minutah in nanj ni splošnega odgovora. Če teče spletna trgovina s plačili ali portal s podatki o strankah, praviloma prevlada zaščita podatkov. Takrat je začasna izolacija prava, na primer prek strani za vzdrževanje ali pravila požarnega zidu, ki dopušča samo vaše skrbnike.
Trdo ugašanje pa je redko najboljši prvi korak, ker v delovnem pomnilniku ležijo sledi, ki jih ponovni zagon izbriše. Bolje je posneti sliko sistema, na primer posnetek (snapshot) pri ponudniku gostovanja, preden se kar koli spremeni. Ob stanju PHP2Shell BSI priporoča, da se spletni strežniki začasno odklopijo z omrežja, če posodobitev ni takoj mogoča. To ne pomeni, da je bil vsak ugasnjen strežnik vdrt.
Ali boste v svojem primeru izolirali, upočasnili ali pustili delovati, odločimo z vami glede na to, kaj leži na sistemu.
Postaviti znova ali očistiti?
Mnogi bi strežnik najraje takoj zgradili znova. To ni napačno, vendar šele po zavarovanju. Sicer ostane nejasno, kako je napadalec prišel noter, in ista pot je odprta tudi novemu sistemu. Tehtanje opisuje stran Strežnik postaviti znova ali očistiti?, zavarovanje pred novo postavitvijo pa stran Zavarujte dokaze, preden postavite znova.
Pomembno: sama posodobitev PHP problema ne reši. Ranljivost zapre, ne odstrani pa že vnesene škodljive programske opreme. Kako sledi najdete v zapisnikih, opisuje stran Analiza dnevnikov spletnega strežnika po napadu. Predpostavite tudi, da so bili dostopni podatki iz konfiguracijskih datotek prebrani: dostopi do zbirke podatkov, e-pošte in API-jev sodijo na seznam skrivnosti, ki jih je treba obnoviti.
Kako konkretno pomaga PHP SOS?
- Ocena stanja: Z vami razjasnimo, kaj je bilo opaženo, kateri sistemi so lahko prizadeti in kateri podatki tam ležijo.
- Zavarovanje in zapiranje: Zavarujemo datoteke, zbirko podatkov in dnevnike, preden se kar koli spremeni. Nato napad zajezimo in zapremo vstopna vrata, pri PHP2Shell s popravkom in ponovnim zagonom vseh procesov PHP.
- Preverjanje in čiščenje: Iščemo webshelle, stranska vrata, opravila cron in tuje dostope ter jih odstranimo. Podrobnosti so na strani Odstranjevanje zlonamerne kode in webshellov.
- Utrjevanje in poročilo: Prejmete dokumentacijo s časovnico, najdbami in priporočili. Če incident preraste en strežnik, preidemo v strukturirano odzivanje na incidente.
Česa ne storite
V stresu se zgodijo napake, ki jih je mogoče preprečiti. Ne brišite »sumljivih« datotek na sum, ne da bi jih prej zavarovali. Ne izvajajte ukazov s forumov, ki jih ne razumete. In ne nameščajte varnostnih vtičnikov na strežnik, ki je morda že ogrožen: škodljiva koda lahko zavede skenerje, rezultat pa vas uspava v lažni varnosti. Previdni bodite tudi pri nasvetih, naj se blokirajo vse zahteve z določenim ID-jem seje; strokovni avtorji takšne nasvete za PHP2Shell izrecno zavračajo. Svojo različico varno preverite z php -v in pogledom v dnevnik sprememb paketa vaše distribucije, saj povratni popravki številko različice pogosto pustijo enako.
Kaj nam pošljite
- kratek opis: kaj je bilo opaženo, od kdaj in kaj je bilo nazadnje spremenjeno
- vrsta sistema: lasten strežnik, vServer, upravljani strežnik ali paket gostovanja
- dostop prek SSH ali upravljalne plošče ali dovoljenje, da govorimo z vašim ponudnikom gostovanja
- podatki o obstoječih varnostnih kopijah in njihovi starosti
- opozorila ponudnika gostovanja, brskalnika ali strank v dobesednem besedilu
Če česa od tega ni, se vseeno javite. Vrzeli zapolnimo v pogovoru.
Zakaj PHP SOS
Delamo »Made in Germany« in smo s partnerskim omrežjem kibernetskih strokovnjakov že več kot 25 let specializirani za IT-varnost. Imate enega sogovornika, delamo na daljavo, brez prihoda na kraj, po vsej Nemčiji in Evropi. Vsak korak je dokumentiran in odkrito ločimo med dokazanim, verjetnim in neznanim. Obljub, ki jih nihče ne more izpolniti, ne dajemo. Pregled naknadne obravnave je v kontrolnem seznamu po vdoru, celotna nujna pomoč pa na strani Spletna stran vdrta? Nujna pomoč na daljavo. O obveznosti prijave ob kršitvah varstva podatkov preberite pravilo 72 ur; pravna ocena ostaja pri pooblaščencih za varstvo podatkov in odvetnikih.
Ste prizadeti? Pokličite nas. Pomagamo.
Ne čakajte, da iz suma nastane večja škoda. Prevzamemo že od prvega sporočila in ostanemo, dokler incident ni zaključen in dokumentiran. Prijavite nujni primer zdaj.
Pogosta vprašanja
Strežnik vdrt: ali ga naj takoj ugasnem?
Ne prenagljeno. Ugasnitev lahko uniči hlapne sledi v delovnem pomnilniku. Bolje je strežnik odklopiti z omrežja ali ga izolirati z požarnim zidom in ga najprej zavarovati. Če niste prepričani, se najprej javite nam.
Kako ugotovim, ali je bil moj strežnik res vdrt?
Znake dajejo procesi, ki jih zažene spletni strežnik, nove datoteke PHP v mapah za nalaganje ali predpomnilnik, neznana opravila cron in ključi SSH ter nenavadne odhodne povezave. Gotovost da šele analiza dnevnikov in datotek. Potrjenih indikatorjev PHP2Shell ni, prepoznavanje temelji na analizi vedenja.
Ali zadostuje posodobitev PHP, če je bil strežnik že vdrt?
Ne. Popravek zapre vstopna vrata, ne odstrani pa že vnesene škodljive programske opreme in ne dokazuje, da prej ni bilo nič narobe. Po posodobitvi je treba poleg tega znova zagnati vse procese PHP.
Ali moram vdrt strežnik prijaviti?
Če bi bili lahko prizadeti osebni podatki, je lahko potrebna prijava nadzornemu organu v 72 urah. Oceno poda vaš pooblaščenec za varstvo podatkov ali odvetnik, tehnična dejstva za to zagotovimo mi.
Ali lahko vdrt strežnik očistim sam?
Pri majhnih sistemih je to mogoče, a tvegano: kdor odstrani samo vidne datoteke, pogosto spregleda stranska vrata, opravila cron ali dostope. Mi preverimo, ali zadošča čiščenje ali je smiselnejša ponovna postavitev iz čistih virov.