scom-logo

SCOM: cоздание фильтров Audit Collection Services (ACS Filter)

После установки и настройки Audit Collection Service в Operations Manager встаёт проблема с слишком большим потоком данных в базу данных ACS. Конечно, первоначально необходимо настроить политики аудита на наблюдаемых системах, чтобы его включить и логировать только требуемые события. Вторым рубежом фильтрации данных будет сам ACS коллектор. В этой статье я разберу механизм фильтрации событий аудита, чтобы отбросить «лишние» с нашей точки зрения данные и не переполнять ими базу данных коллектора. Настройка фильтров (ACS Filter) производится с помощью утилиты AdtAdmin.exe, которая доступна на сервере с установленной ролью ACS коллектора. Фильтры представляют собой WMI Query Language (WQL) запросы. При написании статьи я использовал SCOM 2016, но эта же информация актуальна и для 2012, 2012R2.

Хочу порекомендовать интересный документ Noise Filters v4 на англ. языке от компании Secure Vantage Technologies (SVT). В нём достаточно детально рассмотрен механизм фильтрации и основные фильтры для разных сценариев использования. Правда нужно учитывать, что фильтры не отражают современной картины для Windows Server 2012 и 2016.

Основные рекомендации по работе с фильтрами ACS

Исключающие фильтры

Исключающие фильтры определяют события, которые ACS коллектор НЕ должен сохранять в базу данных, все остальные события, которые не попадают под действие такого фильтра записываются в БД. Исключающие фильтры всегда содержат оператор NOT после WHERE. Рекомендуется всегда использовать именно исключающие фильтры.

Резервные копии фильтров

Банальная рекомендация, но всё же. Храните ваши фильтры в сберегательной кассе в текстовом виде где-то ещё, на всякий случай. Может потребоваться развернуть ещё один ACS коллектор, либо же восстановить текущий после какого-то сбоя. Также можно быстро вернуться к предыдущей конфигурации фильтра при неудачном его изменении.

Исключайте события, которые действительно генерируются

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

Ограничения фильтров

Ограничение на количество символов в фильтре

Размер WMI запроса может быть не более 4800 символов. Это максимальная длина.

Сложность запроса

В документации это не описано, но известно, что при распространённом запросе внутри WHERE с множеством «AND» и «OR» фильтр может перестать работать. Хорошо, что перестаёт работать он так, что система начинает принимать все данные, как будто фильтра нет вовсе. Но никаких ошибок система не возвращает в этом случае. Только просмотр собранных данных поможет определить действительно ли фильтр работает.

Планирование фильтрации

В Operations Manager есть очень полезный отчёт, который позволяет оценить какие события (Event ID) вносят основной вклад в размер нашей базы данных ACS. Отчёт находится в разделе Audit Reports и называется Planning_-_Event_Counts:
Отчёт для планирования фильтрации ACS
acs-filter-planning-event-counts-report
Как видим, в данном примере 66,5% всей массы событий приходится на Event ID 4769. Перед фильтрацией событий на ACS коллекторе, ещё раз подумайте, возможно, целесообразнее настроить аудит на наблюдаемых системах, чтобы отключить лишнее. Здесь опубликованы таблицы по параметрам аудита различных систем: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations

Создание фильтра

Доступ учётной записи Network Service к параметру DbQueueQuery

Перед тем, как применять фильтры для коллектора ACS необходимо настроить доступ к соответствующей ветке реестра для учётной записи «Network Service», от имени которой работает служба Operations Manager Audit Collection Service. При создании фильтра, ACS коллектор вписывает его в параметр DbQueueQuery в разделе HKLM\SYSTEM\CurrentControlSet\services\AdtServer\Parameters.
Если не предоставить Set Value для Network Service, то в консоли мы увидим Error 0x00000005 Access Denied:
acs-filter-registry-permission2
Параметр, в который ACS коллектор записывает фильтр

После настройки разрешений фильтр успешно прописывается в соответствующем параметре:
acs-filter-registry-permission3

Значение фильтра по умолчанию: select * from AdtsEvent, что означает принимать все события.

Предварительная проверка фильтра с помощью утилиты WBEMTEST

Перед тем, как передать фильтр в AdtAdmin.exe его желательно протестировать с помощью утилиты WBEMTEST, которая доступна на всех серверах Windows Server 2008, 2012, 2016 и устанавливать её не нужно. Запускаем её на нашем ACS коллекторе:
WBEMTEST
acs-filter-wbemtest-connect
Подключаемся к root\default:
acs-filter-wbemtest-connect-to-default
acs-filter-wbemtest-notification-query
Вставляем фильтр, который мы хотим протестировать:
acs-filter-wbemtest-query
Если фильтр написан правильно, мы увидим окно поиска:
acs-filter-wbemtest-query-result
Если же в фильтре есть ошибки, то мы увидим исключение:
acs-filter-wbemtest-query-exeption

Запись фильтра в ACS коллектор

После всех подготовительных процедур и устранения ошибок с фильтром можно, наконец записать наш фильтр в коллектор. Для начала работы с AdtAdmin.exe необходимо войти на сервер ACS Collector и запустить командную строку от имени администратора. Утилита находится в папке

%windir%\system32\security\AdtServer

Для просмотра текущих фильтров выполняем команду

AdtAdmin.exe /getquery

AdtServer GetQuery просмотр текущих фильтров
Справка по параметрам AdtAdmin.exe https://technet.microsoft.com/en-us/library/bb309436.aspx

Выполняем следующую команду для записи фильтра:

adtadmin -setquery -query:"SELECT * FROM AdtsEvent WHERE NOT (EventId=4769 OR EventId=4768)"

Для того, чтобы проверить, перестали ли попадать отфильтрованные события в базу данных ACS коллектора, необходимо выполнить простой запрос к базе данных ACS:

Select collectiontime, eventid
from Adtserver.dvall
where collectiontime > '2017-04-13 18:00:00:000'
and EventId = 4769
order by CollectionTime DESC

Поиграв с датами и временем можно понять, попадают ли события в базу или нет:
Проверка работы фильтра с помощью SQL запроса к базе данных ACS

Построение фильтров

Данные в базе коллектора хранятся в SQL таблицах, с определённым набором полей. Чёткого соответствия между расположением информации в событии в Event Viewer и её расположением в базе данных ACS нет. Для того, чтобы определить какая информация из Event ID в какое поле базы данных попадает, можно выполнить SQL запрос в SSMS и посмотреть все поля и информацию в них. Имена полей в таблице SQL используются для построения WMI запросов.
Вот пример SQL запроса, который выводит всю информацию из базы данных по Event ID 4776:

Select *
from Adtserver.dvall
where collectiontime > '2017-04-14 15:25:00:000'
AND EventId = 4776
order by CollectionTime DESC

Получение всех полей из базы данных ACS по конкретному событию

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

Account SID
Local System S-1-5-18
Local Service S-1-5-19
Network Service S-1-5-20

Примеры фильтров

Пример 1.  Фильтр, который отбрасывает событие 4688, сгенерированное Local System. 4688 — это событие создания нового процесса, например запуска программы, службы и т.п.

SELECT * FROM AdtsEvent WHERE NOT ((EventId=4688) AND (PrimarySid='S-1-5-18'))

PrimarySid — соответствующее поле в таблице SQL:
Поле PrimarySid в базе данных ACS

Пример 2. Фильтр, который отбрасывает событие 4636 (An account was logged off) с типом входа в систему 3 (Logon Type: 3). Данное событие активно генерируется в течении дня на разных серверах, если включен соответствующий аудит (Audit Logoff), но оно по факту не означает, что пользователь завершил свой сеанс работы, например с общей папкой. Это часто происходит по причине того, что сервер завершает простаивающие подключения.
Найдём с помощью SSMS событие 4636 и посмотрим в какое поле пишется тип входа в систему, чтобы применить это в фильтре:

Select *
from Adtserver.dvall
where collectiontime > '2017-04-18 15:25:00:000'
and EventId = 4634
order by CollectionTime DESC

SCOM ACS
Как видим, интересующее поле называется String02. Применим его в фильтре:

SELECT * FROM AdtsEvent WHERE NOT (EventId=4634 AND String02='3')

Добавить комментарий