Contents of this directory is archived and no longer updated.

Posts on this page:

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

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


Read more →

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

Article name Article ID
How to stop an ActiveX control from running in Internet Explorer KB240797
Description of the Software Restriction Policies in Windows XP KB310791
RSoP Tool Incorrectly Displays Software Restriction Policies KB312325
Software Restriction Policies Do Not Recognize 16-Bit Programs KB319458
How To use Software Restriction Policies in Windows Server 2003 KB324036
"Software Restriction Policy Does Not Allow You to Start This Program" Error Message Even Though the Program Is Defined As "Allowed" KB815471
Software Restriction Policies feature does not log events as expected KB823726
Software Restriction Policies Do Not Persist After You Define Them KB830678
"Windows cannot open this program because it has been prevented by a software restriction policy" error message when a user tries to open a file in Windows Server 2003 KB873419
You may receive a "RUNAS ERROR: Unable to run" error message in Windows XP with Service Pack 2 KB895196
The Digital Signatures tab may not appear in the properties dialog box of a digitally signed file that is larger than approximately 400 MB in Windows XP with Service Pack 2 KB922225
FIX: Error message when you try to install a large Windows Installer package or a large Windows Installer patch package in Windows Server 2003 or in Windows XP: "Error 1718. File was rejected by digital signature policy" KB925336
Batch files for which you create a hash rules do not work on a Windows XP-based client computer KB943854
Software Restriction Policy Enforcement set to “All Software Files” causes checks against paths/files that are invalid KB959074
"HTTP Error 404 - File or Directory not found" error message when you request dll or exe files with IIS 6.0 KB970140
You cannot install a Windows Installer package under the Local System context on a Windows XP-based computer that has update KB956572 installed KB971913
Error message when you try to install a large Windows Installer package or a large Windows Installer patch package in Windows Server 2003 Service Pack 2: "Error 1718 File was rejected by digital signature policy" KB973825
The "Run only allowed Windows applications" Group Policy setting displays no entries on a computer that is running Windows Vista, Windows Server 2008, or Windows 7 KB976922
Error message occurs when you use GPMC to view a software restriction Group Policy setting in Windows 7 and in Windows Server 2008 R2: "An error has occurred while collecting data for Software Restriction Policies" KB981750
AppLocker incorrectly calculates the hash of certain files at runtime in Windows 7 or in Windows Server 2008 R2 KB975449
Windows 7 or Windows Server 2008 R2 stops responding at the "Please wait" screen before you are requested to press Ctrl+ALT+DEL KB983551
You cannot access allowed applications that are managed by AppLocker in Windows 7 or in Windows Server 2008 R2 KB2568041
You can circumvent AppLocker rules by using an Office macro on a computer that is running Windows 7 or Windows Server 2008 R2 KB2532445
AppLocker path condition does not work when a file name contains international characters in Windows 7 or in Windows Server 2008 R2 KB2659440

Список будет периодически обновляться по мере выхода новых 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), мы получим ошибку:

x86 error

Это происходит по вполне очевидным причинам. Наши правила по умолчанию не распространяются на папку 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) в реестре:

ProgramFiles and ProgramFiles (x86) paths in Wow6432Node

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

ProgramW6432Node

Этот ключ реестра во всех случаях ведёт в папку 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. Два хеша генерируются даже если это одиночная машина в рабочей группе и совместимость с предыдущими версиями систем не требуется. Вот как это выглядит в реестре:

SRP MD5 hash

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

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

SRP 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:

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

AppLocker & SRP comparison

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

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

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

  SRP AppLocker
Применение правил Все пользователи Определённые группы и пользователи
Уровень по умолчанию Unrestricted Deny
Разрешающее действие :yes: :yes:
Запрещающее действие :yes: :yes:
Особое действие :yes: (Basic User) :no:
Правила сертификатов :yes: :no:
Правила издателей :no: :yes:
Правила хешей :yes: :yes:
Правила сетевой зоны :yes: :no:
Правила пути :yes: :yes:
Системные переменные окружения :yes: :no:
Собственные переменные окружения :no: :yes:
Пути из реестра :yes: :no:
Режим аудита :yes: :yes:
Группировка правил :no: :yes:
Мастер создания правил :yes: :yes:
Импорт/экспорт политик :no: :yes:
Поддержка PowerShell :no: :yes:
Сообщения об ошибках :yes: :yes:
Настраиваемый список расширений :yes: :no:

Мы видим, что преимущество 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.

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

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

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

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

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

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

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

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

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

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

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

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

Вот и всё… :pop: