Stručne: Zmeniť CMS po hacku pomôže len vtedy, ak príčinou bol samotný starý systém, napríklad preto, že výrobca už nedodáva bezpečnostné aktualizácie alebo dôležité rozšírenia sa už neudržiavajú. Ak bola príčina v zastaraných pluginoch, slabých prístupoch alebo zraniteľnosti, ako je PHP2Shell, v podkladovom PHP, zmena iba presunie námahu. V každom prípade platí: obsah najprv preveriť, potom presťahovať, inak škodlivý kód prejde so sebou.
Keď je dôvera preč
Po vniknutí je nálada často jednoznačná: „S týmto systémom nikdy viac.“ Je to pochopiteľné. Web presmeroval návštevníkov na cudzie stránky, Google varoval, zákazníci sa pýtali. Nové CMS pôsobí ako nový začiatok.
Situácia okolo PHP2Shell však ukazuje, prečo môže tento reflex zavádzať. Zraniteľnosť je v interpreteri PHP, nie vo WordPresse, TYPO3, Shopware ani v inom systéme. WordPress.org preto podľa drweb.de nepláni proti nej vlastnú aktualizáciu. Kto teraz prejde z jedného CMS na PHP na druhé CMS na PHP, má nakoniec rovnakú závislosť, len s iným logom. Ktoré systémy bežia na PHP, ukazuje prehľad Ktoré CMS a obchodné systémy bežia na PHP.
O všetkom rozhoduje príčina
Skôr než začnete uvažovať o zmene, musí byť objasnená príčina vniknutia. Typickými vstupnými bránami sú zastarané rozšírenia, opakovane používané alebo slabé heslá, chýbajúce dvojfaktorové prihlásenie, nezáplatovaný server alebo zabudnuté testovacie inštalácie. Žiadna z týchto príčin nie je viazaná na konkrétne CMS.
Kto príčinu nepozná, riskuje, že si ju prenesie do nového systému. Tím, ktorý doteraz odkladal aktualizácie, to urobí aj v novom CMS. Agentúra, ktorá používala spoločné administrátorské účty, to zopakuje, ak nikto nezmení postup. Otázka teda nie je „ktoré CMS?“, ale „aký proces?“.
Zmeniť CMS po hacku: zvažovanie
| Kritérium | Ostať pri existujúcom CMS a spevniť ho | Prejsť na iné CMS |
|---|---|---|
| Príčina vniknutia | Známa a odstrániteľná, napríklad zastaraný plugin | Je v samotnom systéme, napríklad chýbajúce aktualizácie od výrobcu |
| Údržba od výrobcu | Bezpečnostné aktualizácie sa dodávajú | Výrobca údržbu ukončil |
| Závislosť od rozšírení | Niekoľko udržiavaných rozšírení | Veľa rozšírení bez aktívnej údržby |
| Náročnosť | Vyčistenie, hardening, zmena procesu | Nové vybudovanie, migrácia, školenie, často nový dizajn |
| Čas do bezpečného webu | Kratší | Dlhší, potrebné prechodné riešenie |
| Ochrana pred zraniteľnosťami PHP | Žiadna zmena, PHP sa musí záplatovať | Žiadna zmena, kým nový systém používa PHP |
| Dlhodobý prínos | Vysoký, ak sa zlepšia procesy | Vysoký, ak bol starý systém aj tak na konci |
Ak vo vašej situácii vyjde väčšina riadkov vľavo, zmena sa sotva oplatí. Ostať, vyčistiť, spevniť a zlepšiť postup údržby prinesie viac bezpečnosti za menej peňazí. Pre prevádzkovateľov WordPressu zhŕňa najdôležitejšie kroky článok WordPress a PHP2Shell.
Dodávateľa na toto rozhodnutie nie vždy potrebujete. Ak bola príčina jednoznačná, napríklad známy plugin so zverejnenou zraniteľnosťou, a vaša agentúra alebo administrátor web čisto nanovo nainštalovali, môžete rozhodnúť sami. Externá pomoc sa oplatí, ak príčina zostáva nejasná alebo by mohli byť dotknuté osobné údaje.
Ak meníte: neodniesť si škodlivý kód
Ak padne rozhodnutie pre zmenu, samotná migrácia je bezpečnostné riziko. Útočníci zanechávajú stopy nielen v súboroch, ale aj v databáze. Tieto kroky pomáhajú presťahovať sa čisto:
- Starý systém zálohovať a izolovať: Úplná záloha ako dôkaz, potom starý systém odpojiť od siete alebo ho nechať dostupný iba interne.
- Obsah exportovať cielene: Texty, štruktúru stránok a médiá, nie celú databázu. Používateľské účty neprebierať, ale vytvoriť nanovo.
- Obsah preveriť: Texty prezrieť na zavlečené skripty, skryté odkazy a cudzie presmerovania. Ako na to, opisuje článok Kontrola databázy na zavlečený kód.
- Médiá filtrovať: Prevziať iba očakávané typy súborov, súbory s dvojitými príponami alebo skriptovým obsahom vyradiť.
- Nový systém nainštalovať čisto: Z originálneho zdroja výrobcu, na serveri so záplatovaným PHP, s novými prístupovými údajmi a dvojfaktorovým prihlásením.
- Naplánovať presmerovania: Staré adresy presmerovať na nové, aby vyhľadávače a návštevníci dorazili, bez toho, aby zostali otvorené staré cesty.
Zmena CMS nenahrádza vyčistenie starého servera. Ak starý systém beží ďalej, napríklad ako zabudnutá kópia pod subdoménou, zadné vrátka zostávajú otvorené.
Alternatíva, ktorá sa často prehliada
Niektoré firmy po hacku zistia, že funkcie veľkého CMS vlastne nepotrebujú. Firemný web s niekoľkými stránkami, ktoré sa menia zriedka, sa zaobíde aj bez PHP na serveri. Generátor statických stránok vytvorí hotové súbory HTML, ktoré už nepotrebujú žiadnu logiku na strane servera. Aké výhody a nevýhody to má, opisuje článok Statické weby: menej PHP, menšia plocha útoku.
Naopak pre obchody, portály alebo weby s mnohými redaktormi to zvyčajne nie je možnosť. Tu zostáva zmysluplný dynamický systém a bezpečnosť vzniká údržbou, hardeningom a monitorovaním.
Kto si nie je istý, či v starom WordPresse ešte nehrozia skryté prístupy, nájde v článku Hľadanie backdoorov vo WordPresse typické miesta nálezov. Pomôže to aj pri rozhodovaní, či je vyčistenie realistické.
Ako konkrétne pomáha PHP SOS?
- Najprv objasníme príčinu vniknutia a povieme vám, či je v CMS, alebo v procese a serveri.
- Existujúci systém vyčistíme v rámci odstránenia malvéru alebo ho pripravíme ako dôkaz pre nové vybudovanie.
- Pri zmene preveríme obsah a médiá, ktoré sa majú prevziať, na škodlivý kód, skôr než sa dostanú do nového systému.
- Nový server nastavíme so záplatovaným PHP a spevnenou konfiguráciou.
Záver
Zmena CMS po hacku je zriedka riešením, ale niekedy správnou príležitosťou. Ak sa starý systém už neudržiava, nový začiatok sa oplatí. Ak príčina bola v procesoch alebo na serveri, práca na procese prinesie viac než nové logo. V oboch prípadoch platí: najprv preveriť, potom presťahovať.
Časté otázky
Pomôže zmena CMS proti PHP2Shell?
Nie, pokiaľ nové CMS tiež beží na PHP. PHP2Shell je v interpreteri PHP, nie v CMS. Rozhodujúci je stav záplat PHP na serveri, nie systém nad ním.
Je WordPress menej bezpečný než iné CMS?
Paušálne sa to povedať nedá. Mnohé vniknutia vznikajú pre zastarané rozšírenia, slabé prístupy alebo chýbajúce aktualizácie a tieto príčiny existujú v každom systéme. Rozšírenosť však robí z CMS častejší cieľ automatizovaných skenov.
Môžem obsah z napadnutého CMS jednoducho exportovať?
Len po kontrole. Databáza môže obsahovať zavlečené skripty, skryté odkazy alebo cudzie administrátorské účty. Nahrané súbory môžu maskovať škodlivý kód. Exportujte obsah cielene a pred importom ho preverte.
Kedy je zmena CMS skutočne zmysluplná?
Keď výrobca už nedodáva bezpečnostné aktualizácie, keď web závisí od rozšírení, ktoré sa už neudržiavajú, alebo keď systém jednoducho nevyhovuje dnešným požiadavkám. Hack je potom príležitosťou, nie dôvodom.