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

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

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

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

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

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

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

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

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

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

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

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

"Чтобы перечислить все папки с правами записи пользователей вы можете использовать, например, утилиту AccessEnum из пакета Sysinternals ». (или AccessChk).

Документ АНБ дает 16 примеров папок в черный список с помощью SRP (хотя правила пути реестра используют обратную косую черту неправильно, поэтому необходимо исправить - см. пункт о путях реестра ниже) и предупреждает о распространенной чрезмерно широкой записи в черном списке.

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

  1. Использование переменных среды, например %systemroot%, Пользователи могут обойти SRP, очистив переменную среды. Они не используются в предлагаемых значениях по умолчанию. Однако они могут быть соблазнительными. Эта ножка исправлена ​​в AppLocker, потому что она никогда не смотрит на переменные среды.
  2. Предлагаемые значения по умолчанию игнорируются, чтобы учесть два разных \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%
  3. Расширения по умолчанию не запрещают сценарии PowerShell (* .PS1), поддерживаемые Windows.. (Видеть видео). И APPX тоже. Также, согласно сравнительной таблице Microsoft, SRP не может управлять «упакованными приложениями» в Windows 8; Я без понятия что это значит.
  4. Правила пути реестра не должны иметь косую черту сразу после последнего знака процента (несмотря на то, что они включены в собственные встроенные правила Microsoft для XP / Server 2003), и любые обратные косые черты должны быть заменены косыми чертами вперед, чтобы правило работало (1/2/3).
  5. Из источников, которые я нашел для SRP, ни один не собрал для вас полный список выше. А статью Вадима Поданса я обнаружил случайно. Что еще там скрывается?
  6. Многие источники рекомендуют просто удалить файлы LNK из списка. (И веб-ярлыки, чтобы не нарушать избранное ?!). Вызывает тревогу то, что источники не обсуждают уязвимости LNK ... или получение интерпретаторов сценариев для запуска файлов с неожиданным расширением, например wscript /e... или, может быть, добавление достаточного количества шелл-кода во встроенный параметр скрипта ... и т. д.
  7. Если вы попытаетесь пойти на компромисс, разрешив файлы LNK на рабочем столе, и оставите пользователям право записи на рабочий стол, теперь они могут полностью обойти вашу политику. И снова прекрасный отзыв от Вадима Поданса. Обратите внимание, что объяснение относится к использованию любого расширения в правиле пути. Microsoft представляет несколько примеров этого, включая *.Extension, без предупреждения. Так вы не можете доверять официальной документации, и сейчас это вряд ли удастся исправить.
  8. [Возможный недостаток 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. См. Пункт 7 :).
  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. Объекты групповой политики с правилами БЕЗОПАСНОСТИ могут быть прикреплены к пользователям и группам пользователей; 2. В Windows Vista появилось несколько локальных объектов групповой политики, которые достигают того же результата без контроллера домена; 3. Режим аудита доступен через расширенную функцию ведения журнала без принудительного применения.

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

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

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