Меню

Настройка srp в домене



Software Restriction Policies (SRP) — эффективная защита Microsoft Windows без антивируса

В данной статье рассказывается о механизме Software Restriction Policies (SRP), который предназначен для создания политик запуска программ в среде Microsoft Windows. В частности, для возможности использования SRP для минимизации рисков возможного инфицирования компьютера вредоносными программами.

С чего начинается защита от вирусов и других зловредных программ?

Защита от компьютерных вирусов, «троянских коней» и прочей дряни в первую очередь зависит от того, с какими привилегиями ты заходишь в компьютер. Обычно все учётные записи (логины) делятся на две категории — административные, предназначенные для установки программ и настройки системы; и стандартные (с ограниченными правами), предназначенные для ежедневной работы. Хочешь что-то настроить, проинсталлировать? Входи Администратором. Хочешь смотреть фильмы, писать курсовую, общаться в Skype? Входи стандартным пользователем.

Дело в том, что у стандартных пользователей нет прав на инсталляцию программ и настройку системы, за счёт чего она работает весьма стабильно и безопасно. Что-то напортачить или сломать не получится, на это у пользователя просто нет прав. Компьтерный вирус — это не чёрная магия, а программа, просто компьютерная программа, поэтому заразить систему вирусом рядовой пользователь тоже не может. Причём, компьютеру всё равно, новый это вирус или старый, особо хитрый или примитивный — если имеющихся привилегий недостаточно, занести вирус в системную папку или прописать его автозапуск в системном реестре не получится никак.

Рисунок 1. Уровень привилегий учётной записи пользователя в Windows 7

Вне зависимости от того, работаем мы дома или в офисе, в систему всегда следует входить только с ограниченными привилегиями. Системные администраторы должны обладать двумя учётными записями — и рядовой, и административной, но использовать последнюю только при доказанной необходимости. Тип используемой вами учётной записи можно уточнить в Control Panel (Панели Управления).

Однако, существуют зловредные программы, которые способны сохраняться не только в системных папках, но и в User Profile — так называемом профиле, рабочей среде пользователя. Эти программы запускаются каждый раз при входе пользователя в систему. Обычно вирусы такого типа «приезжают» на flash-дисках, рассылаются через программы обмена сообщениями и по электронной почте, попадают в компьютер со специальным образом созданных веб-страниц. Для борьбы с подобного типа угрозами в Windows-системах существует весьма простая и надёжная настройка безопасности — Software Restriction Policies (Политики ограничения программ).

Что же такое Software Restriction Policies?

С помощью SRP можно создать “белый список” программ, которые заведомо разрешены для запуска; все остальные программы будут заблокированы. Например, мы говорим системе “запускай всё из папок C:\Windows, C:\Program Files, D:\Games, а остальное не разрешается”. В результате, приезжающий на флешке вирус тихо «обламывается», не сумев запуститься с неразрешённого пути E:\ или Z:\. Что-то попыталось пролезть с ненадёжного веб-сайта? Оно тоже не запустится, так как было сохранено в папке профиля пользователя Temporary Internet Files или %Temp%. А мы оттуда ничего запускать не разрешали! Присланный посредством Skype «новый супер-пупер скринсейвер», на самом деле представляющий собой троянскую программу, тоже не запустится.

Политика Software Restriction Policies сильно выигрывает в сравнении с любыми тормозяще-навороченными, но в то же время очень ненадёжными антивирусными программами, будь то Kaspersky, NOD или Avast (название и производитель не имеют значения). Ловля блох антивирусным монитором — компьютерный аналог «русской рулетки». Причём, далеко не факт, что вы в ней выиграете. В то же время, SRP сразу же отбросит всё неразрешённое, не вникая, что это там было, хорошее или плохое.

На самом деле, политика не предотвратит сохранение тела вируса на жёстком диске. SRP — не антивирусная программа, она не анализирует содержимое файлов. Но и запуститься хранящейся на диске или flash-носителе потенциально деструктивной программе она не позволит.

SRP не нужно откуда-то скачивать, она уже встроена в следующие системы Microsoft:

  • Windows XP Professional, Windows XP Media Center 2005;
  • Windows Vista Business, Windows Vista Enterprise & Ultimate;
  • Windows 7 Professional, Windows 7 Enterprise & Ultimate;
  • Windows Server 2003 и 2008 (все редакции);

К сожалению, никакие системы из серии Windows Home не поддерживаются.

Как включить и настроить политику SRP?

Для включения SRP зайдите в систему с правами администратора и выполните команду Start → Run → gpedit.msc. В разделе Computer Configuration (Конфигурация компьютера) раскройте папку Windows Settings → Security Settings → Software Restriction Policies.

Читайте также:  Outlook 2010 настройка отчета о прочтении

Рисунок 2. Включение политики SRP

На всех упомянутых ранее версиях Windows это окно выглядит примерно одинаково. Однако, в политиках домена Active Directory вы можете найти SRP и в разделе User Configuration (Конфигурация пользователя). Я рекомендую выполнять базовую конфигурацию SRP на уровне Computer Configuration, а User Configuration использовать только для расширения области действия политики для некоторых групп пользователей.

Щёлкните правой кнопкой по папке Software Restriction Policies и выберите команду Create New Policies. Политика создана, теперь нужно сделать дополнительные настройки. Выполните двойной щелчок по значению Enforcement и укажите Apply to: All software files и Apply to: All Users. Тем самым, проверке будут подлежать все программы и динамические библиотеки, и защищены будут все пользователи, включая самых опасных — администраторов.

Параметр Apply to: All software files может оказаться неприменимым для вашей системы, если используются приложения, вызывающие dll-модули некорректными методами либо хранящие множество своих модулей в профилях пользователей. Чтобы облегчить управление такими приложениями, можно ослабить уровень защиты, переключив настройку в положение Apply to: All software except libraries. Однако, учтите, что количество зловредных программ, выполненных в виде динамических библиотек и вызываемых строкой вида rundll32.exe C:\Recycler\virus.dll, неуклонно растёт. И только более строгая, полная фильтрация позволяет защитить систему от крайне опасной проблемы, носящей название DLL Hijacking.

Рисунок 3. Настройка области действия политики SRP

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

Рисунок 4. Настройка обрабатываемых политикой SRP типов файлов

Существуют несколько режимов работы SRP:

  • Disallowed: режим «белого списка». По умолчанию, запрещён запуск любых программ, кроме описанных в правилах политики;
  • Basic User: режим принудительного ограничения привилегий. Все программы запускаются с привилегиями рядового пользователя, кроме исключений, описанных политикой;
  • Unrestricted: режим «чёрного списка». По умолчанию, разрешается запускать любые программы, кроме отдельно заблокированных в правилах политики.

Раскройте папку Security Levels и назначьте режим Disallowed в качестве основного.

Рисунок 5. Включение режима «белого списка» политики SRP

В контейнере Additional Rules перечисляются программы, которые мы разрешаем запускать. Обычно особого внимания это от нас не требует, так как политика автоматически указывает, что все программы, находящиеся в Program Files и Windows, разрешены для запуска. Таким образом, большинство программ будет работать нормально, а стандартные пользователи не имеют прав на изменение содержимого этих папок. Однако, если ваши программы установлены в иные каталоги, добавьте в список дополнительные разрешённые пути или хэш-суммы исполняемых модулей в режиме Unrestricted.

По возможности, не добавляйте в Additional Rules пути, которые открыты рядовым пользователям для Записи. «Белый список» Software Restriction Policies позволяет защитить систему не только от случайно приносимых вирусов, но также от других нежелательных программ — например, чат-клиентов, игр, альтернативных браузеров. Ни в коем случае не добавляйте в Additional Rules пути вида C:\, %Temp% илиF:\ (путь к сменному носителю) с типом доступа Unrestricted, так как это аннулирует весь эффект политики.

Рисунок 6. Настройка списка разрешённых для запуска программ

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

Что делать, если что-то перестало работать?

Существует вероятность, что самая важная для вас программа перестанет работать из-за блокировок, налагаемых политикой SRP. В этом случае, вам на помощь приходит системный журнал, с содержимым которого можно ознакомиться, выполнив команду Start → Run → eventvwr.msc.

Рисунок 7. Просмотр журнала событий Application

Если действительно SRP является причиной неработоспособности программы, вы увидите в журнале одно или несколько предупреждений от источника SoftwareRestrictionPolicies с кодом 865. Внутри сообщения указывается имя и путь заблокированного модуля. Добавьте этот путь или цифровой отпечаток (hash) программы в Additional Rules и запустите программу ещё раз.

Читайте также:  Настройка зажигания на карбюратором ваз 21074

Теперь всё работает, но что будет дальше?

Иногда вам придётся устанавливать новые программы, а также обновлять их и саму систему. Для этого политику SRP нужно временно отключать. Создайте два файла, которые помогут вам облегчить отключение/включение SRP, и сохраните их в папке Windows:

SRP_Disable.reg

SRP_Enable.reg

На самом деле, значение DefaultLevel не отключает политику, а переводит её из режима «белого списка» Default: Disallowed в режим «чёрного списка» Default: Unrestricted, разрешая запуск любых программ, кроме тех, что описаны в контейнере Additional Rules в режиме Disallowed. По возможности, не создавайте записи с типом доступа Disallowed, так как это осложняет работу с политикой.

Создайте ярлыки на reg-файлы на рабочем столе Администратора. Процедура установки новых программ усложняется лишь ненамного по сравнению с тем, как вы привыкли это делать:

  • отключаем защиту SRP ярлыком SRP Disable;
  • инсталлируем программу или выполняем обновление системы;
  • снова включаем SRP ярлыком SRP Enable.

Рисунок 8. Ярлыки управления режимами SRP

Возможно, поначалу вы будете забывать включать политику после установки программ. Можно настроить систему таким образом, чтобы вручную отключенная защита включалась снова через регулярные интервалы времени. Запустив программу gpedit.msc, в секции Computer Configuration откройте папку Administrative Templates -> System -> Group Policy и в параметре Registry Policy Processing выберите Enabled и включите галочку Process even if the GPO have not changed. В любом случае, после перезагрузки компьютера Software Restriction Policies включится автоматически.

Software Restriction Policies не гарантирует стопроцентную защиту от зловредных программ, но её эффективность может быть по крайней мере на несколько порядков выше эффективности обычных антивирусных программ. Успехов в повышении уровня безопасности вашего компьютера!

Источник

Обход некоторых видов ограничений запуска приложения через механизмы Software Restriction Policies (в режиме Unrestricted) в групповых политиках Active Directory

Некоторые администраторы применяют в своей инфраструктуре Active Directory (AD) функционал Software Restriction Policies (SRP), имеющийся в составе Group Policy, для того, чтобы явным образом ограничивать запуск и исполнение каких-либо приложений. То есть используется сценарий ограничительных мер по типу «разрешено всё, кроме того, что явно запрещено». Например, в рамках мероприятий по противодействию новомодным комплексным шифровальщикам, у некоторых администраторов может возникнуть желание явно запретить запуск некоторых исполняемых файлов, используемых вредительским ПО, не запрещая при этом запуск всех прочих приложений и не используя механизмы проверки цифровых подписей.

В данной заметке мы поговорим о том, почему мероприятия подобного рода могут оказаться малоэффективны, наглядно продемонстрировав пример того, как любой непривилегированный пользователь может без особых сложностей обойти некоторые механизмы защиты. В качестве наглядного примера мы рассмотрим ситуацию с запретом исполнения небезызвестной утилиты PsExec из пакета PsTools Sute .

Итак, предположим, что администратор домена настроил общую для всех компьютеров политику, в которой в разделе Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies > Additional Rules несколькими правилами запретил запуск утилиты PsExec по двум критериям – Path и Hash. То есть при запуске приложений проверяется, как путь так и хеш файла

При этом в Security Level администратор выбрал режим работы SRP — Unrestricted, то есть разрешено всё, кроме исключений, описанных в Additional Rules

Назначив такую политику на доменные компьютеры, администратор выполняет попытку запуска утилиты PsExec, и убедившись в том, что система вещает о невозможности запуска — » This program is blocked by group policy. For more information, contact your system administrator «, считает свою задачу выполненной.

Спустя некоторое время возникает ситуация, в которой на каком-то условном доменном компьютере, условный пользователь и отъявленный проказник Петя Резинкин, хочет во чтобы то ни стало воспользоваться выше обозначенным приложением. Но совершенно справедливо этот пользователь получает от системы «отлуп»:

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

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

Читайте также:  Простейший прибор для настройки спутниковой антенны

Чтобы продемонстрировать простоту и доступность этого метода, в первую очередь нашему Пете потребуется цифровой сертификат с поддержкой Code Signing (1.3.6.1.5.5.7.3.3).

Получение Code Signing сертификата

Получить Code Signing сертификат можно разными путями. Если администратор доменных служб сертификации AD любезно предоставил всем желающим использовать шаблон сертификата, в котором есть поддержка Code Signing, то Петя сможет получить сертификат, которому любая доменная система уже будет отчасти доверять. С другой стороны, если нет необходимости заморачиваться с доверием сертификату (если проверка подписания исполняемых файлов не обязательна), то нашему Пете вполне подойдёт самоподписанный сертификат, который он способен сделать и установить в своё хранилище личных сертификатов без чьей-либо помощи и без необходимости иметь какие-то административные привилегии.

Если Петя сидит на модной Windows 10, где администратором домена не запрещено использовать PowerShell, то создать само-подписанный сертификат нужного типа – вопрос вызова буквально одного командлета:

В результате такого запроса будет сгенерирован самоподписанный сертификат с правом подписывания кода сроком действия в 25 лет. Созданный сертификат автоматически будет помещён в хранилище личных сертификатов пользователя.

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

А если система у нашего Пети более старая, чем Windows 10, или администратор настолько коварен, что ограничил доступ к оболочке PowerShell, то можно прибегнуть к помощи старой доброй «on-board» утилиты certreq.

Создаём конфигурационный файл запроса по типу:

Выполняем запрос, указав конфигурационный файл:

В результате выполнения такого запроса сертификат будет сгенерирован и также автоматически установлен в личное хранилище сертификатов пользователя

Итак, нужный сертификат имеется. Далее нам потребуется любой инструмент, который умеет работать с цифровыми подписями исполняемых файлов Windows.

Подмена цифровой подписи

Для работы с цифровой подписью существуют разные утилиты, но мы по традиции выбираем ту, которая «родней» с точки зрения вендора – утилита SignTool. Эту утилиту можно найти в составе Visual Studio или Windows SDK (например, для SDK Windows 8.1 x64 эту утилиту можно найти в каталоге C:\Program Files (x86)\Windows Kits\8.1\bin\x64 ). Подробней о работе этой утилиты можно почитать здесь .

Посмотреть текущие цифровые подписи интересующего нас приложения можно командой:

либо, просто заглянув в графической оболочке Windows Explorer в свойства интересующего нас исполняемого файла на вкладку Цифровые подписи:

Теперь Пете остаётся только заменить имеющуюся цифровую подпись собственной:

В ходе выполнения команды, для подписи указанного файла из личного хранилища сертификатов пользователя автоматически будет выбран наиболее подходящий сертификат (опция /a), а прежняя цифровая подпись файла будет заменена подписью пользователя:

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

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

В конечном результате Петя может запускать приложение.

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

Для тех, кто ещё только собирается внедрять SRP или хочет навести у себя в этом порядок, весьма полезными могут отказаться русскоязычные статьи Vadims Podans: Sysadmins LV — Software Restriction Policies .

Источник

Adblock
detector