Харденинг zVirt: защищаем виртуальную среду от хакеров
Привет! Мы продолжаем рассказывать о нашей концепции Хардкор ИТ на примере харденинга реальных сервисов. В прошлый раз мы укрепляли инфраструктуру и усложняли атаки на Microsoft Exchange, а сегодня речь пойдет об отечественной платформе виртуализации вычислительных ресурсов zVirt от компании Orion soft.
На связи Симкин Кирилл, ведущий инженер дирекции инфраструктурных проектов Positive Technologies.
И снова начнём с истории из жизни. Один из наших клиентов поделился деталями атаки, в результате которой злоумышленники зашифровали диски многих виртуальных машин на его платформе виртуализации. Другой наш партнер рассказал такую историю — некоторые виртуальные машины в его парке начали активно, не характерно для них, потреблять процессорные мощности. Дальнейшее расследование показало, что хакеры получили доступ к платформе виртуализации через скомпрометированный каталог Active Directory и установили на серверы майнеры. При чем тут виртуализация? А скомпрометирован каталог был через небезопасное подключение Active Directory к платформе виртуализации, когда учетные данные передавались в открытом виде через сеть. И, конечно, неверно было назначать администраторами платформы виртуализации учетные записи, входящие в группу доменных администраторов Active Directory.
Эти истории сподвигли меня на то, чтобы разобрать проблему безопасности виртуальных сред с помощью методики Хардкор ИТ. Конечно, время вспять мы не повернем, но помочь героям наших кейсов и другим компаниям избежать подобных атак в будущем — вполне.
Прежде всего, хочется сказать несколько слов о выборе сервиса, на котором я решил испытать нашу концепцию. Конечно, здесь не обошлось без актуальной сегодня темы импортозамещения:
до 2025 года все российские компании с государственным участием и органы государственной власти обязаны перейти с программного обеспечения зарубежных вендоров на системы из реестра отечественного ПО — к ним относится и zVirt. Более того, zVirt уже занял значительную долю рынка и развернут на 40% замещенных узлов VMware vSphere в России и, судя по всему, процент будет только расти.
С ростом популярности платформа zVirt также будет становиться все более привлекательной целью для хакеров, потому что через нее можно взломать сервисы, которые работают в виртуальных машинах. Очевидное решение для защиты от атак — использовать мощные сканеры и средства защиты под управлением опытной команды SOC. Замечательно, если все это у вас есть, и тем не менее, в дополнение к инструментам ИБ, для минимизации рисков еще можно использовать харденинг. Мы разберем одну из типовых схем установки zVirt и связанные с ней потенциальные проблемы, а затем постараемся устранить их, не прибегая к дополнительным средствам.
Пример типовой схемы установки
Рассмотрим платформу виртуализации поближе: в этом разборе за основу взят zVirt. версии 4.2. Вот как выглядит одна из распространенных типовых схем.
Эта схема установки zVirt включает в себя несколько гипервизоров, подключенных к блочным устройствам (LUN) по протоколам FC или iSCSI, либо к дискам с файловой системой по протоколу NFS3 или NFS4. Гипервизоры с доступом к одному и тому же набору устройств можно объединить в кластер, что необходимо для живой миграции виртуальных машин и работы службы High Availability. Каждый гипервизор имеет одно или несколько сетевых подключений с разделением по VLAN. Виртуальные машины подключаются к виртуальным сетевым адаптерам, каждый из которых привязан к определенной VLAN внешней сети.
В этой схеме управляющий сервер виртуализации находится в виртуальной машине HostedEngine, для работы которой на определенном гипервизоре требуется специальная настройка. Управляющий сервер и каждый гипервизор постоянно связываются через сеть management VLAN. Управление виртуализацией осуществляется через веб-консоль, работающую на управляющем сервере. Для аутентификации и авторизации могут использоваться как локальные учетные записи и группы, так учетные записи из внешних источников: LDAP, Active Directory, FreeIPA и др.
Типовая схема установки и что с ней не так
Описанная выше типовая схема установки не является уникальной, с теми или иными нюансами так могут быть развернуты, помимо zVirt, и другие платформы виртуализации. Точнее, они уже развернуты, и учитывая идущий процесс импортозамещения, сейчас платформы виртуализации, не входящие в реестр отечественно ПО, заменяются на таковые из этого реестра, в том числе на zVirt. И процесс миграции обычно сводится к тому, что новая платформа виртуализации повторяет схему предыдущей, и гипервизор за гипервизором, виртуальные машины одну за одной переносят из старой платформы в новую. И сжатые сроки, и то, что схема установки новой платформы повторяет схему установки предыдущей платформы виртуализации, в какой-то степени способствуют тому, что не уделяется должное внимание планированию. А это вполне влияет на устойчивость новой платформы виртуализации к взлому. Как вы увидите дальше, нужно учесть некоторые нюансы, и легче всего их учесть на этапе разворачивания платформы виртуализации, до того, как началась миграция и создание виртуальных машин.
Типовая схема установки zVirt может иметь неоптимальные настройки, влияющие на безопасность. Например, для доступа через SSH в ОС гипервизоров используется учетная запись root с паролем. Или для доступа в ОС гипервизоров и в web-консоль zVirt часто применяются неперсонифицированные учетные записи. Еще одной проблемой является то, что несколько пользователей могут одновременно подключаться к одной виртуальной консоли виртуальной машины без уведомления друг друга, что позволяет как минимум одному пользователю следить за действиями другого, а то и выполнять действия в ОС виртуальной машины от имени другого пользователя.
Дальше, неверно настроенное зонирование для блочных устройств или экспорт NFS, а также избыточные правила на межсетевом экране, позволяют подключать эти устройства не только к гипервизорам кластера zVirt, что в случае непреднамеренных действия может привести к порче данных, а в случае злонамеренных — дает возможность украсть или модифицировать данные.
Кроме того, администраторы часто не завершают сеанс пользователя ОС в виртуальной машине и закрывают консоль. Сервер с графическим интерфейсом в виртуальной машине автоматически блокирует сессию спустя некоторое время. Если же на нем установлен текстовый видеорежим, то сессия может оставаться открытой неограниченно долго. В итоге другой пользователь, открывший виртуальную консоль, получит доступ в эту открытую сессию.
Также есть возможность установки RPM-пакетов из файловой системы посредством DNF или RPM без проверки цифровой подписи пакета, что позволяет установить скомпрометированный RPM-пакет.
Есть также архитектурная особенность zVirt (на самом деле, не только zVirt): пользователь root на гипервизорах может получить доступ к содержимому дисков виртуальных машин.
Всё вышеперечисленное (и не только, в конце концов, ОС гипервизора и управляющего сервера базируется на дистрибутиве Linux общего назначения, имеющего свои нюансы настройки и потенциальные уязвимости) может быть использовано для проведения атаки на платформу виртуализации.
Матрица MITRE ATT&CK, описывающая тактики и техники, которыми злоумышленники пользуются в своих атаках на корпоративную инфраструктуру (если вы не знаете, что это, то в статье «А можно по-русски? Можно: делимся интерактивной и user-friendly матрицей MITRE ATT&CK на русском языке…» описана начальная информация для ознакомления), содержит 14 тактик и более 140 техник, подходящих для атак на приведенную выше схему установки zVirt.
Настройки zVirt «по умолчанию» предполагают реализацию только 2 из 43 превентивных контролей (в данном случае «контроль» — это набор мер по предотвращению злонамеренных действий и уменьшению последствий, в случае если злонамеренные действия случились) минимальный путь злоумышленника составит три шага и займет, по нашим расчетам, менее 22 часов. Вот как может выглядеть его путь в системе.
Прокачиваем защиту zVirt и усложняем жизнь хакерам
Очевидно, что есть простор для улучшения безопасности, а значит самое время обратиться к методике Хардкор ИТ. Начнем с общих и даже банальных рекомендаций, затем попробуем усилить контроль учетных записей и затруднить доступ к виртуальной среде.
Обновления и лишние сервисы
Самое очевидное — используйте только поддерживаемые производителем версии ПО и следите за выпуском новых обновлений, которые содержат исправления ошибок и закрывают уязвимости, и, каким бы странным ни показался этот совет, — устанавливайте их! Принцип «работает — не трогай» справедлив только до тех пор, пока злоумышленник не воспользуется незакрытой уязвимостью.
По умолчанию на гипервизорах и управляющем сервере виртуализации запускается предопределенный набор сервисов, не все из которых могут быть необходимы для функционирования системы. Такие сервисы потенциально могут иметь уязвимости («нет абсолютно здоровых пациентов, есть недообследованные»), и их следует выключить или, если это невозможно, закрыть прослушиваемый сетевой порт локальным сетевым экраном.
В параметрах SSH-сервера на гипервизорах и сервере управления виртуализацией по умолчанию разрешена аутентификация через общий программный интерфейс сервисов безопасности (Generic Security Services API, GSSAPI). Эта функция может иметь потенциальные уязвимости и работает, даже если вы используете только локальные учетные записи. Чтобы отключить ее, установите в файле /etc/ssh/sshd_config параметр GSSAPIAuthentication значение no и перезапустите sshd.
Учетные записи и бесконечные сессии
Прежде всего, нужно запретить регламентом выполнение рутинных операций под учетной записью root и admin в ОС гипервизоров, управляющего сервера и в веб-консоли zVirt. Создайте персонифицированные учетные записи с тем минимальным набором полномочий, которые необходимы пользователю, использующему эту учетную запись, для выполнения задач на платформе виртуализации.
Аутентификацию с пустым паролем в ОС нужно выключить. Сделать это можно разными способами, но лучше всего использовать утилиту authselect и указать параметр профиля without-nullok .
Чтобы исключить проблему с бесконечно открытыми SSH-сессиями до гипервизоров или управляющего сервера zVirt, их длительность нужно ограничить. Здесь мы столкнемся с тем, что zVirt использует OpenSSH версии 8 и не имеет своих средств контроля длительности бездействия пользователя в SSH-сессии и вообще длительности SSH-сессии. Кроме того, у нас не получится сделать исключение для учетной записи root, которая не должна иметь ограничений в этом смысле. Контроль длительности в этом случае можно обеспечить альтернативными средствами, и можно, например, добавить в конец файла .bash_profile в домашнем каталоге пользователя на гипервизоре (и управляющем сервере) строку export TMOUT=3600, где 3600 — максимальное время сессии в секундах.
Если в качестве источника учетных записей платформы виртуализации используются Microsoft Active Directory, FreeIPA, LDAP-каталоги и другие сервисы, то стоит уделить отдельное внимание их защите. Они при атаке обязательно будут «пробоваться на зуб» злоумышленником. Настройки подключения внешнего источника учетных записей должны быть безопасными, т.е. не должны передаваться ученые данные через сеть в открытом виде. К слову, в wiki Orion Soft есть статья, описывающая подключение Active Directory, и она состоит из двух частей… Инженер партнера выполнил только первую часть, позволяющую выполнять аутентификацию через каталог, но по какой-то причине проигнорировал вторую часть, в которой настраивалось шифрование, что и привело к истории, упомянутой в начале статьи.
И отдельно стоит указать, что доменные учетные записи, использующиеся для доступа в платформу виртуализации, не должны входить в привилегированные группы каталога, наподобие доменных администраторов. Тогда компрометация «узко специализированной» учетной записи, в данном случае администратора виртуализации, не позволит скомпрометировать весь каталог, хотя, конечно, невозможно не согласиться, что, фраза «компрометация учетной записи администратора платформы виртуализации» в любом случае звучит не очень оптимистично.
Шифрование и контроль доступа
Выше упоминалось, что пользователь с правами root может получить доступ из ОС гипервизора к содержимому дисков виртуальных машин. Чтобы защитить данные от просмотра или копирования, диски нужно шифровать.
Также следует заострить внимание на конфигурации протоколов SSL и TLS: при создании новых ключей сертификатов используйте RSA-2048, а для обновления или создания новых запросов на подпись сертификатов — SHA-256 или более безопасный вариант.
На гипервизорах и управляющем сервере используйте средства контроля целостности системных файлов и каталогов, такие как AIDE или rkhunter. К слову, пакет AIDE установлен по умолчанию, но ему требуется настройка для запуска сервиса контроля целостности.
Вопрос, который обязательно нужно решать до разворачивания zVirt, поскольку потом может быть сложно изменить: следует обезопасить управляющую сеть zVirt, которая отвечает за связь управляющего сервера с гипервизорами, выделив ее в отдельный сегмент, и разрешить доступ к ней только администраторам.
Еще одна потенциально опасная «заводская» настройка zVirt — возможность установить RPM-пакеты из локальной файловой системы без проверки их цифровой подписи. Для этого могут использоваться менеджеры пакетов DNF или RPM, параметры которых нам и нужно изменить:
Настройки DNF находятся в файле /etc/dnf/dnf.conf. За проверку подписи пакетов из локальной файловой системы отвечает параметр localpkg_gpgcheck, но по умолчанию его там просто нет. Нужно добавить этот параметр в конфигурационный файл и установить значение True.
Настройки RPM находятся в файле /usr/Iib/rpm/macros. Нужный нам параметр называется %_pkgverify_level, и здесь нужно установить значение all.
Пароли и двухфакторная аутентификация
Как вы могли ожидать, здесь я напомню, что для всех учетных записей следует установить требования к сложности и задать время смены паролей. Кроме того, в версии zVirt 4.2 можно подключить двухфакторную аутентификацию в административном и пользовательском порталах — этим, мягко говоря, не следует пренебрегать.
Далее, следует учесть, что по умолчанию в zVirt при старте загрузчика ОС гипервизора и управляющего сервера можно менять конфигурацию загрузки ОС без ввода пароля. Это позволяет атакующему, имеющему физический доступ к серверу, модифицировать, в том числе, параметры загрузки ядра Linux, поэтому обязательно нужно устранить этот недочет, и установить в загрузчике ОС пароль на модификацию параметров загрузки.
Свой кластер для виртуальной машины с HostedEngine
Если злоумышленник взломает гипервизор и получит права root, ему станут доступны диски виртуальных машин на этом гипервизоре. Подобная атака может иметь место, например, вследствие эксплуатации возможной уязвимости гипервизора, позволяющей злоумышленнику попасть из ОС виртуальной машины в ОС гипервизора. Чтобы предотвратить компрометацию виртуальных дисков виртуальной машины Hosted Engine, нужно создать для нее отдельный кластер виртуализации, и разрешить подключение LUN (или диска NFS) с виртуальным диском Hosted Engine только к гипервизорам этого кластера.
В зависимости от технологии подключения СХД зависит то, как мы будем это делать. Если используется FC или iSCSi, то можно создать общую для всех гипервизоров сеть хранения данных и запретить доступ к определенным LUN с помощью зонирования для FC и ограничения списка инициаторов iSCSI. Вот как это выглядит на схеме:
При использовании NFS с общей сетью хранения данных, ограничить доступ гипервизоров к файловой системе можно только на базе IP-адресов. Это не лучшая идея с точки зрения безопасности, поэтому нужно физически отделить сеть хранения данных виртуальной машины с управляющим сервером (Hosted Engine) от сетей хранения данных других виртуальных машин. Этот вариант можно реализовать так, как показано на схеме ниже.
Если же платформа виртуализации уже развернута без yчетa этой рекомендации, то можно в уже действующей платформе виртуализации создать отдельный кластер виртуализации для Hosted Engine с учетом нюансов, описанных выше, и воспользоваться процедурой перемещения виртуальной машины с Hosted Engine в другое хранилище.
Как вы могли заметить, мы не использовали сторонние решения безопасности и не увеличивали число узлов в атаке. Однако наш харденинг заставит злоумышленника потратить на каждый шаг больше усилий, а значит у команды реагирования будет больше времени на обнаружение и устранение угрозы. В результате его минимальный путь в системе останется прежним, но займет уже больше 24 часов, вместо ранее вычисленных 22 часов в системе без харденинга. И все это без дополнительных трат на покупку и внедрение новых средств защиты.
Отмечу, что это не очень большое увеличение времени, однако, расчет сделан по минимальному пути перемещения злоумышленника между элементами платформы виртуализации. И это только один из путей, который злоумышленник может использовать, но он, в силу знаний и умений, может предпочесть и другой путь. Наша же задача увеличить время на всех возможных путях компрометации платформы виртуализации, поэтому важно применить все рекомендации по харденингу.
Спасибо, что дочитали статью до конца. Будем рады ответить на вопросы по теме.
