Когда в очередной раз, начинаются разговоры про информационную безопасность, начинаться они могу с 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 приложениями.
Лучшее, что можно с ним это сделать это удалить, например так:
1 |
Get-AppxPackage -AllUsers | Remove-AppxPackage |
Но вы можете и оставить приложения, просто запретив их запуск с помощью AppLocker:
Таким образом, можно разрешить “полезные” Metro приложения и запретить все остальные:
Что касается Windows Installer и Script rules – на практике их применение встречается настолько редко, что описывать их сейчас смысла не вижу.
Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.