Аудит объектов ядра windows относится к группе аудита

Назначение аудита
безопасности

• Определение
  истинных виновников компьютерных
  правонарушений и причин, способствовавших
  их возникновению.

• Обнаружение
  подготовительных действий к совершению
  компьютерного правонарушения.

• Немедленная
  реакция на событие, связанное с
  безопасностью компьютерной системы
  (в ОС Windows
  не реализовано).

Основные требования
политики аудита

• Ассоциирование
  пользователя с событием аудита;

• обязательность
  аудита стандартного набора событий –
  идентификации и аутентификации
  пользователя, доступа к объектам,
  уничтожения объектов, действий
  привилегированного пользователя и
  др.;

• наличие необходимого
  набора атрибутов записи журнала аудита
  – даты и времени события, логического
  имени инициировавшего событие
  пользователя, типа события, признака
  успешного или неудачного завершения
  вызвавшего событие действия, имени
  связанного с событием объекта;

• возможность
  фильтрации записей журнала аудита;

• поддержка и защита
  от несанкционированного доступа к
  журналу аудита.

Аудит безопасности
в ОС Windows

• Журнал
  аудита содержится в файле windows
  System32
  Config
  secevent.evt,
  а доступ к нему осуществляется с помощью
  административной функции «Просмотр
  событий» Панели управления Windows.

Возможна регистрация
следующих событий:

• вход пользователей
  в систему;

• доступ субъектов
  к объектам;

• доступ
  к службе каталогов Active
  Directory;

• изменение политики
  безопасности;

• использование
  привилегий;

• отслеживание
  процессов;

• системные события;

• события входа в
  систему;

• управление учетными
  записями пользователей и групп;

• доступ к глобальным
  системным объектам;

• использование
  прав на архивацию и восстановление
  объектов.

• Для каждой категории
  регистрируемых событий администратор
  может указать тип события (успешное и
  (или) неудачное завершение) либо отменить
  его регистрацию в журнале аудита.

• При
  аудите использования привилегий
  регистрируются попытки использования
  не всех возможных привилегий, а лишь
  тех, которые считаются потенциально
  опасными с точки зрения разработчиков
  подсистемы безопасности защищенных
  версий Windows
  (например, создание маркерного объекта
  или создание журналов безопасности).
  Следует отметить, что не все объективно
  опасные привилегии входят в этот список.

К системным
событиям, которые могут регистрироваться
в журнале аудита, относятся:

• перезагрузка
  операционной системы;

• завершение работы
  операционной системы;

• загрузка пакета
  аутентификации;

• запуск
  процесса входа (Winlogon);

• сбой при регистрации
  события в журнале аудита;

• очистка журнала
  аудита;

• загрузка пакета
  оповещения об изменении в списке
  пользователей.

Другие
параметры аудита (Windows
7 и старше)

• Максимальный
  размер журнала аудита.

• Реакция операционной
  системы на его переполнение:

  • затирать старые
    события при необходимости (реакция по
    умолчанию);

  • архивировать
    журнал при заполнении, не перезаписывать
    события;

  • не переписывать
    события (очистить журнал вручную).

Аудит доступа к
объектам

• Используется
  системный список контроля доступа
  SACL,
  содержимое которого формируется
  администратором системы.

• Элементы
  ACE
  списка SACL
  имеют один и тот же тип и содержат
  заголовок ACE,
  маску регистрируемых в журнале аудита
  прав доступа и SID
  пользователя или группы, чьи попытки
  доступа к объекту должны регистрироваться
  (если в ACE
  не указан SID,
  то регистрируются попытки доступа к
  объекту всех пользователей).

Расширенная
политика аудита (Windows
7 и старше)

Пример. Изменение
аудита использования прав:

• Использование
  прав, не затрагивающее конфиденциальные
  данные.

• Использование
  прав, затрагивающее конфиденциальные
  данные.

• Аудит других
  событий использования прав.

Пример. Изменение
аудита доступа к объектам:

• Файловой системы.

• Общих папок.

• Объектов ядра.

• Реестра.

• Диспетчера учетных
  записей безопасности.

• Других событий
  доступа к объектам.

• И другие параметры.

Администраторы
и аудиторы

• Для обеспечения
  безопасности информации в КС целесообразно
  разделить полномочия администраторов
  КС и аудиторов (пользователей с правами
  доступа к файлу аудита). Если этого не
  сделать, то возникнет ситуация, при
  которой установка параметров политики
  безопасности и проверка ее соблюдения
  сосредоточатся в одних руках.

• В ОС
  Windows
  можно сделать так, что просматривать
  и очищать журнал аудита, а также управлять
  списками SACL
  объектов доступа смогут только члены
  группы аудиторов компьютерной системы
  (право «Управление аудитом и журналом
  безопасности»).

• Но полномочия на
  изменение значений параметров политики
  аудита при этом сохранятся у членов
  группы администраторов компьютерной
  системы.

Аудит
событий безопасности в ОС Unix

Системные
журналы в Unix-системах
сохраняются в каталогах /usr/adm
(старые версии), /var/adm
(более современные версии) или /var/log
(некоторые версии Solaris,
Linux
и др.) в файлах:

• acct
  – регистрация команд, выполненных
  пользователем;

• loginlog
  – регистрация неудачных попыток входа;

• sulog
  – регистрация использования команды
  su;

• wtmp
  – регистрация входов и выходов
  пользователей, загрузки и завершения
  работы ОС;

• security
  – сообщения подсистемы безопасности;

• vold.log
  – регистрация ошибок внешних устройств
  и др.

• Для регулярного
  архивирования и сохранения файлов
  системных журналов могут использоваться
  командные сценарии.

• В других
  Unix-системах
  каждый файл системного журнала из
  каталога /var/log
  обновляется в соответствии со своим
  набором правил.

• Многие
  Unix-системы
  имеют средства централизованного сбора
  информации о событиях (сообщениях)
  безопасности (сервис syslog).

Сообщение аудита
в ОС Unix

• имя программы,
  при выполнении которой было сгенерировано
  сообщение;

• источник сообщения
  (модуль операционной системы);

• приоритет (важность)
  сообщения;

• содержание
  сообщения.

Параметры
аудита в ОС Unix

Каждая
строка конфигурационного файла
/etc/syslog.conf
состоит из двух частей, разделяемых
символом табуляции:

• селектора, в
  котором указываются приоритеты и
  источники регистрируемых сообщений
  (например, все сообщения об ошибках или
  все отладочные сообщения ядра системы);

• описания действия,
  которое должно быть выполнено при
  поступлении сообщения указанного типа
  (например, записать в системный журнал
  или отослать на терминал указанного
  пользователя).

Расширение аудита
в ОС Linux

В ОС
Linux,
начиная с версии ядра 2.6, существует
возможность аудита попыток доступа к
файлам и выполнения системных вызовов
(демон auditd).
Основные дополнительные возможности
этой службы:

• Ротация файла
  аудита (его перезапись при переполнении).

• Задание максимального
  размера файла аудита.

• Аудит попыток
  доступа к файлам.

• Утилиты для
  определения параметров аудита, фильтрации
  записей аудита, формирования отчетов
  на основе журналов аудита.

Соседние файлы в предмете Защита информации

• #
• #
• #
• #
• #
• #
• #

Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.

1. Введение
2. Знакомство с расширенным аудитом Windows
3. Настройка политик аудита
4. Усиление цифровой обороны
5. Выводы

Введение

Все мы любим заворожённо читать про очередное расследование инцидента, где шаг за шагом распутывается клубок: как проник злоумышленник, какие инструменты он использовал и когда, что за процессы создавались на скомпрометированном хосте, что происходило в сети и, конечно же, кто виноват и что делать.

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

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

Знакомство с расширенным аудитом Windows

Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.

Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».

Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Рисунок 1. Политика аудита

 

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Рисунок 2. Конфигурация расширенной политики аудита

 

Ниже на рисунке видно, как они коррелируют между собой.

Рисунок 3. Корреляция аудита и расширенного аудита

 

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Таблица 1. Категории и подкатегории аудита

Категория (Category)	Подкатегория (Subcategory)
Вход учётной записи (Account Logon)	Аудит проверки учётных данных (Audit Credential Validation)
Аудит службы проверки подлинности Kerberos (Audit Kerberos Authentication Service)
Аудит операций с билетами службы Kerberos (Audit Kerberos Service Ticket Operations)
Аудит других событий входа учётных записей (Audit Other Account Logon Events)
Управление учётными записями (Account Management)	Аудит управления группами приложений (Audit Application Group Management)
Аудит управления учётными записями компьютеров (Audit Computer Account Management)
Аудит управления группами распространения (Audit Distribution Group Management)
Аудит других событий управления учётными записями (Audit Other Account Management Events)
Аудит управления группами безопасности (Audit Security Group Management)
Аудит управления учётными записями пользователей (Audit User Account Management)
Подробное отслеживание (Detailed Tracking)	Аудит активности DPAPI (Audit DPAPI Activity)
PNP-действие аудита (Audit PNP Activity)
Аудит создания процессов (Audit Process Creation)
Аудит завершения процессов (Audit Process Termination)
Аудит событий RPC (Audit RPC Events)
Проверка изменений прав маркера (Audit Token Right Adjusted) [Windows 10 / Server 2016 и выше]
Доступ к службе каталогов DS (DS Access)	Аудит подробной репликации службы каталогов (Audit Detailed Directory Service Replication)
Аудит доступа к службе каталогов (Audit Directory Service Access)
Аудит изменения службы каталогов (Audit Directory Services Changes)
Аудит репликации службы каталогов (Audit Directory Service Replication)
Вход / выход (Logon / Logoff)	Аудит блокировки учётных записей (Audit Account Lockout)
Аудит заявок пользователей или устройств на доступ (Audit User / Device Claims)
Аудит расширенного режима IPsec (Audit IPsec Extended Mode)
Аудит основного режима IPsec (Audit IPsec Main Mode)
Аудит быстрого режима IPsec (Audit IPsec Quick Mode)
Аудит выхода из системы (Audit Logoff)
Аудит входа в систему (Audit Logon)
Аудит сервера политики сети (Audit Network Policy Server)
Аудит других событий входа и выхода (Audit Other Logon / Logoff Events)
Аудит специального входа (Audit Special Logon)
Доступ к объектам (Object Access)	Аудит событий, создаваемых приложениями (Audit Application Generated)
Аудит служб сертификации (Audit Certification Services)
Аудит сведений об общем файловом ресурсе (Audit Detailed File Share)
Аудит общего файлового ресурса (Audit File Share)
Аудит файловой системы (Audit File System)
Аудит подключения платформы фильтрации (Audit Filtering Platform Connection)
Аудит отбрасывания пакетов платформой фильтрации (Audit Filtering Platform Packet Drop)
Аудит работы с дескрипторами (Audit Handle Manipulation)
Аудит объектов ядра (Audit Kernel Object)
Аудит других событий доступа к объектам (Audit Other Object Access Events)
Аудит реестра (Audit Registry)
Аудит съёмного носителя (Audit Removable Storage)
Аудит диспетчера учётных записей безопасности (Audit SAM)
Аудит сверки с централизованной политикой доступа (Audit Central Access Policy Staging)
Изменение политики (Policy Change)	Аудит изменения политики аудита (Audit Policy Change)
Аудит изменения политики проверки подлинности (Audit Authentication Policy Change)
Аудит изменения политики авторизации (Audit Authorization Policy Change)
Аудит изменения политики платформы фильтрации (Audit Filtering Platform Policy Change)
Аудит изменения политики на уровне правил MPSSVC (Audit MPSSVC Rule-Level Policy Change)
Аудит других событий изменения политики (Audit Other Policy Change Events)
Использование привилегий (Privilege Use)	Аудит использования привилегий, не затрагивающих конфиденциальные данные (Audit Non Sensitive Privilege Use)
Аудит других событий использования привилегий (Audit Other Privilege Use Events)
Аудит использования привилегий, затрагивающих конфиденциальные данные (Audit Sensitive Privilege Use)
Система (System)	Аудит драйвера IPsec (Audit IPsec Driver)
Аудит других системных событий (Audit Other System Events)
Аудит изменения состояния безопасности (Audit Security State Change)
Аудит расширения системы безопасности (Audit Security System Extension)
Аудит целостности системы (Audit System Integrity)
Аудит доступа к глобальным объектам (Global Object Access Auditing)	Файловая система (File system)
Реестр (Registry)

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.

Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории

 

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Рисунок 5. Аудит создания процессов регистрирует успешные события

 

Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.

Рисунок 6. Вкладка с описанием политики

 

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Рисунок 7. Настройка SACL

 

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).

Рисунок 8. Принудительное переопределение параметров политики аудита

 

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Рисунок 9. Использование инструмента auditpol

 

Настройка политик аудита

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

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

Таблица 2. Рекомендуемые настройки аудита Windows

Категория	Подкатегория	Включить	Хост (DC, сервер, АРМ)	Категория (успех / отказ)
Account Logon	Audit Credential Validation	+	DC, сервер, АРМ	Успех и отказ
Audit Kerberos Authentication Service	+	DC	Успех и отказ
Audit Kerberos Service Ticket Operations	+	DC	Успех и отказ
Audit Other Account Logon Events	—
Account Management	Audit Application Group Management	+	DC	Успех и отказ
Audit Computer Account Management	+	DC	Успех
Audit Distribution Group Management	+	DC	Успех
Audit Other Account Management Events	+	DC, сервер, АРМ	Успех
Audit Security Group Management	+	DC, сервер, АРМ	Успех
Audit User Account Management	+	DC, сервер, АРМ	Успех и отказ
Detailed Tracking	Audit DPAPI Activity	+	DC, сервер, АРМ	Успех и отказ
Audit PNP Activity	+	DC, сервер, АРМ	Успех и отказ
Audit Process Creation	+	DC, сервер, АРМ	Успех
Audit Process Termination	—
Audit RPC Events	—
Audit Token Right Adjusted	—
DS Access	Audit Detailed Directory Service Replication	+	DC	Успех и отказ
Audit Directory Service Access	+	DC	Успех и отказ
Audit Directory Services Changes	+	DC	Успех и отказ
Audit Directory Service Replication	+	DC	Успех и отказ
Logon/Logoff	Audit Account Lockout	+	DC, сервер, АРМ	Отказ
Audit User / Device Claims	—
Audit IPsec Extended Mode	—
Audit IPsec Main Mode	—
Audit IPsec Quick Mode	—
Audit Logoff	+	DC, сервер, АРМ	Успех
Audit Logon	+	DC, сервер, АРМ	Успех и отказ
Audit Network Policy Server	—
Audit Other Logon / Logoff Events	+	DC, сервер, АРМ	Успех и отказ
Audit Special Logon	+	DC, сервер, АРМ	Успех
Object Access	Audit Application Generated	—
Audit Certification Services	—
Audit Detailed File Share	—
Audit File Share	—
Audit File System	+	DC, сервер, АРМ	Успех и отказ
Audit Filtering Platform Connection	—
Audit Filtering Platform Packet Drop	—
Audit Handle Manipulation	—
Audit Kernel Object	—
Audit Other Object Access Events	+	DC, сервер, АРМ	Успех и отказ
Audit Registry	+	DC, сервер, АРМ	Успех и отказ
Audit Removable Storage	+	DC, сервер, АРМ	Успех и отказ
Audit SAM	—
Audit Central Access Policy Staging	—
Policy Change	Audit Policy Change	+	DC, сервер, АРМ	Успех
Audit Authentication Policy Change	+	DC, сервер, АРМ	Успех
Audit Authorization Policy Change	+	DC, сервер, АРМ	Успех
Audit Filtering Platform Policy Change	—
Audit MPSSVC Rule-Level Policy Change	+	DC, сервер, АРМ	Успех и отказ
Audit Other Policy Change Events	—
Privilege Use	Audit Non Sensitive Privilege Use	+	DC, сервер, АРМ	Успех и отказ
Audit Other Privilege Use Events	—
Audit Sensitive Privilege Use	+	DC, сервер, АРМ	Успех и отказ
System	Audit IPsec Driver	—
Audit Other System Events	+	DC, сервер, АРМ	Успех и отказ
Audit Security State Change	+	DC, сервер, АРМ	Успех
Audit Security System Extension	+	DC, сервер, АРМ	Успех
Audit System Integrity	—
Global Object Access Auditing	File system	—
Registry	—

После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.

Усиление цифровой обороны

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.

Рисунок 10. Журналирование командной строки процесса

 

Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.

Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).

Рисунок 11. Путь к аудиту создания процессов

 

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

Рисунок 12. Настройка «Включать командную строку в события создания процессов» 

 

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Рисунок 13. Детектирование mimikatz

 

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.

PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.

Список поддерживаемых ОС:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1
• Windows 8.1
• Windows 8
• Windows 7 SP1

Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.

Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)

Рисунок 14. Путь к аудиту Windows PowerShell

 

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

Рисунок 15. Включить регистрацию блоков сценариев PowerShell

 

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Рисунок 16. Пример регистрируемого события 4104

 

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

• журнал «Установка» (Setup) — не менее 10 МБ,
• журнал «Система» (System) — не менее 50 МБ,
• журнал «Приложение» (Application) — не менее 50 МБ,
• журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).

Рисунок 17. Настройка хранения журналов аудита

 

Выводы

Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.

Аудит системных событий Audit system events

Область применения Applies to

Определяет, следует ли выполнять аудит, когда пользователь перезапускается или завершает работу компьютера, или когда возникает событие, которое влияет на безопасность системы или журнал безопасности. Determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.

Если вы определяете этот параметр политики, вы можете указать, следует ли проводить аудит успехов, аудит отказов или вообще не проводить аудит для типа события. If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Аудит успехов приводит к созданию записи аудита при успешном попытке входа. Success audits generate an audit entry when a logon attempt succeeds. Аудит отказов приводит к созданию записи аудита при неудачной попытке входа. Failure audits generate an audit entry when a logon attempt fails.

Чтобы отключить аудит, в диалоговом окне свойства для этого параметра политики установите флажок определить следующие параметры политики и снимите флажки успех и отказ . To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

По умолчанию Default:

• Успех на контроллерах домена. Success on domain controllers.
• Без аудита на рядовых серверах. No auditing on member servers.

Настройка этого параметра аудита Configure this audit setting

Вы можете настроить этот параметр безопасности, открыв соответствующую политику в разделе Computer Конфигуратионвиндовс Сеттингссекурити Сеттингслокал ПолиЦиесаудит. You can configure this security setting by opening the appropriate policy under Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy.

Источник

Аудит других системных событий Audit Other System Events

Область применения Applies to

• Windows 10; Windows 10
• WindowsServer2016 Windows Server 2016

Аудит других системных событий включает в себя события «Брандмауэр Windows» и «Брандмауэр Windows» и «Запуск и остановка», события отказа для этих служб и ошибок обработки политики брандмауэра Windows. Audit Other System Events contains Windows Firewall Service and Windows Firewall driver start and stop events, failure events for these services and Windows Firewall Service policy processing failures.

Аудит других системных событий определяет, будет ли операционная система проводить аудит различных системных событий. Audit Other System Events determines whether the operating system audits various system events.

В этой категории есть следующие системные события: The system events in this category include:

Запуск и завершение работы службы брандмауэра Windows и драйвера. Startup and shutdown of the Windows Firewall service and driver.

Обработка политики безопасности службой брандмауэра Windows. Security policy processing by the Windows Firewall service.

Файл ключа криптографии и операции миграции. Cryptography key file and migration operations.

События BranchCache. BranchCache events.

Объем событий: низкий. Event volume: Low.

Список событий: Events List:

5024(ов): служба брандмауэра Windows запущена успешно. 5024(S): The Windows Firewall Service has started successfully.

5025(ов): служба брандмауэра Windows остановлена. 5025(S): The Windows Firewall Service has been stopped.

5027(F): службе брандмауэра Windows не удалось получить политику безопасности из локального хранилища. 5027(F): The Windows Firewall Service was unable to retrieve the security policy from the local storage. Служба может продолжить применять текущую политику. The service will continue enforcing the current policy.

5028(F): службе брандмауэра Windows не удалось проанализировать новую политику безопасности. 5028(F): The Windows Firewall Service was unable to parse the new security policy. Служба продолжит применять текущую политику. The service will continue with currently enforced policy.

5029(F): службе брандмауэра Windows не удалось инициализировать драйвер. 5029(F): The Windows Firewall Service failed to initialize the driver. Служба продолжит применять текущую политику. The service will continue to enforce the current policy.

5030(F): не удалось запустить службу брандмауэра Windows. 5030(F): The Windows Firewall Service failed to start.

5032(F): брандмауэру Windows не удалось уведомить пользователя о том, что приложение заблокировано для приема входящих подключений в сети. 5032(F): Windows Firewall was unable to notify the user that it blocked an application from accepting incoming connections on the network.

5033(ов): Драйвер брандмауэра Windows запущен успешно. 5033(S): The Windows Firewall Driver has started successfully.

5034(ов): Драйвер брандмауэра Windows остановлен. 5034(S): The Windows Firewall Driver was stopped.

5035(F): не удалось запустить драйвер брандмауэра Windows. 5035(F): The Windows Firewall Driver failed to start.

5037(F): обнаружена критическая ошибка во время выполнения драйвером брандмауэра Windows. 5037(F): The Windows Firewall Driver detected critical runtime error. Завершение работы. Terminating.

5058(S; F): операция с файлом ключа. 5058(S, F): Key file operation.

5059(S; F): ключевая операция миграции. 5059(S, F): Key migration operation.

6400(-): BranchCache: получен ошибочно отформатированный ответ при обнаружении доступности содержимого. 6400(-): BranchCache: Received an incorrectly formatted response while discovering availability of content.

6401(-): BranchCache: получены недопустимые данные с однорангового узла. 6401(-): BranchCache: Received invalid data from a peer. Данные удалены. Data discarded.

6402(-): BranchCache: сообщение для размещенного кэша, предлагающее ему неверный формат данных. 6402(-): BranchCache: The message to the hosted cache offering it data is incorrectly formatted.

6403(-): BranchCache: размещенный кэш отправляет клиенту ошибочно отформатированный ответ. 6403(-): BranchCache: The hosted cache sent an incorrectly formatted response to the client.

6404(-): BranchCache: не удалось проверить подлинность размещенного кэша с помощью ПОДГОТОВЛЕНного SSL-сертификата. 6404(-): BranchCache: Hosted cache could not be authenticated using the provisioned SSL certificate.

6405(-): служба BranchCache: %2 экземпляров события с кодом %1 возникла. 6405(-): BranchCache: %2 instance(s) of event id %1 occurred.

6406(-): %1 зарегистрировано в брандмауэре Windows для управления фильтрацией по следующим параметрам: %2 6406(-): %1 registered to Windows Firewall to control filtering for the following: %2

6408(-): зарегистрированный продукт %1 окончился неудачей, и брандмауэр Windows теперь управляет фильтрацией для %2 6408(-): Registered product %1 failed and Windows Firewall is now controlling the filtering for %2

6409(-): BranchCache: не удалось проанализировать объект точки соединения службы. 6409(-): BranchCache: A service connection point object could not be parsed.

Источник

Настройка аудита в Windows для полноценного SOC-мониторинга

Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.

Введение

Все мы любим заворожённо читать про очередное расследование инцидента, где шаг за шагом распутывается клубок: как проник злоумышленник, какие инструменты он использовал и когда, что за процессы создавались на скомпрометированном хосте, что происходило в сети и, конечно же, кто виноват и что делать.

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

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

Знакомство с расширенным аудитом Windows

Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.

Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».

Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Рисунок 1. Политика аудита

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Рисунок 2. Конфигурация расширенной политики аудита

Ниже на рисунке видно, как они коррелируют между собой.

Рисунок 3. Корреляция аудита и расширенного аудита

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Таблица 1. Категории и подкатегории аудита

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.

Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Рисунок 5. Аудит создания процессов регистрирует успешные события

Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.

Рисунок 6. Вкладка с описанием политики

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Рисунок 7. Настройка SACL

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).

Рисунок 8. Принудительное переопределение параметров политики аудита

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Рисунок 9. Использование инструмента auditpol

Настройка политик аудита

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

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

Таблица 2. Рекомендуемые настройки аудита Windows

После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.

Усиление цифровой обороны

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.

Рисунок 10. Журналирование командной строки процесса

Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.

Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).

Рисунок 11. Путь к аудиту создания процессов

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

Рисунок 12. Настройка «Включать командную строку в события создания процессов»

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Рисунок 13. Детектирование mimikatz

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.

PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.

Список поддерживаемых ОС:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1
• Windows 8.1
• Windows 8
• Windows 7 SP1

Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.

Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)

Рисунок 14. Путь к аудиту Windows PowerShell

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

Рисунок 15. Включить регистрацию блоков сценариев PowerShell

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Рисунок 16. Пример регистрируемого события 4104

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

• журнал «Установка» (Setup) — не менее 10 МБ,
• журнал «Система» (System) — не менее 50 МБ,
• журнал «Приложение» (Application) — не менее 50 МБ,
• журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).

Рисунок 17. Настройка хранения журналов аудита

Выводы

Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.

Источник

Аудит доменных служб Active Directory в Windows Server 2008 R2

ИТ среда не является статичной. Ежеминутно в системах происходят тысячи изменений, которые требуется отследить и запротоколировать. Чем больше размер и сложность структуры, тем выше вероятность появления ошибок в администрировании и раскрытия данных. Без постоянного анализа изменений (удачных или неудачных) нельзя построить действительно безопасную среду. Администратор всегда должен ответить, кто, когда и что изменил, кому делегированы права, что произошло в случае изменений (удачных или неудачных), каковы значения старых и новых параметров, кто смог или не смог зайти в систему или получить доступ к ресурсу, кто удалил данные и так далее. Аудит изменений стал неотъемлемой частью управления ИТ инфраструктурой, но в организациях не всегда уделяют внимание аудиту, часто из-за технических проблем. Ведь не совсем понятно, что и как нужно отслеживать, да и документация в этом вопросе не всегда помогает. Количество событий, которые необходимо отслеживать, уже само по себе сложность, объемы данных велики, а штатные инструменты не отличаются удобством и способностью упрощать задачу отслеживания. Специалист должен самостоятельно настроить аудит, задав оптимальные параметры аудита, кроме того, на его плечи ложится анализ результатов и построение отчетов по выбранным событиям. Учитывая, что в сети запущено нескольких служб – Active Directory/GPO, Exchange Server, MS SQL Server, виртуальные машины и так далее, генерирующих очень большое количество событий, отобрать из них действительно необходимые, следуя лишь описаниям, очень тяжело.
Как результат, администраторы считают достаточными мероприятия резервного копирования, предпочитая в случае возникновения проблем просто произвести откат к старым настройкам. Решение о внедрении аудита часто принимается только после серьезных происшествий. Далее рассмотрим процесс настройки аудита Active Directory на примере Windows Server 2008 R2.

Аудит Active Directory штатными средствами

В Windows Server 2008 по сравнению с предыдущей Windows Server 2003 обновлены возможности подсистемы аудита, настраиваемые через политики безопасности, а количество отслеживаемых параметров увеличено на 53. В Windows Server 2003 существовала только политика Аудит доступа к службе каталогов, контролировавшая включение и отключение аудита событий службы каталогов. Теперь управлять аудитом можно на уровне категорий. Например, политики аудита Active Directory разделены на 4 категории, в каждой из которых настраиваются специфические параметры:

— Directory Service Access (доступ к службе каталогов);
— Directory Service Changes (изменения службы каталогов);
— Directory Service Replication (репликация службы каталогов);
— Detailed Directory Service Replication (подробная репликация службы каталогов).

При включении глобальной политики аудита Аудит доступа к службе каталогов автоматически активируются все подкатегории политики служб каталогов.
Система аудита в Windows Server 2008 отслеживает все попытки создания, изменения, перемещения и восстановление объектов. В журнал записывается предыдущее и текущее значения измененного атрибута и учетная запись пользователя, выполнившего операцию. Но если при создании объектов для атрибутов использовались параметры по умолчанию, их значения в журнал не заносятся.

ПРИМЕЧАНИЕ: В Windows Server 2003 аудит регистрировал только имя измененного атрибута.

В Windows Server 2008 R2 аудит внедряется при помощи:

— глобальной политики аудита (Global Audit Policy, GAP);
— списка управления доступом (System access control list, SACL) — определяет операции, для которых будет производиться аудит;
— схемы – используется для окончательного формирования списка событий.

По умолчанию для клиентских систем аудит отключен, для серверных активна подкатегория Доступ к службе каталогов Active Directory, остальные отключены. Для включения глобальной политики “Аудит доступа к службе каталогов” (Audit directory service access) необходимо вызвать Редактор управления групповыми политиками перейти в ветку Параметры безопасности/Локальные политики/Политика аудита, где активировать политику и установить контролируемые события (успех, отказ).

Рис.1 Включение политики аудита Directory Service Access

Второй путь — использовать для настройки утилиту командной строки auditpol, получить полный список GAP с установленными параметрами. При помощи auditpol достаточно ввести команду:
> auditpol /list /subcategory:*

Рис.2 Получаем список установок при помощи auditpol

Активируем политику “directory service access”:

> auditpol /set /subcategory:"directory service changes" /success:enable

ПРИМЕЧАНИЕ: Подробные сведения о команде можно получить, запустив ее в виде
auditpol /h

Чтобы не ждать, обновим политику контролера домена:

> gpupdate

Подкатегория политики аудита Доступ к службе каталогов формирует события в журнале безопасности с кодом 4662, которые можно просмотреть при помощи консоли Просмотр событий (Event Viewer) вкладка Журналы Windows – Безопасность.

Рис.3 Просмотр событий при помощи Event Viewer

В качестве альтернативного варианта просмотра событий можно использовать командлет Get-EventLog оболочки PowerShell. Например:

PS> Get-EventLog security | ?{$_.eventid -eq 4662}

ПРИМЕЧАНИЕ: Командлет Get-EventLog может принимать 14 параметров, позволяющих отфильтровать события по определенным критериям: After, AsBaseObject, AsString, Before, ComputerName, EntryType, Index, InstanceID, List, LogName, Message, Newest, Source и UserName.

Рис.4 Получаем список событий при помощи Get-EventLog

Кроме этого, регистрируется ряд других событий 5136 (изменение атрибута), 5137 (создание атрибута), 5138 (отмена удаления атрибута) и 5139 (перемещение атрибута).
Для удобства отбора определенных событий в консоли Просмотр событий используют фильтры и настраиваемые представления, а также подписку, позволяющую собирать данные журналов и с других серверов.

Таблица 1. Список событий аудита событий Active Directory в Windows Server 2008

Проверка учетных данных
ИДЕНТИФИКАТОР Сообщение
4774 Учетная запись была сопоставлена для входа в систему.
4775 Не удалось сопоставить учетную запись для входа в систему.
4776 Предпринята попытка проверить учетные данные для учетной записи контроллера домена.
4777 Не удается проверить учетные данные для учетной записи контроллера домена.

Управление учетной записью компьютера
ИДЕНТИФИКАТОР Сообщение
4741 Создана учетная запись компьютера.
4742 Изменена учетная запись компьютера.
4743 Удалена учетная запись компьютера.

Управление группами рассылки
ИДЕНТИФИКАТОР Сообщение
4744 Создана локальная группа с отключенной проверкой безопасности.
4745 Изменена локальная группа с отключенной проверкой безопасности.
4746 Добавлен пользователь к локальной группе с отключенной проверкой безопасности.
4747 Удален пользователь из локальной группы с отключенной проверкой безопасности.
4748 Удалена локальная группа с отключенной проверкой безопасности.
4749 Создана глобальная группа с отключенной проверкой безопасности.
4750 Изменена глобальная группа с отключенной проверкой безопасности.
4751 Добавлен пользователь к глобальной группе с отключенной проверкой безопасности.
4752 Удален пользователь из глобальной группы с отключенной проверкой безопасности.
4753 Удалена глобальная группа с отключенной проверкой безопасности.
4759 Создана универсальная группа с отключенной проверкой безопасности.
4760 Изменена универсальная группа с отключенной проверкой безопасности.
4761 Член добавлен к универсальной группы с отключенной проверкой безопасности.
4762 Удален пользователь из универсальной группы с отключенной проверкой безопасности.
Другие события управления учетными записями
ИДЕНТИФИКАТОР Сообщение
4739 Изменена политика домена.
4782 Хэш пароля учетной записи доступа к нему.
4793 Был вызван API проверку политики паролей.
Управление группой безопасности
ИДЕНТИФИКАТОР Сообщение
4727 Создана глобальная группа с включенной безопасностью.
4728 Добавлен пользователь к глобальной группе с включенной безопасностью.
4729 Удален пользователь из глобальной группы с включенной безопасностью.
4730 Удалена глобальная группа с включенной безопасностью.
4731 Создана локальная группа с включенной безопасностью.
4732 Добавлен пользователь в локальную группу с включенной безопасностью.
4733 Удален пользователь из локальной группы с включенной безопасностью.
4734 Удалена локальная группа с включенной безопасностью.
4735 Изменена локальная группа с включенной безопасностью.
4737 Изменена глобальная группа с включенной безопасностью.
4754 Создана универсальная группа с включенной безопасностью.
4755 Изменена универсальная группа с включенной безопасностью.
4756 Добавлен пользователь к универсальной группе с включенной безопасностью.
4757 Удален пользователь из универсальной группы с включенной безопасностью.
4758 Удалена универсальная группа с включенной безопасностью.
4764 Изменен тип группы.

Управление учетными записями пользователей
ИДЕНТИФИКАТОР Сообщение
4720 Учетная запись пользователя создана.
4722 Учетная запись пользователя включена.
4723 Изменен пароль учетной записи.
4724 Сброс пароля пользователя.
4725 Учетная запись пользователя отключена.
4726 Учетная запись пользователя удалена.
4738 Изменена учетная запись пользователя.
4740 Учетная запись пользователя заблокирована.
4765 Журнал SID был добавлен к учетной записи.
4766 Не удалось добавить журнал SID учетной записи.
4767 Учетная запись пользователя была разблокирована.
4780 Список управления Доступом был установлен на учетные записи, которые являются членами группы администраторов.
4781 Было изменено имя учетной записи.
4794 Была предпринята попытка задать режим восстановления служб каталогов.
5376 Диспетчер учетных данных: учетные данные были сохранены.
5377 Диспетчер учетных данных: учетные данные были восстановлены из резервной копии.

Другие события
ИДЕНТИФИКАТОР Сообщение
1102 Очищен журнал безопасности
4624 Успешный вход в систему
4625 Не удачный вход в систему

В ветке Политика аудита также активируются и другие возможности (см.рис.1): аудит входа/выхода в систему, аудит управления учетными записями, доступ к объектам, изменения политик и так далее. Например, настроим аудит доступа к объектам на примере папки с общим доступом. Для этого активируем, как рассказано выше, политику Audit object access, затем выбираем папку и вызываем меню Свойства папки, в котором переходим в подпункт Безопасность и нажимаем кнопку Дополнительно. Теперь в открывшемся окне “Дополнительные параметры безопасности для ..” переходим во вкладку Аудит и нажимаем кнопку Изменить и затем Добавить и указываем учетную запись или группу, для которой будет осуществляться аудит. Далее отмечаем отслеживаемые события (выполнение, чтение, создание файлов и др.) и результат (успех или отказ). При помощи списка “Применять” указываем область применения политики аудита. Подтверждаем изменения.

Рис.5 Настраиваем аудит папки с общим доступом

Теперь все указанные операции будут отображаться в журнале безопасности.
Чтобы упростить настройку аудита при большом количестве объектов, следует активировать флажок Наследование параметров от родительского объекта. При этом в поле Унаследовано от будет показан родительский объект, от которого взяты настройки.
Больший контроль событий, записываемых в журнал, достигается применением политики детализированного аудита (Granular Audit Policy), которая настраивается в Параметры безопасности/Локальные политики/Advanced Audit Policy Configuration. Здесь 10 подпунктов:

— Вход учетной записи – аудит проверки учетных данных, службы проверки подлинности Kerberos, операции с билетами службы Kerberos, другие события входа;
— Управление учетными записями – аудит управления группами приложений, учетными записями компьютеров и пользователей, группами безопасности и распространения;
— Подробное отслеживание – событий RPC и DPAPI, создания и завершения процессов;
— Доступ к службе каталогов DS – аудит доступа, изменений, репликации и подробной репликации службы каталогов;
— Вход/выход – аудит блокировки учетных записей, входа и выхода в систему, использования IPSec, сервера политики сети;
— Доступ к объектам – аудит объектов ядра, работы с дескрипторами, событий создаваемых приложениями, служб сертификации, файловой системы, общих папок, платформой фильтрации;
— Изменение политики – изменения политики аудита, проверки подлинности, авторизации, платформы фильтрации, правил службы защиты MPSSVC и другие;
— Использование прав – аудит прав доступа к различным категориям данных;
— Система – аудит целостности системы, изменения и расширения состояния безопасности, драйвера IPSec и других событий;
— Аудит доступа к глобальным объектам – аудит файловой системы и реестра.

Рис.6 Доступные настройки Advanced Audit Policy Configuration
Активация аудита управления учетными записями пользователей позволит отслеживать: создание, изменение, удаление, блокировку, включение и прочие настройки учетных записей, в том числе пароль и разрешения. Посмотрим, как она работает на практике — выбираем подкатегорию User Account Management и активируем. Команда для auditpol выглядит так:
> auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
> gpudate

Система аудита в консоли Просмотр события сразу покажет событие с номером 4719 Изменение параметров аудита, в котором показаны название политики и новые значения.

Рис.7 Фиксация изменения политики системой аудита

Чтобы создать событие, откроем консоль Active Directory – пользователи и компьютеры и изменим один из параметров любой учетной записи — например, добавим пользователя в группу безопасности. В консоли Просмотра события сразу будут сгенерировано несколько событий: события с номером 4732 и 4735, показывающие изменение состава группы безопасности, и добавление учетной записи новой группы безопасности (на рис.8 выделены фиолетовым).
Создадим новую учетную запись – система генерирует несколько событий: 4720 (создание новой учетной записи), 4724 (попытка сброса пароля учетной записи), несколько событий с кодом 4738 (изменение учетной записи) и, наконец, 4722 (включение новой учетной записи). По данным аудита администратор может отследить старое и новое значение атрибута — например, при создании учетной записи меняется значение UAC.

Рис.8 При создании новой учетной записи система аудита Windows Server 2008 генерирует несколько событий

Недостатки штатной системы аудита

Штатные инструменты операционной системы часто предлагают лишь базовые наборы средств анализа. Официальная документация (http://technet.microsoft.com/ru-ru/library/dd772623(WS.10).aspx) очень подобно расписывает возможности самого инструмента, практически мало помогая в выборе параметров, изменения которых необходимо отслеживать. В итоге решение этой задачи целиком ложится на плечи системного администратора, который должен полностью разбираться в технических аспектах аудита, и зависит от уровня его подготовки, а значит, велика вероятность ошибки. Кроме того, на его плечи ложится анализ результата, построение разнообразных отчетов.
Для удобства выбора определенных событий интерфейс консоли Event Viewer позволяет создавать фильтры и настраиваемые представления. В качестве параметров для отбора данных можно указать: дату, журнал и источник событий, уровень (критическое, предупреждение, ошибка и т.д.), код, пользователя или компьютер и ключевые слова. В организации может быть большое количество пользователей, объединенных в группы и подразделения, для которых аудит необходимо настроить персонально, но данная возможность в интерфейсе не предусмотрена.

Рис. 9 Настройка фильтра событий в консоли Event Viewer

В случае срабатывания правил в настраиваемом представлении можно создать задачу (меню Привязать задачу к событию): запустить программу, отправить сообщение по электронной почте или отобразить сообщение на рабочем столе.

Рис.10 Создание задачи в консоли Event Viewer

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

Рис.11 Система аудита Windows Server 2008 только выдает старое и новое значение атрибута, не предоставляя средств для удобного отката

Некоторые стандарты безопасности требуют хранения данных, собранных в процессе аудита, в течение продолжительного времени (например, SOX до 7 лет). Системными средствами реализовать это можно, но очень сложно. Размер журнала безопасности (как и других) ограничен 128 Мб, и при большом количестве событий данные могут быть перезаписаны (т.е. утеряны) уже через несколько часов. Чтобы этого избежать, необходимо вызвать окно свойств журнала в Event Viewer, где увеличить размер журнала и активировать его архивацию, установив флажок в “Архивировать журнал при заполнении. Не перезаписывать события”.

Рис.12 Чтобы не потерять старые события безопасности, следует увеличить размер журнала и включить архивацию

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

***
Данная статья является частью «Полного руководства по аудиту Active Directory в Windows Server 2008 R2» [PDF]. Вы можете скачать его по данной ссылке, заполнив небольшую форму.