Häkitud WordPressi veebileht: mida teha samm-sammult

Punane hoiatus Chrome'is, ümbersuunamine võõrale domeenile ja haldusliides, kus kõik näeb välja nagu ikka. Hädaolukorra tegevuskava just WordPressi veebilehele: mida ei tohi esimesel tunnil teha, kus nakkus tegelikult peidus on ja kuidas Google'i hoiatusest lahti saada.

Neljapäeva hommikul helistab klient ja ütleb, et Chrome kuvab tema ekraanil teie poe asemel punast täisekraanihoiatust. Te avate veebilehe telefonis ja poolteist sekundit hiljem viskab brauser teid hoopis võõrale domeenile, aga tööarvutis, kus haldusliides on esmaspäevast saati lahti, näeb kõik välja täpselt nagu ikka. Nii näebki häkitud WordPressi veebileht kõige sagedamini välja — mitte rikutud avaleht ründaja allkirjaga, vaid sait, mis näitab omanikule üht nägu ja külastajale teist. Just seepärast kuluvad esimesed tunnid tavaliselt vaidlusele, kas probleem üldse on olemas.

Küsimused, millele siin vastame, esitatakse tavaliselt just selles järjekorras: mida tohib ja mida ei tohi esimesel tunnil teha, kui veel ei ole teada, kui sügavale ründaja pääses; kus täpselt WordPressi installatsioonis kood tavaliselt peidus on, sest ilma selleta on puhastamine oletamine; ja kuidas saavutada, et Google hoiatuse eemaldaks, ilma et rikuksite ära oma teise katse. Vahepeale jääb see, mille omanikud kõige sagedamini vahele jätavad — juurdepääsuandmete vahetamine õigel hetkel ja õiges järjekorras.

Kõik, mida lähitundidel teha tuleb, on siin, ja vahepeal ei pea kuhugi mujale minema. Artiklist jääb välja ainult see, mis kulub ära pärast seda, kui veebileht juba töötab — varukoopiate strateegia, süsteemi turvamine ja kaitse järgmise korra vastu, mis on platvormist sõltumata ühesugune —, ja eraldi juhendile viitame allpool. Jutt on sellest, mis teeb WordPressi teistsuguseks: pistikprogrammide ökosüsteem, kaust wp-content, andmebaasitabelid, kus nakkus elab failide puhastamise üle, ja käsud, mis lubavad rohkem, kui tegelikult kontrollivad. Meie praktikas otsustavad just need neli asja, kas veebileht on puhas ühe päevaga või kolmanda katse järel.

Esimene tund: ärge kustutage midagi

Esimene reaktsioon on peaaegu alati üks kahest — avada majutuse failihaldur, leida sealt midagi võõrast ja see ära kustutada, või vajutada nuppu, mis taastab eilse varukoopia. Palume mitte teha kumbagi, ja põhjus on praktiline, mitte bürokraatlik. Kiirustamine on arusaadav, sest iga punase hoiatusega tund maksab teile külastajaid. Aga just kiirustades tehakse need kaks otsust, mis venitavad taastamise kaheksast tunnist nädalaks, ja mõlemad on pöördumatud.

Kui nakatunud failid on kustutatud, kaob ka ainus materjal, mille põhjal hiljem sissemurdmiskoht tuvastatakse: failide muutmisajad, ründaja üleslaaditud skriptide sisu ja serveri pääsulogi kirjed, mis nende aegadega kokku langevad. Ilma sissemurdmiskohata on puhastamine üksnes sümptomite eemaldamine, ja selle hind on mõõdetud — Google'i ja California ülikooli (Berkeley) uuringus, mis hõlmas 760 935 häkkimisjuhtumit ajavahemikus 2014. aasta juulist 2015. aasta juunini, häkiti 12% veebilehtedest 30 päeva jooksul uuesti, sest kõrvaldatud olid ainult sümptomid, mitte põhjus (Li jt, WWW 2016).

Seepärast on esimene töö täielik koopia — kõik failid ja kogu andmebaas ühe korraga, enne kui puudutatakse ainsatki baiti. Nähtav ümbersuunamine või rikutud avaleht on harva kõik, mis veebilehel toimub: Sucuri andmetel leiti 2023. aastal 49,21% nakatunud veebilehtedest vähemalt üks tagauks (backdoor) ja aasta jooksul eemaldas nende meeskond 21 062 sellist programmi (Sucuri, "2023 Hacked Website & Malware Threat Report", 2024. aasta juuni). Hoidke koopiat väljaspool sedasama serverit, sest just seal on ründajal endiselt ligipääs.

Järgmine kõne on majutusteenuse pakkujale, ja mitte viisakusest: tal on pääsulogid, mis teie kontos ulatuvad tavaliselt vaid mõne päeva taha, ning jagatud serveris peab ta kontrollima, kas naaberkontodes sama ei toimu. Kui veebilehel võetakse vastu makseid või sisestatakse isikuandmeid, tuleb see praegu välja lülitada või hooldusrežiimi panna — iga külastaja, kes järgmise tunni jooksul kaardiandmed sisestab, on eraldi probleem, mida teil veel ei ole. Hooldusrežiim maksab ühe päeva käibe; mahamagatud hetk maksab kirja, mille peate klientidele saatma.

Kui wp-admin enam ei avane — häkitud veebilehel juhtub seda tihti —, ei õnnestu hooldusrežiimi liidesest sisse lülitada ja jääb kaks teed. Veebilehe juurkataloogi .htaccess-faili lisatakse reegel, mis saadab kõik peale teie IP-aadressi ühele staatilisele lehele teatega tehniliste tööde kohta. Või palute samas vestluses majutajal konto ajutiselt peatada. Teine variant näib jõhker, aga toimib ka siis, kui failidele enam ligi ei pääse.

Eilne varukoopia näib kiireima teena tagasi, ja mõnikord ongi see õige samm — aga ainult siis, kui on teada, mis päeval ründaja sisse pääses. Meie praktikas märgatakse nakkust tunduvalt hiljem, kui see alguse sai: kõigepealt vaikib kood mõnda aega, siis hakkab näitama rämpslehti või ümbersuunamisi. See tähendab, et eilses koopias on tagauks suure tõenäosusega juba sees. Taastamine peidab sellisel juhul paariks tunniks sümptomid ja viib veebilehe täpselt sellesse seisu, milles see kunagi ära häkiti, mistõttu alustame häkitud veebilehe taastamist tavaliselt mõne tunni jooksul ja ka kiirustades koopiast, mitte kustutamisest — isegi siis, kui klient helistab ja palub lihtsalt kiiresti kõik ära puhastada.

Häkitud WordPressi veebileht: märgid, mis selle ära annavad

Ümbersuunamine, mis käivitub Google'i tulemusest tulnud külastajal, aga ei käivitu siis, kui aadress brauseri ribale kirjutada, ei ole arusaamatus, vaid ründaja teadlik valik: Google'i rämpssisupoliitikates on ümbersuunamine eraldi nimetatud häkitud sisu liik, mille puhul ründajad lisavad koodi, mis suunab osa kasutajaid kahjulikele või rämpslehtedele (Google Search Central, kontrollitud 2026. aasta augustis). Ja just see, et ümber suunatakse osa, mitte kõik, omanikku eksitabki. Kontroll võtab minuti: avage veebileht inkognitoaknas, seejärel leidke see Google'i tulemustest ja avage sealtkaudu, ning korrake mõlemat telefonis.

Teine märkide rühm on halduspoolel ja on palju konkreetsem: wp-admin annab äkki 404, sisselogimisvorm laadib õige parooli järel lihtsalt uuesti, kasutajate loendis on administraatorikonto, mida keegi teie meeskonnast ei ole loonud, või on jaotises Sätted → Üldine saidi aadress muutunud võõraks. Andmebaasis on viimane neist märkidest kõigest kaks rida tabelis wp_options — siteurl ja home —, ja just seepärast võivadki aadress, mida te sätetes näete, ja aadress, kuhu külastaja jõuab, teineteisest erineda.

Kolmas rühm tuleb väljastpoolt ja on kõige valusam, sest veebilehe seisust räägib teile keegi teine: majutusettevõte peatab hoiatuseta konto, millest on rämpsposti välja läinud, Search Console'i ilmub kanne turvaprobleemi kohta, või tekib otsingutulemustes veebilehe kõrvale märkus, et sait võib olla häkitud (Google'i ingliskeelses liideses "This site may be hacked"), mille Google kuvab siis, kui peab tõenäoliseks, et ründaja on olemasolevaid lehti muutnud või uusi rämpslehti lisanud (Google Search Help, kontrollitud 2026. aasta augustis). Selle märkuse paneb Google ise, mitte kellegi kaebuse peale, ja see ilmub ka siis, kui veebileht teile endale laitmatu tundub.

Nimetused ei ole siin akadeemiline küsimus, sest nende järgi te lahendust otsite ja hindate, kas teostaja teie juhtumit mõistab: Google nimetab oma dokumentatsioonis kolme — gibberish hack, Japanese keyword hack ja cloaked keywords and links hack, kus ründaja loodud lehed näitavad otsingumootorile üht sisu ja külastajale teist. Valdkonnas levinud "pharma hack" pärineb turbeettevõttelt Sucuri (2020) ja Google'i dokumentatsioonis seda ei ole. Praktiline kontroll on kõigi kolme puhul siiski üks: sisestage otsingusse site:-päring oma domeeniga, ja te näete kohe lehti, mida keegi teie ettevõttes kirjutanud ei ole. Jaapani variandis on need automaatselt genereeritud lehed jaapanikeelsete pealkirjadega juhuslikult nimetatud kaustades ja teie domeeniga aadressis.

Ja nüüd ebameeldiv osa: puhas skannitulemus ei tõesta, et veebileht on puhas, sest skanner näeb ainult seda, mida server talle näitab, ründaja kood aga tunneb skannerid ja otsingumootorid sageli ära. Google hoiatab oma maskeeritud märksõnalehtede juhendis, et häkkimist varjatakse tihti nii, et omanikule tunduks, nagu oleks probleem juba möödas. Kui skannimine on puhas, aga majutaja kurdab väljuva posti üle, uskuge majutajat. Siis on omal kohal veebilehe turvaaudit failide ja logide käsitsi kontrolliga, sest skanner vastab küsimusele, kas veebilehel on midagi teadaolevate mustrite loendist, mitte küsimusele, kas veebilehel on endiselt keegi sees.

Kus WordPressi risk tegelikult asub

Meie praktikas ei ole põhjus, kui see lõpuks leitakse, peaaegu kunagi WordPressi tuum ise. Patchstacki ülevaates "State of WordPress Security in 2026" on kokku loetud 11 334 uut turvanõrkust, mis WordPressi ökosüsteemis 2025. aastal avastati — 42% rohkem kui aasta varem —, ja teile on praegu tähtis just nende arvude jaotus: 91% neist puudutas pistikprogramme, 9% teemasid, WordPressi tuumas endas aga teatati terve aasta jooksul vaid kuuest, kõik pealegi madala prioriteediga. Peaaegu ükski värskelt avastatud turvanõrkus ei peitu seega selles WordPressis, mille te kunagi paigaldasite, vaid selles, mis sellele on aastate jooksul juurde pandud.

Iga pistikprogramm on eraldi koodibaas, mida kirjutab eraldi autor eraldi — ja üsna sageli juba katkenud — uuendamisdistsipliiniga. Nelikümmend pistikprogrammi ei tähenda seetõttu üht turvaküsimust, vaid nelikümmend üksteisest sõltumatut turvaküsimust. Meie praktikas saab tavaline ettevõtte veebileht täiesti hakkama kümne kuni viieteistkümne pistikprogrammiga, ülejäänud on sinna enamasti jäänud ammu unustatud ülesannetest: galerii, mida enam ei näidata, vorm, mis on teisega asendatud, slaider, mida praegune kujundus enam ei kasuta. Kui me võtame üle WordPressi veebiarenduse ja hoolduse, on pistikprogrammide arvu vähendamine esimene, mitte viimane töö.

Ja siin on viga, mis kordub sagedamini kui ükski teine: tarbetu pistikprogramm deaktiveeritakse, mitte ei kustutata. Deaktiveerimine ütleb WordPressile, et seda enam ei laadita, kuid failid jäävad serverisse oma kohale, osa neist on endiselt otse HTTP kaudu kättesaadavad, ja ründaja skript peab teadma ainult teed. Wordfence dokumenteeris 2021. aasta juunis pistikprogrammis Fancy Product Designer aktiivselt ärakasutatava nullpäeva turvanõrkuse, mis Wordfence'i enda kirjelduse järgi oli mõnes konfiguratsioonis ärakasutatav ka siis, kui pistikprogramm oli deaktiveeritud, ja soovitas selle mitte välja lülitada, vaid täielikult eemaldada. Kui pistikprogrammi teil enam vaja ei ole, ei ole selle koht pistikprogrammide loendis halli värvi, vaid väljaspool serverit.

Miks see kõik toimub automaatselt ja ilma igasuguse isikliku põhjuseta, seletab mastaap: W3Techsi andmetel töötab 2026. aasta 5. augustil WordPressil 41,2% kõigist veebisaitidest. Sellise mahuga ökosüsteemis on iga avalikustatud pistikprogrammi turvanõrkus kohe kasutatav väga suure hulga ühtmoodi ehitatud veebilehtede vastu, mistõttu on rünnakut kasulikum automatiseerida kui sihtida — skript vaatab versiooninumbreid, mitte ettevõtete nimesid. Keegi ei ole valinud just teie veebilehte, ja just seepärast häkitakse väike tutvustusleht ilma kliendiandmete ja makseteta sama rahulikult ära nagu suur e-pood.

Kuhu ründaja WordPressi installatsioonis koodi peidab

Esimene koht, mille me avame, on wp-content/uploads — kaust, kus on sisuliselt ainult pildid, PDF-failid ja videod ning kus ei peaks kunagi käivituma ükski PHP-fail. Kui seal 2019. aasta tootefotode vahel lebab .php-laiendiga fail, ei ole see sinna juhuslikult sattunud: peaaegu alati on tegu kas üleslaadijaga, millega ründaja järgmised failid serverisse toob, või veebikestaga (web shell), mis lubab teie serveri nimel käske käivitada. Et probleem on päris, mitte teoreetiline, näitab juba seegi, et nii Sucuri kui ka Wordfence pakuvad eraldi turvamissätet, mis .htaccess-reegliga lülitab just selles kaustas PHP-mootori välja.

Teine koht on wp-content/mu-plugins. Sinna pandud pistikprogrammid aktiveeruvad automaatselt, neid ei saa haldusliidesest deaktiveerida ja — mis on siin kõige tähtsam — need ei ilmu tavalisse pistikprogrammide loendisse, mistõttu veebilehe omanik võib kuude kaupa vaadata näiliselt puhast liidest; Sucuri kirjeldas 2025. aasta juulis just säärast juhtumit tagauksega selles kaustas. Selle kõrval kontrollime alati .htaccess-faile nii juurkataloogis kui ka alamkaustades, sest ümbersuunamine, mis käivitub ainult otsingumootorist tulnud külastajatel või ainult mobiilseadmetes, on kõige sagedamini sinna kirjutatud — ja see ongi põhjus, miks te oma veebilehte täiesti normaalsena näete.

Koodi kirjutatakse ka olemasolevate, täiesti legitiimsete failide esimestele ridadele, kõige sagedamini wp-config.php algusesse ja teema functions.php-faili, ja see ei näe peaaegu kunagi välja nagu pahatahtlik kood: see on üks pikk rida base64_decode-, gzinflate- või eval-väljakutsega, mille järel tuleb sadu tühje ridu, et redaktoris paistaks, nagu oleks fail otsa saanud. Seepärast on failide võrdlemine puhta originaaliga väärtuslikum kui silmaga lugemine: silmaga ei leia seda rida keegi, sest keegi ei keri faili üheksasajanda reani.

Ja siis on andmebaas, kuhu failiskanner ei vaata ja kus kontrollida tuleb kolme kohta: wp_options read siteurl ja home, mille ründaja üle kirjutab, et teie lehe ressursid laaditaks võõrast serverist; tabel wp_users, kuhu ilmub sageli usutava nimega administraatorikonto; ja kirjete sisu tabelis wp_posts, kus peidetud lingid ja iframe-koodid on ehitatud vanade postituste keskele, mida keegi enam ei ava. Kui failid puhastatakse, aga andmebaasi süstitud kood jääb alles, tuleb nakkus tagasi juba samal päeval. Rida ise ei käivitu — igal laadimisel loeb ja käivitab selle väike laadija teema functions.php-failis või mu-plugins-kaustas —, ja just see paar taastab kustutatud failid kiiremini, kui te tulemust kontrollida jõuate. Just seepärast ongi häkitud veebilehe taastamisel failide ja andmebaasi puhastamine meil üks töö, mitte kaks.

Failide võrdlemine kontrollitud originaalidega

Esimene tööriist, mille me pärast täieliku faili- ja andmebaasikoopia kindlustamist kätte võtame, on wp core verify-checksums: see võrdleb iga faili räsi WordPress.org-i avaldatud kontrollsummadega ja näitab kohe, millised failid on muudetud ja milliseid installatsioonis üldse ette nähtud ei ole. Probleem algab seal, kus lõpeb selle ulatus — käsk kontrollib ainult katalooge wp-admin/ ja wp-includes/ ning juurkataloogi wp-*-faile, kogu wp-content-kausta, seega pistikprogrammid, teemad ja üleslaadimised, jätab lähtekood teadlikult vahele (WP-CLI checksum-command lähtekood, vaadatud 2026. aasta 5. augustil). Ühe juurkataloogi faili jätab seesama lähtekood eraldi välja — wp-config.php —, mistõttu fail, mille esimestele ridadele koodi kõige sagedamini kirjutatakse, sellele kontrollile ei paista. Käsu puhas tulemus ei tähenda puhast veebilehte.

Pistikprogrammide jaoks on olemas eraldi käsk wp plugin verify-checksums, kuid ka see võrdleb faile ainult WordPress.org-i repositooriumi kontrollsummadega, mistõttu arendajalt ostetud kommertspistikprogramm jäetakse kontrollist lihtsalt välja; teemade jaoks samaväärset käsku WP-CLI dokumentatsioonis üldse ei ole (WP-CLI dokumentatsioon, vaadatud 2026. aasta 5. augustil). Automaatsele kontrollile ei allu seega ei teemad ega väljaspool repositooriumi ostetud pistikprogrammid, ja wp core verify-checksums jätab vahele kogu wp-content — selle koodiosa, kus tekkisid kõik 11 334 Patchstacki 2025. aastal kokku loetud turvanõrkust peale tuuma kuue. Veebilehtedel, mille me üle võtame, on just teema tihti ainus asi, mida keegi kunagi kontrollinud ei ole.

Meie praktikas on kontrollsummad seepärast lähtepunkt, mitte meetod: tuuma ja pistikprogramme me ei ravi, vaid asendame, see tähendab laadime samad versioonid originaalallikast alla ja kirjutame kaustad tervikuna üle, mitte faili kaupa. Vanast installatsioonist jätame alles wp-content/uploads, ja sedagi alles pärast kontrolli, kas piltide seas PHP-faile ei ole — samal põhjusel, mille pärast tasub PHP-mootor selles kaustas üldse välja lülitada. Teema taastame versioonihaldusest, kui see olemas on; kui ei ole, võtame arendaja tarnitud koopia ja paneme kohandused teadlikult peale, ükshaaval, sest ainult nii saab hiljem öelda, milline rida veebilehel on meie oma ja milline mitte.

Selle ühe halva rea ülesotsimine ja kustutamine tundub odavam, ja just seepärast on see kõige sagedamini korduv viga: ründaja jätab harva maha ainult ühe sissepääsu, ja üks märkamata jäänud tagauks muudab kogu ülejäänud töö asjatuks. Kood on sageli jaotatud mitme faili vahel, peidetud base64- või gzinflate-väljakutse taha, kirjutatud andmebaasi options-tabelisse või pandud sedasama mu-plugins-kausta, mida haldusliides ei näita. Mustri järgi otsimine leiab selle, mida te juba tunnete; täielik asendamine vabastab ka sellest, mida te ei tunne.

On ka töö, mida me selles etapis ei tee: me ei looda pistikprogrammile, mis pakub nakatunud failid ühe nupuvajutusega "terveks ravida", sest see töötab sellesama teadaolevate mustrite loendiga ja pealegi sellessamas keskkonnas, kus ründajal on endiselt ligipääs. Me ei võrdle faile käsitsi ka siis, kui veebileht on tavalise visiitkaardi või blogi mahus, sest värske paigaldus ülekantud sisuga nõuab vähem tunde kui kahe kataloogi rea-realt võrdlemine, ja tulemus on kontrollitav. Hoolikas käsitsi võrdlemine on omal kohal seal, kus teema või pistikprogramm on ainulaadne ja versioonihaldust ei ole; kuidas varukoopiatega ümber käia, et see valik üldse olemas oleks, oleme kirjeldanud üldises taastamisjuhendis.

Võtmed, seansid ja paroolid: mis mida tegelikult teeb

Autentimisvõtmed ja soolad (security keys and salts) failis wp-config.php ei krüpteeri midagi, kuigi nii väidab peaaegu iga juhend: WordPress kasutab neid alusena võtmele, millega funktsioon wp_generate_auth_cookie() allkirjastab autentimisküpsise HMAC-SHA256-ga, küpsis ise on aga avatekst kasutajanime, kehtivusaja ja seansimarkeriga (WordPress Developer Resources, vaadatud 2026. aasta 5. augustil). Seepärast ei ole pärast nende väärtuste vahetamist ükski varem väljastatud allkiri enam kontrollitav ja server lükkab tagasi iga seni väljastatud küpsise, isegi kui seanss ise formaalselt veel lõppenud ei ole.

Praktiline tagajärg on täpselt see, mida häkkimise hetkel vaja on: WordPressi ametlik dokumentatsioon kirjeldab võtmete vahetamist kui viisi, kuidas visata välja kõik, kes veel sisse logituna olla võiksid (WordPress.org, "FAQ My site was hacked", uuendatud 2026. aasta 26. juulil), ehk kui ründajal on käes kehtiv seanss, lõpeb see samal hetkel. Koos seanssidega kaotavad kehtivuse ka kõik väljastatud nonce-markerid, mistõttu poolelolevad vormid ja poolel teel olevad tellimussammud katkevad sel hetkel — vahetuse hetke valime teadlikult, mitte juhuslikult keset tööpäeva.

Võtmete ja soolade vahetamine ei muuda ühtegi parooli. Paroolide räsid loob WordPress bcryptiga ja iga parooli jaoks eraldi juhusliku soolaga, mis wp-config.php konstantidega seotud ei ole (funktsioon wp_hash_password(); bcrypt on vaikimisi alates WordPress 6.8-st), mistõttu ründaja, kes teab administraatori parooli või on jõudnud endale konto luua, logib pärast võtmete vahetust lihtsalt uuesti sisse. Paroole vahetatakse eraldi ja kõiki, ka neid, mida justkui keegi ei tea, ning ühtlasi tuleb käia läbi kasutajate loend ja otsida kontosid, mida keegi teie meeskonnast ei ole loonud.

WordPressiga juurdepääsuandmete loend ei lõpe: ühe korraga vahetatakse majutuse juhtpaneeli parool, FTP- ja SFTP-pääsuandmed, andmebaasi kasutaja parool koos vastava kirjega failis wp-config.php, samuti SSH-võtmed, mida ei vahetata parooli põhimõttel, vaid genereeritakse uuesti, kustutades serveri failist authorized_keys vana avaliku võtme. Lõpuks vahetatakse kõik veebilehel hoitavad API-võtmed — makselahenduse, e-posti saatmise teenuse, tarne- ja raamatupidamisintegratsioonide omad —, sest just need jäävad tavaliselt kõige kauemaks puutumata: neid ei näe igapäevaselt keegi ühelgi ekraanil.

Eeldage, et ründajal on täielik andmebaasi koopia, sest see on kogu rünnaku odavaim samm: kõik, mis andmebaasis on olnud — klientide e-posti aadressid, tellimuste ajalugu, paroolide räsid ja pistikprogrammide sätetesse kirjutatud võtmed —, tuleb lugeda võõrastesse kätesse sattunuks. Kui mõnda neist paroolidest on kasutatud veel kusagil, on kompromiteeritud ka see koht, ja tavaliselt on see hetk, mil jutt liigub veebilehelt e-posti kontodele, raamatupidamissüsteemile ja poe maksekontole.

Järjekord on sama tähtis kui loend ise: võtmeid ja paroole vahetatakse pärast seda, kui tagauksed on eemaldatud, sest vastasel juhul loeb ründaja uued väärtused sealtsamast wp-config.php-failist või lihtsalt püüab kinni järgmise sisselogimise. Kõigepealt täielik koopia, siis põhjus, siis puhastamine ja alles päris lõpuks juurdepääsuandmed — just selle järjekorra peal jääb omal käel alustatud taastamine kõige sagedamini toppama või läheb sassi, mistõttu võtame selle etapi enda peale ja anname lõpus üle kirjaliku aruande selle kohta, mis, millal ja miks muudeti.

Kuidas saada Google'i hoiatus kaduma ja mida teha pärast

Search Console'i turvaprobleemide aruanne, mis eestikeelse liideseta tööriistas kannab nime "Security Issues", on ainus koht, kus näeb, mida täpselt Google teie veebilehel leidnud on: seal on kirjas ohu liik ja näidis konkreetsetest mõjutatud lehtedest, ja sellest sõltub ka see, mida külastaja praegu näeb. Ohu liik ei muuda seda, mida külastaja näeb: Chrome ei vali hoiatuse pealkirja enam selle järgi, kas tuvastati andmepüük, pahavara või soovimatu tarkvara, vaid kuvab kõigil juhtudel ühte ja sama täisekraanihoiatust — eesti keeles "Ohtlik sait" —, mis inimest veebilehele lihtsalt sisse ei lase. Juba mainitud märkus saidi võimaliku häkkimise kohta on aga üksnes kiri lingi kõrval, millest saab läbi klõpsata (Google Chrome'i abileht ohtlike saitide kohta, kontrollitud 2026. aasta augustis). Vanemaid, ohu liigi järgi erinevaid pealkirju — näiteks "Deceptive site ahead" — Chrome enam ei kasuta, kuigi Google'i dokumentatsioonis on need kohati endiselt alles. Esimene blokeerib, teine hoiatab, ja see muudab, kui palju aega teil tegelikult on.

Enne nupu "Request Review" vajutamist tuleb veenduda, et veebileht on tõesti puhas, mitte ainult näib teie brauseris puhas. Google hoiatab oma cloaked keywords hacki juhendis otse, et ründajad püüavad jätta muljet, nagu oleks leht juba kustutatud või parandatud, mistõttu tuleb iga endine rämpsleht üle kontrollida URL-i kontrollimise tööriistaga, mis näitab Googleboti vaadet, mitte teie oma. Teine samm, mis kõige sagedamini vahele jääb, on omanike loend: Japanese keyword hacki puhul lisab ründaja end Search Console'i kinnitatud omanikuks (Google'i dokumentatsioon saidil web.dev), ja kuni teda sellest loendist eemaldatud ei ole, teab ta veebilehe seisust täpselt sama palju kui teie.

Otsitav nupp on turvaprobleemide aruande "Request Review", mitte "reconsideration request", mille Google seob käsitsi rakendatud meetmetega, ja taotluse teksti tasub kirjutada kolm asja: mis leiti, kuidas ründaja sisse pääses ja mida konkreetselt on selle kõrvaldamiseks tehtud. Tähtaega me ei luba, sest ei luba ka Google: selle sotsiaalset manipuleerimist käsitlev dokumentatsioonileht ütleb, et ülevaatamine võib võtta mitu päeva, Search Console'i turvaprobleemide abileht aga nimetab ajavahemikuks mõnest päevast mõne nädalani (mõlemad kontrollitud 2026. aasta augustis). Kui keegi nimetab teile konkreetsed 24 või 72 tundi, kordab ta arvu, mida üheski Google'i allikas ei ole.

Kiirustamine maksab selles sammus rohkem kui ootamine. Samas Google'i ja California ülikooli (Berkeley) uuringus saavutas 80% veebilehtede omanikest oma lehe puhtaks tunnistamise juba esimesel katsel, ülejäänud 20% vajasid mitut katset, ja mediaanaeg, mille nad ründaja jäetud koodi väljakammimisele kulutasid, oli terve nädal. Andmed on aastatest 2014–2015 ja nii tulebki neid lugeda, aga aritmeetika ei ole muutunud: tagasi lükatud taotlus tähendab, et hoiatus jääb veel üheks tsükliks, ja teist korda ei ole te enam esmakordne esitaja.

Kui hoiatus on eemaldatud, ei ole töö veel läbi, sest indeksisse jäävad ründaja loodud lehed, ja neid ei tohi avalehele ümber suunata — need peavad tagastama 404 või 410, et Google need päriselt välja viskaks, samal ajal kui Search Console'i eemaldamistööriist üksnes peidab need ajutiselt. Positsioonid ei tule tagasi ühe nupuvajutusega: lehed tuleb uuesti indekseerida ja see toimub Google'i, mitte teie tempos. Kuidas selles etapis logifaile ja varukoopiaid kasutada, et järgmine kord oleks lähtepunkt parem, oleme kirjeldanud eraldi juhendis häkitud veebilehtede taastamisest.

Millal lõpetada omal käel tegemine ja kui palju see maksab

Osa siin kirjeldatust teeb kogenud veebilehe omanik ise ära, ja me ütleme seda otse ka inimestele, kes helistavad meile avatud Search Console'i ja juba leitud süüdlasest pistikprogrammiga. Kui nakkus on üks rikutud avaleht, kui logifailidest on näha, milline pistikprogramm selle sisse lasi, kui kasutajate loendis võõraid administraatoreid ei ole ja kui on olemas eilne varukoopia, mille te kunagi päriselt testkeskkonnas taastanud olete, siis ostab kaheksa tasutud tundi teile rahulikuma une, mitte kiirema tulemuse.

On neli olukorda, kus me soovitame peatuda, ja esimene on korduv nakatumine pärast puhastamist: kui veebileht häkitakse teist korda, ei ole see ebaõnne küsimus, vaid tõend, et sissemurdmiskoht on endiselt lahti, ja kolmas puhastamine samas keskkonnas maksab täpselt sama palju kui kaks esimest. Teine on igasugune kahtluse vari kliendi- või makseandmete kohta, sest seal tekivad tehnilise töö kõrvale ka kohustused järelevalveasutuse ees ja tähtajad, mida hea tahtega pikendada ei saa. Kolmas on veebileht, millelt ettevõte iga päev teenib, ja neljas — lihtsalt ajapuudus: puhastamine ei ole intellektuaalselt keeruline, aga see on pikk, üksluine ja ei andesta ühtegi vahele jäänud faili.

Meie häkitud veebilehtede taastamine maksab 90 € tunnis ilma käibemaksuta, miinimumiga kaheksa töötundi, mis tasutakse ette. Töö alustame tavaliselt mõne tunni jooksul pärast pöördumist ja kogu protsess algusest üleandmiseni võtab tavaliselt 8–72 tundi, kusjuures vahe kaheksa ja seitsmekümne kahe tunni vahel on peaaegu alati selles, kui sügavale ründaja end sisse seada jõudis ja kui vana on viimane puhas koopia. Miinimum ei ole turundusarv: täielik koopia, põhjuse otsimine logifailidest, puhastamine ja kontroll mahuvad lühemasse aega harva.

Kord on seesama, mis eespool kirjeldatud, ainult ilma teie nädalavahetuseta. Enne kui me midagi puudutame, võtame täieliku faili- ja andmebaasikoopia, et intsidenti oleks hiljem üldse võimalik uurida, ja alles siis veebileht isoleeritakse; edasi puhastatakse see pahavarast ja tagaustest, andmebaas kontrollitakse üle, juurdepääsuandmed ja võtmed vahetatakse, sissemurdmise põhjus leitakse ja suletakse, Google'ile esitatakse ülevaatustaotlus ja seadistatakse seire, lõpuks saate aga kirjaliku aruande juhtunust ja sellest, mida muudeti. Kui veebileht praegu ei tööta või te ei ole kindel selles, mida näete, võite tellida kiire veebilehe kontrolli, ja me ütleme, kas siin on üldse midagi, mille eest maksta.

Paljudel juhtudel ei ole õige vastus siiski taastamine, vaid see, mis pärast seda toimub: kui veebilehele on kogunenud kakskümmend pistikprogrammi, millest pooltel ei mäleta keegi enam põhjust, siis on probleem hoolduses, ja seda lahendab WordPressi veebiarendus ja hooldus, mitte veel üks puhastustsükkel poole aasta pärast. Kogu selle loo odavaim tund on see, mis kulutatakse ette: kasutuseta pistikprogrammi kustutamine kaustast wp-content/plugins, mitte selle deaktiveerimine, ja varukoopia, mille keegi on kunagi päriselt testkeskkonnas taastanud, maksavad kokku vähem kui üks meie tööpäev.