Руководство по созданию политик запрета WDAC

С помощью Защитник Windows управления приложениями (WDAC) можно создавать политики для явного запрета определенных драйверов и приложений. Чтобы создать действующие политики запрета управления приложениями Защитник Windows, следует понимать порядок применения приоритета правил WDAC при оценке файлов по активным политикам.

Автономная политика запрета

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

<FileRules>
  <Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
  <Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />
</FileRules>
<SigningScenarios>
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Kernel Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_1" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_2" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Добавление предыдущих правил "Разрешить все" не влияет на другие развернутые вами политики WDAC, которые применяют явный список разрешений. Для иллюстрации рассмотрим следующий пример:

Policy1 — это список разрешений для приложений, подписанных Windows и Майкрософт.

Policy2 — это новая политика запрета, которая блокирует MaliciousApp.exe, а также двоичные wmic.exe компонента Windows. Он также включает правила "Разрешить все".

  • MaliciousApp.exe блокируется, так как в политике Policy2 есть явное правило блокировки. Он также неявно блокируется политикой Policy1, так как отсутствуют разрешающие правила, охватывающие файл в этой политике.
  • Файл с подписью Windows wmic.exe заблокирован, так как в политике Policy2 есть явное правило блокировки.
  • Все остальные приложения, подписанные Windows и Майкрософт, разрешены, так как в политиках Policy1 и Policy2 есть явное правило разрешения, которое охватывает файл.
  • Все остальные приложения неявно запрещены. Например, ExampleApp.exe, не допускается, так как он является доверенным только политикой Policy2 (из-за правил Allow All), а не Policy1.

Рекомендации по политике смешанного разрешения и запрета

Если набор правил запрета должен быть добавлен в существующую политику, которая включает явные правила разрешения, не включайте предыдущие правила "Разрешить все". Вместо этого правила запрета следует объединить с существующей политикой WDAC с помощью мастера WDAC или с помощью следующей команды PowerShell:

$DenyPolicy = <path_to_deny_policy>
$ExistingPolicy = <path_to_existing_policy>
Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $ExistingPolicy

Рекомендации

  1. Сначала протестируйте в режиме аудита . Как и во всех новых политиках, мы рекомендуем развернуть новую политику запрета в режиме аудита и отслеживать события блокировки аудита 3076 , чтобы обеспечить блокировку только приложений, которые вы намеревались заблокировать. Дополнительные сведения о мониторинге событий блокировки с помощью журналов Просмотр событий и расширенной охоты: управление политиками управления приложениями Защитник Windows и устранение неполадок

  2. Рекомендуемые типы запрещенных правил . Правила подписывания и атрибутов файлов рекомендуются с точки зрения безопасности, управляемости и производительности. Хэш-правила следует использовать только при необходимости. Так как хэш файла меняется с любым изменением файла, трудно испевать за политикой блоков на основе хэша, когда злоумышленник может тривиально обновить файл. Хотя WDAC оптимизировал синтаксический анализ хэш-правил, некоторые устройства могут повлиять на производительность при оценке среды выполнения, если политики имеют десятки тысяч или более хэш-правил.

Руководство по созданию политики запрета

Запретить правила и политики можно создать с помощью командлетов PowerShell или мастера WDAC. Мы рекомендуем создавать правила подписывания (PCACertificate, Publisher и FilePublisher) везде, где это возможно. В случае неподписанных двоичных файлов необходимо создавать правила для атрибутов файла, таких как исходное имя файла или хэш.

Правило запрета на основе издателя программного обеспечения

$DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Fallback SignedVersion,Publisher,Hash -Deny

Правило запрета на основе атрибутов программного обеспечения

$DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Fallback Hash -Deny

Правило запрета на основе хэша

$DenyRules += New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny

Объединение правил запрета с политикой шаблонов AllowAll

После создания правил запрета их можно объединить с политикой шаблона AllowAll:

$DenyPolicy = <path_to_deny_policy_destination>
$AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml"
Merge-CIPolicy -PolicyPaths $AllowAllPolicy -OutputFilePath $DenyPolicy -Rules $DenyRules
Set-CiPolicyIdInfo -FilePath $DenyPolicy -PolicyName "My Deny Policy" -ResetPolicyID

Развертывание политики запрета

Теперь должна быть подготовлена политика запрета для развертывания. Сведения о развертывании политики в управляемых конечных точках см. в руководстве по развертыванию WDAC .