+7 (812) 325 84 00

+7 (499) 322 07 96

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

  • Архив

    «   Март 2024   »
    Пн Вт Ср Чт Пт Сб Вс
            1 2 3
    4 5 6 7 8 9 10
    11 12 13 14 15 16 17
    18 19 20 21 22 23 24
    25 26 27 28 29 30 31
                 

Повышение защищенности стандартного рабочего места под Windows

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.    “Белый список” приложений

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

 

Приложение

 

Путь   и каталог запуска

 

Пульт для работы с   чатом WorskpaceDesktopEdition

 
 

C:\Program Files\GCTI\Workspace Desktop Edition\InteractionWorkspace.exe

 
 

Статистика CCPulse

 
 

C:\GCTI\CCPulse+\CallCenter.exe

 
 

Управление системными   сообщениями в чате KnowledgeManager

 
 

C:\Program Files\GCTI\eServices 8.1.3\Knowledge   Manager\KnowledgeManager.BAT

 

(Использует каталог C:\Program Files\Java\jre6)

 
 

WFM – Управление   расписаниями

 
 

C:\Program Files\NICE_IEX_WFM\totalview\ttv40.exe

 
 

HPSM

 
 

C:\Program Files\HP\Service Manager 7.11\Client\ServiceManager.exe

 
 

Citrix Access Gateway

 
 

C:\Program Files\Citrix\Secure Access Client\nsload.exe

 
 

Skype

 
 

C:\Program Files\Skype\Phone\Skype.exe

 
 

Lync 2010

 
 

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Lync

 
 

Microsoft Office

 
 

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office

 
 

Internet Explorer

 
 

C:\Program Files\Internet Explorer\iexplore.exe

 
 

Google Chrome

 
 

C:\Program Files\Google\Chrome\Application\chrome.exe

 
 

Mozilla Firefox

 
 

C:\Program Files\Mozilla Firefox\firefox.exe

Если любопытно - это было стандартное рабочее место оператора клиентского call-центра.

3.    Реализация
Политика SRP реализуется с помощью объекта GPO в домене AD в контейнере Computer Configuration и может быть
назначена на целевые OU, содержащие объекты компьютеров рабочих столов VDI, при необходимости, с фильтрацией
по ACL права Apply Group Policy для необходимых учетных записей или групп.

Согласно архитектуре ОС, установка чрезмерно жестких блокировок на системные каталоги (в частности, %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.

Расположение политики: Computer Configuration\Policies\Windows   Settings\Security Settings\Software Restriction Policy

Параметр

Значение

Enforcement\Apply software restriction policies to   the following

All software files

Enforcement\Apply software restriction policies to   the following users

All users

Enforcement\When applying software restriction   policies

Ignore certificate rules

Designated File Types

По умолчанию (не кастомизировалось)

Trusted Publishers

Не определено

Software Restriction Policy\Security Levels

Disallowed - Default Security Level (Software will not run, regardless of access   rights of the user)

Software Restriction Policy\Additional Rules

По списку (см.таблицу ниже)


Правила SRP.
 

Правило

 
 
Режим
 

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot% (реестр, путь)

 
 
Unrestricted
 
 

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir% (реестр, путь)

 
 
Unrestricted
 
 

*.lnk (путь)

 
 
Unrestricted
 
 

\\%USERDNSDOMAIN%\Sysvol\ (путь)

 
 
Unrestricted
 
 

C:\GCTI\CCPulse* (путь)

 
 
Unrestricted
 
 

C:\WINDOWS\Debug (путь)

 
 
Disallowed
 
 

C:\WINDOWS\PCHEALTH\ERRORREP (путь)

 
 
Disallowed
 
 

C:\WINDOWS\Registration (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\catroot2 (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\com\dmp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\FxsTmp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\spool\drivers\color (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\spool\PRINTERS (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\spool\SERVERS (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\Tasks (путь)

 
 
Disallowed
 
 

C:\WINDOWS\SysWOW64\com\dmp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\SysWOW64\FxsTmp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\SysWOW64\Tasks (путь)

 
 
Disallowed
 
 

C:\WINDOWS\Tasks (путь)

 
 
Disallowed
 
 

C:\WINDOWS\Temp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\tracing (путь)

 
 
Disallowed
Сформированная политика SRP обеспечивает полную блокировку запуска исполняемого ПО за пределами каталогов “C:\WINDOWS“, “C:\Program Files“, “C:\CGTI\CCPulse*“, и блокировку потенциально нелегитимного ПО в каталоге ОС. В том числе, обеспечивается запрет запуска любых исполняемых модулей из пределов пользовательского профиля. Отсутствие локальных административных прав у оператора и корректное выставление ACL на объекты файловой системы NTFS является обязательным условием эффективности метода.

Для сведения, см. 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 “Управление приложениями и устройствами“ (управление приложениями).

 

Правило

 

Назначение

 
 

Режим

 

Make all removable drives read-only

 
 

Блокировка записи на сменные носители

 
 

Включено/Рабочий режим

 
 

Block programs from running from removable devices

 
 

Блокировка запуска исполняемых модулей со сменных   носителей

 
 

Включено/Рабочий режим

 
 

ШАБЛОН. Разрешить   запуск доверенных приложений (ОСНОВНЫЕ АРМ)

 
 

Разрешить запуск доверенных приложений по рабочему списку   КЦ. Пустое правило (шаблон)

 
 

Отключено/Тест

 
 

ШАБЛОН. Block applications from running (блокировка через SEP)

 
 

Блокировка нелегитимных приложений через SEP. Пустое правило   (шаблон)

 
 

Отключено/Тест

 
 

Protect client files and registry keys

 
 

Защита критических компонент антивирусного модуля

 
 

Включено/Рабочий режим

 
 

Block writing to USB drives

 
 

Блокировка записи на USB

 
 

Отключено/ Рабочий режим

 
 

Log files written to USB drives

 
 

Протоколирование записи на USB

 
 

Отключено/ Рабочий режим

 
 

Block modifications to hosts file

 
 

Блокировка записи в файл конфигурации распознавателя DNS

 
 

Включено/Рабочий режим

 
 

Block autorun.inf

 
 

Блокировка автозапуска

 
 

Включено/Рабочий режим

 
 

Block access to Autorun.inf - old edition

 
 

Блокировка доступа к файлу автозапуска старой редакции   для процессов антивируса

 
 

Включено/Рабочий режим

 
 

Prevent changes to Windows shell load points

 
 

Блокировка изменений конфигурации оболочки ОС

 
 

Включено/Рабочий режим

 
 

Prevent changes to system using Internet Explorer

 
 

Защита системы от изменений через браузер Internet Explorer

 
 

Включено/Тест

 
 

Prevent modification of system files

 
 

Блокировка модификации системных файлов

 
 

Включено/Тест

 
 

Prevent registration of new Browser Helper Objects

 
 

Блокировка установки объектов BHO

 
 

Включено/Тест

 
 

Prevent registration of new Toolbars

 
 

Блокировка установки дополнительных панелей инструментов   браузера IE

 
 

Включено/Тест

 
 

Lockdown Internet   Explorer

 
 

Поведенческая блокировка браузера IE

 
 

Включено/Тест

 
 

Stop software   installers

 
 

Блокировка установщиков ПО

 
 

Включено/Тест

 
 

Block access to Autorun.inf

 
 

Защита файлов автозапуска (Autorun.inf)

 
 

Включено/Рабочий режим

 
 

Block applications from running from TEMP

 
 

Блокировка запуска исполняемых модулей из временных   каталогов

 
 

Включено/Рабочий режим

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

Два правила, отмеченные префиксом “ШАБЛОН” - пустые. Это шаблоны разрешения и блокировки приложений средствами SEP (сейчас аналогичный функционал обеспечен через групповые политики SRP). Шаблоны специально оставлены для возможности быстрой альтернативной реализации в случае необходимости. Однако, использование параллельно обоих методов для блокировки запуска ПО не рекомендуется.

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.

Программное управление уровнями целостности (Integrity Levels) объектов файловой системы

Короткий пост.

Для одной факультативной задачи, потребовалось сделать средство программного управления уровнями целостности (Integrity Level) файловых объектов в операционной системе.

Уровни целостности - технология довольно экзотическая и малоизученная, появились в Windows Vista/2008, используются в них и во всех более поздних версиях клиентских и серверных ОС как один из встроенных механизмов защиты. Пример описания на MSDN – “Windows Integrity Mechanism Design”, https://msdn.microsoft.com/en-us/library/bb625963.aspx.

В итоге не придумал ничего лучше, чем тряхнуть стариной, и написать мини-утилиту командной строки на старом добром Си. Выкладываю как есть, исходный текст совсем не велик, и интуитивно понятен. Библиотеки классов не используются вовсе, стандартные функции тоже по минимуму, хватает Windows API. MIL – это “Manage integrity levels”.

Компилируется в любой современной версии Visual Studio (я использовал Visual Studio Community 2017) как консольное приложение.

MIL.7z ( 2.01 КБ)