Īsi: ja jūsu vietne ir uzlauzta, šis kontrolsaraksts palīdz neko neaizmirst: vispirms ierobežot un saglabāt pierādījumus, tad atrast cēloni un iztīrīt, pēc tam atjaunot visas piekļuves, pārbaudīt pienākumus un incidentu dokumentēti noslēgt. Secība ir svarīga, jo kas dzēš pirmais, zaudē pēdas, un kas tikai tīra, neaizverot robu, tiek uzbrukts atkārtoti.
Kam šis kontrolsaraksts domāts, ja vietne ir uzlauzta
Kontrolsaraksts paredzēts vadībai, īpašniekiem un IT atbildīgajiem pēc apstiprināta vai ticama uzbrukuma vietnei, veikalam vai PHP tīmekļa serverim. Tas der arī pēc PHP2Shell, ja serveris pirms atjauninājuma bija sasniedzams un ir norādes uz kompromitāciju.
Ne katrs punkts der katrai videi. Tomēr izejiet sarakstam cauri pilnībā un pie katra punkta atzīmējiet, vai tas ir izpildīts, nav attiecināms vai atvērts. Šis protokols vēlāk ir vērtīgs apdrošināšanai, datu aizsardzībai un iekšējai pēcapstrādei.
Pie katra soļa ierakstiet datumu, laiku, atbildīgo personu un rezultātu. Ja iesaistītas vairākas personas, nosakiet vienu, kas vada sarakstu un fiksē lēmumus.
1. fāze: nekavējoties ierobežot un saglabāt
- Ierobežot kaitējumu: vietni pārslēgt uzturēšanas režīmā vai atvienot no tīkla, ja apmeklētāji ir apdraudēti vai dati varētu aizplūst. BSI PHP2Shell gadījumā iesaka neielāpotus tīmekļa serverus uz laiku atvienot no tīkla, ja atjauninājums nav iespējams nekavējoties.
- Neko nedzēst: nenoņemt failus, serveri neuzstādīt no jauna un nenotīrīt žurnālus, pirms pēdas nav saglabātas.
- Saglabāt žurnālus: Access, Error, PHP-FPM un sistēmas žurnālus nokopēt citā sistēmā un fiksēt kontrolsummas. Par PHP2Shell speciālā prese iesaka glabāt žurnālus no 20.10.2026.
- Saglabāt attēlu: izveidot failu un datubāzes kopiju, virtuāliem serveriem momentuzņēmumu, kā pierādījuma stāvokli un to nemainīt.
- Informēt atbildīgos: agri iesaistīt vadību, datu aizsardzības speciālistu, hostinga sniedzēju un, ja ir, kiberapdrošināšanu. Daudzām apdrošināšanām ir ziņošanas pienākumi.
2. fāze: atrast cēloni un iztīrīt
- Noteikt ieejas vietu: izvērtēt žurnālus, failu izmaiņas un versijas. Pārbaudiet pašu PHP, CMS, motīvus, paplašinājumus, piekļuves datus un servera pakalpojumus. Bez zināma cēloņa atkārtota uzbrukuma risks paliek.
- Aizvērt robu: PHP novest līdz izlabotai versijai (8.5.12, 8.4.27, 8.3.36 vai 8.2.35, attiecīgi sniedzēja apstiprināts backports), atjaunināt CMS un paplašinājumus, pārstartēt visus PHP darbprocesus.
- Ierobežot laika periodu: noteikt agrāko aizdomīgās darbības brīdi. Tas nosaka, kuri dublējumi var būt tīri un kuri dati varētu būt skarti.
- Noņemt slēptās piekļuves: pārbaudīt un noņemt webshell, svešus PHP failus augšupielāžu un kešatmiņas mapēs, mainītus kodola failus, cron uzdevumus, SSH atslēgas un sistēmas pakalpojumus. Kodola failus aizstāt no tīra avota.
- Iztīrīt datubāzi: noņemt nezināmus administratoru kontus, ievadītus skriptus saturā un iestatījumos, kā arī surogāta saturu.
- Apsvērt atkārtotu uzbūvi: dziļas servera kompromitācijas gadījumā atkārtota uzbūve uz jaunas, ielāpotas sistēmas ar pārbaudītiem datiem bieži ir uzticamāks ceļš nekā tīrīšana darbojošā sistēmā.
3. fāze: atjaunot piekļuves un nostiprināt
- Mainīt paroles: CMS, hostinga kontam, panelim, datubāzei, FTP, SFTP, SSH un e-pastam, un tieši no tīras ierīces.
- Nomainīt atslēgas un žetonus: API atslēgas, maksājumu un piegādes pakalpojumu saskarnes, CMS lietojumprogrammas atslēgas, SSH atslēgas un sertifikātus, kas atradās serverī, ģenerēt no jauna.
- Beigt sesijas: visas aktīvās pieteikšanās CMS un pakalpojumos atteikt un pārbaudīt reģistrētās divu faktoru ierīces.
- Aktivizēt divu faktoru autentifikāciju: visām administratoru piekļuvēm, ieskaitot hostingu, domēnu un DNS.
- Nostiprināt serveri: pārbaudīt un dokumentēt PHP iestatījumus, failu tiesības, izpildes bloķēšanu augšupielāžu mapēs, ugunsmūri un drošības galvenes.
4. fāze: pienākumi, komunikācija un noslēgums
- Pārbaudīt ziņošanas pienākumus: ja var būt skarti personas dati, saskaņā ar VDAR 33. pantu var būt nepieciešams ziņojums 72 stundu laikā. Vērtējums jāveic datu aizsardzības speciālistam vai advokātam. Nozares pienākumus, piemēram, saskaņā ar NIS2, pārbaudīt atsevišķi.
- Apsvērt iesniegumu: policijas centrālie kontaktpunkti kibernoziegumu jomā (Zentrale Ansprechstellen Cybercrime) pieņem uzņēmumu iesniegumus. Saglabātie žurnāli tam ir svarīgs pamats.
- Informēt klientus un Google: skartos informēt lietišķi un saskaņoti. Ja Google rāda brīdinājumu, pēc iztīrīšanas pieprasīt pārskatīšanu, kā aprakstīts rakstā Google brīdinājuma noņemšana.
- Dokumentēt noslēgumu un uzraudzīt: cēloni, periodu, pasākumus un atvērtos punktus fiksēt ziņojumā, secināt mācības ārkārtas rīcības plānam un turpmākajās nedēļās sistēmas pastiprināti uzraudzīt.
Biežākās kļūdas pēcapstrādē
Daudzi incidenti ievelkas, jo pirmajā satraukumā tiek ietaupīts nepareizā vietā vai rīkojies par ātru. No šīm kļūdām jāizvairās:
- Noņemt tikai redzamo: izdzēsta surogātlapa vai noņemta pāradresācija nav pierādījums tīrai vietnei. Slēptās piekļuves bieži paliek nepamanītas.
- Paroles mainīt no skartās sistēmas: ja datorā vai serverī vēl darbojas ļaunprogrammatūra, jaunie piekļuves dati var uzreiz atkal aizplūst.
- Akli atjaunot dublējumu: bez aizvērta roba un bez dublējuma pārbaudes uzbrucējs drīz atkal stāv durvīs.
- Ielāpu uzskatīt par atvieglojumu: atjauninājums uz izlabotu PHP versiju nepierāda, ka iepriekš nekas nav noticis, un neizņem ievadītu ļaunprogrammatūru.
- Pienākumus pārbaudīt par vēlu: termiņi sākas ar incidenta uzzināšanu, nevis ar iztīrīšanas beigām.
- Nav dokumentācijas: bez protokola apdrošinātāju, iestāžu vai klientu jautājumus vēlāk gandrīz nevar atbildēt.
Šis kontrolsaraksts neaizstāj juridisko konsultāciju. Jautājumos par ziņošanas pienākumiem, atbildību vai apdrošināšanu vērsieties pie sava datu aizsardzības speciālista, advokāta vai apdrošinātāja.
Kā PHP SOS palīdz konkrēti?
- Uzņemamies strukturētu Incident Response un kopā ar jums izpildām kontrolsarakstu punkts pa punktam ar protokolu.
- Žurnālus un sistēmas stāvokļus saglabājam tā, lai tie apdrošināšanai, iestādēm un iespējamai IT forensikai paliktu izmantojami.
- Aizveram robu, attīrām vai uzbūvējam no jauna un atjaunojam piekļuves pareizā secībā.
- Sniedzam noslēguma ziņojumu ar cēloni, pasākumiem un ieteikumiem un pēc vēlēšanās sistēmas pēc tam turpinām uzraudzīt.
Biežāk uzdotie jautājumi
Kas man jādara vispirms, ja mana vietne ir uzlauzta?
Saglabāt mieru, neko nedzēst un ierobežot kaitējumu. Vajadzības gadījumā atvienojiet vietni no tīkla vai pārslēdziet uzturēšanas režīmā un pirms tīrīšanas saglabājiet žurnālus un failus. Pēc tam seko cēloņa meklēšana un attīrīšana.
Vai pietiek ar vietnes atjaunošanu no dublējuma?
Parasti nē. Dublējums jau var saturēt ļaunprātīgu kodu, un ievainojamība, pa kuru uzbrucējs iekļuva, pēc atjaunošanas joprojām ir atvērta. Vispirms aizveriet cēloni, tad pārbaudītu, tīru stāvokli ievietojiet atjauninātā sistēmā.
Vai man uzlaušana jāpaziņo datu aizsardzības iestādei?
Ja var būt skarti personas dati, VDAR 33. pants principā paredz ziņojumu 72 stundu laikā pēc uzzināšanas, ja risks skartajām personām nav maz ticams. Vērtējums jāveic jūsu datu aizsardzības speciālistam vai advokātam.
Kad incidents patiešām ir noslēgts?
Kad cēlonis ir aizvērts, visas zināmās slēptās piekļuves noņemtas, piekļuves atjaunotas, pienākumi izpildīti un pasākumi dokumentēti. Pie tā pieder arī pastiprinātas uzraudzības periods pēc tam, lai atpazītu palaistas garām pēdas.