


19 октября в 07:20 по Москве FirstVDS сообщил об установке ещё одного исправления VMmanager после инцидента безопасности. По сообщению провайдера, уязвимость пока устранена не полностью, поэтому доступ к панели управления виртуализацией остаётся закрытым. В Mentoring.digital разбираем, что это обновление означает для разработчиков, чьи серверы попали в уведомление FirstVDS.
Коротко: установленный патч и восстановленный доступ к панели пока нельзя считать одним событием. Для получивших уведомление команд остаётся отдельная работа с доступами, которые хранились на затронутых серверах. Статус работающего приложения не заменяет проверку этих доступов.
Первичное сообщение FirstVDS опубликовано 18 октября и описывает атаку 17 октября через VMmanager 6. Провайдер сообщил о копировании данных с дисков части клиентских виртуальных серверов, включая пароли, ключи и конфигурационные файлы. Владельцам затронутых серверов направлены уведомления.
В дополнении от 19 октября FirstVDS уточнил, что ночное исправление вендора уже установлено. При этом вендор пока не рекомендует открывать доступ к панели и готовит следующие патчи. По состоянию на это сообщение расследование не завершено.
Речь идёт о части инфраструктуры. Отсутствие уведомления провайдер объясняет тем, что на соответствующих узлах следов атаки не обнаружено, с оговоркой о продолжающемся расследовании. Переносить сообщение на любой сервер FirstVDS или на чужую установку VMmanager без дополнительных данных нельзя.
Мы предлагаем разделить две задачи: закрытие пути первоначальной атаки и прекращение действия уже раскрытых доступов. Их выполняют в разных системах, а подтверждают разными результатами. Запись об установленном патче не отвечает на вопрос, может ли прежний токен всё ещё обратиться к внешнему сервису.
Условный пример: на сервере находился токен автоматической публикации пакетов. Даже если сам сайт отвечает нормально, команде нужно выяснить, где этот токен использовался, какие права имел и как подтвердить его отзыв. Замена пароля входа на сервер не является такой проверкой.
Для затронутых клиентов FirstVDS рекомендует сменить хранившиеся на сервере пароли и ключи, отозвать старые значения и проверить журналы входов. Секретные значения не следует переносить в рабочий чат или таблицу отчёта. В реестре достаточно названия системы, назначения доступа, ответственного и статуса отзыва.
Начните с конкретных серверов из уведомления. Затем сопоставьте их с приложениями и внешними зависимостями. Для каждого доступа полезно ответить на три вопроса:
Например, восстановление успешной сборки проверяет новую конфигурацию CI/CD, то есть автоматической сборки и доставки изменений. Но отзыв старого ключа подтверждается отдельно в системе, которая его выдала. Эти два результата стоит записать раздельно, чтобы не закрыть задачу по одному зелёному статусу.
При разборе зависимостей может помочь наставник по API и интеграциям, а порядок работы с окружениями и доступами можно обсудить с ментором по DevOps-практикам. Редакция не проверяла серверы читателей и не устанавливает факт компрометации конкретного проекта.
Для самой панели значимым будет подтверждение провайдера об устранении ограничения и условиях восстановления доступа. Для вашей команды отдельный результат состоит в проверенном отзыве зависимых ключей и восстановлении нужных операций. Эти статусы могут измениться в разное время.
Практический шаг сейчас: передать ответственному специалисту уведомление FirstVDS вместе со списком приложений на указанных серверах и проверить выполнение инструкции провайдера. Не объявляйте инцидент закрытым только потому, что установлен очередной патч или снова проходит проверка доступности сайта.
Обложка: редакционная иллюстрация, не фотография инфраструктуры FirstVDS.