После инцидента у хостинг-провайдера разумно проверить доступы и сайт, даже если проект снова открывается. Начните с почты владельца, панели, DNS и учётных записей сайта, затем смените пароли и ключи, которые могли храниться на сервере. Работайте поэтапно: сначала сохраните копию текущего состояния, чтобы не потерять данные и иметь материал для сравнения.
Beget сообщил, что в ночь на 2 ноября 2026 года его инфраструктура подверглась кибератаке. В опубликованном разборе компания сообщала, что по имевшимся тогда данным не видела попыток скачать или изменить пользовательские данные, но рекомендовала сменить пароли, ключи и другие учётные данные, которые могли храниться на серверах. Это заявление не доказывает ни компрометацию каждого сайта, ни безопасность отдельного аккаунта; для конкретного проекта нужны собственная проверка и ответы поддержки.
Перед сменой доступов сохраните состояние
Если сайт и панель снова доступны, скачайте текущие файлы и экспортируйте базу данных. Зафиксируйте дату, размеры архивов, список пользователей CMS, установленные плагины и основные DNS-записи. Храните копии отдельно от аккаунта хостинга и ограничьте к ним доступ. Не восстанавливайте старый архив поверх нового сайта до проверки: так можно перезаписать свежие заказы и заявки.
Сделайте список всех мест, где использовались одинаковые пароли или секреты: панель хостинга, почта, FTP/SSH, CMS, база, CRM, аналитика, платежи, почтовый SMTP, вебхуки и внешние API. Не храните список паролей в открытом документе. Для каждой записи отмечайте только сервис, владельца и дату смены.
С чего начинать: почта, домен и панель
Сначала защитите основной почтовый ящик владельца и регистратора домена. Через почту часто сбрасываются остальные пароли, а через DNS можно направить посетителей на другой сервер. Установите уникальные пароли, включите двухфакторную защиту, проверьте резервный адрес и телефоны, завершите неизвестные активные сессии и убедитесь, что правила переадресации почты вам знакомы.
Затем смените пароль панели хостинга и пользователей, которым выдали доступ. Если подрядчик больше не работает с проектом, удалите его доступ через штатный интерфейс после согласования внутри команды. Проверьте, не изменились ли контактный адрес, NS-серверы, A/AAAA, MX и TXT-записи. Сохраните экспорт до и после изменений, чтобы было понятно, что именно поменялось.
Проверьте WordPress и другие CMS
В административной панели сайта пересмотрите список пользователей, роли и адреса электронной почты. Удаляйте только те учётные записи, которые точно не должны иметь доступа; незнакомую запись сначала зафиксируйте и выясните её назначение. Проверьте активную тему, плагины и время их последнего изменения. Не обновляйте всё подряд во время аварийного восстановления, если нет проверенной копии и тестовой площадки.
Смените пароль администратора CMS и используйте отдельные пароли для каждого пользователя. Если ключи или токены хранились в настройках сайта либо в файлах на сервере, выпустите новые в соответствующих сервисах и отзовите старые. Ключи доступа к платежам, CRM и почтовым сервисам важнее декоративных параметров: проверьте, кто может их просматривать и когда они обновлялись.
Сравните важные файлы с известной чистой копией проекта: конфигурацию, пользовательские плагины, каталоги загрузок и задания планировщика. Ищите неизвестные PHP-файлы в папках изображений, новые администраторские аккаунты, изменённые шаблоны и скрипты, которые появились без вашего согласования. Само наличие незнакомого файла ещё не доказывает заражение, поэтому сохраняйте копию и перед удалением консультируйтесь со специалистом.
Обновите доступ к файлам и серверу
Если вы подключались по FTP, SFTP или SSH, смените пароль или отзовите старые ключи и создайте отдельные ключи для тех, кому доступ по-прежнему нужен. Удалите неизвестные ключи только после того, как убедитесь, что у команды есть рабочий альтернативный доступ. Включите журналирование входов, если это поддерживает выбранная панель, и проверьте, нет ли новых пользователей ОС.
Не отправляйте приватный SSH-ключ в поддержку и не вставляйте его в браузерную форму. Если ключ хранился на компьютере, который мог быть скомпрометирован, создайте новую пару на доверенном устройстве, установите новый публичный ключ на сервере и только после проверки отзовите старый. Смена ключа сервера не заменяет смену пароля панели или CMS — это разные уровни доступа.
Поменяйте ключи интеграций
Проверьте файлы конфигурации сайта, переменные окружения и панели, где могли храниться пароли базы данных, SMTP, ключи карт, вебхуки или API-токены. Меняйте секрет в самом внешнем сервисе и сразу обновляйте его в сайте. Если сначала стереть старое значение из файла, а новое не выпустить, интеграция перестанет работать. После замены проверьте тестовую операцию и журнал событий.
Токены, которыми никто не пользуется, отзовите. Для нужных ключей ограничьте права: отдельный токен для чтения не должен иметь возможность оплачивать услуги или менять настройки проекта. Зафиксируйте владельца и срок следующего пересмотра, но не вставляйте реальные значения секретов в задачу, статью или скриншот.
Как искать подозрительные изменения
Сверьте журналы доступа панели, сервера и CMS за период вокруг инцидента. Ищите незнакомые входы, массовые ошибки авторизации, новые административные аккаунты, изменение файлов и запуск необычных процессов. Если логи недоступны, попросите провайдера подтвердить, какие журналы сохранились и можно ли получить сведения по вашему аккаунту.
Проверьте, что резервная копия открывается и её можно восстановить в изолированной копии сайта. Не считайте бэкап проверенным только потому, что архив скачался. Ищите копию, созданную до подозрительной активности, и отдельную копию текущего состояния для анализа. Если вы нашли признаки вмешательства, ограничьте доступ и обратитесь к специалисту по реагированию; не удаляйте потенциальные следы до сохранения материалов.
Как выбирать площадку после инцидента
Переезд имеет смысл, если у команды есть копия данных, доступ к домену и понятный план переключения. Но смена хостинга сама по себе не защищает пароль, утёкший из CMS, не переносит автоматически почтовые ящики и не исправляет небезопасный код. При сравнении площадок спрашивайте о восстановлении, доступе к архивам, изоляции услуг, реакции поддержки и возможности протестировать перенос без остановки рабочего сайта.
Ни один список провайдеров не обещает отсутствие инцидентов. Рейтинг ниже нужен, чтобы начать сравнение возможных площадок и задать одинаковые вопросы по вашему проекту. Уточняйте условия и полную стоимость до оплаты. Ссылки партнёрские: студия может получить вознаграждение за переход.
Рейтинг хостингов для сравнения
Перед реальным переездом восстановите тестовую копию, проверьте роли пользователей, DNS, сертификат, формы и интеграции. Рабочую площадку переключайте только после того, как ответственное лицо подтвердит целостность данных и план возврата.
Частые вопросы
Нужно ли срочно менять все пароли после инцидента у провайдера?
В первую очередь — уникальные пароли и ключи, которые хранились на сервере или повторялись в других системах. Делайте это по списку и проверяйте каждую интеграцию после замены.
Значит ли сообщение о кибератаке, что данные моего сайта украли?
Нет. Официальные сообщения не доказывают компрометацию каждого клиента. Проверяйте собственный аккаунт, журналы и уведомления провайдера, а выводы о конкретном сайте делайте по фактам.
Можно ли удалить подозрительный файл сразу?
Сначала сохраните копию и зафиксируйте путь и время изменения. Удаление без анализа может уничтожить полезные данные и не устранить причину появления файла.
Как защитить резервные копии?
Храните как минимум одну копию вне аккаунта основного хостинга, ограничьте к ней доступ и регулярно проверяйте восстановление в изолированной среде.