VDI
Использование виртуализации рабочих мест (Virtual Desktop Infrastructure, VDI) для многих организаций стало стандартом де-факто. Установка гипервизора позволяет не выделять каждому пользователю отдельную физическую машину, а предоставлять полностью имитирующий таковую виртуальный хост на сервере. Две основные значимые бизнес-причины: сокращение издержек и упрощение части задач системного администрирования. Помимо этого VDI позволяет мгновенно создавать чистые рабочие станции с нуля или организовывать мобильный доступ сотрудников с самых разных устройств. Предприятия активно пользуются этими возможностями. Разберемся подробнее, что особенного в построении защиты инфраструктуры VDI.
Необходимость защиты VDI
Причины интереса бизнеса к VDI понятны. Вместе с тем сотрудники компаний уже давно привыкли к своим стандартным рабочим местам и хотят работать с VDI точно так же, как и с установленными локально операционными системами. Видимые сотрудникам изменения при работе в Интернете через браузер, копировании данных с USB-флешки, запуске приложений должны быть минимальны. Конечно, ИТ-подразделения обеспечивают такую плавность перехода. Но при этом все угрозы для физической инфраструктуры остаются актуальными и для VDI.
Сама по себе виртуализация не защищает никак. Операционная система, установленная на виртуальную машину, обладает ровно теми же уязвимостями, что и локальная ОС, — известно множество заражений виртуальных сред. Мало того, известны случаи выхода вредоносного кода из-под управления гипервизора непосредственно на хост. Для этого использовались уязвимости уже самих гипервизоров. Все это приводит к необходимости полноценной защиты виртуализированных рабочих мест. Подробнее о необходимости защиты VDI можно прочесть здесь.
Различные подходы к защите и важность контроля оперативной памяти
Из-за специфики виртуальных сред подходы к их защите отличаются от методов, применяемых для традиционных физических инфраструктур. Стоит отдельно кратко остановиться на том, почему они не могут применяться для виртуальных инфраструктур. В первую очередь виртуальные машины, как правило, менее мощны, и простое копирование решений для физических инфраструктур может привести к заметному увеличению времени отклика хостов. Помимо этого существуют специфические проблемы, такие как «шторм активности», при котором все виртуальные машины с типовым ПО одновременно начинают выполнять одну и ту же задачу, например обновлять базы.
Разработчики специализированных решений для обеспечения безопасности VDI стремятся снизить нагрузку на виртуальные машины, по возможности централизовать защитные функции, чтобы не дублировать их на каждом хосте.
В идеальном случае выделяется отдельный хост, отвечающий только за защиту виртуальной инфраструктуры, а на другие хосты агенты не устанавливаются. У такого подхода есть целый ряд ограничений, в первую очередь связанных с доступом к оперативной памяти защищаемых хостов. Даже если сам доступ к памяти возможен (а при определенных условиях это действительно так), то одно лишь ее содержимое дает далеко не полную картину происходящего на машине. Ниже мы подробнее опишем, почему для полноценной защиты необходим более глубокий динамический поведенческий анализ всего происходящего на виртуальной машине.
Есть и другой путь, находящийся где-то посередине между установкой «тяжелых» решений и безагентской защитой. Это установка «легких» агентов, которые, с одной стороны, имеют доступ к оперативной памяти, а с другой — требуют меньше ресурсов за счет того, что часть их функциональности вынесена в специально выделенную защитную машину. Почему важен именно доступ к оперативной памяти? Этого требует распространение «бестелесных» вредоносов, не оставляющих никаких следов, кроме как в оперативной памяти. Известный пример: программа Mimikatz, используемая злоумышленниками для получения паролей пользователей в нешифрованном виде в ходе целевых атак (она, в частности, применялась в атаках группы Wild Neutron).
Почему контроль оперативной памяти необходим, но недостаточен сам по себе
Индустрия ИБ знает о подобных приемах давно, и сканирование памяти защищаемых физических и виртуальных машин не ново. «Лаборатория Касперского» реализовала драйвер (работающий в том числе и в «легком» агенте для защиты виртуальных хостов), сканирующий загруженные в память драйверы, ядро ОС, память процессов, работающих в пользовательском режиме, и т.д.
Однако простое сканирование памяти не сможет заменить более глубокий поведенческий анализ происходящего на машине. Сканирование, безусловно, нужный метод, но переоценивать его не стоит: он обладает скорее точечным действием. Сам по себе, без сопоставления происходящего в памяти с данными о событиях в файловой системе, реестре, вызовах API системы, этот метод либо не будет «ловить» практически ничего, либо будет выдавать множество ложных срабатываний.
Приводя аргументы в пользу сканирования оперативной памяти, часто говорят, что если вредоносный файл запакован, то в естественном виде его можно увидеть только в памяти. Однако современные антивирусные движки способны анализировать и запакованные файлы. Хуже дела обстоят с программами-протекторами, реализующими полиморфизм и другие технологии, затрудняющие анализ. Тем не менее даже в этом случае просмотр памяти сам по себе не принесет много пользы. Без поведенческого анализа сложно судить о назначении кода. Также непонятно, в какой именно момент следует запускать сканирование, то есть как определить, что расшифровка закончена (если она вообще не происходит «на лету»).
На эти особенности работы протекторов накладываются механизмы работы с памятью в современных ОС. В MS Windows множество операций происходит асинхронно. В случае записи в файл данные сначала оседают в памяти, а на диск записываются из буфера. То есть момент сброса информации на диск не определен и непонятно, в контексте какого процесса это произойдет.
Также все современные ОС для улучшения производительности работают с файлом подкачки, в который выгружается содержимое виртуальной памяти. При неблагоприятном для защитного решения развитии событий виртуальная память может быть выгружена до сканирования физической памяти. Проблемой для безагентского решения это становится потому, что оно имеет доступ только к физической памяти. Таким образом, сброс виртуальной памяти в своп может серьезно помешать работе решения.
Наконец, если вредонос написан на скриптовом языке и выполняется интерпретатором, то сам скрипт в памяти может присутствовать лишь частично. В итоге зловредных функций в памяти не окажется, но скрипт тем не менее выполнится.
Если говорить о специфике защиты виртуальных сред, то здесь на работу с памятью накладываются еще и особенности гипервизора. Он получает управление в строго определенные моменты, число которых ограничено. А это, в свою очередь, ограничивает и возможные детектирования зловредов в памяти.
Как должна выглядеть полноценная защита
Итак, сканирование оперативной памяти очень полезно для борьбы с вредоносами, но защитное решение должно быть многоуровневым. Параллельно со сканированием памяти необходим и сбор подробных данных о динамике происходящих на хосте событий. Излишнее увлечение сканированием памяти может замедлить работу защитного решения, не принеся значительного его усиления.
В любом случае, понимая разницу в потребностях различных заказчиков, «Лаборатория Касперского» реализовала оба варианта: безагентское решение и решение с «легким» агентом. Именно второе обеспечивает сбор всех перечисленных выше поведенческих данных, позволяющих надежнее защитить устройство. О сравнении этих двух решений можно прочесть здесь.
Узнать больше о подходе «Лаборатории Касперского» к защите виртуальных сред и связаться с нашими специалистами можно на этой странице.
Советы