CC BY-NC-ND
276
1Ю.К. Сергеев
ИСПОЛЬЗОВАНИЕ ТЕХНОЛОГИЙ ВИРТУАЛИЗАЦИИ ДЛЯ ЗАЩИТЫ ИНФОРМАЦИИ
В этой статье рассматриваются вопросы обеспечения безопасности информации в виртуальных системах. Операционная система, работающая в виртуальной машине, уже не обращается к аппаратным средствам напрямую, это за нее делает ПО виртуализации. Результатом этих изменений может стать преобразование методов и подходов к защите информации при ее обработке, передаче и хранении в виртуальных компьютерных системах. Автором рассматривается защищенная архитектура компьютерной системы, реализованная на основе гипервизора Хеп, а также предлагаются пути использования технологий виртуализации для реализации специализированных средств защиты информации, направленных на обеспечение ИБ в виртуальной среде.
Ключевые слова: информационная безопасность, виртуальная машина, Хеп, политика Байба, средства защиты информации, руткит, вредоносное ПО.
Введение
Виртуализация - чрезвычайно перспективная технология. Уже сегодня повсеместно используются различные системы виртуализации для реализации важных задач бизнеса и государства. Огромное количество преимуществ, среди которых консолидация серверных ресурсов, увеличение отказоустойчивости, балансировка нагрузки и мгновенная миграция, порождают все больший интерес со стороны компаний и организаций. Всемирно известные ИТ-компании, такие как IBM, Oracle, Microsoft, VMware и другие, уделяют все большее внимание развитию этой технологии. Так, например, Citrix приобрела opensource проект, разрабатываемый Кембриджским университетом, под названием Xen за 500 миллионов американских долларов. Компания IBM тратит изрядные сум-
мы на изучение схожих по принципу технологий, разрабатываемых в проекте Phantom группой специалистов по компьютерной безопасности X-Force, о которых было рассказано на международной конференции по безопасности RSA Conference 2008.
Сегодня проблема большинства программных СЗИ состоит в том, что они выполняются в той же среде, что и пользовательские приложения и общесистемные службы. Например, так как GUI в Windows работает в режиме ядра, то всегда существует потенциальная возможность эскалации прав пользователя до административных, что позволяет модифицировать СЗИ, блокировать их работу, скрывать действия вредоносных программ и совершать любые другие несанкционированные действия. К тому же зачастую пользователь может влиять на работу средств защиты, имея достаточные права, чтобы отключать их ради увеличения производительности (например, антивирус).
В последние несколько лет все более активное развитие получают rootkit-технологии, появившиеся еще в мире Unix. Руткит -программа или набор программ для скрытия следов присутствия злоумышленника или вредоносной программы в системе. Обнаружить его в зараженной системе довольно-таки сложно, учитывая, что все совершаемые действия могут находиться под контролем руткита, который может их обрабатывать и не позволять себя обезвредить.
Целью работы стало создание архитектуры защищенной системы с использованием технологий виртуализации, которая позволяла бы реализовать «контроль сверху» за процессами, существующими в защищаемой ОС. Данная архитектура должна применять формальную политику для разграничения доступа к ресурсам, иметь возможность контролировать оперативную память, постоянную память и сетевые устройства защищаемых ОС. Для реализации этих целей используется виртуализация с применением гипервизора Xen.
Предлагаемая архитектура системы
Системы, построенные с применением технологий виртуализации, благодаря своей архитектуре позволяют реализовать то, чего нельзя создать в классическом варианте компьютерной системы.
Хеп - монитор виртуальных машин (гипервизор), функционирующий на архитектуре х86. В терминологии Хеп виртуальная машина называется доменом. Гипервизор способен поддерживать одновременную работу большого числа виртуальных машин на одной физи-
ческой, при этом не затрачивая значительных вычислительных ресурсов, за счет небольшой (тысячи строк) кодовой базы гипервизора. Xen поддерживает Intel VT и AMD Pacifica, которые дают возможность работать с виртуальными серверами на одном процессоре, используя аппаратное ускорение процессора и виртуализацию памяти.
Защищаемые операционные системы защиты и
управления
Рис. 1. Предлагаемая архитектура компьютерной системы
Реализация новой архитектуры (рис. 1) защищенной компьютерной системы с применением гипервизора построена на концепции вынесения агентов безопасности, мониторинга и управления из пользовательской операционной среды в специализированную ОС. Другими словами, администратор может управлять и контролировать работу пользовательской ОС из ОС защиты и управления без использования сетевых технологий, совершая операции обеспечения безопасности напрямую путем обращения к интерфейсу взаимодействия гипервизора.
Виртуализация всех компьютерных ресурсов, их разделение и динамическое присвоение, а также работа многих виртуальных доменов одновременно позволяет выделить Xen как наиболее гибкую и производительную платформу виртуализации. Благодаря архитектуре построения изоляция ресурсов более надежна, чем это обычно бывает в сегодняшних ОС. Реализация этих идей частично достигнута с применением гипервизора Xen.
Архитектура процессоров x86 предоставляет 4 кольца привилегий (рис. 2), обычно операционные системы работают на двух из них - Ring-0 и Ring-3. Ядро занимает нулевой уровень, а приложения запускаются в третьем кольце. В случае использования типичного монитора виртуальных машин (Virtual Machine Monitor (VMM)) для архитектуры x86 операционные системы вынуждены сосуществовать с приложениями в кольце 3. Для собственной защиты они должны быть запущены в отличных друг от друга уникальных адресных пространствах, обращение по которым должно быть под контролем VMM. Это, естественно, приводит к уменьшению производительности и ухудшению масштабируемости таких систем.
Рис. 2. Аппаратные уровни привилегий для процессора x86
Более эффективной тактикой в таком случае, которой пользуется Xen, является виртуализация с использованием не задействованных ранее привилегированных уровней Ring-1 и Ring-3. Они не использовались в операционных системах со времен IBM OS/2.
Гипервизор работает в кольце 0 архитектуры x86, что позволяет ему получать доступ к любому участку памяти. Когда Xen запускается на каком-либо хосте, гипервизор первым берет на себя управление системой. Затем он загружает гостевую ОС, или домен 0 (Dom0) в терминологии Xen. Администратор взаимодействует с Xen только посредством Dom0, который называется привилегированным доменом. Все драйверы устройств для доступа к оборудованию также загружаются в Dom0. Привилегированный домен обеспечивает доступ других гостевых ОС, которые иногда называют доменом U (или DomU), к виртуальным блочным и сетевым устройствам без использования аппаратной виртуализации1.
Гипервизор Xen создавался как защищенная система, но его архитектура построена таким образом, что нам необходимо доверять привилегированному домену (Dom0). Это доверие распространяется и на программное обеспечение, запущенное с привилегиями суперпользователя root в пределах адресного пространства Dom0.
В результате TCB (Trusted Computer Base) включает довольно большое количество кода:
- гипервизор;
- ядро linux в Dom0;
- любое программное обеспечение, запущенное от имени root в Dom0.
Под TCB в соответствии с «Оранжевой книгой» понимается набор программ, управляющих частями системы и ответственных за ее безопасность. Исходный код Xen доступен любому разработчику под лицензией GPL, поэтому в этот продукт легко интегрировать новые возможности, еще не имеющие программной реализации, и использовать уже существующие.
Политика безопасности
Рассмотрим политику безопасности, которая описывала бы взаимодействие защищаемой ОС и ОС защиты и управления в рамках предложенной архитектуры. Привилегированная ОС должна иметь возможность осуществлять простейшие операции чтения и записи по отношению к объектам непривилегированных защищаемых ОС через формально заданный интерфейс. Попытки доступа из DomU в привилегированный должны быть запрещены. Логич-
ным в данном случае окажется выбор политики Байба2, реализуемой средствами мандатного контроля.
Пусть в информацию внесена решетка ценностей SC (High, Low), так, чтобы защищаемая пользовательская ОС соответствовала уровню Low, а ОС защиты - уровню High. В этой связи любой информационный поток X^Y может воздействовать на объект Y тогда и только тогда, когда ценность X выше или равна ценности Y. Для данной системы политика определяется для операции чтения и записи следующим образом:
Х^Г<=>с(Х) > с(У)
Для реализации данной политики в гипервизоре должен быть создан монитор обращений, определяющий всего две метки High и Low и контролирующий взаимодействие ОС в соответствии с политикой Байба.
При этом ОС защиты и управления должна выступать посредником при всех внешних взаимодействиях системы в целом, например, исполняя роли: поточного сетевого антивируса, персонального межсетевого экрана, узловой системы обнаружения вторжений, программы контроля целостности и доверенной загрузки ОС и других привычных СЗИ. Кроме того, привилегированный домен может контролировать доступ к внешним устройствам и их проверку перед передачей в защищаемую ОС, а также обеспечивать возможность быстрого восстановления при сбоях в пользовательской системе.
Детектирование и нейтрализация руткитов
Развивая эту идею, можно переложить ряд существующих подходов компьютерной защиты в виртуальную «систему координат». В качестве примера автором был реализован один из них - защита оперативной памяти виртуальных машин. Для этого была написана программа, позволяющая осуществлять поиск и нейтрализацию определенного класса руткитов (SSDT rootkits)3 в ОС Windows из другой операционной системы (привилегированный домен), работающей вместе с защищаемой под управлением гипервизора Xen.
Вредоносный код в памяти гостевой системы можно искать, получая доступ к памяти ядра системы в домене U и копируя страницы памяти в область, доступную привилегированному домену, а затем, используя различные алгоритмы поиска паттернов, различных сравнений, анализа аномалий, выявлять подозрительный код, детектировать его.
В программе была использована функция xc_map_foreign_ range() для организации доступа к области памяти гостевого домена из адресного пространства созданной программы. Эта функция использует IOCTL_PRIVCMD_MMAP гипервызов Xen для мап-пинга mfn (Machine page Frames Numbers - номера физических страниц памяти) в pfn (Pseudo-physical page Frames Numbers - номера псевдофизических страниц памяти). После того как функция вызвана программа из привилегированного домена, запущенная с правами root, может читать/писать в память виртуального HVM-домена обычными способами работы с памятью процесса в Linux системе.
Даже внутри архитектуры x86 память может быть организована по-разному в том смысле, что система может работать в разных режимах - real, protected paging enabled, protected paging disabled, PAE, IA32e. Функция map_domain_va() определяет в защищенном режиме, работает vcpu или нет, просматривая управляющие регистры с помощью гипервызова fetch_regs(). Управляющие регистры процессора CR0 и CR4 отражают, в каком режиме работает vcpu. Регистр CR3 указывает на гостевой физический адрес таблицы памяти, которую домен сейчас использует. В библиотеке libxenctrl реализованы функции map_domain_va_32(), map_domain_va_pae(), map_domain_va_64(), чтобы поддерживать эти разные форматы страниц памяти.
Функция xc_map_foreign_range() получает 5 аргументов и возвращает адрес сопоставленного пространства из гостевой машины домену 0. Рассмотрим аргументы подробнее и выясним, как их получить:
- xc_handle - xen-описатель;
- domid - идентификатор домена U;
- PAGE_SIZE - размер страницы памяти;
- PROT - тип доступа (чтение, запись и другие);
- gmfn - гостевой физический адрес блока.
Первый аргумент создается после осуществления вызова функции xc_interface_open(), второй также возможно получить на основе данных, поступивших программе извне, например из stdin. Пользователь, другая программа могут задать как имя, так и идентификатор домена напрямую. В нашем случае мы будем получать его в качестве аргумента программы поиска выбранного нами рут-кита. Размер страницы выбирается в зависимости от архитектуры, в нашем случае это 4M.
Для нахождения таблицы SSDT в памяти гостевого домена под управлением Windows XP Professional SP2 достаточно написать программу, которая делала бы полный дамп оперативной памяти
этой виртуальной машины из другой ОС. При этом каждую новую страницу можно помечать специальной меткой, таким образом будет легко определить номер необходимого фрейма памяти. Была выбрана строка «start - gmfn N», где N - порядковый номер блока (рис. 3).
Рис. 3. Маркировка фрейма дампа памяти
Программа получает два аргумента. Первый из них - это номер домена, дамп которого необходимо получить, а второй - количество виртуальных процессоров в этом домене. Эта информация легко узнается с помощью штатной утилиты xm с опцией list, запущенной с правами root в домене 0, а используя существующие Xen API, можно получать эти данные и самим.
Получив требуемые аргументы, утилита сохраняет постранично данные из оперативной памяти в файл core в том же каталоге, в котором она находится. Кроме того, в stdout (в данном случае на консоль) пишется аналогичная информация, но с добавлением меток начала и окончания фреймов.
Открыв полученный тегированный файл с помощью hex-редак-тора (см. рис. 2), было определено с помощью функции поиска по заданному байткоду местоположение искомой таблицы. Таблица
SSDT хранится в 1281-й странице памяти виртуальной машины независимо от времени ее запуска, номера домена (если она была запущена несколько раз или после другого домена) и других параметров среды. Естественно, это верно для Windows XP Professional SP2, но по схожей методике этот фрейм можно найти и для других версий ОС с различными сервисными пакетами.
Довольно несложно создать утилиту для анализа SSDT на лету без сохранения данных на диск, а лишь с выводом в stdout информации об изменениях в этой таблице.
Программа принимает три аргумента:
- ID домена;
- количество процессоров vcpu;
- идентификатор выбора действия утилиты «восстановление SSDT» или «детектирование изменений SSDT» (1 или 0).
Утилита делает ряд проверок, связанных с окружением, узнает, запущен ли домен с использованием аппаратной виртуализации. В случае успеха система считывает из эталонного файла core.1281 дамп 1281 фрейма в буфер и затем либо записывает адреса из него в память виртуального домена напрямую, либо не исправляет SSDT, а лишь проводит сравнение всех значений этой таблицы итеративно, при этом выводит на экран результаты проверки, после чего Хеп-описатель закрывает и программа завершает свою работу.
Таким образом, была продемонстрирована возможность реализации специализированного средства защиты для работы в виртуальных средах в рамках предложенной архитектуры. Аналогичные результаты были получены автором и при работе с виртуальным «жестким диском» и реализации сетевой подсистемы. Жесткие диски и сетевые интерфейсы доступны для работы из привилегированной ОС.
Для реализации контроля целостности файлов защищаемых ОС перед их запуском достаточно предварительно их монтировать в ОС защиты и управления, осуществлять подсчет контрольных сумм, сверять их с эталонными, а затем принимать решение о разрешении или запрете запуска защищаемой ОС.
Сетевой адаптер гостевого домена имеет свое отображение в Domain 0. Трафик из виртуальной машины может быть отфильтрован, прослушан и изменен в ОС защиты и управления. Например, может быть построена система межсетевого экранирования на основе iptables, работающая как распределенный персональный межсетевой экран для каждой из защищаемых ОС, при этом средства защиты будут выполняться в ОС защиты и управления.
Монитор обращений
Для программной реализации политики Байба может быть реализован монитор обращений, который контролировал бы все типы гипервызовов, осуществляемых защищаемыми ОС по отношению к ресурсам компьютерной системы (рис. 4).
ч_у
Защищаемые ОС
Рис. 4. Схема работы монитора обращений в рамках предложенной архитектуры
Данное программное обеспечение должно состоять из следующих логических компонент:
- монитор обращений;
- хранилище политик Байба для доменов;
- модуль перехвата и кэширования решений монитора обращений.
Политики задаются из ОС защиты и управления путем присвоения меток каждому из доменов, после чего генерируется бинарное хранилище политик, доступное для обработки монитору обращений. Каждый гипервызов виртуального домена перехватывается и
проходит процедуру проверки на соответствие заданной политике безопасности4.
Важным моментом при построении данной архитектуры является априорное доверие к гипервизору с точки зрения отсутствия в нем программных закладок, а также формальное описание интерфейса взаимодействия ОС защиты и управления с гипервизором для получения доступа.
Так как метки ОС изменяются не часто, то эффективно реализовать кэширование решений монитора обращений относительно разрешения или запрета несанкционированного доступа к ресурсам. Проверка в этом случае должна осуществляться только при загрузке защищаемой ОС (инициализации домена) и в случае изменения меток доступа, что позволит минимизировать эффект от ввода мандатного управления доступов на уровне виртуальных доменов к аппаратным ресурсам компьютера.
Заключение
Итак, на основе предложенной архитектуры возможно реализовать инструменты поиска и нейтрализации руткитов и вредоносного ПО в защищаемых ОС вне зависимости от из технической совершенности, даже если несанкционированное ПО работает в самом низкоуровневом режиме ядра и имеет доступ ко всей области памяти данной ОС. Это достигается за счет изоляции аппаратных ресурсов с помощью технологий виртуализации на основе гипер-визора Xen и реализации формальной политики безопасности по модели Байба.
Содержимое файловых систем защищаемых ОС может быть защищено с помощью средств контроля целостности, работающих в ОС защиты и управления, а также может быть обеспечена доверенная загрузка виртуальных защищаемых систем.
Таким образом, в данной статье был показан ряд подходов к защите информации в виртуальных машинах, при этом средства защиты функционируют вне защищаемых операционных систем, реализуя централизованную и безагентную архитектуру информационной безопасности компьютерной системы.
Примечания
1 Kamble Nitin A., NakajimaJun, Mallick AsitK. Evolution in Kernel Debugging using Hardware Virtualization With Xen, Proceedings of the Linux Symposium. Ottawa: Open Source Technology Center, Intel Corporation, 2006.
2 Biba K.J. Integrity considerations for secure computer systems. Bedford, 1977.
3 Rutkowska J. Rootkits Detection on Windows Systems, ITUnderground Conference. Warsaw. October 12th - 13th 2004.
4 Coker G. «Xen Security Modules (XSM)», National Information Assurance Research Lab National Security Agency (NSA): Presentation. 17 April 2007.
