Назад | Перейти на главную страницу

исключение групповой политики для запрещенного

Я пытаюсь настроить групповую политику в домене, чтобы заблокировать cryptolocker (среди прочего). Я в основном слежу за Cryptolocker Prevention Kit (http://community.spiceworks.com/topic/396103-cryptolocker-prevention-kit-updated). Используя DC 2008R2.

Однако мне нужно сделать исключение для Firefox, так как установки - это 7zip-архивы exe, которые заблокированы. Я добавил исключение, сделал "gpupdate / force" на тестовой машине (Win 7), а затем перезагрузился. Но исключение игнорируется. Вот соответствующий фрагмент из GPMC:

%LocalAppData%\Temp\7z*\*.exe 
Security Level Disallowed 
Description Block executables run from archive attachments opened with 7zip 
Date last modified 11/8/2013 10:56:08 AM 

%LocalAppData%\Temp\7z*\setup.exe 
Security Level Unrestricted

Эти политики находятся в глобальной политике машин, если это имеет значение. Фактически блокируемый файл -% LocalAppData% \ Temp \ 7zSE455.tmp \ setup.exe согласно программе просмотра событий. "SE455" в 7zSE455.tmp изменяется, поэтому я не могу это жестко закодировать.

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

Если я удалю первую политику / правило выше, сделаю танец перезагрузки gpupdate, тогда он заработает, значит, это ЯВЛЯЕТСЯ это правило блокирует меня.

По моим оценкам, Unrestricted должен иметь приоритет перед Disallowed. Так почему же меня до сих пор блокирует групповая политика?

Изменить: технический документ (http://technet.microsoft.com/en-us/library/bb457006.aspx) указывает, что более конкретное соответствие правилу заменяет менее конкретное соответствие правилу. В моем случае выше, setup.exe ЯВЛЯЕТСЯ более конкретный, чем * .exe. Итак, я ошибался насчет неограниченного отмены запрета, но мои правила ДОЛЖЕН все еще работает, как ожидалось. К сожалению, нет.

Приведенный выше технический документ правильный, но неясный. Правила пути действительно основаны на папках. Например, вы хотите заблокировать c: \ temp \ xyz \ *. Exe, но разрешить c: \ temp \ xyz \ setup.exe. Если правилом блокировки является c: \ temp \ xyz \ *. Exe, разрешающее правило будет проигнорировано. Это потому, что «Если к программному обеспечению применяются два идентичных правила с разными уровнями безопасности, более консервативное правило имеет приоритет».

Идентичный здесь означает ту же папку / путь. Поскольку ДОРОЖКА в c: \ temp \ xyz \ *. exe - это c: \ temp \ xyz, а путь в c: \ temp \ xyz \ setup.exe также c: \ temp \ xyz, они считаются идентичными правилами. Даже c: \ temp \ x * \ *. Exe будет считаться тем же путем, поскольку c: \ temp \ x * может соответствовать c: \ temp \ xyz. Да, мне это тоже кажется багом, но так оно и есть.

Чтобы запустить setup.exe, у вас есть два варианта:

Создайте правило хеширования для setup.exe. Правила хеширования всегда имеют приоритет над правилами пути. Они также довольно безопасны и довольно просты в установке в Server 2008R2. Просто создайте новое правило хеширования и перейдите к файлу. Он создает для вас хеш. Это также позволяет этой установке запускаться с ЛЮБОГО пути, независимо от других правил пути, которые у вас могут быть. Обратной стороной является необходимость обновления правила хеширования при каждом изменении setup.exe. Вы также должны внести каждый файл в белый список.
Измените правило запрета c: \ temp \ x * (или c: \ temp \ x * \ *. Exe, или c: \ temp \ x *) на c: \ temp. После завершающего \. Но он не переопределит конкретную папку, поэтому c: \ temp \ xyz \ в неограниченном правиле будет работать правильно. Однако это новое правило запрета - *. *, Поэтому оно может перехватить другие папки, которые вы не собирались ограничивать, например c: \ temp \ rarc6da \ setup.exe. В этом случае вам понадобится отдельное правило пути для каждого из них.