Вася Гусев прислал мне одну замечательную ссылку на пост (а в посте ссылка на документ) Дмитрия Буланова по управлению AppLocker'ом с использованием Windows PowerShell: http://dimanb.spaces.live.com/blog/cns!7D6C59DEE1DA79E5!323.entry

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

Уже несколько лет администраторам в организациях приходилось устанавливать стороннее программное обеспечение, за что организациям приходилось тратить немалые средства. Теперь с появлением AppLocker у администраторов нет необходимости в поиске стороннего программного обеспечения, т.к. с появлением Windows 7 и Windows Server 2008 R2 AppLocker добавлен в групповые политики.

При этом автор очень сильно недоговаривает, поскольку SRP существует ещё с 2001 года (когда вышел RTM Windows XP). Т.е. раньше тоже были средства контроля используемых приложений.

Часто со временем, после развертывания операционных систем, конфигурация программного обеспечения типичного рабочего места оказывается далека от желаемого результата. Несогласованности приходят чаще, не столько от установки, сколько от работы несоответствующего стандартам программного обеспечения в пределах настольного окружения. Пользователи инсталлируют программное обеспечение из разнообразных источников: компакт-дисков и дисковых накопителей, загрузки файлов из сети Интернет, совместного использования файлов через совместные пиринговые сети, и через электронную почту. Результат – возможность заражения компьютера вредоносным программным кодом

Наверное, единственное утверждение, с которым я согласен.

Software Restriction Policies (SRP), в Windows XP и Windows Vista, было одним из первых решений прикладного контроля. SRP дал IT-администраторам грубый механизм, для определения и написания политик контроля за приложениями. Однако SRP мог ограничить управление в динамической настольной среде, где приложения устанавливались и обновлялись на постоянной основе, т.к. они в основном использовали правила хэширования. С правилами хэширования, каждый раз при обновлении программного обеспечения необходимо было создавать новые правила хэширования.

Враньё! Особенно выделенное. В ряде моментов SRP более гибок, чем AppLocker. Если говорить про правила хешей, то AppLocker вносит только одно удобство – позволяет за раз добавить несколько файлов в правило хеша из одной папки. Но дальше в этом плане ничем не отличается от SRP. А с правилами путей профитов в AppLocker по сравнению с SRP почти и нету, поскольку в правилах путей как правила используются wildcards, вместо полных путей до конечного файла. Про паблишеров я отмечусь чуть ниже.

С появлением AppLocker в операционной системе Windows 7 растет необходимость введения решений прикладного контроля на предприятии: простой и гибкий механизм, который позволяет администраторам конкретизировать разрешения для запуска программного обеспечения в своей программной среде. В результате, AppLocker обеспечивает не только защиту безопасности, но и оперативность и удобство по развертыванию политик

Этим автор ещё раз доказывает своё мнение, что до AppLocker'а у нас был ад и Израиль и у нас не было SRP. И прочитайте выделенное. Мне это говорит, что наоборот, AppLocker – источник всех проблем. Не будь его, не росла эта необходимость. В чём оперативность здесь – мне пока непонятно. Да, и что есть прикладной контроль? Есть мнение, что это от английского Application Control (жертва пиратского промпта? © Artem Pronichkin).

1. Ограничение в запуске нелицензионного программного обеспечения на рабочем месте;
2. Понижение уязвимости, средствами запрещения запуска несанкционированных приложений на вашем рабочем месте, в том числе запуск вредоносного кода;
3. Запрещать пользователям запуск приложений, которые бесполезно потребляют сетевую пропускную способность;
4. Ограничение пользователей от запуска приложений, которые дестабилизируют их рабочую среду;
5. Эффективность конфигурации управления;
6. Позволять пользователям устанавливать и запускать одобренное администратором программное обеспечение основанное на деловых потребностях;
7. Гарантировать, согласованность установки программного обеспечения с корпоративными политиками и правилами, например PCI DSS, Sarbanes-Oxley, HIPAA, Basel II, и другое.

пункт 3 - покажите!!! Как? Я тоже хочу использовать такую функциональность! Т.е. создавать правила на основе критериев: только приложения, которые полезно потребляют пропускную способность сети. В последнем пункте заметил несколько новых слов, значения которых я не знаю. Подозреваю, что основная целевая аудитория документа тоже не сильно владеет такими терминами.

Но вообще все эти пункты укладываются в более короткий список:

• Контроль запуска только разрешённых администратором приложений. Что исключает возможность несанкционированного запуска потенциально опасного, вредного или лишнего ПО.

Размазывать единственное предназначение AppLocker'а (равно как и SRP) на 7 пунктов незачем. Разве что – задавить читателя массой возможностей нового продукта.

разрешения, запрещения и исключения

в русском языке вряд ли есть такое слово, как “запрещения”. Правильнее будет “запрет”. Промпт переводит как умеет…

Администратору предоставляется возможность разрешения на запуск приложений, которые входят в «белый список приложений» и блокировать все остальное.

в этом предложении я ничего не понял, кроме “белый список приложений”.

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

Хотелось бы мне знать, чем в данном случае явный запрет будет отличаться от отдельного запрета? Технически это одно и то же. Т.е. если мы одним правилом накрываем достаточно большую область, в которой нужно создать исключения, то создание исключения или отдельного запрета будет равноценным, поскольку тут так же работает правило приоритета более точного правила. А SRP этим не обделён ни разу.

AppLocker вводит правила издателя, которые основаны на прикладных цифровых подписях. Правила издателя дают возможность создания правил, которые включают возможность обновления программного обеспечения. Например, организация может создать правило, чтобы “разрешить все версии, большие, чем 9.0 для запуска Acrobat Reader, если у программного обеспечения Adobe есть цифровая подпись”. После чего, когда у Adobe появится новая версия Acrobat, вы можете безопасно запустить обновление программы без необходимости создания нового правила для последующей версии приложения.

Вот здесь снова появляется ложь. Правила издателя были в SRP, только немного в ином виде (Certificate Rule). Опять же, следует учитывать, что вы можете использовать эту возможность только при условии, что у файла есть цифровая подпись. Нету подписи – вот вам пачка хешей, работайте. Плюс, как я уже упоминал, AppLocker не закрывает одну опасную брешь в концепции цифровых подписей – не проверяется доверие конкретной цифровой подписи. Кто угодно может прочитать правило паблишера (да-да, именно средствами родного PowerShell, поскольку других вменяемых средств нету) и подписать свой файл своей же подписью, которую AppLocker скушает и разрешит для запуска. Вобщем, разработчики AppLocker'а допустили 2 фатальные ошибки, из-за которых эти профиты могут просто потерять реальный практический смысл:

1. совершенно испоганили правило издателя (publisher), отменив проверку доверия конкретной цифровой подписи;
2. разрешили пользователям со стандартыми правами (standard user) читать все настройки этой политики.

Поэтому эти 2 пункта следует рассматривать не как бенефиты AppLocker'а, а как его недостатки в контексте безопасности. Это было сделано в пользу удобства и в ущерб безопасности. И это не говоря о том, что не все редакции Windows 7 могут использовать эту политику.

Правила AppLocker могут быть ассоциированы с конкретным пользователем или группой в пределах организации. Это обеспечивает гранулирование контроля, что позволяет вам поддерживать требования компании и предписания благодаря которым пользователи могут управлять специфическими приложениями. Например, вы можете создать правило, чтобы “разрешить сотрудникам Отдела Финансов управлять линией приложений, которые относятся к их деятельности”. Эти приложения блокируются от запуска для всех пользователей, которые не находятся в Отделе Финансов (в том числе администраторы), но все еще обеспечивают доступ для тех, у кого есть надобность управлять данными приложениями.

На самом деле это тоже не прорыв. Подобная реализация на уровне групп пользователей была и в SRP, поскольку SRP можно было конфигурировать в секции User Configuration и фильтровать политику с помощью Security Filtering. Т.е. данный функционал был чуть причёсан и сделан более user-friendly.

Благодаря AppLocker в Windows 7, у администраторов появляется возможность контроля за приложениями пользователей.

Ещё раз отмечаю, что AppLocker в этом отношении не единственный бесплатный инструмент.

Вобщем, мой совет читателям – избегать подобных переводов, как ересь и ЛПП, поскольку промпт никогда (во всяком случае – в обозримом будущем) не сможет переводить тексты со смыслом и именно тем смыслом, который заложен в оригинале. Поэтому предлагаю ссылки на оригинальные статьи, которые были переведены в этом документе:

• Windows 7 AppLocker Executive Overview
• Getting Started with AppLocker management using Powershell

Спасибо за внимание :-)

Хорошие новости – я наконец-то добрался до него! Что такое 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 категории:

1. Executable Rules – содержит правила для файлов с расширениями COM, SCR и EXE;
2. Windows Installer Rules – содержит правила для файлов с расширениями MSI и MSP;
3. 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 правила по умолчанию (и так будет в каждой категории):

1. Allow Everyone all files in Windows directory;
2. Allow Everyone all files in ProgramFiles directory;
3. 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 вещи:

1. целостность подписи (вне зависимости кем эта подпись сделана).
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 :-)