Вернуться к статьям Что произошло у FirstVDS
17 октября 2026 года FirstVDS обнаружил, что злоумышленник получил административный доступ к VMmanager 6, панели управления виртуальными машинами. По отчёту провайдера, сборщик подключал диски клиентских ВМ со стороны гипервизора и выборочно копировал файлы. Среди них могли быть конфигурации с паролями, закрытые ключи и токены. Для этого не требовался вход по SSH в саму виртуальную машину. Точный набор скопированных файлов по каждой ВМ провайдер установить не смог. Постмортем FirstVDS от 27 октября
На FirstVDS размещались проекты трёх наших клиентов. Как только провайдер сообщил об инциденте, мы приняли все необходимые меры для защиты их информации.
Какие доступы менять после компрометации сервера
Начните со списка серверов в уведомлении провайдера. Для каждого запишите, какие учётные данные на нём хранились, где их можно отозвать и что перестанет работать при замене. Если один пароль или ключ использовался на нескольких серверах, проверьте все места, где он даёт доступ.
| Где искать | Что заменить и как проверить |
|---|---|
| Сервер, панель управления и админка сайта | Смените пароли администратора, пользователей с доступом к серверу и учётных записей сайта, если они могли попасть в скопированные файлы. Завершите затронутые сессии там, где сервис это поддерживает. |
| SSH и автоматизация | Если мог быть скопирован закрытый ключ, создайте новую пару и удалите прежний публичный ключ из списков разрешённых ключей на серверах и в сервисах, куда он давал вход. Проверьте резервный доступ перед отключением старого ключа. |
| База данных | Смените пароли учётных записей, которые использует сайт, и обновите их в конфигурации приложения и фоновых задач. Проверьте чтение и запись. Для магазина можно создать тестовый заказ в безопасной среде. |
| Репозиторий, выкладка сайта и хранилище копий | Перевыпустите затронутые токены и ключи. Проверьте права новой учётной записи и один рабочий сценарий: выкладку, загрузку или скачивание копии. |
| CRM, почта, платёжный сервис и боты | Перевыпустите затронутые API-токены, SMTP-пароли и секреты вебхуков. Проверьте доставку уведомления, обмен с CRM и обновление статуса оплаты по тестовому сценарию, который поддерживает провайдер. |
Проверьте файлы .env, конфигурации приложений, задания cron и настройки выкладки. Выписывайте назначение учётных данных и место, где они используются. Сами значения паролей и токенов храните в защищённом хранилище.
В каком порядке заменить доступы
- Ограничьте подозрительную активность. Если есть признаки постороннего доступа, согласуйте с администратором изоляцию затронутой системы и сохранение журналов. Доступы с признаками злоупотребления отзывайте сразу через сервис, который их выдал. Приоритет у учётных записей, через которые можно управлять другими системами.
- Подготовьте чистую среду. Выпускайте новые ключи с доверенного устройства. Если целостность сервера под вопросом, разверните проверенную копию или чистый образ. Подключайте новые секреты после проверки среды.
- Переключите интеграции. Если сервис допускает два ключа и текущий риск позволяет короткое переключение, обновите настройки приложения, выполните тест и сразу отзовите старый ключ. Если сервис позволяет держать только один ключ, подготовьте изменения заранее и согласуйте короткий перерыв. Проверьте фоновые задания: они могут продолжать использовать старые настройки.
- Проверьте обе стороны. Убедитесь, что интеграция выполняет нужное действие с новым доступом. Затем проверьте статус прежнего ключа у поставщика. При возможности выполните безопасный запрос на чтение и убедитесь, что сервис отклоняет его со старыми учётными данными. Для SSH проверьте, что старый ключ удалён на всех узлах, где он давал доступ.
Смена паролей, закрытых ключей и секретов приложений при подозрении на компрометацию входит в рекомендации по реагированию на инциденты. Руководство CISA по реагированию
Достаточно ли восстановить сайт из резервной копии
Восстановление возвращает файлы и базу данных. Пароли и токены внешних сервисов продолжают действовать, пока их не отзовут у поставщика. Более того, в резервной копии могут остаться прежние настройки. Перед запуском восстановленного сайта подключите новые доступы и проверьте, что фоновые задания используют их.
Если ключ попал в репозиторий, сначала отзовите или замените его. Удаление файла из последнего коммита оставляет прежние копии в истории и у тех, кто уже скачал репозиторий. Документация GitHub об удалении секретов из репозитория
Если сайт работает, сверяйте состояние доступов с уведомлением провайдера и результатами проверки, а не с доступностью главной страницы. При обслуживании сервера заранее согласуйте, кто управляет ключами, где их отзывать и кто проверит работу сайта после замены. Обслуживание серверов сайтов на 1С-Битрикс
Как мы возвращали клиентский проект в работу из внешней резервной копии после другого инцидента. Наш разбор атаки на Beget