Использование политик ограниченного использования программ

Политики SRP имеют 3 уровня безопасности, которые отображены в Security Levels:

• Disallowed – запрещено всё, кроме исключений в Additional Rules.
• Unrestricted – разрешено всё, кроме исключений в Additional Rules.
• Basic User – то же самое, что и Unrestricted, только дополнительно включает запрет запуска приложений с повышенными привилегиями.

Рисунок 1. Внешний вид консоли управления политикой Software Restriction Policies

Далее следует объект Enforcement (см. рис. 2). В этом окне можно форсировать применение политики не только к исполняемым файлам, но и к связанным с ними библиотекам DLL. Включение данной опции может значительно повысить нагрузку на систему, так как при запуске приложения через политику проходят и все файлы библиотек, из-за чего расходуется и время, и процессорные мощности.

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

Настраиваем SRP на примере Windows Server Standart 2008 R2

Рисунок 2. Окно выбора степени воздействия политики SRP. Настройки этого окна влияют на глобальную эффективность политик SRP

Чуть ниже предлагается выбор применения политики для всех пользователей без исключения или для всех пользователей, кроме членов группы Administrators.

Здесь хочу отметить, что при включенном UAC (User Account Control) локальные администраторы не выводятся из-под действия политики SRP и освобождаются от фильтрации только приложения, которые запущены с использованием повышенных привилегий. Также в доменной среде данная опция доступна только в секции Computer Configuration редактора групповых политик.

И последняя опция – Enforce Certificate Rule. На практике правила сертификатов редко используются, и зачастую есть смысл отключить их проверку, что приведет к ускорению обработки политики.

Следом идёт элемент Designated File Type. Здесь перечислен список расширений файлов, которые контролируются Software Restriction Policies. Если пользователям необходимо запускать (или запрещено запускать) файлы с указанными в этом списке расширениями, то для них нужно составлять исключения для уровня безопасности по умолчанию (об этом подробнее чуть дальше). Данный список можно редактировать под свои условия.

И последний элемент – Trusted Publishers (см. рис. 3). В этом окне регулируются настройки доверенных издателей сертификатов, которыми подписываются приложения. Данное окно актуально, только если используются правила для сертификатов. В остальных случаях оно не используется.

Однако для корректной работы некоторых программ (например, Windows Update в Windows XP/Windows Server 2003) необходимо разрешить управление списком Trusted Publishers для End users (самая верхняя опция).

Рисунок 3. Окно c настройкой прав пользователей для редактирования списка доверенных издателей сертификатов и поведения системы при проверке сертификатов

#13. Настройка групповых политик на Windows Server 2019.

И, наконец, рабочая область – раздел Additional Rules (см. рис. 4). В этом разделе составляются все исключения для действия политики по умолчанию.

Рисунок 4. Основное окно, в котором администратор создаёт правила исключений. Правила создаются нажатием правой кнопки мыши и выбором нужного типа исключения

Можно использовать следующие типы исключений (дополнительных правил) с учётом порядка их применения:

• Certificate Rule – правило для сертификатов. Данный тип правила используется только для подписанных приложений и скриптов. Например, можно разрешить запуск всех приложений, которые подписаны сертификатом Microsoft Corporation, вне зависимости от их расположения и запретить запуск приложений, которые подписаны Adobe Systems. При этом нужно указать сертификаты соответствующих издателей, которые должны быть загружены либо локально, либо на сетевую папку.
• Hash Rule – правило хэша. Для каждого приложения требуется создание отдельного правила. Данный тип правил очень полезен для приложений и файлов, которые находятся в открытых для записи пользователями папках. Например, можно разрешить запуск приложения из папки My Documents (куда пользователь имеет права записи) по хэшу. В таком случае гарантируется защита от подмены файла (с таким же именем) или при инфицировании файла вирусом, так как в обоих случаях хэш самого файла изменится и не подпадёт под правило хэша политики SRP и запуск его будет невозможен. В Windows Vista/Windows Server 2008 хранится 2 хэша – MD5 для совместимости с клиентами Windows XP и SHA256, как «родной» алгоритм хэширования новых систем.
• Network Zone Rule – правило зоны сети. В Windows реализовано несколько зон сети, как Интернет, Trusted Sites, Restricted Sites, Local Intranet и Local Computer. Данный тип правил регулирует, какие установочные пакеты разрешены для скачивания исходя из условия их размещения. Для корректной работы правил на основе зон сети установочные пакеты должны быть основаны на Windows Installer (иметь расширение .MSI). Например, можно разрешить скачивание пакетов Windows Installer из зоны Trusted Sites и запретить скачивание из зоны Restricted Sites. Однако следует учесть, что данная политика не влияет на скачивание файлов из браузера Internet Explorer. На практике правила зон сети используются достаточно редко.
• Path Rule – правило пути. Правила данного типа позволяют указывать размещение приложений и файлов, которые не будут проверяться политикой и будут разрешены для запуска. По умолчанию уже созданы два разрешающих правила для системных папок Windows и Program Files. Благодаря этому приложения из данных папок будут разрешены для запуска, если, конечно, не удалить правила вручную (чего делать не рекомендуется). Правила для путей могут настраиваться очень гибко, так как позволяют использовать системные и пользовательские переменные окружения (например, %windir%) и знаки подстановок (например, «?» и «*»). Кроме того, можно указать ключ реестра, из которого будет получен путь.

Практическая реализация на примерах

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

Наиболее эффективным применением политик Software Restriction Policies будет разрешение запуска файлов из папок, куда пользователи не имеют права записи, и запрещение запуска файлов из папок, куда пользователи имеют право записи. В таком случае пользователь гарантированно не сможет запустить файл с рабочего стола (куда он имеет права на запись), но может запустить файл из системной папки Windows (куда обычный пользователь не имеет права записи). Этой схеме наиболее полно отвечает уровень безопасности по умолчанию – Disallowed, которое имеет значение – запретить всё, кроме правил, которые указаны в Additional Rules.

Если применить уровень безопасности по умолчанию Disallowed, то для запуска файлов придётся запускать непосредственно сами файлы в папках, в которых они размещены, так как запуск ярлыков из пользовательского окружения запрещён. Поэтому в Additional Rules необходимо будет создать разрешительные правила, которые позволят запускать ярлыки из Start Menu (это ярлыки, которые отображаются в меню Start и «Start -> All Programs»). Для этого в Additional Rules необходимо создать правила для пути, которые будут указывать на:

Здесь используется системная переменная %username%, вместо которой при работе автоматически будет подставляться имя текущего пользователя. Однако следует учесть, что разрешение запуска ярлыка ещё не значит, что разрешено запускать программу, на которую указывает сам ярлык, еще должно быть разрешающее правило и для самой программы. То есть пользователь не сможет просто изменить путь, на который указывает ярлык для программы в меню «Пуск».

Для этих двух правил необходимо выставить уровень Unrestricted, в результате чего пользователи смогут спокойно запускать ярлыки из меню Start и из вложенных папок первого уровня (например, «Accessories -> Paint.lnk»). Однако для систем Windows XP/Windows Server 2003 и систем с локализацией на других языках эти пути могут изменяться в зависимости от языка системы.

Для унификации работы с папками профилей пользователей политика SRP предлагает возможность чтения значений из реестра. Ветка реестра: HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders содержит пути для большинства пользовательских папок профиля. Для указания пути к Start Menu рекомендуется использовать значения реестра для каждой локальной машины. Чтобы использовать значения реестра, его ключ нужно заключить в знаки процента «%», как это показано на примерах:

%HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell FoldersStart Menu%**.lnk

Для того чтобы разрешить запуск ярлыков из меню быстрого запуска (Quick Launch), нужно добавить правило для пути:

%userprofile%AppDataRoamingMicrosoftInternet ExplorerQuick Launch*.lnk

Таким образом, пользователям уже разрешается запускать ярлыки из меню Start и Programs, при этом абсолютное местоположение меню Start будет определяться каждой машиной индивидуально. Если необходимо разрешить запуск ярлыков или программ из других локаций, то это достигается добавлением правил пути или хэша, как это показано ниже.

Если у вас на диске D: установлено приложение, которое в силу своих особенностей требует разрешения записи в папку с программой для пользователей (увы, но такие приложения до сих пор встречаются, и с ними приходится считаться), то правило пути типа: D:ProgramsSpecProgram*.exe. Или указание имени программы не будет эффективным решением, поскольку пользователю не составит труда переименовать программу и замаскировать под это имя свою любимую игру или заражённый файл. В таких случаях разумнее использовать правила хэша. Если по такому правилу разрешить только необходимые исполняемые (или скриптовые) файлы программы, то при подмене файлов пользователю не удастся запустить ложное приложение, так как хэш нового файла не будет совпадать и файл не подпадёт ни под одно исключение, в следствие чего запуск будет предотвращён уровнем безопасности по умолчанию, то есть Disallowed.

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

Как правило, при реализованных политиках SRP используется общий уровень безопасности Disallowed, который позволяет достаточно комфортно и безопасно работать в системе, но вносит ограничение на некоторые операции, такие как установка новых приложений. На время процесса инсталляции приложений или других админинстративных операций требуется кратковременно отключать действие политики по умолчанию. Делать это в редакторе политик не очень удобно. Но есть и другое решение – временная деактивизация через реестр. Для этого можно воспользоваться тремя .REG-файлами, которые кратковременно изменяют уровень безопасности (только для Windows Vista/Windows Server 2008):

• SRP_Enable – включает уровень политики в Disallowed:

Windows Registry Editor Version 5.00

• SRP _ Disable – включает уровень политики в Unrestricted :

Windows Registry Editor Version 5.00

• SRP _ Basic – включает уровень политики в Basic User :

Windows Registry Editor Version 5.00

Источник: samag.ru

Установка этого устройства запрещена системной политикой

В этом посте перечислены возможные решения ошибки . Установка этого устройства запрещена системной политикой. Обратитесь к системному администратору (The installation of this device is forbidden by system policy, Contact your system administrator) , которого вы можете увидеть. При возникновении этой ошибки процесс установки завершается, отображая это сообщение на экране. Он останавливает установку всех типов программ, таких как драйверы, программное обеспечение, приложения и т. д.

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

Установка этого устройства запрещена системной политикой

Настройка групповых политик ограниченного использования программ в Windows 7

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

Поскольку у меня стоит Windows 7 Professional, первой идеей оказалось использование AppLocker’a, однако быстро выяснилось, что работать в моей редакции винды он не хочет, и требует Ultimate или Enterprise. В силу лицензионности моей винды и пустоты моего кошелька, вариант с AppLocker’ом отпал.

Следующей попыткой стала настройка групповых политик ограниченного использования программ. Поскольку AppLocker является «прокачанной» версией данного механизма, логично попробовать именно политики, тем более они бесплатны для пользователей Windows 🙂

Заходим в настройки:
gpedit.msc -> Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Политики ограниченного использования программ

В случае, если правил нет, система предложит сгенерировать автоматические правила, разрешающие запуск программ из папки Windows и Program Files. Так же добавим запрещающее правило для пути * (любой путь). В результате мы хотим получить возможность запуска программ только из защищенных системных папок. И что же?
Да, это мы и получим, но вот только маленькая незадача — не работают ярлыки и http ссылки. На ссылки еще можно забить, а без ярлыков жить плоховато.
Если разрешить запуск файлов по маске *.lnk — мы получим возможность создать ярлык для любого исполняемого файла, и по ярлыку запустить его, даже если он лежит не в системной папке. Паршиво.
Запрос в гугл приводит к таким решениям: или разрешить запуск ярлыков из пользовательской папки, либо пользовать сторонние бары с ярлычками. Иначе никак. Лично мне такой вариант не нравится.

В итоге мы сталкиваемся с ситуацией, что *.lnk является с точки зрения винды не ссылкой на исполняемый файл, а исполняемым файлом. Бредово, но что ж поделать… Хотелось бы, чтобы винда проверяла не местонахождение ярлычка, а местонахождение файла, на который он ссылается.

И тут я нечаянно натолкнулся на настройки списка расширений, являщихся исполняемыми с точки зрения винды (gpedit.msc -> Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Назначенные типы файлов). Удаляем оттуда LNK и заодно HTTP и релогинимся. Получаем полностью рабочие ярлычки и проверку на местонахождение исполняемого файла.
Было сомнение, можно ли будет передавать через ярлыки параметры — можно, так что все ок.

В результате мы получили реализацию идеи, описанной в статье «Windows-компьютер без антивирусов» без каких либо неудобств для пользователя.

Также для любителей стрелять себе в ногу, можно создать папку в Program Files и кинуть ярлык для нее на рабочий стол, назвав, например «Песочницей». Это позволит запускать оттуда программы без отключения политик, пользуясь защищенным хранилищем (защита через UAC).

Надеюсь описанный метод окажется для кого-то полезным и новым. По крайней мере я о таком ни от кого не слышал и нигде не видел.

• windows
• групповые политики
• безопасность

Источник: h.amazingsoftworks.com