Запретить все приложения по умолчанию (часть 2)

Введение

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

Опасная зона

Прежде чем мы зайдем слишком далеко, важно отметить, что перед внедрением SRP на рабочих компьютерах вы должны тщательно спланировать и протестировать их. Это можно сделать в Active Directory ( AD ), изолировав одну тестовую машину или пользовательский объект в организационной единице ( OU ) или установив разрешение « Применить групповую политику » для объекта групповой политики ( GPO ) только для этой единственной тестовой машины. или -учетная запись пользователя. SRP можно использовать даже на автономных компьютерах, если вы вообще не хотите касаться производственной среды. Я бы порекомендовал вам использовать виртуальные машины для базового тестирования и «производственные» машины для финальных тестов. После интенсивного тестирования SRP следует внедрить на пилотных пользователях в группах — лучше делать маленькие шаги, чем торопиться с катастрофой!

Общий процесс

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

Следующий список дает краткий обзор того, что нужно иметь в виду при внедрении SRP в среде Windows.

При разработке установки SRP необходимо принимать различные решения, например:

• Выберите между объектами групповой политики пользователя и компьютера: к каким объектам AD должны применяться политики SRP?
• Выберите между подходом «черный список» ( BL ) и «белый список» ( WL ) (WL рекомендуется, если это возможно)
• При использовании подхода BL необходимо составить список всего, что не должно запускаться.
• При использовании подхода WL необходимо составить список всего, что должно запускаться.
• Решите, какие параметры SRP использовать (применение, назначенные типы файлов, исключения администратора и т. д.)
• Решите, какой тип правил использовать (путь, HASH, сертификат или интернет-зона).

При тестировании настройки SRP необходимо предпринять различные шаги, например:

• Протестируйте базовые функции в виртуальной лаборатории (используя Virtual PC/Server, VMware и т.п.)
• Протестируйте функциональность в своей среде, используя «производственные» машины (и учетные записи пользователей).
• Протестируйте с небольшими группами пилотных пользователей с шагом 5-10 пользователей в течение нескольких недель, затем увеличьте масштабы.
• Переход к следующей пилотной группе только после успешного внедрения для предыдущих пилотных пользователей.
• Обязательно протестируйте все различные типы пользователей и типы машин, которые необходимо защитить с помощью SRP.
• Обязательно протестируйте сценарии обновления, такие как исправление операционной системы, обновление сторонних приложений, миграция и т. д.
• Также сосредоточьтесь на производительности на различном оборудовании в вашей организации. Реализация SRP в большинстве случаев немного повлияет на производительность системы, в зависимости от того, как она реализована (см. часть о доверенных издателях).
• Иногда приложения запускают другие приложения, убедитесь, что это находится под полным контролем
• По умолчанию ярлыки на рабочем столе и в меню «Пуск» (. LNK ) заблокированы, обязательно измените это при необходимости.
• Убедитесь, что любые сценарии администрирования (например, сценарии входа в общие ресурсы SYSVOL/NETLOGON и т. д.) могут работать.

Прежде чем внедрять SRP в производство, необходимо провести некоторые процедуры:

• Внедрить письменный рабочий процесс о том, как приложения, обновления и т. д. должны тестироваться, утверждаться и внедряться в сеть, чтобы все знали о необходимых процедурах.
• Убедитесь, что руководство знает плюсы и минусы SRP и что они согласны с решением о его введении.
• Имейте запасной план, как быстро избавиться от объектов групповой политики SRP для определенных пользователей, групп, компьютеров, сайтов и т. д.
• Обучение пользователей: информируйте пользователей, почему SRP важен и какова процедура приобретения нового программного обеспечения.
• Небольшой совет: поместите описания в правила SRP, со временем правильное соглашение об именах сэкономит вам время.

Различные пути к SRP

Настройка политики ограниченного использования программ в основном состоит из нескольких шагов:

1. Создание объекта групповой политики «Пользователь» или «Компьютер» и размещение его на сайте, в домене или организационной единице (или в качестве локальной политики) и включение SRP в рамках групповой политики. Настройки SRP находятся здесь (см. рис. 1):
   Конфигурация компьютера| Параметры Windows | Настройки безопасности | Политики ограниченного использования программ
   Конфигурация пользователя | Параметры Windows | Настройки безопасности | Политики ограниченного использования программ
   
   При первом внедрении SRP в GPO будет доступна опция « Новые политики ограниченного использования программ ».

фигура 1

2. Установка уровня безопасности по умолчанию. На рис. 2 показано, как задается уровень, если щелкнуть правой кнопкой мыши желаемый уровень и выбрать « Установить по умолчанию ».

   • Уровень по умолчанию — « Неограниченный », что означает, что любое программное обеспечение может работать и что должны быть установлены дополнительные правила для запрещенного программного обеспечения — это также известно как «черный список».
   • Самый безопасный уровень — « Запрещено », что означает, что ни одно программное обеспечение не может работать и что должны быть установлены дополнительные правила для разрешенного программного обеспечения — это также известно как «белый список».
   • По умолчанию система создает несколько правил, которые позволяют операционной системе работать без каких-либо неудобных блокировок.
     Черт! Если эти правила будут бездумно удалены или изменены, затронутые системы могут стать непригодными для использования.
     

   
   

фигура 2

3. В Windows Vista и Longhorn у нас появился новый уровень под названием « Обычный пользователь », который позволяет запускать программы от имени пользователя, не имеющего прав администратора, поэтому пользователь может получить доступ к ресурсам, доступным только обычным пользователям. Этот уровень больше не рассматривается в этой статье.

   Типы файлов можно удалять и добавлять в соответствии с любой средой, но список типов файлов по умолчанию включает наиболее распространенные исполняемые файлы: BAT, CMD, COM, EXE, HTA, LNK, MSI, OCX, PIF, REG и SCR, а также эти расширения.: ADE, ADP, BAS, CHM, CPL, CRT, HLP, INF, INS, ISP, MDB, MDE, MSC, MSP, MST, PCD, SHS, URL, VB и WSC.

   Примечание. Как указано в диалоговом окне «Свойства назначенного типа файлов», список «в дополнение к стандартным типам программных файлов, таким как EXE, DLL и VBS» — мне не удалось получить их полный список, но я подтвердили, что VBS, VBE, JS и JSE заблокированы, хотя их нет в списке. Я бы предпочел, чтобы единый список администраторов по всему миру мог меняться по мере необходимости, но это так.

Рисунок 3

4. Настройка исключений для уровня безопасности по умолчанию. Они известны как « Дополнительные правила ». Дополнительную информацию см. в теме «Дополнительные правила» в этой статье.
5. Настройка « Свойства принудительного применения ». См. рис. 4, сюда входят:

   • « Все файлы программного обеспечения »: у нас есть возможность проверять библиотеки DLL (библиотеки динамической компоновки), когда они также выполняются. Это не настройка по умолчанию, и она будет иметь некоторое влияние как на производительность, так и на задачи планирования/реализации/обслуживания.
   • « Все пользователи, кроме локальных администраторов »: здесь мы можем выбрать, следует ли применять SRP для локальных администраторов. По умолчанию все пользователи попадают под SRP. Этот параметр политики применим только к политикам компьютеров.
   • « Применить правила сертификата »: возможность выбрать, следует ли применять правила сертификата. Примечание. Как указано в диалоговом окне на рис. 4, «правила сертификатов отрицательно скажутся на производительности вашего компьютера».

Рисунок 4

6. Настройка « Свойства доверенных издателей », также известных как параметры политики Authenticode (см. рис. 5). В этом диалоговом окне мы можем выбрать, кто должен иметь возможность выбирать доверенных издателей для правил сертификатов. У нас также есть возможность проверить, отозван ли сертификат или нет, и/или проверить, действительна ли отметка времени при ее добавлении.

Рисунок 5

Дополнительные правила

При настройке дополнительных правил следует определить метод или несколько методов идентификации программного обеспечения. У нас есть 4 различных метода идентификации программного обеспечения:

1. HASH-правила
   HASH — это криптографические отпечатки пальцев, которые остаются независимо от имени файла и его местоположения. Они особенно хороши при использовании WL, но не так эффективны при BL (причина этого частично описана в примере с ProduKey в моей первой статье SRP): ХЭШ MD5 или SHA-1 дает надежную программную идентификацию «ProduKey.exe». ' двоичный файл, поэтому разрешение запуска определенного значения HASH гарантирует, что может работать только эта версия исполняемого файла. Однако запрет определенного HASH влияет только на одну версию (или компиляцию) приложения, и опытный пользователь может довольно легко изменить файл, чтобы он был идентифицирован как другая (неизвестная) часть программного обеспечения. Слово «неизвестно» очень важно в этом вопросе — это действительно ключ к выбору между BL или WL — хотим ли мы, чтобы пользователи могли запускать программное обеспечение, которого мы не знаем, да или нет?
   Если пользователи не должны иметь возможность запускать старую версию определенного приложения, допустим, оно «глючит» и вызывает сбои системы, использование правила «запретить это значение HASH» будет хорошим решением. Имейте в виду, что новая версия данного приложения всегда приводит к новому значению HASH, которое должно быть разрешено или запрещено.
2. Правила сертификата
   Правила сертификатов используют подписанные хэши и обеспечивают очень надежную идентификацию программного обеспечения, но поскольку мы доверяем данному сертификату, мы фактически доверяем всему программному обеспечению, подписанному этим конкретным сертификатом. Это может быть хорошо или плохо. Хорошо, если мы, например, получим приложение от стороннего поставщика, который подписал все значимые файлы в приложении (возможно, включая библиотеки DLL), поэтому вместо того, чтобы создавать заданное количество правил HASH, мы можем просто создать одно правило. который доверяет сертификату, и мы готовы к работе. Но, скажем, я доверяю цифровому сертификату, используемому для подписи какого-либо инструмента от Microsoft (или любого другого поставщика программного обеспечения) — теперь мои пользователи могут запускать все приложения, подписанные этим конкретным сертификатом… Хм, так что проблема в том, чтобы точно знать, какие приложения были подписаны этим сертификатом? Без этого знания мы не знаем, что мы позволили. Вместо того, чтобы разрешать только одно приложение, которое нам нужно для наших пользователей, мы могли бы позволить сотням приложений от поставщика работать на наших системах.
   Протестировать правила сертификата можно с помощью следующих инструментов: Средство подписи файлов (Signcode.exe) и Средство создания сертификата (Makecert.exe).
3. Правила пути
   Правила пути — это наиболее распространенные и «простые в использовании» правила, которые у нас есть. Правила пути могут запрещать или разрешать размещение файла в указанном месте (например, « C:ScriptsScript.VBS »), имени файла (например, « Script.VBS »), папке (например, « C:Scripts »), UNC- путь (например, « \SERVERSHAREFile.VBS ») или путь реестра (например , «%[Реестр Куст][Имя раздела реестра][Имя значения]% »). Правила пути могут использовать переменные среды (например, « %WINDIR% ») и подстановочные знаки ' ? ' = один символ (например, " \SERVER??ShareScript.VBS ") и ' * ' = любое количество символов (например, " *.VBS ").
   Если вы используете правила пути, необходимо решить несколько вещей:

   • Если указан заданный путь к папке, это также влияет на все исполняемые файлы во всех подпапках.
   • Если у пользователя есть доступ на запись к папке, для которой задано значение Unrestricted, пользователь может скопировать любой файл в этот каталог и выполнить его оттуда. Дизайн должен позаботиться об этой проблеме, возможно, путем введения настроек ACL (списка управления доступом) с использованием групповых политик.
   • Если у пользователя есть доступ на запись к исполняемому файлу, указанному как Unrestricted, пользователь может перезаписать этот исполняемый файл другим, чтобы обойти SRP.
   • Если путь к папке включает переменные среды, такие как %TEMP%, даже ограниченный пользователь может изменить переменные среды пользователя с помощью команды SET на другой путь ( SET TEMP=C:MyFolder ) — и внезапно пользователь может контролировать, какое программное обеспечение может запускаться путем копирования исполняемых файлов или сценариев по этому пути.

   Как указано выше, пользователи могут попытаться переименовать или переместить запрещенные файлы или перезаписать неограниченные файлы, чтобы обойти SRP, поэтому правила HASH или сертификатов обычно считаются «лучшим выбором».

4. Интернет-зона
   Зоны безопасности Internet Explorer могут использоваться для управления установкой программного обеспечения и применяются только к пакетам установщика Windows ( .MSI ), которые запускаются из одной из зон Интернета по умолчанию. Эти правила используются не так часто.
   Когда используется несколько правил, они оцениваются в порядке, указанном выше, правило по умолчанию будет оцениваться как последнее правило — наиболее точное совпадение будет иметь приоритет.

Ограничения SRP

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

• Установлены драйверы или другое программное обеспечение режима ядра
• Любая программа, выполняемая локальной учетной записью SYSTEM
• Макросы внутри документов Microsoft Office (у нас есть другие способы заблокировать их с помощью групповых политик)
• Программы, написанные для общеязыковой среды выполнения (эти программы используют политику безопасности доступа для кода)

Вывод

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

Для внедрения политики «Запрет по умолчанию» требуются самоотверженность, понимание и тяжелая работа — возможно, поэтому это редко делается… Одно можно сказать наверняка: правильное внедрение таких политик обеспечит сетевым администраторам гораздо лучший сон по ночам..

В течение следующих нескольких лет будет интересно посмотреть, продолжит ли Microsoft развивать эту часть среды групповой политики — или появится что-то еще лучшее, кто знает…

внешние ссылки

KB 324036 Как использовать политики ограниченного использования программ в Windows Server 2003

Technet: Использование политик ограниченного использования программ для защиты от несанкционированного ПО (Vista/Longhorn)

Technet: политика ограниченного использования программ для клиентов Windows XP

Запретить все приложения по умолчанию (часть 1)