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

Сегодня расскажу о ещё одном способе обхода политики SRP и запуске VBS кода в обход политики. На саму идею меня натолкнул Александр Станкевич.

Суть проблемы была в следующем. Если мы создадим более ограничивающую политику, например, разрешив только запуск .exe файлов из %systemroot% и %systemroot%\system32, то у нас будет 2 таких правила:

• Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe
• Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%system32/*.exe

И тогда у нас из разрешения выпадают .exe файлы из других папок, а так же выпадают остальные типы файлов из указанных папок. Но мы часто пользуемся консолями MMC, которые имеют расширение .MSC и которые проверяются политикой SRP:

 

Так вот, если мы попробуем запустить любой .msc файл из папки system32, то получим ошибку:

Вроде всё логично, т.к. для MSC файлов нету отдельных исключений в Additional Rules. Но эта же оснастка запускается через Start –> Administrative Templates –> Services.lnk.

В этом пункте меню находится ярлык на соответствующую оснастку в папке System32. Быстро сориентировавшись я стал искать способ использования этой лазейки и достаточно быстро её нашёл. Ни для кого не секрет, что кроме cscript.exe в системе есть ещё 2 обработчика VBS/JS – это Internet Explorer и MSHTA.exe. Запуск  VBS/JS через IE – занятие довольно утомительное, поскольку этот код сильно зажат на уровне сетевых зон и просто так код запустить не удастся (нужно существенно изменить настройки сетевых зон, чтобы IE без вопросов исполнял абсолютно всё, не спрашивая пользователя). Но MSHTA.exe (HTA – HTML Application) не использует сетевые зоны и так же является обработчиком кода VBS/JS, который завёрнут в HTML обёртку. Типичный пример HTA – Manage Your Server в Windows Server 2003. Я сделал следующий трюк – создал на рабочем столе файл .hta следующего содержания:

<HTML>
<script language="vbscript">
    msgbox "I'm dangerous VB Code!!!!1!11"
</script>
</HTML>

и попытался его запустить – получил ошибку. Однако я рядышком сделал шорткат (ссылку) на этот файл и запустил через ссылку. И файл запустился! Я увидел исполненный VBS код. В принципе, внутри тега <script> можно записать любой VBS/JS код и он будет работать. Однако такой способ не сработал для файла с расширением .VBS. В ходе экспериментов было выделено 2 группы расширений, которые различно хандлятся политикой SRP при запуске этих файлов через шорткаты:

• REG, MSC, HTA, CHM – не хандлятся политикой SRP и запускаются в обход политики через ссылки на указанные файлы.
• CMD, BAT, MSI, VBS, JS – эти типы файлов корректно хандлятся политикой SRP и их запуск через ссылки невозможен.

В принципе, HTA обычно редко используется в работе (кроме случаев собственных наработок администраторов), поэтому в общем случае можно блокировать запуск mshta.exe, reg.exe и hh.exe, который используется для просмотра CHM файлов.

В настоящее время я открыл кейс в техсаппорте Microsoft по этому поводу, поэтому если от них будут какие-то новости, то я об этом обязательно расскажу. Такие дела.

Недавно на форуме SysFaq.ru была занятная тема про порядок применения групповых политик в домене. В общем смысле там вопрос сводился к приоритету политик, что настроенный параметр в доменной политике будет иметь приоритет над тем же параметром в локальной политике и работает принцип LSDOU (Local, Site, Domain, OU). Но если говорить по SRP, то здесь есть свои нюансы.

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

fig.1.

Т.е. видно, какая политика выиграла. В случае с SRP, вы этого не увидите:

fig.2.

Когда вы получите набор правил из всех политик, то вполне вероятны конфликтные ситуации, когда в одной политике правило разрешает запуск чего-то, а в другой политике запрещается, то финальная политика определяется по своим особым законам. Причём, сложности добавляет тот факт, что внутри порядки разные. Например, порядок разбора правил путей отличается от порядка разбора всех остальных типов правил. Поэтому я решил немного детальней осветить этот вопрос, чтобы не было никакой путаницы. Я ещё в журнальной статье (На страже безопасности – Software Restriction Policies) отмечал про порядок применения типов правил. Однако, формат журнала не позволял детально рассмотреть этот момент, поэтому я его раскрываю здесь.

Итак, когда на клиентский компьютер применилось несколько политик со своими правилами, то они сортируются по конфликтным парам. Конфликтную пару могут составить 2 одинаковых правила (например, по сертификату или хешу), но с разными уровняеми (Unrestricted, Disallowed). Если для правила не нашлось конфликтной пары, то оно считается единственным правилом в паре и в итоге оно будет результирующим. При этом все пары сортируются и проверяются в строгом порядке:

• [сперва запрет, потом разрешение] Правило сертификата
• [сперва запрет, потом разрешение] Правило хэша
• [сперва запрет, потом разрешение] Правило сетевой зоны
• [сперва разрешение, потом запрет] Правило пути

Для первых трёх типов на каждый объект может быть задана одна пара правил (не может быть для одного файла 2 разных хеша, поэтому для него существует только один хеш и для этого хеша может быть 2 уровня – Unrestricted/Disallowed). И для первых трёх типов правил работает правило First Matching. При попытке запуска файла сперва проверяется запрет по правилу сертификата. Если он есть, то дальнейшая проверка правил обрывается и на основе first matching доступ прекращается. Если же запрета нету, то проверяется разрешение на основе сертификата. Если разрешение есть, то опять же на основе first matching доступ к файлу разрешается и остальные правила не проверяются. Если же правила сертификатов для объекта не обнаружено, то проверка переходит к правилам хешей. Та же самая ситуация повторяется и с хешами и правилами сетевой зоны. Если ничего из этого не соответствует объекту, то процесс переходит к проверке правил путей.

В правилах пути существует свой порядок сортировки правил:

• [сперва разрешение, потом запрет] сначала самое общее правило (например, C:\)
• [сперва разрешение, потом запрет] более точное (например, C:\Documents and Settings)
• [сперва разрешение, потом запрет] ещё более точное (например, C:\Documents and Settings\All Users\Desktop)
• [сперва разрешение, потом запрет] <...> до полного соответствия имени файла

Здесь так же правила разбиваются на пары. Т.е. для каждой точки пути подбирается такое же правило, но с другим уровнем Unrestrited/Disallowed. Как можно заметить, здесь меняется порядок проверки запретов и разрешений. Если в первых трёх типах правил первыми проверялись запреты, то в правилах путей всё наоборот – сначала обрабатываются разрешения и только потом запреты. Это обусловлено тем, что для правил путей нету правила First Matching, а проверяются абсолютно все правила. При этом, как видно из описания, сначала проверяются более общие правила с бОльшей площадью охвата (как весь диск C:\). И вот так проверяются все правила путей и результирующим правилом для объекта станет то, которое проверилось самым последним, которое будет самым точным из всех правил, под которое подпадает проверяемый объект. Безусловно, если есть пара, которая одновременно разрешает и запрещает запуск по полному имени файла, то последним проверится запрет и доступ будет запрещён. В этом смысле так же работает правило, что одинаковый запрет имеет приоритет над таким же разрешением. Если в исключениях не нашлось ни одного правила, под которое смог бы подпасть объект, тогда решение о запуске будет приниматься на основе Default Level.

Примечание: при проверке результирующей суммы в RSOP.MSC на клиентах Windows Vista SP1 и выше вы можете попасть на одну засаду. Дело в том, что новая консоль RSOP.MSC теперь показывает не всё. В разрезе результирующей политики вы не увидите правил сертификатов! Т.е. они по факту есть и работают (соответствующие сертификаты размещаются в контейнерах Trusted/Untrusted Publishers в CertStore), но в этой консоли их не будет. Почему так – я не знаю, но вам следует принимать во внимание этот факт.

Примечание: хочу замтетить, что порядок применения политик SRP влияет только на Default level, Enfocrement, Designated Files Types и секцию Trusted Publishers. Для Additional Rules порядок применения политик не имеет значения.

Update 04.09.2009: для защиты от атаки на SRP путём подмены сертификатов цифровой подписи обязательно прочтите обновлённый материал: Защищаем Software Restriction Policies. Т.е. вместо отключения возможности добавления сертификатов в Trusted Publishers, вы можете запрещать пользователям добавлять свои сертификаты в контейнер Trusted Root Certification Authorities.

Update 20.12.2009: пофиксено правило запрета для папки Temp. Вместо переменной %systemroot% используется путь из реестра.

Update 22.04.2010: пофиксен путь реестра для принтеров.

---

Хорошие новости – сегодня раскроем очередную партию секретов Software Restriction Policies.

Плохие новости – буду срывать покровы и показывать, как ещё можно злонамеренно обходить политику.

Жизнь такая интересная штука, которая любит преподносить сюрпризы, как приятные, так и не очень. Вот и сейчас, казалось бы, считал, что разобрался с вопросом SRP, куда уж дальше? А вот и нет. Давайте по порядку.

1) Возьмём пост: Секреты Software Restriction Policies (часть 2) и список стандартных правил из него. Ни в коем случае в исключениях нельзя использовать переменные окружения, типа %systemroot%, %programfiles%, %userprofile%, etc, поскольку это таит в себе угрозу:

Start –> Run… –> set programfiles=c:\users\username\desktop

и эта строчка перепишет переменную окружения %programfiles% на новое значение. Как можно догадаться, что теперь это исключение в политике будет отрабатывать не на настоящую папку Program Files, а на десктоп пользователя и пользователь сможет запускать оттуда что угодно! И вы ничего с этим не сделаете. Следовательно, эти 2 переменные следует заменить на оригинальные значения (т.е. ключи реестра), если вы использовали переменные окружения, вместо ключей реестра, которые показывают реальный путь до этих папок:

Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Но эти 2 переменные – не единственные, которые мы используем. Если у нас доменная сеть, то пользователям нужно разрешать запуск логонных скриптов, которые хранятся в папке NetLogon контроллера домена. Общий вид исключения выглядит как:

Unrestricted - %logonserver%\Netlogon\*.bat

Поскольку папка Netlogon реплицируется между контроллерами домена, то переменная %logonserver% позволяет гарантированно запустить логонный скрипт, даже если остальные контроллеры домена временно недоступны. Но, как я уже показал, переменную %logonserver% можно перенаправить куда угодно и используя это исключение может запускать свои приложения. Чтобы устранить этот недостаток можно пойти двумя путями:

• использовать полный прямой путь до папки со скриптами. Это может быть не очень удобно
• использовать цифровые подписи для логонных скриптов. Значительно повышает эффективность работы и безопасность запуска скриптов, но требует более серьёзной технической подготовки от IT-персонала.

Так же не следует заменять %logonserver% на \\domain.com\netlogon\*.bat, поскольку при разрешении имени домена далеко не факт, что пользователь получит имя и адрес работающего контроллера. В принципе, такой формат будет возвращать имя нужного контроллера, но я не готов ручаться, что это будет работать всегда.

Стало быть, утверждение из предыдущего поста: “следует предельно максимально использовать переменные окружения и ключи реестра вместо абсолютных путей” следует считать частично верным. Т.е. переменные окружения использовать не рекомендуется использовать вообще. А так же не рекомендуется использовать ключи реестра из ветки HKCU, поскольку пользователь может их менять на своё усмотрение.

2) с подсказки коллеги с форума SysAdmins.SU WindowsNT (который тоже активно применяет SRP в своих организациях и занимается исследованием этой темы). Пользователи могут шедулить задания, которые будут исполняться через каждую минуту и ждать, когда администратор временно отключит политику SRP и задание, таки, выполнится! Вот тут я не знаю как быть. Как вариант – дать пользователям Read Only на C:\Windows\Tasks через командную строку (например, через icacls), что запретит пользователям создавать задания. На сколько это хорошо или плохо уже судить не мне, поэтому здесь ничего категорично советовать не буду.

3) SRP бессмысленна с обработкой расширения LNK, поскольку тут таится другая угроза. Я думаю, что многие смотрели на эти исключения, но не видели лазейки. Например, исключение:

Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop%*.lnk

Вы думаете, оно разрешит нам запускать только ярлыки с рабочего стола? Наивняк! Я тоже так думал, до вчерашнего дня, когда я отлаживал один скрипт на PowerShell и понял одну вещь. SRP не отличает файл от папки. Создаёте на десктопе папку, например, 1.LNK и из этой папки запускаете что хотите! SRP не отличит, что 1.LNK это папка, а не ярлык.

Я создавал исключения для .LNK по причине, что я не знаю, что это такое. Я знаю, что .LNK только ссылка. А может ли LNK самостоятельно исполнять какой-то код? Мне этого неизвестно. Поэтому я сначала использовал исключения для LNK.

4) так же WindowsNT подсказал другую проблему. Я уже неоднократно говорил об опасностях папки C:\Windows\Temp и папки спулера, а именно – что пользователи имеют право записи и исполнения в этих папках. Но эти папки разрешаются общим правилом SystemRoot, поэтому мы использовали отдельные запреты:

Dissalowed - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\DefaultSpoolDirectory%
Dissalowed - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%Temp

и для установки приложений и драйверов мы использовали REG файлы (ссылка на тему – в самом начале поста). Однако, как выяснилось, значение PolicyScope начинает действовать только после перелогона, что усложняет нам жизнь.

Поэтому было принято решение рекомендовать переносить спулер и системный темп за пределы системного каталога. Как вы это сделаете – выбирайте на свой вкус. Самое простое:

• спулер - http://support.microsoft.com/kb/318748
• системный Temp – переопределить переменную в Environment Variables:

Подменить его можно или вручную или стартапным скриптом.

Следовательно REG файлы для временного отключения и включения политики на локальном компьютере нужно отредактировать, а именно – убрать параметры Policy Scope и оставить только Default Level.

5) а теперь самый главный бонус для самых терпеливых, кто дочитал до сюда :-) . Внимание, на экран:

по умолчанию Trusted Publisher Management в SRP выставлен в All administrators and end users (в Windows Vista и Windows Server 2008) или End users в Windows XP/Windows Server 2003. Это поле отвечает за возможность добавления сертификатов в секцию Trusted Publishers пользовательского certificate store. И мало кто обращает на него внимания, поскольку значение этой настройки весьма неоднозначна в интернете и точную формулировку мало кто может дать и эту опцию почти никто не трогает.

А теперь делаем финт ушами:

потребуется .NET Framework SDK или любой инструмент для генерации сертификата. Самое простое – утилита makecert.exe.

• генерируем сертификат:

открываем командную строку, перемещаемся в папку, где хранится утилита makecert.exe и выполняем команду:

makecert.exe -n "cn=srp" -ss my -eku 1.3.6.1.5.5.7.3.3

этой командой сгенерируется сертификат с OID равным Code Signing. Сертификат хранится в хранилище Current User\Personal.

• Экспортируем сертификаты в .CER файл:

Открываем оснастку certmgr.msc, переходим в Personal и экспортируем этот сертификат в файл под именем, например, siging.cer. Далее открываем сертификат, переходим на вкладку Certification Path, выделяем Root Agency сертификат, жмём View Certificate –> Details –> Copy to file. Экспортируем корневой сертификат в .CER файл, например, root.cer. Эти сертификаты нам потребуются для обхода SRP.

• создаём скрипт:

открываем блокнот и в нём набираем:

msgbox “Hello World!”

сохраняем как script.vbs.

• подписываем этот скрипт:

для подписи потребуется утилита signcode.exe из того же SDK. Открываем командную строку, переходим в ней в папку, где хранится signcode.exe и выполняем команду:

signcode.exe -cn "srp" script.vbs

или

signcode.exe -cn "srp" -t http://timestamp.verisign.com/scripts/timstamp.dll script.vbs

эту часть пользователь может выполнить у себя дома. Теперь пользователю нужно доставить оба файла сертификатов и скрипт на рабочий компьютер как угодно. На рабочем компьютере (который защищён SRP) пользователь извлекает на рабочий стол (в любое место, куда ему разрешена запись) VBS файл и открывает оснастку certmgr.msc. В ней он импортирует:

• root.cer в секцию Trusted Root CAs
• signing.cer в секцию Trusted Publishers

пользователь дважды щёлкает на VBS файле и:

он запускается! Чтобы это сработало важно только добавить сертификат, который использовался при подписи скрипта в Trusted Publishers.

Бороться с этим можно только одним способом. Переставить переключатель в Allow only all administrators to manage Trusted Publishers. Если так сделать, то такой финт ушами уже не получится. Но тут мы сразу потеряем автоматическую установку Windows Update в Windows XP/2003. На сколько я понимаю Windows Update использует эту же лазейку. Т.е. при поступлении обновлений некая служба (вероятно Windows Update) с системными правами добавляет сертификат подписи в Trusted Publishers и инициирует запуск самих апдейтов, которые подписаны этим сертификатом. А апдейты в Windows XP/2003 сначала разжимаются в папку с рандомным именем в корне рандомного диска и устанавливаются. После чего сертификат удаляется из store. В Windows VIsta и выше файлы обновлений уже имеют расширение .MSU и не мониторятся политикой по умолчанию, поэтому в этих системах можно запретить пользователям добавлять сертификаты в Trusted Publishers. Но (не буду утвержать на 100%, но скорее всего это так) мы ещё потеряем возможность использования правил по сертификатам, которые настроены в User Configuration групповой политики, поскольку сертификат из той политики добавляется именно в User Store.

Вот такие дела, вобщем.

В предыдущей части мы поговорили об основных этапах настройки OCSP на сервере CA. Науонец-то мне удалось восстановить работу виртуальных машин и можно продолжить разговор. И сейчас предлагаю поговорить уже о базовой настройке OCSP Responder.

настройка Online Responder

Настройка Online Responder очень проста: Start –> Administrative Tools –> Online Responder Management. И правой кнопкой по Revocation Configuration –> Add Revocation Configuration. Мастер очень простой и понятный, интересно будет на стадии Select Signing Certificate:

fig.1

именно тут нужно ставить галочку Auto-Enroll for an OCSP signing certificate, вместо использования Certificate Autoenrollment. С этой галочкой OCSP будет для себя каждые две недели (по умолчанию) запрашивать новый сертификат. В последнем шаге указываются адреса CRL'ов, по которым OCSP будет сверять сертификаты, а так же период обновления CRL'ов. После этой несложной процедуры, нужно этот сервер указать как Array Controller. Дело в том, что в сети может быть несколько онлайн респондеров для одного CA и они будут образовывать массив респондеров. Но один из них должен стать главным в массиве и остальные члены этого массива будут сверять свою конфигурацию именно с контроллером. Для этого в той же оснастке нужно перейти в Array Configuration, правой кнопкой на вновь созданном сервере и выбрать Set As Array Controller.

Проверка конфигурации

В принципе, теперь можно проверять конфигурацию OCSP. Если встать в самый верх дерева консоли (Online Responer: servername), то в центральной части оснастки должна появиться зелёная галочка:

fig.2

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

fig.3

 

Там же вы можете посмотреть сам сертификат, который будет использоваться для подписи OCSP ответов. Если ваша картина соответствует тому, что отображено на скриншотах, то это значит, что вы успешно настроили OCSP. Теперь все издаваемые сертификаты в поле Authority Information Access будут содержать адрес OCSP респондера и клиенты Windows Vista и выше смогут через него проверять статус сертификата. Собственно, как это выглядит:

 
fig.4

Как видите, там прописан адрес, куда будут направляться OCSP запросы. В качестве бонуса прилагаю трассировку Network Monitor ответа OCSP Responder:

  Frame: Number = 10, Captured Frame Length = 2974, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-01-02-05],SourceAddress:[00-15-5D-01-02-01]
+ Ipv4: Src = 192.168.2.11, Dest = 192.168.1.2, Next Protocol = TCP, Packet ID = 11241, Total IP Length = 2960
+ Tcp: Flags=...A...., SrcPort=HTTPS(443), DstPort=49800, PayloadLen=2920, Seq=2068515486 - 2068518406, Ack=1096717416, Win=513 (scale factor 0x8) = 131328
- Ssl:   Server Hello. Certificate. Certificate Status.
  - TlsRecordLayer:
     ContentType: HandShake
   + Version: TLS 1.0
     Length: 4139 (0x102B)
   - SSLHandshake: SSL HandShake TLS 1.0 Encrypted Handshake Message
      HandShakeType: ServerHello(0x02)
      Length: 76 (0x4C)
    + ServerHello: 0x1
      HandShakeType: Certificate(0x0B)
      Length: 2556 (0x9FC)
    - Cert: 0x1
       CertOffset: 2553 (0x9F9)
     - Certificates:
        CertificateLength: 1088 (0x440)
      - X509Cert: Issuer: contoso-DC2-CA,contoso,com, Subject: dc2.contoso.com,OU,Contoso,Riga,Riga,LV
       + SequenceHeader:
       - TbsCertificate: Issuer: contoso-DC2-CA,contoso,com, Subject: dc2.contoso.com,OU,Contoso,Riga,Riga,LV
        + SequenceHeader:
        + Tag0:
        + Version: v3 (2)
        + SerialNumber: 0x110c0b52000000000013
        + Signature: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)
        + Issuer: contoso-DC2-CA,contoso,com
        + Validity: From: 05/11/09 17:24:32 UTC To: 03/30/11 14:06:53 UTC
        + Subject: dc2.contoso.com,OU,Contoso,Riga,Riga,LV
        + SubjectPublicKeyInfo: RsaEncryption (1.2.840.113549.1.1.1)
        + Tag3:
        + Extensions:
       + SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)
       + Signature:
     - Certificates:
        CertificateLength: 1459 (0x5B3)
      + X509Cert: Issuer: Contoso CA,contoso,com, Subject: contoso-DC2-CA,contoso,com
      HandShakeType: Certificate Status(0x16)
      Length: 1491 (0x5D3)
    - CertStatus: 0x1
       CertificateStatusType: OCSP Response(0x01)
     - OcspResponse:
        OCSPResponseLength: 1487 (0x5CF)
      + OCSPResponseData: Response has valid confirmations (0); Cert Status = Good; SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

Если смотреть в Network Monitor, то запрос клиента в графе протокол будет - SSL, а в графе Description – SSL:  Client Hello. В ответе OCSP в графе Description будет – SSL:  Server Hello. Certificate. Certificate Status. Эту часть я выделил синим цветом в начале трассировки. Далее, красным я выделил часть, в которой содержится полная информация о проверяемом сертификате. Чуть ниже синим выделил часть, которая содержит всю необходимую информацию о сертификате издателя для проверяемого сертификата (там по сути будет та же информация, что и в красной части, поэтому свёрнуто). Но наиболее полезным для нас будет именно часть, которая выделена зелёным цветом, поскольку именно там будет храниться ответ OCSP. В данном случае сертификат имеет статус Good, т.е. валидный. В противном случае там будет отображено следующее:

+ OCSPResponseData: Response has valid confirmations (0); Cert Status = Revoked; SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

я отозвал сертификат, опубликовал Delta CRL и снова промониторил трафик. Браузер, в свою очередь, вежливо предложил покинуть этот сомнительный ресурс.

Заключение

Как мы успели рассмотреть, конфигурирование OCSP в Windows Server 2008 достаточно простое, хотя и требует от администраторов определённых навыков и умений. Зато в ответ мы получаем достаточно простую схему проверки сертификатов без необходимости скачивания каждый раз списков CRL. Безусловно, я не ставил перед собой задачу полного раскрытия всех аспектов конфигурирования OCSP (читай, срывания покровов), но показать основные ключевые этапы, которые придётся пройти каждому, кто будет настраивать OCSP в своих сетях. Поэтому в конце прилагаю несколько ссылок на более полное и глубокое исследование этого вопроса:

Setting Up Online Responder Services in a Network
Online Responder Installation, Configuration, and Troubleshooting Guide