Инцидент с тикетами Virtualizor: почему root-пароли нельзя хранить нигде
Инцидент безопасности в феврале 2026 года, затронувший систему поддержки Virtualizor, высветил одну из старейших проблем хостинговой отрасли: платформы поддержки незаметно превращаются в хранилища клиентских учётных данных.
Согласно собственному сообщению Virtualizor о безопасности, несанкционированный доступ к их системе тикетов раскрыл около 1500 исторических обращений в поддержку. Компания сообщила, что часть этих тикетов содержала чувствительные сведения, в том числе root-пароли открытым текстом, которые клиенты когда-то присылали, обращаясь за помощью. В Virtualizor заявили, что инцидент связан с системой поддержки и не вызван уязвимостью в самом программном обеспечении Virtualizor. 1
Важный вывод не сводится к одной платформе или одному провайдеру.
Проблема в том, что в системах поддержки годами копятся данные клиентов, которым никто не предназначал роль постоянного хранилища секретов.
Поддержка — забытая система безопасности
Многие хостинг-провайдеры со временем накапливают одно и то же.
Root-пароли, вставленные в переписку при разборе проблемы. SSH-ключи, приложенные во время миграции. Токены API внутри сообщений об ошибках. Дампы баз, загруженные, чтобы воспроизвести баг.
Тикет закрывается. Проблема решена. Клиент занимается своими делами дальше.
А данные нередко остаются в базе тикетов, в резервных копиях, во вложениях и во внутренних архивах.
Уровень риска системы поддержки напрямую связан с каждым секретом, который через неё прошёл. У многих провайдеров в этой истории куда больше чувствительного, чем им кажется.
Никогда не отправляйте в поддержку постоянные учётные данные
Любые учётные данные, отправленные через тикет, стоит считать потенциально скомпрометированными.
Сюда входят:
- root-пароли
- пароли администратора
- ключи API
- приватные ключи
- учётные данные баз данных
- пароли от панели управления
- временные пароли, созданные для разбора проблемы
Если учётные данные уже были отправлены — смените их.
Безопаснее давать временный доступ:
- создайте временную учётную запись для поддержки
- выдайте ограниченные права
- отзовите доступ после работы
- пользуйтесь консолью, когда SSH недоступен
Провайдер должен уметь разобраться с вашей услугой, не требуя ваших постоянных учётных данных.
Что стоит изменить хостинг-провайдерам
Ответственность лежит не только на клиентах.
Провайдерам следует исходить из того, что в старых тикетах чувствительные сведения есть, и снижать возможный ущерб.
Хорошие практики:
- проверять старые тикеты на данные, похожие на учётные
- удалять ненужные вложения по истечении сроков хранения
- защищать системы поддержки строгими механизмами аутентификации
- ограничивать доступ сотрудников к данным клиентов
- фиксировать в документах правила обращения с учётными данными
Платформу поддержки нужно рассматривать как продакшен-систему безопасности. В ней лежат сведения о клиентах, эксплуатационные детали и, возможно, аутентификационный материал.
Доступ без учётных данных
В AVS ISP мы не просим клиентов присылать root-пароли.
В услуги VPS и VDS входит консоль noVNC прямо в браузере, из личного кабинета. Если SSH недоступен из-за ошибки в фаерволе, сломанной конфигурации, неудачного обновления или другой системной проблемы, клиент заходит на машину напрямую, не передавая никаких постоянных учётных данных.
Когда нужна помощь поддержки, задача — помочь клиенту разобраться с проблемой, не создавая ещё одну копию его секретов.
Наша VPS-инфраструктура построена на виртуализации KVM: границы изоляции обеспечиваются аппаратной виртуализацией на уровне гипервизора, а не только средствами операционной системы.
В переписке с поддержкой должна быть диагностика, а не пароли.
Если вы когда-либо отправляли учётные данные любому хостинг-провайдеру, включая нас, самое правильное действие одно и то же: смените их.
Плохая схема резервных копий превращает шифровальщика в безвозвратную потерю
Самое разрушительное в атаках шифровальщиков — часто не само проникновение.
А потеря вариантов восстановления.
Если злоумышленник добрался до продакшена и до резервных копий, доступных с той же машины, авария превращается в безвозвратную потерю данных.
Настоящая схема резервного копирования требует разделения:
- отдельные учётные данные
- отдельные системы
- отдельные домены отказа
- желательно отдельные физические площадки
Резервная копия, которая лежит в той же среде и защищена теми же учётными данными, что и продакшен, — не независимая копия для восстановления.
AVS ISP держит инфраструктуру в нескольких локациях и предлагает дополнительные локации VPS тем, кому нужно географическое разнесение. Но принцип действует везде: у клиента должны быть резервные копии, которыми управляет он сам, а не только копии внутри среды его хостинг-провайдера.
Более широкий вывод для хостинга
Урок из подобных инцидентов простой:
Безопасность — это не только фаерволы, гипервизоры и защита сети.
Это ещё и повседневные рабочие привычки.
Пароль, скопированный сегодня в тикет, через годы становится инцидентом безопасности.
Хостинг-провайдерам стоит проектировать системы, исходя из того, что клиенты будут ошибаться. Клиентам — выбирать провайдеров, у которых эти ошибки менее опасны.
Лучший тикет в поддержку — тот, который решает проблему, так и не получив ни одного секрета.
Частые вопросы
Стоит ли давать VPS-провайдеру свой root-пароль?
Нет. Хостинг-провайдер не должен требовать постоянных учётных данных. Временный доступ, консоль или ограниченные учётные записи безопаснее.
Тикеты поддержки — это риск для безопасности?
Да. В тикетах часто оказываются логи, детали конфигурации, учётные данные и сведения о клиенте, и хранятся они годами.
Что делать, если я отправил пароль в поддержку хостинга?
Немедленно смените его. И заодно смените все связанные ключи, токены и учётные данные, которые могли попасть в ту же переписку.
Источники
- Security Update: Transparency Regarding a Recent Support Ticket Incident, Virtualizor (3 февраля 2026 года) — первоисточник
- Mass VPS Provider Ransomware Attack Linked to Stolen Credentials from Virtualizor Support Breach, Cyber Kendra (февраль 2026 года) — независимое сообщение