Настройка AppLocker

Когда в очередной раз, начинаются разговоры про информационную безопасность, начинаться они могу с host hardening.

Microsoft достаточно активно рекламировала AppLocker как простую и эффективную технологию.

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

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

Подробнее о подготовке  можете почитать в моей статье “Информационная безопасность“. В этой статье остановимся на технической стороне вопроса.

Предположим, в вашей компании 5 департаментов, три из которых используют один и тот же набор ПО.

Это значит что нужно создать три эталонных рабочих станции, на каждой из которых будет установлен определённый и согласованный набор ПО.

Политики AppLocker будут созданы на этих машинах и применены к рабочим станциям.

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

Кстати, AppLocker иногда предлагается в качестве решения по аудиту софта на предприятии, но я бы рекомендовал сторонние решения, которые гораздо функциональнее и могут генерировать удобоваримые отчёты.

Вообще, AppLocker является развитием Software Restriction Policy (SRP).

Но у SRP было несколько функций, которых, почему-то, уже нет в AppLocker, например:

• В AppLocker нельзя добавлять некоторые (свои) типы файлов;
• В AppLocker нельзя создавать правила для зон сети (использовалось все равно редко);
• В SRP использовались системные переменные окружения, у AppLocker они почему-то “свои”.

Зато в AppLocker удобные мастера создания/слияния/экспорта/импорта правил, поддержка PowerShell, а главное, возможность применения политики к определённой группе (хоть и к единственной).

C помощью AppLocker вы можете запретить запуск всего софта, разрешив только “белый список”, или разрешить запуск всего софта кроме внесённого в “чёрный список”.

Списки эти будем называть правилами AppLocker, а членство в них может быть изменено на основании трёх условий: Publisher, Path, Hash.

• Publisher (издатель) – может работать только при наличии цифровой подписи у приложения.

В “издателе” можно оперировать названием компании-разработчика, именем продукта, именем и версией исполняемого файла и т.п. – это будет понятнее на практике.

К сожалению, не весь софт имеет цифровую подпись, потому что это самый удобный вариант.

• Path (расположение) – очевидно что можно запретить запуск исполняемого кода в зависимости от его расположения.

Обратите внимание что переменные AppLocker отличаются от системных – https://technet.microsoft.com/en-us/library/dd759068.aspx

Если файл будет перенесён в другое расположение, правило перестанет отрабатывать.

• Hash (хэш файла) – на первый взгляд хороший вариант т.к. Позволяет однозначно идентифицировать приложение.

Но как только версия приложения изменится, правило на неё распространятся перестанет.

Это значит что при каждом изменении версии нужно вносить поправки в правила.

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

Для демо создадим политику AppLockerPolicy в которой будем задавать правила – Computer Configuration/Policies/Windows Settings/Security Settings/Application Control Policies/AppLocker

Имейте ввиду, на клиенте должна быть запущена служба Application Identity, и лучше если это будет включено централизованно, например в той же групповой политике:

Для созданной политики есть два основных режима – аудит, когда нам интересен лог, и форсирование, когда необходимо применение.

В демо, для наглядности, я буду использовать форсирование:

Обратите внимание, по-умолчанию отрабатывает что-то вроде “Deny All”, поэтому если вы не сделаете разрешающих правил после перезагрузки на клиенте будет вот такая ситуация (поможет вход под локальным администратором после исправления политики):

Поэтому первым делом можно включить Default rules:

Обратите внимание, толку от этих правил практически никакого, но мы пока, для проверки, создадим своё, запрещающее правило для WordPad на основе издателя:

Обратите внимание, я указал группу Everyone, хотя мог, например, Marketing;

Правило работает для издателя Microsoft, имя продукта Windows OS (WordPad входит в ОС);

Имя файла wordpad.exe – значит на остальное ПО в составе Windows правило распространятся не будет;

Правило будет работать версий 6.3 и старше (а могло, например, запрещать только старые версии);

Никаких исключений я не добавлял.

Я создал правило на основе Publisher, хотя мог на основе Path или Hash – все потому что на основе Publisher и удобнее, и функциональнее.

Убедимся что правило работает:

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

Выполним более сложный сценарий, в котором разрешим запуск только Adobe Reader старше 11й версии для группы Managers.

При этом весь остальной софт от Adobe будет запрещён к запуску.

Правило будет выглядеть вот так:

Убедимся что получен необходимый результат:

Мы рассмотрели реализацию сценария “чёрного списка”. Теперь рассмотрим сценарий “белого списка”.

Предположим, у нас есть эталонная машина с которой будем формировать правила.

Установим на эту машину соответствующий пакет RSAT и будем редактировать групповую политику App Locker, предварительно удалив из нее созданные мастером и нами правила.

Т.к. Перед нами стоит задача разрешить только то ПО, которое установлено на этой машине, правила вручную создавать не будем, а воспользуемся мастером Automatically Generate Rules.

По-умолчанию мастер будет анализировать содержимое C:\Program Files и создавать правила на основе Publisher, а если цифровой подписи нет, то на основе hash:

Но большинство софта по-прежнему находится в папке  C:\Program Files (x86), так что проанализируем и ее содержимое:

Обратите внимание, перед созданием правил, некоторые из предлагаемых можно удалить.

Также имейте ввиду что при повторном запуске мастер создаёт дубли, так что аккуратнее с этим.

Некоторое ПО может быть установлено без полномочий администратора в папку App Data:

.. Поэтому нелишним будет проанализировать папку %OSDRIVE%\Users:

В завершении статьи – большинство пользователей квадратными глазами будет смотреть на недоразумение которое Microsoft называет Metro приложениями.

Лучшее, что можно с ним это сделать это удалить, например так:

Но вы можете и оставить приложения, просто запретив их запуск с помощью AppLocker:

Таким образом, можно разрешить “полезные” Metro приложения и запретить все остальные:

Что касается Windows Installer и Script rules – на практике их применение встречается настолько редко, что описывать их сейчас смысла не вижу.

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.