Практика защиты виртуальных сред

Параметры безопасности гипервизоров

Практически ни одна компания не настраивает никаких параметров ИБ после внедрения виртуальной среды. Если эта операция и проводится, она является инициативой снизу: квалифицированные специалисты могут настроить те или иные параметры на свое усмотрение, но времени на их полноценный анализ и настройку в рамках всей инфраструктуры у них нет – необходимо решать повседневные задачи. Стоит отметить, что, например, несмотря на сильную с точки зрения ИБ архитектуру гипервизора Citrix XenServer, его безопасность сильно зависит от безопасности домена 0. Итак, основываясь на нашем проектном опыте защиты ВС на базе этого продукта, мы рекомендуем настроить:

• параметры демона SSHD – запрет входа от имени root, настройка su/sudo;
• параметры однопользовательского режима – запрет получения консоли root без пароля;
• параметры загрузчика extlinux – защита паролем изменения опций загрузки ядра;
• режим хранения паролей в файле /etc/shadow;
• локальную парольную политику, включая качество пароля, частоту его смены и сроков действия, хранение их истории;
• отключение возможности работы VIF (Virtual Interface) в promiscuous mode, это позволяет ограничить вероятность «прослушки» виртуальных машин друг другом;
• отключение автозагрузки xsconsole под root на физической консоли tty1 – запрет неконтролируемого доступа от имени root без аутентификации при наличии прямого доступа к серверу;
• параметры ядра для борьбы с флудом (SYN, ICMP и т.д.);
• запрос пароля при подключении к XenServer из XenCenter;
• централизованный аудит с использованием Syslog;
• контроль целостности образа гипервизора, ядра операционной системы домена 0 и ее основных системных исполняемых и конфигурационных файлов.

Наша практика защиты VMware и Microsoft Hyper-V показывает, что эти гипервизоры также требуют настройки. После перехода VMware ESXi с версии 4.1 на 5.0, а затем на 5.1 решение значительно продвинулось в настройках по умолчанию с точки зрения их оптимизации по требованиям ИБ. К тому же вендор разработал такие полезные документы, как vSphere 5.0 Security Hardening Guide и черновик vSphere 5.1 SHG, что позволяет ему выглядеть наиболее передовым в плане подхода к обеспечению ИБ.

Компания Microsoft со своей стороны подготовила документ Hyper-V Security Guide, но он, в отличие от VMware, субъективно менее удобен при использовании на практике и к тому же давно не обновлялся производителем. Кроме того, безопасность гипервизора Hyper-V сильно зависит от безопасности операционной системы Windows, что не добавляет уверенности с точки зрения ИБ при построении виртуальных сред на базе этого продукта.

Встроенные системы журналирования

Так случилось, что прогрессивная, опробованная годами система управления виртуальной средой VMware vCenter имеет ряд очевидных недостатков по части журналирования событий ИБ. Попробуем рассмотреть часть из них.

Событие выхода из системы не связано с событием входа. Если параллельно работает несколько сервисов от имени одной учетной записи, нет возможности отследить, какая из них и какие действия выполняет в реальности. Можно попробовать угадать: первый выход был осуществлен из первого подключения или из второго?

Более того, даже если заглянуть в БД SQL Server – что в таблицу dbo.VPX_EVENT, что в VPX_EVENT_ARG, где vCenter хранит события, – возможностей точно определить действия опять же не представится. Т.е. правилом должно быть следующее: никакие пользователи и сервисы не должны использовать одну и ту же учетную запись. Далее рассмотрим события vCenter, генерируемые в рамках процедуры аутентификации пользователя:

• неправильный ввод пароля;
  
  

  Cannot login ysergeev@10.31.248.142

  error

  05.03.2013 16:25:42

  ysergeev

• вход от имени несуществующего пользователя;
  

  Cannot login ysergee@10.31.248.142

  error

  05.03.2013 16:26:29

  ysergee

• вход от имени заблокированной учетной записи.
  

  Cannot login test@10.31.248.142

  error

  05.03.2013 16:28:29

  test

Таким образом, по структуре самого события определить причину неуспешной аутентификации невозможно. Для решения этой проблемы в SIEM (Security Information and Event Management) необходимо вести списки учетных записей. Например, в ArcSight ESM можно создать два Active List: VMware Users – Enabled, VMware Users – Disabled. После чего проверять события от VMware по ним и генерировать скоррелированное событие на возникновение первичных событий VMware касательно учетных записей из этих списков. Сами списки при этом должны формироваться на основе аудита из ОС Windows.

Что же может незаметно сделать злоумышленник после успешного входа в систему? Например, если у него есть всего лишь права обычного пользователя VMware vCenter, он может незаметно создать роутер между доступными ему VLAN и тем самым обойти любой аппаратный межсетевой экран, размещенный в сети. Допустим, злоумышленник хочет получить доступ к сетевому сегменту в обход средств межсетевого экранирования и добавляет в конфигурацию виртуальной машины win2003-srv-01 второй виртуальный адаптер, указывая ему другой Port Group (фактически VLAN). А затем настраивает маршрутизацию между интерфейсами в ОС виртуальной машины).

События в VMware же лишь указывают на то, что конфигурация ВМ была каким-то образом изменена. Как это влияет на безопасность, судить по ним сложно. И в этом случае SIEM нас уже не выручит, как в случае с аутентификацией. Получается, что нужно использовать либо стороннее средство контроля доступа и журналирования событий ИБ, отличное от vCenter, либо инструменты контроля конфигураций виртуальной инфраструктуры. В качестве таких продуктов могут выступать решения HyTrust и Tripwire Enterprise.

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

Фактически мы можем создать любой Port Group или удалить его из любого vSwitch абсолютно незаметно. А потом подключить его к нужной виртуальной машине… При этом стоит отметить, что удаление vSwitch проходит уже более детально.

Но оно все равно не позволяет понять, какой объект был действительно удален на ESXi-сервере 10.31.32.12. Ведь ни наименования, ни номера vSwitch в событии не представлено.

Конфигурации виртуальных машин

Практически во всех компаниях используются конфигурации, создаваемые мастером конфигурации по умолчанию, что приводит к тому, что в ВМ появляется несколько устройств, а соответственно и драйверов, которые ей никогда не используются. В 2012 году снова были выявлены уязвимости, позволяющие реализовать escape-атаки по причине наличия виртуальных устройств. Так, бюллетень CVE-2012-2450 дает возможность провести такую атаку из-за проблемы с регистрацией в виртуальной машине SCSI-устройств, что может привести к DoS-атаке и выполнению произвольного кода на сервере виртуализации. А CVE-2012-2449 позволяет выполнить аналогичные виды атак, но уже через виртуальный floppy. Таким образом, из-за одного неиспользованного floppy-дисковода, да еще и виртуального, злоумышленник получал, в конце концов, возможность приобрести контроль над всей виртуальной инфраструктурой.

Особенности работы сертифицированных средств защиты от НСД

На текущий момент в России сертифицировано только одно наложенное средство защиты для ВС – vGate. Сам факт появления продукта такого класса в нашей стране, безусловно, вдохновляет. Тем не менее наша практика его настройки показывает, что у него имеется ряд значительных недостатков, которые допустимы лишь для небольших виртуальных инфраструктур, состоящих не более чем из 4–8 серверов виртуализации. В то же время есть надежда, что необходимость расширения присутствия в корпоративном секторе поможет разработчику усовершенствовать решение. Это выглядит реализуемым ввиду наблюдаемого нами развития продукта в последние несколько лет.

Безусловно, производитель старается оперативно реагировать на проблемы. Так, например, доверенная загрузка виртуальных машин, являющихся рабочими станциями, управляемыми VMware View, была долгое время недоступна, а затем стала возможной после внесения изменений в код ПО. Еще одной проблемой, переходящей в Release Notes от версии к версии, являлась потеря возможности контроля целостности виртуальной машины после изменения русскоязычных параметров ВМ через VI Client. Но, кроме того, замечены некоторые архитектурные недостатки, исправить которые может быть несколько сложнее. Решение vGate:

• требует установки своих компонент на каждый ESXi и vCenter, а также на каждую рабочую станцию пользователя;
• требует ведения 2 отдельных баз учетных записей с несинхронизируемыми паролями между ними;
• не отображает иерархию размещения виртуальных машин по ESXi-серверам, кластерам и дата-центрам;
• осуществляет псевдопроксирование запросов к vCenter/ESXi, но не проксирование ответов – обратный трафик может быть заблокирован любым нормальным stateful межсетевым экраном;
• не импортирует автоматически список Port Group;
• не имеет интеграции с Active Directory;
• не имеет возможностей применения 2-факторной аутентификации.

При этом компоненты, устанавливаемые на каждый физический сервер, включают межсетевой экран. Доставка правил межсетевого экранирования осуществляется автоматически непрозрачным способом – после установки на vCenter доступ к нему будет потерян на неопределённое время (обычно от 1 до 15 минут), которое потребуется для синхронизации с сервером. Никакого статуса или журнала, отражающего процесс доставки, найти будет невозможно. В облачной среде vCloud или при использовании VDI это приведет к их неработоспособности ровно на то время, на которое будет недоступен vCenter, что в Enterprise-среде недопустимо. При этом возникают проблемы с обновлением компонентов, переносом настроек.

Особенно удивляет необходимость ведения 2 баз учетных данных – в результате привилегии пользователей в рамках мандатной политики доступа назначаются в vGate, а вот дискреционный контроль доступа остается целиком на плечах VMware vCenter. Кроме того, vGate при журналировании использует сбор событий ИБ из vCenter, автоматически наследуя несовершенство их системы аудита. Это рождает вопрос: если мы используем механизмы защиты vCenter (аутентификация, разграничение доступа и аудит), должны ли мы сертифицировать его по требованиям безопасности информации, когда нам нужна сертифицированная защита? А гипервизор? Исходя из архитектуры работы продукта, ответом должно быть – да, должны.

Обслуживание системы осложнено не только проблемами с установкой компонентов на все точки подключения к vGate, но и тем, что Port Group в решении прописываются вручную и при этом обязательным и уникальным полем для них является номер VLAN. В реальности в vCenter мы можем иметь несколько Port Group с одним и тем же VLAN и это может быть обоснованно. Завести их в vGate штатным способом не получится. К тому же если администратор вносит новую сеть в vCenter, кому-то после этого нужно ее сразу прописать в vGate. В условиях, когда этим занимаются разные люди, часто редко пересекающиеся, это приведет к усложнению процесса обслуживания.

Последней существенной проблемой можно назвать отсутствие импорта иерархии виртуального ЦОД. ВМ отображаются единым списком, нет возможности понять, на какой площадке они находятся, на каком физическом сервере сейчас работают без использования отдельной консоли vSphere Client. Когда этот список исчисляется не 10–20 виртуальными машинами, а сотнями, конструкция становится сложно управляемой. Особенно когда метки безопасности нельзя задать для таких сущностей, как Folder, Resource Pool, Cluster, Datacenter, Network, а лишь для VM, ESX Host, Datastore и Port Group.

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

Особенности антивирусной защиты

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

Первое, с чем встречаешься на практике, – то, что безагентский антивирус реализован сложнее, чем безагентский межсетевой экран и средство обнаружения вторжений. Для его работы необходим драйвер VMware Endpoint не только на уровне гипервизора, но и в каждой ВМ! Сегодня при использовании VMware ESXi 5.x драйвер уже будет идти в составе VMware Tools (если пакет установлен в полном режиме или в режиме выбора компонентов с указанием Endpoint-драйвера, а не в стандартном), но тем не менее... При этом действительно антивирусное ПО в каждую ВМ не устанавливается. Таким образом, отключение Endpoint-драйвера в виртуальной машине приведёт к отключению антивирусной защиты для нее. Безусловно, хотелось бы, чтобы у вредоносной программы не было возможности отключения защиты, что архитектурно достигнуто для контроля сетевых взаимодействий.

Возможностей по обнаружению вредоносного ПО у безагентского антивируса также меньше. Он фактически контролирует только Disk I/O операции и не позволяет перехватывать ПО, не осуществляющее сохранение тела программы на жесткий диск. Это допустимо для серверов, где пользователи не работают напрямую в интернете, но для виртуальных рабочих станций (а именно для них безагентское решение обеспечивает максимальную эффективность с точки зрения производительности!) нужно применять дополнительные меры. Такой мерой может быть настроенный профиль IPS, например.

Безусловно, архитектура безагентских решений обеспечивает в разы меньшую нагрузку на все ресурсы физического сервера виртуализации: обновлять нужно не 1000 агентов в 1000 виртуальных машинах, а 50 в 50. В больших сетях это может быть неплохим подспорьем при принятии решения о том, каким антивирусом пользоваться. Безагентское решение также выигрывает благодаря предсказуемости своего влияния на производительность инфраструктуры. На основе нашего проектного опыта составлены три графика для On-Demand Scan проверки 20 узлов (см. рис. 8, 9 и 10).

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

В итоге по CPU и RAM безагентские решения заметно выигрывают, а вот благодаря тому, что агентские средства защиты имеют больше возможностей для исключения сканирования ранее проверенных файлов, операции с дисковой подсистемой в их случае более эффективны до тех пор, пока не случается пересечения – одновременного сканирования в нескольких ВМ. В этом случае прогнозировать рост нагрузки очень сложно, да и при измерениях, скорее всего, он будет варьироваться. В целом предсказуемость работы безагентского решения кажется более перспективной. Но агентские средства (например, Symantec Endpoint Protection 12.1) при должной настройке также показывают неплохие результаты. Мы думаем, что имеющиеся недостатки безагентских систем в ближайшем будущем будут устраняться быстрыми темпами вместе с развитием систем виртуализации.

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