Uzlauzta WordPress mājaslapa: ko darīt soli pa solim

Sarkans brīdinājums Chrome, pāradresācija uz svešu domēnu un administrācijas panelis, kurā viss izskatās kā vienmēr. Ārkārtas gaita tieši WordPress vietnei: ko nedrīkst darīt pirmajā stundā, kur infekcija patiesībā slēpjas un kā tikt vaļā no Google brīdinājuma.

Ceturtdienas rītā zvana klients un saka, ka Chrome viņa ekrānā jūsu veikala vietā rāda sarkanu pilnekrāna brīdinājumu; jūs atverat vietni telefonā, un pārlūks pēc pusotras sekundes aizmet uz pavisam svešu domēnu, bet darba datorā, kurā administrācijas panelis ir atvērts jau kopš pirmdienas, viss izskatās tieši tāpat kā vienmēr. Tieši tā visbiežāk izskatās uzlauzta WordPress mājaslapa — nevis sabojāta sākumlapa ar uzbrucēja parakstu, bet vietne, kas īpašniekam rāda vienu seju un apmeklētājam otru, tāpēc pirmās stundas mēdz paiet, strīdoties par to, vai problēma vispār pastāv.

Jautājumi, uz kuriem šeit ir atbilde, parasti tiek uzdoti tieši šādā secībā: ko drīkst un ko nedrīkst darīt pirmajā stundā, kamēr vēl nav zināms, cik dziļi uzbrucējs ir ticis; kur tieši WordPress instalācijā kods mēdz būt paslēpts, jo bez tā tīrīšana ir minēšana; un kā panākt, lai Google noņem brīdinājumu, nesabojājot sev otro mēģinājumu. Pa vidu paliek tas, ko īpašnieki izlaiž visbiežāk — piekļuves datu nomaiņa pareizajā brīdī un pareizajā secībā.

Viss, kas jādara tuvākajās stundās, ir šeit, un pa vidu nekur citur nebūs jāiet. Ārpus raksta paliek tikai tas, kas noder pēc tam, kad vietne jau atkal strādā — dublējumkopiju stratēģija, sistēmas nostiprināšana un aizsardzība pret nākamo reizi, kas ir vienāda neatkarīgi no platformas —, un atsevišķu ceļvedi par to norādām tālāk. Runa ir par to, kas WordPress padara atšķirīgu: spraudņu ekosistēmu, mapi wp-content, datubāzes tabulām, kurās infekcija pārdzīvo failu tīrīšanu, un komandām, kas sola vairāk, nekā patiesībā pārbauda. Mūsu praksē tieši šīs četras lietas izšķir, vai vietne ir tīra pēc vienas dienas vai pēc trešā mēģinājuma.

Pirmā stunda: nedzēsiet neko

Pirmā reakcija gandrīz vienmēr ir viena no divām — atvērt hostinga failu pārvaldnieku, atrast tur kaut ko svešu un to izdzēst, vai arī nospiest pogu, kas atjauno vakardienas dublējumkopiju. Mēs lūdzam neizdarīt ne vienu, ne otru, un tam ir praktisks, nevis birokrātisks iemesls. Steiga ir saprotama, jo katra stunda ar sarkano brīdinājumu maksā apmeklētājus, taču tieši steigā tiek pieņemti tie divi lēmumi, kas atkopšanu no astoņām stundām pagarina līdz nedēļai, un abi ir neatgriezeniski.

Kad inficētie faili ir izdzēsti, pazūd arī vienīgais materiāls, pēc kura vēlāk nosaka ielaušanās punktu: failu izmaiņu laiki, uzbrucēja augšupielādēto skriptu saturs un servera piekļuves žurnāla ieraksti, kas ar šiem laikiem sakrīt. Bez ielaušanās punkta tīrīšana ir tikai simptomu noņemšana, un cena par to ir izmērīta — Google un Kalifornijas Universitātes (Bērklijā) pētījumā par 760 935 uzlaušanas gadījumiem laikā no 2014. gada jūlija līdz 2015. gada jūnijam 12 % vietņu 30 dienu laikā tika uzlauztas atkārtoti, jo bija novērsti tikai simptomi, nevis cēlonis (Li u.c., WWW 2016).

Tāpēc pirmais darbs ir pilna kopija — visi faili un visa datubāze vienā piegājienā, pirms tiek aizskarts kaut viens baits, jo redzamā pāradresācija vai sabojātā sākumlapa reti ir viss, kas vietnē notiek: pēc Sucuri datiem 2023. gadā 49,21 % inficēto vietņu tika atrastas vismaz vienas aizmugures durvis (backdoor), un gada laikā to komanda izņēma 21 062 šādas programmas (Sucuri, "2023 Hacked Website & Malware Threat Report", 2024. gada jūnijs). Kopiju glabājiet ārpus tā paša servera, jo tieši tur uzbrucējam joprojām ir piekļuve.

Nākamais zvans ir hostinga pakalpojumu sniedzējam, un ne pieklājības pēc: viņiem ir piekļuves žurnāli, kas jūsu kontā parasti ir redzami tikai dažas dienas atpakaļ, un koplietošanas serverī viņiem ir jāpārbauda, vai blakus kontos nenotiek tas pats. Ja vietnē tiek pieņemti maksājumi vai ievadīti personas dati, tā šajā brīdī ir jāizslēdz vai jāieslēdz uzturēšanas režīms — katrs apmeklētājs, kurš nākamajā stundā ievada kartes datus, ir atsevišķa problēma, kuras jums vēl nav. Uzturēšanas režīms maksā vienu dienu apgrozījuma; nokavēts brīdis maksā vēstuli klientiem.

Ja wp-admin vairs neatveras — uzlauztā vietnē tā mēdz notikt —, uzturēšanas režīmu no paneļa ieslēgt neizdosies, un paliek divi ceļi: vietnes saknes .htaccess failā pieliek noteikumu, kas visus, izņemot jūsu IP adresi, aizsūta uz vienu statisku lapu ar paziņojumu par tehniskiem darbiem, vai tajā pašā sarunā lūdz hostingam kontu uz laiku apturēt. Otrais variants izskatās rupjš, bet nostrādā arī tad, ja failiem vairs netiekat klāt.

Vakardienas dublējumkopija izskatās pēc ātrākā ceļa atpakaļ, un reizēm tas tiešām ir pareizais solis, taču tikai tad, ja ir zināms, kurā dienā uzbrucējs iekļuva. Mūsu praksē infekciju pamana krietni vēlāk, nekā tā sākusies — vispirms kods kādu laiku klusē, tad sāk rādīt surogātlapas vai pāradresācijas —, un tas nozīmē, ka vakardienas kopijā aizmugures durvis visdrīzāk jau ir iekšā. Atjaunošana tādā gadījumā uz pāris stundām noslēpj simptomus un atgriež vietni tieši tajā stāvoklī, kurā to reiz uzlauza, tāpēc uzlauztas vietnes atkopšanu mēs parasti uzsākam dažu stundu laikā un arī steigā sākam ar kopiju, nevis ar dzēšanu, pat tad, kad klients zvana un lūdz vienkārši ātri visu notīrīt.

Pazīmes, pēc kurām atpazīt uzlauztu WordPress mājaslapu

Pāradresācija, kas nostrādā apmeklētājam, kurš atnācis no Google rezultāta, bet nenostrādā, kad adresi ieraksta pārlūka joslā, nav pārpratums, bet uzbrucēja apzināta izvēle: Google surogātsatura politikās pāradresācijas ir atsevišķi nosaukts uzlauzta satura veids, kurā uzbrucēji ievada kodu, kas "daļu lietotāju pāradresē uz kaitīgām vai surogātlapām" (Google Search Central, pārbaudīts 2026. gada augustā). Vārds "daļu" ir tas, kas maldina īpašnieku. Pārbaude aizņem minūti: atveriet vietni inkognito logā, tad atrodiet to Google rezultātos un atveriet no turienes, un pēc tam abas reizes atkārtojiet telefonā.

Otra pazīmju grupa ir administrācijas pusē un daudz konkrētāka: wp-admin pēkšņi atgriež 404, pieteikšanās forma pēc pareizas paroles vienkārši ielādējas no jauna, lietotāju sarakstā ir administratora konts, ko neviens no jūsu komandas nav veidojis, vai arī sadaļā Iestatījumi → Vispārīgie vietnes adrese vairs nav jūsu. Datubāzē pēdējā no šīm pazīmēm ir tikai divas rindas tabulā wp_options — siteurl un home —, un tieši tāpēc adrese, ko redzat iestatījumos, un adrese, uz kuru nonāk apmeklētājs, var atšķirties.

Trešā grupa nāk no malas un ir vissāpīgākā, jo par vietnes stāvokli jums pasaka kāds cits: hostinga uzņēmums bez brīdinājuma aptur kontu, no kura izgājis surogātpasts, Search Console parādās ieraksts par drošības problēmu, vai arī meklēšanas rezultātos blakus vietnei parādās atzīme "This site may be hacked", ko Google rāda, ja uzskata, ka uzbrucējs ir mainījis esošās lapas vai pievienojis jaunas surogātlapas (Google Search Help, pārbaudīts 2026. gada augustā). Šo atzīmi Google pieliek pats, nevis pēc kāda sūdzības, un tā parādās arī tad, kad vietne jums pašam izskatās nevainojama.

Nosaukumi šeit nav akadēmisks jautājums, jo pēc tiem jūs meklēsiet risinājumu un vērtēsiet, vai izpildītājs saprot jūsu gadījumu: Google savā dokumentācijā nosauc trīs — gibberish hack, Japanese keyword hack un cloaked keywords and links hack, kurā uzbrucēja izveidotās lapas meklētājprogrammai rāda vienu saturu, bet apmeklētājam citu. Nozarē populārais "pharma hack" nāk no drošības uzņēmuma Sucuri (2020), un Google dokumentācijā tā nav. Praktiskā pārbaude tomēr ir viena visiem trim: ievadiet meklētājā site: vaicājumu ar savu domēnu, un lapas, kuras neviens jūsu uzņēmumā nav rakstījis, redzēsiet uzreiz. Japāņu variantā tās ir automātiski ģenerētas lapas ar japāņu valodas virsrakstiem nejauši nosauktās mapēs un jūsu domēnu adresē.

Un tagad nepatīkamā daļa: tīrs skenējuma rezultāts nepierāda, ka vietne ir tīra, jo skeneris redz tikai to, ko serveris tam parāda, bet uzbrucēja kods bieži atpazīst skenerus un meklētājprogrammas, un Google savā ceļvedī par maskētajām atslēgvārdu lapām brīdina, ka uzlaušana mēdz tikt slēpta tā, lai īpašniekam liktos, ka problēma jau ir pagājusi. Ja skenējums ir tīrs, bet hostings sūdzas par izejošo pastu, ticiet hostingam. Tad ir vietā drošības audits ar failu un žurnālu pārbaudi rokām, jo skeneris atbild uz jautājumu, vai vietnē ir kaut kas no zināmo paraugu saraksta, nevis uz to, vai vietnē kāds joprojām ir.

Kur WordPress risks patiesībā atrodas

Mūsu praksē, kad cēlonis beidzot atrodas, tas gandrīz nekad nav pats WordPress kodols. Patchstack pārskatā "State of WordPress Security in 2026" ir saskaitītas 11 334 jaunas ievainojamības, kas WordPress ekosistēmā atklātas 2025. gadā — par 42 % vairāk nekā gadu iepriekš —, un tieši šo skaitļu sadalījums ir tas, kas jums šobrīd ir svarīgs: 91 % no tām attiecās uz spraudņiem, 9 % uz tēmām, bet pašā WordPress kodolā visa gada laikā tika ziņots tikai par sešām, turklāt visas bija zemas prioritātes. Gandrīz katra jaunatklātā ievainojamība tātad ir nevis tajā WordPress, ko jūs kādreiz uzstādījāt, bet tajā, ko tam gadu gaitā ir pielicis klāt.

Katrs spraudnis ir atsevišķa koda bāze, ko raksta atsevišķs autors ar atsevišķu — un diezgan bieži jau pārtrauktu — atjaunināšanas disciplīnu, tāpēc vietne ar četrdesmit spraudņiem nav vietne ar vienu drošības jautājumu, bet vietne ar četrdesmit savstarpēji neatkarīgiem drošības jautājumiem. Mūsu praksē tipiska uzņēmuma vietne pilnībā iztiek ar desmit līdz piecpadsmit spraudņiem, un pārējie tur parasti ir palikuši no sen aizmirstiem uzdevumiem: galerijas, ko vairs nerāda, formas, kas aizstāta ar citu, slaidera, kuru pašreizējais dizains vairs neizmanto. Kad mēs pārņemam WordPress vietnes izstrādi un uzturēšanu, spraudņu skaita samazināšana ir pirmais darbs, nevis pēdējais.

Un šeit ir kļūda, kas atkārtojas biežāk par jebkuru citu: nevajadzīgais spraudnis tiek deaktivizēts, nevis izdzēsts — deaktivizēšana pasaka WordPress, lai to vairs neielādē, taču faili paliek serverī savā vietā, daļa no tiem joprojām ir sasniedzama tieši pa HTTP, un uzbrucēja skriptam pietiek zināt ceļu. Wordfence 2021. gada jūnijā dokumentēja aktīvi izmantotu nulles dienas ievainojamību spraudnī Fancy Product Designer, kura "dažās konfigurācijās ir izmantojama arī tad, ja spraudnis ir deaktivizēts", un ieteica to nevis atslēgt, bet pilnībā atinstalēt. Ja spraudnis jums vairs nav vajadzīgs, tā vieta nav spraudņu sarakstā pelēkā krāsā, bet ārpus servera.

Kāpēc tas viss notiek automātiski un bez jebkāda personiska iemesla, izskaidro mērogs: pēc W3Techs datiem 2026. gada 5. augustā WordPress darbina 41,2 % no visām tīmekļa vietnēm. Šāda apjoma ekosistēmā katra publiskota spraudņa ievainojamība uzreiz ir izmantojama pret ļoti lielu skaitu vienādi uzbūvētu vietņu, tāpēc uzbrukumu ir izdevīgāk automatizēt, nevis mērķēt — skripts izskata versiju numurus, ne uzņēmumu nosaukumus. Neviens nav izvēlējies tieši jūsu vietni, un tieši tāpēc arī neliela prezentācijas lapa bez klientu datiem un bez maksājumiem tiek uzlauzta tikpat mierīgi kā liels interneta veikals.

Kur uzbrucējs paslēpj kodu WordPress instalācijā

Pirmā vieta, ko mēs atveram, ir wp-content/uploads — mape, kurā pēc būtības atrodas tikai attēli, PDF faili un video un kurā nekad nevajadzētu izpildīties nevienam PHP failam. Ja tur starp 2019. gada produktu fotogrāfijām guļ fails ar paplašinājumu .php, tas nav nokļuvis nejauši: gandrīz vienmēr tas ir vai nu augšupielādētājs, ar kuru uzbrucējs ieved serverī nākamos failus, vai čaula, kas ļauj izpildīt komandas jūsu servera vārdā. Ka problēma ir reāla, nevis teorētiska, redzams jau no tā, ka gan Sucuri, gan Wordfence piedāvā atsevišķu nostiprināšanas iestatījumu, kas ar .htaccess noteikumu izslēdz PHP dzinēju tieši šajā mapē.

Otra vieta ir wp-content/mu-plugins. Tur ievietotie spraudņi tiek aktivizēti automātiski, tos nav iespējams deaktivizēt no administrācijas paneļa un — kas šajā gadījumā ir svarīgākais — tie neparādās parastajā spraudņu sarakstā, tāpēc vietnes īpašnieks var mēnešiem skatīties uz šķietami tīru paneli; Sucuri 2025. gada jūlijā aprakstīja tieši šādu gadījumu ar aizmugures durvīm šajā mapē. Blakus tam mēs vienmēr pārbaudām .htaccess gan saknē, gan apakšmapēs, jo pāradresācija, kas nostrādā tikai apmeklētājiem no meklētājprogrammas vai tikai mobilajās ierīcēs, visbiežāk ir ierakstīta tur — un tā ir iemesls, kāpēc jūs savu vietni redzat pilnīgi normālu.

Kods mēdz būt ierakstīts arī esošu, pilnīgi likumīgu failu pirmajās rindās, visbiežāk wp-config.php sākumā un tēmas functions.php failā, un tas gandrīz nekad neizskatās pēc ļaunprātīga koda: tā ir viena gara rinda ar base64_decode, gzinflate vai eval izsaukumu, aiz kuras seko simtiem tukšu rindu, lai redaktorā šķistu, ka fails ir beidzies. Tāpēc failu salīdzināšana ar tīru oriģinālu ir vērtīgāka par lasīšanu ar aci: ar aci šo rindu neatrod neviens, jo neviens neritina failu līdz deviņsimtajai rindai.

Un tad ir datubāze, kur failu skeneris neskatās un kur pārbaudāmas ir trīs vietas: wp_options rindas siteurl un home, kuras uzbrucējs pārraksta, lai jūsu lapas resursi tiktu ielādēti no sveša servera; tabula wp_users, kurā mēdz parādīties administratora konts ar ticamu vārdu; un ierakstu saturs wp_posts, kur slēptas saites un iframe kodi tiek iebūvēti vecu rakstu vidū, ko neviens vairs neatver. Ja faili tiek iztīrīti, bet injekcija datubāzē paliek, infekcija atgriežas tajā pašā dienā. Pati rinda neizpildās — to katrā ielādē nolasa un palaiž neliels ielādētājs tēmas functions.php failā vai mu-plugins mapē —, un tieši šis pāris atjauno izdzēstos failus ātrāk, nekā jūs paspējat pārbaudīt rezultātu. Tieši tāpēc uzlauztas vietnes atkopšanā failu un datubāzes tīrīšana mums ir viens darbs, nevis divi.

Failu salīdzināšana ar pārbaudītiem oriģināliem

Pirmais rīks, ko paņemam pēc tam, kad pilna failu un datubāzes kopija ir nodrošināta, ir wp core verify-checksums: tā salīdzina katra faila jaucējvērtību ar WordPress.org publicētajām kontrolsummām un uzreiz parāda, kuri faili ir mainīti un kuri instalācijā vispār nav paredzēti. Problēma sākas tur, kur beidzas tās tvērums — komanda pārbauda tikai wp-admin/, wp-includes/ un saknes wp-* failus, bet visu wp-content mapi, tātad spraudņus, tēmas un augšupielādes, pirmkods apzināti izlaiž (WP-CLI checksum-command pirmkods, skatīts 2026. gada 5. augustā). Vienu saknes failu tas pats pirmkods izslēdz atsevišķi — wp-config.php —, tāpēc fails, kura pirmajās rindās kodu ieraksta visbiežāk, šai pārbaudei nav redzams. Tīrs komandas rezultāts nenozīmē tīru vietni.

Spraudņiem pastāv atsevišķa komanda wp plugin verify-checksums, taču arī tā salīdzina failus tikai ar WordPress.org repozitorija kontrolsummām, tāpēc komerciāls spraudnis, ko esat pircis no izstrādātāja, pārbaudē vienkārši tiek izlaists; tēmām līdzvērtīgas komandas WP-CLI dokumentācijā nav vispār (WP-CLI dokumentācija, skatīta 2026. gada 5. augustā). Automātiskai pārbaudei tādējādi nepakļaujas ne tēmas, ne ārpus repozitorija pirktie spraudņi, un wp core verify-checksums izlaiž visu wp-content — to koda daļu, kurā radās visas 11 334 Patchstack 2025. gadā saskaitītās ievainojamības, izņemot kodola sešas. Vietnēs, kuras mēs pārņemam, tieši tēma mēdz būt vienīgā, ko neviens nekad nav pārbaudījis.

Mūsu praksē kontrolsummas tāpēc ir sākumpunkts, nevis metode: kodolu un spraudņus mēs neārstējam, bet aizstājam, proti, lejupielādējam tās pašas versijas no oriģinālā avota un pārrakstām mapes pilnībā, nevis pa vienam failam. No vecās instalācijas paturam wp-content/uploads, un arī to tikai pēc pārbaudes, vai starp attēliem nav PHP failu — tā paša iemesla dēļ, kura dēļ PHP dzinēju šajā mapē vispār ir vērts izslēgt. Tēmu atjaunojam no versiju kontroles, ja tāda ir; ja nav, ņemam izstrādātāja piegādāto kopiju un pielāgojumus uzliekam virsū apzināti, pa vienam, jo tikai tā vēlāk var pateikt, kura rinda vietnē ir mūsu un kura nav.

Atrast un izdzēst slikto rindiņu izklausās lētāk, un tieši tāpēc tā ir visbiežāk atkārtotā kļūda: uzbrucējs reti atstāj vienu ieeju, un vienas nepamanītas aizmugures durvis padara visu pārējo darbu par velti. Kods mēdz būt sadalīts vairākos failos, noslēpts aiz base64 vai gzinflate izsaukuma, ierakstīts datubāzes opciju tabulā vai ievietots tajā pašā mu-plugins mapē, kuru administrācijas panelis nerāda. Meklēšana pēc parauga atrod to, ko jūs jau pazīstat; pilnīga aizstāšana atbrīvo arī no tā, ko nepazīstat.

Ir arī darbs, ko šajā posmā nedarām: nepaļaujamies uz spraudni, kas piedāvā inficētos failus "izārstēt" ar vienu pogu, jo tas strādā ar to pašu zināmo paraugu sarakstu un turklāt tajā pašā vidē, kurā uzbrucējam joprojām ir piekļuve. Nesalīdzinām failus ar roku arī tad, kad vietne ir parastas vizītkartes vai bloga apjomā, jo svaiga instalācija ar pārnestu saturu prasa mazāk stundu nekā divu direktoriju salīdzināšana rindiņu pa rindiņai, un rezultāts ir pārbaudāms. Rūpīga manuāla salīdzināšana ir vietā tur, kur tēma vai spraudnis ir unikāls un versiju kontroles nav; kā rīkoties ar dublējumkopijām, lai šī izvēle vispār pastāvētu, esam aprakstījuši vispārīgajā atkopšanas ceļvedī.

Atslēgas, sesijas un paroles: kas ko patiesībā izdara

Drošības atslēgas un sāļi (security keys and salts) failā wp-config.php neko nešifrē, lai gan tā apgalvo gandrīz katrs ceļvedis: WordPress tās izmanto par pamatu atslēgai, ar kuru funkcija wp_generate_auth_cookie() ar HMAC-SHA256 paraksta autentifikācijas sīkdatni, bet pati sīkdatne ir atklāts teksts ar lietotājvārdu, derīguma termiņu un sesijas marķieri (WordPress Developer Resources, skatīts 2026. gada 5. augustā). Tāpēc, nomainot šīs vērtības, katrs agrāk izsniegtais paraksts kļūst nepārbaudāms un serveris noraida ikvienu līdz šim izdotu sīkdatni, pat ja pati sesija formāli vēl nav beigusies.

Praktiskā seka ir tieši tā, kas uzlaušanas brīdī vajadzīga: WordPress oficiālā dokumentācija atslēgu nomaiņu apraksta kā veidu, kā izmest ārā ikvienu, kas vēl varētu būt pieteicies (WordPress.org, "FAQ My site was hacked", atjaunināts 2026. gada 26. jūlijā), tātad, ja uzbrucējs tur rokās derīgu sesiju, tā beidzas tajā pašā mirklī. Kopā ar sesijām nederīgi kļūst arī visi izdotie nonce marķieri, tāpēc iesāktās formas un pusceļā esošie pasūtījumu soļi tobrīd pārtrūkst — nomaiņas brīdi izvēlamies apzināti, nevis nejauši darba dienas vidū.

Atslēgu un sāļu nomaiņa nemaina nevienu paroli. Paroļu jaucējvērtības WordPress veido ar bcrypt un katrai parolei atsevišķu nejaušu sāli, kas ar wp-config.php konstantēm nav saistīts (funkcija wp_hash_password(); bcrypt pēc noklusējuma kopš WordPress 6.8), tāpēc uzbrucējs, kurš zina administratora paroli vai ir paspējis izveidot sev kontu, pēc atslēgu maiņas vienkārši piesakās no jauna. Paroles maināmas atsevišķi un visas, arī tās, kuras it kā neviens nezina, un vienlaikus jāpāriet cauri lietotāju sarakstam, meklējot kontus, ko neviens no jūsu komandas nav veidojis.

Ar WordPress piekļuves datu saraksts nebeidzas: vienā piegājienā maināma hostinga vadības paneļa parole, FTP un SFTP piekļuves dati, datubāzes lietotāja parole kopā ar atbilstošo ierakstu wp-config.php, kā arī SSH atslēgas, kuras nevis maina pēc paroles principa, bet ģenerē no jauna, no servera faila authorized_keys izdzēšot veco publisko atslēgu. Beidzot maināmas visas vietnē glabātās API atslēgas — maksājumu vārtejas, e-pasta sūtīšanas servisa, piegādes un grāmatvedības integrāciju —, jo tās mēdz palikt neaiztiktas visilgāk: neviens tās ikdienā neredz nevienā ekrānā.

Pieņemiet, ka uzbrucējam ir pilna datubāzes kopija, jo tas ir lētākais solis visā uzbrukumā: viss, kas datubāzē ir bijis, tostarp klientu e-pasta adreses, pasūtījumu vēsture, paroļu jaucējvērtības un spraudņu iestatījumos ierakstītās atslēgas, jāuzskata par svešās rokās nonākušu. Ja kāda no šīm parolēm ir lietota vēl kaut kur, arī tā vieta ir kompromitēta, un parasti tas ir brīdis, kad saruna no vietnes pāriet uz e-pasta kontiem, grāmatvedības sistēmu un veikala maksājumu kontu.

Secība ir tikpat svarīga kā pats saraksts: atslēgas un paroles maināmas pēc tam, kad aizmugures durvis ir izņemtas, jo pretējā gadījumā uzbrucējs jaunās vērtības nolasa turpat wp-config.php failā vai vienkārši pārtver nākamo pieteikšanos. Tieši šī rinda — vispirms pilna kopija, tad cēlonis, tad tīrīšana un tikai visbeidzot piekļuves dati — ir tā, kur pašu spēkiem sākta atkopšana visbiežāk apstājas vai sajūk, tāpēc šo posmu mēs uzņemamies paši un beigās nododam rakstisku atskaiti par to, kas tika mainīts, kad un kāpēc.

Kā panākt, lai Google brīdinājums pazūd, un ko darīt pēc tam

Google Search Console sadaļa "Drošības problēmas" ir vienīgā vieta, kur var redzēt, ko tieši Google jūsu vietnē ir atradis: tur ir norādīts draudu veids un konkrētu skarto lapu paraugs, un no tā ir atkarīgs arī tas, ko šobrīd redz apmeklētājs. Draudu veids nemaina to, ko redz apmeklētājs: Chrome vairs nešķiro brīdinājuma virsrakstu pēc tā, vai atrasta pikšķerēšana, ļaunprogrammatūra vai nevēlama programmatūra, bet visos gadījumos rāda vienu un to pašu pilnekrāna brīdinājumu — latviski "Bīstama vietne" —, kas cilvēku vietnē vienkārši neielaiž, savukārt jau pieminētā atzīme "This site may be hacked" meklēšanas rezultātos ir tikai uzraksts blakus saitei, kuram var noklikšķināt cauri (Google Chrome palīdzības lapa par bīstamām vietnēm, pārbaudīta 2026. gada augustā). Vecāko, pēc draudu veida atšķirīgo virsrakstu — piemēram, "Deceptive site ahead" — Chrome vairs nelieto, lai gan tas joprojām ir atrodams daļā Google dokumentācijas. Pirmais bloķē, otrais brīdina, un tas maina, cik daudz laika jums patiesībā ir.

Pirms nospiest pogu "Pieprasīt pārskatīšanu", ir jāpārliecinās, ka vietne tiešām ir tīra, nevis tikai izskatās tīra jūsu pārlūkā. Google savā ceļvedī par cloaked keywords hack tieši brīdina, ka uzbrucēji cenšas radīt iespaidu, ka lapa jau ir dzēsta vai salabota, tāpēc katra bijusī surogātlapa ir jāpārbauda ar URL pārbaudes rīku, kas rāda Googlebot skatu, nevis jūsējo. Otrs solis, ko izlaiž visbiežāk, ir īpašnieku saraksts: Japanese keyword hack gadījumā uzbrucējs pievieno sevi kā verificētu Search Console īpašnieku (Google dokumentācija vietnē web.dev), un, kamēr viņš no tā saraksta nav izņemts, viņš par vietnes stāvokli zina tieši tikpat daudz, cik jūs.

Meklējamā poga ir "Pieprasīt pārskatīšanu" drošības problēmu atskaitē, nevis "atkārtotas izskatīšanas pieprasījums", ko Google attiecina uz manuālajām sankcijām, un pieprasījuma tekstā ir vērts uzrakstīt trīs lietas: kas tika atrasts, kā uzbrucējs iekļuva un kas konkrēti ir izdarīts, lai to novērstu. Termiņu mēs nesolām, jo to nesola arī Google: tās dokumentācijas lapa par sociālo inženieriju saka, ka pārskatīšana "var aizņemt vairākas dienas", bet Search Console palīdzības lapa par drošības problēmām raksta "no dažām dienām līdz dažām nedēļām" (abas pārbaudītas 2026. gada augustā). Ja kāds jums nosauc konkrētas 24 vai 72 stundas, viņš atkārto skaitli, kura nav nevienā Google avotā.

Steiga šajā solī izmaksā dārgāk nekā gaidīšana. Tajā pašā Google un Kalifornijas Universitātes (Bērklijā) pētījumā 80 % vietņu īpašnieku panāca vietnes atzīšanu par tīru jau pirmajā mēģinājumā, bet pārējiem 20 % vajadzēja vairākus mēģinājumus, un mediānais laiks, ko tie pavadīja, izķemmējot uzbrucēja atstāto kodu, bija vesela nedēļa. Dati ir no 2014.–2015. gada un tā arī jālasa, taču aritmētika nav mainījusies: noraidīts pieprasījums nozīmē, ka brīdinājums paliek vēl vienu ciklu, un otrreiz jūs vairs neesat pirmreizējs iesniedzējs.

Kad brīdinājums ir noņemts, darbs vēl nav galā, jo indeksā paliek uzbrucēja izveidotās lapas, un tās nedrīkst pāradresēt uz sākumlapu — tām ir jāatgriež 404 vai 410, lai Google tās izņemtu pavisam, kamēr Search Console noņemšanas rīks tās tikai uz laiku paslēpj. Pozīcijas neatgriežas ar slēdža pagriezienu: lapas ir jāpārindeksē no jauna, un tas notiek Google tempā, nevis jūsējā. Kā šajā posmā izmantot žurnālfailus un dublējumkopijas, lai nākamreiz sākumpunkts būtu labāks, esam aprakstījuši atsevišķā ceļvedī par uzlauztu vietņu atkopšanu.

Kad pārstāt darīt pašam un cik tas maksā

Daļu no šeit aprakstītā pieredzējis vietnes īpašnieks izdara pats, un mēs to bez aplinkiem sakām arī cilvēkiem, kuri mums zvana ar atvērtu Search Console un jau atrastu vainīgo spraudni. Ja infekcija ir viena sabojāta sākumlapa, ja žurnālfailos ir redzams, kurš spraudnis to ielaida, ja lietotāju sarakstā nav svešu administratoru un ja ir vakardienas dublējumkopija, kuru kādreiz tiešām esat atjaunojuši testa vidē, tad astoņas apmaksātas stundas jums nopirks mierīgāku miegu, nevis ātrāku rezultātu.

Ir četras situācijas, kurās mēs iesakām apstāties, un pirmā ir atkārtota inficēšanās pēc tīrīšanas: ja vietne tiek uzlauzta otrreiz, tas nav neveiksmes jautājums, bet pierādījums, ka ielaušanās punkts joprojām ir atvērts, un trešā tīrīšana tajā pašā vidē maksās tieši tikpat, cik pirmās divas. Otrā ir jebkura aizdomu ēna par klientu vai maksājumu datiem, jo tur līdzās tehniskajam darbam parādās arī pienākumi pret uzraudzības iestādi un termiņi, kurus ar labu gribu pagarināt nevar. Trešā ir vietne, no kuras uzņēmums pelna katru dienu, un ceturtā — vienkāršs laika trūkums: tīrīšana nav intelektuāli sarežģīta, bet tā ir gara, vienmuļa un nepiedod nevienu izlaistu failu.

Mūsu uzlauztu vietņu atjaunošana maksā €90 stundā bez PVN, ar minimumu astoņas darba stundas, kas tiek apmaksātas avansā. Darbu parasti sākam dažu stundu laikā pēc pieteikuma, un viss process no sākuma līdz nodošanai parasti aizņem 8–72 stundas, turklāt atšķirība starp astoņām un septiņdesmit divām stundām gandrīz vienmēr ir tajā, cik dziļi uzbrucējs paguva iekārtoties un cik veca ir pēdējā tīrā kopija. Minimums nav mārketinga skaitlis: pilna kopija, cēloņa meklēšana žurnālfailos, tīrīšana un pārbaude īsākā laikā iekļaujas reti.

Kārtība ir tā pati, kas aprakstīta augstāk, tikai bez jūsu nedēļas nogales. Pirms pieskaramies jebkam, noņemam pilnu failu un datubāzes kopiju, lai incidentu vēlāk vispār būtu iespējams izmeklēt, un tikai tad vietne tiek izolēta; tālāk tā tiek notīrīta no ļaunprātīgas programmatūras un aizmugures durvīm, datubāze pārbaudīta, piekļuves dati un atslēgas nomainītas, atrasts un aizvērts ielaušanās cēlonis, iesniegts pieprasījums Google pārskatīšanai un iestatīts monitorings, bet beigās jūs saņemat rakstisku atskaiti par notikušo un par to, kas tika mainīts. Ja vietne šobrīd nedarbojas vai neesat pārliecināts par to, ko redzat, varat pieteikt steidzamu vietnes pārbaudi, un mēs pasakām, vai šeit vispār ir par ko maksāt.

Daudzos gadījumos īstā atbilde tomēr nav atkopšana, bet gan tas, kas notiek pēc tās: ja vietne ir uzkrājusi divdesmit spraudņus, no kuriem pusei neviens vairs neatceras iemeslu, tad problēma ir uzturēšanā, un to risina WordPress izstrāde un uzturēšana, nevis vēl viens tīrīšanas cikls pēc pusgada. Vislētākā stunda visā šajā stāstā ir tā, kas iztērēta iepriekš: nelietota spraudņa izdzēšana no wp-content/plugins, nevis tā deaktivizēšana, un dublējumkopija, kuru kāds reiz tiešām ir atjaunojis testa vidē, kopā izmaksā mazāk nekā viena mūsu darba diena.