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

Прежде чем оперировать правилами, необходимо подготовить список расширений, которые будет мониторить SRP. Мы уже говорили о том, что список по умолчанию не очень прикольный. Во-первых, оттуда следует выкинуть LNK:

В этом посте я постарался собрать наиболее полезные или интересные ссылки на MS Knowledge Base (или просто KB) по теме Software Restriction Policies и AppLocker.

Список будет периодически обновляться по мере выхода новых KB.

Давненько я ничего не писал про SRP, хотя давно пора было бы заполнить некоторые пробелы. В этой статье мы разберём 3 вопроса (проблемы):

• особенности применения SRP в системах x64;
• особенности конфигурирования политики на терминальном сервере;
• особенности создания правил в Vista-based системах и применения в XP-based системах.

Проблемы SRP в системах x64

Использование SRP в 64-разрядной системе иногда чревато проблемами. Давайте разберёмся с дефолтными правилами. Их у нас всего 2:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Это очень хорошие и полезные правила. Они позволяют нам запускать любые приложения из папки Windows и Program Files. Но в x64 системах у нас есть 2 класса приложений, родные x64 и унаследованные приложения x86, которые работают в режиме эмуляции. Такие приложения как правило устанавливаются в папку Program Files (x86). И если мы попробуем запустить любое приложение из папки Program Files (x86), мы получим ошибку:

Это происходит по вполне очевидным причинам. Наши правила по умолчанию не распространяются на папку Program Files (x86). Для этого мы должны создать ещё одно правило:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%

После этого мы сможем запускать всё из папки Program Files (x86). Вроде бы всё хорошо и замечательно. Но природа работы SRP многогранна и необычна.

Представим ситуацию, у вас установлен 32-разрядный MS Outlook (ну или любая другая 32-разрядная почтовая программа) и вам пришло письмо с приаттаченным RAR архивом. А WinRAR у вас установлен x64. Вы пытаетесь открыть архив из письма, а не получается. На сколько я проверял, вообще ничего не происходит, но в журнале событий (напоминаю, что логи SRP пишутся в журнал Application) с EventID = 865 можно найти многозначащее:

Access to C:\Program Files\WinRAR\WinRAR.exe has been restricted by your Administrator by the default software restriction policy level.

Что хотите, то и делайте. Правила все есть, а не работают. Но я не зря говорил о многогранной и необычной природе SRP. При запуске одного приложения из второго (в нашем случае из аутлука запускаем WinRAR, чтобы открыть архив) контекст SRP наследуется из родительского приложения в дочернее (если так вообще можно сказать). Если говорить простым языком, если родительское приложение (в нашем случае MS Outlook) является 32-битным, то все запускаемые из него приложения проверяются так, будто они 32-битные. На практике это означает примерно следующее. Где фактически находится ветка реестра Software для x86 приложений? Кто-то скажет, что там же, где и всегда: HKLM\Software и будет не прав, потому что правильный ответ: HKLM\Software\Wow6432Node. И давайте посмотрим, что нам покажут вышеперечисленные пути (из правил SRP) в реестре:

А ведут оба этих пути в одну и ту же папку, т.е. Program Files (x86). Соответственно, в такой ситуации у нас нет ни одного правила для папки Program Files и вполне логично, что WinRAR запущен не был. В обратной ситуации (когда из 64-битного аутлука запустить 32-битный WinRAR) такой проблемы нет, потому что путь в значении ProgramFiles (x86) всегда ведёт в Program Files (x86). Для решения этой проблемы в Windows 7 было добавлено ещё одно значение: ProgramW6432Dir = C:\Program Files.

Этот ключ реестра во всех случаях ведёт в папку Program Files. Следовательно, нам нужно создать ещё одно правило, которое будет включать этот параметр реестра. В сухом остатке список правил по умолчанию для x64 систем у нас должен быть минимум такой:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%

Эти 4 правила обеспечивают полный эквивалент правил по умолчанию, которые используются в родных x86 системах. Однако, хочу отметить один факт. Параметр ProgramW6432Dir по указанному пути присутствует только в Windows 7 и Windows Server 2008 R2. В предыдущих системах (включая Windows Vista x64 и Windows Server 2008 x64) он отсутствует. Поэтому в них для решения этой проблемы придётся прописывать абсолютные пути (без использования переменных) к папкам C:\Program Files и C:\Program Files (x86).

Политики SRP на терминальных серверах

Достаточно часто (если исходить из общего количества внедрений SRP) администраторы наступают на одни и те же грабли. Поскольку природа терминальных серверов достаточно разнообразна, практически сложно создать какую-то одну политику SRP с правилами, которые удовлетворяли бы требованиям всех пользователей. Всегда будет так, что одному пользователю будет необходимо одно бизнес-приложение, а другому это приложение не нужно и должно быть запрещено. Адмнистраторы недолго думая пользуются тем фактом, что SRP можно настраивать и на уровне пользователя (секция User Configuration). Создают несколько политик SRP в этой секции, настраивают фильтрацию (чаще security filtering) так, чтобы каждой группе пользователей применялись нужные правила. Но сразу после применения политики могут начаться проблемы. Например, в пользовательской политике исключили расширение LNK, а на самом деле это расширение блокируется. Дело в том, что в определённых ситуациях (не скажу точно при каких условиях) SRP неявно создаёт копию политики по умолчанию в общекомпьютерной ветке реестра: HKLM\Software\Policies\Microsoft\Windows\Safer и получается конфликт, поскольку настройки компьютерной политики (кроме правил в Additional Rules) перекрывают соответствующие настройки в пользовательской политике.

Чтобы заранее избежать подобной ситуации следует придерживаться следующего правила: создать базовую (которая применима ко всем пользователям на машине) политику в секции Computer Configuration (в этой секции определить общие настройки и глобальные правила). Для расширения прав и/или назначения гранулированных прав запуска тех или иных приложений можно назначать правила в секции User Confgiration.

Создание политик в Vista-based системах и применения в XP-based системах

Ещё давным-давно (в декабре 2007) вышла в свет Windows Vista с некоторыми изменениями в SRP. В частности правила хешей теперь поддерживают алгоритм SHA256, который не поддерживается в Windows XP и Windows Server 2003 (включая R2). Но возникает вопрос interoperability с предыдущими системами. Например, что будет, если мы создадим правило в Windows Vista, а применим его на Windows XP (через GPMC.msc, который входит в состав RSAT)?

В интернетах ходят разные мифы на этот счёт, но в реальности всё гораздо проще. Когда Windows Vista (или выше) создаёт правило хеша, система генерирует 2 хеша — родной SHA256 и совместимый хеш MD5. Таким образом обеспечивается полная совместимость с системами XP/2003. Два хеша генерируются даже если это одиночная машина в рабочей группе и совместимость с предыдущими версиями систем не требуется. Вот как это выглядит в реестре:

Здесь мы видим стандартный хеш MD5 (AlgID = 8003 это MD5). ItemData содержит фактический хеш.

Под ключом правила (каждое правило здесь указано в виде GUID'а) добавляется ещё один ключ SHA256:

Вот здесь мы видим другой идентификатор алгоритма (800c это SHA256). ItemData так же содержит фактический хеш, но не MD5, а SHA256.

Примечание: полный список криптографических алгоритмов можнно найти по здесь: http://msdn.microsoft.com/en-us/library/aa375549(VS.85).aspx

Порядок проверки хешей для XP/2003 остался тот же — только MD5. В Windows Vista сначала проверяется хеш из ключа SHA256.

В последнее время мне всё чаще стали задавать вопрос, что выбрать, AppLocker или старый добрый SRP?

Казалось бы, что тут думать — AppLocker и точка. Многие, наверное, помнят пиар-акцию под названием «Windows 7 + 1», которую проводили многие MVP для рекламы новых технологий Windows 7. И весьма досадно то, что некоторые MVP вместо раскрытия реальной объективности новых технологий распространяли просто маркетинговый булшит и даже подтасовывали факты. Например статья Владимира Безмалого про AppLocker:

• AppLocker как средство обеспечения информационной безопасности
• AppLocker Часть 2

Этот вариант статьи можно ещё прочитать и здесь: http://www.osp.ru/win2000/2009/09/10721226/. Моё внимание обратила на себя табличка сравнения SRP и AppLocker. Вот она с моими комментариями:

Я думаю, что ни для кого не секрет, что аудит в SRP был и не сильно хуже, чем в AppLocker. Разница лишь в том, что AppLocker пишет в свой собственный EventLog, а SRP писал аудит в текстовый файл.

На счёт мастера создания правил я немного не понял. В принципе, окно создания правила в SRP тоже своего рода мастер. Только одношаговый, в отличии от AppLocker.

А сообщения об ошибках в SRP были тоже. Как в виде диалогоых окон, так и в журнале Application в эвентлоге. Т.е. тут у меня 2 мнения — либо человек не работал с SRP, либо намеренно исказил факты, чтобы подкрутить популярность AppLocker'а, поскольку революции AppLocker не совершил. Ведь с появлением AppLocker мы приобрели не только удобный интерфейс, но и потеряли несколько полезных вещей, которые есть в SRP. Как я уже отмечал ранее, мы потеряли возможность самостоятельно регулировать список контролируемых расширений файлов и потеряли возможность фильтрования файлов по конкретным сертификатам. Новое правило издателя позволяет контролировать версию разрешённого приложения, но не отличает каким сертификатом подписано приложение. Да и применимость издателей такая же как и у классических правил сертификатов — т.е. низкая. К сожалению я не могу вспомнить ни одно бизнес-приложение (не стандартные приложения типа Microsoft Office), которое бы было подписано. Плюс невозможность использования системных переменных окружения так же усложняет создание правил в доменной среде. Эту табличку можно переделать в такой вид:

Мы видим, что преимущество AppLocker перед SRP резко переходит на нет. Я не хочу сказать, что AppLocker — отстой, а лишь хочу показать, что реализация этой технологии не на столько крутая, что её стоит пиарить как революцию.

Из блога Владимира Безмалого:

В Windows 7 SRP также могут применяться, однако все чаще будет использоваться AppLocker. Почему?

К сожалению этого не случится, во всяком случае в цикле Windows 7. Как уже отмечалось, наиболее значительное изменение в AppLocker — это новый простой, удобный и понятный интерфейс, чего в SRP не было. В значительной степени из-за этого SRP на домашних компьютерах применялся лишь в единичных случаях. Сейчас же применить AppLocker гораздо проще на домашних системах при получении одинаково эффективного результата. Но Microsoft слишком жадный и включил эту технологию только в Windows 7 Ultimate и Enterprise. Я верю, что от появления SRP в домашних редакциях Windows 7 количество применений SRP на них не увеличится совсем. Учитывая, что с ноутбуками будет чаще всего проинсталлирована какая-то домашняя редакция Windows 7, то профита от AppLocker они не получат тоже. Но если дома есть возможность использовать AppLocker и вы хотите получить адекватный уровень защиты от запуска случайных файлов — используйте AppLocker. Хотя, скажите, кто из вас, кроме меня, использует Windows 7 Ultimate/Enterprise дома и использует AppLocker? :-)

Если вы будете иметь возможность перевести часть парка машин предприятия на Windows 7 Enterprise, то вопрос использования AppLocker может сложиться не в его пользу. Это обусловлено тем, что если у вас уже используется SRP, то вам AppLocker не будет нужен до тех пор, пока весь парк не будет переведён на Windows 7 Enterprise. Ведь с AppLocker вы ощутимых бенефитов не получите в плане безопасности, но сразу усложните себе жизнь тем, что вам придётся поддерживать гораздо больше политик — SRP и AppLocker. При необходимости поддерживать клиентов отличных от Windows 7 Enterprise лучше использовать то, что может охватить наиболее число машин — SRP.

Внимать моим рекомендациям — личное дело каждого, просто я отразил своё видение проблематики. Вобщем, я не верю в массовое светлое будущее AppLocker по крайней мере до выхода следующей версии Windows, даже не смотря на активный и нечестный пиар технологии со стороны Microsoft (что вполне нормально для самого создателя) и прочих пиарщиков. Но начинать его использование по мере возможности — очень даже можно и нужно, т.к. однажды SRP просто не окажется в релизе ОС.

Update: этот пост периодически обновляется.

Вот и пришло время сделать сводный пост по своим исследованиям Software Restriction Policies. Здесь я опубликую ссылки на предыдущие материалы, посвящённые этой действительно интересной технологии. К сожалению это скорее всего будет означать завершение срывов покровов в этом направлении. Безусловно, технологии не стоят на месте, а постоянно развиваются, поэтому очень долго топтаться на одном месте не стоит. Но это совсем не означает, что SRP стал реликвией, музейным экспонатом и просто утилем. SRP до сих пор имеет и какое-то время будет иметь важное значение в обеспечении безопасности ОС Windows, поскольку теперь политики SRP поставляются во все домашние редакции Windows 7. А так же будет неотъемлемой частью обеспечения безопасности уже активно используемых систем начиная с Windows XP.

И, собственно, сам список.

• На страже безопасности – Software Restriction Policies

Опубликованная в журнале «Системный администратор» статья даст представление о том, что такое SRP, поведает о ключевых особенностях этих политик и может выступать в качестве теоретической базы для работы с SRP.

• Секреты Software Restriction Policies

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

• Секреты Software Restriction Policies (часть 2)

В этой части рассказаны методы обхода SRP на примере запуска CHM файлов и потенциальной возможности запуска некоторого кода с использованием файлов с расширением SCF. Плюс даны некоторые рекомендации по организации правил для типовой рабочей станции и косметические настройки обработки групповых политик в отношении SRP.

• Секреты Software Restriction Policies (часть 3)

Очередной обзор нескольких способов обхода политик SRP путём подмены системных переменных окружения, использованием в обработке расширений LNK и подстановкой нелегитимных доверенных издателей (цифровых подписей). Так же приведён потенциальный полувандалистский метод атаки на SRP путём генерации зашедуленного задания в ожидании, когда политика будет отключена в профилактических целях.

• Секреты Software Restriction Policies (часть 4)

В этом посте детально рассказано о непростом порядке сортировки и применения множества правил SRP. Используя этот материал вы научитесь разрешать конфликты в правилах и упростит планирование правил SRP.

• Секреты Software Restriction Policies (часть 5)

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

• Секреты Software Restriction Policies (часть 5.a)

содержит официальное заявления сотрудника техподдежки Microsoft — Rahul Denkanikota. В результате двухмесячного общения с техподдержкой мне лично была предложена замена для mshta.exe, которая уже лишена недостатка оригинального файла. Однако, данное решение не планируется выпускать в массы по причине очень большой специфики. В остальных же случаях, если это возможно, следует полностью отказаться от mshta.exe и заблокировать его на уровне правил SRP.

• Защищаем Software Restriction Policies

В этом посте опубликовано решение, которое позволяет защитить SRP от подстановки ложных сертификатов цифровых подписей. В целом, с некоторыми оговорками, после данного поста репутация SRP вновь восстановлена до уровня «надёжно».

• AppLocker vs Software Restriction Policies

Краткая статья, содержащая сравнение возможностей SRP и его последователя, AppLocker.

• Software Restriction Policies — занимательная трилогия

В этой части рассказывается о проблемах и их решении при внедрении SRP в 64-разрядных ситемах, терминальных серверах и небольшой рассказ об отличиях правил SRP в Windows Vista и более новых систем по сравнению с pre-Vista системами (Windows XP/Server 2003).

• Software Restriction Policies, ссылки на KB

Коллекторский пост, содержащий ссылки на статьи в knowledge base (KB), связанные с теми или иными проблемами работы с SRP.

Вот и всё… :pop: