Serveris nulaužtas – ką daryti? Pirmi žingsniai ir skubi pagalba

Trumpai: Ar tai jus palietė? Skambinkite. Padėsime. Jei įtariate, kad jūsų serveris nulaužtas, pirmiausia svarbu viena: išsaugoti pėdsakus. Nuo pirmos žinutės nuotoliu perimame padėties vaizdą, išsaugojimą, suvaldymą, išvalymą ir dokumentavimą, kol incidentas bus užbaigtas.

Ar tai jus palietė? Požymiai, kad serveris nulaužtas

Norint susisiekti, pakanka įtarimo. Atakos įrodinėti nereikia. Tipiniai požymiai:

• Žiniatinklio serveris ar PHP-FPM paleidžia procesus, tokius kaip sh ar bash. Tai stiprus perspėjimo ženklas, kurį aiškiname puslapyje Žiniatinklio serveris paleidžia shell.
• Įkėlimų, talpyklos ar laikinuosiuose aplankuose yra nauji ar nepažįstami PHP failai.
• Yra cron užduočių, kurių niekas nesukūrė, arba SSH raktų, kurių niekas negali priskirti.
• Apkrova be aiškios priežasties didelė arba serveris užmezga neįprastus išeinančius ryšius.
• Jūsų serverio laiškai patenka į šlamšto aplanką arba atmetami.
• Hostingo teikėjas, klientas ar naršyklės įspėjimas praneša apie kenkėjišką kodą.
• CMS atsiranda administratorių paskyrų, kurių niekas nesukūrė.

Daugiau požymių rasite skyriuje Ar jau esu kompromituotas?. Jei tinka keli punktai, laikykite serverį nulaužtu, kol įrodoma priešingai.

Serveris nulaužtas: ką daryti nedelsiant

1. Išlikite ramūs ir nieko nekeiskite. Netrinkite failų, nedarykite „greitų pataisymų“, neįrenkite iš naujo ant senos būsenos.
2. Užfiksuokite laiką. Užsirašykite, ką ir kada pastebėjote ir kas paskutinis keitė sistemą.
3. Išsaugokite žurnalus. Prieigos, klaidų ir sistemos žurnalai neturi būti rotuojami ar perrašomi. Esant PHP2Shell specializuota spauda pataria saugoti serverio žurnalus nuo 2026 m. spalio 20 d.
4. Sumažinkite atakos paviršių. Atjunkite serverį nuo viešojo tinklo arba užblokuokite ugniasiene, jei galėtų nutekėti duomenys. Neišjunkite jo tiesiog.
5. Surinkite prieigas. Kas turi SSH, valdymo skydelio, FTP, CMS ir duomenų bazės prieigą? Slaptažodžius keiskite tik pasitarę ir tik iš švaraus įrenginio.
6. Paskirkite kontaktinį asmenį. Turėtų būti pasiekiamas žmogus, galintis priimti sprendimus, taip pat dėl išjungimo ir paleidimo iš naujo.
7. Susisiekite dabar. Paskambinkite arba parašykite per WhatsApp. Visa kita aiškinamės su jumis žingsnis po žingsnio.

Atjungti nuo tinklo ar leisti veikti toliau?

Tai dažniausias klausimas pirmosiomis minutėmis ir bendro atsakymo jis neturi. Jei veikia internetinė parduotuvė su mokėjimais ar portalas su klientų duomenimis, dažniausiai svarbiau apsaugoti duomenis. Tuomet teisinga laikinai atskirti, pavyzdžiui, per priežiūros puslapį ar ugniasienės taisyklę, kuri praleidžia tik jūsų administratorius.

Staigus išjungimas, priešingai, retai yra geriausias pirmas žingsnis, nes operatyviojoje atmintyje yra pėdsakų, kuriuos ištrina paleidimas iš naujo. Geriau sistemos atvaizdas, pavyzdžiui, hostingo teikėjo momentinė kopija (snapshot), prieš ką nors keičiant. Esant PHP2Shell padėčiai BSI rekomenduoja laikinai atjungti žiniatinklio serverius nuo tinklo, jei atnaujinti iš karto neįmanoma. Tai nereiškia, kad kiekvienas išjungtas serveris buvo nulaužtas.

Ar jūsų atveju atskirti, apriboti ar leisti veikti toliau, sprendžiame kartu su jumis pagal tai, kas yra sistemoje.

Įrengti iš naujo ar išvalyti?

Daugelis serverį norėtų kuo greičiau sukurti iš naujo. Tai nėra klaida, bet tik po išsaugojimo. Kitaip lieka neaišku, kaip užpuolikas pateko, ir tas pats kelias lieka atviras ir naujai sistemai. Svarstymą aprašo puslapis Serverį įrengti iš naujo ar išvalyti?, o išsaugojimą prieš naują kūrimą puslapis Išsaugokite įrodymus prieš įrengdami iš naujo.

Svarbu: vien PHP atnaujinimas problemos neišsprendžia. Jis uždaro spragą, bet nepašalina jau įterptos kenkėjiškos programinės įrangos. Kaip rasti pėdsakus žurnaluose, aprašyta puslapyje Žiniatinklio serverio žurnalų analizė po atakos. Ir vadovaukitės prielaida, kad prieigos duomenys iš konfigūracijos failų buvo perskaityti: duomenų bazės, pašto ir API prieigos turi patekti į atnaujintinų paslapčių sąrašą.

Kaip PHP SOS padeda konkrečiai?

1. Įvertiname padėtį: su jumis išsiaiškiname, kas buvo pastebėta, kurios sistemos galėjo būti paveiktos ir kokie duomenys jose yra.
2. Išsaugome ir uždarome: išsaugome failus, duomenų bazę ir žurnalus, kol dar niekas nepakeista. Po to suvaldome ataką ir uždarome įsilaužimo kelią, esant PHP2Shell pataisa ir visų PHP procesų paleidimu iš naujo.
3. Tikriname ir valome: ieškome webshell, užpakalinių durų, cron užduočių ir svetimų prieigų ir jas pašaliname. Išsamiau rasite skyriuje Kenkėjiškos programinės įrangos ir webshell šalinimas.
4. Sutvirtiname ir pateikiame ataskaitą: gaunate dokumentaciją su laiko juosta, radinių vietomis ir rekomendacijomis. Jei incidentas išeina už vieno serverio ribų, pereiname prie struktūruoto incidentų valdymo (Incident Response).

Ko nedaryti

Streso metu daromos išvengiamos klaidos. Netrinkite „įtartinų“ failų tik įtarimo pagrindu, jų prieš tai neišsaugoję. Nevykdykite iš forumų paimtų komandų, kurių nesuprantate. Ir neįdiekite saugumo papildinių serveryje, kuris galbūt jau kompromituotas: kenkėjiškas kodas gali apgauti skaitytuvus, o rezultatas suteikia klaidingą saugumo jausmą. Būkite atsargūs ir su patarimais blokuoti visas užklausas su tam tikru sesijos ID; specializuoti autoriai tokius PHP2Shell patarimus aiškiai atmeta. Savo versiją saugiai patikrinti galite su php -v ir pažvelgę į savo distribucijos paketo pakeitimų žurnalą, nes backport dažnai palieka versijos numerį tą patį.

Ką mums atsiųsti

• trumpas aprašymas: kas pastebėta, nuo kada, kas buvo paskutinis pakeistas
• sistemos tipas: nuosavas serveris, vServer, valdomas serveris (managed server) ar hostingo paketas
• prieiga per SSH ar valdymo skydelį arba leidimas kalbėtis su jūsų hostingo teikėju
• žinios apie esamas atsargines kopijas ir jų amžių
• hostingo teikėjo, naršyklės ar klientų įspėjimai pažodžiui

Jei kažko iš to trūksta, vis tiek susisiekite. Spragas užpildysime pokalbio metu.

Kodėl PHP SOS

Dirbame Made in Germany ir kartu su savo kibernetinių specialistų partnerių tinklu daugiau nei 25 metus specializuojamės IT saugumo srityje. Turite vieną kontaktinį asmenį, dirbame nuotoliu, be atvykimo, visoje Vokietijoje ir Europoje. Kiekvienas žingsnis dokumentuojamas, ir atvirai atskiriame, kas įrodyta, kas tikėtina ir kas nežinoma. Pažadų, kurių niekas negali ištesėti, nedarome. Veiksmų po incidento apžvalgą rasite kontroliniame sąraše po įsilaužimo, visą skubią pagalbą skyriuje Svetainė nulaužta? Skubi pagalba nuotoliu. Apie pranešimo pareigą dėl duomenų pažeidimų skaitykite 72 valandų taisyklę; teisinį vertinimą palieka duomenų apsaugos pareigūnams ir teisininkams.

Ar tai jus palietė? Skambinkite. Padėsime.

Nelaukite, kol iš įtarimo išaugs didesnė žala. Perimame darbą nuo pirmos žinutės ir pasiliekame, kol incidentas bus užbaigtas ir dokumentuotas. Pranešti apie avariją dabar.

Dažni klausimai

Šaltiniai

• BSI (Vokietijos federalinė informacijos saugumo tarnyba)
• BDAR 33 straipsnis: pranešimas priežiūros institucijai
• OWASP Cheat Sheets