 |
|
|
|
Против лома есть приемы. Обеспечение безопасности сетевой инфраструктуры
Против лома есть приемы Безопасность не определяющий фактор при выборе технологии виртуализации. Но в некоторых вопросах виртуальные машины могут успешно конкурировать с привычными средствами защиты Мы окружены виртуальными технологиями. Без некоторых из них уже тяжело представить сегодняшний мир: VLAN, VPN, LVM, зоны и Crossbow Open/Solaris [1], Jail и многое другое. Абстрагирование от физического устройства или среды позволяет более гибко решать практически любые задачи, возникающие при администрировании и защите сетей, систем и сервисов. Ведь используя виртуальный «рубильник», достаточно просто ограничить или увеличить ресурсы, изолировать потенциально опасный сервис или, наоборот, установить приманку (honeypot), произвести быстрое восстановление или перенести систему на другой сервер. Именно удобство управления привело к тому, что такой подход используется везде, где в этом есть смысл: в программировании, в администрировании и защите данных. В случае же виртуализации серверов некоторые моменты не так очевидны, и многие специалисты не связывают использование виртуальных машин или виртуальных сред с повышением безопасности, а даже, наоборот, их использование считается минусом для безопасности. Не спорю, подобные утверждения небезосновательны, ведь появление еще одного слоя, как минимум, увеличивает число объектов потенциальных угроз А значит, вместо улучшения мы можем получить еще больше проблем. Поэтому единого мнения по поводу данного вопроса не было и не будет. Но с одной стороны, прогресс не стоит на месте, технологии обкатываются, и уровень безопасности сегодняшних виртуальных систем признан достаточно высоким, чтобы им доверять свои сервера. С другой стороны, по мере роста популярности будет возрастать число желающих найти уязвимость в виртуальных машинах. И если злоумышленник найдет проблемное место, то вместо компрометации одного физического сервера мы поставим под удар несколько виртуальных. Более того, у специалистов нет единого мнения по защите виртуальных сред. Одни говорят, что достаточно классических инструментов – вроде IPS и антивирусов, другие считают, что это должны быть специфические средства. И они появляются. Как пример можно привести технологию повышения безопасности VMware VMsafe (см. рисунок), представляющую API, которая позволяет контролировать все, что происходит в виртуальной машине, и остановить вредоносную программу до того, как она сможет заразить ОС. Сегодня VMware VMsafe поддерживается уже в нескольких продуктах (Reflex VMC, Trend Micro Core Protection for Virtual Machines).
Технология защиты для системы виртуализации VMware VMsafe уже интегрирована в некоторые продукты Учитывая, что виртуальные машины в некоторых ситуациях практически не уступают физическим, только психологический барьер мешает перейти полностью на виртуальную среду. Но те, кто хоть раз попробовал восстановить виртуальный сервер из снимка (snapshots) или перевести виртуальную машину на другое оборудование при помощи Live Migration (VMotion), наверняка будут планировать следующую модернизацию с учетом использования виртуальных машин. Классическое определение обеспечения безопасности состоит из трех основных составляющих: конфиденциальность, целостность и доступность. Современные условия добавляют к ним и другие требования: подлинность, достоверность и подотчетность. Причем не обязательно один инструмент должен обеспечивать все эти условия. Безопасность требует комплексного подхода, именно поэтому мы сегодня наблюдаем такое разнообразие продуктов. Виртуальные машины как нельзя лучше выполняют многие из этих требований и могут потеснить продукты, бывшие популярными долгое время. Ограничение процессов и сервисов Наверное, один из самых популярных примеров использования технологий виртуализации для защиты систем – это изолирование или ограничение доступа потенциально опасного сервиса к файлам базовой системы. Принцип работы достаточно прост и описан многократно. Сервис выполняется в отдельной среде, при этом используется изолированная от основной иерархия файлов, которая является корневой для запущенного процесса. В случае появления проблем – взлома или нестабильной работы – все они будут локализованы внутри запертой среды сервиса, и потому основная система работает как обычно: «не замечая» нештатной ситуации. Наиболее популярны в контексте создания изолированной технологии вроде Jail/chroot, реализующие в рамках ОС безопасную закрытую среду – «песочницу» (sandbox), в которой запирается и выполняется сервис и приложение. В принципе, Jail/chroot сегодня также относят к технологиям виртуализации, ведь процесс работает в специально созданном для него виртуальном окружении. Хотя изначально Jail/chroot создавалась как средство ограничения доступа, то есть подсистема безопасности, чем они, собственно, и являются. И только сейчас, с появлением нужной терминологии, их стали классифицировать как системы виртуализации. В случае взлома максимум, что может получить злоумышленник, – это доступ к файлам конкретного сервиса, пройти дальше chroot он не сумеет. Реализации chroot известны достаточно давно и поддерживаются на уровне ядра всеми UNIX-подобными ОС. Технология считается проверенной временем, поэтому использование chroot имеется во всех рекомендациях по повышению безопасности системы и используется повсеместно. Более того, некоторые сервисы либо изначально сконфигурированы для запуска в chroot-среде, либо запустить этот механизм в действие можно лишь сняв комментарий в конфигурационном файле. Дополнительные инструменты вроде Jailkit [2] существенно упрощают перевод в chroot любого приложения как серверного, так и пользовательского (браузеры, Skype, IM-клиент и так далее). Кроме прочего, используется chroot для создания honeypot (специальных сервисов, привлекающих внимание атакующих) и для тестирования программ в «чистой» среде. Но у chroot есть и недостатки: система ограничений распространяется исключительно на файловую систему, поэтому она не может являться полностью безопасной. Если процесс внутри запущен от имени суперпользователя, есть опасность выхода из chroot окружения в случае обнаружения уязвимости внутри механизма chroot. Сегодня уже есть концепты [3] и готовые эксплоиты, реализующие эту атаку, правда, их не так уж и много, но это не значит, что они не появятся в будущем, ведь реализаций chroot немного, и они хорошо известны. Но главным минусом chroot можно считать отсутствие механизма ограничения системных ресурсов, а поэтому в случае проблем процесс может повлиять на основную систему. Например, захватить процессорное время, увеличить объем операций ввода-вывода, заполнить раздел на диске и т.п. И в итоге спровоцировать отказ в обслуживании для других подсистем. Теперь обратим внимание на возможности систем виртуализации. Не разделяя их по принципу действия: уровня ОС, реализующих виртуальную среду (Virtual Environments) – контейнеры Solaris, OpenVZ, Linux-VServer, или более «тяжелые» – VirtualBox, VMware, ESX, KVM, Hyper-V. Использовав одно из этих решений как средство ограничения, мы получаем более предсказуемую и управляемую среду. Ведь возможностей по управлению нештатными ситуациями в виртуальных машинах на порядок больше, чем в chroot. Администратор при их создании указывает лимит ресурсов: дисковая квота, операции ввода/вывода, процессорное время, ОЗУ и изоляция сети. Злоумышленник может нанести вред исключительно виртуальной системе и никому больше, остальные подсистемы, работающие на том же сервере, в других контейнерах или виртуальных машинах, не узнают о появившихся проблемах и будут, как и прежде, получать свою порцию ресурсов. То есть у взломщика меньше возможностей повлиять на работу сервера, чем при использовании традиционного chroot. А «добраться» до самой системы виртуализации не так уже и просто, ведь внешне виртуальная система зачастую выглядит как обычная ОС, практически не выдавая своего «ненастоящего» происхождения. Более вероятной является атака на интерфейс управления виртуальной машиной. Примером может служить взлом и удаление 100 тысяч сайтов хостинг-провайдера Vaserv [4], в котором использовалась уязвимость в панели управления HyperVM, позволяющая провести SQL-инъекцию и получить доступ к файлам. Но у виртуальных машин есть еще один несомненный плюс. Доступность данных Сохранность и доступность данных является залогом успешной работы всех категорий пользователей. Если нет доступа к определенному сервису, то организация будет фактически простаивать, работу свою не смогут выполнять пользователи на всех уровнях: кассир не сможет принять и выдать деньги, менеджер – оформить заказ и получить отчет, посетитель интернет-магазина уйдет к конкуренту. Этот список можно продолжать и продолжать, и зачастую больший вред приносят не финансовые потери, а удар по имиджу, который восстановить не так уж и просто. Ведь достаточно «зависнуть» банкомату – и в следующий раз люди предпочтут другой банк, благо выбирать есть из чего. Задача доступности решается несколькими способами. Основные из них: обязательное резервирование данных для их быстрого восстановления и создание отказоустойчивых систем. Оба варианта не являются взаимоисключающими и должны использоваться в комплексе. Использование технологий виртуализации как нельзя лучше позволяет решить обе проблемы. Системы резервного копирования, работающие на уровне файлов, – ставшие уже стандартным средством, позволяющим быстро восстановить работоспособность сервера. Планируя операции по архивированию данных, всегда приходится выбирать между удобством восстановления и ресурсами, необходимыми для создания копии. В результате различных схем резервирования разработано немало, от использования выбранной зависит быстрота восстановления. Ведь если полная копия создавалась в субботу, а сбой произошел в пятницу, то администратор вынужден будет пройти полный путь, использовав все промежуточные копии. При этом фактор времени часто является определяющим, и главная – быстро вернуть к жизни рухнувший сервис, разбираться в причинах часто нет времени (что неправильно, но часто ситуация против). Виртуализация позволяет значительно сократить время на операцию восстановления работоспособности, ведь вместо копирования отдельных файлов здесь используется система снимков (snapshots), полностью сохраняющих состояние машины на момент снимка. Причем в большинстве реализаций создание снимка не требует остановки виртуальной машины, то есть операция не снижает время доступности. Но снапшоты дают возможность достаточно быстро вернуть сервер к жизни, не прибегая к повторной установке ОС и восстановлению данных. Естественно, каждая реализация имеет свои особенности – например, архивация Hyper-V и все связанные моменты описаны в документе «Планирование архивации» [5]. Кроме этого администратор может так же быстро сохранить текущее состояние для дальнейшего изучения проблемы. Хотя нужно отметить, что снимки ни в коем случае не являются заменой резервному копированию данных, а лишь хорошо дополняют его. Ведь никто не застрахован от сбоев самой системы виртуализации или основной ОС, когда нельзя будет воспользоваться снимком. Но для быстрого возврата системы в рабочее состояние это весьма ценный инструмент. В принципе, можно возразить, что метод создания снимков не является чем-то новым и революционным. Достаточно вспомнить продукт Acronis Backup & Recovery/True Image [6], который поддерживает все описываемые методы: пофайловое и посекторное резервное копирование, создание снимков, резервирование данных на рабочей системе, резервирование некоторых типов виртуальных машин (VMware, Hyper-V, Citrix XenServer и Parallels) и, соответственно, быстрое восстановление, в том числе и на другое оборудование. Но все же есть ряд существенных отличий между снимком системы, сделанным Acronis, и снимком виртуальной ОС. Так, Acronis, создавая снимок, работает с физическим сервером; если на нем запущено несколько сервисов при создании копии, придется сохранить большое количество данных. Соответственно, при восстановлении будет затрачено большее количество времени, чтобы перенести их обратно на жесткий диск и запустить систему. Виртуальные серверы, как правило, ограничены в ресурсах, поэтому вместо одного большого мы получаем несколько меньших снимков, которые быстрее создаются и быстрее восстанавливаются. Но и технологии использования снимков в виртуальных системах совершенно другие. Ведь при создании снимка обычно сохраняется текущее состояние машины, а все изменения записываются уже в новый образ. Выглядит операция достаточно просто, и принцип везде одинаков, с небольшими отличиями. Например, система использует образ vm-name.vmdk, начинаем процесс создания снимка. Виртуальная машина VMware монтирует образ vm-name.vmdk в режиме «только чтение» и создает новый образ vm-name-delta01.vmdk, в который начинает записывать все изменения. При создании следующего снимка в режим «только чтение» переводится vm-name-delta01.vmdk и создается образ vm-name-delta02.vmdk. И так далее. В результате создание снимка мощного виртуального сервера происходит практически мгновенно и не требует большого количества операций ввода-вывода, как это происходит с Acronis. В зависимости от конкретного решения поддерживаются следующие варианты восстановления:
Поэтому очевидно, что сравнивать классические методы резервирования и восстановления системы с используемыми в виртуальных машинах некорректно, хотя это не взаимоисключающие, а отлично дополняющие друг друга технологии. Кластеры решают все Но есть еще один момент, позволяющий построить безотказную среду при помощи виртуальных систем. Речь идет о кластерах, которые используются в тех случаях, когда простои информационной системы недопустимы, клиенты должны иметь непрерывный доступ к сервисам и приложениям. Я специально не буду выделять какой-либо тип – высокой готовности (High-availability, HA) или балансировка нагрузки сети (Network Load Balancing, NLB), чтобы просто передать идею, а не разбираться в различиях. Кластеры – это всегда избыточность. Для его построения используется два и более сервера, выполняющих, как правило, сходные функции. В случае выхода одного из серверов остальные продолжают работать, предоставляя доступ к сервису. В обычной ситуации нам требуется как минимум два физических сервера, которые и предоставляют все необходимые услуги. Но «навешивание» большого количества сервисов на один физический сервер не является хорошей практикой, хотя бы потому, что проблемы в работе одного из них могут сказаться на работе остальных. К тому же не редкость сегодня гетерогенная среда. «Нарезая» физический сервер на несколько виртуальных, мы фактически решаем все эти проблемы. Один сервер может выполнять одну роль и работать под управлением нужной ОС. Кроме этого, так легче распределить нагрузку между серверами более равномерно. В журнале уже подробно описывалась реализация подобного решения [7]. Такие технологии виртуальных машин, как Live Migration [8], позволяют мгновенно переносить виртуальную машину между физическими серверами, например, в случае необходимости остановки одного из серверов для технического обслуживания. Процесс происходит настолько быстро, что TCP-соединения (ведь сетевые интерфейсы тоже виртуальны) не успевают разорваться, а пользователи даже не замечают, что они уже работают совсем с другим сервером. Анализ уязвимостей Собственно, эти вопросы косвенно уже затрагивались выше. Применение виртуальных машин позволяет настроить honeypot и собирать информацию о методах взломщиков, чтобы определять источники опасности. Учитывая, что такая система специально подставляется взломщику, использовать для этих целей сервер, выполняющий другие функции, было бы глупо. Без применения виртуальных машин нам потребовалось бы выделить отдельный физический сервер, что весьма дорого. Теперь же мы можем настроить любое количество ложных сервисов, развернув honeynet в любом месте корпоративной сети и используя их как датчики нападения и сбора данных о действиях хакеров. И главное – все это без опасения, что действия злоумышленника могут сказаться на работе сети или сервисов. Учитывая, что сегодня технологии виртуализации уже достаточно распространены, использование виртуальных систем для построения honeypot не должно насторожить взломщика. Кроме этого, большинство угроз исходят из систем, которые работают автоматически, без участия пользователя: сетевые черви, брутфорсеры, вирусы. При использовании физического сервера в случае взлома системы или любой другой нештатной ситуации важным фактором является время восстановления работоспособности. Поэтому часто просто пренебрегают дальнейшей возможностью произвести анализ (forensic analysis), а просто восстанавливают систему из резервной копии. Виртуальные машины в этом случае просто бесценный инструмент. Ранее уже говорилось о снимках, можно сохранить текущее состояние системы для дальнейшего исследования, чтобы выяснить, что успел сделать взломщик, какие инструменты использовал, какие следы оставил. Причем исследователь получает исключительную возможность провести анализ на «живой системе» (Live analysis), ведь некоторые вирусы сегодня живут исключительно в ОЗУ, не оставляя следов на жестком диске. Просто создав копию диска взломанной системы, мы потеряем важную информацию о процессах и активных сетевых соединениях. Кроме этого, в старом снимке часто может не быть некоторых новых или изменившихся файлов, созданных пользователями. Вполне возможно, что это документ, который нужен был еще вчера. Без проблем. Запускаем виртуальную машину, изолировав ее от сети, и забираем нужный документ, делаем копию базы данных и переносим все, что нужно, на работающий сервер. Если же виртуализация до этого не использовалась, то самое время вспомнить о возможности P2V-миграции, позволяющей получить точную копию физического компьютера в виртуальной среде (Physical to Virtual). Большинство разработчиков решений виртуализации представили необходимые инструменты, позволяющие достаточно просто произвести нужный перенос [9-11]. *** Виртуализация может сослужить хорошую службу в сфере повышения защищенности систем и анализа произошедших проблем. Но очевидно, что рынок виртуализации находится на раннем этапе развития, практически каждый день мы видим анонсы, объявляющие о появлении новых технологий и инструментов. И хотя безопасность сегодня не является основным фактором, который голосует за использование виртуальных систем, в будущем по мере роста вычислительных мощностей и новых инструментов, вполне вероятно, можно ждать смещения приоритетов.
|
СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и четырех книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
