Lühidalt: Kas seate serveri pärast häkkimist uuesti üles või puhastate, sõltub sellest, kui kindlalt te sissemurdmise ulatust tunnete. Kui ründajal võisid olla root-õigused, sissemurdmise ajahetk on ebaselge või logid puuduvad, on uuesti ülesehitamine usaldusväärsetest allikatest töökindlam valik. Puhastamine tuleb kõne alla ainult kitsalt piiratud, hästi tõendatud nakatumise korral. Mõlemal juhul kehtib: kõigepealt tõendid kindlustada ja turvaauk sulgeda, alles siis koristada.
Miks seda küsimust pärast PHP2Shelli eriti sageli esitatakse
PHP2Shell võimaldab php.net-i andmetel kahjuliku koodi kaugkäivitamist ilma sisselogimiseta. Kes käitas paigata serverit, peab seetõttu küsima, kas ajal alates 17.10.2026, meediaaruannete kohaselt esimesest täheldatud rünnakukatsest, midagi juhtus. Paik sellele küsimusele ei vasta ja avaldatud, kinnitatud kompromiteerimisnäitajaid (Indicators of Compromise) ei ole.
Kui seejärel leitakse kahtlane fail, tundmatu protsess või võõras cron-töö, tuleb otsustada. Impulss on sageli kiiresti kustutada või kohe uuesti paigaldada. Mõlemad võivad olla õiged, kuid mitte esimese sammuna.
Järjekord enne otsust
Enne kui valite puhastamise ja uuesti üles seadmise vahel, tuleb teha kolm asja. Need kehtivad mõlemal teel.
- Tõkestada: Võtta server võrgust maha või piirata ligipääs hädavajalikule, ilma seda välja lülitamata, kui tahetakse veel töömälu kindlustada.
- Kindlustada tõendid: Kindlustada logid, failid, andmebaas ja võimalikult ka süsteemi kujutis, kuupäeva ja kontrollsummaga. Miks see enne igat uuesti paigaldamist vajalik on, selgitab artikkel Tõendite kindlustamine enne uuesti üles seadmist.
- Kaasata kindlustaja ja andmekaitse: Paljud küberpoliisid eeldavad oluliste sammude kooskõlastamist. Juhised leiate artiklist Küberkindlustus: mis kahjujuhtumi korral loeb. Kas IKÜM-i järgi on teavitamiskohustus, hindavad andmekaitsespetsialistid või advokaat.
Alles seejärel tasub tegelik kaalutlus ette võtta.
Server uuesti üles seada pärast häkkimist või puhastada: kriteeriumid
| Kriteerium | Puhastada | Uuesti üles seada |
|---|---|---|
| Sissemurdmise ulatus | Kitsalt piiratud, tõendatud, näiteks üks fail üleslaadimiskaustas ilma muude jälgedeta | Ebaselge või süsteemiligipääsule viitavate märkidega |
| Ründaja võimalikud root-õigused | Välistatud heade tõenditega | Ei saa välistada |
| Logide olemasolu | Täielikud asjaomase ajavahemiku kohta | Lünklikud, üle kirjutatud või manipuleeritavad |
| Vaev | Väiksem, kui leid on selge | Suurem, kuid paremini planeeritav |
| Allesjääv ebakindlus | Suurem, peidetud tagauksi on raske välistada | Väiksem, kui ehitatud puhtalt usaldusväärsetest allikatest |
| Seisakuaeg | Enamasti lühem | Enamasti pikem, ettevalmistusega hästi juhitav |
| Sobivus vanasüsteemidele | Problemaatiline, kui süsteem on niigi vananenud | Hea võimalus minna üle toetatud PHP versioonile |
Rusikareegel: mida vähem te teate, seda enam räägib uuesti ülesehitamise poolt. PHP interpretaatori turvaaugu puhul, mis käivitab koodi veebiserveri kasutaja kontekstis, võib ründaja kasutada muid nõrkusi, et saada rohkem õigusi. Seda on ilma põhjaliku uurimiseta raske välistada.
Mõlemad teed praktikas
Mida „uuesti üles seadmine“ tegelikult tähendab
Uuesti üles seadmine ei tähenda vana varukoopia kopeerimist värskele serverile. Uuesti ülesehitamine algab puhta operatsioonisüsteemiga ametlikust allikast, ajakohaste pakettide ja paigatud PHP versiooniga. Rakendus paigaldatakse tootja originaalist, pistikprogrammid ja teemad samamoodi.
Alles siis lisanduvad enda sisud, ja kontrollituna. Üleslaaditud failid ei tohi sisaldada käivitatavaid skripte, andmebaas võib sisaldada sisse toodud sisu, näiteks peidetud administraatorikontosid või skripte postitustes. Konfiguratsioonifailid kirjutatakse uuesti, mitte ei kopeerita. Kõik sisselogimisandmed uuendatakse: andmebaas, CMS-i administraatorid, SSH-võtmed, API-võtmed, majutuspaneel.
Varukoopiad mängivad siin olulist rolli, kuid ainult siis, kui nende seis on enne sissemurdmist ja neid endid ei ole muudetud. Mitu põlvkonda eraldi kohtades teeb selle kontrollitavaks; lähemalt artiklis Varukoopiad 3-2-1 reegli järgi.
Kui puhastamine on põhjendatav
Puhastamine võib olla mõistlik, kui nakatumine avastati vara, täielikud logid on olemas ja uurimine ei anna viidet muudele ligipääsudele. Siis eemaldatakse leitud failid pärast kindlustamist, kontrollitakse cron-töid, kasutajakontosid ja SSH-võtmeid ning võrreldakse tuumafaile tootja originaaliga.
Oluline on realistlik hinnang: veebishellid on sageli märkamatud ja peidetud mitmesse kohta. Kuidas neid leida, kirjeldab artikkel Veebishellide tuvastamine ja eemaldamine. Pärast puhastamist tuleks serverit tihedalt jälgida, et märgataks ülejäänud tagauks.
Ärge kustutage midagi enne, kui logid ja failid on kindlustatud, ja sulgege turvaauk enne, kui server uuesti võrku läheb. Muidu kaotate jäljed ja kutsute esile järgmise sissemurdmise.
Millal te teenusepakkujat ei vaja
Lihtsa veebisaidi puhul jagatud majutuses, kus majutaja haldab süsteemi ja kinnitab PHP paiga, ei olegi otsus sageli teie käes. Saate rakenduse originaalist uuesti paigaldada, sisu kontrollida ja sisselogimisandmed uuendada, majutaja toel. Ka kogenud sisemine meeskond saab uuesti ülesehitamise ise teha, kui tõendite kindlustamine ja dokumenteerimine on paigas.
Väline abi tasub, kui root-õigusi ei saa välistada, isikuandmed võivad olla mõjutatud, kindlustus on kaasatud või mitu süsteemi on seotud.
Kuidas PHP SOS konkreetselt aitab?
- Kindlustame logid, failid ja andmebaasi tõendatavalt enne, kui midagi muudetakse.
- Hindame sissemurdmise ulatust ja soovitame põhjendusega puhastamist või uuesti ülesehitamist, eristades tõendatut, tõenäolist ja teadmata.
- Ehitame serveri vajaduse korral uuesti üles usaldusväärsetest allikatest, paigatud PHP versiooni ja uuendatud ligipääsudega.
- Võtame pahavara eemaldamise enda peale seal, kus puhastamine on põhjendatav, ja dokumenteerime iga sammu.
Kokkuvõte
Küsimus „uuesti üles seada või puhastada?“ vastatakse teadmisega sissemurdmisest. Kes ulatust kindlalt ei tea, ehitab uuesti. Kes saab selle hästi tõendatult piirata, võib puhastada. Mõlemal juhul kehtib sama järjekord: tõkestada, kindlustada, turvaauk sulgeda, alles siis koristada.
Korduma kippuvad küsimused
Kas uuesti üles seadmine on pärast häkkimist alati parem?
Mitte alati, kuid sageli. Kui on ebaselge, kui kaugele ründaja jõudis, on uuesti ülesehitamine usaldusväärsetest allikatest tavaliselt töökindlam valik. Kitsalt piiratud ja hästi tõendatud nakatumise korral võib puhastamisest piisata.
Kas ma võin lihtsalt vana varukoopia taastada?
Ainult siis, kui on kindel, et varukoopia tehti enne sissemurdmist ja see ei sisalda tagaust. Lisaks peab turvaauk olema enne suletud, muidu on server kohe taas ründatav. Hilisemad andmed tuleb eraldi kontrollida.
Mida pean enne uuesti üles seadmist kindlustama?
Logid, failide ja andmebaasi koopia ning võimaluse korral süsteemi kujutis. Neid tõendeid vajate põhjuseanalüüsiks, kindlustuseks ja võimalikuks teavitamiseks. Pärast kustutamist on need kadunud.
Kas piisab leitud veebishelli kustutamisest?
Harva. Ründajad loovad sageli mitu tagaust, näiteks cron-töid, kasutajakontosid või SSH-võtmeid. Kes kustutab ainult nähtava faili, jätab teised ligipääsud lahti.