Виртуализация как защита от вирусов

Обновлено: 25.04.2024

Джошуа Корман, эксперт подразделения IBM Internet Security Systems, о специфике обеспечения информационной безопасности при виртуализации серверов.

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

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

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

Виртуализация привносит с собой непредвиденные прежде риски. Так было с древнейших времен, сначала кто-то делал изобретение, потом приходило осознание скрытых в нем угроз: изобретатели автомобилей и самолетов на первых порах тоже не думали о безопасности. Такие мысли возникают, когда некоторая новация соприкасается с внешней средой. Известно, что положительный эффект от внедрения виртуализации состоит в том, что она позволяет избавить стандартные серверы от их врожденных недостатков, поскольку с ее помощью на ограниченном количестве физических серверов можно расположить огромное число виртуальных серверов, получая при этом экономию, больший КПД, уменьшение затрат на аппаратное обеспечение, на энергию и все остальное. Но одновременно она открывает дополнительные риски, которые можно разделить на две категории. Возникновение первой группы рисков связано с тем, что виртуальная среда динамична, а многие привычные для нас методы администрирования рассчитаны на статические системы. Риски этого сорта усугубляются тем, что автоматизация управления еще недостаточно развита, и виртуализация требует существенного человеческого участия, а 90% системных нарушений порождают люди. И дело не только в злонамеренности, а скорее в том, что люди не подготовлены к работе в новых условиях. Когда все серверы собраны в одну стойку и виртуализованы, создается ложное впечатление, будто кроме специалистов по виртуализации теперь никто больше и не требуется. Однако специалисты по серверной виртуализации не могут обладать требуемой для обеспечения безопасности квалификацией.

Какие уязвимости можно считать специфическими для виртуальной среды?

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

Чем различаются две составляющие дисциплины Virtualization Security – virtualizing security и securing virtualization?

Виртуализация средств безопасности есть не что иное, как распространение существующих технологий безопасности на виртуальные серверы. Новым является то, что виртуализация повышает КПД серверов, и, как следствие, объем потенциальных рисков в пересчете на единицу оборудования возрастает пропорционально возрастанию величины КПД. Для обеспечения этого типа безопасности используются практически все известные унаследованные технологии, с поправкой на то, что нагрузка на эти средства возрастает. Что касается безопасности виртуализации, то учет особенностей виртуальных систем зависит от особенностей их собственного поведения. Это еще можно назвать интегрированной безопасностью (Integrated Security), поскольку в основе лежит не защита от отдельных уязвимостей, а рассмотрение системы как единого целого. Если мы защищаем физические серверы, то, поставив необходимые межсетевые экраны, мы можем быть спокойны за то, что происходит за ними, но с виртуальными серверами дело обстоит иначе – они динамичны и могут оказывать влияние друг на друга. Поэтому, помимо технологий, в обеспечении безопасности виртуализации заметную роль играют услуги профессиональных экспертов.

Какая роль на этом фоне отводится специализированным устройствам наподобие Virtual Security Appliance или Security Virtual Machine (SVM)?

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

Что же делать?

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

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




О своеобразии текущего момента


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

Очень симптоматично: далеко не все понимают опасность киберкриминала. В среднем 73% пользователей осведомлены о том, что самую большую опасность для их электронных данных представляют киберпреступники и хакеры, но согласитесь, что это не 100% (а ведь если вы спросите, кто ворует кошельки, 100% ответят — воры). Интересно, что американцы остерегаются киберпреступников гораздо меньше, чем жители стран азиатско-тихоокеанского региона — 61% против 82.

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

Судите сами. Уязвимость сетевого протокола SMB операционной системы Microsoft Windows, которой позднее (сейчас я скажу, когда именно) воспользовался вирус WannaCry, была опубликована Microsoft еще в феврале 2017 г. 14 марта 2017 г. — не то чтобы очень оперативно, но уж как смогла — Microsoft выпустила серию обновлений, призванных нейтрализовать уязвимость во всех поддерживаемых операционных системах.

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

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

Виртуализация поможет!


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


Стоит ли игра свеч?

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

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


Защищать или не защищать виртуальные среды от зловредов – вопрос давно и без особой дискуссии закрытый в пользу первого варианта. Другое дело – как защищать? Концепцию безагентового антивируса для платформы VMware мы разработали уже достаточно давно: подробнее о ней можно прочитать в этом посте Евгения Касперского. Но технологии на месте не стоят. Виртуализация привлекает новые прикладные IT-направления, а с ростом её применимости расширяются и специфические требования к защите. Очевидно, что для виртуального десктопа нужно одно, для базы данных – второе, веб-сайтам – третье и так далее. При этом безагентовый антивирус – далеко не единственный вариант защиты, а VMware – хотя и самая популярная, но не единственная платформа виртуализации.

Какие есть альтернативы и какая чему больше подходит?

Agentless (безагентовая) концепция.

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


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


Ну, ОК, а что делать если антивирус работает только с Windows как гостевой ОС на виртуалке, плюс – очень хочется иметь самый полный набор защитных технологий, включая криптографию? Тогда потребуется традиционный продукт для эндпоинтов. Да, его будет проблематично целиком заточить под развесистую виртуальную инфраструктуру, и внимания такое решение потребует больше, но есть случаи, когда такой подход уместен.


А теперь – к практике. Недавно мы выпустили третью версию нашего продукта для виртуальных сред, реализовав в нем обе концепции защиты (Agentless и Light Agent). Помимо VMware мы теперь поддерживаем Citrix XenServer и Microsoft Hyper-V. К уже имеющемуся безагентовому решению для VMware добавился вариант защиты с использованием лёгкого агента для всех трёх платформ. При этом все продукты управляются из единой консоли, что особо важно для мульти-гипервизорных сред, чтобы не создавать консольный зоопарк.

Так каким задачам, какой вариант больше всего подходит?

В общем случае логика выбора защиты такая: для максимальной защиты гостевой Windows нужен лёгкий агент, на других ОС (Linux, OS X) – продукт для эндпоинтов. Увы, во втором варианте применение ограничено из-за соображений производительности и взаимодействия антивируса с фичами самой виртуальной среды. Над поддержкой других ОС лёгким агентом мы работаем. А если критична производительность, при этом ценность и разнообразие данных невысока и к ним ограничен доступ извне – тогда подходит безагентовое решение.

Мы проанализировали типовые прикладные задачи с использованием виртуализации и составили вот такую любопытную табличку.


Это не исчерпывающая и не однозначная картина — в разных организациях условия могут меняться, а список задач расширяться. Её цель – показать модель угроз и методологию оценки задач и приоритетов.

Возвращаемся к заголовку. Ну, что, выбор-то, получается, совсем даже и не сложный!


Предыстория виртуализации


Рис. 1: Пульт управления IBM 7094, где была впервые реализована концепция разделения времени (изображение принадлежит пользователю Wikipedia ArnoldReinhold, лицензировано под Creative Commons BY-SA 3.0)

С чего начиналась современная виртуализация


1971 Representation // Как виртуализацию видели в 1971

Modern Representation // Современное представление

VMM // Монитор виртуальной машины

VM // Виртуальная машина

Operating System // Операционная система

Virtual Machine // Виртуальная машина

Virtual Machine Monitor // Монитор виртуальной машины

Physical Machine/Hardware // Физическая машина/железо

Рисунок 2: Сравнение: представление Попека и Голдберга vs современное обобщенное представление (взято из usenix)

Глоссарий по виртуализации


Рисунок 3: Типы виртуализации

Bare metal hypervisors // Гипервизоры для голого железа

Hosted Hypervisors // Хостовые гипервизоры

Hardware virtualiaztion // Аппаратная виртуализация

Интуитивное представление о виртуализации

В вышеприведенном глоссарии, как и в любой шпаргалке, для полноты восприятия не хватает контекста, зато много модных словечек (см. рис. 4). Мы попытаемся обобщить важнейшие из перечисленных элементов, пожертвовав некоторыми деталями для большей ясности. Как понятно из глоссария, один из самых сложных участков работы при виртуализации связан с обработкой привилегированных/чувствительных инструкций.

Привилегированными называются такие инструкции, которые позволяют вызывающей стороне получить контроль над критически важными ресурсами. Они принципиально важны для защиты системы от вредоносных действий и неконтролируемых программ из пользовательского пространства. Таковы, например, инструкции HLT (контроль потока выполнения в CPU с возможностью приостановки), влияние на отображение в памяти путем инвалидации страничных записей в буфере ассоциативной трансляции (INVLPG) или доступ к специальным регистрам (RDMSR, WRMSR, MOV CR). Привилегированные инструкции могут предоставить неограниченный доступ хост-машине (например, контроль над всеми обработчиками прерываний).

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

Виртуализуй и защищай


Рисунок 4: Стек KVM-QEMU и соответствующий поток (изображение представлено пользователем Википедии V4711, по лицензии Creative Commons BY-SA 4.0)

Важнейший довод в пользу виртуализации – использовать ресурсы по максимуму, в то же время, обеспечивая защищенность ресурсов, и их изоляцию друг от друга. Современные гипервизоры, оснащенные новейшими программными и аппаратными возможностями, позволяют создавать разнообразные изолированные виртуальные машины; от классических полнофункциональных операционных систем (скажем, Ubuntu) до современных минимальных MicroVM, выполняющих легковесные ядра (напр., Firecracker + OSv). Изоляция ресурсов, например, памяти, устройств файловой системы и ядра защищает от вмешательства взломанной гостевой VM как хостовую виртуальную машину, так и другие гостевые виртуальные машины.

Например, если на гостевой VM был успешно выполнен эксплойт ядра, и злоумышленник получил на ней права администратора, он все равно не пробьется через изоляцию. Если он не располагает уязвимостью гипервизора, то хост-VM и другие гостевые VM вторжением затронуты не будут, поскольку у них и у взломанной машины ядра отличаются. Как и любая другая стратегия защиты, виртуализация не решает всех проблем; с виртуализацией связаны и присущие только ей уникальные векторы атак. Вот несколько примеров специфических атак, направленных именно на уязвимость виртуализации:

Виртуализуй и атакуй

Многие базовые принципы, благодаря которым виртуализация оказывается столь эффективным и универсальным защитным подходом, можно превратить в оружие. Сама идея не нова, исследования подобных угроз уже производились. Можно упомянуть программу «Bashware«, показавшую, как WSL (виртуализованное решение для выполнения подсистемы Linux под Windows) может быть взято на вооружение для сокрытия вредоносов от всех современных защитных механизмов.

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

Виртуализация с аппаратной поддержкой и KVM

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

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

К счастью, для тех, кто не хочет все строить с нуля, в современном ядре Linux поддерживается KVM (kvm.ko); этот модуль ядра фактически превращает ядро Linux в гипервизор. KVM предоставляет возможности Intel VT-x через интерфейс ioctl (2). Также KVM активно использует встроенные возможности ядра Linux для управления песочницами, которые (в усиленной версии) более известны как виртуальные машины.

История атаки

Такая атака подразумевает привилегированное использование скомпрометированной хост-машины с Ubuntu, на которой включена функция VT-x. Атака использует вредоносные информационные нагрузки (майнеры и вымогатели), незаметно выполняясь на скомпрометированном хосте, прикрытая самодельной виртуальной маскировкой (Рисунок 6)

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



Рисунок 5: Ход атаки

Подготовка камуфляжа для уровня 1

Построим vCloak1, который позволит нам выполнить первый уровень нашей маскировки. Воспользуемся минимальной виртуальной машиной под Ubuntu (мы могли бы с тем же успехом скомпилировать Ubuntu для firecracker) с QEMU. Этот этап реализован при помощи vcloak1.sh, который автоматически выполняется предположительно привилегированной точкой входа:

Листинг 1: Строим уровень 1 виртуального камуфляжа, минимальный вариант Ubuntu на QEMU с virtiofs

В этот момент мы достигли первой границы виртуализации. Как только vCloak1 закгрузится, он выполняет vCloak2, конфигурирующий и выполняющий второй уровень нашего камуфляжа.

Подготовка камуфляжа для уровня 2


Листинг 2: Проверяем KVM и собираем уровень 2 нашего камуфляжа


Листинг 3: vcloak2.py выполняет три контейнера VT-x

Пока все нормально, но что же выполняют эти инстансы firecracker? Для затравки в истории об атаке уже упоминалось, что они выполняют приложения OSv. OSv – это свободное универсальное модульное ядро вида unikernel, рассчитанное на безопасную поддержку единичного немодифицированного приложения Linux в виде microVM поверх гипервизора, в результате чего получается минимальное ядро, совместимое с Linux на уровне двоичного кода. Такие решения как OSv – это, по сравнению с MicroVM, уже следующий шаг на пути к минимализму; когда по ядру unikernel создается на каждое приложение, получается приложение OSv с ядром, ужатым до сухого остатка.

Рассмотрим, как просто собрать приложение OSv из нативного кода на C++:


Листинг 4: Сборка и запуск простой программы на C, где OSv служит оберткой

Аналогично, можно собрать приложение OSv и на Python:

Листинг 5: Собираем и запускаем простую программу на python с OSv в качестве обертки

Как было кратко продемонстрировано выше, OSv – это мощный и легкий способ превращать обычные приложения в приложения Unikernel. В комбинации с микро-виртуальной машиной, например, с Firecracker (или даже с еще более мелкими вариантами аппаратной виртуализации), создается минимальная и при этом высокопроизводительная виртуализованная полезная нагрузка. Подробнее об этом отличном продукте рассказано на странице OSv в GitHub. На данном этапе все, что нам остается доделать – написать нужный код на python для каждого из трех приложений OSv, как мы и обещали.


Рисунок 6: Вложенная виртуализация порой бывает немного запутанной

Вложенная виртуализация

Мы рассмотрели, как уровень за уровнем создавался наш камуфляж, и проследили развертывание вредоносного ПО от первого привилегированного выполнения до создания множества минимальных ядер Unikernel, образующих второй уровень нашего камуфляжа. Эти ядра Unikernel (уровень 2) виртуализованы с применением VT-x, KVM и firecracker поверх другой виртуальной машины с Ubuntu (уровень 1), хотя, firecracker также может использоваться на этом уровне.

Создание майнера

В ходе описываемых исследований предпринималось множество попыток маскировки, создавались как опенсорсные майнеры, пригодные для реального использования, так и минималистичные инструменты такого рода, которые могут послужить только в качестве доказательства осуществимости. Для простоты картины быстро презентуем опенсорсный майнер, разработанный subhan-nadeem:

Листинг 6: Фрагменты кода из майнера

Создаем код вымогателя

Точно, как и в случае майнеров, на роль вымогателей было протестировано много решений. Но ради ясности мы рассмотрим PoC-версию вымогателя под авторством guihermej:

Листинг 7: Фрагменты кода из вымогателя

Создание извлекателя


Листинг 8: Фрагменты кода Извлекателя

Повторение и анализ

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

Отсюда и в дальнейшем память всех различных процессов будет представлена как единый сплющенный двоичный блоб. Все вызовы API и экосистема ОС, заключенные в MicroVM, извне невидимы. На сертификатах MicroVM не отражается конфигурация хоста, эти сертификаты скрыты от хоста (в частности, это позволяет спрятаться от инструментов анализа трафика, воспользовавшись защитой SSL MITM).


Рисунок 7: Программный стек vCloak; цветными линиями обозначены границы отдельных областей виртуализации

Как только MicroVM завершит процесс загрузки, она загрузит три разных ядра Unikernel, основанных на VT-x и Firecracker, и в этих ядрах будет содержаться вредоносная логика. При помощи таких Unikernel-ядер в модель памяти вносится еще один уровень хаоса, не только потому, что здесь добавляется еще один слой виртуализации, но и потому, что у ядра Unikernel пространство пользователя и пространство ядра не отделены друг от друга. Из-за всего этого коверкания серьезно усложняется работа оператора первой хост-машины, который обнаружил первый слой камуфляжа и хочет обратить вспять его логику.

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

Дальнейшие исследования и оптимизация



Рисунок 8: Таблица для самопроверки

  • Извлекатель для совместно используемой памяти – можно настроить извлекатель так, чтобы он делился памятью с вредоносами и тем самым не так сильно светил разделяемые данные.
  • Извлекатель для совместно используемой сети – в некоторых случаях бывает более рационально воровать данные через какой-нибудь сетевой протокол, поскольку за ним могут следить не столь пристально.
  • Вредоносы для промышленного использования – мы экспериментировали с реальными вредоносами, например, xmrig и GonnaCry, и оба можно обернуть в виртуалку без труда.
  • Среда времени исполнения – как vCloak1, так и vCloack2, могут быть представлены в виде минимальной VM, MicroVM, Unikernel или просто крошечного загружаемого ELF, если вложенная виртуализация не требуется. Весь этот уровень опционален.
  • Гипервизор пользовательского пространства – На протяжении всего этого экскурса используется firecracker, но можно реализовать более компактный гипервизор для пользовательского пространства, чтобы еще сильнее ужать полезную нагрузку.
  • Гипервизор пространства ядра – может быть подготовлена собственноручно сделанная альтернатива KVM, которая позволила бы ужать полезную нагрузку и расширить возможности блокировки, но это уже тема для отдельной статьи alternative can be produced to reduce payload size and add cloaking abilities.
  • Укрепление – Можно сделать камуфляж еще эффективнее, воспользовавшись новыми возможностями, например, MAP_EXCLUSIVE, SGX или SVE\SME для более полного сокрытия памяти.
  • Расширенная область атаки на хост – такими возможностями мы не пользуемся, поскольку их обсуждение выходит за рамки этой статьи. Правда, известны уязвимости, которые позволили бы сделать камуфляж еще эффективнее.

Инструменты

Занимаясь исследованием виртуализации, я создал несколько инструментов, которые помогли мне в этих изысканиях:

Устранение угрозы

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

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

Что можно сделать/доступные ресурсы:

  • Поставить гипервизор под строгий контроль RBAC/MAC (реализация для Citrix)
  • Сократить площадь атаки, отключив избыточные возможности (напр., избыточное совместное использование, в общем виде объясняемое в проекте Xen)
  • Обнаружение аномалий на хосте (есть интересное академическое исследование на эту тему, выполненное Кингом Абдулализом и Стивеном Уолтхьюзеном)
  • Видимость внутри состояния виртуальной машины
  • Создание монитора виртуальной машины
  • Выявление аномалий при потреблении ресурсов хоста виртуальной машиной

Заключение

Виртуализация – это круто! На основании абстрагирования, обеспечиваемого при помощи виртуализации, построены многие инновационные вещи, в частности, облака, машины конечных точек и даже новейшие автомобили. Виртуализация усиливает производительность и безопасность вообще, но у нее есть и темная сторона. Как показали недавние реальные атаки, и как рассмотрено в этой статье, злоумышленник может обратить себе на пользу многие из возможностей виртуализации. Использование новейших технологий, в частности, VT-x и минималистичных песочниц, позволяет сделать виртуализацию еще более малозаметной.

Назначение vCloak – послужить практичным введением в проблему того, как виртуализация может использоваться для незаметного внедрения вредоносного ПО, чтобы пользователи были осведомлены в угрозах такого рода и могли от них защититься.

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


Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

  1. На физическом сервере может быть много виртуальных машин.
  2. Их количество ограничивается только аппаратными ресурсами сервера.
  3. Виртуальные машины легко как создать, так и удалить.
  4. Развертывание новых служб занимает минимум времени.
  5. Поскольку высокая загрузка виртуальной машины не бывает продолжительной, можно максимально использовать оборудование, ведь значительное расходование ресурсов одной виртуальной машиной компенсируется отсутствием нагрузки от другой.

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

Гипервизоры

Связь между физическим оборудованием и виртуальной машиной осуществляет гипервизор. Любой запрос гостевой операционной системы на доступ к устройству передается гипервизором на уровень аппаратного обеспечения, а ответ возвращается обратно. Весь этот процесс скрыт от гостевой операционной системы, она работает с виртуальными устройствами как с физическими. Гипервизоры делятся на два типа. Гипервизоры типа 2 работают внутри обычной операционной системы. К ним относятся VMware Workstation, VirtualBox и Parallels Desktop.

Гипервизоры типа 1 работают прямо на аппаратном обеспечении, без посредничества полноценной операционной системы. За счет этого они более производительны и широко распространены на предприятиях. К ним относятся VMware ESXi, Microsoft Hyper-V, Citrix XenServer и другие.

Защита виртуальных сред

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

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

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

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

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

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

Сегодня практически все крупные производители антивирусов предлагают те или иные решения для защиты виртуальных сред. Они делятся на агентские и безагентские. Безагентские на сегодня существуют только для продуктов VMware и построены на использовании решения vShield Endpoint. Эта технология предоставляет программный интерфейс, с помощью которого можно проверять, лечить и удалять файлы на виртуальных машинах.

Решение vSphere компании VMware

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

Для упрощения управления типичными задачами безопасности (и не только) компания VMware разработала набор продуктов vShield, который в том числе содержал брандмауэр, защиту от утечек данных, а также технологию для выгрузки антивирусной проверки с гостевых машин на выделенную виртуальную машину — vShield Endpoint.

Начиная с версии vSphere 5.1 набор функций vShield был дополнен, усовершенствован и стал называться vCloud Networking and Security. Единственным исключением стал vShield Endpoint, который поставлялся вместе с vSphere.

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

В случае файлового антивируса на защищаемые виртуальные машины устанавливается драйвер vShield Endpoint (vShield Endpoint Thin Agent), который входит в состав VMware Tools. Он разрешает или запрещает доступ к файлам в зависимости от результата проверки. Виртуальная машина с антивирусом связана с драйвером на уровне гипервизора ESXi при помощи специальной службы.

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

Решение Kaspersky Security для виртуальных сред

Основным преимуществом виртуализации будут отказоустойчивость и повышение эффективности использования ресурсов. Эти принципы лежат в основе vShield Endpoint и специализированного решения Kaspersky Security для виртуальных сред. Выделение специальной виртуальной машины для проверки объектов на ESXi-хосте позволяет избавиться от многих трудностей, неизбежно возникающих при работе с традиционными антивирусами.

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

Kaspersky Security для виртуальных сред, с одной стороны, управляется Kaspersky Security Center, а с другой — интегрируется с подсистемой vShield и vCenter Server. Kaspersky Security для виртуальных сред взаимодействует с подсистемой vShield посредством сетевого соединения со службой vShield-Endpoint-Mux, поэтому процедура интеграции фактически сводится к передаче этой службе IP-адреса и порта для соединения. В роли посредника здесь выступает vShield Manager, он передает настройки и он же следит за статусами всех компонентов защиты.

Управление Kaspersky Security для виртуальных сред полностью осуществляется через Kaspersky Security Center, более того — это единственный способ управления продуктом.

Принципы работы постоянной защиты

Перехват обращения к файлу осуществляется с помощью VMware vShield Endpoint Thin Agent (Endpoint Driver) на стороне гостевой операционной системы. При этом драйвер временно блокирует файл и передает информацию на виртуальную машину защиты Security Virtual Machine (SVM) через модуль vShield-Endpoint-Mux. После проверки Kaspersky Security для виртуальных сред возвращает вердикт, на основании которого драйвер VMware на гостевой машине выполняет действие — разрешить доступ, заблокировать файл или удалить (см. рисунок).

Алгоритм проверки
Рисунок. Алгоритм проверки

Повышения производительности можно добиться с помощью внутренней оптимизации, например с использованием кэша. На стороне гостевой виртуальной машины драйвер vShield Endpoint Thin Agent может принимать решение о передаче файла на проверку на основании настроенных в политике исключений и внутреннего кэша чистых файлов. Кэш наполняется по результатам проверки Kaspersky Security для виртуальных сред. Однажды проверенный объект больше не будет проверяться, пока он не изменится или кэш не будет сброшен.

А исходя из требований безопасности кэш периодически сбрасывается. Это делается, когда происходят следующие события:

  • обновление баз сигнатур;
  • изменение настроек;
  • запуск задачи проверки по требованию;
  • выключение виртуальной машины;
  • перемещение виртуальной машины между хостами (с помощью механизма vMotion).

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

Основные принципы формирования общего кэша:

  • Используется хеш от полного пути файла. Хеш от пути быстро подсчитывается, в отличие от MD5-суммы объекта.
  • Учитываются свойства файла (даты создания и изменения, размер), что позволяет быть уверенным, что запись в кэше действительно относится к одному и тому же файлу. Учет всех параметров позволяет обнаруживать изменения в кэшированных файлах даже при временной потере соединения с сервером защиты.
  • Записывается дата антивирусных баз при первой и последней проверке. Используется в алгоритме перепроверки.
  • Учитываются настройки легкого агента, с которыми был проверен файл. В кэше хранится информация о профиле защиты, с которым был проверен объект, и, если настройки изменились и стали более жесткими, файл проверяется, даже если не был изменен.

Общий кэш предоставляет следующие преимущества:

  • он особенно эффективен в случае использования инфраструктуры виртуальных рабочих столов VDI;
  • ведется на стороне SVM;
  • сбрасывается только при перезагрузке SVM;
  • запись в кэш собирается из свойств файла (путь, размер, дата создания/изменения) и данных проверки (время первой/последней проверки, настройки проверки, результат). Исключения выполняются, если файл находится на сетевом ресурсе, на сменном носителе или если запущена задача проверки по требованию.

Сравнение с традиционным подходом

Как уже говорилось, основными преимуществами виртуализации являются прежде всего отказоустойчивость и повышение эффективности при использовании ресурсов. Эти принципы положены в основу vShield Endpoint и Kaspersky Security для виртуальных сред. Само по себе выделение специальной виртуальной машины для проверки объектов на хосте ESXi позволяет избавиться от многих трудностей, которые неизбежно возникают при работе с традиционными антивирусными продуктами. Выход из строя отдельного компьютера или его простой принесет меньше неприятностей, чем неполадки хоста ESXi. Ведь, как правило, на одном хосте запущены десятки виртуальных машин, многие из которых критичны для организации.

Именно поэтому установка Kaspersky Endpoint Security для бизнеса, обновление данного продукта с одной версии на другую требует тщательной подготовки, ведь администратор должен учесть возможные проблемы с аппаратным и программным обеспечением. Причем аппаратное, да и программное обеспечение на разных компьютерах будет различным.

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

Потребление ресурсов

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

Диск. Очевидно, что, так как мы отказываемся от полноценного антивирусного программного обеспечения, дисковое пространство используется гораздо эффективнее, ведь Kaspersky Endpoint Security для бизнеса версии 10 занимает около 800 Мбайт, в то время как виртуальная машина защиты — 2 Гбайт в случае использования режима Thin Provisioning (файл диска выделяется динамически) и 30 Гбайт в режиме Thick Provisioning (сразу выделяется все необходимое место под диск).

А ведь на одном хосте может быть несколько сотен виртуальных машин. Выигрыш налицо! В то же время с точки зрения производительности при использовании диска все не так однозначно. Ведь проверяется в обоих случаях примерно одно и то же количество объектов, а значит, число операций чтения и записи будет примерно одинаковым. Однако стоит учесть, что перехват файловых операций и доступ к файлам будут организованы по-разному. Внутренние тесты подтверждают, что Kaspersky Security для виртуальных сред гораздо менее требователен к диску, чем KESB 10.

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

Сеть. Если минимизировать количество клиентов, то удастся значительно разгрузить сеть. Это как раз случай Kaspersky Security для виртуальных сред, ведь виртуальная машина защиты всего одна на ESXi-хост, так что получается экономия на обновлениях, данных синхронизации и большинстве событий.

Постоянная защита

Перехват обращения к файлу осуществляется с помощью VMware vShield Endpoint Thin Agent (Endpoint Driver) на стороне гостевой операционной системы. Этот драйвер временно блокирует файл и передает информацию о доступе на виртуальную машину защиты через модуль vShield-Endpoint-Mux. Запрос на проверку передается Kaspersky Security для виртуальных сред через библиотеку libEPSec.so, предоставляемую компанией VMware. Если файл нужно проверить, антивирус уже сам направляет запрос к библиотеке на чтение объекта. После проверки Kaspersky Security для виртуальных сред возвращает вердикт, на основании которого драйвер VMware на гостевой машине выполняет действие — разрешить доступ, заблокировать файл или удалить.

При работе в виртуальной среде основным критерием является производительность, добиться которой можно как с помощью настроек, так и посредством внутренней оптимизации, например в виде кэша. На стороне гостевой виртуальной машины драйвер vShield Endpoint Thin Agent может принимать решение о передаче файла на проверку на основании настроенных в политике исключений и внутреннего кэша чистых файлов. Кэш наполняется по результатам проверки Kaspersky Security для виртуальных сред. Однажды проверенный объект больше не будет проверяться, пока не изменится или кэш не будет сброшен. Однако из соображений безопасности кэш нужно периодически сбрасывать.

Кэш на гостевой машине существует достаточно недолго. У него есть еще один недостаток: для каждой виртуальной машины он ведется независимо. В среде, где многие машины имеют общую базу (например, VDI) можно добиться значительного повышения производительности с помощью общего для них кэша. В таком случае один и тот же файл, проверенный на одном из узлов, не будет проверяться на всех остальных.

Для проверки файла Kaspersky Security для виртуальных сред использует стандартный набор средств, применяемый и в файловом антивирусе Kaspersky Endpoint Security для Windows. Основу всякой проверки составляет сигнатурный анализ, он выполняется первым. Если он ничего не дал, производится эвристический анализ. Чем глубже уровень эвристики, тем больше выполняется инструкций и тем более точным может быть вердикт, однако это приводит к потере производительности.

Недостатки данного вида защиты

Ограниченность защиты. Драйвер vShield Endpoint (тонкий агент) очень прост и потому почти не оказывает влияния на производительность защищаемой виртуальной машины. Однако он может использоваться только для проверки файлов на диске. Ни о какой защите от атак через браузер, проверке памяти, проактивной защите и т. д. речи не идет. В случае серверов такой подход может быть оправдан, но при защите обычной рабочей станции этого недостаточно.

Жесткие рамки. Значительная доля функций защиты не может быть реализована в силу специфики решения. Задача антивирусных продуктов сводится лишь к проверке данных. Перехват и доступ к объектам осуществляются средствами VMware. Возможность использования новых функций также зависит от VMware. На данный момент к защите файловой системы добавилась только защита от сетевых атак, которая осуществляется посредством набора API под названием Network Extensibility.

Неэффективное потребление ресурсов в случае небольших развертываний. Для клиентов с небольшой виртуальной инфраструктурой vShield Endpoint может показаться не столь привлекательным. Надо учитывать, что потребуется установить несколько дополнительных виртуальных машин: vShield Manager для установки и управления vShield Endpoint (один на vCenter Server) и виртуальную машину защиты (на каждый хост ESXi). Они занимают место в хранилище и потребляют память. Если требуется защитить пару ESXi-хостов с несколькими виртуальными серверами, выигрыш в ресурсах не так очевиден. Если же требуется защита от сетевых атак, дополнительно понадобится еще одна виртуальная машина защиты на каждый ESXi-хост.

Стоимость. На данный момент vShield Endpoint включен в стоимость лицензий VMware vSphere Standard и выше, но для использования защиты от сетевых атак потребуется приобрести лицензию vCloud Networking and Security. Кроме того, защита от сетевых атак требует наличия распределенного виртуального коммутатора, доступного лишь в самых дорогих редакциях VMware vSphere.

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

Читайте также: