Lühidalt: Kui teie veebisait on häkitud, aitab see kontrollnimekiri mitte midagi unustada: esmalt piirata ja tõendid turvata, seejärel leida põhjus ja puhastada, siis uuendada kõik ligipääsud, kontrollida kohustusi ja intsident dokumenteeritult lõpetada. Järjekord on oluline, sest kes kustutab esimesena, kaotab jäljed, ja kes ainult puhastab turvaauku sulgemata, saab uuesti rünnatud.
Mille jaoks see kontrollnimekiri kehtib, kui veebisait on häkitud
Kontrollnimekiri on mõeldud juhatusele, omanikele ja IT-vastutajatele pärast kinnitatud või tõenäolist rünnakut veebisaidile, poele või PHP veebiserverile. See sobib ka pärast PHP2Shelli, kui server oli enne uuendust kättesaadav ja esineb kompromiteerimise vihjeid.
Mitte iga punkt ei sobi igale keskkonnale. Käige nimekiri siiski täielikult läbi ja märkige iga punkti juures, kas see on tehtud, ei kehti või on lahtine. See protokoll on hiljem väärtuslik kindlustuse, andmekaitse ja sisemise järelanalüüsi jaoks.
Sisestage iga sammu juurde kuupäev, kellaaeg, vastutav isik ja tulemus. Kui kaasatud on mitu inimest, määrake üks isik, kes nimekirja peab ja otsuseid fikseerib.
Faas 1: kohe piirata ja turvata
- Kahju piirata: Pange veebisait hooldusrežiimi või võtke võrgust maha, kui külastajad on ohus või andmed võivad lekkida. BSI soovitab PHP2Shelli puhul paigata serverid ajutiselt võrgust maha võtta, kui uuendus ei ole kohe võimalik.
- Mitte midagi kustutada: Ärge eemaldage faile, ärge seadke serverit uuesti üles ega tühjendage logisid, enne kui jäljed on turvatud.
- Logid turvata: Kopeerige juurdepääsu-, vea-, PHP-FPM-i ja süsteemilogid teise süsteemi ning fikseerige kontrollsummad. PHP2Shelli kohta soovitab erialaajakirjandus logisid säilitada alates 20.10.2026.
- Tõmmis turvata: Looge failide ja andmebaasi koopia, virtuaalserverite puhul hetktõmmis (snapshot), tõendusseisuna ja ärge seda muutke.
- Vastutajaid teavitada: Kaasake varakult juhatus, andmekaitsespetsialist, veebimajutaja ja, kui olemas, küberkindlustus. Paljudel kindlustustel on teavituskohustused.
Faas 2: põhjus leida ja puhastada
- Sissepääs tuvastada: Analüüsige logisid, failimuudatusi ja versioone. Kontrollige PHP-d ennast, sisuhaldussüsteemi, teemasid, laiendusi, ligipääsuandmeid ja serveriteenuseid. Ilma teadaoleva põhjuseta jääb korduva rünnaku risk alles.
- Turvaauk sulgeda: Viige PHP parandatud versioonile (8.5.12, 8.4.27, 8.3.36 või 8.2.35 või pakkuja kinnitatud backport), uuendage sisuhaldussüsteem ja laiendused, taaskäivitage kõik PHP töötajad.
- Ajavahemik piiritleda: Määrake kahtlase tegevuse varaseim ajahetk. See otsustab, millised varukoopiad võivad olla puhtad ja millised andmed mõjutatud.
- Tagauksed eemaldada: Kontrollige ja eemaldage veebishellid, võõrad PHP failid üleslaadimis- ja vahemälukaustades, muudetud tuumafailid, cron-ülesanded, SSH-võtmed ja süsteemiteenused. Asendage tuumafailid puhtast allikast.
- Andmebaas puhastada: Eemaldage tundmatud administraatorikontod, sissetoodud skriptid sisus ja seadetes ning rämpssisu.
- Uuesti ülesehitust kaaluda: Serveri sügava kompromiteerimise korral on uuesti ülesehitus värskes, paigatud süsteemis kontrollitud andmetega sageli usaldusväärsem tee kui puhastamine töötavas süsteemis.
Faas 3: ligipääsud uuendada ja karastada
- Paroolid muuta: Sisuhaldussüsteemile, hostingukontole, paneelile, andmebaasile, FTP-le, SFTP-le, SSH-le ja e-postile, ja seda puhtalt seadmelt.
- Võtmed ja tokenid vahetada: Looge uuesti API võtmed, maksete ja saatmisteenuste liidesed, sisuhaldussüsteemi rakenduse võtmed, SSH-võtmed ja sertifikaadid, mis serveris asusid.
- Sessioonid lõpetada: Logige välja kõik aktiivsed sisselogimised sisuhaldussüsteemis ja teenustes ning kontrollige registreeritud kaheastmelise autentimise seadmeid.
- Kaheastmeline autentimine aktiveerida: Kõigile halduse ligipääsudele, kaasa arvatud hosting, domeen ja DNS.
- Server karastada: Kontrollige ja dokumenteerige PHP seaded, failiõigused, käivituslukud üleslaadimiskaustades, tulemüür ja turvapäised.
Faas 4: kohustused, suhtlus ja lõpetamine
- Teavituskohustused kontrollida: Kui võivad olla mõjutatud isikuandmed, võib IKÜM art 33 järgi olla vajalik teavitus 72 tunni jooksul. Hinnang kuulub andmekaitsespetsialistile või advokaadile. Sektoripõhised kohustused, näiteks NIS2 alusel, kontrollida eraldi.
- Avaldust kaaluda: Politsei küberkuritegevuse keskse kontaktpunktid (ZAC) võtavad vastu ettevõtete avaldusi. Turvatud logid on selleks oluline alus.
- Kliente ja Google'it teavitada: Teavitage mõjutatuid asjalikult ja kooskõlastatult. Kui Google kuvab hoiatuse, taotlege pärast puhastamist ülevaatust, nagu on kirjeldatud lehel Google'i hoiatuse eemaldamine.
- Lõpetamine dokumenteerida ja jälgida: Fikseerige põhjus, ajavahemik, meetmed ja lahtised punktid aruandes, tehke järeldused hädaolukorra plaani jaoks ja jälgige süsteeme järgmistel nädalatel tihedamalt.
Sagedased vead järeltöös
Paljud intsidendid venivad pikaks, sest esimeses ärevuses säästetakse vales kohas või tegutsetakse liiga kiiresti. Neid vigu tuleks vältida:
- Eemaldada ainult nähtav: Kustutatud rämpsleht või eemaldatud ümbersuunamine ei ole tõend puhta veebisaidi kohta. Tagauksed jäävad sageli märkamatuks.
- Paroole muuta mõjutatud süsteemist: Kui arvutis või serveris töötab veel kahjutarkvara, võivad uued ligipääsuandmed kohe uuesti lekkida.
- Varukoopiat pimesi tagasi paigaldada: Ilma suletud turvaaugu ja varukoopia kontrollita on ründaja kiiresti jälle ukse ees.
- Paika mõista hoiatuse tühistamisena: Uuendus parandatud PHP versioonile ei tõesta, et varem midagi ei juhtunud, ega eemalda sissetoodud kahjutarkvara.
- Kohustusi liiga hilja kontrollida: Tähtajad algavad intsidendist teadasaamisest, mitte puhastamise lõpust.
- Dokumentatsiooni ei ole: Ilma protokollita on kindlustuse, ametiasutuste või klientide küsimustele hiljem raske vastata.
See kontrollnimekiri ei asenda õigusnõustamist. Teavituskohustuste, vastutuse või kindlustuse küsimustes pöörduge oma andmekaitsespetsialisti, advokaadi või kindlustaja poole.
Kuidas PHP SOS konkreetselt aitab?
- Võtame üle struktureeritud intsidendile reageerimise ja käime kontrollnimekirja koos teiega läbi, punkt punkti haaval protokolliga.
- Turvame logid ja süsteemi seisud nii, et need jäävad kasutatavaks kindlustuse, ametiasutuste ja võimaliku IT-forensika jaoks.
- Sulgeme turvaaugu, puhastame või ehitame uuesti ning uuendame ligipääsud õiges järjekorras.
- Esitame lõpparuande põhjuse, meetmete ja soovitustega ning jälgime süsteeme soovi korral edasi.
Korduma kippuvad küsimused
Mis on esimene asi, mida peaksin tegema, kui mu veebisait on häkitud?
Säilitage rahu, ärge kustutage midagi ja piirake kahju. Võtke veebisait vajaduse korral võrgust maha või pange hooldusrežiimi ning turvake logid ja failid, enne kui puhastate. Seejärel järgneb põhjuse otsimine ja puhastamine.
Kas piisab veebisaidi taastamisest varukoopiast?
Enamasti mitte. Varukoopia võib juba sisaldada kahjulikku koodi ja turvaauk, mille kaudu ründaja sisse tuli, on pärast tagasipaigaldamist endiselt avatud. Esmalt põhjus sulgeda, seejärel kontrollitud puhas seis uuendatud süsteemi paigaldada.
Kas pean häkkimisest andmekaitseasutusele teatama?
Kui võivad olla mõjutatud isikuandmed, näeb IKÜM art 33 põhimõtteliselt ette teavitamise 72 tunni jooksul pärast teadasaamist, kui isikute jaoks risk ei ole ebatõenäoline. Hinnang kuulub teie andmekaitsespetsialistile või advokaadile.
Millal on intsident tõesti lõpetatud?
Kui põhjus on suletud, kõik teadaolevad tagauksed eemaldatud, ligipääsud uuendatud, kohustused täidetud ja meetmed dokumenteeritud. Sellele kuulub järel tihedama jälgimise periood, et märkamata jäänud jälgi tuvastada.