# Serverį perkurti ar valyti? Sprendimas po užkrėtimo

> Serverį po įsilaužimo perkurti ar valyti? Kriterijai, teisinga eilės tvarka ir tipinės atstatymo klaidos suprantamai paaiškinti.

Šaltinis: https://phpsos.de/lt/blog/neu-aufsetzen-oder-bereinigen/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** ar serverį po įsilaužimo perkurti, ar valyti, priklauso nuo to, kiek užtikrintai žinote įsilaužimo apimtį. Jei užpuolikas galėjo turėti root teises, įsilaužimo laikas neaiškus arba trūksta žurnalų, patikimesnis pasirinkimas yra perkūrimas iš patikimų šaltinių. Išvalymas galimas tik esant siaurai apibrėžtam, gerai įrodytam užkrėtimui. Abiem atvejais galioja: pirmiausia išsaugoti įrodymus ir uždaryti spragą, tik tada tvarkyti.

## Kodėl šis klausimas po PHP2Shell keliamas ypač dažnai

PHP2Shell, pasak php.net, leidžia nuotoliu vykdyti kenkėjišką kodą be prisijungimo. Kas eksploatavo nepataisytą serverį, todėl turi klausti, ar nuo 2026-10-17, pasak žiniasklaidos pranešimų, pirmojo stebėto atakos bandymo, kas nors įvyko. Pataisa į šį klausimą neatsako, o paskelbtų, patvirtintų kompromitavimo indikatorių (Indicators of Compromise) nėra.

Jei randamas įtartinas failas, nežinomas procesas ar svetima cron užduotis, reikia spręsti. Dažnas impulsas yra greitai ištrinti arba iškart įdiegti iš naujo. Abu gali būti teisingi, bet ne kaip pirmas žingsnis.

## Eilės tvarka prieš sprendimą

Prieš rinkdamiesi tarp valymo ir perkūrimo, atlikite tris dalykus. Jie galioja abiem keliams.

1. **Sulaikyti:** atjungti serverį nuo tinklo arba apriboti prieigą iki būtiniausios, jo neišjungiant, jei dar reikia išsaugoti operatyviąją atmintį.
2. **Išsaugoti įrodymus:** išsaugoti žurnalus, failus, duomenų bazę ir, jei įmanoma, sistemos atvaizdą, su data ir kontroline suma. Kodėl to reikia prieš bet kokį įdiegimą iš naujo, paaiškina [Išsaugokite įrodymus prieš perkurdami](https://phpsos.de/lt/blog/beweise-sichern-vor-neuinstallation/).
3. **Įtraukti draudiką ir duomenų apsaugą:** daugelis kibernetinio draudimo polisų tikisi, kad esminiai žingsniai bus suderinti. Nuorodos pateiktos skyriuje [Kibernetinis draudimas: kas svarbu žalos atveju](https://phpsos.de/lt/compliance/cyberversicherung/). Ar yra pranešimo pareiga pagal BDAR, vertina duomenų apsaugos pareigūnas arba advokatas.

Tik po to verta imtis tikro svarstymo.

## Serverio perkūrimas po įsilaužimo ar valymas: kriterijai

| Kriterijus | Valyti | Perkurti |
|---|---|---|
| Įsilaužimo apimtis | Siaura, įrodyta, pavyzdžiui, vienas failas įkėlimų aplanke be kitų pėdsakų | Neaiški arba su užuominomis į sistemos prieigą |
| Galimos užpuoliko root teisės | Atmestos su geromis įrodymais | Negalima atmesti |
| Žurnalų prieinamumas | Pilni atitinkamam laikotarpiui | Spragos, perrašyti ar galimi manipuliuoti |
| Darbo sąnaudos | Mažesnės, jei radinys aiškus | Didesnės, bet geriau planuojamos |
| Likęs netikrumas | Didesnis, paslėptų užpakalinių durų sunku atmesti | Mažesnis, jei švariai sukurta iš patikimų šaltinių |
| Prastovos laikas | Dažniausiai trumpesnis | Dažniausiai ilgesnis, su pasiruošimu gerai valdomas |
| Tinkamumas senoms sistemoms | Problemiška, jei sistema ir taip pasenusi | Gera proga pereiti prie palaikomos PHP versijos |

Nykščio taisyklė: kuo mažiau žinote, tuo labiau kalba už perkūrimą. Esant spragai PHP interpretatoriuje, kuri vykdo kodą žiniatinklio serverio naudotojo kontekste, užpuolikas gali išnaudoti kitus pažeidžiamumus, kad gautų daugiau teisių. Be išsamaus tyrimo to vargu ar galima atmesti.

## Abu keliai praktikoje

### Ką iš tikrųjų reiškia „perkurti“

Perkurti nereiškia nukopijuoti senos atsarginės kopijos į naują serverį. Perkūrimas prasideda nuo švarios operacinės sistemos iš oficialaus šaltinio, aktualių paketų ir pataisytos PHP versijos. Programa diegiama iš gamintojo originalo, taip pat papildiniai ir temos.

Tik tada pridedamas savas turinys, ir patikrintas. Įkelti failai neturi turėti vykdomų skriptų, duomenų bazėje gali būti įterpto turinio, pavyzdžiui, paslėptų administratoriaus paskyrų ar skriptų įrašuose. Konfigūracijos failai rašomi iš naujo, o ne kopijuojami. Visi prisijungimo duomenys atnaujinami: duomenų bazė, CMS administratoriai, SSH raktai, API raktai, hostingo skydelis.

Atsarginės kopijos čia vaidina svarbų vaidmenį, bet tik jei jų būsena ankstesnė už įsilaužimą ir jos pačios nebuvo pakeistos. Kelios kartos atskirose vietose leidžia tai patikrinti; daugiau skyriuje [Atsarginės kopijos pagal 3-2-1 taisyklę](https://phpsos.de/lt/ratgeber/backups-3-2-1/).

### Kai valyti pateisinama

Valymas gali būti prasmingas, kai užkrėtimas aptiktas anksti, yra pilni žurnalai ir tyrimas nerodo kitų prieigų. Tuomet rasti failai pašalinami po išsaugojimo, tikrinamos cron užduotys, naudotojų paskyros ir SSH raktai, o branduolio failai lyginami su gamintojo originalu.

Svarbus realistiškas vertinimas: žiniatinklio apvalkalai (webshell) dažnai nepastebimi ir paslėpti keliose vietose. Kaip juos rasti, aprašyta skyriuje [Žiniatinklio apvalkalų atpažinimas ir šalinimas](https://phpsos.de/lt/ratgeber/webshell-erkennen/). Po valymo serverį reikėtų atidžiai stebėti, kad praleistos užpakalinės durys išryškėtų.

> **Veikti nedelsiant:**
> Nieko netrinkite, kol neišsaugoti žurnalai ir failai, ir uždarykite spragą, prieš serveriui vėl grįžtant į tinklą. Kitaip prarasite pėdsakus ir pakviesite kitą įsilaužimą.

## Kada paslaugų teikėjo nereikia

Paprastos svetainės bendrame hostinge, kur hostingo teikėjas valdo sistemą ir patvirtina PHP pataisą, sprendimas dažnai apskritai ne jūsų. Programą galite įdiegti iš naujo iš originalo, patikrinti turinį ir atnaujinti prisijungimo duomenis, padedant hostingo teikėjui. Ir patyrusi vidinė komanda gali perkūrimą atlikti pati, jei įrodymų išsaugojimas ir dokumentacija tvarkingi.

Išorinė pagalba verta, kai negalima atmesti root teisių, gali būti paveikti asmens duomenys, įtrauktas draudimas arba susijusios kelios sistemos.

## Kaip PHP SOS padeda konkrečiai?

1. Išsaugome žurnalus, failus ir duomenų bazę taip, kad jie tiktų kaip įrodymai, prieš ką nors keičiant.
2. Įvertiname įsilaužimo apimtį ir su pagrindimu rekomenduojame valymą arba perkūrimą, atskirdami įrodyta, tikėtina ir nežinoma.
3. Prireikus serverį sukuriame iš naujo iš patikimų šaltinių, su pataisyta PHP versija ir atnaujintomis prieigomis.
4. [Kenkėjiškos programinės įrangos šalinimą](https://phpsos.de/lt/leistungen/malware-entfernung/) perimame ten, kur valymas pateisinamas, ir dokumentuojame kiekvieną žingsnį.

## Išvada

Į klausimą „perkurti ar valyti?“ atsako žinojimas apie įsilaužimą. Kas apimties tikrai nežino, kuria iš naujo. Kas gali ją įrodytai apriboti, gali valyti. Abiem atvejais galioja ta pati eilės tvarka: sulaikyti, išsaugoti, uždaryti spragą, tada tvarkyti.


## Dažni klausimai

**Ar perkurti po įsilaužimo visada geriau?**  
Ne visada, bet dažnai. Jei neaišku, kiek toli pažengė užpuolikas, perkūrimas iš patikimų šaltinių dažniausiai yra patikimesnis pasirinkimas. Esant siaurai apibrėžtam, gerai įrodytam užkrėtimui gali pakakti išvalymo.

**Ar galiu tiesiog įdiegti seną atsarginę kopiją?**  
Tik jei tikrai žinoma, kad kopija sukurta prieš įsilaužimą ir joje nėra užpakalinių durų. Be to, spraga prieš tai turi būti uždaryta, kitaip serveris iškart vėl atakuojamas. Naujesnės datos duomenis reikia tikrinti atskirai.

**Ką turiu išsaugoti prieš perkurdamas?**  
Žurnalus, failų ir duomenų bazės kopiją ir, jei įmanoma, sistemos atvaizdą. Šių įrodymų reikia priežasčių analizei, draudimui ir galimam pranešimui. Ištrynus jų nebelieka.

**Ar pakanka ištrinti rastą žiniatinklio apvalkalą (webshell)?**  
Retai. Užpuolikai dažnai palieka kelias užpakalines duris, pavyzdžiui, cron užduotis, naudotojų paskyras ar SSH raktus. Kas ištrina tik matomą failą, kitas prieigas palieka atviras.

## Šaltiniai

- [BSI: informacija apie saugumo incidentus](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: saugumo pranešimai](https://www.php.net/)