Накратко: Който иска да смени хостера след инцидент със сигурността, трябва първо да запази доказателствата и да изясни инцидента, после да пренесе само проверени данни върху новоизградена система и едва след това да прекрати стария договор. Новия доставчик избирате по критерии за сигурност: доказуеми процеси за пачване, разделяне на клиентите, достъп до логове, резервни копия и ясни лица за контакт. Смяната на хостера има смисъл, когато липсват доверие или качество на услугата, но не замества почистването.
Когато доверието е изчезнало
След PHP2Shell много фирми преживяват хостера си под натиск за първи път. Някои получиха бързо ясна информация за състоянието на пача. Други чакаха дни за отговор, получаваха само общи фрази или установиха, че уебсайтът им е работил на остаряла версия на PHP. Ако към това се прибави и инцидент, желанието за смяна е разбираемо.
Смяната на хостера обаче не е стъпка от овладяването на инцидента, а от новото устройване след него. Който я постави в грешен ред, в най-лошия случай отнася нападателя със себе си и едновременно губи следите, които показват какво се е случило.
Правилният ред при смяната
- Запазете следите, докато ги има. Логовете, файловете и базата данни на старата система трябва да влязат в резервно копие, преди нещо да бъде изтрито или прекратено. Попитайте стария хостер изрично за логове за достъп и грешки от 20 октомври 2026 г. насам и за срока им на съхранение. Как да постъпите, описва статията Запазете доказателствата, преди да инсталирате наново.
- Ограничете инцидента. Кои системи са засегнати, кои достъпи са използвани, до кои данни е имало достъп? От това зависят задълженията за уведомяване и въпросът какво можете да вземете със себе си.
- Проверете задълженията за уведомяване. Ако могат да бъдат засегнати лични данни, срокът за евентуално уведомяване по ОРЗД започва с узнаването на инцидента, не с преместването. Подробности има на страницата Задължение за уведомяване по ОРЗД: 72 часа.
- Изградете новата система чисто. Поддържана версия на PHP, актуални пакети, втвърдена конфигурация, преди да бъде пренесен първият файл.
- Пренасяйте само проверено. Код от чист източник, база данни и медийни файлове след проверка.
- Сменете всички данни за достъп. База данни, админ акаунти, SSH, FTP, API ключове, включително тези в конфигурационните файлове.
- Превключете и наблюдавайте. Смяна на DNS, след това за известно време по-строго наблюдение.
- Прекратете стария договор. Едва когато логовете и резервните копия са запазени и новата работа е стабилна.
Не прекратявайте стария договор, преди да държите логовете и резервните копия в ръка. С края на договора при доставчика могат да бъдат изтрити данни, от които се нуждаете за застрахователи, органи или за собственото изясняване.
Какво не бива да вземате със себе си
Удобно би било просто да копирате цялата уеб директория или образ на сървъра. Точно това е рисковано след инцидент. Уеб шеловете се маскират като безобидни файлове, задните вратички се крият в конфигурационни файлове като .htaccess или .user.ini, а вмъкнатият код може да лежи в съдържанието на базата данни.
Затова пренасяйте кода на приложението от чист източник, например пакета на производителя в подходящата версия или Вашата система за контрол на версиите. Медийните файлове вземайте без изпълними файлове, базата данни - след проверка за подозрително съдържание и нови администраторски акаунти. Онова, което е намерено на старата система, помага при тази проверка.
Мислете и за всичко, което освен уебсайта стои при стария доставчик. Пощенските кутии, DNS записите, сертификатите и пренасочванията лесно се забравят при преместването. Намалете срока на валидност на DNS записите няколко дни преди превключването, за да стигне промяната бързо до посетителите. Ако се премества и електронната поща, планирайте смяната на пощенските кутии отделно, защото и там след инцидент могат да са засегнати данни за достъп.
Изберете новия хостер по сигурност
Цената и дисковото пространство стоят във всяка оферта. Решаващите въпроси за сигурността обикновено трябва да зададете сами. Следният списък помага при сравнението:
| Критерий | Въпрос към доставчика | Защо е важно |
|---|---|---|
| Процес на пачване | Как и в какъв ред се инсталират и рестартират PHP актуализациите за сигурност? | PHP2Shell показа колко важен е доказуем процес |
| Доказателство | Получавам ли при запитване писмено потвърждение за състоянието на пача? | Основа за собствената Ви документация |
| Версии на PHP | Кои клонове се предлагат и докога още? | Стари клонове без актуализации са траен риск |
| Разделяне | Всеки уебсайт работи ли със собствен потребител и собствен PHP процес? | Ограничава щетите, ако съсед бъде атакуван |
| Логове | Имам ли достъп до логове за достъп и грешки, колко дълго се съхраняват? | Без логове няма изясняване |
| Резервни копия | Колко често, колко дълго, отделно от уеб сървъра, с тест за възстановяване? | Възстановяване след инцидент |
| Контакт при спешност | Как да се свържа при инцидент със знаещо лице? | Времето е най-оскъдният фактор при бедствие |
| Обработване по поръчка | Има ли договор по ОРЗД и списък на подизпълнителите? | Задължително при лични данни |
Образец за въпроса за състоянието на пача предлага ръководството Попитайте хостера за състоянието на пача. То е подходящо и за сравнение на доставчици преди сключването на договор.
По-добър отговор ли е друг модел на работа?
Понякога проблемът е по-малко в хостера, отколкото в модела на работа. Който поддържа собствен сървър без редовни грижи, често е по-добре защитен с добре обгрижвано управлявано предложение. Обратно, фирма със собствена ИТ може да спечели повече контрол над моментите на пачване, ако администрира сама. Преценката описва статията Управляван хостинг или собствен сървър?.
Независимо от модела важи: фиксирайте разпределението на задачите писмено. Кой инсталира PHP актуализациите, кой рестартира, кой проверява приложението, кой на кого се обажда при спешност? При PHP2Shell много забавяния възникнаха точно тук, защото всяка страна мислеше, че другата се грижи.
Как помага PHP SOS конкретно?
- Запазваме логовете и данните на старата система и изясняваме какво се е случило при инцидента.
- Изграждаме новата система втвърдена и пренасяме само проверено съдържание от чисти източници.
- Проверяваме офертите на нови доставчици по критериите за сигурност и задаваме правилните въпроси.
- При текущ инцидент работим в рамките на нашия Incident Response, докато инцидентът бъде приключен и документиран.
Често задавани въпроси
Трябва ли след хакване веднага да сменя хостера?
Не веднага. Първо трябва да се запазят следите, да се ограничи инцидентът и да се изясни причината. Прибързано преместване може да пренесе злонамерения код и да унищожи доказателства при стария доставчик.
Вината на хостера ли е, ако уебсайтът ми е бил атакуван през PHP2Shell?
Зависи от договора и от момента. При споделения хостинг за PHP актуализациите обикновено отговаря хостерът, при собствени сървъри - операторът. Пачовете излязоха на 21 октомври 2026 г.; дали и кога са инсталирани, може да се изясни само с доказателства. За въпроси на отговорността потърсете правен съвет.
Какви данни мога да взема със себе си при новия хостер?
Само проверено съдържание: базата данни след проверка за вмъкнат код, медийни файлове без изпълними файлове и код от чист източник, например пакета на производителя или Вашата система за контрол на версиите. Пълни образи на сървъра или уеб директории от компрометираната система не бива да пренасяте непроверени.
Трябва ли след инцидент да включа защитата на данните?
Ако могат да бъдат засегнати лични данни, може да съществува задължение за уведомяване по ОРЗД, по правило в срок от 72 часа. При новия хостер Ви трябва освен това договор за обработване на данни по поръчка. Изяснете това с длъжностното лице по защита на данните; това не е правен съвет.