Накратко: Смяната на CMS след хак помага само ако старата система самата е била причината, например защото производителят не доставя вече ъпдейти за сигурност или важни разширения не се поддържат. Ако причината е била в остарели добавки, слаби достъпи или уязвимост като PHP2Shell в подлежащия PHP, смяната само премества усилията. Във всеки случай важи: първо проверете съдържанието, после го преместете, иначе зловредният код се премества с него.
Когато доверието е изчезнало
След проникване настроението често е недвусмислено: „С тази система никога повече.“ Това е разбираемо. Уебсайтът е пренасочвал посетители към чужди страници, Google е предупредил, клиенти са питали. Ново CMS се усеща като ново начало.
Положението около PHP2Shell обаче показва защо този рефлекс може да подведе. Уязвимостта е в интерпретатора на PHP, а не в WordPress, TYPO3, Shopware или друга система. WordPress.org според drweb.de затова не планира собствен ъпдейт срещу нея. Който сега смени едно PHP CMS с друго PHP CMS, накрая има същата зависимост, само с друго лого. Кои системи работят на PHP, показва прегледът Кои CMS и магазинни системи работят на PHP.
Решава причината
Преди да мислите за смяна, причината за проникването трябва да е изяснена. Типични входни врати са остарели разширения, многократно използвани или слаби пароли, липсващо двуфакторно удостоверяване, непачнат сървър или забравени тестови инсталации. Никоя от тези причини не е свързана с определено CMS.
Който не познава причината, рискува да я пренесе в новата система. Екип, който досега е отлагал ъпдейтите, ще го прави и в новото CMS. Агенция, която е ползвала общи администраторски акаунти, ще го повтори, ако никой не промени реда. Въпросът затова е по-малко „кое CMS?“, а „кой процес?“.
Смяна на CMS след хака: преценката
| Критерий | Оставате при съществуващото CMS и го заздравявате | Преминавате към друго CMS |
|---|---|---|
| Причина за проникването | Позната и отстранима, например остаряла добавка | Лежи в самата система, например липсващи ъпдейти на производителя |
| Поддръжка от производителя | Ъпдейтите за сигурност се доставят | Производителят е прекратил поддръжката |
| Зависимост от разширения | Малко, поддържани разширения | Много разширения без активна поддръжка |
| Усилия | Почистване, заздравяване, промяна на процеса | Ново изграждане, миграция, обучение, често нов дизайн |
| Време до сигурен уебсайт | По-кратко | По-дълго, нужно е преходно решение |
| Защита от уязвимости в PHP | Без промяна, PHP трябва да се пачне | Без промяна, докато новата система ползва PHP |
| Дългосрочна полза | Висока, ако процесите се подобрят | Висока, ако старата система така или иначе е била в края си |
Ако повечето редове във Вашата ситуация попадат вляво, смяната едва ли си струва. Оставане, почистване, заздравяване и подобряване на реда на поддръжка носи повече сигурност за по-малко пари. За операторите на WordPress WordPress и PHP2Shell обобщава най-важните стъпки.
За това решение не Ви трябва винаги доставчик. Ако причината е била еднозначна, например известна добавка с публикувана уязвимост, и Вашата агенция или администратор е инсталирал уебсайта чисто наново, можете да решите сами. Външна помощ си струва, когато причината остава неясна или може да са засегнати лични данни.
Ако сменяте: не пренасяйте зловредния код
Ако решението е за смяна, самата миграция е риск за сигурността. Нападателите оставят следи не само във файловете, но и в базата данни. Тези стъпки помагат да се премести чисто:
- Обезопасете и изолирайте старата система: Пълно резервно копие като доказателство, след това старата система се изключва от мрежата или остава достъпна само вътрешно.
- Експортирайте съдържанието целенасочено: Текстове, структура на страниците и медии, а не цялата база данни. Потребителските акаунти не се прехвърлят, а се създават наново.
- Проверете съдържанието: Прегледайте текстовете за внесени скриптове, скрити връзки и чужди пренасочвания. Как става това, описва Как да проверите базата данни за внесен код.
- Филтрирайте медиите: Прехвърляйте само очаквани видове файлове, отстранете файлове с двойно разширение или със скриптово съдържание.
- Настройте новата система чисто: От оригиналния източник на производителя, на сървър с пачнат PHP, с нови данни за достъп и двуфакторно удостоверяване.
- Планирайте пренасочвания: Старите адреси се пренасочват към новите, за да стигнат търсачките и посетителите, без старите пътища да остават отворени.
Смяната на CMS не замества почистването на стария сървър. Ако старата система продължава да работи, например като забравено копие на поддомейн, задната врата остава отворена.
Алтернативата, която често се пропуска
Някои фирми след хак установяват, че изобщо не се нуждаят от функциите на голямо CMS. Фирмен уебсайт с малко страници, които рядко се променят, може да се справи и без PHP на сървъра. Генераторът на статични страници създава готови HTML файлове, които не изискват сървърна програмна логика. Какви са предимствата и недостатъците, описва Статични уебсайтове: по-малко PHP, по-малка повърхност за атака.
Обратно, за магазини, портали или уебсайтове с много редактори това обикновено не е вариант. Тук динамичната система остава разумна, а сигурността се получава чрез поддръжка, заздравяване и наблюдение.
Който е несигурен дали в стария WordPress не дебнат още скрити достъпи, ще намери в Как да намерите задни врати в WordPress типичните места за откриване. Това помага и при решението дали почистването е реалистично.
Как помага PHP SOS конкретно?
- Първо изясняваме причината за проникването и Ви казваме дали е в CMS или в процеса и сървъра.
- Почистваме съществуващата система в рамките на премахването на зловреден софтуер или я подготвяме като доказателство за ново изграждане.
- При смяна проверяваме съдържанията и медиите за прехвърляне за зловреден код, преди да стигнат до новата система.
- Настройваме новия сървър с пачнат PHP и заздравена конфигурация.
Извод
Смяната на CMS след хак рядко е решението, но понякога е правилният повод. Ако старата система вече не се поддържа, новото начало си струва. Ако причината е била в процесите или в сървъра, работата по процеса носи повече от ново лого. И в двата случая важи: първо проверете, после преместете.
Често задавани въпроси
Помага ли смяната на CMS срещу PHP2Shell?
Не, докато новото CMS също работи на PHP. PHP2Shell е в интерпретатора на PHP, а не в CMS. Решаващо е състоянието на пача на PHP на сървъра, а не системата над него.
WordPress по-несигурен ли е от други CMS?
Не може да се каже общо. Много прониквания възникват от остарели разширения, слаби достъпи или липсващи ъпдейти, а тези причини съществуват във всяка система. Разпространението обаче прави едно CMS по-често цел на автоматизирани сканирания.
Мога ли просто да експортирам съдържанието от хакнатото CMS?
Само след проверка. Базата данни може да съдържа внесени скриптове, скрити връзки или чужди администраторски акаунти. Качените файлове могат да маскират зловреден код. Експортирайте съдържанието целенасочено и го проверете преди импортиране.
Кога смяната на CMS наистина има смисъл?
Когато производителят вече не доставя ъпдейти за сигурност, когато уебсайтът зависи от разширения, които вече не се поддържат, или когато системата просто вече не пасва на днешните изисквания. Хакът тогава е поводът, а не причината.