Защита виртуальных машин, размещенных в дата центре


    В век облачных технологий, когда у каждого пользователя есть собственное облако для хранения фотографий, а компании арендуют сервера для облачных вычислений, встает вопрос о конфиденциальности хранимой информации. И если пользователи для защиты хранимых данных могут обойтись доверием к облаку или использованием крипто контейнеров, то у компаний дела обстоят хуже. Так как в облака переносится не только хранилище данных, но и сами вычисления.
    Особенно страдает защита виртуальных машин, так как в случае компрометации хоста, не составит труда получить доступ к ВМ. До недавнего времени ни один из гипервизоров будь то VMware, Xen, Hyper-V не предоставляли каких-либо значимых технологий по защите ВМ.

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

    С релизом Windows Server 2016, в Microsoft решили уделить больше внимания безопасности хоста и виртуальной инфраструктуры. Появилась возможность изолировать ВМ от администратора хоста Hyper-V. А используя виртуальный TPM стало возможным шифрование данных ВМ с помощью bitlocker.

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

    Используемые технологии


    Shielded VM – технология изолирующая виртуальную машину от хоста. Защищает ВМ от случайных или преднамеренных действий администратора хоста и от вредоносного программного обеспечения.
    Для работы Shielded VM необходимо наличие сервера Host Guardian Service(HGS), который выдает ключи доступа к ВМ и проверяет здоровье хоста Hyper-V.

    HGS поддерживает два вида аттестации:

    1. TPM-trusted аттестация – проверка проходит на основе идентификатора TPM, последовательности загрузки ОС и политики целостности кода. Таким образом можно быть уверенным, что на хосте работает только одобренный код.
    2. Admin-trusted аттестация – проверка происходит на основе принадлежности к группе безопасности Active Directory.

    Схема работы HGS

    При запуске виртуальной машины защищённый хост проходит аттестацию у HGS сервера, который принимает решение о передачи ключей доступа к виртуальной машине.

    Admin-trusted аттестацию целесообразно использовать внутри предприятия, когда нужно изолировать доступ к ВМ от администраторов.

    TPM-trusted аттестацию лучше использовать при размещении ВМ на арендованном сервере, чтобы обеспечить изоляцию данных и ВМ от работников Дата Центра.

    Связь сервера HGS и защищённого хоста осуществляется по http (https) протоколу. HTTPS не требуется, для обеспечения безопасной связи, но, если вы захотите включить HTTPS, вам потребуется дополнительный сертификат. В случае AD аттестации необходимо дополнительно настроить односторонний доменный траст.

    Virtual Secure Mode (VSM) – технология работающая на основе виртуализации, которая позволяет изолировать критические для безопасности операции в мини ОС.

    На VSM работают две другие технологии:

    1. Device Guard – проверка данных UEFI прошивки и драйверов режима ядра (контроль целостности кода).
    2. Credential Guard – изоляция процесса аутентификации пользователей (LSA).

    Принцип работы VSM


    Основная ОС запускается в виртуальном окружении. А гипервизор выступает в роли хостовой ОС, тем самым ограничивая доступ к оперативной памяти. В итоге вредоносное ПО запущенное на хосте даже с администраторскими правами не сможет получить доступ к памяти VSM. Также такая структура должна защищать от атаки на DMA порты.

    Об организации Shielded VM


    Заказывая Shielded VM подразумевается, что хост Hyper-V и сервер HGS находятся на стороне дата центра (так организованно в Microsoft Azure). В таком случае создавать экранированную виртуальную машину можно самостоятельно или используя предоставленный шаблон.

    Создавая Shielded VM самостоятельно заказчик у себя на ПК разворачивает и настраивает ВМ, а потом шифрует ключом выданным Дата Центром. После переносит ВМ в Дата Центр.

    Во втором случае, заказчик создает только PDK файл, защищающий ВМ созданную из шаблона. PDK файл связывает файл шаблона с HGS сервером. Но необходимо убедиться, что в шаблоне нет вредоносного ПО.

    Первый способ выглядит более безопасным, так как файл данных ВМ попадает на хост в уже шифрованном виде. В любом случае ключи доступа к ВМ не попадают к администраторам Дата Центра в открытом виде.

    Единственным местом подверженным атакам остался HGS сервер. Так как:

    • Администратор HGS может понизить требования к политике безопасности.
    • Злоумышленник получивший администраторские права может попробовать получить ключи доступа.
    • Для работы HGS требуется AD и нет требования к обязательному наличию TPM, следовательно, ключи вероятней всего будут храниться в открытом виде.

    Исходя из этого появилась, идея проверить возможность работы Shielded VM в условиях, когда сервер HGS размещается в своей инфраструктуре. Это еще больше обезопасит виртуальные машины. Также такой способ можно использовать если Дата Центр не предоставляет услугу Shielded VM. Минус этого подхода в том, что придётся самостоятельно администрировать эту структуру.

    Может возникнуть вопрос о подмене сервера HGS администратором гипервизора — ведь для этого необходимо просто указать новый адрес. Защита от этого реализована достаточно просто, созданная ВМ зашифрована с использованием открытого ключа HGS сервера, поэтому другой HGS сервер не сможет выдать ключи для ее запуска.

    Также стоит понимать, что технология Shielded VM шифрует только конфигурационные файлы виртуальной машины. VHDX файл остаётся незашифрованным. Для его шифрования нужно включить vTPM, и зашифровать диск битлокером.

    Сочетание новых технологий предоставляет надежную защиту:

    • человеческий фактор устранен;
    • ключи передаются в зашифрованном виде;
    • серверы защищены новыми технологиями, предусматривающими проверку целостности кода;
    • белый список разрешенных приложений;
    • изоляция ВМ от хоста.

    Это все очень хорошо защищает от вредоносного ПО нацеленного на хост Hyper-V и предоставляет доступ к ВМ только владельцу, защищая от действий администраторов или кого-либо получившего администраторские права.

    Требования к серверам Hyper-V и HGS

    Требования указаны для использования TPM аттестации. AD аттестация менее требовательна, но при этом обеспечивает гораздо меньшую защиту.

    HGS:
    • Windows Server 2016

    Hyper-V:
    • Windows Server 2016 Datacenter Edition
    • UEFI Secure Boot
    • TPM v2
    • IOMMU (VT-d)

    Как настроить


    Для примера будет рассмотрен вариант: вы арендовали выделенный сервер и хотите его обезопасить. Будет использована TPM аттестация. Соединение между хостом и HGS будет проходить по http протоколу. Если HGS сервер не имеет белого IP необходимо будет пробросить 80 порт или использовать реверс прокси.

    Добавление и настройка HGS роли на сервере


    Установка HGS сервера и создание домена

    Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart

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

    $adminPassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
    
    Install-HgsServer -HgsDomainName 'relecloud.com' -SafeModeAdministratorPassword $adminPassword -Restart



    Создание самоподписаных сертификатов

    Для теста были созданы самоподписанные сертификаты, но для реальной среды лучше использовать PKI.

    $certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
    
    $signingCert = New-SelfSignedCertificate -DnsName "signing.relecloud.com"
    
    Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath 'C:\signingCert.pfx'
    
    $encryptionCert = New-SelfSignedCertificate -DnsName "encryption.relecloud.com"
    
    Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath 'C:\encryptionCert.pfx'



    Инициализация HGS сервера

    Указываем сертификаты шифрования и подписи. Выбираем метод аттестации.

    $certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
    
    Initialize-HgsServer -HgsServiceName '<HgsServiceName>' -SigningCertificatePath 'C:\signingCert.pfx' -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath 'C:\encryptionCert.pfx' -EncryptionCertificatePassword $certificatePassword [-TrustActiveDirectory | -TrustTPM]




    Добавление охраняемого хоста Hyper-V


    Получаем идентификатор TPM

    Данную процедуру необходимо выполнить для каждого защищаемого хоста.

    (Get-PlatformIdentifier -Name '<HostName>').InnerXml | Out-file <Path><HostName>.xml -Encoding UTF8


    Добавляем полученный файл на сервер HGS

    Add-HgsAttestationTpmHost -Path <Path><Filename>.xml -Name <HostName> -Force



    Создаем и применяем Code Integrity Policy

    При создании политики происходит сканирование всех установленных программ и добавление их в белый список. Перед созданием политики необходимо убедится, что в системе:

    • Отсутствуют вирусы и вредоносное ПО
    • Установлено необходимое для работы ПО и оно является благонадежным

    Рекомендуется сначала проверить работу политики в режиме аудита. В таком случае исполняемый файл, запрещенный политикой будет отображен в логе.

    Сканирование займет некоторое время.

    New-CIPolicy -Level FilePublisher -Fallback Hash -FilePath 'C:\temp\HW1CodeIntegrity.xml' -UserPEs
    
    ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity.p7b'



    Файл .p7b необходимо переименовать в SIPolicy.p7b и скопировать в папку C:\Windows\System32\CodeIntegrity\SIPolicy.p7b

    Перезагружаем компьютер и проверяем работу системы под планируемой типичной нагрузкой. После успешной проверки работы системы отключаем режим аудита

    Set-RuleOption -FilePath 'C:\temp\HW1CodeIntegrity.xml' -Option 3 -Delete
    
    ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity_enforced.p7b'
    
    Copy-Item -Path '<Path to HW1CodeIntegrity\_enforced.p7b>' -Destination 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
    
    Restart-Computer

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

    Рекомендуется оставить исходный XML файл, чтобы в случае необходимости изменения политики не проводить повторное сканирование.

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

    Регистрируем политику на HGS сервере

     Add-HgsAttestationCIPolicy -Path <Path> -Name '<PolicyName>'



    Создание TPM baseline политики

    Эта политика основывается на PCR регистрах (Platform Configuration Registers), находящихся в модуле TPM. В них хранятся целостности метрик системы, начиная с загрузки BIOS до завершения работы системы. Если порядок загрузки будет изменен, например, руткитом, это отобразиться в регистрах PCR.

    Политика создается для класса одинаковых аппаратных хостов. Перед ее созданием необходимо иметь установленный Hyper-V.

    Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart
    
    Get-HgsAttestationBaselinePolicy -Path 'HWConfig1.tcglog'

    Для данной команды необходимо включить Secure Boot, IOMMU (VT-d), Virtualization Based Security.

    Можно использовать флаг -SkipValidation который позволить выполниться команде, но он не исправит ошибки.



    Добавляем TCGlog файл на HGS сервере

    Add-HgsAttestationTpmPolicy -Path <Filename>.tcglog -Name '<PolicyName>'



    Проверяем статус HGS сервера


    На этом моменте настройка HGS сервера заканчивается. Для проверки выполненной работы проведем диагностику.

    Get-HgsTrace -RunDiagnostics




    Подключаем хост Hyper-V к HGS серверу


    Для подключения защищаемого хоста к серверу HGS достаточно указать URL адрес сервера.

    Set-HgsClientConfiguration -AttestationServerUrl 'http://<FQDN>/Attestation' -KeyProtectionServerUrl 'http://<FQDN>/KeyProtection'



    При правильной настройке должно быть:

    • IsHostGuarded: true
    • AttestationStatus: passed

    Если что-то настроено не верно в AttestationStatus будет указана причина.

    Создание экранированной виртуальной машины


    Получаем файл описания HGS сервера, который понадобиться для привязки ВМ к серверу.

    Invoke-WebRequest http://<"HGSServer">FQDN>/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:\HGSGuardian.xml


    Создавать ВМ нужно на отдельной машине под управлением Windows Server 2016, не настроенной на использование HGS.

    Создаем новую ВМ второго поколения, устанавливаем на нее ОС, настраиваем RDP и проверяем его работоспособность, шифруем битлокером.



    Экранирование ВМ

    Задаем название ВМ

    $VMName = 'SVM'

    Выключаем ВМ

    Stop-VM –VMName $VMName

    Создаем сертификат владельца

    $Owner = New-HgsGuardian –Name 'Owner' –GenerateCertificates

    Импортируем сертификат сервера

    $Guardian = Import-HgsGuardian -Path 'C:\HGSGuardian.xml' -Name 'TestFabric' –AllowUntrustedRoot

    Создаем Key Protector

    $KP = New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot

    Включаем экранирование
    Set-VMKeyProtector –VMName $VMName –KeyProtector $KP.RawData
    
    Set-VMSecurityPolicy -VMName $VMName -Shielded $true

    Включаем vTPM в виртуальной машине

    Enable-VMTPM -VMName $VMName


    После настройки и включения защиты в ВМ ее необходимо переместить на охраняемый хост. Для этого экспортируем машину, переносим полученные файлы на хост, и импортируем ее в консоль Hyper-V.

    На этом этапе настройка завершена, ВМ экранирована.

    Проверяем работу Shielded VM

    При попытке подключится к ВМ через консоль Hyper-V увидим сообщение:


    Так же в настройках ВМ увидим предупреждение о невозможности менять настройки защиты:


    Раздел виртуальной машины защищен BitLocker-ом:


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

    Больше статей на Servilon
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 22
    • +1
      Что произойдет, если недоступен HGS сервер?
      • 0
        Если это происходит при попытке запуска экранированной ВМ, она не запуститься, так как не кому будет выдать ключи.
        • 0
          А с кластерами работает? будет ли проходить миграция виртуалок между хостами?
          • 0
            Работает, все хосты кластера должны быть аттестованы HGS сервером. Миграция работать будет, при этом трафик будет шифроваться.
        • +1
          Типичная хрень от Microsoft. Навроде «кластера» с единой точкой отказа.
          Что мешает сделать снапшот VM и покопаться в дампе памяти для поиска ключей? Благо инструментарий для этого есть.
          • +2
            VSM не позволит это сделать, так как хостовая ОС сама запускается в виртуальном окружении.
            • +1
              Что мешает сделать снапшот виртуальной хостовой ОС и ковыряться во всем что под ней запущено?
          • +1
            пару дней назад на хабре было большое обсуждение как быстро уничтожить SSD может правильный метод чем шифрование т.к. при физическом доступе к компьютеру шифрованный диск подвержен атаке Cold boot attack https://ru.wikipedia.org/wiki/Cold_boot_attack

            • –2
              возможность шифрования виртуалок битлокером нормально работает и в 2012r2,
              • +2
                К сожалению, Virtual Secure Mode aka VSM это решето: его безопасность во многом определяется защищенностью platform firmware, а с этим сейчас все очень и очень плохо. Даже Intel и AMI пока что не умеют чинить уязвимости в своих прошивках которые приводят к обходу VSM, я детально писал об этом (с пруфами, анализом патчей и прочим) в последней части своей последней на момент конца 2016-го года статьи.
                PS: да, MS в курсе этого безобразия, но сделать с ним что-то что бы VSM стал крутым и безопасным они не могут — platform firmware попросту не их область ответственности.
                • +1
                  https://www.bromium.com/sites/default/files/us-16-wojtczuk-analysis-of-the-attack-surface-of-windows-10-virtualization-based-security-wp-v2.pdf — неплохой документ про анализ векторов атак на Virtualization Based Security в Windows.

                  http://blog.cr4.sh/2016/10/exploiting-ami-aptio-firmware.html — статья с описанием моей уязвимости INTEL-SA-00057 которая помимо всего прочего приводит к обходу VSM на материнских платах от Intel. В переписке Intel подтвердили, что исправлять это в полной мере они не планируют: им важно что бы через этот баг secure boot и flash write protection не ломали, а до обхода VSM им дела нет.
                  • +1
                    https://github.com/Cr4sh/fwexpl — вот кстати еще более старый проектик который позволяет обходить VSM через уязвимости в прошивке компьютеров от Lenovo. Он умеет выводить информацию о виртуаизированных домейнах Hyper-V а так же предоставляет API для чтения-записи физической памяти через System Management Mode. Таким образом, атакующий который работает в рут партиции Hyper-V может сдампить все содержимое памяти с защищенных виртуальных машин в обход VSM.
                    • +2
                      Не получится эксплуатировать этe уязвимость так как потребуется перезагрузка хоста или запуск приложения, чему будет препятствовать политика HGS. В случае ее нарушения ВМ не запуститься, так как не получит сеансовый ключ, который выдает HGS
                      • 0
                        > чему будет препятствовать политика HGS

                        В теории — да, но на практике:
                        1) Эта штука упирается в Device Guard User Mode Code Integrity для которого только за последний год была целая пачка различных техник обхода;
                        2) Атакующий может использовать full ROP пейлод (см. Weird Machine и Return Oriented Programming) который проэксплуатирует уязвимость в platform firmware и запустит произвольный код в System Management Mode не используя никаких приложений (техника ROP подразумевает, что пейлод исполняющийся на скомпрометированном хосте будет составлен из уже имеющихся в памяти участков легитимного исполняемого кода переход вектора исполнения между которыми осуществляется за счет контроля над данными).
                        • 0
                          Вот немного ссылок по обходу политик Device Guard и UMCI, HGS исполнение такого кода просто не «увидит»:
                          http://www.cvedetails.com/cve/CVE-2016-0188/
                          http://www.exploit-monday.com/2016/11/Effectiveness-of-Device-Guard-UMCI.html
                          http://www.exploit-monday.com/2016/08/windbg-cdb-shellcode-runner.html
                          https://enigma0x3.net/2016/11/21/bypassing-application-whitelisting-by-using-rcsi-exe/
                          https://enigma0x3.net/2016/11/17/bypassing-application-whitelisting-by-using-dnx-exe/
                          http://subt0x10.blogspot.ru/2016/09/bypassing-application-whitelisting.html
                          • 0
                            … кроме этого:
                            * Есть JiT компиляторы типа .NET и JVM которым исполнение произвольного кода в памяти является необходимым бай дизайн, это можно использовать для обхода code integrity.
                            * В дефолтной поставке Windows есть огромное количество whitelisted приложений с валидной цифровой подписью от Microsoft которые позволяют творить всякое зло (данная тема неплохо раскрыта по ссылкам выше).
                            • 0
                              а если сервер core режиме без установленного .Net и JVM?
                              • 0
                                Там дотнет в дефолтной поставке: https://msdn.microsoft.com/en-us/library/ee391632(v=vs.85).aspx
                                • 0
                                  .
                                • 0
                                  Все это слишком сложно. Надо:
                                  1. Найти хостинг, где стоят машины.
                                  2. Подкупить сотрудника хостера или внедрить туда своего.
                                  3. Взломать хостовую операционку (не сложно).
                                  4. Попытаться поставить на работающий гипервизор программы для сбора дампов, так что бы клиент этого не заметил.
                                  5. В случае, если эти уязвимости работают и не пропаченны 2 дня назад, скопировать дамп памяти.
                                  6. Расшифровать дамп памяти, получить ключ.
                                  7. Еще раз зайти на хост остановит гипервизор и взять VHD.
                            • 0
                              на выделенном сервере (например хетцнер) такое можно реализовать?
                              • +1
                                ДА, если сервер поддерживает TPM. Проверьте:
                                PS C:\> Get-Tpm
                                TpmPresent : True

                                И разместите HGS на другом хосте, лучше в альтернативном датацентре, например, в небольшая ВМ в Azure

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.