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

Цель состоит в том, чтобы запретить пользователям запускать нежелательные программы на терминальном сервере.

Я прочитал много статей от Microsoft и других, в которых говорится, что новая функция Applocker на 100% лучше старой политики ограниченного использования программ и рекомендуется в качестве замены последней.

Я не уверен, что понимаю реальные преимущества Applocker помимо выполнения в режиме ядра. Большинство его функций можно воспроизвести с помощью Политики ограниченного использования программ.

В то же время у него есть один БОЛЬШОЙ недостаток, который делает его довольно бесполезным: он не расширяемый, и вы не можете добавлять пользовательские расширения файлов, которые хотите ограничить.

Каковы преимущества Applocker по сравнению с SRP и что бы вы порекомендовали для управления программным обеспечением?

Политика ограниченного использования программ устарела от Microsoft (технически утверждающая, что SRP не поддерживается ), поскольку в Windows 7 Enterprise / Ultimate появился AppLocker.

На практике SRP имеет определенные подводные камни, как для ложных негативов, так и для ложных срабатываний. Преимущество AppLocker заключается в том, что он все еще активно поддерживается и поддерживается. Если AppLocker - это вариант, он может быть дешевле - после учета вашего времени и рисков. Также возможно, что есть подходящая сторонняя альтернатива (но этот вопрос не включал эту опцию :).

Надеюсь, вы получите полное представление о подводных камнях SRP до того, как попадете в любую из них </sarcasm>. Некоторые из них описаны в хорошей статье по безопасности от Вадима Подана .

Известные подводные камни

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

   РЕДАКТИРОВАТЬ: «Для перечисления всех папок с правами записи пользователя вы можете использовать, например, утилиту AccessEnum из пакета Sysinternals». (или AccessChk ).

   Технически документация также предостерегает вас от переопределения правил по умолчанию . РЕДАКТИРОВАТЬ: документ NSA дает 16 примеров папок для черного списка с SRP , хотя правила пути реестра используют обратные косые черты неправильно, поэтому должны быть исправлены (см. Пункт о путях реестра ниже) и предупреждает о распространенной слишком широкой записи в черном списке.

   Очевидный вопрос заключается в том, почему мы не берем \Windowsвместо этого белый список отдельных путей . (Включая \Windows\*.exeнаследство System32\*.exeи т. Д.). Я не заметил никаких ответов на этот вопрос :(.

2. Используя переменные среды, такие как %systemroot%, SRP может быть обойден пользователями путем очистки переменной среды. РЕДАКТИРОВАТЬ: они не используются в предлагаемых по умолчанию. Однако они могут быть заманчивыми для использования. Эта метка исправлена ​​в AppLocker, потому что она никогда не смотрит на переменные среды.

3. Предлагаемые значения по умолчанию не учитывают два разных типа, \Program Filesиспользуемых в современных 64-битных установках. При решении этой проблемы с использованием более безопасных «путей реестра» появляются сообщения о ложных отказах в случайных ситуациях, которые могут быть легко пропущены при тестировании. например, см. комментарии к инструкции SpiceWorks SRP . РЕДАКТИРОВАТЬ: Это связано с тем, что 32-разрядные приложения читают соответствующие пути из WOW6432Node реестра: разрешение состоит в том, чтобы добавить оба этих пути в SRP, чтобы все программы работали на 32-разрядных и 64-разрядных компьютерах как неограниченные, независимо от того, запущены ли они из хост-процесс x64 или x86:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. Расширения по умолчанию игнорируют сценарии PowerShell (* .PS1), поддерживаемые Windows . (Смотрите видео ). И APPX тоже ... также согласно таблице сравнения Microsoft, SRP не может управлять «упакованными приложениями» в Windows 8, я понятия не имею, что это значит.
5. Правила пути реестра не должны быть слэш сразу после последнего знака процента (несмотря на то , включены в Microsoft собственного встроенных правил для XP / Server 2003) и всех обратных косых черт должны быть заменено forwardslashes для того , чтобы правила к работе ( 1 / 2 / 3 )
6. Ни один из источников, которые я нашел для SRP, ни один из них не составил для вас полный список выше. А статью Вадима Подана я обнаружил только случайно. Что еще там скрывается?
7. Многие источники рекомендуют просто удалять файлы LNK из списка. (И веб-ярлыки, чтобы не нарушать избранное ?!). К сожалению, ни один из источников, по-видимому, не обсуждает уязвимости LNK ... или не получает интерпретаторов сценариев для запуска файлов с неожиданным расширением, напримерwscript /e ... или, возможно, вставляет достаточно шелл-кода в параметр встроенного сценария ... и т. Д.
8. Если вы попытаетесь пойти на компромисс, разрешив файлы LNK на рабочем столе, и оставите пользователям доступ для записи на рабочем столе, они теперь могут полностью обойти вашу политику. Прекрасный отзыв от Vadims Podāns снова. Обратите внимание, что объяснение относится к использованию любого расширения в правиле пути. Microsoft представляет несколько примеров этого, в том числе *.Extension, без предупреждения. Таким образом, вы не можете доверять официальной документации , и это вряд ли будет исправлено сейчас.
9. Потенциальный недостаток AppLocker. Вадим Подаш сообщает, что записи SRP, использующие подключенные диски, не работают. Вместо этого должен использоваться путь UNC. Может быть, они будут обращаться к доступу через подключенный диск? это не на 100% ясно. Очевидно, что AppLocker был другим: он не работал ни с одним из них :(. "По неизвестной причине UNC-пути не работают в Applocker! Это означает, что если ваше приложение установлено в сети, вы должны создать правила хэша или издателя «.

Прагматичный подход

Белый список программного обеспечения является потенциально очень мощной защитой. Если мы станем циничными: именно поэтому Microsoft не одобряет более дешевые версии и изобретает более сложные.

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

1. Начните с правил по умолчанию (с эпохи до Win7 :).
2. Предпочитают не использовать переменные среды, например %systemroot%.
3. Добавьте правила, чтобы убедиться, что оба \Program Files\каталога разрешены на современных 64-битных машинах. Дополнительные «пути реестра», которые вам нужно будет добавить \Program Files\на 64-битных компьютерах, - это %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%и %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. При добавлении в правила пути реестра пропускайте обратную косую черту сразу после знака процента и заменяйте любую дальнейшую обратную косую черту \прямой /(например %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Добавьте PS1 в список контролируемых расширений.
6. Поймите, что управляемая конфигурация SRP не защищена от пользователя, решившего ее победить. Цель состоит в том, чтобы помочь / побудить пользователей работать в рамках политики, защитить их от таких атак, как «загрузка с диска».
7. Разрешить файлы LNK. (Желательно, удалив его из списка расширений, а не через какое-то правило пути).
8. Смотри выше :).
9. Убедитесь, что ваша папка сценария входа разрешена. Документ АНБ предлагает добавить \\%USERDNSDOMAIN%\Sysvol\. (См. Пункт № 2, вздох, затем см. Пункт № 6).

Я согласен, что у SRP есть некоторые дополнительные функции, которые AppLocker действительно может извлечь из этого.

При этом я вижу большие преимущества AppLocker (как показано в этом сравнении ):

• Правила AppLocker могут быть нацелены на конкретного пользователя или группу пользователей, тогда как SRP применяется на всем компьютере.
• AppLocker поддерживает режим аудита, так что правила могут быть проверены в производственном режиме до их применения. SRP не имеет эквивалентного режима только для журнала.

Самым большим преимуществом для меня является возможность внесения в белый список подписанных исполняемых файлов издателем. Взгляните на этот http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx

AppLocker не дает никаких преимуществ, опубликованная Microsoft явная ложь: 1. Объекты групповой политики с правилами SAFER могут быть присоединены к пользователям и группам пользователей; 2. Windows Vista представила несколько локальных объектов групповой политики, которые достигают того же результата без контроллера домена; 3. Режим аудита доступен через расширенную функцию регистрации без применения.

Я использую Applocker в моей компании. Стратегия, которую мы используем: Отрицать все как базовый уровень (фактически: значения по умолчанию для Applocker), а затем делать то, что было предложено: создать правило, разрешающее только подписанные приложения (office, adobe, wintools, ax и т. Д.). Большинство, может быть, все вредоносные программы не подписаны, поэтому не будут работать. Это вряд ли какое-либо обслуживание. Мне нужно было разрешить только 3 дополнительных унаследованных приложения.

Далее я не могу подтвердить, что нельзя использовать UNC-пути. В некоторых дополнительных правилах безопасности я успешно использую UNC-путь. Подводный камень заключается в использовании переменных среды: они не работают для Applocker. Используйте * подстановочные знаки. Я использую его на Windows 2008 R2 и Windows 2012 R2.

Мне это очень нравится: практически нет падения производительности. Как сказано в документации: Applocker полагается на службу идентификации приложений (убедитесь, что она запускается автоматически).