Фреймворк конфигурации и управления политиками Software Restriction Policies — II

Приняв решение выбрать Политики ограниченного использования программ (Software Restriction Policies, SRP) в качестве инструмента реализации «белых списков» (Application Whitelisting, AWL) и заручившись поддержкой всех ответственных лиц, можно перейти к аудиту используемых на предприятии приложений. Это позволит реализовать AWL с полным знанием того, какие на самом деле программы и откуда запускаются пользователями вручную или операционной системой автоматически (например, сценарии входа, Logon Scripts). Узнав, какие пути реально используются, вы сможете настроить «белые списки», не повредив функционалу компьютера. Разумеется, существует множество конфигураций, в которых рабочая станция стандартизирована и полностью готова к внедрению AWL без дополнительных временных затрат на аудит, но такое случается не столь часто, как хотелось бы.

 

ЧАСТЬ ВТОРАЯ. АУДИТ ИСПОЛЬЗУЕМЫХ ПРИЛОЖЕНИЙ.

 

Разрабатывая фреймворк управления политиками SRP, я старался создать систему аудита, позволяющую ответить на следующие вопросы:

• Какие программы и модули используются на компьютерах компании в настоящий момент? Что потребуется добавить в политику, чтобы не вызвать отказ производственных систем при включении SRP?
• Какие программы и модули были заблокированы уже задействованной политикой? Не было ли среди сработавших блокировок false positive?
• Исправна ли система AWL? Нет ли в ней пробелов, позволяющих её легко обойти?
• Какие программы запускают сотрудники техподдержки и другие пользователи с правами администратора? Не пытаются ли они обмануть или отключить систему AWL?
• В самом ли деле пользователи работают с определёнными программами, количество лицензий на которые ограничено?

Для проведения аудита я создаю и подключаю к корневой папке домена Active Directory (AD) новый объект групповой политики (Group Policy Object, GPO) с именем «SRP Audit Only», в котором выполняю следующие настройки:

• В разделе Computer Configuration > Policies > Windows Settings > Security Settings > Software Restriction Policies создаю новую политику;
• В подразделе Security Levels назначаю правило по умолчанию: Unrestricted;
• В объекте Designated File Types удаляю расширение LNK;
• В объекте Enforcement указываю параметр Apply to: All Users;
• В объекте Enforcement указываю параметр Apply to: All software files.

 

Сразу дам несколько комментариев, почему параметры именно таковы:

• В доменных GPO ветка SRP присутствует также и в разделе User Configuration, но она зависима от Computer Configuration. Если политику задать только в User Cоnfiguration, компьютер также неявно задействует неотконфигурированный Computer Configuration. Это может быть не столь очевидным, но два раздела могут мешать друг другу, накладывая друг на друга свои параметры. Кроме того, я считаю, что компьютер нужно защищать вне зависимости от того, кто за ним работает. Исходя из сказанного, базовую политику (SRP Baseline) я всегда готовлю в Computer Configuration, в то время как объекты GPO с задействованным разделом User Configuration при необходимости могут дополнять собой базовую конфигурацию;
• Уровень Unrestricted разрешает исполнять все программы по умолчанию. Таким образом, политика ничего не будет блокировать, но сможет вести подробный журнал запускаемых модулей;
• Могут ли ярлыки быть опасными? Да, такое бывало — например, известный червь Stuxnet применял уязвимость, связанную именно с LNK-файлами. Но здесь придётся взвесить риски и оценить, насколько доброжелательно воспримут пользователи невозможность свободно обращаться с ярлыками по той причине, что их блокирует SRP. Для себя я решил обработку LNK исключить;
• Кто является самым опасным для системы пользователем? Конечно же, человек с привилегиями администратора. Компрометация привилегий стандартного пользователя, как правило, может привести к потере данных, к которым этот пользователь имеет доступ на Запись. Компрометация привилегий администратора приводит к потере всего компьютера, а в худшем сценарии — всего домена. В любом случае, от аудита всех пользователей без исключения хуже точно не станет.
• Существуют вирусы, работающие посредством вызываемых библиотек. Они запускаются ярлыком, сформированным подобным образом: C:\Windows\System32\rundll32.exe F:\blabla.nil. Исходя из этого, исключать фильтрацию динамических библиотек не следует. Иногда в литературе можно встретить предупреждение, что фильтрация библиотек негативно сказывается на производительности системы, но у себя подобных эффектов я никогда не встречал.

  

 

SRP поддерживает детальное журналирование в виде текстового файла, путь и имя которого указывается в реестре. Чтобы политика могла вести журнал в указанной папке, её следует создать заранее, так как журналирование папки создавать не умеет. Кроме того, политика SRP работает в контексте пользователя, поэтому все должны иметь разрешение дописывать файл журнала. Для всего этого в GPO «SRP Audit» я указываю ряд параметров:

• Computer Configuration > Preferences > Windows Settings > Registry >  В ключе реестра HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers создать значение LogFileName типа REG_SZ, равное «C:\Windows\Logs\SRP\SRP.log». Сразу обращаю внимание, что тип значения REG_EXPAND_SZ не поддерживается, поэтому указать в пути переменные окружения не получится;
• Computer Configuration > Preferences > Windows Settings > Folders >  Создать папку с именем «%WindowsDir%\Logs\SRP»;
• Computer Configuration > Policies > Windows Settings File System > Добавить путь «%SystemRoot%\Logs\SRP» > Добавить разрешение Read для группы Everyone, наследование включено;
• Computer Configuration > Policies > Windows Settings > File System > Добавить путь «%SystemRoot%\Logs\SRP\SRP.log» > Добавить разрешение Write для группы Everyone, наследование включено;

 

Получаемый на выходе журнал состоит из записей подобного рода:

explorer.exe (PID = 4960) identified C:\Windows\System32\ctfmon.exe as Unrestricted using path rule, Guid = {e69f085d-d392-4822-8f1a-5add14e43561}

 

Существенной проблемой является тот факт, что события записываются сплошным потоком в единый файл, при этом никакие временные метки не добавляются. Чтобы хоть как-то облегчить понимание происходящего, я разработал скрипт ежедневной ротации журнала SRP_LogRotation.ps1, текст которого приведён ниже. Также, в политику добавляются следующие параметры конфигурации скрипта:

• Computer Configuration > Preferences > Windows Settings > Registry > HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers > LoggingDepth типа DWORD;
• Computer Configuration > Preferences > Windows Settings > Registry > HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers > ServerLogFolder типа REG_SZ или REG_EXPAND_SZ;

 

Обнаружив смену даты с момента предыдущего запуска, скрипт копирует текущий журнал в файл с именем SRP_%ComputerName%_YYYYMMDD.log, после чего журнал очищается. Формула YYYYMMDD подразумевает собой «вчера» и вычисляется по формуле «%Today%-1», но это вычисление точным может не являться. Например, если последний раз компьютер работал в пятницу, 04-Dec-2015, а затем был выключен на выходные, то при включении в понедельник он обнаружит смену даты и перебросит последний журнал в файл, датируемый воскресеньем, 06-Dec-2015. Усложнять скрипт, делая его более интеллектуальным, анализируя системные журналы с целью выяснения точной даты, мне не требовалось.

Тем не менее, дни не копятся бесконечно, поэтому параметр LoggingDepth определяет глубину ротации журналов в сутках. Журналы, сохранённые ранее указанной глубины, удаляются. Обычно я устанавливаю этот параметр равным 30.

Параметр ServerLogFolder определяет путь до файл-сервера в виде \\Server\Share\Folder. Если этот параметр определён, компьютер создаёт в указанном пути подпапку %ComputerName%, внутри которой синхронизирует копии файлов своих локальных журналов SRP, при этом также отслеживая глубину ротации. Централизованное хранение журналов всех аудируемых компьютеров я применяю для последующего оптового анализа, импортируя все файлы в SQL-базу.

 

SRP_LogRotation.ps1

$CurrentLogFileName = (Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers -Name LogFileName).LogFileName
$LoggingDepth = (Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers -Name LoggingDepth).LoggingDepth
$ServerLogFolder = (Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers -Name ServerLogFolder).ServerLogFolder

if ($CurrentLogFileName -ne $null) {
$CurrentLogFolder = Split-Path -Path $CurrentLogFileName
$Yesterday = ((Get-Date).AddDays(-1)).ToString(«yyyyMMdd»)
$ComputerName = $env:ComputerName

if ($LoggingDepth -ne $null) {
$EventHorizon = (Get-Date).AddDays(-$LoggingDepth)
Get-ChildItem $CurrentLogFolder -filter («SRP_»+ $ComputerName +»_*.log») | ?{$_.LastWriteTime -lt $EventHorizon} | del
}

$OldLogFileName = Join-Path $CurrentLogFolder «SRP_$ComputerName`_$Yesterday.log»
if (!(Test-Path «$OldLogFileName»)) {
try {Copy-Item «$CurrentLogFileName» «$OldLogFileName»}
finally {Clear-Content «$CurrentLogFileName»}
}
if (Test-Path $ServerLogFolder) {
$DestinationFolder = Join-Path $ServerLogFolder $ComputerName
New-Item $DestinationFolder -type Directory
Get-ChildItem $CurrentLogFolder -filter («SRP_»+ $ComputerName +»_*.log») | ForEach-Object {if (!(Test-Path ($DestinationFolder +»\»+ $_.BaseName +».*»))) {Copy-Item $_.FullName $DestinationFolder}}
if ($LoggingDepth -ne $null) {Get-ChildItem $DestinationFolder -filter («SRP_»+ $ComputerName +»_*.bak») | ?{$_.LastWriteTime -lt $EventHorizon} | del }
}
}

 

Скрипт сохраняется в точке распространения (Deployment Point) и распространяется по рабочим станциям, затем ставится в Планировщик задач (Task Scheduler) с помощью всё того же объекта GPO «SRP Audit Only». Для этого конфигурируются следующие параметры политики:

• Computer Configuration > Preferences > Windows Settings > Files > Action: Update; Source: «\\WindowsNT.LV\NetLogon\Deployment\SRP\SRP_LogRotation.ps1»; Destination: «%WindowsDir%\»;
• Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell > Turn On Script Execution = Enabled, «Allow local scripts and remote signed scripts»
• Computer Configuration > Preferences > Control Panel Settings > Scheduled Tasks > New Scheduled Task (at least Windows 7)
  • General > Action > Update; Task Name: «SRP Log Rotation»
  • General > User Account > «NT AUTHORITY\System»; Run whether user is logged on or not; Run with highest privileges
  • Triggers > New > Begin the task > At startup
  • Triggers > New > Begin the task > on a Schedule; Daily at 00:00; Repeat every 1 hour for duration of 1 day
  • Actions > New > Start a program; Program: «powershell.exe»; Arguments: «-f C:\Windows\SRP_LogRotation.ps1»
  • Common > Item-level targeting > Collection is false (OS is Windows XP or OS is Windows Server 2003 or OS is Windows Server 2003 R2)
• Computer Configuration > Preferences > Control Panel Settings > Scheduled Tasks > New Scheduled Task
  • Task > Name > «SRP Log Rotation»; Run «powershell.exe»; Arguments: «-f C:\Windows\SRP_LogRotation.ps1»
  • Schedule > Daily at 00:00; Advanced > Repeat every 1 hour for duration of 1 day
  • Common > Item-level targeting > Collection is true (OS is Windows XP or OS is Windows Server 2003 or OS is Windows Server 2003 R2)

Как видно из конфигурации, Windows Vista я игнорирую (из-за её низкой распространённости). Если у вас на предприятии больше нет Windows XP/2003, то последнюю настройку тоже можете не добавлять.

        

 

Почему параметры именно таковы:

• WindowsNT.LV — это доменное имя Active Directory. Мне кажется удобным хранить распространяемые скрипты именно в папке NetLogon, так как её содержимое автоматически реплицируется между контроллерами домена, при этом считывать файлы можно с ближайшего контроллера, указывая имя домена, а не конкретного сервера;
• По умолчанию, исполнение скриптов PowerShell из файлов не разрешено; данная политика такой запуск разрешает;
• Оставлять имя и пароль пользователя напрямую в скрипте или в самом планировщике задач — не самая лучшая идея. Пусть задача исполняется от лица локальной системы (SYSTEM), это не требует сохранения пароля. В домене при работе по сети такая учётная запись распознаётся как ComputerName$. Альтернативой можете попробовать учётную запись с ограниченными привилегиями Network Service;

 

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

• Убедитесь, что группа Authenticated Users обладает правом Access this computer from the network. Если это нежелательно, то такое право следует выдать группам Domain Computers и Domain Controllers (подразумевается, что контроллеры тоже будут аудироваться и защищаться политикой, при этом они в группу Domain Computers не входят);
• Создайте папку на локальном диске, в которой будут собираться журналы. Сколько места следует зарезервировать? В среднем, суточный журнал типовой рабочей станции может занимать от 1-3 мегабайт; таким образом, журналы за 30 дней могут занять порядка 50-70 мегабайт для каждого компьютера. Иногда встречаются суточные журналы размером 40 МБ, а в исключительных случаях даже до 100 МБ, но в таком случае это уже является проблемой с приложениями или операционной системой, которую нужно решать. Умножив эти объёмы на количество аудируемых серверов и рабочих станций, вы получите искомое. По моей практике, выходит порядка 70 ГБ на 1000 компьютеров;
• Убедитесь, что группы Domain Computers и Domain Controllers имеют разрешение NTFS на Запись (Modify) в приготовленную папку. Компьютеры от лица своих учётных записей будут создавать подпапки, внутри которых сохранять копии log-файлов;
• Сделайте целевую папку Общей (Shared Folder) и добавьте разрешения на Запись (Change) указанным группам;
• Определите политику хранения (Retention Policy) файлов журналов. Проблемой могут являться устаревшие журналы компьютеров, которые давно не включались либо вообще выведены из состава домена. Для того, чтобы эти файлы не отнимали место впустую, я применяю приведённый ниже PowerShell-скрипт, удаляющий слишком старые файлы и папки. Его можно поставить в Планировщик задач (Task Scheduler) файл-сервера на одноразовый запуск ежесуточно.

DataRetention.ps1

$RetentionDepth = 30
$DataFolder = "D:\Reports\SRP_Logs"

$EventHorizon = (Get-Date).AddDays(-$RetentionDepth)
Get-ChildItem $DataFolder -recurse -force | ?{$_.LastWriteTime -lt $EventHorizon} | del -recurse -force

 

Организовав сбор журналов и выждав несколько дней, можно приступить к собственно анализу. Организовать фильтрацию и просмотр записей журналов можно разными способами, но вручную в любом случае это было бы очень сложно. Для себя я выбрал инструмент SRP Readiness Tool производства SysAdmins.lv. Он состоит из двух модулей:

• Модуль трансляции производит разбор (parsing) содержимого журнала, выбирая уникальные записи, затем импортирует их в базу MS SQL. Как правило, исполняется через Планировщик задач на файл-сервере, обеспечивая регулярный импорт поступающих журналов;
• Графический модуль анализа имеющихся в базе журналов.

Программа запрашивает у контроллера домена и отображает структуру организационных единиц (Organizational Units, OU) Active Directory, показывая только объекты Компьютеров. Далее можно выбрать интересующие OU или конкретные компьютеры и запросить информацию о зафиксированных запусках программ в этой группе. Разумеется, все программы вряд ли нас интересуют, поэтому можно настроить список исключений того, что не должно показываться в результирующей выборке, например, «C:\Windows\*» или «C:\Program Files\*».

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

 

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