# Intsidendile reageerimine (Incident Response) serverirünnakute korral > Intsidendile reageerimine serverirünnakute korral: võtame üle triaaži, piiramise, puhastamise ja taastamise selgete rollide ja dokumenteeritud käiguga. Allikas: https://phpsos.de/et/leistungen/incident-response/ Seis: 25.10.2026 Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6 **Lühidalt:** Kui rünnak puudutab rohkem kui üht veebisaiti, vajate intsidendile reageerimise teenusepakkujat, kes intsidendi struktureeritult läbi töötab. Võtame enda peale olukorrapildi, piiramise, puhastamise ja turvalise taastamise, selgete rollide ja lünkadeta dokumentatsiooniga. Otsused jäävad teile, tehnilise aluse tagame meie. ## Mida tähendab intsidendile reageerimine serverirünnakute korral Intsidendile reageerimine (Incident Response) on turvaintsidendi korrapärane käsitlemine. Kiirustavate üksiktoimingute asemel järgib töö kindlaid etappe: tuvastamine ja hindamine, piiramine, kõrvaldamine, taastamine, järeltöö. Iga meede fikseeritakse ajahetke ja põhjendusega. Veebiserverite puhul on see eriti oluline. PHP rakendustega server sisaldab sageli ligipääsuandmeid andmebaasidele, makseteenuse pakkujatele, e-posti serveritele ja liidestele. Kes sinna on sisse pääsenud, võib edasi liikuda. Olukord pärast PHP2Shelli näitab, kui kiiresti selline olukord tekkida võib: autentimata koodi käivitamine, üle 22,6 miljoni avalikult ligipääsetava instantsi Unit 42 andmetel ja avaldatud, kinnitatud kompromiteerimisnäitajaid (Indicators of Compromise) pole. ## Millal vajate intsidendile reageerimise teenusepakkujat - mitu serverit või rakendust on mõjutatud või võivad olla mõjutatud - on kahtlus, et isikuandmed või makseandmed on välja voolanud - ründaja võib olla veel aktiivne, näiteks töötavate ühenduste või uute kontode kaudu - on väljapressimine või rünnaku avalik teadaanne - kindlustaja, ametiasutused või äripartnerid ootavad dokumenteeritud käiku Üksiku nakatunud veebisaidi korral piisab sageli [hädaabist häkitud veebisaidi korral](https://phpsos.de/et/leistungen/website-gehackt-notfallhilfe/). Ülemineku täieliku intsidendi käsitlemiseni arutame teiega läbi, niipea kui hakkab ilmnema suurem ulatus. ## Kuidas PHP SOS konkreetselt aitab? 1. **Triaaž ja olukorrapilt:** Selgitame, mida on täheldatud, millised süsteemid ja andmed võivad olla mõjutatud ja keda tuleb sisemiselt kaasata. Tulemuseks on esimene kirjalik olukorrapilt avatud küsimustega. 2. **Jälgede kindlustamine ja piiramine:** Logid, failisüsteemid ja andmebaasid kindlustatakse enne sekkumist. Seejärel isoleerime mõjutatud süsteemid, blokeerime kompromiteeritud ligipääsud ja katkestame ründaja äratuntavad ühendused. 3. **Kõrvaldamine:** Sulgeme sissepääsu, näiteks paikamisega parandatud PHP versioonidele ja kõigi tööprotsesside taaskäivitusega, eemaldame tagauksed ja vahetame saladused välja. Üksikasjaliku analüüsi jaoks kaasame vajaduse korral [IT-forensika](https://phpsos.de/et/leistungen/it-forensik/) spetsialiseerunud partnereid. 4. **Taastamine:** Süsteemid võetakse kontrollitult uuesti kasutusele, võimalusel puhastest allikatest või uuesti üles seatud serverites. Seejärel jälgime neid tõhustatult uute kõrvalekallete suhtes. 5. **Järeltöö:** Saate lõpparuande ajajoone, põhjuste, meetmete ja soovitustega. Koos kirjutame üles, mis peaks järgmisel korral kiiremini minema. > **Tegutsege kohe:** > Hoidke serveri logid alles ja ärge muutke süsteeme enne, kui on kindlustatud. BSI soovitab PHP2Shelli puhul veebiserverid, mida kohe paigata ei saa, ajutiselt võrgust maha võtta. ## Rollid ja kommunikatsioon intsidendi ajal Intsident vajab selgeid vastutusalasid. End on tõestanud väike ring: otsustusõigusega isik, tehniline kontaktisik teie poolel ja meie tehnilise juhtimisena. Olukorra arutelud toimuvad kindlate vahemike järel, tulemused fikseeritakse kirjalikult. Paralleelselt kulgevad ülesanded, mida me enda peale ei võta, kuid milleks anname faktid: [IKÜM-i 72-tunnise teavitamiskohustuse](https://phpsos.de/et/compliance/dsgvo-meldepflicht-72-stunden/) kontroll, kindlustaja teavitamine, võimalik avaldus ja [kriisikommunikatsioon](https://phpsos.de/et/compliance/krisenkommunikation/) klientide ja partnerite suunas. ## Mida me teilt vajame ja mida te saate Vajame haldusligipääse mõjutatud süsteemidele, ülevaadet infrastruktuurist ja teenusepakkujatest, otsustusõigusega isikut ning valmidust süsteemid vajaduse korral ajutiselt välja lülitada. Abiks on olemasolevad hädaolukorra plaanid, võrguskeemid ja varukoopiad kuupäevaga. Saate jooksva intsidendiprotokolli, regulaarsed olukorrapildid arusaadavas keeles, lõpparuande juhtkonnale, andmekaitsespetsialistile ja kindlustajale ning prioriseeritud parenduste loendi. Kuidas end järgmiseks intsidendiks paremini ette valmistada, kirjeldab [IT-hädaolukorra plaani koostamine veebiserveritele](https://phpsos.de/et/compliance/notfallplan-erstellen/). ## Tüüpilised vead esimestel tundidel Paljud intsidendid muutuvad raskemaks, sest ärevuses tehakse heatahtlikke samme vales järjekorras. Neid mustreid näeme sageli: - **Kohe uuesti üles seadmine:** Server kustutatakse ja paigaldatakse uuesti, enne kui on kindlustatud. Pärast seda ei saa enam selgitada, kas andmed on välja voolanud. - **Paroolide muutmine nakatunud süsteemist:** Kui ründajal on veel ligipääs, näeb ta uusi paroole kaasa. - **Ainult nähtava faili kustutamine:** Veebishell on kadunud, teine tagauks cron-töös jääb. - **Paikamine ilma taaskäivituseta:** Uued PHP failid asuvad kettal, vanad tööprotsessid töötavad mälus edasi. - **Keegi ei pea protokolli:** Hiljem ei tea keegi, kes millal mida muutis. See raskendab vestlusi kindlustaja ja ametiasutustega. Kooskõlastatud käik hoiab need vead ära, piiramist viivitamata. ## Mida me ei luba Me ei luba, et iga intsident selgitatakse täielikult välja; ilma jälgedeta jäävad küsimused lahtiseks ja seda kirjutame ka aruandesse. Me ei anna õigusnõu ega väiteid vastutuse või kindlustuskaitse kohta. Meie eesmärk on selge lõpp: töötame intsidendi kallal, kuni see on lõpetatud ja dokumenteeritud. ## Korduma kippuvad küsimused **Mis vahe on intsidendile reageerimisel ja IT-forensikal?** Intsidendile reageerimise eesmärk on intsident piirata ja töö turvaliselt taastada. IT-forensika selgitab üksikasjalikult ja tõendatavalt, mis juhtus. Praktikas põimuvad need, forensika kindlustab jälgi sageli paralleelselt. **Millal peaksin kaasama intsidendile reageerimise teenusepakkuja?** Niipea kui on kahtlus, et ründajal oli ligipääs süsteemidele ja te ei oska ulatust kindlalt hinnata. Mida varem jälgede kindlustamine algab, seda rohkem saab hiljem tõendada. **Kes teeb intsidendi ajal otsuseid?** Otsused teete teie, näiteks väljalülitamise, kommunikatsiooni või teavituste üle. Meie valmistame ette tehnilised alused, näitame valikuid koos nende tagajärgedega ja viime otsused ellu. **Kas pean kaasama politsei?** Avalduse esitamine on paljudel juhtudel mõistlik ja mõne kindlustuse jaoks oluline. Selleks on pädevad politsei küberkuritegevuse kesksed kontaktpunktid. Kas ja millal te avalduse esitate, otsustate koos oma advokaadiga. ## Allikad - [BSI: Saksamaa föderaalne infoturbeamet](https://www.bsi.bund.de/) - [IKÜM art 33: teavitamine järelevalveasutusele](https://dsgvo-gesetz.de/art-33-dsgvo/) - [Politsei: küberkuritegevuse kesksed kontaktpunktid (Saksamaa)](https://www.polizei.de/) - [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)