Ochranou WordPressu se jeho majitel zabývá obvykle až tehdy, když je web napadený. To je sice pozdě, ale pořád je to lepší než nikdy. Protože i tato negativní zkušenost je cenná. Jaký postup tedy zvolit pro opravu napadeného webu?
Obsah článku
Jak se pozná, že je web napadený
Prvotní reakce může přijít z hostingu – zakázali vám funkci mail(), která rozesílala spam, v horším případě našli zavirovanou část kódu a vyzývají vás k okamžité nápravě. Hrozí vypnutím webu, což pak i udělají. Nelze se divit, je to klíčová část zásahu – zabránit šíření a „odpojit“ web z internetu.
Někdy může být napadení patrné ihned, protože se titulní nebo jiná stránka přesměruje někam jinam. Může to být obvykle porno, třeba umělecky japonské. Někdy se stránky přesměrovávají pouze na mobilu, na desktopu se chovají normálně. Pokud se podíváte do zdrojového kódu stránky v prohlížeči, najdete odkazy na divné stránky – přitom nemusí být ve výsledku vidět, ale zpracovávají se.
Jiný projev může být vytvoření mnoha administrátorů, kdysi jsem jich viděl 600. Nebo už jako administrátor nevidíte sekci Pluginy nebo jinou, nebo dokonce nejste adminem na vlastním webu. Když se podíváte na ftp (na server), najdete divné soubory s náhodnými jmény nebo v souboru wp-config.php nebo wp-settings.php nebo wp-blog-header.php uvidíte nové řádky.
Dalším projevem může být hlášení pluginu jako je Wordfence, pokud jste ho na webu měli a správně jste ho nastavili. Ten dokáže pravidelně provádět bezpečnostní skeny a hledat zranitelnosti (musíte to mít předem nastavené). Ale zase si nedělejme iluze o dokonalosti – vzhledem k tomu, že PHP a JS jsou textové formáty, omezuje se hledání kritických snippetů na definované výrazy, resp. funkce, které se často volají za účelem maskování (obfuskace) škodlivého kódu.
Ten pak spouští externí příkazy, manipuluje se soubory nebo obchází bezpečnostní omezení. Některé z těchto zneužívaných funkcí:
eval()
– Tato funkce umožňuje spouštění PHP kódu uloženého jako řetězec. Je často zneužívána pro spuštění škodlivého kódu, který byl dynamicky vytvořen nebo získán z externích zdrojů. Strašná ***árna, že to vůbec existuje.exec()
,shell_exec()
,system()
,passthru()
– umožňují spouštění externích příkazů a skriptů na serveru, tedy na úrovni operačního systému.base64_decode()
– zakódování a dekódování kódu, což umožňuje skrýt jeho skutečný účel před jednoduchou inspekcí a detekčními nástroji (=obfuskace).file_get_contents()
,fopen()
,curl_exec()
– načítání dat ze souborů nebo z internetu, slouží pro homecalling a další rozšiřování kódu.include()
,require()
,include_once()
,require_once()
– klasické funkce tady slouží jako schody pro rozšíření kódu do útrob vašeho webu. Vytvořené soubory se vkládají v tak složité posloupnosti, že je obtížné najít začátek a konec (navíc jsou obfuskované).preg_replace()
– Když je funkce použita s přepínačem /e (což v novějších verzích PHP už nejde, proto aktualizujte!), může spustit PHP kód uvnitř nahrazovaných řetězců.
Všechny tyhle funkce jsou základem pro další šíření a modifikace souborů. V nich se objevují buď na začátku, aby se načítaly ihned, nebo na konci, aby se spustily „nenápadně“. Obvykle to má nějaký účel – určité části kódu se starají o šíření webem, jiné komunikují ven, další pak mohou provádět samotnou škodlivou činnost. Ale s tím jsem se skoro nesetkal, protože většinou je váš WordPress pouze vehikl, ne cíl.
A asi nejblbější fází je, když o napadení webu ví Google. Přijde vám hlášení ze Search Console a za podpory informací ze Safe Browsing začne prohlížeč blokovat přístup na váš web všem návštěvníkům (což je logická, ale nemilá reakce).
Pár hlášek, které člověk slýchá
Obvyklé – z mého pohledu laické – reakce jsou:
- My na webu nic důležitého nemáme, proč by napadli zrovna náš web.
- No a co, tak to obnovíme ze zálohy.
- My tam máme tu rekapču, tak to máme chráněné.
- A klasika žánru: Nám se o to stará Pepa, externí firma, náš dobrý hosting.
Proč by někdo napadal zrovna váš web
Protože to jde.
Obvykle nejde o data vašeho webu, pokud je ten web malý. Pokud ale máte e-shop plný objednávek, už jste zajímavým cílem. Útočníci mají typicky tyto cíle:
- Dostat váš web pod kontrolu a využít ho v budoucnu pro DDoS útoky.
- Dostat váš web pod kontrolu a posílat přes něj spam.
- Otestovat si nějaký nový postup nebo technologii na vaší konfiguraci.
- Méně případů: vykrást vaše data.
Zdůraznil bych jednu důležitou věc. Pokud máte WooCommerce, ujistěte se, že se v žádném logu neobjevují informace o objednávkách. Některé pluginy něterých výrobců v minulosti prokazatelně ukládaly ladicí informace do souborů, které bylo možné zobrazit přes adresu v prohlížeči. Obvykle to byla chyba autora, že logování nevypnul. Pak není žádný útok ani potřeba. V těch lozích byly informace o zákaznících, kteří na webu právě nakoupili. Ano, poštovní adresy, telefonní čísla, e-mailové adresy.
Jak reagovat při napadení
- Uzavřít web do servisního režimu a napsat tam informaci + stejnou informaci publikovat na sociálních sítích. Ideálně použijte soubor index.php a v něm zobrazte HTML.
- Bude potřeba nainstalovat celý systém znovu z instalačních zdrojů.
- Ideálně zjistit, co se stalo a mít pro to doklady.
- Následně web zabezpečit a zohlednit výsledky analýzy, tj. provést změnu, aby se napadení nemohlo opakovat.
Obvykle nemá cenu obnovovat web ze zálohy, protože
- je velmi pravděpodobné, že je taky napadená – v tom stresu to nepoznáte,
- i když by napadená nebyla, bude v ní díra, kterou útok přišel,
- určitě byste přišli o nějaká aktuální data, to riziko existuje pořád, tak proč to dělat dobrovolně.
Obnova ze zálohy znamená ve vysokém počtu případů, že máte web do pár dnů napadený znovu. Nákaza může být na webu mnohem déle než je váš archiv záloh. Běžně to bývá půl roku. Máte zálohy starší půl roku? A chcete je nasadit?
Pojďte na to chytře.
Uzavřít web a informovat návštěvníky
Pokud nejde o osobní blog, nepodceňujte informovanost, lidi to ocení, když se dozví, že to není výpadek, nýbrž plánovaná odstávka, která bude trvat do XX:00. Zkuste si to naplánovat a dodržet.
Pokud jde o klientský web nebo e-shop, musíte ihned informovat klienta. Utíkají peníze. Nesete zodpovědnost, takže je na místě klienta uklidnit a vysvětlit mu realisticky stav. Abyste se nedočkali toho, že vám uniklé výnosy z reklamy nebo prodejů bude fakturovat – měl by na to právo a záleží, jak máte spolupráci nastavenou.
Přeinstalovat všechen software
Moc neplánujte, že se vám v rozumném čase podaří najít všechny napadené soubory a vyčistit je. Nereálné. Pokud vás to zajímá (jak mě), pak si celý web vykopírujte na lokální počítač, a to včetně adresářů v uploads, tam bývá nejedno překvapení. Hrát si budete, až vám to znovu poběží na produkci.
Připravte si originální instalační zdroje pro všechny komponenty a seznam pluginů:
- WordPress – zde můžete použít případnou automatickou instalaci, pokud ji platforma nabízí
- všechny placené pluginy stáhněte znovu z originálních zdrojů a zkuste zjistit, jestli náhodou nemají známou zranitelnost (minimálně googlete „slider revolution vulnerability“ nebo pod. 🙂 )
- bezplatné pluginy budete instalovat už z administrace,
- použitou šablonu taktéž stáhněte znovu, všechny ostatní znovu NEinstalujte
- pokud máte podřízenou šablonu, child theme, nejprve ji pečlivě zkontrolujte, jestli neobsahuje změny
- možná ještě must-use pluginy a addony v adresáři /wp-content/
V podstatě je tedy nutné odstranit škodlivý kód. Protože není čas lámat si hlavu, kdo je kdo, pitvání nechte na potom, nejprve vše obnovíte. Nejsou jasné minimálně tři věci:
- které konkrétní soubory jsou aktuálně napadeny,
- jaký je mechanismus šíření kódu a jaký typ kódu se spouští (jestli jsou napadeny PHP skripty prováděné na serveru, nebo javascripty prováděné v prohlížeči),
- ve kterých souborech je bezpečnostní díra a je nutné je z instalace vyřadit (jsou jednou z příčin napadení)
S tímto východiskem přistupujte k tomu, že musíte zabránit, aby se situace opakovala. Tedy pokračujte:
- vytvořte nové heslo do databáze a upravte wp-config.php,
- smažte celou aplikaci WordPress, tedy
- wp-admin, wp-includes, skripty v kořenu webu (kromě wp-config.php),
- wp-content, včetně plugins, themes, upgrades, cache a dalších, kromě adresáře uploads,
- vše, co najdete a na server nepatří,
- nainstalujte vše z originálních zdrojů a v aktuálních verzích
- WordPress nainstalujte automatizovaně nebo rozbalením ZIP soubor a nakopírováním na server; dejte pozor, abyste při automatické instalaci nesmazali data v databázi
- placené pluginy instalujte nahráním ZIP souboru,
- neplacené pluginy instalujte klasickým postupem
- neinstalujte, co není potřeba a neinstalujte opuštěné nebo neudržované pluginy
Změnit a vylepšit konfiguraci
Jakmile web funguje, postupně aktivujte všechny nezbytné pluginy a ujistěte se, že vše funguje, jak očekáváte nebo potřebujete. Pokud jste měli zastaralé komponenty, můžete narazit na změny nebo novinky, ty ale nemusí souviset s napadením. Nevracejte pluginy, které nejsou potřeba, udělejte jejich audit. Následně musíte
- změnit správcům hesla
- vylepšit konfiguraci a web zabezpečit
Jediné slabiny, které zůstávají: kód bude schovaný v uploads pod příponou png nebo jpg, musíte vše přepečlivě projít a ujistit se, že tam není krtek. Druhé riziko je, že kód se oživí z databáze.
Pouze jednou jsem se setkal s tím, že kód se uložil a následně znovu šířil z databáze. Replikoval se tuším z konfigurace nějaké komponenty, která ukládala JavaScript. Možná to byl správce snippetů? Proto je nemám rád. 🙂
Nastavte správně bezpečnostní plugin, hlavně v něm aktivujte firewall s odpovídající citlivostí na příchozí požadavky. Wodfence je potřeba pár dní učit. Zkuste využít službu jako Cloudflare nebo Wedos Global Protection.
Nedovolte, aby se na server ukládala data, která tam nemají co dělat. Ujistěte se, že logy nejsou dostupné z webu, případně že se vůbec nevytvářejí. Nastavte a následně ověřte, že se provádí pravidelná záloha databáze a uživatelských dat. Aplikaci WordPress a pluginy zálohovat nemusíte, v případě napadení je nepoužijete. Ale uživatelská data jsou to hlavní, co má na webu hodnotu.
Vše znovu spustit a monitorovat
Jakmile se vám vše podaří úspěšně vrátit do skoro původního stavu, tzn. udělali jste něco navíc pro ochranu webu, pak lze předpokládat, že jste nákazu odstranili a zamezili jste opakovanému napadení. Pak je dobré zjišťovat, co se stalo. Pokud máte jeden dva weby a jejich správa vás neživí, pak se vám celá analýza asi moc nevyplatí, protože je časově náročná.
Ale pokud máte webů hodně a hrozí, že by se to mohlo opakovat, pak se pusťte do zjišťování toho, co se stalo. Někdy příště zkusím popsat, jak provádím analýzu po napadení já, jak pitvám logy a sestavuju časovou linku. Do té doby věřím, že to nebudete potřebovat. 🙂
Pokud byste pomoc potřebovali, pak nám napište.