Уведомление о безопасности: Инцидент на платформе управления VDS

Уведомление о безопасности: Инцидент на платформе управления VDS
17 октября 2026 года мы обнаружили подозрительную активность на одном из узлов нашей системы управления VDS. Мы немедленно заблокировали сетевые ресурсы, задействованные в атаке, уведомили поставщика платформы и начали расследование инцидента.

Поставщик подтвердил наличие уязвимости в своем продукте и подготовил ряд исправлений безопасности, которые мы применили, как только они стали доступны. Поставщик также уведомил соответствующие организации по кибербезопасности об уязвимости нулевого дня в одном из своих продуктов. В качестве меры предосторожности некоторые функции сервиса были приостановлены на время проведения расследования и дополнительных проверок.

Подробная техническая информация об уязвимости будет опубликована поставщиком позже. До тех пор, пока эта информация не станет доступна, мы хотим четко обозначить, к чему мог быть получен доступ, что не пострадало и что следует предпринять клиентам VDS в настоящее время.

Возможно, к чему был получен доступ.
Согласно нашей текущей оценке, злоумышленник мог получить доступ только для чтения к метаданным, принадлежащим некоторым виртуальным машинам, и к образам их дисков.

Образ виртуального диска содержит файловую систему VDS. В зависимости от конфигурации сервера эта файловая система может включать файлы операционной системы, данные приложений, хэши паролей, файлы конфигурации, закрытые ключи SSH, учетные данные API, пароли баз данных, сертификаты и другие секреты. Мы не подтвердили, что доступ ко всем таким элементам был осуществлен, но клиентам следует рассматривать учетные данные, хранящиеся внутри затронутой виртуальной машины, как потенциально уязвимые.

Предполагаемый доступ осуществлялся только для чтения. Данное описание отражает имеющуюся на данный момент информацию и может быть уточнено после публикации техническим анализом поставщика.

Что осталось неизменным
Наше расследование показало, что инцидент не затронул:

• резервные серверы;
• персональные данные, хранящиеся в клиентском портале;
• платежные реквизиты;
• сервисы, помимо затронутой платформы управления виртуализацией.

В данном случае важно разделение этих систем. Доступ к части среды управления виртуализацией не предоставлял доступа к данным о выставлении счетов, данным учетных записей клиентов или инфраструктуре резервного копирования.

Меры, уже принятые ITLDC
После обнаружения активности мы заблокировали сетевые ресурсы, использованные в атаке, и начали сотрудничество с поставщиком системы управления виртуализацией. Мы незамедлительно применили все предоставленные поставщиком исправления.

В качестве дополнительных мер предосторожности мы ограничили доступ к некоторым некритичным сервисным функциям и сбросили пароли клиентов, используемые для прямого доступа к системе управления виртуализацией.

Этот сброс применяется к прямому доступу к платформе. Он не изменяет пароль внутри вашего виртуального сервера, поскольку только администратор сервера может безопасно управлять учетными данными гостевой операционной системы.

Автоматический доступ через клиентский портал ITLDC продолжает работать как и прежде. Клиенты могут открывать свой интерфейс управления VDS через портал без ввода прежнего пароля для прямого доступа.

Что следует предпринять клиентам VDS сейчас?
Поскольку образы дисков могли быть читаемыми, мы настоятельно рекомендуем выполнить следующие шаги, даже если ваш сервер, по-видимому, работает нормально.

1. Измените пароль операционной системы.
Измените пароли административных и других важных учетных записей внутри виртуального сервера. Используйте новые, уникальные пароли, которые не используются на других серверах или в других службах.

Если тот же пароль использовался в другом месте, измените его и там. Замена одной копии не сделает другие копии менее уязвимыми.

2. Поверните SSH-ключи, хранящиеся на VDS.
Если на виртуальном сервере хранятся закрытые SSH-ключи, используемые для подключения к другим системам, их следует обновлять:

• Сгенерируйте новую пару ключей в доверенной системе.
• Установите новый открытый ключ на каждом устройстве, к которому требуется доступ.
• Убедитесь, что новый ключ работает.
• Удалите старый открытый ключ из каждого места назначения и отзовите старый ключ там, где это применимо.
• Надежно удалите старый закрытый ключ из активных систем и средств автоматизации.

Не отзывайте старый ключ, не проверив предварительно новый, если у вас нет другого надежного способа доступа. Тщательная смена ключей повышает безопасность; отзыв единственного рабочего ключа лишь обеспечивает очень надежную блокировку.

Также проверьте системы развертывания, скрипты, задания CI/CD и конфигурации агентов, которые могут содержать копии старого ключа.

3. Меняйте учетные данные приложения и внешних сервисов.
Замените конфиденциальные данные аутентификации, хранящиеся на виртуальном сервере. Это может включать в себя:

• Ключи API и токены доступа;
• Учетные данные для облачных сервисов и объектных хранилищ;
• Пароли к базам данных;
• учетные данные для внешних панелей управления и сервисов;
• закрытые ключи, используемые приложениями;
• Секреты веб-хуков и ключи подписи.

Сначала создайте новые учетные данные, обновите приложения, которые их используют, проверьте нормальную работу, а затем отзовите старые учетные данные. Если поставщик предоставляет журналы доступа или историю активности токенов, проверьте их на предмет непредвиденного использования.

Самое безопасное правило простое: если секретный ключ хранился в незашифрованном виде в файловой системе VDS, его необходимо перезапустить.

4. Проверьте резервные копии.
Убедитесь, что у вас есть актуальные резервные копии всех необходимых данных, что вы можете получить к ним доступ и что они хранятся в независимом месте. Резервной копии, находящейся в том же домене отказоустойчивости, что и производственная система, недостаточно для серьезных сценариев восстановления.

Резервные копии всегда должны быть зашифрованы, особенно если они содержат полные файловые системы, базы данных, файлы конфигурации или данные клиентов. Ключи шифрования следует защищать отдельно от самой резервной копии.

Наконец, протестируйте восстановление. Сообщение об успешном завершении резервного копирования подтверждает, что файлы были записаны куда-то; успешное восстановление подтверждает, что они могут вам помочь.

Работа по обеспечению безопасности продолжается.
В настоящее время установлены необходимые сетевые блокировки и исправления от поставщика. Мы продолжаем проверку затронутой среды и оценим подробный технический отчет поставщика, как только он станет доступен.

Мы понимаем, что смена учетных данных занимает время, особенно на серверах, подключенных к нескольким внешним системам. Тем не менее, это надлежащая мера предосторожности, когда существовала возможность доступа на чтение к образу диска. Начните с доступа к операционной системе и учетных данных, которые могут быть связаны с другой инфраструктурой, затем перейдите к секретам приложений и учетным записям с более низкими привилегиями.

Если у вас возникли трудности с доступом к интерфейсу управления VDS или вам требуется уточнение информации о вашем сервисе, пожалуйста, свяжитесь со службой поддержки ITLDC через клиентский портал.

itldc.com