Od nášho klienta Strojbal s.r.o. sme dostali zadanie analyzovať, prečo niektoré ich podporné landing stránky vykazujú chyby alebo nie sú vôbec dostupné. Tieto weby boli postavené svojpomocne na CMS WordPress. Po udelení prístupov sme sa pustili do práce.
1. Analýza problému
Zamerali sme sa na prvý web, ktorý nefungoval vôbec (biela obrazovka). Už zbežná kontrola integrity súborov WordPressu preukázala, že išlo o útok cez niektorú z verejne známych bezpečnostných chýb WP, resp. niektorého z použitých pluginov. Podobné problémy sme následne identifikovali takmer pri všetkých ostatných weboch.
Kroky boli jasné:
- Dočasne znefunkčniť všetky weby, aby neboli zneužívané na nelegálnu činnosť.
- Prečistiť všetky weby od škodlivých alebo pozmenených súborov WP.
- Zmeniť heslá používateľov a prečistiť používateľské kontá.
- Aktualizovať WordPress aj všetky použité pluginy.
2. Oprava prvých 2 webov
Najprv sme využili skener od poskytovateľa hostingu. Objavil stovky rôzne poschovávaných súborov, ktoré na prvý pohľad nie vždy vzbudzovali podozrenie. Približne 95 % problémových súborov sme odstránili. Zvyšné zasahovali priamo do funkčných častí WordPressu alebo niektorého pluginu, preto sme ich obnovili z čistej inštalácie danej verzie WP. Nasledovala kontrola používateľských kont a vymazanie podozrivých (ponechali sme konto pôvodného developera a admin konto, ktoré využíval klient) a aktualizácia WP aj pluginov. Weby sme na skúšku spustili.
Zaujímali nás pritom nielen očakávané zmeny, ako nočné automatické aktualizácie WordPressu, ale predovšetkým tie neželané – úpravy súborov, ktoré by mohli signalizovať nekalú činnosť. O každej zmene sme boli okamžite notifikovaní.
Niekoľko dní bol pokoj. Weby boli funkčné, súbory sa menili iba automatickými aktualizáciami a access logy vykazovali veľké množstvá chýb 404 pri pokusoch o prístup k odstráneným infikovaným súborom. Po pár dňoch však náš nástroj zaznamenal modifikácie aj vytváranie nových súborov. Ukázalo sa, že skener hostingu ani naše analýzy logov neodhalili úplne všetky infikované súbory, a tak sme celý proces čistenia zopakovali (vypnúť, vyčistiť, zmeniť heslá atď.).
Približne dva týždne bol opäť pokoj, access logy naďalej zachytávali veľké množstvo neúspešných pokusov. Keď sa problém zopakoval aj potom, usúdili sme, že toto asi nebude úplne ideálna cesta pre všetkých 16 webov.
3. Konzultácia s klientom, ako ďalej
Po oboznámení klienta s výsledkami a predpokladanými nákladmi na opravu ostatných webov sme dospeli k spoločnému riešeniu: niektoré nepotrebné weby sa úplne vypnú a ich domény zrušia, iné domény sa len presmerujú (301 redirect) na hlavný firemný web – ten už roky beží práve na našom mCMS, a preto ako jediný infikovaný nebol. Zostalo 9 domén, pri ktorých klient trval na oprave či prerobení. Náš návrh –minimalistické multisite one-page riešenie postavené na našom redakčnom systéme mCMS – klient nakoniec odsúhlasil.
V číslach:
- 3 domény úplne zrušené (podľa analytík neprinášali žiadny prínos)
- 4 domény presmerované na relevantné podsekcie hlavného webu (301 redirect)
- 9 domén postavených ako landing one-pages s variabilným obsahom a vizuálne podobnou šablónou
4. Príprava systému a webov
Začali sme spoločnou šablónou v Bootstrap Studio – najprv s publikovaním priamo na web (na ukážku klientovi), neskôr priamo do mCMS. Samotné mCMS si vyžiadalo implementáciu funkcionality presmerovania a niekoľko opráv chýb spojených s multisite mechanizmom.
Na strane servera sme pre Apache vytvorili macro, ktoré zjednotilo konfiguráciu všetkých domén a nasmerovalo ich do jedného webrootu – 1 doména tak znamená 1 riadok v konfigurácii vhosts. Pre každý web sme následne pripravili produkty, galérie, základný popis a logo. Väčšinu údajov sme v mCMS nadefinovali parametricky, aby nebolo potrebné robiť množstvo individuálnych zásahov do šablón pre každý web zvlášť.
5. Čas nasadenia
Na samotnú migráciu sme si pripravili checklist postupu pre každú doménu. V dostatočnom predstihu pred migráciou sme prešli a upravili konfiguráciu DNS pre 13 domén u komerčného poskytovateľa hostingu: všetkým doménam sme znížili TTL pre A a AAAA záznamy na minimum (5 minút), odstránili nepotrebné záznamy a podobne. Počas práce došlo k dočasnej nedostupnosti administrácie poskytovateľa – snáď nie našou intenzívnou prácou. 🤔
SSL certifikáty sme vygenerovali cez Let's Encrypt/ZeroSSL pomocou predpripraveného mechanizmu na serveri. Potom stačilo prepnúť DNS na náš server – a weby do 5 minút bežali na novom multisite riešení postavenom na našom redakčnom systéme mCMS.
Záver
Zo 16 problémových WordPress inštalácií tak zostala jedna inštalácia mCMS, ktorú udržiavame centrálne – menej údržby, žiadne deravé pluginy a rýchlejšia správa obsahu pre klienta.