Stručně: Změna CMS po hacku pomůže jen tehdy, pokud příčinou byl starý systém sám, například proto, že výrobce už nedodává bezpečnostní aktualizace nebo se důležitá rozšíření neudržují. Pokud příčina spočívala v zastaralých pluginech, slabých přístupech nebo zranitelnosti jako PHP2Shell v podkladovém PHP, změna jen přesune práci. V každém případě platí: Obsah nejdřív prověřit, pak přenášet, jinak se škodlivý kód přenese s ním.
Když je důvěra pryč
Po průniku bývá nálada jednoznačná: „S tímto systémem nikdy víc.“ Je to pochopitelné. Web přesměrovával návštěvníky na cizí stránky, Google varoval, zákazníci se ptali. Nové CMS působí jako nový začátek.
Situace kolem PHP2Shell ale ukazuje, proč tento reflex může zavádět. Zranitelnost je v interpretu PHP, ne ve WordPressu, TYPO3, Shopware ani jiném systému. WordPress.org proto podle drweb.de neplánuje vlastní aktualizaci proti ní. Kdo teď přejde z jednoho CMS v PHP na jiné CMS v PHP, má nakonec stejnou závislost, jen s jiným logem. Které systémy běží na PHP, ukazuje přehled Která CMS a e-shopové systémy běží na PHP.
Co rozhodlo o příčině
Než začnete uvažovat o změně, musí být objasněna příčina průniku. Typické vstupní brány jsou zastaralá rozšíření, opakovaně používaná nebo slabá hesla, chybějící dvoufázové přihlášení, nezáplatovaný server nebo zapomenuté testovací instalace. Žádná z těchto příčin není vázána na konkrétní CMS.
Kdo příčinu nezná, riskuje, že ji přenese do nového systému. Tým, který dosud odkládal aktualizace, to udělá i v novém CMS. Agentura, která používala společné administrátorské účty, to zopakuje, pokud nikdo postup nezmění. Otázka tedy není ani tak „které CMS?“, ale „jaký proces?“.
Změnit CMS po hacku: rozvaha
| Kritérium | Zůstat u stávajícího CMS a zabezpečit ho | Přejít na jiné CMS |
|---|---|---|
| Příčina průniku | Známá a odstranitelná, např. zastaralý plugin | Spočívá v samotném systému, např. chybějící aktualizace výrobce |
| Péče výrobce | Bezpečnostní aktualizace se dodávají | Výrobce péči ukončil |
| Závislost na rozšířeních | Několik udržovaných rozšíření | Mnoho rozšíření bez aktivní péče |
| Pracnost | Vyčištění, zabezpečení, změna procesů | Nové vybudování, migrace, školení, často nový design |
| Doba do bezpečného webu | Kratší | Delší, nutné přechodné řešení |
| Ochrana před zranitelnostmi PHP | Beze změny, PHP musí být záplatováno | Beze změny, dokud nový systém používá PHP |
| Dlouhodobý přínos | Vysoký, pokud se zlepší procesy | Vysoký, pokud byl starý systém stejně u konce |
Pokud ve vaší situaci většina řádků spadá doleva, změna se téměř nevyplatí. Zůstat, vyčistit, zabezpečit a zlepšit postup údržby přinese víc bezpečnosti za méně peněz. Provozovatelům WordPressu shrnuje nejdůležitější kroky WordPress a PHP2Shell.
K tomuto rozhodnutí dodavatele nepotřebujete vždy. Pokud byla příčina jednoznačná, například známý plugin se zveřejněnou zranitelností, a vaše agentura či administrátor web čistě znovu postavili, můžete rozhodnout sami. Externí pomoc se vyplatí, pokud příčina zůstává nejasná nebo mohou být dotčeny osobní údaje.
Pokud měníte: nepřenést škodlivý kód
Pokud padne rozhodnutí o změně, je samotná migrace bezpečnostním rizikem. Útočníci zanechávají stopy nejen v souborech, ale i v databázi. Tyto kroky pomáhají přestěhovat se čistě:
- Starý systém zajistit a izolovat: Úplná záloha jako důkaz, poté starý systém odpojit od sítě nebo ponechat dostupný jen interně.
- Obsah exportovat cíleně: Texty, strukturu stránek a média, ne celou databázi. Uživatelské účty nepřebírat, ale založit znovu.
- Obsah prověřit: Texty projít na vložené skripty, skryté odkazy a cizí přesměrování. Jak na to, popisuje Kontrola databáze na vložený kód.
- Média filtrovat: Přebírat jen očekávané typy souborů, soubory s dvojitými příponami nebo obsahem skriptu vyřadit.
- Nový systém postavit čistě: Z původního zdroje výrobce, na serveru se záplatovaným PHP, s novými přístupovými údaji a dvoufázovým přihlášením.
- Naplánovat přesměrování: Staré adresy přesměrovat na nové, aby vyhledávače a návštěvníci došli, aniž by zůstaly otevřené staré cesty.
Změna CMS nenahrazuje vyčištění starého serveru. Pokud starý systém běží dál, například jako zapomenutá kopie na subdoméně, zůstávají zadní vrátka otevřená.
Alternativa, která se často přehlíží
Některé firmy po hacku zjistí, že funkce velkého CMS vůbec nepotřebují. Firemní web s několika málo stránkami, které se jen zřídka mění, se obejde i bez PHP na serveru. Generátor statických stránek vytváří hotové soubory HTML, které už nevyžadují serverovou programovou logiku. Jaké to má výhody a nevýhody, popisuje Statické weby: méně PHP, menší útočná plocha.
Naopak pro e-shopy, portály nebo weby s mnoha redaktory to většinou není možnost. Tam zůstává smysluplný dynamický systém a bezpečnost vzniká péčí, zabezpečením a monitoringem.
Kdo si není jistý, zda ve starém WordPressu nezůstaly skryté přístupy, najde v Najít zadní vrátka ve WordPressu typická místa nálezu. Pomůže to i při rozhodování, zda je vyčištění realistické.
Jak konkrétně pomáhá PHP SOS?
- Nejdřív objasníme příčinu průniku a řekneme vám, zda spočívá v CMS, nebo v procesu a serveru.
- Stávající systém čistíme v rámci odstranění malwaru nebo ho připravíme jako důkaz pro nové vybudování.
- Při změně prověřujeme převzatý obsah a média na škodlivý kód, než se dostanou do nového systému.
- Nový server stavíme se záplatovaným PHP a zabezpečenou konfigurací.
Závěr
Změna CMS po hacku je zřídka řešením, ale někdy správnou příležitostí. Pokud se starý systém už neudržuje, nový začátek se vyplatí. Pokud příčina spočívala v procesech nebo na serveru, přinese práce na procesu víc než nové logo. V obou případech platí: Nejdřív prověřit, pak přenášet.
Časté dotazy
Pomůže změna CMS proti PHP2Shell?
Ne, dokud nové CMS běží také na PHP. PHP2Shell je v interpretu PHP, ne v CMS. Rozhodující je stav záplat PHP na serveru, ne systém nad ním.
Je WordPress méně bezpečný než jiná CMS?
Paušálně se to říct nedá. Mnoho průniků vzniká zastaralými rozšířeními, slabými přístupy nebo chybějícími aktualizacemi a tyto příčiny existují v každém systému. Rozšířenost ale činí CMS častějším cílem automatizovaných skenů.
Mohu obsah z napadeného CMS prostě exportovat?
Jen po kontrole. Databáze může obsahovat vložené skripty, skryté odkazy nebo cizí administrátorské účty. Nahrané soubory mohou maskovat škodlivý kód. Exportujte obsah cíleně a před importem ho prověřte.
Kdy je změna CMS skutečně smysluplná?
Pokud výrobce už nedodává bezpečnostní aktualizace, pokud je web závislý na rozšířeních, která se už neudržují, nebo pokud systém dnešním požadavkům prostě nevyhovuje. Hack je pak příležitostí, ne důvodem.