Привет, Хабр! Меня зовут Данил Зарипов, я эксперт центра безопасности (PT ESC) Positive Technologies. Эту статью мы подготовили вместе с моим коллегой Кириллом Масловым, продуктовым экспертом по направлению Asset Management. Мы закрываем наш цикл статей про аудит ИТ-активов, и сегодня поговорим о системах виртуализации.
Виртуальная инфраструктура — это не просто удобный способ экономить железо. Это сложная система, в которой переплетаются гипервизоры, виртуальные машины, сети, системы хранения и управляющее ПО. И если злоумышленник получает к ней доступ, считайте в его руках ключи от любой «двери» в компании. Для защитника же — это огромный пласт данных, который помогает увидеть инфраструктуру целиком, найти уязвимости, отловить небезопасные настройки и вовремя заметить избыточные права доступа.
Как устроена виртуальная инфраструктура изнутри? Почему атакующие всё чаще охотятся за ней? И главное — что с этим делать защитникам, чтобы не дать превратить свои сервера в чужой ботнет? Давайте разбираться на примере продуктов VMware!
Анатомия виртуальной инфраструктуры
Начнём с базы, чтобы у всех картина была полной. Система виртуализации состоит из нескольких ключевых компонентов, каждый из которых важен для понимания того, как устроена виртуальная инфраструктура и где в ней могут скрываться риски.
Гипервизоры — серверы, чьи аппаратные ресурсы используются для работы виртуальных машин. Гипервизор выступает прослойкой между железом и виртуалками, распределяя мощности. В экосистеме VMware они называются ESXi — это фундамент всей виртуальной инфраструктуры.
Виртуальные машины (ВМ)— системы, внутри которых установлены ОС, а поверх них работают приложения, базы данных, сервисы — всё, что реализует бизнес-логику. Это те же серверы, только упакованные в файлы и запущенные поверх гипервизора. Именно ВМ чаще всего становятся целью атакующих — в них данные и сервисы.
Системы хранения данных — неотъемлемая часть любой серьёзной виртуализации. Весь объём информации нужно где-то надёжно хранить, и СХД берут это на себя. Они могут быть отдельными устройствами или программными решениями, но за ними нужно следить — от их доступности зависит работоспособность всей инфраструктуры.
Виртуальные сети — слой, без которого виртуализация невозможна. Чтобы компоненты взаимодействовали там, где нужно, и не взаимодействовали там, где не нужно, администраторы организуют виртуальные сети, сегментируют трафик, настраивают изоляцию. С точки зрения безопасности это важно: через плохо настроенные сети могут проходить маршруты горизонтального перемещения.
Управляющее ПО — мозг всей виртуальной инфраструктуры. В случае с VMware это vCenter Server — центральная консоль для управления конфигурациями, добавления и удаления компонентов, назначения прав. Доступ к управляющему ПО даёт атакующему контроль над всем, что происходит в виртуальной среде.
Учетные записи пользователей управляющего ПО, гипервизоров и др. — у них есть роли и права доступа. Для безопасности это критично: мы точно должны знать, какие учётные записи существуют, какие у них права и не затесалась ли среди них учётка уволенного сотрудника или запись с избыточными полномочиями.
Взгляд атакующего: от vCenter до ботнета
Информации внутри менеджеров виртуальных машин так много, что она представляет огромный интерес для злоумышленников. Атаки на инфраструктуру так или иначе начинают задевать виртуальный слой, и через него злоумышленники проламываются уже во всю организацию.
Чем же может завершиться атака на менеджер виртуальных машин? Один из самых мрачных сценариев — создание ботнета из вашей же виртуальной инфраструктуры. Получив доступ к управляющему ПО, злоумышленник видит все виртуальные машины и при желании может превратить их в зомби-сеть. Да, вы скажете, что зомби-машины бывают и физическими, но что мешает сделать то же самое с виртуалками?
Например, компания MITRE давно отслеживает эту тенденцию, и у нее есть отдельная таблица тактик и техник для атак на виртуальную инфраструктуру. Если заглянуть в неё, можно обратить внимание, что абсолютно все они включены в основную Enterprise-таблицу. Изучать их стоит хотя бы для того, чтобы лучше понимать, какие методы воздействия на инфраструктуру могут применить злоумышленники для захвата вашей виртуальной среды.
Но даже если не лезть в сложные техники, простой доступ к менеджеру виртуальных машин даёт хакеру несколько крайне ценных вещей:
Заметки администраторов. Очень часто администраторы оставляют себе записки, чтобы потом разобраться в инфраструктуре. В полях для заметок могут содержаться логины, пароли, адреса, имя ответственного за ту или иную ВМ и другие сведения, которые помогают пройти дальше. Получив доступ к менеджеру, злоумышленник не может сразу зайти в виртуальную машину — перед ним появится окно логина. Но если в заметках лежит пароль, окно перестаёт быть преградой.
Полная карта инфраструктуры. Когда виртуальные машины создаются, администраторы раскладывают их не как попало, а структурированно — иначе в этом зоопарке невозможно было бы ориентироваться. В менеджере всё это представлено в древовидном виде. Пробежавшись по дереву, злоумышленник без труда найдёт продовые сервера, критичные системы и виртуальные машины, представляющие особый интерес. Ему даже не придется выискивать что-то самому, достаточно выгрузить через API все дерево папок и ВМ, загрузить в LLM и спросить нейронку, что из этой информации важно. Удобно! Теперь вашу инфраструктуру знает злоумышленник (а благодаря оказавшимся у нейронки данных – весь мир). Зная IP-адреса или FQDN, можно уже более точно прицеливаться, искать уязвимости и атаковать дальше.
Взгляд защитника: инвентаризация, конфигурации и доступы
Мы посмотрели на виртуальную инфраструктуру глазами атакующего, а теперь давайте разберёмся, как на неё смотрят те, кто должен её обслуживать и защищать.
Для ИТ-специалистов виртуальная инфраструктура — это в первую очередь объект инвентаризации. Нужно видеть все компоненты, понимать, как они устроены, как связаны между собой, в каких сетях находятся, какие есть рычаги управления. Без этого невозможно ни нормально администрировать инфраструктуру, ни тем более усиливать её защищённость.
Для ИБ-департамента всё сказанное справедливо вдвойне. Мы можем защитить только то, о чём знаем. Поэтому инвентаризация виртуальных компонентов — обязательный первый шаг. Увидев все элементы, мы получаем возможность контролировать безопасность их конфигураций: как настроены компоненты, какие параметры выставлены, нет ли где-то откровенно слабых мест.
Видя, в каких сегментах находятся виртуальные машины и как они могут взаимодействовать между собой, мы можем замечать те маршруты, которые злоумышленники используют для горизонтального перемещения. Виртуальная сеть, настроенная без учёта безопасности, может дать атакующему возможность перепрыгивать из одного сегмента в другой там, где этого быть не должно.
И наконец, контроль избыточных прав доступа — в виртуальной инфраструктуре, как и в любой другой, со временем накапливаются учётные записи, которые давно пора удалить или почистить. Это может быть учётка сотрудника, который уволился год назад, ненужная служебная запись, созданная давным-давно для какого-то проекта, или просто учётка, у которой внезапно оказалось слишком много прав. Всё это важно отслеживать и вовремя исправлять.
Инструменты аудита: от сканирования до моделирования атак
Теперь расскажем, как мы в Positive Technologies помогаем сделать виртуальную инфраструктуру безопаснее и не дать злоумышленникам её скомпрометировать. Начнём с двух продуктов, которые отвечают за уязвимости и конфигурации.
MaxPatrol VM и модуль MaxPatrol HCC. Уязвимости и настройки конфигураций под контролем
MaxPatrol VM позволяет выстроить процесс управления уязвимостями. В карточке уязвимости видна её критичность, вектор CVSS, дополнительная информация и рекомендации по исправлению. Кроме того, MaxPatrol VM показывает, какое программное обеспечение вообще установлено на активе и какая у него конфигурация.
Модуль MaxPatrol HCC нужен для проверки соответствия стандартам и харденинга инфраструктуры. Он фокусируется именно на конфигурациях установленных компонентов и умеет замечать в них небезопасные настройки. Мало просто найти проблему — MaxPatrol HCC объясняет, почему эта настройка опасна, даёт рекомендации по исправлению и позволяет отследить, применилось ли исправление на самом деле.
Два наглядных примера из реальной жизни:
Первый касается гипервизора ESXi. Мы настоятельно рекомендуем запретить прямой доступ по SSH к гипервизорам. Если в вашей инфраструктуре используется vCenter (а так бывает почти всегда), то он и так управляет гипервизорами, и прямой SSH для ручного управления просто не нужен. Если этот доступ не отключить, он может стать открытой дверью для злоумышленника, который через него скомпрометирует гипервизор.
Второй пример — конфигурация самого vCenter. Там есть учётная запись vpxuser, которая используется для того, чтобы vCenter управлял гипервизорами. Стойкость пароля для этой учётной записи должна быть на высоте. Если пароль слабый и его скомпрометируют, злоумышленник получит доступ ко всей виртуальной инфраструктуре.
MaxPatrol SIEM. Обогащение событий данными из vCenter
Но управление уязвимостями и контроль настроек — это только часть работы. Данные из виртуальной инфраструктуры могут пригодиться и при расследовании инцидентов. MaxPatrol SIEM умеет использовать информацию из vCenter с помощью табличных списков Asset Grid. В поле запроса передаётся запрос из MaxPatrol VM, и после установки список автоматически наполняется данными об активах и регулярно обновляется.
Например, можно создать табличный список, отслеживающий критические виртуальные машины. Это те ВМ, которые представлены в vCenter и имеют важные роли — скажем, доменные контроллеры. Все эти данные попадают в табличный список, и дальше правила корреляции могут с ним взаимодействовать.
Ниже пример того, как два правила корреляции работают с таким списком: одно отслеживает клонирование критичных виртуальных машин, другое — загрузку данных с этих машин.
Для тех, кто хочет добавлять критичные машины вручную, существует его брат-близнец — табличный список VSphere_Critical_VMs_Custom, который можно заполнять руками. Правила корреляции работают с обоими.
MaxPatrol Carbon. Моделирование путей атак
Данные из виртуальной инфраструктуры пригодятся не только для обнаружения проблем, но и для того, чтобы понять, как этими проблемами может воспользоваться злоумышленник. MaxPatrol Carbon анализирует информацию из MaxPatrol VM (активы, сетевая связность, уязвимости, мисконфигурации, права пользователей и др.) и строит потенциальные пути хакера до критически важных систем компании.
Вот пример из реального стенда:
MaxPatrol Carbon показывает цепочку: с помощью учетной записи хелпдеска можно захватить vCenter, через него пройти в виртуальную машину, где оставлены учётные данные одного из топ-пользователей, и уже с этими данными зайти на его машину. MaxPatrol Carbon не просто говорит о существовании такого пути, а объясняет, что это за путь, насколько он опасен (время атаки TTA – time to attack, количество шагов, сложность реализации и др.) и дает рекомендации, как его устранить.
Практика аудита: PDQL-запросы для vCenter
Теперь перейдём к самому вкусному — к конкретным запросам, которые помогают вытащить из виртуальной инфраструктуры максимум полезной информации. Все эти запросы выполняются в MaxPatrol VM и дают ответы на ключевые вопросы, которые должен задавать себе любой защитник.
Поиск всех vCenter в инфраструктуре
Самый первый и самый простой запрос — вывести все активы, на которых установлен софт типа vCenter Instance. После аудита они появятся в базе, и вы увидите, какие vCenter вообще есть в вашей инфраструктуре, когда они сканировались в последний раз и всё ли с ними в порядке.
Но если нет уверенности, что все vCenter уже просканированы, можно пойти другим путём. Проверяем, какие машины в инфраструктуре имеют открытые порты, типичные для vCenter.
Для этого нужно предварительно просканировать инфраструктуру в режиме host discovery, service discovery или пентеста — желательно массово, по большому количеству подсетей и портов. Берём типичные порты, запрашиваем их, склеиваем в количество совпадений для каждого актива и выводим только те, где открытых портов больше пяти. Так мы гарантированно найдём все vCenter, даже те, для которых не выполнялся аудит.
Проверка доменов, подключенных к vCenter
В vCenter можно заходить с помощью доменных учётных записей, поэтому критически важно проверять, какие домены вообще подключены к каждому vCenter.
Формируем запрос, который достаёт активы с софтом vCenter Instance и выводит все привязанные к ним домены:
А затем джойним эту информацию с активами типа Active Directory, которые уже есть в инфраструктуре:
Особое внимание стоит обратить на учётные записи внутри самого vCenter. Отдельным запросом достаём их и смотрим, не затесался ли среди них администратор домена. Если администратор домена одновременно является администратором vCenter — это серьёзная проблема, которую нужно исправлять. Так делать нельзя.
Поиск гипервизоров и сверка с реальностью
Следующий кусочек мозаики — гипервизоры. В случае с VMware ESXi мы достаём из vCenter данные о всех привязанных к нему ESXi-хостах и джойним их с активами типа ESXi Host, которые есть в MaxPatrol VM. В идеальном мире все гипервизоры, которые знает vCenter, должны присутствовать в базе и регулярно сканироваться.
Но бывает иначе. В запросе может обнаружиться ESXi, который прописан в vCenter, но актива с таким именем в VM нет. Это странно, потому что при сканировании через API активы должны создаваться автоматически. Возможно, гипервизор уже выведен из эксплуатации и его просто забыли удалить из менеджера. А возможно, случилось что-то гораздо более плохое, и этот ESXi требует немедленного восстановления.
Сверка виртуальных машин
И последний кусочек — виртуальные машины. Достаём из vCenter все ВМ, представленные в дата-центрах, и клеим их на активы в инфраструктуре через VM ID. Здесь есть важный нюанс: активы создаются только для включённых виртуальных машин. Выключенные ВМ при сканировании самого vCenter не создаются, и в гриде мы их не видим.
Если среди включённых ВМ обнаруживаются машины, которых нет в базе, или наоборот, в базе есть активы, которых нет в vCenter, — это повод разобраться, что происходит с инфраструктурой.
Как получить эти данные: сканирование vCenter
Перед тем как выполнять все эти запросы, нужно просканировать сам vCenter. Расскажем, как это делается.
Создание учётной записи. Начинать стоит с создания учётной записи на самом vCenter. В руководстве пользователя всё подробно описано, но если кратко — нужна учётная запись с правами read-only на всю инфраструктуру, на все компоненты.
Запуск задачи. Создав учётную запись, добавляем её в менеджер учётных записей в MaxPatrol VM. Дальше создаём задачу на сбор данных, указываем эту учётную запись, при необходимости меняем порт, параметры шифрования и прочие настройки. Но, как правило, в этом нет необходимости. Запускаем задачу на сканирование vCenter-сервера, используя профиль vSphere Audit.
Что происходит под капотом. Продукт подключается к vCenter через API и начинает собирать данные. Сначала узнаёт о самом vCenter, затем получает сведения о том, какие гипервизоры с ним ассоциированы, снимает с них параметры. Дальше, увидев виртуальные машины, которые запущены на этих гипервизорах, создаёт для них активы.
Важный момент: активы, созданные таким путём, довольно сильно ограничены по набору данных. Мы можем узнать только операционную систему (или хотя бы её семейство), vCenter ID и IP-адрес. Базовый набор, но он уже позволяет понять, что актив существует, и дальше выполнить его полноценный аудит нужным профилем.
Все эти четыре шага выполняются автоматически, под капотом, и не требуют от пользователя никаких дополнительных действий. Просканировали vCenter — получили взгляд практически на всю виртуальную инфраструктуру.
Почему важно сканировать ещё и по SSH
Мы поговорили про аудит профилем vSphere Audit, но настоятельно рекомендуем выполнять аудит менеджера виртуальных машин ещё и профилем Unix SSH Audit. Почему это так важно?
Именно благодаря SSH-профилю мы увидим гораздо больше данных о самом хосте, чем через API: узнаем, какие версии программного обеспечения установлены на активе, получим дополнительные сведения, которые помогут усилить защищённость. И главное — сможем увидеть уязвимые компоненты и вовремя обновить программное обеспечение, закрыв дыры до того, как до них доберутся злоумышленники.
Сканирование по SSH не создаёт отдельный актив — это всё тот же vCenter, просто с него снимается более глубокий слой данных о самой ОС и ее настройках. А информации о защите этой критически важной машины становится куда больше.
Три частых вопроса про аудит виртуальной инфраструктуры
В ходе внедрений и общения с клиентами мы регулярно слышим одни и те же вопросы про аудит систем виртуализации. Разберём три самых частых — чтобы вы знали, что столкнулись не только вы, и как эти проблемы решаются на практике.
Рост количества активов при ограниченной лицензии
Первый вопрос — про рост количества активов и лицензирование. После сканирования vCenter активов в системе становится больше, но на лицензию MaxPatrol VM они не влияют. В лицензии учитываются только те активы, которые были подвергнуты аудиту или пентесту. ВМ из vCenter лишь подсвечивают необходимость их дальнейшего сканирования, если вы решите, что это нужно.
Ошибочное объединение двух разных виртуальных машин
Второй вопрос — про ошибочное объединение виртуальных машин. Если клонировать важный сервер для тестов, система может увидеть две одинаковые машины и не различить клон и оригинал. В результате события от них смешаются, а в базе появятся лишние записи. Поэтому при клонировании важных ВМ меняйте hostname, IP и MAC, а для машин-шаблонов делайте sysprep.
Сканирование vCenter только по API и не сканировать по SSH
Третий вопрос: можно ли сканировать vCenter только по API, без SSH? Теоретически, конечно, никто вам этого не запретит, но мы крайне не рекомендуем так делать. API даёт только информацию об инфраструктуре, но не о самом сервере: версиях софта, уязвимостях ОС, открытых сервисах. Сканируйте и по API, и по SSH — это один актив, на лицензию он влияет один раз, а информации о защите критической машины будет гораздо больше.
Альтернативные системы виртуализации
Мы все время говорили про VMware vCenter — и это не случайно. По нашим опросам, VMware остаётся самой массовой платформой: 39% наших респондентов указали, что используют именно vCenter. Но в последнее время в реальных инсталляциях всё чаще встречаются другие системы виртуализации. Кто-то переходит на альтернативы осознанно, а где-то импортозамещение диктует свои условия.
На текущий момент наши продукты поддерживают:
VMware vCenter — очевидно, основная платформа, на которой мы показывали все примеры.
Microsoft Hyper-V — тоже поддерживается, хотя в материале мы на нём не останавливались.
Proxmox — популярная открытая платформа, её используют 21% опрошенных.
zVirt — отечественное решение на базе oVirt, которое активно развивается и набирает популярность.
Еще мы планируем добавить поддержку Альт Виртуализации — это вопрос ближайших релизов.
Особняком стоит Qemu и KVM — здесь поддержка будет, но с небольшой звёздочкой, потому что это скорее компоненты, а не полноценные менеджеры виртуальных машин. Но мы поддержим их с той точки зрения, что если на каком-то активе обнаруживаются эти компоненты, мы сможем собрать с них информацию о запущенных виртуальных машинах и их базовых параметрах. Да, это не будет таким богатым аудитом, как в случае с vCenter, но эти компоненты больше информации не дадут в любом случае. Если вы видите, что какой-то системы в списке нет, а она вам нужна — пишите, это влияет на наш roadmap.
Подводим итоги
Мы закрываем цикл статей «Страшно, когда не видно» темой, без которой современная инфраструктура уже немыслима, — системами виртуализации. За четыре выпуска мы прошли путь от общего взгляда на управление активами до глубокого погружения в сетевые устройства, домены и виртуализацию. И везде возвращались к одной мысли: невозможно защитить то, о существовании чего вы даже не подозреваете.
Чтобы помочь вам с инвентаризацией инфраструктуры в MaxPatrol VM и MaxPatrol SIEM, мы подготовили экспертное руководство по аудиту активов и скрипты автоматизации. В нем доступны все PDQL-запросы, о которых мы рассказали, примеры из предыдущих вебинаров и комментарии по их использованию. А в скрипте на GitHub они упакованы в готовый инструмент, который отправляет запросы в API MaxPatrol VM, проверяет активы и даже оценивает, насколько они готовы к защите со стороны MaxPatrol SIEM.
Спасибо, что были с нами на протяжении всего цикла. Если остались вопросы или есть идеи для новых тем — пишите, обсудим!
Другие статьи цикла:
Страшно, когда не видно: взгляд внутрь домена
Страшно, когда не видно: аудит сетевых устройств
Страшно, когда не видно: управление активами как фундамент кибербезопасности
Данил Зарипов
Специалист экспертного центра безопасности, Positive Technologies
Кирилл Маслов
Специалист группы экспертизы Asset Management, Positive Technologies