Kui koduleht suunab külastajaid võõrale lehele, kuvab tundmatuid reklaame, saadab rämpsposti või Google näitab turvahoiatust, võib veebileht olla häkitud. Tegemist on tõsise olukorraga, kuid läbimõeldult tegutsedes on WordPressi leht enamasti võimalik puhastada ja taastada.
Kõige olulisem on mitte kustutada juhuslikult faile ega taastada kohe esimest ettejuhtuvat varukoopiat. Esmalt tuleb rünnak piirata, säilitada vajalikud tõendid ja välja selgitada, milliseid veebilehe osi rünne puudutas.
Häkitud koduleht: kiire tegevusplaan
Kui veebileht on praegu maas või kahjustab külastajaid, alusta järgmisest.
- Piira avalikku ligipääsu. Kui leht suunab pahavarale või laadib külastaja seadmesse tundmatuid faile, pane ette serveri või CDN-i tasemel hooldusleht.
- Tee olemasolevast seisust koopia. Salvesta failid, andmebaas ja võimalusel serverilogid ka siis, kui koopia sisaldab pahavara.
- Dokumenteeri sümptomid. Tee ekraanitõmmised, kirjuta üles avastamise aeg, mõjutatud aadressid ja toimunud muudatused.
- Kaitse ligipääsud. Kasuta puhast arvutit, lõpeta tundmatud sessioonid ja vaheta kriitilised paroolid.
- Puhasta ning kõrvalda sissetungi põhjus. Ainult nähtava reklaami või ümbersuunamise eemaldamisest ei piisa.
WordPress.org soovitab pärast ründe avastamist olukorra dokumenteerida, kontrollida ka kohalikku arvutit, võtta ühendust majutajaga ning teha enne puhastamist veebikeskkonnast täiendav hetketõmmis.
Kuidas aru saada, et koduleht on häkitud?
Kõik ründed ei muuda avalehte nähtavalt. Mõnikord kuvatakse pahatahtlikku sisu ainult Google’ile, mobiilikasutajatele, reklaami kaudu saabunud külastajatele või kindlast riigist avatud lehele.
Koduleht suunab võõrale lehele
Üks levinumaid sümptomeid on olukord, kus koduleht suunab külastaja kasiino-, ravimi-, investeerimis- või muu tundmatu sisuga lehele.
Ümbersuunamine võib pärineda:
- teemasse lisatud JavaScriptist
- nakatunud pluginast
.htaccessvõi serveri konfiguratsioonist- andmebaasi sisestatud koodist
- pahatahtlikust reklaami- või analüütikaskriptist
- tagauksest, mis loob eemaldatud koodi uuesti.
Kui probleemi näeb ainult osa külastajatest, ei tähenda see, et veebileht oleks puhas. Pahavara võib teadlikult vältida sisselogitud administraatorile kuvamist.
Google näitab turvahoiatust
Google võib kuvada otsingutulemuses või brauseris teateid, nagu:
- „See sait võib olla häkitud“
- „See sait võib teie arvutit kahjustada“
- „Petlik veebileht“
- „Dangerous site“.
Google Search Console’i turvaprobleemide raport võib näidata pahavara, häkitud sisu või andmepüügiga seotud näidisaadresse. Raportis toodud aadressid on näited ega pruugi olla täielik nimekiri kõikidest nakatunud lehtedest. Google Search Console’i turvaprobleemide juhend
Google’i otsingusse ilmuvad võõrad lehed
Ründaja võib luua tuhandeid nähtamatuid või automaatselt genereeritud lehti, mis reklaamivad ravimeid, hasartmänge, võltsitud tooteid või muid teenuseid.
Veebilehe tavakülastaja ei pruugi neid lehti menüüs näha. Need võivad olla avastatavad ainult:
- Google’i otsingus
- Search Console’i indekseerimisaruandes
- XML-saidikaardis
- serveri failides
- andmebaasi postituste hulgas.
WordPressi on tekkinud võõras administraator
Kontrolli WordPressi kasutajate nimekirja. Tundmatu administraator või ootamatult muutunud kasutajaroll on tugev ohumärk.
Ründaja võib luua varukonto, et pääseda tagasi ka pärast algse turvaaugu parandamist.
Failid ilmuvad pärast kustutamist tagasi
Kui pahatahtlik fail tekib pärast eemaldamist uuesti, on süsteemi jäänud tagauks või muu püsivusmehhanism.
See võib paikneda:
- teises PHP-failis
- must-use-pluginate kataloogis
- üleslaadimiste kaustas
- andmebaasis
- ajastatud WordPressi toimingus
- serveri cron-töös
.user.ini,php.inivõi veebiserveri konfiguratsioonis- sama majutuskonto mõnel teisel veebilehel.
Majutus või brauser saadab hoiatuse
Majutusteenuse pakkuja võib veebilehe sulgeda pahavara, suure e-posti mahu või tavapäratult suure serverikoormuse tõttu. Külastajate viirusetõrje võib samuti veebilehe blokeerida.
Selliseid teateid ei tohiks lihtsalt valepositiivseks pidada. Küsi majutajalt konkreetsed failinimed, tuvastamise aeg ja logiväljavõtted.
Sümptom, võimalik põhjus ja esimene samm
| Sümptom | Võimalik põhjus | Esimene samm |
|---|---|---|
| Külastaja suunatakse võõrale lehele | Nakatunud JavaScript, andmebaas või serveri konfiguratsioon | Testi kontrollitud keskkonnas eri seadmete ja brauseritega ning piira kahjulik liiklus |
| Google kuvab turvahoiatust | Pahavara, andmepüük või SEO-spämm | Ava Search Console’i turvaprobleemide raport |
| Otsingus on võõrad kasiino- või ravimilehed | Automaatselt loodud SEO-spämm | Kontrolli indekseeritud aadresse, andmebaasi ja saidikaarte |
| WordPressis on tundmatu administraator | Varastatud ligipääs või pahatahtlik kood | Peata konto ligipääs ja kontrolli kasutajate muutmise logisid |
| Administraatori parool enam ei tööta | Konto või e-posti aadress on muudetud | Taasta ligipääs majutuse või andmebaasi kaudu |
| Leht saadab rämpsposti | Nakatunud fail, võõras konto või kuritarvitatud vorm | Peata kirjade väljasaatmine ning kontrolli logisid ja järjekordi |
| Pahavara tuleb pärast eemaldamist tagasi | Alles jäi tagauks või ajastatud tegevus | Kontrolli kogu majutuskontot, mitte ainult nähtavalt muudetud faili |
| Veebileht muutub väga aeglaseks | Pahatahtlik protsess, spämm või suurenenud botiliiklus | Kontrolli serverikoormust, päringuid ja ligipääsulogisid |
| Failide muutmise kuupäevad on ootamatud | Volitamata failimuudatused | Säilita koopia ning võrdle faile usaldusväärsete versioonidega |
| Vormides või tellimustes on võõrad andmed | Automatiseeritud rünne või andmebaasi kompromiteerimine | Peata mõjutatud funktsioon ning kontrolli andmete terviklikkust |
Esimesed sammud rünnaku avastamisel
1. Piira kahju, kuid säilita ligipääs uurimiseks
Kui veebileht nakatab või eksitab külastajaid, tuleb avalik ligipääs ajutiselt piirata. Turvalisem on kasutada serveri, hostingu või CDN-i tasemel hoolduslehte, mitte loota nakatunud WordPressi pluginale.
Ära kustuta kohe kogu veebilehte. Puhastamise käigus võib vaja minna:
- ründe algusaja määramist
- muudetud failide võrdlemist
- ligipääsulogisid
- andmebaasi kirjeid
- tõendeid majutajale või andmekaitse hindamiseks.
2. Dokumenteeri olukord
Kirjuta üles:
- millal probleem avastati
- kes sellest teatas
- millistel aadressidel probleem esines
- millises seadmes või brauseris seda nähti
- milliseid kontosid või faile muudeti
- milliseid teateid näitas Google või majutaja
- millal veebileht viimati kindlasti korras oli.
Tee ekraanitõmmised ja ekspordi olemasolevad logid enne, kui nende säilitustähtaeg läbi saab.
3. Tee nakatunud seisust varukoopia
See võib tunduda ebaloogiline, kuid enne puhastamist tuleks teha failidest ja andmebaasist koopia. Nakatunud varukoopia ei sobi avaliku veebilehe taastamiseks, kuid võib aidata:
- tuvastada ründe põhjust
- võrrelda puhastatud ja nakatunud faile
- taastada ekslikult kustutatud sisu
- säilitada uusi tellimusi või vormipäringuid
- hinnata, kas isikuandmed võisid lekkida.
Märgi koopia selgelt nakatunuks ja hoia seda avalikust veebikaustast väljaspool.
4. Kasuta puhast seadet
Kui arvuti, millega veebilehte hallatakse, sisaldab paroolivarguse pahavara, võivad uued paroolid kohe uuesti lekkida.
Enne ligipääsude vahetamist:
- uuenda operatsioonisüsteem ja brauser
- käivita pahavarakontroll
- eemalda kahtlased brauserilaiendused
- kasuta võimalusel teist kontrollitud seadet
- väldi paroolide saatmist e-posti või vestluse kaudu.
5. Võta ühendust majutusteenuse pakkujaga
Majutaja võib näha seda, mida WordPressi administraator ei näe:
- kahtlased sisselogimised
- failimuudatuste ajad
- e-kirjade massiline saatmine
- serveri cron-tööd
- teistelt sama konto veebilehtedelt alguse saanud nakkus
- WAF-i või viirusetõrje teated.
Küsi ka, millised varukoopiad on olemas ja kui kaua serverilogisid säilitatakse.
Veebilehe puhastamine samm-sammult
Häkitud kodulehe puhastamine ei tähenda ainult leitud pahavarafaili kustutamist. Eesmärk on eemaldada pahatahtlik kood, sulgeda tagauksed ja parandada algne haavatavus.
1. Loo puhastamiseks eraldatud keskkond
Võimalusel tee puhastamine staging-keskkonnas või eraldatud serverikoopias. Avaliku nakatunud lehe korduv käivitamine võib kahjustada külastajaid ja anda ründajale võimaluse muudatusi jätkata.
Kontrolli, et staging ei oleks avalikult indekseeritav ega saadaks klientidele päris e-kirju.
2. Kontrolli WordPressi tuumafaile
WordPressi tuumafaile saab võrrelda WordPress.org avaldatud kontrollsummadega:
wp core verify-checksums --include-rootKäsk aitab leida muudetud või ootamatuid tuumafaile. Edukas kontroll ei tähenda siiski, et kogu veebileht on puhas, sest pahavara võib paikneda teemas, pluginates, üleslaadimistes või andmebaasis. WP-CLI kontrollsummade dokumentatsioon
Puhastamisel on sageli turvalisem WordPressi tuum asendada ametlikust allikast pärineva sama või uuema versiooniga, mitte parandada tundmatult muudetud faile käsitsi.
3. Asenda pluginad ja teemad puhaste koopiatega
Kontrolli kõikide pluginate ja teemade päritolu.
- Laadi uued koopiad ametlikust hoidlast või tarkvara tootja kontolt.
- Ära kopeeri vana nakatunud kataloogi pimesi uude paigaldusse.
- Eemalda kasutamata pluginad ja teemad täielikult.
- Ära kasuta litsentsist möödahiilimiseks muudetud ehk nulled-lahendusi.
- Kontrolli eraldi kohandatud teema faile, sest neid ei saa automaatselt ametliku paketiga võrrelda.
Plugina väljalülitamine ei eemalda selle failides olevat pahavara. Kui fail jääb serverisse ja on otse käivitatav, võib risk püsida.
4. Kontrolli tundlikke asukohti
Erilist tähelepanu vajavad:
- veebilehe juurkataloog
wp-adminwp-includeswp-content/pluginswp-content/themeswp-content/mu-pluginswp-content/uploadswp-config.php.htaccess.user.ini- tundmatud PHP-failid meediakaustades.
Vaata ka faile, mille nimi püüab jäljendada WordPressi komponenti. Üksnes faili nime või muutmise kuupäeva järgi ei saa siiski kindlalt otsustada, kas tegemist on pahavaraga.
5. Otsi tagauksi ja püsivusmehhanisme
Tagauks võimaldab ründajal pärast nähtava pahavara eemaldamist veebilehele naasta.
Kontrollida tuleb:
- võõraid administraatorikontosid
- rakenduse paroole ja API-võtmeid
- WordPressi ajastatud tegevusi
- serveri cron-töid
- muudetud serverikonfiguratsiooni
- tundmatuid must-use-pluginaid
- teisi sama majutuskonto veebilehti
- automaatselt uuesti tekkivaid faile.
Kui puhastatakse ainult avalehe ümbersuunamine, kuid jäetakse tagauks alles, võib koduleht mõne tunni või päeva pärast uuesti nakatuda.
6. Kontrolli andmebaasi
Pahavara ei paikne alati failides. Andmebaasi võidakse lisada:
- JavaScripti
- võõraid administraatoreid
- spämmlehti ja -postitusi
- muudetud veebiaadresse
- pahatahtlikke vidinaid
- võõraid ümbersuunamisi
- tundmatuid seadistusväärtusi
- ajastatud tegevusi.
Kontrolli eelkõige kasutajaid, postitusi, valikute tabelit, vidinaid ja pistikprogrammide enda tabeleid.
Ära käivita andmebaasis pimesi ulatuslikku otsi-asenda toimingut. See võib rikkuda serialiseeritud andmeid, seadistusi ja tellimusi.
7. Tuvasta ründe algpõhjus
Pahavara eemaldamise kõrval tuleb vastata küsimusele: kuidas ründaja sisse pääses?
Võimalikud põhjused on:
- uuendamata plugin või teema
- varastatud administraatori- või SFTP-parool
- ebaturvaline majutuskonto
- kompromiteeritud arendaja arvuti
- liiga laiad failiõigused
- mahajäetud testkeskkond
- aegunud PHP või muu serveritarkvara
- sama konto teine nakatunud veebileht
- tundmatu või muudetud päritoluga tarkvara.
Kui algpõhjus jääb parandamata, ei ole puhastamine lõplik.
8. Uuenda tarkvara
Pärast puhta seisu loomist uuenda:
- WordPressi tuum
- aktiivne teema
- pluginad
- PHP toetatud versioonile
- vajalik serveritarkvara.
Uuendusi tuleks teha kontrollitult ja toimiva varukoopiaga. Turvauuenduste edasilükkamine jätab teadaoleva haavatavuse avatuks. WordPressi ametlik turvajuhend soovitab kasutada ajakohast WordPressi ning aktiivselt hooldatavaid pluginaid ja teemasid. WordPressi turvalisuse juhend
9. Vaheta kõik olulised ligipääsud
Pärast pahavara ja tagauste eemaldamist vaheta uuesti:
- WordPressi administraatorite paroolid
- majutuskonto parool
- SFTP- ja SSH-võtmed
- andmebaasi kasutaja parool
- haldusega seotud e-posti konto parool
- CDN-i ja DNS-i ligipääsud
- makse- ja tarneintegratsioonide API-võtmed
- WordPressi rakenduse paroolid
- muud lekkinud saladused.
Uuenda ka WordPressi turvasoolasid, et olemasolevad sisselogimissessioonid tühistada. Kui paroole vahetati juba ründe avastamisel, vaheta need pärast puhastamist uuesti.
10. Testi taastatud veebilehte
Kontrolli vähemalt:
- avaleht ja olulisemad alamlehed
- mobiili- ja arvutivaade
- administraatori sisselogimine
- kontaktivormid
- otsing
- kasutajakontod
- e-poe ostukorv ja kassaprotsess
- maksete ja tarneviiside testimine
- tellimuste e-kirjad
- kolmandate süsteemide integratsioonid
- serveri ja brauseri veateated
- uute failimuudatuste tekkimine.
E-poe puhul tuleks teha kontrollitud testtellimus, mitte piirduda avalehe vaatamisega.
Kas taastada varukoopia või puhastada olemasolev leht?
Varukoopia võib olla kiire lahendus ainult siis, kui on piisavalt kindel, et see pärineb ajast enne nakatumist.
Enne taastamist kontrolli:
- millal rünne tegelikult algas
- kas varukoopias on sama haavatav plugin
- kas koopia sisaldab tagauksi
- millised andmed on pärast varukoopia tegemist lisandunud
- kas taastamine kirjutab üle värsked tellimused, kliendid või vormipäringud.
E-poe puhul võib vana andmebaas kustutada tellimused
Kui taastad WooCommerce’i või muu e-poe vana andmebaasi tervikuna, võivad kaduda kõik pärast varukoopia loomist tehtud:
- tellimused
- maksete olekud
- kliendikontod
- laoseisu muudatused
- tagastusandmed
- kupongid ja kampaaniad
- sisumuudatused.
Seetõttu tuleb e-poes enne andmete taastamist säilitada värsked tehinguandmed ja koostada nende kontrollitud ühendamise plaan. Mõnikord on mõistlik taastada ainult puhtad failid ning puhastada andmebaas eraldi.
Kas varukoopia üksi lahendab probleemi?
Mitte tingimata. Kui taastatud versioon sisaldab sama turvaauku või ründaja ligipääsuandmed on endiselt kehtivad, võib leht uuesti nakatuda.
Varukoopia taastamise järel tuleb endiselt:
- uuendada haavatav tarkvara
- eemaldada vana ründevektor
- vahetada ligipääsud
- kontrollida kogu keskkonda
- jälgida uusi muudatusi.
Mida teha Google’i turvahoiatusega?
Google’i hoiatust ei eemaldata ainult veebilehe avalehe parandamisega. Kõigepealt peab kogu veebikeskkond olema puhastatud ja ründe põhjus kõrvaldatud.
1. Ava Search Console’i turvaprobleemide raport
Kontrolli:
- probleemi liiki
- avastamise kuupäeva
- näidislehti
- võimalikke pahavara- või spämmikategooriaid.
Näidisaadresside puhastamisest üksi ei piisa, sest loetelu ei pruugi hõlmata kogu nakatumist.
2. Eemalda pahavara ja loodud rämpslehed
Kontrolli nii faile, andmebaasi kui ka serveriseadistusi. Ründaja loodud aadressid peaksid pärast sisu eemaldamist tagastama sobiva vastuse, tavaliselt 404 või 410.
Vajadusel saab kõige kahjulikumad võõrad aadressid Search Console’is ajutiselt otsingutulemustest peita, kuid see ei asenda pahavara eemaldamist.
3. Taotle ülevaatust
Kui kogu veebileht on puhastatud, vali Search Console’i turvaprobleemide raportis ülevaatuse taotlemine.
Kirjelda lühidalt:
- milline pahavara või võõras sisu eemaldati
- milline haavatavus parandati
- milliseid komponente uuendati
- kuidas tagauste puudumist kontrolliti
- millised turvameetmed lisati.
Ära taotle ülevaatust enne puhastamise lõpetamist. Google’i andmetel võib pahavara ülevaatus võtta mõne päeva ja häkitud rämpssisu kontroll kauem. Hoiatuse kadumist ei saa lubada kindla tähtaja jooksul. Google’i juhend turvahoiatuse eemaldamiseks
Kas häkkimisest peab kedagi teavitama?
Kui ründaja võis saada ligipääsu klientide, töötajate või teiste inimeste isikuandmetele, tuleb juhtumit hinnata ka isikuandmete rikkumisena.
Dokumenteeri:
- millistele andmetele võidi ligi pääseda
- kui palju inimesi võis olla mõjutatud
- kas andmeid muudeti, kopeeriti või kustutati
- milline oht võib inimestele tekkida
- milliseid leevendusmeetmeid rakendati.
Kui rikkumine põhjustas või tõenäoliselt põhjustab ohu inimeste õigustele ja vabadustele, tuleb Andmekaitse Inspektsiooni võimaluse korral teavitada 72 tunni jooksul pärast rikkumisest teada saamist. Suure ohu korral võib tekkida ka mõjutatud inimeste teavitamise kohustus. Andmekaitse Inspektsiooni juhend isikuandmete rikkumise kohta
See hinnang sõltub konkreetsest juhtumist ning vajadusel tasub kaasata andmekaitsespetsialist või jurist.
Kuidas uut nakatumist ennetada?
Pärast pahavara eemaldamist tuleb turvameetmed üle vaadata kogu veebikeskkonnas.
Regulaarsed uuendused
Uuenda WordPressi, pluginaid ja teemat järjepidevalt. Eemalda tarkvara, mida enam ei kasutata või mille arendus on lõppenud.
Uuenduse järel testi vähemalt veebilehe olulisemaid funktsioone.
Kaheastmeline autentimine
Kasuta administraatorikontodel kaheastmelist autentimist. See vähendab ohtu, et ainult varastatud parooliga saadakse haldusesse sisse.
Piira administraatoriõigused inimestele, kes neid päriselt vajavad.
Tugevad ja kordumatud paroolid
Ära kasuta WordPressis, majutuses ja e-postis sama parooli. Haldusega seotud e-posti konto turvalisus on eriti oluline, sest selle kaudu saab tavaliselt paroole taastada.
HTTPS ja SSL
Kehtiv SSL-sertifikaat kaitseb brauseri ja serveri vahelist andmesidet. See on vajalik paroolide, vormiandmete ja küpsiste turvaliseks edastamiseks.
SSL ei eemalda pahavara ega takista haavatava plugina ärakasutamist. Seetõttu ei saa ainult HTTPS-i olemasolu põhjal järeldada, et veebileht on turvaline.
Turvalised failiõigused ja SFTP
Väldi põhjendamatult laiu failiõigusi ning kasuta tavalise FTP asemel krüpteeritud SFTP- või SSH-ühendust.
WordPressi sisseehitatud teema- ja pluginafailide redaktori saab vajadusel keelata:
define('DISALLOW_FILE_EDIT', true);See ei takista kõiki ründeid, kuid piirab ühe võimaluse, mida administraatorikonto üle võtnud ründaja võib kasutada. WordPressi tugevdamise juhend
Eraldatud ja kontrollitud varukoopiad
Varukoopia peab sisaldama nii faile kui ka andmebaasi. Hoia vähemalt ühte koopiat veebiserverist eraldi ja testi aeg-ajalt, kas seda on võimalik taastada.
Ainult varukoopia olemasolu märgist WordPressi halduses ei tõenda, et koopia on täielik või töökorras.
Logimine ja failimuudatuste jälgimine
Jälgi:
- administraatorite sisselogimisi
- kasutajate ja rollide muudatusi
- pluginatega seotud tegevusi
- failimuudatusi
- e-kirjade saatmist
- serveri koormuse järske muutusi
- ootamatuid cron-töid
- Search Console’i teateid.
Varajane avastamine vähendab aega, mil ründaja saab veebilehel tegutseda.
Veebirakenduse tulemüür
WAF võib aidata blokeerida osa automatiseeritud rünnetest enne WordPressini jõudmist. See on täiendav kaitsekiht, mitte asendus uuendustele, turvalistele paroolidele ja hooldusele.
Millist abi teenuselt oodata?
| Teenus | Mida kontrollida või nõuda |
|---|---|
| Kodulehe puhastamine | Failide ja andmebaasi koopia, pahavara eemaldamine, tagauste kontroll ning testimine pärast taastamist |
| Ründe põhjuse analüüs | Haavatavate komponentide, kontode, logide ja serverikeskkonna kontroll |
| Andmete taastamine | Teadaolevalt puhta varukoopia kontroll ning värskete andmete säilitamise plaan |
| Google’i hoiatuse lahendamine | Search Console’i probleemide kontroll ja ülevaatuse taotlus pärast puhastamist |
| Veebilehe hooldus | Uuendused, varukoopiad, töökindluse kontroll ja regulaarne seire |
| E-poe taastamine | Tellimuste, klientide, maksete, laoseisu ja integratsioonide terviklikkuse kontroll |
| Turvameetmete parandamine | Ligipääsude vahetamine, õiguste piiramine, 2FA, logimine ja vajadusel WAF |
| Isikuandmete juhtum | Mõjutatud andmete ja võimaliku teavitamiskohustuse dokumenteeritud hindamine |
Ükski teenusepakkuja ei saa ausalt garanteerida, et veebilehte ei häkita enam kunagi. Küll aga saab vähendada ründe tõenäosust, sulgeda teadaolevad nõrkused ja parandada uute probleemide avastamise kiirust.
Korduma kippuvad küsimused
Kas häkitud kodulehte saab puhastada ilma varukoopiata?
Sageli saab, kuid töö võib olla mahukam. WordPressi tuuma, pluginad ja teemad saab asendada usaldusväärsete koopiatega, kuid kohandatud kood ja andmebaas tuleb eraldi läbi kontrollida.
Kas piisab pahavaratõrje plugina käivitamisest?
Mitte alati. Skanner võib leida tuntud pahavara, kuid ei pruugi tuvastada kohandatud tagauksi, andmebaasi sisestatud koodi või serveri konfiguratsiooni muudatusi.
Kas veebileht tuleb kohe kustutada?
Üldjuhul mitte. Esmalt tuleks piirata kahju ja säilitada uurimiseks failid, andmebaas ning logid. Juhuslik kustutamine võib hävitada nii ettevõtte andmed kui ka ründe põhjuse tuvastamiseks vajalikud tõendid.
Kas vana varukoopia taastamine lahendab probleemi?
Ainult siis, kui varukoopia on kindlasti puhas ja pärast selle loomist lisandunud andmed säilitatakse. Sama haavatavuse allesjäämisel võib veebileht uuesti nakatuda.
Kas WordPress tuleb täielikult uuesti paigaldada?
WordPressi tuuma ja standardkomponentide asendamine puhaste koopiatega on sageli mõistlik. Täielik ümberehitus ei ole alati vajalik, kuid väga vana või kontrollimatu lahenduse puhul võib see olla turvalisem.
Miks koduleht suunab ainult mõne külastaja teisele lehele?
Pahavara võib tingimuslikult kontrollida seadet, riiki, brauserit, viiteallikat või sisselogimise olekut. Seetõttu ei pruugi administraator probleemi oma arvutis näha.
Kuidas tundmatu administraatori konto eemaldada?
Kõigepealt säilita konto andmed ja kontrolli, millal ning kuidas see loodi. Seejärel peata konto ligipääs, eemalda see ja kontrolli, kas veebilehele on jäänud kood, mis konto uuesti loob.
Kas pärast puhastamist on veebileht 100% turvaline?
Ei. Ühtegi avalikku veebisüsteemi ei saa pidada absoluutse garantiiga turvaliseks. Puhastamise eesmärk on eemaldada tuvastatud pahavara, parandada teadaolev sissetungitee ja vähendada kordumise riski.
Kas SSL-sertifikaat kaitseb häkkimise eest?
SSL krüpteerib andmeside külastaja ja serveri vahel. See ei kaitse iseenesest haavatava plugina, varastatud administraatoriparooli või serverisse lisatud pahavara eest.
Kui kiiresti Google’i hoiatus kaob?
Pärast täielikku puhastamist tuleb Search Console’is taotleda turvaülevaatust. Töötlemisaeg sõltub probleemi liigist ja Google’i kontrollist ning seda ei saa täpselt lubada.
Kas häkitud veebileht võib mõjutada e-posti?
Jah. Ründaja võib kasutada serverit rämpsposti või andmepüügikirjade saatmiseks. See võib kahjustada domeeni ja serveri mainet ning põhjustada tavapäraste kirjade rämpsposti sattumist.
Kas puhastamise järel tuleb kõik paroolid vahetada?
Jah, kriitilised ligipääsud tuleks pärast puhta seisu saavutamist uuesti vahetada. See hõlmab WordPressi, majutust, SFTP-d, andmebaasi, e-posti, DNS-i ja vajalikke API-võtmeid.
Kas rünnak võib puudutada ka teisi sama serveri veebilehti?
Jah. Kui mitu veebilehte kasutavad sama majutuskontot või liiga laiu failiõigusi, võib nakkus liikuda nende vahel. Kontrollida tuleb kogu kontot.
Kokkuvõte
Kui koduleht on häkitud, ei piisa tavaliselt ühe nähtava faili kustutamisest. Korralik pahavara eemaldamine hõlmab olukorra dokumenteerimist, failide ja andmebaasi kontrolli, tagauste eemaldamist, algpõhjuse parandamist, ligipääsude vahetamist ning veebilehe põhjalikku testimist.
Varukoopia võib taastamist kiirendada, kuid seda ei tohiks kasutada pimesi. Eriti e-poe puhul tuleb enne vana andmebaasi taastamist säilitada värsked tellimused, kliendiandmed ja maksete olekud.
Pärast puhastamist aitavad riski vähendada regulaarsed uuendused, eraldatud varukoopiad, kaheastmeline autentimine, õiguste piiramine ning pidev tehniline jälgimine.
Vaata lähemalt häkitud kodulehe puhastamise teenust või regulaarset kodulehe haldust.
