Чем дальше развиваются технологии виртуализации, тем больше разнообразных «грандов ИТ технологий» выходит на рынок. Несмотря на то, что проект Xen как таковой довольно давно существует в виде open source решения, такая операционная система с интегрированным гипервизором как Citrix XenServer относительно недавно привлекла внимание клиентов Enterprise уровня. Изначально ОС была ориентирована на low/mid-end предприятия и предназначалась для решения проблем минимизации затрат на мультисерверную архитектуру. Но в процессе развития, компания Citrix интегрировала в свой гипервизор такие жизненно важные вещи как High Availability и Likewise интеграцию c Active Directory. Таким образом, на данный момент существуют коммерческие версии Citrix XenServer позиционирующиеся как реальная альтернатива VMWare ESX/ESXi. Но, как известно, к гипервизорам предъявляются особые требования безопасности. Это обусловлено тем, что при захвате гипервизора наиболее вероятно, что компания потеряет не только его, но и все виртуальные машины.
Все чаще и чаще вендоры выпускают свою документацию по настройке как самой системы так и руководства класса «Hardening/Security Guide». Компания Citrix выпустила документы Common Criteria Security Target и User Security Guide. Данные документы имеют ряд рекомендаций и советов, но имеют слишком мало практической информации. В документации по CCST вы можете найти формальное описание объекта защиты и ряд практических настроек. В User Security компания описала общую методологию защиты системы. Таким образом, полноценный Security Guide от Citrix, который полностью бы охватывал все аспекты, к сожалению, отсутствует.
В 2011 году компания Citrix получила звание Security Organization of the Year от ISSA. Особо подчеркивалось, что к продуктам Citrix применим термин «Secured By Design». Возможно, некоторые решения от этой компании и можно отнести к данной категории, но исследование их серверных продуктов XenServer показали наличие некоторой специфики их дизайна и своеобразие трактовки данного термина группой специалистов Citrix. В нашей статье мы познакомимся с некоторыми аспектами эксплуатации Citrix Free XenServer 5.6.0 и проблемами безопасности, которые возможно могут возникнуть при практическом использовании данной системы. Выбор конкретно данной версии обусловлен довольно большой распространенностью и известностью. Многое из сказанного далее не претерпело никаких изменений в версиях 6-го семейства.
Основой всего гипервизора является XenAPI (XAPI). Это демон, выполняемый системой с правами суперпользователя и обеспечивающий интерфейс управления самой системой и виртуальными машинами. Будучи прямым родственником операционной системы Red Hat Enterprise Linux гипервизор унаследовал ряд стандартных решений от прародителя. Таковым является модуль PAM, отвечающий за подключение к XAPI.
Данный модуль по умолчанию настроен на полный include стандартных настроек из system-auth. На практике же это значит, что любой пользователь, имеющий учетную запись в системе, может исполнять запросы XAPI с правами pool-admin за исключением смены пароля root средствами API. Данная особенность системы является документированной и присуща версиям Free и Advance. По политике компании Citrix при использовании данных вариантов XenServer вы имеете системы с «единым уровнем» пользователя, — LSU (Local Super User). Данное решение компании Citrix представляется сомнительным в рамках идеологии построения продуктов уровня Enterprise в ее общественном понимании.
Данная специфика создает некоторые проблемы в рамкам использования гипервизора как многопользовательской системы. Для создания разграничений надо скорректировать настройки PAM модуля xapi таким образом, что бы ограничить круг лиц, допущенных до управления гипервизором. Возможностей для этого великое множество, в вашем распоряжении все стандартные средства PAM. Описание возможностей PAM и идеи для конфигурирования защиты XAPI вы можете подчерпнуть из “The Linux-PAM System Administrators Guide” от Andrew G.Mortan и Thorsten Kukuk.
Еще одной спецификой XAPI является наличие в системе возможности удаленного управления по HTTP/HTTPS. Демон держит открытыми 80 и 443 порты на административном интерфейсе. В рамках этой статьи мы не будем рассматривать многоинтерфейсные системы, там эта проблема стоит чуть менее остро, учитывая возможность физического отделения сети управления. Но хотелось бы отметить, что данная компоновка необходима для любого production-решения.
Довольно часто, административный интерфейс является и общим для передачи данных и каскадирования виртуальных машин. Таким образом, любое управление по 80-му порту без использования SSL тоннелей дает возможность злоумышленнику как минимум использовать сниффер и получить настройки системы, а как максимум провести успешную инъекцию кода или перехватить сессию управления. Как вариант решения, Iptables оптимален. В целом же, стоит ограничить трафик, поступающий на 80443 порты в системе. Достойно этот вопрос освещен в собственном документе компании Citrix Common Criteria Evaluated Configuration Guide for Citrix XenServer ® 5.6, Platinum Edition.
Для разъяснения следующего вызывающего вопросы места, погрузимся чуть глубже в моторику работы Citrix XenServer. Для удобства доступа к виртуальными машинам гипервизор использует передачу текстовыхграфических консолей гостевых систем на XAPI. Для этого используется небольшая программка vncterm. Идеология работы примерно следующая: При запросе консоли средствами XAPI создается форк процесса vncterm на loopback интерфейсе и передается на XAPI пользователю.
Так происходит с любыми хостами, включая сам хост гипервизора. За небольшим исключением. В случае подключения на хост гипервизора, вместо отправки на аутентификацию, выполняется авторский код компании Citrix, предоставляющий вам мгновенный доступ к локальной консоли под пользователем root.
Любой пользователь, имеющий доступ на XAPI на сервере без привязки к Active Directory сможет получить root доступ на хост гипервизора.
Как вторичную проблему vncterm отметим единую для всех сессию. То есть, создав сессию на гостевую систему под пользователем root и забыв произвести выход из гостевой системы, вы оставите открытый VNC канал. При следующем запросе к данной гостевой системе любой пользователь XAPI получит ту самую открытую сессию. Компрометация системы неизбежна. Отметим, что локальная аутентификация пользователя так же происходит автоматически на mingetty –autologin root с автоматической загрузкой xsconsole.
Это не является критичным, но теоретически возможна инъекция sh кода. Поэтому следует ограничить выдачу привилегий суперпользователя в системе.
Еще одним проблемным местом системы является трансфер виртуальных машин между серверами в режиме XenMotion. Он происходит через 80-й порт системы в plain-text режиме. Таким образом, злоумышленник имеет возможность перехвата данных «на лету». Решение этой проблемы только одно, — применения средств шифрования IP уровня. Но это не единственная проблема при передачи данных,- так же по умолчанию сервис iSCSI передает учетные данные в открытом виде. Данная проблема решается активацией CHAP.
Citrix XenServer использует несколько режимов хранения виртуальных машин: в виде LVM и в виде VHD файлов. Первый режим можно расценивать как условно-безопасный, так как права на монтирование директорий имеет только суперпользователь. А вот режим VHD представляет собой очередную проблему безопасности. Файл создается со стандартным umask из скриптов сервера: rw-r-r. Таким образом, виртуальная машина доступна любому пользователю системы. Эта проблема решается методом исправления скриптов, который будет описан в Positive Technologies Citrix XenServer 5.6 Security Guide.
Так как системы является потомком RHEL, то она унаследовала их систему менеджмента пакетов RPM вместе с надстройкой yum. Изначально в системе, при попытке тривиального “yum update” вы не получите обновлений систем. Хотя явственно ощущаете, что за красивой заставкой спрятался динозавр линуксостроения. Проблема заключается в том, что компания Citrix блокирует подключение к репозиториям CentOS на уровне конфигурации yum. Конечно, не является проблемой включить их обратно и выполнить обновление системы. Но данное действие приведет к досрочному упокоению гипервизора из-за того, что Citrix изменили некоторые стандартные вещи в системе на свои, «религиозно-верные», и теперь накатывание обновлений приводит к краху системы. Так как некоторые пакеты в системе определяются сканером безопасности как имеющие уязвимости уровня “critical” (dhclient к примеру), то установка обновлений становится обязательной. Для решения подобных проблем вам потребуется сканер безопасности, yum, dump и терпение.
Хотелось бы отметить, что из общих настроек системы «из коробки» присутствует важная промашка в настройках модуля pam_unix.so. Конкретнее, у него не включен режим хранения паролей в /etc/shadow.
Таким образом, учитывая стандартные права на файле /etc/passwd есть потенциальный доступ к хэшам паролей системы. Так же это и касается моторики работы системы с NFS хранилищами. Citrix XenServer Administration Guide рекомендует выставление на NFS сервере опции no_root_squash. Такое решение является стандартным для гипервизоров, и следует максимально изолировать такое хранилище от внешнего мира, используя средства iptables или подобные. Дополнительно, конечно, следует скорректировать режимы создания файлов и произвести ремаппинг root пользователя на специализированного пользователя системы.
Таким образом, подводя итог в целом, получается что продукт Citrix Free XenServer в исходной настройке имеет несколько возможных серьезных проблем безопасности «by design». Многие из них являются общими проблемами для RHEL семейства, другие же являются уникальными для данной системы. Конечно, с точки зрения Citrix, это не проблемы, а особенности архитектуры их гипервизора. Решение вопросов безопасности и общая методология защиты данной ОС будут представлены в документе Positive Technologies: Citrix XenServer Security Guide, который в ближайшем будущем выйдет в открытое бета-тестирование.
Автор: isox
