Krótko: Zmiana CMS po włamaniu pomaga tylko wtedy, gdy przyczyną był sam stary system, na przykład dlatego, że producent nie dostarcza już aktualizacji bezpieczeństwa lub ważne rozszerzenia nie są już utrzymywane. Jeśli przyczyna leżała w przestarzałych wtyczkach, słabych dostępach lub luce takiej jak PHP2Shell w leżącym poniżej PHP, zmiana tylko przesuwa nakład pracy. W każdym przypadku obowiązuje: najpierw sprawdzić treści, potem przenieść, w przeciwnym razie złośliwy kod przeniesie się razem z nimi.
Gdy zaufanie znika
Po włamaniu nastrój jest często jednoznaczny: „z tym systemem nigdy więcej”. To zrozumiałe. Strona przekierowywała odwiedzających na obce witryny, Google ostrzegło, klienci dopytywali. Nowe CMS wydaje się nowym początkiem.
Sytuacja wokół PHP2Shell pokazuje jednak, dlaczego ten odruch może prowadzić na manowce. Luka tkwi w interpreterze PHP, a nie w WordPressie, TYPO3, Shopware ani innym systemie. WordPress.org nie planuje według drweb.de własnej aktualizacji przeciwko niej. Kto teraz zmienia jedno CMS oparte na PHP na inne CMS oparte na PHP, ma w końcu tę samą zależność, tylko z innym logo. Które systemy działają na PHP, pokazuje przegląd Jakie CMS i systemy sklepowe działają na PHP.
O tym, co było przyczyną, decyduje ustalenie
Zanim zaczną Państwo myśleć o zmianie, trzeba wyjaśnić przyczynę włamania. Typowe wejścia to przestarzałe rozszerzenia, wielokrotnie używane lub słabe hasła, brak logowania dwuskładnikowego, niezałatany serwer lub zapomniane instalacje testowe. Żadna z tych przyczyn nie jest związana z konkretnym CMS.
Kto nie zna przyczyny, ryzykuje, że zabierze ją do nowego systemu. Zespół, który dotąd odkładał aktualizacje, będzie tak samo robił w nowym CMS. Agencja, która używała wspólnych kont administratora, powtórzy to, jeśli nikt nie zmieni przebiegu. Pytanie brzmi więc mniej „jakie CMS?”, a bardziej „jaki proces?”.
Zmiana CMS po włamaniu: rozważenie
| Kryterium | Pozostać przy obecnym CMS i je utwardzić | Zmienić na inne CMS |
|---|---|---|
| Przyczyna włamania | Znana i możliwa do usunięcia, np. przestarzała wtyczka | Leży w samym systemie, np. brak aktualizacji producenta |
| Utrzymanie przez producenta | Aktualizacje bezpieczeństwa są dostarczane | Producent zaprzestał utrzymania |
| Zależność od rozszerzeń | Niewiele utrzymywanych rozszerzeń | Wiele rozszerzeń bez aktywnego utrzymania |
| Nakład | Oczyszczenie, utwardzanie, zmiana procesu | Odbudowa, migracja, szkolenie, często nowy projekt graficzny |
| Czas do bezpiecznej strony | Krótszy | Dłuższy, potrzebne rozwiązanie przejściowe |
| Ochrona przed lukami PHP | Bez zmian, PHP musi być załatane | Bez zmian, dopóki nowy system używa PHP |
| Długoterminowy pożytek | Wysoki, jeśli procesy zostaną poprawione | Wysoki, jeśli stary system i tak był u kresu |
Jeśli w Państwa sytuacji większość wierszy ląduje po lewej stronie, zmiana ledwie się opłaca. Pozostanie, oczyszczenie, utwardzenie i poprawa przebiegu serwisu przynoszą więcej bezpieczeństwa za mniej pieniędzy. Dla operatorów WordPressa najważniejsze kroki podsumowuje artykuł WordPress i PHP2Shell.
Usługodawcy do tej decyzji nie zawsze Państwo potrzebują. Jeśli przyczyna była jednoznaczna, na przykład znana wtyczka z opublikowaną luką, a Państwa agencja lub administrator czysto zainstalowali stronę od nowa, mogą Państwo zdecydować sami. Zewnętrzna pomoc się opłaca, gdy przyczyna pozostaje niejasna lub mogą być dotknięte dane osobowe.
Jeśli zmieniają Państwo: nie zabierać złośliwego kodu
Jeśli zapadnie decyzja o zmianie, sama migracja jest ryzykiem bezpieczeństwa. Atakujący zostawiają ślady nie tylko w plikach, ale także w bazie danych. Te kroki pomagają przenieść się czysto:
- Zabezpieczyć i odizolować stary system: Pełna kopia jako dowód, potem odłączyć stary system od sieci lub udostępnić go już tylko wewnętrznie.
- Eksportować treści celowo: Teksty, struktura stron i media, nie cała baza danych. Kont użytkowników nie przejmować, lecz założyć na nowo.
- Sprawdzić treści: Przejrzeć teksty pod kątem wprowadzonych skryptów, ukrytych linków i obcych przekierowań. Jak to zrobić, opisuje artykuł Sprawdzanie bazy danych pod kątem wprowadzonego kodu.
- Filtrować media: Przejmować tylko oczekiwane typy plików, pliki z podwójnymi rozszerzeniami lub zawartością skryptu odrzucić.
- Czysto zainstalować nowy system: Z oryginalnego źródła producenta, na serwerze z załatanym PHP, z nowymi danymi dostępowymi i logowaniem dwuskładnikowym.
- Zaplanować przekierowania: Przekierować stare adresy na nowe, aby wyszukiwarki i odwiedzający trafiali na miejsce, bez pozostawiania otwartych starych ścieżek.
Zmiana CMS nie zastępuje oczyszczenia starego serwera. Jeśli stary system działa dalej, na przykład jako zapomniana kopia pod subdomeną, tylna furtka pozostaje otwarta.
Alternatywa, którą często się pomija
Niektóre firmy po włamaniu stwierdzają, że funkcji dużego CMS w ogóle nie potrzebują. Strona firmowa z kilkoma stronami, które rzadko się zmienia, obejdzie się bez PHP na serwerze. Generator stron statycznych tworzy gotowe pliki HTML, które nie potrzebują już logiki programu po stronie serwera. Jakie ma to zalety i wady, opisuje artykuł Strony statyczne: mniej PHP, mniejsza powierzchnia ataku.
Odwrotnie, dla sklepów, portali lub stron z wieloma redaktorami zwykle nie jest to opcja. Tu sensowny pozostaje system dynamiczny, a bezpieczeństwo wynika z pielęgnacji, utwardzania i nadzoru.
Kto nie jest pewien, czy w starym WordPressie nie czają się ukryte dostępy, znajdzie w artykule Wyszukiwanie tylnych furtek w WordPressie typowe miejsca znalezisk. Pomaga to także w decyzji, czy oczyszczenie jest realistyczne.
Jak konkretnie pomaga PHP SOS?
- Najpierw wyjaśniamy przyczynę włamania i mówimy Państwu, czy leży ona w CMS, czy w procesie i serwerze.
- Oczyszczamy istniejący system w ramach usuwania złośliwego oprogramowania lub przygotowujemy go jako dowód do odbudowy.
- Przy zmianie sprawdzamy treści i media do przejęcia pod kątem złośliwego kodu, zanim trafią do nowego systemu.
- Konfigurujemy nowy serwer z załatanym PHP i utwardzoną konfiguracją.
Podsumowanie
Zmiana CMS po włamaniu rzadko jest rozwiązaniem, ale czasem właściwą okazją. Jeśli stary system nie jest już utrzymywany, nowy początek się opłaca. Jeśli przyczyna leżała w procesach lub na serwerze, praca nad procesem przynosi więcej niż nowe logo. W obu przypadkach obowiązuje: najpierw sprawdzić, potem przenieść.
Częste pytania
Czy zmiana CMS pomaga przeciwko PHP2Shell?
Nie, dopóki nowe CMS także działa na PHP. PHP2Shell tkwi w interpreterze PHP, a nie w CMS. Decyduje stan poprawek PHP na serwerze, a nie system nad nim.
Czy WordPress jest mniej bezpieczny niż inne CMS?
Nie da się tego powiedzieć ogólnie. Wiele włamań wynika z przestarzałych rozszerzeń, słabych dostępów lub braku aktualizacji, a te przyczyny występują w każdym systemie. Popularność czyni jednak CMS częstszym celem zautomatyzowanych skanowań.
Czy mogę po prostu wyeksportować treści ze zhakowanego CMS?
Tylko po sprawdzeniu. Baza danych może zawierać wprowadzone skrypty, ukryte linki lub obce konta administratora. Przesłane pliki mogą maskować złośliwy kod. Proszę eksportować treści celowo i sprawdzić je przed importem.
Kiedy zmiana CMS naprawdę ma sens?
Gdy producent nie dostarcza już aktualizacji bezpieczeństwa, gdy strona jest zależna od rozszerzeń, które nie są już utrzymywane, lub gdy system po prostu nie pasuje już do dzisiejszych wymagań. Włamanie jest wtedy okazją, a nie powodem.