Блог системного интегратора

1.    Введение
Недавно консультировал одного крупного и весьма технологичного клиента по вопросу блокировки посторонних приложений на рабочих местах. В результате получился некий шаблон, которым, кажется, стоит поделиться. Изначально речь шла об ограничении списка запускаемых приложений на рабочих столах VDI Citrix XenDesktop, однако, методика может быть с успехом применена в любом доменном окружении, и не только для виртуальных машин.

Операционная система виртуальных рабочих мест была стандартизована - Windows 7 x64, но все сказанное справедливо и для более новых версий Windows. Условие проекта - требовалось по максимуму задействовать штатные средства ОС.

Все системы были в одном домене AD, поэтому имелась возможность применить групповые политики. Я решил для блокировки использовать механизмы SRP (Software Restriction Policies), а не более новые Applocker. Пример практического сравнения технологий – “AppLocker vs Software Restriction Policies”, https://www.sysadmins.lv/blog-ru/applocker-vs-software-restriction-policies.aspx. Требуемый функционал можно реализовать и так, и так, в основу моего выбора легли примерно те же соображения.

2.    “Белый список” приложений

Исходный список приложений, выданный клиентом, был такой:

Согласно архитектуре ОС, установка чрезмерно жестких блокировок на системные каталоги (в частности, %Systemroot% и %ProgramFiles%, нарушает функциональность системы в целом. Поэтому, при создании новой политики блокировки SRP с режимом Disallowed по умолчанию, для ОС Windows Server 2008/2008 R2/Vista/7 и выше, ОС сразу же автоматически создает два исключения реестровых путей:

·         %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%;

·         %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%.

Таким образом, по списку разрешенного ПО (таблица выше), двумя первыми правилами ОС по умолчанию фактически покрываются все рабочие приложения, кроме приложения “Cтатистика CCPulse”. Для него создается явное Unrestricted-правило пути “C:\GCTI\CCPulse*” (символ ‘+’ SRP не воспринимает).

Поскольку эти пути вносятся в “белый” список, что автоматически разрешает запуск почти любого ПО из системных каталогов, для предотвращения запуска из них нелегитимного кода, критично отсутствие у оператора административных прав на ОС (а также на подкаталоги “C:\GCTI\CCPulse*”).

Кроме того, в любой установке ОС Windows 7 с настройками прав файловой системы NTFS по умолчанию, в подкаталогах %Systemroot%, есть ряд директорий, в которые рядовой пользователь (член локальной группы Users) имеет права на запись (например, %Systemroot%\Temp). Для таких каталогов необходимо написать явные SRP-правила пути с режимом Disallowed. При наличии правила Unrestricted для вышележащего каталога (пример - %Systemroot%), и правила Disallowed для подкаталога (пример - %Systemroot%\Temp), запрещающее правило в своей области действия имеет приоритет.

Дополнительное разрешающее реестровое правило пути “%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%”, рекомендуемое Microsoft, не используется, ввиду отсутствия данного каталога в защищаемом образе ОС (система 64-разрядная).

Разрешающее правило пути “\\%USERDNSDOMAIN%\Sysvol\” предназначено для доменных скриптов входа, рекомендовано Microsoft для машин в домене AD, и может требоваться для задач централизованного управления.

Разрешающее (Unrestricted) правило для “*.lnk” является рекомендуемым решением Microsoft для запуска ярлыков из оболочки ОС (shell) Explorer.exe, см. статью “Allowing Shortcuts When Using Software Restriction Policies”, http://www.windowsnetworking.com/kbase/WindowsTips/WindowsServer2008/AdminTips/ActiveDirectory/AllowingShortcutsWhenUsingSoftware­RestrictionPolicies.html. Однако, оно не содержит явной угрозы, так как, если ярлык ссылается на программный код по пути Disallowed, результат запуска успешным не будет. Переименование любого исполняемого модуля в LNK-файл в доверенном, либо недоверенном, пути, с его последующим запуском, также не приводит к успеху (хотя, подобная уязвимость действительно существовала в ранних версиях ОС Windows - в частности, 2000/XP/2003).

SRP-блокировка включена в контейнере Computer Configuration, а не User Configuration для максимальной защиты, независимо от того, кто работает в системе. Кроме того, она включена для всех пользователей, включая локальных администраторов, с помощью параметров Enforcement, и для всех программных модулей и DLL-библиотек. Нужно отметить, что параметр “Apply software restriction policies to the following users – All Users“ задает принудительную блокировку для всех контекстов безопасности (включая Local System). Эта максимальная защита теоретически позволяет заблокировать нелегитимный код, даже если он исполняется с правами операционной системы, однако может создать определенные неудобства в обслуживании образа виртуальной машины VDI, если он подпадает под действие политики. Кроме того, в этом варианте, неправильное Disallowed-правило пути вполне может привести ОС в нерабочее состояние. Поэтому следует соблюдать крайнюю осторожность при модификации политики в производственной среде.

Итоговые параметры политики SRP получились такие:

Политика SRP.

Для сведения, см. cводный документ “National Security Agency. Application Whitelisting using Software Restriction Policies”, https://www.nsa.gov/ia/_files/os/win2k/application_whitelisting_using_srp.pdf.

Существует также сводная печатная работа по теме блокировки и использования минимальных привилегий при работе с клиентскими ОС Windows: ISBN-13 978-1849680042, PACKT Publishing, “Russel Smith. Least Privilege Security for Windows 7, Vista and XP”, http://www.amazon.com/Least-Privilege-Security-Windows-Vista/dp/1849680043. Данная работа рекомендуется к изучению при реализации любых проектов по повышению безопасности использования рабочих мест Windows в корпоративных сетях.

4.    Общие замечания

Методика позволяет неплохо защититься при условии, что приложения не запускаются из пределов пользовательского профиля и других областей с доступом обычного пользователя на запись. На самом деле, запрет запуска кода из профиля – почти обязательное условие для эффективной защиты рабочего места Windows, в том числе, и от ransomware. Однако, это накладывает ряд ограничений на приложения, в том числе, на новые, написанные специально для Windows 8/8.1/10.

Простого решения этой проблемы не существует, если только не использовать правила хэшей для запускаемого кода, или еще что-нибудь в этом роде, а это, в любом случае, чревато дополнительными накладными расходами. Нужно иметь это обстоятельство в виду, если в сети используются такие приложения. Они иногда пишутся программистами и в самой компании – сталкивался, бывает.

Также понятно, что никакие политики блокировки не отменяют требования иметь нормальный антивирус на всех рабочих местах. А наличие в нем самом поведенческого анализатора/блокировщика процессов позволяет выстроить дополнительный уровень защиты – обычно в антивирусах бывают расширенные возможности, которых нет в групповых политиках. Только при составлении антивирусных политик нужно проследить, чтобы эти два уровня между собой не “дрались” из-за функциональных пересечений.

5.    Вариант с локальной политикой для недоменного компьютера

Блокировку SRP можно применять и на отдельно стоящей рабочей станции - в этом случае редактируется стандартный объект Local Group Policy через оснастку Gpedit.msc. Приведенные скрины с моей собственной домашней системы в  рабочей группе, ОС – Windows 10 x64. Немного отступил от собственного правила запрета запуска кода из профиля, но я-то знаю, что делаю:

6.    Пример дополнительной функциональности поведенческого анализатора антивируса

У моего клиента был централизованно управляемый Symantec Endpoint Protection, поэтому, в дополнение к компоненту SRP операционной системы, со стороны антивируса была задействована политика поведенческого анализатора Application and Device Control (управление приложениями и устройствами) SEP. Таких политик в SEP Manager может быть любое количество, для разных групп клиентов, и разных локаций. В приведенном примере, ветвь политики “Управление устройствами” на текущий момент не задействована за ненадобностью, а правила ветви “Управление приложениями” приведены ниже:

Политика SEP “Управление приложениями и устройствами“ (управление приложениями).

В данном примере включена и работает только часть правил. При этом, “Рабочий режим” означает реальную блокировку, а “Тест” – только запись в журналы SEPM на предмет исследования поведения системы на первоначальном этапе внедрения защиты. При необходимости, тестовые правила можно переключить в рабочий режим.

7.    Дополнительные сведения

На сайте поддержки и сообщества Symantec существует много открытых ресурсов, посвященных повышению защищенности ОС Windows штатными и сторонними средствами. В качестве примера приведу ряд статей, посвященных защите от загружаемых вирусов-шифровальщиков:

·         Recovering Ransomlocked Files Using Built-In Windows Tools: http://www.symantec.com/connect/articles/recovering-ransomlocked-files-using-built-windows-tools;

·         Cryptolocker Q&A: Menace of the Year: http://www.symantec.com/connect/blogs/cryptolocker-qa-menace-year;

·         First Response to: Cryptolocker\Ransomcrypt\Encryptor: http://www.symantec.com/connect/articles/first-response-cryptolocker-ransomcrypt-encryptor.

Для примера рассмотрим следующий сценарий, близкий к реальным условиям клиента. Имеется четыре приложения – 1C, Directum, CRM, Invest, для поддержки которых необходимо организовать доступ разных групп службы ТП.

Глобальные группы доступа пользователей к приложениям: DOMAIN\Access_1C, DOMAIN\Access_Directum, DOMAIN\CRM_Access, DOMAIN\Access_Invest;  

Соответствующие (создаваемые в рамках решения) коллекции компьютеров в SCCM: 1C, Directum_5_3, PC_Remote_control_CRM, PC_Remote_control_Invest;

Соответствующие глобальные группы учетных записей пользователей ТП, которым предоставляется доступ к Remote Control для

компьютеров в целевых коллекциях: DOMAIN\SCCM-RC_Access_1C, DOMAIN\SCCM-RC_Access_Directum, DOMAIN\SCCM-RC_Access_CRM, DOMAIN\SCCM-RC_Access_Invest.

Решение строим для этих условий.

3.    Формирование коллекций компьютеров

Механизм сопоставления User Device Affinity требует требует включения в политиках домена параметров аудита Audit account logon events и Audit logon events, как описано в статье “How Automatic User Device Affinity Works in SCCM 2012”, https://blogs.technet.microsoft.com/sudheesn/2015/03/05/how-automatic-user-device-affinity-works-in-sccm-2012. Сбор данных из журналов безопасности осуществляется SCCM автоматически. Порог срабатывания (время работы пользователя в системе, по прошествии которого он становится “Primary User”), контролируется через политику клиента SCCM, раздел “Сопоставление пользователей и устройств”, например, так:


Приступаем к созданию коллекций. Пример для коллекции для компьютеров с CRM:

Коллекция формируется на основе запроса WQL:

Сам запрос WQL:

Идея запроса взята отсюда: “ConfigMgr User Device Affinity (UDA) Collection Query”, https://deploymentramblings.wordpress.com/2017/05/22/configmgr-user-device-affinity-uda-collection-query/. При выполнении этого запроса формируется коллекция компьютеров, основные пользователи (Primary Users в терминологии SCCM) входят в доменную группу DOMAIN\CRM_Access.

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

4. Контроль доступа к Remote Control

Доступ к функции SCCM Remote Control на управляемой системе, в общем случае, контролируется членством в локальной группе "Пользователи удаленного управления Configuration Manager" (в русской версии SCCM). В нее попадают объекты безопасности, прописанные в политике клиента SCCM в разделе “Средства удаленного управления”, параметр “Пользователи средств удаленного управления и удаленного помощника”. При установке значения этого параметра, перечисленные в нем пользователи и группы попадают в локальную группу "Пользователи удаленного управления Configuration Manager" на компьютере, к которому применяется политика. Но, как уже говорилось, эффективная политика – только одна, поэтому нам стандартный механизм помочь не может.

Однако, опытным путем установлено, что если параметр “Пользователи средств удаленного управления и удаленного помощника” в политике клиента SCCM оставить пустым, вот так:

, то клиент SCCM на управляемой системе перестает контролировать требуемую локальную группу вовсе. Это приводит нас к идее реализовать контроль над группой по-другому - например, универсальным централизованным скриптом, запускаемым на клиентской стороне, скажем, периодически по планировщику.

Именно такое решение и было применено – скрипт на WSH с помощью подсистемы WMI подключается к локальным экземплярам классов клиента SCCM, и динамически проверяет принадлежность системы к каждой из анализируемых коллекций, при необходимости добавляя в локальную группу "Пользователи удаленного управления Configuration Manager" операционной системы десктопа требуемую глобальную группу доступа для Help Desk.

“Подводный камень” заключается в том, что простого способа проверить список коллекций, к которым принадлежит компьютер, с помощью локальной подсистемы WMI - нет (по крайней мере, я пока не придумал). Такая проверка возможна только, если подсоединиться по сети к подсистеме WMI самого сервера SCCM. Но очень хочется исполнять скрипт с правами локальной системы, а не сетевой учетной записи - ведь если подсоединяться к SCCM с локальной системы с помощью сетевой УЗ с паролем, это почти наверняка так или иначе приведет к ослаблению системы безопасности. Учетная же запись системы по сети подсоединиться к SCCM для проверки списка коллекций не может - для такого запроса у нее не хватает прав на уровне DCOM, а ослаблять защиту DCOM без крайней необходимости не стоит, по той же причине.

Эта задача решается с помощью переменных коллекции. Пример того, как это реализовано, для уже упомянутой коллекции PC_Remote_control_CRM:

То есть, для каждой проверяемой коллекции (и только для нее одной в рамках инсталляции SCCM), мы дополнительно определяем специальную переменную с префиксом Collection_RC_, с именем и значением, соответствующим имени самой коллекции. Переменные коллекции, в отличие от самого списка коллекций, “спускаются” в локальный WMI клиента при каждом обновлении политики; наличие их в репозитарии WMI мы проверяем программным способом.

Скрипт ManageSCCMRCAccess.vbs приведен в приложении к статье, предоставляется AS IS. Работоспособность проверена на всех версиях Windows, содержащих подсистему WMI, то есть, он гарантированно работает на Windows XP и выше - иначе говоря, на всех системах Windows, для которых существует клиент SCCM. Логика скрипта отражает условия нашей задачи (имена коллекций и групп), но он может быть адаптирован по потребностям для любого количества комбинаций “коллекция-группа доступа”. Для запроса данных SCCM используются классы и методы WMI, для управления локальной группой – интерфейс ADSI. Перед каждой проверкой коллекций производится предварительная чистка группы "Пользователи удаленного управления Configuration Manager". Это сделано для отработки ситуации, когда приложение более не используется (компьютер пропадает из коллекции), это приводит к отзыву права подключения у соответствующей группы ТП. Установка константы DEBUGLOG=True задает протоколирование работы скрипта в простой текстовый лог C:\SCCM_RC_Config.log – включить отладку полезно на случай, если что-то пошло не так.

5. Запуск скрипта

Скрипт размещается в сетевой папке с правами только для чтения для группы Domain Computers, запускается планировщиком Task Scheduler операционной системы раз в час, обнаруженные изменения вступают в силу немедленно. Этого оказалось достаточно, чтобы построить систему управления правами доступа к Remote Control, практически не требующую вмешательства администратора. Единственное, что нужно – добавлять пользователей в глобальные группы доступа к приложениям DOMAIN\Access*, но это как раз та операция, которая контролируется персоналом ИТ.

Никто, кстати, не мешает использовать любые другие способы периодического запуска скрипта, например, с помощью самого SCCM.

Скриншоты задания планировщика приведены ниже, они тривиальны. Задача назначается на целевые рабочие станции с помощью доменного GPO, раздел “Preferences”:

• Все ссылки на реальную инфраструктуру клиента в скрипте и скриншотах изменены;
  
• Решение тестировалось в среде SCCM 2012 R2, но оно полностью применимо и к SCCM 2016 – основные подсистемы в новой версии почти не поменялись;
  
• Для анализа объектов WMI в системе Windows, из известных мне средств, удобнее всего использовать утилиту WMI Explorer от CodePlex, см. https://archive.codeplex.com/?p=wmie.
  

• “Client Push Installation change in Configuration Manager 2012 and how to take advantage of this change for troubleshooting purpose”, http://blogs.technet.com/b/neilp/archive/2012/07/03/client-push-installation-changes-in-configuration-manager-2012-and-how-to-take-advantage-of-these-for-troubleshooting-purposes.aspx;
• “Manually Control your ConfigMgr Client Deployment”, https://bennettadelson.wordpress.com/2012/11/08/manually-control-your-configmgr-client-deployment/.
  

Запрос к БД SCCM из первого поста отображает время и код завершения последней операции установки: