Įsilaužta: kaip atpažinti, atkurti ir apsisaugoti ateityje

7 modulis: Saugumas · Skaitymo trukmė: 10 min.

Mokymosi tikslas: po šios pamokos galėsite atpažinti įsilaužimą, teisinga tvarka atkurti svetainę ir apsisaugoti, kad tai nepasikartotų.

Pagrindinės sąvokos: įsilaužimo požymiai, įrodymų fiksavimas, izoliavimas, visų slaptažodžių ir salts pakeitimas, įsilaužimo kelio nustatymas, žurnalai, švari atsarginė kopija, švarus pakartotinis diegimas, kontrolinės sumos (checksums), nežinomi administratoriai, PHP faile uploads, mu-plugins, Search Console, pranešimas apie duomenų saugumo pažeidimą

Kas yra įsilaužimas

Svetainė yra nulaužta (gautas neteisėtas priėjimas), kai kas nors be leidimo perėmė kontrolę (visos svetainės ar jos dalies): jis gali keisti failus ar duomenų bazę arba vykdyti kodą. Dažnai jis išlieka prieinamas per užpakalines duris (backdoor): paslėptą failą ar kodo gabalėlį, per kurį vėliau gali grįžti, net jei uždarote pirminę spragą.

Tai ir yra šios pamokos esmė: vien matomos žalos pašalinimo nepakanka. Kol užpakalinės durys egzistuoja arba spraga, per kurią jis pateko, lieka atvira, viskas kartosis. Dažnai per kelias dienas.

Kaip atpažinti

Požymiai (vienus matysite patys, kitų reikės ieškoti):

• Google Jūsų svetainei rodo pranešimą „Ši svetainė galimai nulaužta“, arba Search Console praneša apie saugumo problemą.
• Paieškos rezultatuose (site:example.com) matote puslapius, kurių nežinote, dažnai kita kalba arba apie vaistus, azartinius lošimus ar netikras parduotuves.
• Lankytojai peradresuojami, dažnai tik tie, kurie atėjo per Google arba naudoja telefoną. Jūs to nematote, nes esate prisijungę arba atėjote per žymę (bookmark). Patikrinkite privačiame lange per paieškos rezultatą.
• Skiltyje Vartotojai yra administratorius, kurio nepažįstate.
• Aplanke wp-content/uploads yra PHP failų, arba šakniniame aplanke ar wp-content/mu-plugins yra keistai pavadintų failų.
• Jūsų talpinimo paslaugų teikėjas arba kenkėjiškų programų skeneris praneša apie užkrėstus failus; Jūsų laiškai atmetami arba paketas siunčia šlamštą.
• Svetainė staiga tapo lėta arba saugykla prisipildė.

Veiksmų planas

1. Likite ramūs ir viską užfiksuokite

Nemeskite visko iš karto. Užrašykite, ką matote ir nuo kada, padarykite ekrano nuotraukas ir sukurkite dabartinės būklės kopiją (failų ir duomenų bazės, arba papildomą atsarginę kopiją per talpinimo paslaugų teikėją). Ta kopija prireiks ieškant įsilaužimo kelio ir kaip įrodymas. Nelaikykite jos žiniatinklio aplanke.

2. Sustabdykite žalą lankytojams

Laikinai išjunkite svetainę arba uždenkite priežiūros puslapiu, ypač jei lankytojai peradresuojami į kenkėjišką programinę įrangą ar sukčiavimo (phishing) svetaines. „DirectAdmin“ galite sustabdyti domeną; kitur gali padėti slaptažodis visai svetainei arba laikinas index.html su pranešimu.

3. Pakeiskite visus slaptažodžius ir raktus

Laikykite, kad įsilaužėlis žino kiekvieną slaptažodį, kurį buvo galima rasti svetainėje ar per ją. Pakeiskite, pageidautina iš kito (švaraus) kompiuterio:

• talpinimo valdymo skydelio slaptažodį ir visų FTR bei SFTP paskyrų slaptažodžius (pašalinkite nenaudojamas paskyras);
• duomenų bazės vartotojo slaptažodį ir pakoreguokite jį faile wp-config.php;
• visų WordPress administratorių slaptažodžius ir pašalinkite nežinomas paskyras;
• raktus ir salts faile wp-config.php (3 pamoka). Tai panaikina visus prisijungimo slapukus, taip pat ir įsilaužėlio;
• programų slaptažodžius (3.3 pamoka) ir susiejimų API raktus;
• el. pašto slaptažodžius, jei šlamštas buvo siunčiamas per pašto dėžutę.

Po to visur įjunkite dviejų veiksnių autentifikavimą (7.3 pamoka).

4. Suraskite įsilaužimo kelią

Nežinodami, kaip buvo įsilaužta, negalite būti tikri, kad spraga uždaryta. Dažniausios priežastys (7.1 pamoka) ir kur ieškoti:

• Pasenęs įskiepis ar tema: kurios dalys buvo neatnaujintos? Patikrinkite pavadinimus pažeidžiamumų duomenų bazėje (5.3 pamoka).
• Nutekėjęs slaptažodis: peržiūrėkite talpinimo valdymo skydelio ir FTP prisijungimų istoriją.
• Žiniatinklio serverio žurnalai: ieškokite apie tą laiką, kai pasirodė pirmieji keisti failai, POST užklausų į nežinomus failus ar įskiepių failus, dažnai iš to paties IP adreso.
• Failai pagal datą: Failų tvarkyklėje arba per SFTP rikiuokite pagal pakeitimo datą. Failai, kurie buvo pakeisti tuo pačiu metu, ypač ne atnaujinimo metu, nusipelno dėmesio.

5. Išvalymas

Du keliai, dažnai juos derinant:

A. Atkurti švarią atsarginę kopiją iš prieš įsilaužimą buvusio laikotarpio (8.2 pamoka). Pasirinkite atsarginę kopiją, tikrai padarytą prieš pirmuosius požymius, nes įsilaužėliai kartais laukia savaites. Atkurkite visiškai, kad dingtų ir pridėti failai. Po to iškart visk atnaujinkite (kitaip spraga vėl atsiras). Trūkumas: viskas, kas atsirado po atsarginės kopijos (įrašai, užsakymai), dingsta.

B. Švariai atstatyti iš naujo, naudojant esamą turinį:

1. Pakeiskite patį WordPress švaria kopija iš wordpress.org (wp-admin, wp-includes ir pavienius failus; ne wp-content ir wp-config.php). Su WP-CLI pirmiausia galite patikrinti, kas buvo pakeista:

wp core verify-checksums
wp plugin verify-checksums --all

Šios komandos palygina Jūsų failus su oficialiomis versijomis ir praneša apie kiekvieną pakeistą ar papildomą failą (antroji tik įskiepiams iš wordpress.org įskiepių aplanko).

2. Pašalinkite visus įskiepius ir temas ir įdiekite juos iš naujo iš šaltinio, naujausią versiją. Ko nereikia, to neatkurkite.
3. Patikrinkite wp-content/uploads, ar nėra PHP failų ir kitų failų, kurie nėra medija, bei wp-content/mu-plugins.
4. Patikrinkite .htaccess, ar nėra keistų peradresavimo taisyklių, ir wp-config.php, ar nėra eilučių, kurių nepažįstate.
5. Patikrinkite duomenų bazę: nežinomus administratorius, parinktis siteurl, home ir active_plugins lentelėje wp_options, ir ieškokite įrašuose įterptų skriptų (<script su keistais adresais).
6. Peržiūrėkite suplanuotas užduotis: periodines užduotis (cronjob) talpinimo valdymo skydelyje ir WP-Cron (su įskiepiu arba wp cron event list).

Kenkėjiškų programų skeneris (iš talpinimo paslaugų teikėjo ar įskiepio) padeda ieškant, bet aklai juo nepasitikėkite: ko jis neranda, dar gali būti.

6. Uždarymas ir patikrinimas

• Atnaujinkite viską, sustiprinkite apsaugą (7.4 pamoka) ir vėl įjunkite svetainę.
• Ar Jūsų svetainė Google pažymėta kaip nesaugi? Skiltyje Search Console ties Saugumo problemomis paprašykite naujo įvertinimo, bet tik tada, kai viskas bus švaru.
• Sekite kitas savaites: naujus failus, naujus administratorius, skenerio pranešimus. Jei pasikartoja, vadinasi, įsilaužimo kelias ar užpakalinės durys dar nerastos.

Asmens duomenys: pranešimas apie duomenų saugumo pažeidimą

Jei įsilaužėliai galėjo pasiekti asmens duomenis (el. parduotuvės klientų duomenis, formų pateiktis, narių sąrašus, svetainės vartotojus), tai yra duomenų saugumo pažeidimas BDAR prasme. Tokiu atveju privalote per 72 valandas nuo sužinojimo apie tai pranešti priežiūros institucijai (Valstybinei duomenų apsaugos inspekcijai (VDAI)), nebent nėra tikėtina, kad tai kels riziką susijusiems asmenims (BDAR 33 straipsnis). Jei rizika didelė, taip pat privalote informuoti pačius tuos asmenis (34 straipsnis). Bet kuriuo atveju užfiksuokite, kas įvyko ir ką padarėte, net jei nepranešate. Jei abejojate, žiūrėkite priežiūros institucijos svetainėje (9.3 pamoka).

Pagalbos paieška

Įsilaužimo pasekmių šalinimas reikalauja laiko ir patirties. Jei nesate tikri, ar viską pavyko sutvarkyti, kreipkitės pagalbos: į svetainės kūrėją, specializuotą įmonę arba talpinimo paslaugų teikėją (kai kurie teikėjai, taip pat WebOké, siūlo šią paslaugą, dažniausiai už papildomą mokestį). Pateikite jiems 1 žingsnyje padarytą kopiją, aprašykite, ką pastebėjote ir kada, bei ką jau padarėte.

Santrauka

• Įsilaužimas dažnai palieka užpakalines duris; vien matomos žalos pašalinimo nepakanka.
• Tvarka: fiksavimas, lankytojų apsauga, visų slaptažodžių ir salts pakeitimas, įsilaužimo kelio nustatymas, išvalymas, uždarymas ir patikrinimas.
• Išvalyti galima naudojant švarią atsarginę kopiją, padarytą gerokai prieš įsilaužimą, arba švariai iš naujo įdiegus WordPress, įskiepius bei temas ir patikrinus uploads, mu-plugins, .htaccess bei duomenų bazę.
• wp core verify-checksums parodo, kurie WordPress failai buvo pakeisti.
• Jei buvo paveikti asmens duomenys, per 72 valandas praneškite apie duomenų saugumo pažeidimą priežiūros institucijai, nebent rizika yra mažai tikėtina.

Testas (quiz)

Užduotis

Užduotis D7.5: Jūsų veiksmų planas įsilaužimo atveju. Užpildykite veiksmų planą savo svetainei, kad nereikėtų to galvoti, kai ateis laikas: kur yra Jūsų atsarginės kopijos ir kiek laiko atgal jos siekia, kas turi kokius slaptažodžius ir kaip juos visus pakeisite (sąrašas), kur rasti talpinimo paslaugų teikėjo žurnalus, kam skambinsite pagalbos ir kokie asmens duomenys yra Jūsų svetainėje (klausimui, ar reikės pranešti apie duomenų saugumo pažeidimą). Po to atlikite pratimą: kokius penkis žingsnius darysite per pirmą valandą, gavę pranešimą „Ši svetainė galimai nulaužta“, kokia tvarka ir kodėl tokia tvarka?

Papildoma literatūra

Šie straipsniai aprašo veiksmus WebOké valdymo skydeliuose; kituose skydeliuose jie veikia panašiai.

• DirectAdmin vadovas 18.2: Mano svetainė nulaužta: veiksmų planas
• Pagalbos! Mano svetainė buvo įsilaužta. Kaip galiu tai išspręsti ir kaip to išvengti ateityje?
• DirectAdmin vadovas 15.11: Imunify360: patikrinkite savo svetainę dėl kenkėjiškų programų
• DirectAdmin vadovas 17.2: Svetainės apžvalga ir išrašai: klaidų žurnalas ir prieigos žurnalas
• DirectAdmin vadovas 3.4: Prisijungimo istorija: kas ir kada prisijungė?
• Duomenų saugumo pažeidimai (Nyderlandų duomenų apsaugos institucija, Autoriteit Persoonsgegevens): https://www.autoriteitpersoonsgegevens.nl/themas/beveiliging/datalekken
• DUK: mano svetainė buvo nulaužta (wordpress.org, anglų kalba): https://wordpress.org/documentation/article/faq-my-site-was-hacked/