CC BY
180
Контекст и идентификация понятий
С информативностью понятий связана также проблема их идентификации в базах данных и знаний. В работе [4] показано, что визуализация знаний возможна только в определенном контексте. Точно так же любой текст или человеческий диалог всегда строится с учетом контекста, благодаря чему достигается компактность при сохранении точности передаваемого смысла высказываний. В естественном языке говорящий (или пишущий) должен всегда быть уверен в том, что слушатель или читатель правильно понимает контекст, для чего делаются соответствующие вводные предложения в начале текста или диалога. Если же требуется использовать один и тот же объект в разных контекстах, то к идентификатору объекта добавляется идентификатор контекста. В рассмотренном выше примере студенческого сообщества, если высказывание делается в контексте группы, то для идентификации экземпляра достаточно фамилии; в контекстах более высокого уровня к фамилии добавляется номер курса, факультета, университета и т.д.
В последнее время идет активный процесс формализации знаний в стандарте Глобальной семантической сети (Semantic Web, SW). Для каждой предметной области в SW формируются онтологии, т.е. документы, подготовленные на OWL или других языках и содержащие описание классов объектов, отношений между ними и свойств. С использованием онтологий создаются документы, содержащие факты, относящиеся к заданной предметной области. Информативность таких документов можно оценивать с применением данного подхода. В частности, может быть разработан модуль в среде популярного редактора онтологий Protégé (http://protege.stanford.edu), вычисляющий информативность понятий с целью контроля создаваемых онтологий и выявления ошибок. Еще одно применение данного подхода возможно при создании и поддержке крупных баз данных, в которых иногда происходят нарушения целостности данных вследствие переполнения индексов. Разрядность индекса не должна быть меньше информативно -сти соответствующей ему сущности.
Заключение
Предлагаемый подход позволяет измерять количество информации, содержащейся в отдельных понятиях, лежащих в основе баз знаний, в общепринятых единицах теории информации. Использование понятия контекста позволяет устранить проблемы полисемии и других неоднозначностей, а также естественным образом ограничить пространство состояний предметной области. Следующий этап исследований, который может базироваться на предложенном подходе, - оценка информативности сложных высказываний, состоящих из понятий, количество информации в каждом из которых известно.
Литература
1. Рассел С., Норвиг П. Искусственный интеллект: Современный подход. - 2-е изд. Пер. с англ. - М.: Вильямс, 2006. - 1408 с.
2. Богданов И. В. Учебная информация и единицы ее измерения // Труды СГУ. - Вып. 44. -Гуманитарные науки. Психология и социология образования. - М.: Изд-во СГУ, 2002.
3. Бессмертный И.А. Семантическая паутина и искусственный интеллект // Научно-технический вестник СПбГУ ИТМО. - 2009. - № 6(64). - С. 77-82.
4. Bessmertny I.A. Knowledge Visualization Based on Semantic Network // Programming and Computer Software. - 2010. - V. 36. - № 4. - Р. 197-204.
Бессмертный Игорь Александрович - Санкт-Петербургский государственный университет информационных
технологий, механики и оптики, кандидат технических наук, доцент, [email protected]
УДК 004.056
УЯЗВИМОСТИ МОНИТОРОВ ВИРТУАЛЬНЫХ МАШИН Ю.Е. Евелев, Г.М. Чернокнижный
Рассмотрены проблемы безопасности систем виртуализации. Приведены уязвимости известных мониторов виртуальных машин (ВМ). Даны примеры эксплойтов. Рассмотрена технология УМ^е и ее возможности по увеличению эффективности системы защиты с учетом использования вендоров безопасности. Ключевые слова: виртуализация, уязвимость, вендоры безопасности, эксплойт.
Введение
Несмотря на то, что виртуальные серверы нематериальны, они точно так же уязвимы, как и обычные физические серверы. Деление физического сервера на отдельные ВМ никоим образом не делает эти машины безопаснее - виртуализация естественным образом передает им хорошо известные врожденные
слабости стандартных серверов. Ставится задача: рассмотреть основные угрозы, возникающие в виртуальной вычислительной среде, проанализировать недостатки ВМ с точки зрения безопасности в плане общего подхода и конкретно для известных гипервизоров. Анализ современных технологий повышения безопасности ВМ позволяет сформулировать рекомендации по их эффективной защите.
Основные угрозы при использовании виртуализации
Угрозы при использовании виртуальных машин можно разделить на «старые» и «новые». Под старыми угрозами понимаются традиционные угрозы, присущие любой IT-инфраструктуре. Это уязвимости операционных систем, уязвимости исполняемых программ и др. Под новыми угрозами понимаются уязвимости гипервизора (программного или аппаратного) и уязвимости менеджмента (управления) сложной виртуальной инфраструктурой:
- захват гостевой машины;
- вывод из строя виртуальной машины;
- компрометация управления ВМ;
- запуск неавторизованных ВМ;
- изменение разделения ресурсов - процессор, память, приоритеты;
- выключение машин;
- компрометация VMM/Hypervisor;
- организационные проблемы - разделение полномочий, политики информационной безопасности (ИБ), разграничение доступа.
Таким образом, при использовании виртуализации количество возможных уязвимостей возрастает, а традиционные угрозы (вирусы, DoS / DDoS атаки, переполнение буферов, SQL-injection, XSS, утечки информации) остаются. Основные недостатки виртуальных машин с точки зрения ИБ сводятся к следующему:
- Необходимость обновлять пакеты (программы) системы, что не всегда возможно и удобно. Обновление необходимо для устранения текущих уязвимостей и установки патчей. Обновить виртуальную машину довольно сложно, так как не всегда известно, на каком сервере она находится (Live Migration), в случае неграмотного менеджмента есть вероятность запутаться. В связи с этим необходимо четко задать каталогизацию виртуальных машин;
- Snapshots / Suspend затрудняют процесс управления обновлениями. Snapshot (снапшот) - моментальный снимок, копия файлов и директорий файловой системы на определенный момент времени. Это довольно полезная функция виртуальных машин, так как, например, в случае падения сервера восстановить его из снапшота - дело нескольких десятков минут. С другой стороны, снапшоты занимают довольно большие объемы винчестеров, само создание снапшота - довольно длительный процесс. Чаще всего в момент создания снапшота ВМ недоступна для конечных пользователей. Suspend - это пауза системы. Она может требоваться, например, для снятия нагрузки с энергосети на ночь. В случае, если той же ночью необходимо сделать резервную копию, это будет невозможно;
- Возможность разрастания неизвестных ВМ. В ходе работы с виртуальной инфраструктурой постоянно создаются новые ВМ, удаляются старые, некоторые ВМ теряются по тем или иным причинам (например, Live Migration). В этом случае происходит разрастание ВМ. Дабы оградиться от этого недостатка, необходим грамотный менеджмент виртуальной сети;
- Сложно контролировать ВМ, возможно появление неуправляемых, неизвестных ВМ;
- Динамическое перемещение (Live Migration);
- Перемещение ВМ в менее защищенные машины, сети;
- Атаки методом повтора операций и повторного использования данных;
- Проведение повторяющихся операций внутри ВМ может привести к повторяющимся криптографическим атакам;
- Воровство: ВМ - это файлы, очень просто украсть всю систему или несколько систем;
- Атаки на гипервизор. Гипервизор - это программа. Уязвимости программ были и будут всегда. В случае ограниченного финансирования необходимо четко расставить приоритеты между дополнительными функциями гипервизора и его безопасностью. Дополнительные функции увеличивают функционал гипервизора, но это и новые строки кода, а значит, и новые уязвимости [1].
Проблема безопасности виртуальной инфраструктуры может быть условно разделена на две составляющие:
1. безопасность виртуальных машин;
2. безопасность платформы виртуализации.
В первом случае, так же, как и на физической платформе, необходима установка средств защиты в гостевой операционной системе (антивирусы, сетевые экраны и прочее), а также правильная настройка виртуальных машин и виртуальных сетей. Например, в некоторых продуктах VMware (Workstation, Server) виртуальные коммутаторы являются по своей природе «хабами», что может открыть возможно-
сти по прослушиванию незащищенного трафика другими ВМ, контролируемыми злоумышленниками, и ввести в заблуждение системных администраторов [2].
В отношении безопасности платформы виртуализации необходимо проанализировать отчеты об уязвимостях платформ и учитывать этот фактор при выборе конкретной платформы. Частью обслуживания виртуальной инфраструктуры должна стать своевременная установка обновлений системы виртуализации и отслеживание критических уязвимостей. При этом необходимо также учитывать возможность внутреннего несанкционированного доступа в пределах хостовой системы. Сейчас атаки на виртуальные системы достаточно редки, ввиду не такого широкого распространения платформ виртуализации, поэтому истинная защищенность платформ виртуализации неизвестна. Аналитики предсказывают, что к 2015 году каждая вторая операционная система будет виртуализована, и со временем вопрос безопасности будет становиться все более серьезным.
Аппаратная виртуализация значительно упрощает написание программного обеспечения (ПО) с использованием технологий виртуализации, что значительно увеличит в ближайшее время объем подобного вредоносного ПО. О реальной опасности говорить еще рано, поскольку трудозатраты на его написание все еще достаточно велики. Компания Microsoft, разработавшая SubVirt, неоднократно заявляла, что затраты на его реализацию сравнимы с затратами на создание операционной системы. Тем не менее, эту опасность стоит иметь в виду, а производители антивирусного ПО в ближайшее время должны включить в свои системы возможности обнаружения руткитов, использующих виртуализацию.
Уязвимости программных средств виртуализации
Уязвимости продуктов VMWare перечислены ниже.
1. Уязвимость из-за ошибки в проверке входных данных в драйвере «HGFS.sys» из пакета VMware Tools. Атакующий может передать специально сформированные данные, что приведет к выполнению произвольного кода с повышенными привилегиями на гостевой Windows-системе.
2. Уязвимость из-за ошибки в проверке входных данных в «vmware-authd». Атакующий может передать специально сформированные данные, что приведет к выполнению произвольного кода с повышенными привилегиями на гостевой Linux-системе.
3. Уязвимость из-за ошибки в проверке входных данных в сервисе управления Openwsman при обработке «Content-Length» заголовков. Атакующий может получить привилегии «root» на целевой системе.
4. Уязвимость из-за ошибки в проверке входных данных в VMware VIX API. Атакующий может передать специально сформированные данные, что приведет к выполнению произвольного кода на хосто-вой системе.
Уязвимости продуктов SUN\ORACLE Virtual Box. В Virtual Box, как и в любом другом программном продукте, есть множество уязвимостей. Выделенная в данной работе уязвимость связана с уровнем привилегий в системе и позволяет локальному злоумышленнику выполнить вредоносные действия с повышенными привилегиями на целевой системе. Уязвимость существует из-за ошибки в проверке входных данных в драйвере VBoxDrv.sys при обработке определенных IOCTL. Атакующий может передать специально сформированные данные, что приведет к выполнению произвольного кода с привилегиями ядра.
Пример эксплойта: #include <windows.h/> #include <stdio.h/>
int main(int argc, char **argv) {
HANDLE hDevice; DWORD cb;
char szDevice[] = "\\\\.\\VBoxDrv"; if ( (hDevice = CreateFileA(szDevice, GENERIC_READ| GENERIC_WRITE, 0, 0,
OPEN_EXISTING, 0,
NULL) ) != INVALID_HANDLE_VALUE ) {
printf("Device %s succesfully opened!\n", szDevice); }
else {
printf("Error: Error opening device %s\n",szDevice); }
cb = 0;
if (!DeviceIoControl(hDevice, 0x228103,
(LPVOID)0x80808080,0,
(LPVOID)0x80808080,0x0,
&cb,
NULL)) {
printf("Error in Devicelo ... bytes returned %#x\n",cb); }
}
Уязвимости MS Virtual PC. Основной уязвимостью остается ошибка в управлении памятью на уровне монитора виртуальных машин (Virtual Machine Monitor). Она позволяет обходить такие защитные механизмы, как предотвращение выполнения данных (DEP), безопасная обработка исключений и рандомизация адресного пространства (ASLR) и может быть использована для повышения уровня привилегий или удаленно для выполнения кода. В своем блоге Microsoft отказывается признавать данную брешь уязвимостью, называя ее лишь способом более легкой эксплуатации уже имеющихся уязвимостей.
Уязвимости XEN. Одна из основных уязвимостей данного продукта позволяет локальному злоумышленнику обойти ограничения безопасности на целевой системе. Уязвимость существует из-за ошибки в проверке входных данных в Xen pygrub. Эксплуатирование уязвимости приведет к обходу механизма аутентификации на целевой системе. Пример эксплойта: xm create -c guest
press space bar to stop the grub count down press e to edit
select the kernel line and press e
Append a "1" to the end of the kernel line and press retur
press "b" to boot
Другой, не менее важной проблемой является уязвимость, которая позволяет локальному злоумышленнику выполнить DoS атаку на целевую систему. Уязвимость существует по двум причинам:
1. Из-за ошибки в проверке входных данных при обработке DR7 регистра отладки. Атакующий из вне гостевой системы может установить определенные точки останова, что приведет к краху гипервизора. Успешное эксплуатирование уязвимости, возможно, потребует использование гипервизорa HVM;
2. Из-за того, что доступ к регистру CR4 неправильно проверяется. Атакующий из вне гостевой системы может выполнить действия, приводящие к краху DomU или Dom0 доменов [3].
Вендоры безопасности и SECURITY API на примере VMSafe
В 2008 году компания VMware анонсировала технологию VMsafe. Реализацию VMsafe на данный момент можно увидеть только в программном пакете VMware vSphere, выпущенном в мае 2010 года. По своей сути, VMsafe - это технология, позволяющая сторонним разработчикам получить доступ к гипер-визору VMware и фактически представляющая собой набор API интерфейсов. Эти интерфейсы доступны по умолчанию в VMware vSphere, использовать этот набор API могут только ВМ управляемые решением по ИБ. Появление этой технологии позволило VMware, не проходя самостоятельного пути по созданию комплекса средств защиты, привлечь к обеспечению ИБ инфраструктур виртуализации, построенных на VMware vSphere, лидеров рынка ИБ.
В виртуальной среде при помощи технологии VMsafe и решений производителей средств ИБ (не исключая при этом разработку внутренних стандартов/политик обеспечения безопасности и следование рекомендациям производителей) можно обеспечить более высокий уровень ИБ, чем на физическом уровне.
Согласно официальной информации компании VMware, преимущества решений c использованием технологии VMSafe включают:
- Better Security - улучшение возможностей по обеспечению безопасности, появление новых возможностей мониторинга инфраструктуры не имеющих аналогов в физической инфраструктуре;
- Better isolation - улучшение изоляции гостевых операционных систем;
- Better correlation - улучшение возможностей по корреляции событий;
- Better enforcement across the infrastructure - решения, которые поддерживают технологию VMsafe, могут быть легко введены в эксплуатацию, так как такие решения обычно поставляются в виде виртуальных устройств (virtual appliance) и позволяют потратить меньше времени на их внедрение;
- Better scalability - улучшение возможностей масштабируемости инфраструктуры, сохраняя все правила и политики.
Работа с VMsafe может осуществляться в 2 режимах:
1. Kernel-mode - обработка в гипервизоре.
2. VM-mode - обработка внутри ВМ.
Для соблюдения политики безопасности необходимо настраивать политики виртуальных коммутаторов (vSwitch) на хостах таким образом, чтобы они были одинаковы - VLAN ID, имена Port Groups и т.п. Все это нужно поддерживать в актуальном состоянии. Технология Distributed vSwitch позволяет объединить несколько хостов VMware ESX Server одним виртуальным коммутатором, что дает множество новых возможностей.
- Появляется возможность централизованного назначения политик для такого коммутатора, что устранит ошибки в конфигурации и обеспечит задание параметров VLAN, групп портов и Security из единой точки интерфейса;
- Distributed vSwitch позволяет корректно работать механизму VMware Fault Tolerance, чтобы «теневая» копия ВМ имела идентичные сетевые политики на другом сервере, и в случае отказа основной ВМ мгновенно заменяла ее в действующем сетевом окружении. Таким образом, получаем не просто отказоустойчивый кластер, а безопасный отказоустойчивый кластер;
- Появляется возможность перезагружать коммутатор, не перезагружая хост ESX. Это необходимо для того, чтобы при изменении числа портов у коммутатора, не перезагружать хост ESX.
В контексте безопасности VMware продукт VMsafe Distributed vSwitch занимает отдельное место. На каждом сервере VMware ESX появляется еще одна ВМ «Security VM», подключенная к распределенному виртуальному коммутатору и выполняющая функции обеспечения сетевой безопасности для виртуальных машин сервера. Это может быть IDS/IPS-система, Firewall и т.п. - а может и все вместе. При этом защищающая ВМ назначает политики защищаемой ВМ. При миграции работающей ВМ за счет технологии VMware VMotion эти политики «переезжают» на другой хост-сервер ESX.
Данная модель говорит о том, что в виртуальной инфраструктуре VMware отпадает необходимость в установке агентов ПО для безопасности внутри ВМ, а управление политиками безопасности данных систем становится гораздо проще [4].
Заключение
Проведенный анализ угроз виртуализации и уязвимостей гипервизоров позволяет сделать вывод о том, что правильно развернутая инфраструктура, использующая виртуализацию, может обеспечить дополнительный уровень безопасности машинам в сети. К операционным системам и приложениям, запускаемым на ВМ, должны применяться те же меры безопасности, что и на индивидуальных физических машинах. Безопасность ВМ - это вложение, которое нужно делать. Виртуализация должна быть всего лишь одним из многих инструментов в арсенале надежности.
Литература
1. Грам В. Технологии виртуализации и повышение эффективности функционирования корпоративных предложений // Копьютерра [Электронный ресурс]. - Режим доступа: http ://offline.computerra.ru/2009/06.html, своб.
2. Черняк Л. Виртуализация серверов стандартной архитектуры // Открытые системы [Электронный ресурс]. - Режим доступа: http://www.osp.ru/os/list/2009/04.html, своб.
3. Keir T. Virtualization: The Executive Summary // [Электронный ресурс]. - Режим досту-па:http://www.pcworld.com/businesscenter/article/215199/virtualization_the_executive_summary.html, своб.
4. Причины выбрать Vmware // [Электронный ресурс]. - Режим доступа: http://www.vmware.com/ru/virtualization/why-choose-vmware.html, своб.
Евелев Юрий Евгеньевич - Санкт-Петербургский государственный инженерно-
экономический университет (ИНЖЭКОН), студент, [email protected]
Чернокнижный Геннадий Михайлович - Санкт-Петербургский государственный инженерно-
экономический университет (ИНЖЭКОН), кандидат технических наук, доцент, [email protected]
