Руководство по использованию AppLocker средствами PowerShell (Часть 2)

Управление AppLocker средствами PowerShell

AppLocker позволяет конкретизировать приложения, которые могут или не могут запускаться на машинах в сети организации. Как говорилось выше, инструменты управления AppLocker’а оптимизируются по направлению к созданию “белого списка” приложений, т.е. списка приложений, которые разрешается запускать. А те приложения, которые не включены в список блокируются системой.

Благодаря AppLocker в Windows 7, у администраторов появляется возможность контроля за приложениями пользователей. В добавление ко многим возможностям с политиками AppLocker, можно управлять при помощи усовершенствованной оснастки MMC, а также в сборке Windows 7 RC, появилась возможность администрирования AppLocker средствами командлетов Powershell.

Для управления AppLocker необходимо в открытой сессии Powershell воспользоваться следующим командлетом: Import-Module applocker.

Увеличить рисунок

На скриншоте выше видно пять командлетов, которые доступны на данный момент. Чтобы узнать подробную информация по использованию каждого из командлетов AppLocker, можно воспользоваться командлетом 'Get-Help'. Сейчас мы вкратце рассмотрим принцип работы каждого из вышеперечисленных командлетов:

Использование командлета Get-AppLockerFileInformation

Это самый основной командлет в семействе AppLocker. Он обеспечивает очень простую (но в то же время мощную) функциональность просмотра списка файлов, папок или журналов событий, и извлекает информацию, уместную для AppLocker, например для каждой выполнимой программы в папке. Может восстановить соответственного издателя, путь и информацию хэша, и т.п. Вот – пример:

Увеличить рисунок

Параметр “Recurse” говорит командлету проникнуть в каждую под-папку Office12, пока перечисление Filetype указывает, что находить нужно только исполняемые файлы (или скрипты, MSI-файлы, и т.п.). В примере, я воспользовался выводом out-gridview, чтобы обеспечить более легкую визуализацию восстановимой информации файла.

Рассмотрим все параметры данного командлета:

-Path <String[]>

Список путей к файлам, из которых выводится информация о файлах. Поддерживает регулярные выражения.

-Directory <String>

Указывает директорию, содержащую файлы, из которых необходимо вывести информацию о файлах. Чтобы найти все подпапки и файлы в директории, используется параметр Recurse

-FileType <AppLockerFileType[]>

Указывает настраиваемый тип файла для поиска. Типами файла являются: Exe, Script, WindowsInstaller, или Dll

Значения: Exe, Script, WindowsInstaller, Dll

-Recurse <Boolean>

Ищет все подпапки и файлы в директории, указанной параметром Directory.

-EventLog <Boolean>

Указывает, что информация возвращается из журнала событий

-LogPath <String>

Указывает, имя или путь к файлу журнала события, где размещены события AppLocker. Если этот параметр не указан, локальные Microsoft-Windows-AppLocker/EXE и каналы DLL используются по умолчанию.

Значение: Microsoft-Windows-AppLocker/EXE и DLL

-EventType <AppLockerEventType[]>

Фильтруются события AppLocker типом события. Выбором типа события являются: Allowed, Denied, или Audited. Типы события соответствуют событиям Информационному, Ошибке, и Предупреждениям, в AppLocker журнала событий

Значения: Allowed, Denied, Audited

-Statistics <Boolean>

Обеспечивает количество событий о файле, которые выводятся в списке в журнале событий после обращения опциональных фильтров

Использование командлета New-AppLockerPolicy

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

Увеличить рисунок

Выше в примере, использовался командлет New-AppLockerPolicy для того, чтобы создать политику для Office12, используя правила издателя для подписанных наборов из двух предметов и правила хэширования для любых неподписанных наборов. Параметр “-Optimize” обеспечивает интересную особенность: вместо того, чтобы создать одно правило для каждой исполняемой программы, этот параметр заставляет командлет найти специфические образцы и создать оптимальный набор правил. Для правил издателя это может приводить к меньшему набору правил. Для правил хэшированного файла - будет группировать многоразовые хэши к единственному правилу.

Чтобы сохранить созданную политику, мы присвоили вывод в XML-файл. Созданная политика может быть удобно загружена и применена, используя AppLocker оснастку MMC (доступна через secpol.msc или gpmc.msc).

Рассмотрим все параметры данного командлета:

-FileInformation <FileInformation[]>

Файл может содержать издателя, путь, и хэшированный файл. Некоторая информация, возможно, отсутствует, как, например, информация издателя для неподписанного файла.

-RuleType <RuleType[]>

Конкретизирует вид правил, чтобы создать политику из информационного файла. Издатель, путь, или хэшируемый файл могут быть созданы из информационного файла. Многоразовые типы правила, могут быть указаны таким образом, что если необходимая информация файла не доступна, то будут создаваться типы резервного правила. Например, вы можете конкретизировать -RuleType Publisher, Hash таким образом, что правила хэша будут применены, когда информация издателя не доступна. Publisher, Hash - значения по умолчанию.

Значения: Publisher, Hash

-RuleNamePrefix <String>

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

-User <String>

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

• DNS user name (domain\username);
• User Principal Name (username@domain.com);
• SAM user name (username);
• Security identifier (S-1-5-21-3165297888-301567370-576410423-1103).

-Optimize <Boolean>

Создает инструкции подобным правилам, которые группируются вместе.

-IgnoreMissingFileInformation <Boolean>

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

-XML <Boolean>

Указывает вывод из новой политики AppLocker как Xml-форматируемая строка

Использование командлета Test-AppLockerPolicy

Как оказалось, создавать правила AppLocker средствами PowerShell довольно таки просто. Теперь мы можем только проверить получится ли использовать Outlook.exe как только мы применим новую политику. Да, можем!

Увеличить рисунок

Командлет не только подтверждает, что Outlook.exe разрешен для запуска, а также говорит нам какое правило позволяет нам запускать Outlook.

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

Рассмотрим все параметры данного командлета:

-PolicyObject <AppLockerPolicy>

Указывает объект политики, который содержит политику AppLocker. Он может быть получен от Get-AppLockerPolicy или New-AppLockerPolicy.

-XMLPolicy <String>

Путь к XML-файлу, который содержит политику AppLocker

-Path <String[]>

Указывает список путей файла для тестирования. Поддерживает регулярные выражения.

-User <String>

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

• DNS user name (domain\username);
• User Principal Name (username@domain.com);
• SAM user name (username);
• Security identifier (S-1-5-21-3165297888-301567370-576410423-1103).

-Filter <PolicyDecision[]>

Фильтрует вывод политики для каждого входящего файла. Опции решения политики: Allowed, Denied, DeniedByDefault, и AllowedByDefault. По умолчанию, показаны все политики.

Значения: Allowed, Denied, DeniedByDefault, AllowedByDefault

Использование командлета Set-AppLockerPolicy

Вы можете использовать это командлет для того, чтобы установить политику AppLocker.

Увеличить рисунок

Сейчас попробуем скомбинировать все три предыдущих примера в к одну строку (вместо того, чтобы выполнять все вышеперечисленные шаги по отдельности).

Увеличить рисунок

В одной строке, мы собрали информацию файла для каждой выполнимой программы в Office12, создали политику AppLocker и установили ее в локальный GPO (точно так же легко установить эту политику к существующему domain GPO, используя его ldap путь).

Рассмотрим все параметры данного командлета:

-XMLPolicy <String>

Указывает путь к XML-файлу, где сохранена политика AppLocker

-PolicyObject <AppLockerPolicy>

Указывает объект AppLockerPolicy, который содержит политику AppLocker. Может быть получено из Get-AppLockerPolicy и New-AppLockerPolicy.

-LDAP <String>

Указывает из GPO путь LDAP. Указывает уникальный GPO. Если этот параметр не указан, устанавливается местная политика AppLocker.

-Merge <Boolean>

Когда используется параметр Merge, правила в указанной политике AppLocker будут поглощены с правилами AppLocker в целевом GPO в пути LDAP. Слияние политик переместит правила с копией IDS, и осуществит, установив и сохранив указанную политику AppLocker в целевом GPO. Если параметр Merge не указан, то новая политика перепишет существующую.

-Confirm [<SwitchParameter>]

Запрашивает подтверждение перед выполнением команды.

-WhatIf [<SwitchParameter>]

Описывает, что случилось бы, если выполнить команду

Статья опубликована в рамках конкурса "Наш выбор - Windows 7!". Оригинальный стиль автора сохранен.