Среди многочисленных преимуществ виртуализации серверов — экономия оборудования, сокращение затрат на электропитание и охлаждение, а также более простое управление. Каждому опытному ИТ-специалисту приходилось иметь дело с компьютером, зараженным шпионскими программами, вирусом, а иногда и компонентами rootkit. Если заражен физический компьютер, можно, в крайнем случае, выключить его или отсоединить от сети, чтобы предотвратить распространение заражения. Но что делать, если пораженный компьютер представляет собой виртуальную машину? Или хуже того, если заражен сервер VMware ESX?
Если поражен сервер, взломщик может создать новые ложные виртуальные машины или предпринять атаку типа hyperstack или hyperjack. Атака hyperstack похожа на атаку man-in-the-middle, в ходе которой первоначальный гипервизор заменяется ложным, но подмена не заметна для истинного гипервизора и аппаратных средств. Затем ложный гипервизор управляет всем взаимодействием между гипервизором и виртуальными машинами. Атака hyperjack заключается в поражении гипервизора, подобно внедрению компонентов rootkit на физический компьютер. Уже известны случаи атак против гипервизора, и проведение широкомасштабной атаки на ESX — вопрос времени.
Если гипервизор поражен, определить источник атаки очень трудно, так как машина виртуальная. Проблема еще более усугубляется, если гипервизор является частью кластера. Ложная виртуальная машина может перемещаться с одного сервера на другой и, возможно, даже реплицироваться на удаленный сайт с использованием механизма репликации SAN. Если заражен сервер в кластере, вероятно, придется отключить весь кластер виртуализации и выполнить чистку.
Надеюсь, приведенных аргументов достаточно, чтобы показать, насколько важна безопасность виртуализации. .
Защищенная сеть управления
Самый важный шаг к безопасности серверов ESX — организовать защищенную сеть управления для серверов, как показано на рисунке. Эта специализированная сеть управления защищена от других внутренних сетей. На рисунке единственный способ управлять сервером ESX — получить доступ к компьютеру Virtual Host Management. Обычно на этом компьютере выполняется VMware vCenter Server.
Рисунок. Сеть ESX с выделенной сетью управления |
Для доступа к сети управления сетевой администратор должен пройти проверку подлинности в SSL VPN, настроенной на двухфакторную проверку. После проверки подлинности в Active Directory (AD) сетевой администратор получает одноразовый пароль one-time password (OTP) в текстовом сообщении на сотовый телефон. Если сетевой администратор получает OTP, но не обращается к устройству SSL VPN, значит, его имя пользователя и пароль AD украдены. После проверки в SSL VPN сетевой администратор получает ссылку, чтобы использовать RDP для доступа к серверу vCenter.
Формируется правило брандмауэра, чтобы обеспечить прохождение трафика SSL (TCP-порт 443) из сети виртуального сервера в специализированную сеть управления. Чтобы еще более укрепить безопасность, можно сделать правило брандмауэра более строгим, разрешив доступ к устройству SSL VPN в защищенной сети только с определенных IP-адресов. Обычно мы разрешаем прохождение всего трафика из выделенной сети управления в сеть виртуального сервера. В случае атаки эта специализированная сеть должна обеспечить дополнительное время, чтобы изолировать сеть, прежде чем будет украдена какая-либо информация.
Этот подход направлен на защиту сервера любой ценой. Такая стратегия довольно необычна для устройств VPN, но приемлема для компаний с несколькими администраторами ESX. Если принято решение отказаться от использования SSL VPN, все же настоятельно рекомендуется использовать специализированную сеть управления и открыть в брандмауэре TCP-порт 3389 (то есть Terminal Server), чтобы сетевые администраторы могли обращаться к серверу vCenter.
Концепция выделенной сети управления согласуется с современной моделью безопасности под названием «создание бункеров» (siloing). Сеть разделяется на логические подсети, чтобы пользователи не могли получить доступ к компьютерам, которые им не нужны. Я предпочитаю использовать для реализации метода siloing брандмауэр, а не коммутатор или маршрутизатор. При организации выделенной сети управления необходимо учитывать следующие факторы.
- Платы HP Integrated Lights-Out (iLO)/Dell Remote Access Controller (DRAC). С помощью этих плат сетевой администратор может получить удаленный доступ к консоли на сервер ESX даже когда он отключен. Однако они должны быть подключены к выделенной сети управления, а не общедоступной сети, чтобы «оставить открытой заднюю дверь» для доступа к серверу.
- Управление коммутатором. Он должен быть доступен только из сети управления.
- Управление брандмауэром. Он должен быть доступен только из выделенной сети управления.
- Управление бесперебойным источником питания. Если используется бесперебойный источник питания с сетевой платой управления, эта плата должна быть подключена к сети управления; в противном случае взломщик может запустить атаку с отказом в обслуживании (DoS) против всех виртуальных машин, обратившись к плате управления источником питания и имитируя отказ в электроснабжении.
Для ESX или ESXi можно организовать управление через особую сетевую плату на сервере ESX. В vSphere Client, на сервере ESXi, перейдите на вкладку Configuration и щелкните Networking. Выберите режим Add Networking, VMkernel, Use this port group for management traffic. Затем назначьте серверу статический IP-адрес. На экране 1 показан пример выделенной сети управления для ESX.
Экран 1. Сервер ESX с выделенной сетью управления |
В данном примере выделенная сеть управления ESX создана с IP-адресом 192.168.x.x сервера ESX. Как можно увидеть, все остальные виртуальные машины изолированы в отдельной сети с именем VM Network. Две виртуальные машины, подключенные к этой сети управления, работают с vCenter. Все другие виртуальные машины на сервере ESX подключены к отдельной сети виртуальных машин.
Другой важный шаг к надежно защищенной виртуальной среде — установить на серверах достаточное количество сетевых плат. vMotion (ESX) обеспечивает перемещение активной виртуальной машины с одного сервера на другой. Изоляция трафика, особенно трафика vMotion — проблема как безопасности, так и производительности. Следует организовать выделенную сеть управления для vMotion, поскольку при каждом перемещении виртуальной машины с одного сервера на другой трафик передается в виде простого текста (в том числе все объекты, находящиеся в это время в оперативной памяти), что создает серьезную угрозу безопасности.
Для автономных серверов необходимо три сетевых платы, как показано в таблице 1. Для кластеризованных серверов требуется семь сетевых плат, как показано в таблице 2.
Таблица 1. Три сетевых платы на автономном сервере |
Таблица 2. Семь сетевых плат на сервере в кластере |
Планировщик распределенных ресурсов VMware Distributed Resource Scheduler (DRS) автоматически балансирует нагрузку между серверами ESX. Следует подготовить пул ресурсов из двух или нескольких серверов ESX, а затем запустить виртуальные машины на этом пуле ресурсов. Когда сервер оказывается перегруженным, виртуальные машины автоматически переносятся на другие, менее загруженные серверы ESX в пуле ресурсов. Функция VMware Distributed Power Management (DPM) автоматически консолидирует виртуальные машины на меньшем числе серверов ESX, когда нагрузка невелика. Неиспользуемые серверы ESX автоматически отключаются. Если нагрузка увеличивается, запускаются дополнительные серверы ESX, и на них переносятся виртуальные машины. Особенно важно создать изолированную сеть для переносов vMotion в кластерах с включенными DRS и DPM, поскольку предсказать время переноса vMotion невозможно. Дополнительное преимущество сети vMotion — повышение скорости миграции vMotion благодаря снижению конкуренции в сети.
Рекомендации по усилению безопасности ESX
Организация выделенной сети управления — лишь первый шаг к надежно защищенной виртуальной инфраструктуре. Рассмотрим ряд способов укрепления безопасности серверов ESX.
Как сообщили представители компании VMware, vSphere 4.1 станет последней версией, содержащей как версию ESX, так и ESXi гипервизора vSphere. Во всех выпусках vSphere Hypervisor будет присутствовать только ESXi. Основная причина изменения — безопасность. В отличие от ESX, в ESXi нет консоли Service Console и сервера Web Server, поэтому поверхность атаки значительно меньше. Рекомендую безотлагательно перейти на ESXi, поскольку сделать это все равно придется после выхода следующей версии vSphere. Необходимо изучить интерфейс командной строки (CLI) на ESXi, который придет на смену консоли Service Console в ESX. Перед переходом убедитесь, что у сторонних приложений и программ, выполняемых в Service Console, есть версии, совместимые с ESXi.
Если возможности перейти на ESXi пока нет (судя по моему опыту, примерно половина всех компаний пока не рассталась с ESX), при обращении к консоли ESX обязательно соблюдайте следующие правила.
- Отключите удаленный привилегированный доступ (remote root access). Такой доступ запрещен по умолчанию, но многие администраторы включают его после установки ESX. Вместо привилегированного доступа создайте дополнительную учетную запись с административными правами для управления из консоли ESX.
- Задействуйте sudo. При регистрации в консоли ESX, используйте sudo вместо удаленного привилегированного доступа или su. При использовании sudo все команды консоли записываются в \var\log\secure. Если войти как root или использовать su, записываются не все команды консоли. Чтобы исключить такую возможность, рекомендуется удалить или отключить su.
- Используйте профили серверов. Профили серверов есть в VMware vSphere Enterprise Plus. Когда сервер ESX будет укреплен, можно применять серверные профили для клонирования конфигурации сервера ESX, определить несоответствующие серверы ESX и автоматически устранить недостатки. Благодаря серверным профилям можно унифицировать конфигурацию всех серверов ESX в виртуальной инфраструктуре.
- Настройте брандмауэр ESX. Убедитесь, что в нем открыты только нужные порты. С помощью команды esxcfg-firewall -q просмотрите текущие настройки брандмауэра. В таблице 3 показан список портов ESX и их назначение.
Таблица 3. Порты ESX и их назначение |
Используйте модуль расширения vCenter Update Manager для управления обновлением программы. Рекомендую задействовать vCenter для управления серверами ESX. Даже вместе с VMware vSphere Essentials предоставляется лицензия VMware vCenter Server for Essentials, так что говорить о чрезмерно высокой цене vCenter не приходится. vCenter Update Manager автоматизирует устранение пробелов в программном обеспечении всех серверов ESX и виртуальных машин, работающих на серверах. vCenter следует запускать на физическом сервере. Применить программное обновление к серверу ESX не удастся, если сервер vCenter будет виртуальной машиной вне кластера, поскольку, прежде чем обновлять сервер, необходимо закрыть все виртуальные машины на нем. С помощью vCenter администратор ESX может детально настраивать привилегии, управляя сервером ESX и кластером.
Приобретите коммерческие сертификаты SSL для серверов ESX. По умолчанию для ESX и ESXi применяются самозаверяющие сертификаты. Такие сертификаты уязвимы для атак типа man-in-the-middle и должны быть заменены коммерческими сертификатами SSL.
Выполните резервное копирование образа виртуальных машин. Эта предосторожность связана с безопасностью не напрямую, но поможет восстановиться в случае нападения. Рекомендуется регулярно выполнять резервное копирование образа *.vmdk виртуальных машин. Благодаря этой мере существенно упрощается и ускоряется процесс восстановления виртуальной машины, особенно если она работает с Microsoft Exchange Server, SQL Server или SharePoint Server.
Используйте модуль Trusted Platform Module (TPM) на серверах ESX. Микросхемы TPM первоначально применялись в ноутбуках, чтобы воспрепятствовать загрузке ложной операционной системы и зашифровать жесткий диск. Сегодня микросхемы TPM стали одним из дополнительных компонентов на серверах нового поколения. Связав версию ESX с микросхемой TPM, можно обеспечить дополнительную защиту от атак hyperstack и hyperjack.
Для версий ESX и ESXi 4.1 необходимо применить программное исправление, устраняющее проблему проверки подлинности/усечения пароля пользователя root. В ESX и ESXi 4.1 выполняется проверка только первых восьми символов пароля пользователя root. Оставшаяся часть пароля отбрасывается, независимо от его длины. Дополнительные сведения об этой проблеме можно найти в статье «ESX 4.1 and ESXi 4.1 root passwords are authenticated up to only 8 characters» по адресу kb.vmware.com/kb/1024500 в базе знаний VMware.
Не используйте временные диски. Убедитесь, что ни в одной из виртуальных машин нет временных дисков. Если в виртуальной машине используются временные диски, то после ее отключения уничтожаются все изменения, сделанные на диске. Это очень удобный способ заметать следы для взломщиков. Одно из немногих полезных применений временных дисков — в лаборатории, где после отключения отменяются все изменения виртуальной машины. Этот параметр можно изменить только при отключенной виртуальной машине. Чтобы выяснить, используются ли в виртуальной машине временные диски, запустите vSphere, щелкните на имени виртуальной машины правой кнопкой мыши и выберите пункт Properties. Выберите жесткий диск и посмотрите на режим жесткого диска виртуальной машины. Флажок Independent должен быть снят. На экране 2 показана виртуальная машина с временным диском.
Экран 2. Виртуальная машина с временным диском |
Планомерная борьба с угрозой
Данная статья не содержит исчерпывающего набора инструкций по повышению надежности виртуальной инфраструктуры: на эту тему можно написать целую книгу. Однако приведенные советы послужат подспорьем для защиты виртуальной среды VMware. На внедрение этих мер может уйти немало сил, но все же гораздо меньше, чем на очистку зараженной виртуальной инфраструктуры. Дополнительную информацию о безопасности виртуальной среды можно найти в руководстве «vSphere 4.1 Hardening Guide» на сайте сообщества .vmware.com/docs/DOC-15413.
Алан Сугано (asugano@adscon.com) — президент компании ADS Consulting Group, специализирующейся на разработках в области Microsoft.NET, SQL Server и сетевых технологиях