Примечание: данный пост перепечатан в связи с закрытием бложиков на spaces.live.com, как имеющий какую-то ценность для автора и/или читателей.
Очень часто люди задают вопросы по поводу безопасности своих локальных машин, терминальных серверов и постоянно ищут средство защиты систем от поражения вирусами, троянами и просто контроля запуска узкого числа инсталлированных приложени. И каждый раз снова и снова приходится отвечать тремя словами на этот вопрос, а именно - Software Restriction Policies. Данная политика совмещает себе как простоту реализации, так и эффективность её работы. В критических случаях пользователю разрешено запускать только те приложения, которые явно разрешил запускать администратор. Данная технология не нова, поэтому подробно расписывать её здесь не буду, а лишь обозначу ключевые отличия реализации данной политики в Windows Vista/Windows Server 2008 от реализации в WindowsXP/Windows Server 2003.
Политика включается как обычно:
- локальная - Start -> Run... -> secpol.msc -> Software Restriction Policies
- доменная - Group Policy Object Editor -> Computer Configuration -> Windows Settings -> Security Settings -> Software Restriction Policies
Итак, какие изменения у нас появились по сравнению с предыдущими версиями:
- в Security Levels добавился новый уровень безопасности Basic User;
- в Additional Rules удалены 2 правила по умолчанию, которые разрешают запуск EXE файлов в папках Windows и Windows\System32;
- при использовании правил Hash Rule теперь вместо MD5 (как в предыдущих версиях) используется более стойкий алгоритм хэширования Sha256, но при этом сохранилась совместимость со старыми клиентами XP/2003 (будет храниться 2 хэша - MD5/Sha1 и Sha256);
- в Enforcement добавился Enforce/Ignore Certificate Rule;
Казалось бы, пустяк, но я считаю, что тут есть о чём поговорить. Итак, сначала поговорим о новом действии политики как Basic User. Данное действие политики было специально заделано под User Account Control (UAC) и которое совместно с UAC филтрует права пользователя на запуск. Если политики UAC распространяются на все приложения без исключения, то комбинирование действия по умолчанию UAC и при использовании Software Restriction Policies позволяет запретить повышение привелегий для некоторых приложений. Иными словами, даже если запустить приложение с повышенными привилегиями, они всё равно будут отфильтрованы.
Пример 1.
Рассмотрим поведение политики Basic User для установки действия Basic User для программы CMD.EXE:
Сперва при отключенной политике выполню команду, которая включает режим Hibernate для компьютера. Для этого нажимаю на ярлыке CMD правой кнопкой и выбираю Run As Administrator и получаю предупреждение UAC:
соглашаюсь и получаю консоль командной строки, в которой набираю следующую команду и исполняю:
данная команда включает режим Hibernate (возможно не самый удачный пример) и ошибок не вернула.
Действие общей политики здесь неважно, поэтому перейдём сразу к Additional Rules. Для этого я создал Hash Rule для CMD.EXE как показано на картинке:
Теперь снова запускаю консоль CMD с повышенными привилегиями и повторяю процедуру:
хоть я и просил повышенные привилегия для исполнения команды, но действие Basic User не дало этой возможности и отфильтровало мои права до обычного пользователя. Т.е. мы видим, что Basic User ни за что не позволяет выполнить приложение в привилигированном режиме!
Пример 2.
В предыдущем примере я добровольно пытался запустить приложение с повышенными привилегиями. В результате никакого повышения не получилось и приложение запустилось в обычном режиме. А теперь рассмотрим запуск приложения, которое требует повышенния привилегий через UAC. Для этого я буду использовать запуск консоли Computer Management с возможностью изменения настроек консоли. Я удалил правило для CMD.EXE и создал такое же правило для консоли compmgmt.msc:
И при нажатии правой кнопкой на Computer -> Manage получил запрос на повышение прав от UAC с чем я и согласился:
и снова действие Basic User отфильтровало мои повышенные права и выдало такое окошко. Как видно из скриншота политика блокировала запуск консоли. Ещё раз повторюсь, запуск данной консоли с возможностью изменения настроек без повышения прав через UAC невозможно, что мы и видим на рисунке.
Резюме: Действие политики SRP Basic User не позволяет ни в коем случае выполнить приложение с повышенными привилегиями. Если это доступно, то приложение запускается в обычном режиме, как показано на примере 1 или вообще запрещает запуск, если приложение для запуска требует повышенных прав, как это видно на примере 2.
Примечение: Когда первый раз я стал изучать политику SRP на своём нотебуке с Windows Vista был неприятно удивлён, когда при активации политики Disallowed у меня сохранялась возможность запуска .EXE файлов напрямую из проводника и .LNK из меню Start -> Run... . Я помню по XP/2003, что политика активировалась в момент при выборе действия политики. Здесь же я обнаружил что политика применилась лишь частично, игнорировав .EXE и .LNK файлы. Этим вопросом я озадачил Александра Станкевича, который позднее подсказал, что наблюдал такое же поведение на 2008 сервере до тех пор, пока не перезагрузил компьютер. Поэтому при инициализации политики для её полной активации нужно перезагрузить компьютер! Когда политика проинициализирована перезагрузка больше не требуется до полной отмены политики и все изменения применяются на лету. О чём, кстати сообщается в правом окне политики SRP, когда политика удалена или не создана (эхх, невнимательный какой).
Ну и ещё добавлю небольшую заметку по интеграции политик SRP с UAC. В Enforcement есть опция применения политики SRP For All Users except Administrators, т.е. применение политики ко всем пользователям, кроме администраторов. Данная опция работает только для приложений, которые запущены с повышенными привилегиями. Это вполне логично, т.к. даже локальный администратор работает в системе с правами обычного пользователя (ситуацию, когда UAC отключён совсем я не рассматриваю, ибо это не есть хорошо), поэтому в обычной работе политика в любом случае будет воздействовать на него. Это важно понимать, т.к. не совсем явная вещь и её легко упустить из виду.
Что касается Enforce/Ignore Certificate Rule, то тут наверное нету смысла объяснять, что это. По умолчанию правила сертификатов проверяются в первую очередь и если у вас они не используются, то включение обработки правил сертификатов может значительно снизить скорость запуска приложений.
Порядок (приоритет) применения правил политики SRP:
- Certificate Rules
- Hash Rules
- Path Rules
- Default Rule
поэтому отключение правил сертификатов, когда они не используются будет весьма кстати. Напомню, что Certificate Rule может использоваться не только для фильтрации подписанных приложений, но и для разрешения запуска подписанных доверенными сертификатами скриптов.
И на последок дам 3 .REG файла, которыми я пользуюсь в работе для управления политикой:
SRP_Enable - включает действие политики в Disallowed:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers]
"DefaultLevel"=dword:00000000
SRP_Disable - включает действие политики в Unrestricted:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers]
"DefaultLevel"=dword:00040000
SRP_Basic - включает действие политики в Basic User:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00020000
Я обычно кладу эти 3 файла (теперь 3, до этого использовались только SRP_Enable и SRP_Disable) в папку Windows и на рабочий стол администраторской учётной записи создаю ярлыки для них:
эти ярлыки включены в исключения политики и указывают на соответствующие .REG файлы, которые так же находятся в исключениях. Однако хочу заметить, что действие этих ярлыков в среде рабочей группы может быть изменено после перезагрузки системы (после перезагрузки вернётся действие, которое указано в политике), а в доменной среде - либо после перезагрузки либо при последующем обновлении политик (по умолчанию - 1 раз в 90 минут). Поэтому данные ярылки дают лишь временный эффект, но как правило они и нужны на очень короткий срок.
Ну и хочу поделиться маленькой приятной особенностью, которая появилась сейчас. Администраторы, которые работали с политикой SRP в системах XP/2003 испытывали головную боль при обновлении серверов и рабочих станций. Проблема была в самом механизме работы инсталляторов апдейтов, которые в корне произвольного тома создавали папки с произвольными именами, в которые распаковывались апдейты и затем устанавливались. Такая схема не представляла возможным создание правил для SRP, чтобы без отключения политики установить апдейты. Поэтому во время апдейтов приходилось отключать политику и после включать её обратно. В Windows Vista и Windows Server 2008 это уже не так! Я сегодня же проверил возможность установки обновлений с Windows Update при включенной политике SRP Disallowed. И все 16 обновлений спокойно установились и политику отключать не пришлось. Это хороший плюс для Windows Vista!
Вроде осветил основные изменения политик Software Restriction Policies и ничего не забыл. Если забыл что-то, то пните ;)
упс, чуть не забыл, официальную ссылку на TechNet:
Using Software Restriction Policies to Protect Against Unauthorized Software
Comments: