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


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

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

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

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

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


11
2017-11-09 13:38


Источник


Ограничения на расширение файла несколько бесполезны, поскольку вокруг него существует немало способов. Это может удержать людей, которые не знают, что они делают, но если вы думаете, что это остановит вирию или корпоративный шпионаж, вы лаяете неправильное дерево. Вы видели другие недостатки? - Chris S
Посмотрите здесь: technet.microsoft.com/library/hh994614 - joeqwerty


Ответы:


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

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

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

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

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

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

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

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

  2. Использование переменных среды, таких как %systemroot%, SRP можно обойти пользователями, очистив переменную окружения. EDIT: они не используются в предлагаемых значениях по умолчанию. Однако они могут заманчиво использовать. Этот footgun исправлен в AppLocker, потому что он никогда не смотрит на переменные среды.

  3. Предлагаемые значения по умолчанию не учитывают двух разных \Program Files используется на современных 64-битных установках. При разрешении этого использования более безопасных «путей к реестру» имеются сообщения о ложных отказах в случайных ситуациях, которые можно легко упустить при тестировании. например см. комментарии к SpiceWorks SRP howto, EDIT: Это относится к 32-разрядным приложениям, просматривающим соответствующие пути из WOW6432Node реестра: разрешение заключается в добавлении и то и другое эти пути к SRP позволяют всем программам работать на 32-разрядных и 64-разрядных машинах как Unrestricted, начиная с хоста 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), и любые обратные слэши должны быть заменены forwardslhes, чтобы правило работало (1/2/3).
  6. Из источников, которые я нашел для SRP, ни один не поставил полный список выше для вас. И я случайно обнаружил статью Вадима Подана. Что еще скрывается там?
  7. Многие источники рекомендуют просто удалять файлы LNK из списка. (И веб-ярлыки, чтобы не нарушать избранное?). Как ни странно, ни один источник не обсуждает уязвимости LNK ... или получение интерпретаторов сценариев для запуска файлов с неожиданным расширением, например. wscript /e... или, может быть, набивать достаточно шеллкода в параметре встроенного скрипта ... и т. д.
  8. Если вы попытаетесь пойти на компромисс, разрешив файлы LNK на рабочем столе, и вы оставите пользователей с правом записи на рабочий стол, они теперь могут полностью обходить вашу политику. Прекрасный отзыв от Вадима Подана. Обратите внимание, что это объяснение относится к использованию любого расширения в правиле пути. Microsoft представила несколько примеров этого, включая *.Extension, без предупреждения. Так вы не можете доверять официальной документации, и вряд ли это будет исправлено.
  9. [Потенциальный недостаток AppLocker]. Vadims Podāns сообщает, что записи 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. Убедитесь, что папка сценария входа в систему разрешена. В документе NSA предлагается добавить \\%USERDNSDOMAIN%\Sysvol\, (См. Пункт № 2, вздох, затем см. Пункт № 6).

5
2017-08-07 10:28





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

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

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

1
2017-11-09 13:56





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


0
2018-02-19 18:24



Немного более подробно сделаем это лучшим ответом в будущем. Ссылка может измениться и сделать ответ менее полезным. Устранение некоторых деталей из связанного материала помогло бы - Dave M


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


0
2018-04-23 21:20



Могли бы вы предоставить эти объекты групповой политики, чтобы помочь другим людям реализовать ее? - womble♦


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

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

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


0
2017-08-31 08:02