Автор — Клемент Нотин, аналитик безопасности Active Directory, Tenable
Решение Tenable.ad обнаруживает атаки на Active Directory (AD). Для этого оно собирает события безопасности с отслеживаемых им контроллеров домена, а затем анализирует и коррелирует их. Windows предоставляет встроенные параметры политики аудита, определяющие, какие типы событий будут записаны в журнал безопасности. Тестируя это функции, мы заметили особенное поведение, которое может привести к потере событий.
При настройке контроллеров домена AD для записи событий безопасности, передачи их в SIEM и генерации алертов нельзя допустить ошибки журналирования, из-за которых SOC может пропустить атаку. В этой статье приведены практические советы по предотвращению непредвиденных проблем с параметрами политики аудита.
Дисклеймер
Эта статья основана на наблюдениях и нашей интерпретации документации Microsoft. Эта статья предоставляется «как есть», и мы не даем никаких гарантий правильности или полноты, и вам следует полагаться только на рекомендации Microsoft.
Введение
В Windows, начиная с Windows 2000, присутствовали только простые параметры политики аудита, поделенные на девять категорий. Они называются «категориями верхнего уровня» или «базовой политикой аудита» и доступны в том числе в новых версиях.
Позже появились «гранулярные политики аудита» — сначала в Windows Vista/2008 (настраивались только через auditpol.exe), а затем и в Windows 7/2008 R2 (доступны в настройках групповой политики). Они называются «подкатегории» или «расширенная параметры политики аудита».
Каждый параметр базовой политики соответствует сочетанию нескольких параметров расширенной политики. Пример из «Вопросов и ответов по расширенному аудиту безопасности» Microsoft:
«Включение одного параметра базовой политики аудита для события входа эквивалентно включению всех четырех параметров расширенной политики».
Информация в этой статье была протестирована на контроллерах домена Windows, так как они больше всего подходят для обнаружения угроз для AD. Однако она должна применяться и к остальным машинам Windows (серверам и рабочим станциям).
Сюрприз №1: расширенная политика аудита полностью заменяет базовую
При включении даже одного параметра расширенной политики аудита Windows полностью переключается на режим расширенной политики и игнорирует параметры базовой политики (по крайней мере, в последних версиях Windows). Вот наглядный пример.
- До: в системе используются параметры базовой политики. Для «Аудита использования привилегий» присваиваем значение «Успех, Отказ» (выделено зеленым). К другим категориям применены значения по умолчанию. Результат соответствует ожиданиям:
- После: включается только один параметр расширенной политики (выделено зеленым). Примечательно, что остальные категории больше не проходят аудит, в том числе те, к которым ранее были применены параметры базовой политики (выделено красным).
Таким образом, использовать обе политики одновременно невозможно. При использовании расширенной политики аудита придётся придерживаться её в дальнейшем и отказаться от базовой политики во избежание путаницы.
Вот что об этом говорится в «Вопросах и ответах расширенного аудита безопасности» Microsoft:
«Во время назначения параметров расширенной политики аудита с помощью групповой политики все параметры политики аудита текущего компьютера сбрасываются. После применения параметров расширенной политики аудита с помощью оснастски групповой политики точно настраивать политику аудита системы для текущего компьютера можно будет только через параметры расширенной политики аудита. […] Важно: назначая параметры расширенной политики аудита с помощью оснастски групповой политики или сценария входа, не используйте вместе параметры базовой политики аудита (Локальная политика/Политика аудита) и параметры расширенной политики (Параметры безопасности/Конфигурация расширенной политики аудита). Использование как параметров как расширенной, так и базовой политики аудита может привести к неожиданным результатам отчета аудита».
➡ Рекомендация Tenable.ad: используйте только параметры расширенной политики аудита. Параметры базовой политики аудита необходимо конвертировать в параметры расширенной политки.
Эта рекомендация присутствует в лучших руководствах по усилению безопасности, опубликованных различными организациями по кибербезопасности (ANSSI, DISA, STIG, CIS Benchmarks и т. д.).
Сюрприз №2: расширенная политика аудита может игнорироваться
Несмотря на сказанное выше, в некоторых случаях параметры базовой политики аудита могут превалировать над параметрами расширенной политики. Довольно сложно понять, в каких случаях это может произойти.
Вот что об этом сказано в «Вопросах и ответах расширенного аудита безопасности» Microsoft:
«Если вы назначаете расширенные политики аудита через «Конфигурацию расширенной политики аудита» или сценарий входа, следует активировать политику «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)», которая находится здесь: Локальные политики/Параметры безопасности. Это действие предотвратит конфликты между аналогичными параметрами, т. к. базовая политика аудита будет игнорироваться».
➡ Рекомендация Tenable.ad: чтобы избежать непредвиденных неприятностей, в начале использования расширенной политики аудита рекомендуется включить параметр групповой политики «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)». Эта политика включена по умолчанию, поэтому должна изначально работать в большинстве сред.
Эта рекомендация присутствует в лучших руководствах по усилению безопасности, опубликованных различными организациями по кибербезопасности (ANSSI, DISA, STIG, CIS Benchmarks и т. д.).
Сюрприз №3: установленные по умолчанию значения расширенной политики аудита не соблюдаются
Как было сказано выше, при включении даже одного параметра расширенной политики аудита система полностью переключается на режим расширенной политики. Как же система поступает с другими параметрами, значения которых не были выставлены отдельно? Можно предположить, что она оставляет значения по умолчанию. Эти значения описаны в документации каждого параметра аудита. Вот описание аудита события входа:
Кажется, что из этого следует, что аудит события входа по умолчанию должен иметь значение «Успех и Отказ», если не указано иное. Однако это не совсем так.
На сервере были выставлены следующие значения: «Успех» для аудита блокировки учетных записей и «Не настроено» для аудита события входа.
И всё же во второй политике аудита значение по умолчанию «Не настроено» изменилось на «Нет аудита».
Все прекрасно знают, что на значения по умолчанию полагаться нельзя. Но все же подобный результат весьма неожидан. Разумеется, другие групповые политики при этом не влияли на параметры аудита.
➡ Рекомендация Tenable.ad: не полагайтесь на значения по умолчанию для параметров расширенной политики аудита. Следует вручную установить необходимое значение («Нет аудита», «Успех», «Отказ», «Успех и Отказ») для всех нужных параметров.
Особое внимание стоит уделить переходу с базовой политики аудита на расширенную. Необходимо экспортировать все параметры политики на машины и конвертировать их в соответствующие расширенные параметры, что позволит избежать ухудшения результатов журналирования. Что касается групповой политики, особенно касательно безопасности — следует стремиться к созданию единой политики, которая будет применяться к вершине иерархии AD, а не создавать множество низкоуровневых политик.
Сюрприз №4: параметры групповой политики не объединяются
Что происходит, если на одной машине задействовано несколько групповых политик с разными параметрами политики аудита? Что, если одна политика активирует значение «Успех», а другая — значение «Отказ»? Соединятся ли они в «Успех и Отказ»?
Ответ: значения не могут объединяться — будет применена политика с наивысшим приоритетом. Этот факт отвечает общим принципам работы групповой политики, но всё же стоит помнить о нём.
В качестве иллюстрации приводится настройка параметров аудита на контроллерах домена. На этих серверах настроены две групповые политики.
Политика домена по умолчанию настроена на уровне всего домена.
- Для аудита блокировки учетных записей установлено значение «Успех и Отказ» (выделено желтым).
- Для аудита события входа установлено значение «Успех» (выделено красным).
Политика контроллера домена по умолчанию установлена на уровне OU контроллеров домена.
- Для аудита события выхода установлено значение «Успех и Отказ» (выделено голубым).
- Для аудита события входа установлено значение «Отказ» (выделено красным).
Получился следующий результат:
Конфликтующие значения для события входа (выделено красным) не объединились. Было применено значение политики контроллера домена по умолчанию. Эта политика превалирует согласно принципам работы групповых политик.
В то же время и значение для события выхода (выделено голубым) из политики контроллера домена по умолчанию, и значение для блокировки учетной записи (выделено желтым) из политики домена по умолчанию были успешно применены, так как не конфликтовали между собой.
В «Вопросах и ответах расширенного аудита безопасности» Microsoft это объясняется так:
«По умолчанию все параметры групповой политики, связанные с более высоким уровнем сайтов, доменов и подразделений AD, наследуются подразделениями более низких уровней. Однако наследуемая политика может быть переопределена групповой политикой, связанной на более низком уровне».
Больше о порядке работы групповых политик можно прочитать в спецификации [MS-GPOL].
➡ Рекомендация Tenable.ad: помните, что конфликтующие значения аудита не объединяются.
Если стоит задача определить групповую политику аудита безопасности для всего домена, следует убедиться, что другие групповые политики более низких подразделений не превалируют над ней. При необходимости этой групповой политике можно присвоить значение «Принудительно», но это не лучший вариант, так как он может привести к путанице при управлении большим количеством групповых политик.
Если необходим аудит только на контроллерах домена, можно связать групповую политику с подразделением контроллеров домена, при условии, что на уровне домена не действует принудительная групповая политика, параметры политики аудита которой превалируют.
Сюрприз №5: лишь один инструмент должным образом отображает эффективную политику аудита
Очевидно, во время настройки параметров политики аудита может возникнуть множество непредвиденных ситуаций. Необходим инструмент, который позволит убедиться, что политика настроена правильно.
На ум приходят инструменты, вычисляющие результат групповой политики GPO (RSoP), однако…
Например, утилита rsop.msc даже не поддерживает расширенную политику аудита, что неудивительно, ведь она уже не поддерживается. Для сравнения — вкладка расширенных параметров политики аудита есть в редакторе групповых политик (справа) и отсутствует в утилите rsop.msc (слева):
А утилита gpresult.exe отображает и базовую, и расширенную политику аудита при их наличии. Какая из них применяется?..
А что, если параметры были настроены локально, а не через оснастску групповой политики (что не рекомендуется)?
Единственный инструмент, который корректно отображает текущую эффективную политику аудита — это auditpol.exe, что видно на скриншотах выше. Это в своем блоге подтвердила компания Microsoft. Можно копнуть и глубже: auditpol.exe вызывает AuditQuerySystemPolicy, который в свою очередь вызывает LsarQueryAuditPolicy в LSASS.
➡ Рекомендация Tenable.ad: используйте только одну команду, если хотите увидеть эффективную политику аудита на машине: auditpol.exe /get /category:*.
Бонусный сюрприз: путаница в спецификации
При управлении расширенной политикой аудита через оснастску групповой политики появляется файл audit.csv, который описан в открытой спецификации Microsoft [MS-GPAC]. В одном из примеров есть ошибка:
Machine Name,Policy Target,Subcategory,Subcategory GUID,Inclusion Setting,Exclusion Setting,Setting Value
TEST-MACHINE,System,IPsec Driver,{0CCE9213–69AE-11D9-BED3–505054503030},No Auditing,,0
TEST-MACHINE,System,System Integrity,{0CCE9212–69AE-11D9-BED3–505054503030},Success,,1
TEST-MACHINE,System,IPsec Extended Mode,{0CCE921A-69AE-11D9-BED3–505054503030},Success and Failure,,3
TEST-MACHINE,System,File System,{0CCE921D-69AE-11D9-BED3–505054503030},Not specified,,0
В правой части строки указано значение (например, «Нет аудита», «Успех» и т.д.) и соответствующее ему числовое значение (0, 1, 3…). Согласно первой и последним строчкам значение «0» соответствует и значению «Нет аудита», и «Не определено», что не имеет смысла. К счастью, текстовое значение игнорируется. Оно предназначено только для чтения пользователем и игнорируется, когда применяется расширенная политика аудита.
Кроме того, в спецификации присутствует путаница со значениями «0» и «4».
Значение «0» указывает на то, что этот параметр подкатегории аудита не изменился.
Значение «4» указывает на то, что для этого параметра подкатегории аудита установлено значение «Нет».
На самом деле, картина следующая.
- Значение «0» означает, что аудит «отключен», и в графическом редакторе это выглядит так:
- Значение «4» означает, что аудит «не определен», следовательно, будет применено значение по умолчанию (за исключением случаев, описанных выше). На скриншоте это выглядит следующим образом (в этом случае отсутствует даже строчка для этого случая в audit.csv).
Готовы усилить защиту вашей Active Directory? Узнайте больше о Tenable.ad
Закажите демо и презентацию Tenable.ad по этой ссылке.
