С этого уровня он управляет ВМ сверху: выключает их, копирует виртуальные диски, меняет сеть или шифрует весь datastore одной операцией. Поэтому безопасность сервера виртуализации начинается не внутри гостевых ОС. Разберём три слоя с максимальным радиусом поражения и настройки, способные разорвать цепочку атаки.

Один хост — большой радиус поражения

Сервер для виртуализации объединяет процессоры, память, сеть, хранилища и множество систем. Над ними расположен гипервизор — слой, создающий ВМ и распределяющий ресурсы физического узла. Control plane управляет хостами, сетями, питанием ВМ и datastore — хранилищем их дисков и конфигураций. Поэтому захват хоста имеет больший радиус поражения, чем взлом одной гостевой ОС. Примеры далее взяты из VMware vSphere, но принципы применимы к Hyper-V, KVM и Proxmox.

Главные цели — control plane, гипервизор и контур восстановления; входом могут стать учётная запись, уязвимый vCenter, бэкап-сервер или ВМ. В Verizon DBIR 2026 эксплуатация уязвимостей стала начальным вектором 31% взломов, а ransomware присутствовал в 48% подтвержденных нарушений. Это общий фон, а не статистика исключительно по гипервизорам. До настройки защиты полезно оценить сервер под виртуализацию, число ВМ, память, схему хранения и возможность изолировать управление и бэкапы.

Слой 1. Контур управления: одна учетная запись открывает кластер

vCenter, SCVMM и панели Proxmox VE удобны тем, что позволяют управлять хостами, сетями, хранилищами и виртуальными машинами из одной точки. Но централизация работает в обе стороны: административная учетная запись превращается в мастер-ключ, способный открыть весь кластер. Если платформа виртуализации подключена к общей Active Directory, компрометация домена может быстро перерасти в захват гипервизоров.

Показательный пример — уязвимость CVE-2024-37085. Подключенные к домену ESXi-хосты могли автоматически предоставлять полные права участникам группы ESX Admins. Microsoft зафиксировала ransomware-атаки, в которых злоумышленники создавали такую группу и добавляли в неё подконтрольного пользователя. Другой риск — CVE-2024-38812 с оценкой CVSS 9,8: специально сформированный сетевой пакет позволял атаковать доступный по сети vCenter даже без предварительной кражи административного пароля.

Защита контура управления должна включать несколько обязательных мер:

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

Привилегированные аккаунты нельзя использовать для почты, браузера, RDP и других повседневных задач. Дополнительно необходима break-glass account — аварийная локальная учетная запись с полными правами, не зависящая от рабочей Active Directory. Она хранится отдельно, используется только при отказе основной системы аутентификации, а каждое обращение к ней должно фиксироваться и проверяться.

Слой 2. Гипервизор: SSH, root и отложенные обновления

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

В 2025 году Broadcom закрыл цепочку ошибок VMware. CVE-2025-22224 с оценкой 9,3 позволяла администратору гостевой ВМ выполнить код в процессе VMX на хосте; CVE-2025-22225 могла затем обеспечить выход из sandbox — такой переход называют VM escape. Broadcom сообщил о признаках эксплуатации обеих уязвимостей. Ранее Mandiant описала операции UNC3886, где атакующие использовали zero-day-ошибки CVE-2023-34048 и CVE-2023-20867, перемещаясь между vCenter, ESXi и гостевыми системами через механизмы VMware Tools.

Мини-чек-лист состояния хоста:

• SSH: выключен после завершения работ;
• shell: выключен;
• сборка: сверена с исправленной версией;
• Secure Boot и TPM: включены, если поддерживаются;
• удалённый syslog: работает;
• прямой вход: ограничен административными IP.

Lockdown Mode или его аналог должен блокировать обход центрального управления. На включение SSH, изменение firewall и массовое выключение ВМ нужны отдельные оповещения. Логи следует выводить с хоста: локальные записи атакующий может очистить. Как формулируют эксперты Mandiant, «hardening is not a one-time task» — configuration drift, то есть постепенное отклонение настроек от безопасного профиля, приходится отслеживать постоянно.

Слой 3. Виртуальные машины и бэкапы: последняя защита тоже под атакой

EDR внутри виртуальной машины остается важным элементом защиты, но его возможности заканчиваются на границе гостевой ОС. Если команды поступают со стороны скомпрометированного гипервизора, защитный агент может не увидеть выключение ВМ, копирование её дисков или изменение виртуальной сети.

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

Sophos отмечала попытки воздействия на резервные копии в 94% исследованных ransomware-инцидентов. Успешными оказались 57% таких попыток, а при повреждении бэкапов расходы на восстановление возрастали в восемь раз. Типичная последовательность атаки выглядит так:

1. Злоумышленник получает доменную или административную учетную запись.
2. Входит в систему резервного копирования.
3. Удаляет задания, snapshots и доступные репозитории.
4. После уничтожения путей восстановления запускает шифрование datastore.

Чтобы резервная инфраструктура не пала вместе с производственной, необходимо разделить контуры управления:

• использовать разные аккаунты администраторов виртуализации и резервного копирования;
• включить отдельную MFA для доступа к бэкап-системе;
• вывести репозиторий из производственного домена;
• хранить хотя бы одну immutable-копию, которую нельзя изменить или удалить до окончания заданного срока;
• предусмотреть air gap — логически или физически отделённую копию, постоянно недоступную из основной сети;
• регулярно проверять полное восстановление контроллера домена, vCenter и критичных ВМ.

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

Проверка перед следующим окном обслуживания

Перед очередным обновлением проверьте пять пунктов:

• панели управления и интерфейсы гипервизоров недоступны из пользовательских VLAN;
• привилегированные аккаунты отделены от повседневных и защищены FIDO2/WebAuthn;
• SSH и shell выключены либо ограничены адресами и временем работ;
• журналы vCenter, гипервизоров, AD и бэкапов уходят на внешний сервер;
• хотя бы одна резервная копия не зависит от производственного домена и прошла полный тест восстановления.

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