Хорошие новости – я наконец-то добрался до него! Что такое AppLocker? По сути это следующая стадия эволюции хорошо знакомой нам политики Software Restriction Policies, который доступен в операционных системах начиная с Windows 7 (Ultimate и Enterprise) и Windows Server 2008 R2. Безусловно, политики SRP остались в этих ОС (и SRP единственный инструмент подобного рода, который будет доступен в домашних редакциях Windows 7) в качестве совместимости. Я ещё не имею большого опыта (всего неделю использую его) с AppLocker и хочу поделиться первыми впечатлениями с замашками на общий обзор. Ну и обязательно проведу сравнительные моменты с политикой Software Restriction Policies. Я буду стараться рассмотреть только технические и организационные моменты политики AppLocker, поэтому данная статья может быть полезна только тем, кто имел опыт работы с SRP в качестве материала подготовки перехода с SRP к AppLocker. Для новичков тут вряд ли будет что-то интересное.
Введение
Прежде всего, чтобы как-то начать с ним работать следует включить и запустить службу Application Identity. Чтобы добраться до самой политики AppLocker нужно запустить редактор групповой политики и развернуть его в секции Computer Configuration. Если это изолированная рабочая станция, то просто Start –> Run… –> secpol.msc. И мы увидим примерно такое окно:
Здесь мы видим деление на 3 категории:
- Executable Rules – содержит правила для файлов с расширениями COM, SCR и EXE;
- Windows Installer Rules – содержит правила для файлов с расширениями MSI и MSP;
- Script Rules – содержит правила для файлов с расширениями BAT, CMD, JS, PS1 и VBS.
Update 16.08.2009: в категорию Executable Rules включено ещё одно PE расширение – SCR (скринсейвер). Однако, в документации я не смог найти ни одного упоминания, что это расширение где-то проверяется в AppLocker. Но имейте ввиду, что де-факто это так.
Вот такого разделения весьма не хватало в политиках SRP, где всё было в кучу, теперь всё сгруппировано по категориям. Однако, в AppLocker нету возможности управлять расширениями, в отличии от SRP (где можно было редактировать окно Designated File Types), что является первой точкой возможнного ослабления защиты. И (ололо?) тут мы не видим HTA файлов! Следовательно, при использовании апплокера мы можем невозбранно запускать произвольный VBS код (разумеется, в контексте пользователя, который его запустил). Хотя, может, я слишком маниакальный и только вижу пользователей, которые пачками проносят HTA файлы 
.
Создаём самые первые правила
По умолчанию в консоли никаких правил нету (в отличии от SRP, где основные правила исключений уже были). Чтобы создать правила по умолчанию нужно выбрать нужную категорию и правой кнопкой мышки выбрать Create Default Rules. И тогда появится 3 правила по умолчанию (и так будет в каждой категории):
- Allow Everyone all files in Windows directory;
- Allow Everyone all files in ProgramFiles directory;
- Allow BUILTIN\Administrator all files.
Тут всё понятно – это аналог дефолтных правил в SRP с добавлением того, что администратор может запускать что угодно. Но я буду рекомендовать удалять последнее правило из каждой категории, которое позволяет администраторам запускать всё что угодно (а случай работы с полностью отключенным UAC я даже обсуждать не хочу). Мы ведь помним, что в 99% случаев всех заражений виноват именно локальный администратор.
Примечание: понятие BUILTIN\Administrators здесь трактуется как использование приложений в привелигированном режиме (elevated mode). При обычном запуске приложений на администратора распространяются только первые 2 правила.
На этом этапе мы видим кардинальное перерождение уровня Basic User в новый формат. Basic User в SRP позволял запускать файлы в обычном режиме и запрещал запускать приложения в elevated mode. Здесь же этот функционал работает с точностью до наоборот. Задание исключений для группы BUILTIN\Administrators не позволяет нам запускать приложения в обычном режиме, но разрешает их запуск в elevated mode. И ярковыраженного Basic User больше нету.
Уже из скриншота видно, что мы можем как-то разделять правила по группам пользователей. Этого, кстати, тоже не хватало в SRP. Теперь мы имеем возможность разделять правила для различных пользователей даже на уровне одной изолированной от домена рабочей станции. Это решает сразу 2 проблемы, которые были в SRP:
- нету необходимости в неудобном переключателе между режимом применения политики (для всех пользователей, кроме администраторов или для всех пользователей без исключения) в окне Enforcement.
- нету необходимости редактировать политики в нескольких местах. Т.е. в отличии от SRP, AppLocker уже не имеет настроек в секции User Configuration. Это упрощает процесс создания и внедрения политик на уровне домена, не требуя от администратора досконального знания, как политики из разных разделов GPO будут вести себя в случае конфликтов. Хотя, это знать полезно.
Как только мы создали правила, AppLocker уже начинает работать. Это довольно-таки спорный момент. В SRP у нас было отдельная секция, где мы задавали уровень по умолчанию, а в AppLocker этого уже нету. Каждая категория начинает работать в момент, когда создано хоть одно правило. Тогда работа идёт в строгом соответствии с этими правилами (даже если оно одно). Если удалить все правила из конкретной категории, то политика для данной категории отключается и конкретные типы файлов можно запускать без ограничений. Если сравнить с SRP, то мы так же помним, что политики SRP не экспортируются никак! Т.е. мы не можем их переносить между компьютерами, бэкапить на уровне локальной рабочей станции. Поэтому для предотвращения потери конфигурации и правил в SRP был введён переключатель режима. AppLocker в этом плане немного изменился – мы имеем возможность экспорта настроек и правил политики. Для этого нужно выставить курсор на секцию AppLocker и правой кнопкой мышки выбрать Export Policy. К счастью, политики экспортируются в читабельный XML файл, а не в бинарный мусор (как в случае с экспортом правил IPSec). Для полного отключения политики, там же после экспорта выбрать Clear Policy. Т.е. для временного отключения AppLocker мы сначала эксортируем настройки и правила, очищаем политику и работаем. Когда работу закончили – импортируем политику и мы снова под колпаком. SRP поддерживал возможность временного отключения политики на конкретной рабочей станции через реестр. Теперь мы такого функционала лишены, хотя с возможностью экспорта это не сильно и нужно нам. Ну и, повторюсь, AppLocker работает только в режиме белого списка.
Основные изменения в правилах
А теперь уже конкретно по правилам. В SRP у нас была возможность создавать 4 типа правила: Certificate, Hash, Network Zone, Path. Как и ожидалось, Network Zone не смог найти себе места в этих политиках, поэтому в AppLocker этот тип удалён и остаётся только 3: Publisher (бывший Certificate rule), Hash, Path с такой же приоритезацией. Правила издателя (Publisher) и пути (Path) несколько изменились в своей сути. Начнём с правила пути.
Изменения в правилах пути
Если вспомнить SRP, то там мы могли использовать абсолютные пути, переменные окружения (но на самом деле оказалось, что это очень опасно), подстановочные знаки и чтение путей из реестра. В AppLocker мы можем использовать только абсолютные пути и специальные переменные окружения. Вот таблица (взята из встроенной в Windows справки):
| Windows directory or drive | AppLocker path variable | Windows environment variable |
| Windows | %WINDIR% | %SystemRoot% |
| System32 | %SYSTEM32% | %SystemDirectory% |
| Windows Installation directory | %OSDRIVE% | %SystemDrive% |
| Program Files | %PROGRAMFILES% | %ProgramFiles% and
%ProgramFiles(x86)% |
| Removable media (for example, CD or DVD) | %REMOVABLE% | |
| Removable storage device (for example, USB flash drive) | %HOT% | |
Мы в правилах можем использовать только переменные, которые указаны во второй колонке. Мы лишены возможности использовать другие переменные как %temp%, %logonserver% и др. Но, в то же время, мы можем использовать в правилах переменные для обозначения CD/DVD приводов и съёмных накопителей (просто флешки). Здесь следует учесть, что эти переменные не являются переменными окружения Windows, а внутренние для AppLocker, даже не смотря на совпадение в синтаксисе. Это ещё сильнее утвердило во мне мысль, что Microsoft знал про баг с переменными окружения в Windows и сейчас уже подмена переменных ничего не даёт совсем для обхода запретов политики. Вобщем, тут мы немного потеряли (переменные окружения и чтение путей из реестра), но, в то же время, приобрели защиту от подмены переменных окружения и получили перменные для съёмных дисков и CD/DVD приводов.
Изменения в правилах издателя (Publisher rule)
Это по сути ребрендинг правил сертификатов (Certificate Rule). Тут изменения более глобальные. И так же, частично в лучшую сторону и частично в обратную. Когда вы делаете правило издателя сертификата, то вы указываете на файл, который содержит цифровую подпись и всё. Политика сама извлечёт из файла цифровую подпись и прикрутит издателя к правилу. Вот как это выглядит вживую:
я ему просто подсунул подписанный файл и мы видим несколько разных полей. Поле Publisher извлекается из поля Subject сертификата цифровой подписи. Остальные поля извлекаются уже непосредственно из внутреннего кода файла (он обычно зашивается в EXE файлы при компиляции исходников). В случае со скриптами я не уверен, что они поддерживают распознаваемые версии и другие данные, которые мы видим пустыми на нашем скриншоте. И тогда все файлы данной категории, которые подписаны этим сертификатом будут запускаться без проблем. Двигая указанный ползунок мы можем указывать строгость соответствия подписи от полного соответствия, включая версию файла, до конкретного издателя.
Если говорить про версии файлов, то мы видим (правда, затенённое) поле с раскрывающимся списком, где мы можем задавать как точное совпадение версии (Exact match), так и сравнительную версию – только текущая и более новые версии (And above) или только текущая и более старые версии (And below).
Здесь, в отличии от SRP уже не используется внутренний в Windows механизм Trusted Publishers, который использовался в SRP, поэтому подсовывание сертификатов в этот контейнер ничем нам не поможет, как я уже демонстрировал в случае с SRP.
Внимание – Publisher!
Но тут ВНЕЗАПНО я понял одну вещь. SRP в правилах сертификатов проверял не только соответствие цифровой подписи, но и полное соответствие сертификата в правиле Certificate Rule и сертификата в самой подписи. AppLocker этого не делает. В отношении сертификатов, AppLocker проверяет только 2 вещи:
- целостность подписи (вне зависимости кем эта подпись сделана).
- соответствие поля Subject в сертификате подписи.
Что даёт нам некоторые преимущества. Например, утилиты Sysinternals подписаны разными сертификатами в разное время. Из-за чего для каждого сертификата в SRP надо было указывать каждый уникальный сертификат, что доставляло неудобства. Здесь же мы можем создавать более гибкие правила, которые позволяют запускать, например, любую версию ворда не ниже 10.0. Если у вас в сети используется несколько версий офиса (2002, 2003 и 2007), то мы можем одним правилом разрешить все 3 версии, указав в правиле версию самого древнего ворда и сказать, что можно эту версию и более новые. То же самое и касается утилит Sysinternals.
Что касается скриптов, если в SRP для них правила сертификатов были весьма удобным и безопасным решением. Но, как я говорил, соответствие самих сертификатов AppLocker не проверяет, поэтому мы можем невозбранно подделывать цифровые подписи:
makecert.exe -n "cn=Administrator, cn=Users, dc=contoso, dc=com" -ss my -eku 1.3.6.1.5.5.7.3.3
эта команда сгенерирует нам свой сертификат с таким же полем Subject, что и подписаны скрипты на предприятии (а там скрипты подписаны сертификатом администратора и к нему доступа у нас нету). Далее, мы этим сертификатом подписываем наши вредоносные скрипты, проносим на рабочие компьютеры и они будут запускаться! И только потому, что в наших сертификатах совпал Subject с сертификатом администратора. Технет пишет:
Use a publisher condition when possible. Publisher conditions can be created to allow applications to continue to function even if the location of the application changes or if the application is updated
но мы им не поверим, а от себя скажу, что правила издателей нельзя использовать для скриптов ни в коем случае, а в остальных случаях использовать с особой осторожностью. Пользователи не дураки и смогут прочитать сертификат цифровой подписи в своих логонных скриптах.
Исключения из правил
Поскольку зачастую правила пути и издателя имеют достаточно большой охват (к правилам хеша это не относится), то возможны ситуации, когда из области действия правила нужно что-то исключить. В SRP мы просто создавали отдельное запрещающее правило, что было несколько уныло. Теперь мы можем в самом правиле задавать исключения:
На скрине видно, что у нас есть основное разрешающее правило издателя. Но мы хотим что-то из этого издателя запретить, например, запуск тестовых скриптов из определённой папки. Мы в ходе создания правила указываем нужное исключение (причём, исключение может быть любого типа, а не только того типа, что и основное правило). Достаточно гуманно.
Примечание: не забывайте, что в Windows 7 и Windows Server 2008 R2 системный темп всё так же разрешён на запись пользователям и подпадает под дефолтные ращрешающие правила. Поэтому, если вы ещё их не перенесли в другое место, вы должны в правилах папки Windows должны включить исключения на папку Temp и папку спулера печати.
Много правил в одном правиле
В ходе создания правил вы увидите, что вы в процессе создания правила можете внутри создавать коллекцию подправил, которая будет составлять ваше правило. Скриншот показывать не буду, т.к. это видно по предыдущему скрину. Там есть кнопка Add, с помощью которой можете добавлять несколько различных исключений для своих правил. Это тоже весьма удобно, при условии, что администратор осмысленно структуирует свои правила.
Баги-баги
Я ещё не уверен, что это баг (нашёл такое поведение пока писал этот пост), но мне такой расклад не понравился. Что я сделал:
- создал правило издателя, которое разрешает запускать любые скрипты определённого издателя.
- создал там же исключение из правила. По пути запретил одну папку.
- скрипты из этой папки не запускаются. Всё логично.
- а теперь я создаю ещё одно такое же правило издателя (не удаляя имеющееся правило), но без исключений. И скрипты из запрещённой папки снова начинают запускаться.
Мне думается, что если где-то есть запрет, то он должен быть приоритетней разрешения. Хотя, я ещё далеко не всё знаю про AppLocker, поэтому могу просто чего-то не знать. Либо же явное разрешение без исключений перекрывает запрет в исключениях. Как по аналогии с правами NTFS, когда явно назначенное разрешение перекрывает унаследованный запрет.
Ну что ж, написал много букв по не самой лёгкой теме, поэтому на сегодня вам будет достаточно. У меня ещё есть несколько открытых вопросов по AppLocker и по ходу их разрешения буду писать в бложик.
Удачи! © One