MS WEC

✔️ Рекомендуется - Рекомендуемый способ сбора для этого источника событий

Настройка сбора событий с устройств Windows при помощи Агента KUMA (WEC).

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.ru/kuma/4.0/248413

Описание схемы работы

Сбор событий Windows с использованием Windows Event Collector (WEC) позволяет централизованно собирать события с множества устройств Windows в сети. В основе данного способа лежит технология Windows Event Forwarding (WEF), которая обеспечивает передачу событий с источников (рабочие станции и серверы) на центральный сервер-коллектор (WEC). Этот подход упрощает мониторинг и управление событиями в масштабах всей сети, обеспечивая единую точку сбора данных.

Компоненты схемы:

Источники событий: рабочие станции и серверы Windows.
Windows Event Collector или WEC-сервер - сервер, с запущенной службой «Сборщик событий Windows». Данный сервер на основании создаваемых подписок на события получает события от источников и обеспечивает их локальное хранение. Взаимодействие между WEC-сервером и источниками событий осуществляется с использованием протокола удаленного управления Windows (WS-Management protocol). Для настройки доступно два типа подписок:
- Source-initiated subscriptions (Push) — события отправляются источником. Источники настраиваются на отправку событий на WEC-сервер с помощью GPO.
- Collector-initiated subscriptions (Pull) — события собираются WEC-сервером самостоятельно. WEC-сервер подключается к рабочим станциям/серверам и забирает события из локальных журналов.
Агент KUMA - компонент KUMA, устанавливаемый на WEC-сервер для отправки собранных событий с источников в коллектор KUMA.
Коллектор KUMA - компонент KUMA, обеспечивающий прием/нормализацию/агрегацию/фильтрацию событий, полученных от агента KUMA, и их дальнейшую отправку в коррелятор и/или хранилище KUMA.

В данном примере мы рассмотрим вариант Source-initiated subscriptions (режим Push) ввиду того, что этот режим более предпочтителен из-за отсутствия необходимости настройки «прослушивания» входящих соединений службой WinRM на источниках событий.

Подробнее о Windows Event Collector и технологии Windows Event Forwarding:
https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector
https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection

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

По умолчанию на устройствах Windows аудит событий не осуществляется.

Рекомендуется настраивать политику аудита Windows, исходя из перечня событий аудита, которые нужны для работы «коробочных» правил корреляции KUMA (например, вход в систему, запуск процессов и т.д.). При необходимости перечень журналируемых событий аудита в дальнейшем можно расширить.

Перечень событий аудита Windows:
https://support.kaspersky.ru/kuma/4.0/250594

Настройка политики аудита на отдельной рабочей станции/сервере

Windows Event Log Powershell

Чтобы настроить аудит событий, связанных с выполнением команд и скриптов в PowerShell на отдельной рабочей станции/сервере:

Запустите оснастку Редактор локальной групповой политики: нажмите кнопку Win → введите gpedit.msc и запустите Редактор локальной групповой политики от имени администратора.

Перейдите в Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Windows PowerShell.

Выберите Включить ведение журнала модулей.
В появившемся окне Включить ведение журнала модулей:
- Укажите Включено.

В секции Параметры нажмите Показать. В окне Вывод содержания в качестве значения укажите «*» и нажмите ОК.

В окне Включить ведение журнала модулей нажмите ОК.
Выберите Включить регистрацию блоков сценариев PowerShell.
В появившемся окне Включить регистрацию блоков сценариев PowerShell укажите Включено и нажмите ОК.

Убедитесь, что состояние параметров политики соответствует скриншоту ниже.

Windows Event Log Security

Чтобы настроить аудит событий, связанных с входами пользователей, аутентификацией, доступом к ресурсам, изменениями учетных записей и т.д. на отдельной рабочей станции/сервере:

Запустите оснастку Редактор локальной групповой политики: нажмите кнопку Win → введите gpedit.msc и запустите Редактор локальной групповой политики от имени администратора.

Перейдите в Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Конфигурация расширенной политики аудита → Политики аудита системы - Объект локальной групповой политики.
Настройте параметры аудита согласно скриншотам ниже.

При использовании Расширенной политики аудита необходимо включить параметр "Аудит: принудительное переопределение параметров категории политики аудита параметрами подкатегории политики аудита (Windows Visa или более поздние версии) в целях переопределения параметров, указанных в Политике аудита.

Дополнительно необходимо включить журналирование команд, выполняемых в командной строке (cmd):

Запустите оснастку Редактор локальной групповой политики: нажмите кнопку Win → введите gpedit.msc и запустите Редактор локальной групповой политики от имени администратора.
Перейдите в Конфигурация компьютера → Административные шаблоны → Система → Аудит создания процессов.
Активируйте параметр политики Включать командную строку в события создания процессов.

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

Windows Event Log System

Дополнительные настройки для журнала System не требуются.

Windows Event Log Defender

Дополнительные настройки для журнала Microsoft-Windows-Windows Defender/Operational не требуются.

Настройка политики аудита для группы рабочих станций/серверов средствами GPO

При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов настройки.

Чтобы настроить политику аудита для группы рабочих станций/серверов средствами GPO:

Создайте группу компьютеров средствами Active Directory – пользователи и компьютеры, задайте имя группе, например, KUMA WEC. Добавьте в данную группу рабочие станции/серверы, с которых предполагается сбор событий.

Если предполагается сбор событий с контроллеров домена, в таком случае, контроллеры домена можно не добавлять в созданную группу компьютеров, добавив отдельно в Фильтр безопасности при настройке GPO

Для того, чтобы изменения вступили в силу (в данном случае членство в новой группе), выполните перезагрузку устройства. Альтернативным вариантом может быть перевыпуск Kerberos-тикетов для устройства с помощью klist.exe.
На контроллере домена запустите оснастку Управление групповой политикой: нажмите Win + R → gpmc.msc.
Выберите существующий объект групповой политики или создайте новый. В данном примере создается новый объект групповой политики Audit Policy for KUMA: ПКМ Объекты групповой политики → Создать → введите в имени Audit Policy for KUMA.

Далее выберите созданный объект групповой политики Audit Policy for KUMA и нажмите Изменить.

Windows Event Log Powershell

Чтобы настроить аудит событий, связанных с выполнением команд и скриптов в PowerShell:

Перейдите в Конфигурация компьютера → Политики → Административные шаблоны → Компоненты Windows → Windows PowerShell.

Выберите Включить ведение журнала модулей.
В появившемся окне Включить ведение журнала модулей:
- Укажите Включено.

В секции Параметры нажмите Показать. В окне Вывод содержания в качестве значения укажите «*» и нажмите ОК.

В окне Включить ведение журнала модулей нажмите ОК.
Выберите Включить регистрацию блоков сценариев PowerShell.
В появившемся окне Включить регистрацию блоков сценариев PowerShell укажите Включено и нажмите ОК.

Убедитесь, что состояние параметров политики соответствует скриншоту ниже.

Windows Event Log Security

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

Перейдите в Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Конфигурация расширенной политики аудита → Политики аудита.
Настройте параметры аудита согласно скриншотам ниже.

Дополнительно необходимо включить журналирование команд, выполняемых в командной строке (cmd):

Перейдите в Конфигурация компьютера → Политики → Административные шаблоны → Система → Аудит создания процессов.
Активируйте параметр политики Включать командную строку в события создания процессов.

Windows Event Log System

Дополнительные настройки для журнала System не требуются.

Windows Event Log Defender

Дополнительные настройки для журнала Microsoft-Windows-Windows Defender/Operational не требуются.

Далее вернитесь в Управление групповой политикой → выберите объект групповой политики Audit Policy for KUMA → в окне справа Фильтры безопасности удалите группу Прошедшие проверку и добавьте группу KUMA WEC.

Нажмите ПКМ на домен и выберите Связать существующий объект групповой политики → выберите Audit Policy for KUMA и нажмите ОК.

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

В целом, групповые политики Active Directory можно назначать на OU, сайт или весь домен. Для того, чтобы новые параметры аудита, заданные в GPO, были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:
- перезагрузка устройства и вход пользователя;
- автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени);
- вручную с помощью команды gpupdate (на рабочей станции/сервере);
- вручную из консоли Group Policy Management Console (на контроллере домена, только для OU);
- вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена).

Для проверки успешного применения GPO выполните следующую команду на одной из рабочих станций/сервере:

auditpol.exe /get /category:* | Select-String -Pattern "Успех"

Убедитесь, что параметры аудита соответствуют скриншоту ниже.

Настройка WEC-сервера

Настройка службы Windows Event Collector (WEC)

Проверьте, что служба WinRM запущена на WEC-сервере с помощью следующей команды в PowerShell:

Test-WSMan

Вывод в случае если служба WinRM запущена:

Если появилось сообщение, что «Клиенту не удается подключиться к узлу назначения, указанному в запросе. Убедитесь, что служба на узле назначения работает и принимает запросы», запустите на WEC-сервере службу WinRM с помощью следующей команды в PowerShell:

winrm qc

При применении команды согласитесь с выполнением изменений. После включения службы WinRM WEC-сервер начнет «прослушивать» соединения на порт TCP/5985 от источников событий.

Команда winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно следующей командой:

winrm set winrm/config/Winrs ‘@{AllowRemoteShellAccess = "false"}’
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’ # проверка, что WinRS отключен

Запустите на WEC-сервере службу сборщика событий Windows («Сборщик событий Windows») с помощью следующей команды в PowerShell:

wecutil qc

При включении службы сборщика событий Windows в Windows Firewall автоматически создается разрешающее правило для входящих соединений по TCP/5985.

Настройка подписки на WEC-сервере

Чтобы настроить подписку на WEC-сервере:

Нажмите кнопку Win, введите eventvwr.msc и запустите Просмотр событий от имени администратора.
Выберите Подписки → правой кнопкой мыши Создать подписку → Укажите имя подписки, например, KUMA WEC и тип подписки Инициировано исходным компьютером.

Выберите группу устройств, события которой требуется собирать. В нашем примере – это ранее созданная группа KUMA WEC: нажмите Выбрать группы компьютеров → Добавить доменный компьютер → в поле Введите имена выбираемых объектов укажите ранее созданную группу компьютеров и нажмите ОК.

В качестве альтернативы вместо группы компьютеров можно добавить необходимые рабочие станции/серверы по отдельности.

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

Задайте собираемые события: Выбрать события → перейдите на вкладку XML и установите флажок Изменить запрос вручную.
Вставьте в поле следующий фильтр событий:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-PowerShell/Operational">
    <!-- Windows Event Log Powershell (4103, 4104) -->
    <Select Path="Microsoft-Windows-PowerShell/Operational">*[System[(EventID=4103 or EventID=4104)]]</Select>
  </Query>
  <Query Id="1" Path="Security">
    <!-- Windows Event Log Security -->
    <Select Path="Security">*[System[(EventID=1102 or EventID=4624 or EventID=4625 or EventID=4656 or EventID=4657 or EventID=4663 or EventID=4672 or EventID=4688 or EventID=4697 or EventID=4720 or EventID=4722 or EventID=4723 or EventID=4724 or EventID=4725 or EventID=4726 or EventID=4731 or EventID=4732 or EventID=4733 or EventID=4734 or EventID=4735 or EventID=4738 or EventID=5140 or EventID=5145)]]</Select>
  </Query>
  <Query Id="2" Path="System">
    <!-- Windows Event Log System -->
    <Select Path="System">*[System[(EventID=7036 or EventID=7045)]]</Select>
  </Query>
  <Query Id="3" Path="Microsoft-Windows-Windows Defender/Operational">
    <!-- Windows Event Log Defender -->
    <Select Path="Microsoft-Windows-Windows Defender/Operational">*[System[(EventID=1006 or EventID=1015 or EventID=1116 or EventID=1117 or EventID=5001 or EventID=5010 or EventID=5012 or EventID=5101)]]</Select>
  </Query>
</QueryList>

Нажмите ОК.

Рекомендации по настройке аудита событий Windows:
https://kb.kuma-community.ru/books/kuma-how-to/page/poleznye-ssylki-po-ib

Далее в окне Свойства подписки нажмите Дополнительно и для параметра Оптимизация доставки событий укажите Уменьшенная задержка.
Нажмите ОК.

В одну подписку можно добавить не более 22 уникальных Event ID (кодов событий). Если указать больше, то на стороне источников событий (Журналы приложений и служб/Microsoft/Windows/Eventlog-ForwardingPlugin/Operational) появится ошибка "Не удается создать подписку <Наименование подписки>. Код ошибки: 5004.", при этом события от источников перестанут поступать на WEC-сервер.

Поэтому, если стоит задача собирать большое количество разных типов событий, в таком случае создайте несколько подписок, в каждой из которых будет свой уникальный набор Event ID.

Если в подписке не задан фильтр по Event ID, то есть используется значение по умолчанию "<Все коды событий>", ограничение в 22 уникальных Event ID отсутствует и выполняется сбор всех журналируемых событий.

При наличии одинаковых Event ID в разных подписках, события будут дублироваться, как на WEC-сервере, так и в KUMA. Поэтому при создании нескольких подписок проверьте наличие дубликатов Event ID.

Настройка WinRM и подписки на источниках событий

Для отдельной рабочей станции/сервера

Настройка службы WinRM

Проверьте наличие запущенной службы WinRM на рабочей станции/сервере с помощью следующей команды в PowerShell:

Test-WSMan

Вывод в случае, если служба WinRM запущена:

Если появилось сообщение, что «Клиенту не удается подключиться к узлу назначения, указанному в запросе. Убедитесь, что служба на узле назначения работает и принимает запросы», запустите на рабочей станции/сервере службу WinRM с помощью следующей команды в PowerShell:

winrm qc

При применении команды согласитесь с выполнением изменений, кроме «Служба WinRM не настроена на разрешение удаленного управления компьютером. Разрешите исключение брандмауэра WinRM».

После включения службы WinRM рабочая станция/сервер начнет «прослушивать» соединения на порт TCP/5985. Для отключения данного listener’а (т.к. рабочая станция/сервер инициирует соединение к WEC-серверу, выступая в качестве клиента) выполните следующую команду в PowerShell:

Remove-WSManInstance winrm/config/Listener -SelectorSet @{Address="*";Transport="http"}

Команда winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно следующей командой:

winrm set winrm/config/Winrs ‘@{AllowRemoteShellAccess = "false"}’
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’ # проверка, что WinRS отключен

На источнике событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers («Читатели журнала событий»):

Нажмите кнопку Win → введите lusrmgr.msc и запустите Локальные пользователи и группы от имени администратора.
В появившемся окне перейдите в Группы, выберите группу Читатели журнала событий и нажмите правой кнопкой мыши Свойства.
В свойствах группы нажмите Добавить, в Размещение выберите имя рабочей станции и в поле Введите имена выбираемых объектов укажите NETWORK SERVICE.
После ввода УЗ нажмите Проверить имена.
Как только УЗ будет найдена нажмите ОК.
В окне свойств группы нажмите еще раз ОК для применения изменений группы.

Для сбора событий журнала Security с контроллера домена необходимо предоставить доступ к журналу встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20), из-под которой запускается сервис WinRM.
Для этого на контроллере домена в PowerShell выполните следующую команду:
wevtutil sl security /ca:'O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)'

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

Чтобы настроить подписку:

Нажмите кнопку Win, введите Политики и запустите Изменение групповой политики от имени администратора.
В появившемся окне перейдите в Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Пересылка событий → Настроить конечный диспетчер подписки.
Выберите Включено и нажмите Показать.
В появившемся окне введите параметры WEC-сервера:

Server=http://<FQDN WEC-сервера>:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) источников событий к WEC-серверу за новыми инструкциями по пересылке журналов.

Microsoft рекомендует настраивать параметр Refresh в зависимости от частоты внесения изменений в подписки. Если подписки изменяются нечасто, для параметра Refresh можно установить значение в несколько часов, например, Refresh=43200 (обновление раз в 12 часов).

Источники событий должны иметь возможность «резолвить» FQDN WEC-сервера для отправки событий. Для этого создайте A-запись на DNS-сервере или создайте запись локально в файле hosts

После применения данной настройки перезапустите службу WinRM c помощью PowerShell-команды:

Restart-Service -Name WinRM

Для группы рабочих станций/серверов средствами GPO

Настройка службы WinRM

При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов.

Чтобы настроить службу WinRM для группы рабочих станций/серверов средствами GPO:

На контроллере домена запустите оснастку Управление групповой политикой: нажмите Win + R → gpmc.msc.
Выберите ранее использовавшийся объект групповой политики Audit Policy for KUMA и нажмите Изменить.

В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Системные службы → в списке служб найдите «Служба удаленного управления Windows (WS-Management)» → Свойства и укажите параметры согласно скриншоту ниже.

Нажмите Применить и ОК.
Далее перейдите в Конфигурация компьютера → Настройка → Параметры панели управления → Службы → справа в окне нажмите Создать → Службы → укажите параметры согласно скриншоту ниже.

Перейдите во вкладку Восстановление и укажите параметры согласно скриншоту ниже.

Нажмите Применить и ОК.
Перейдите в Конфигурация компьютера → Политики → Административные шаблоны → Компоненты Windows → Удаленное управление Windows → Служба удаленного управления Windows → выберите Разрешить удаленное администрирование сервера средствами WinRM и укажите параметры согласно скриншоту ниже.

Перейдите в Конфигурация компьютера → Политики → Административные шаблоны → Компоненты Windows → Удаленная оболочка Windows → выберите Разрешить доступ к удаленной оболочке и укажите параметры согласно скриншоту ниже.

Также на источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers («Читатели журнала событий»):

Выберите ранее использовавшийся объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера → Настройка → Параметры панели управления → нажмите правой кнопкой мыши на Локальные пользователи и группы → Создать → Локальная группа. В появившемся окне укажите параметры согласно скриншоту ниже.

При добавлении члена локальной группы введите NETWORK SERVICE и нажмите ОК.

Нажмите Применить и ОК.

Для того, чтобы новые параметры групповой политики Audit Policy for KUMA были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:

перезагрузка устройства и вход пользователя
автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени)
вручную с помощью команды gpupdate (на рабочей станции/сервере)
вручную из консоли Group Policy Management Console (на контроллере домена, только для GPO)
вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена)

Проверьте наличие запущенной службы WinRM на одной из рабочих станций/сервере с помощью следующей команды в PowerShell:

Test-WSMan

Вывод в случае, если служба WinRM запущена:

Убедитесь, что WinRS отключен с помощью следующей команды:

winrm get winrm/config | findstr ‘AllowRemoteShellAccess’

Убедитесь, что порт TCP/5985 не «прослушивается» (т.к. рабочая станция/сервер инициирует соединение к WEC-серверу, выступая в качестве клиента):

netstat -aon -p TCP  # выполнить в cmd

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

Чтобы настроить подписку для группы рабочих станций/серверов средствами GPO:

На контроллере домена запустите оснастку Управление групповой политикой: нажмите Win + R → gpmc.msc.
Выберите ранее использовавшийся объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера → Политики → Административные шаблоны → Компоненты Windows → Пересылка событий → Настроить конечный диспетчер подписки.
Выберите Включено и нажмите Показать.
В появившемся окне введите параметры WEC-сервера:

Server=http://<FQDN WEC-сервера>:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) источников событий к серверу за новыми инструкциями по пересылке журналов.

перезагрузка устройства и вход пользователя
автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени)
вручную с помощью команды gpupdate (на рабочей станции/сервере)
вручную из консоли Group Policy Management Console (на контроллере домена, только для OU)
вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена)

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

Убедитесь, что на WEC-сервер поступают события с рабочих станций/серверов:

На WEC-сервере нажмите кнопку Win, введите eventvwr.msc и запустите Просмотр событий от имени администратора.
Перейдите в Журналы Windows → Перенаправленные события. Если в появившемся окне Перенаправленные события отображаются события с источников, значит подписка работает корректно.

Для MS Server 2016 и 2019 в случае если события не пересылаются, выполнить шаги по этой инструкции. При добавлении разрешения для URL-адреса с помощью netsh http add urlacl добавьте кавычки "..." в параметре SDDL:
netsh http delete urlacl url=http://+:5985/wsman/ netsh http add urlacl url=http://+:5985/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)" netsh http delete urlacl url=https://+:5986/wsman/ netsh http add urlacl url=https://+:5986/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"

В случае если события определенного журнала не отправляются с источника событий проверьте на данном источнике в журнале Microsoft/Windows/Event_forwardingPlugin/Operational наличие событий с кодом 5004 (ошибка отправки журналов на WEC-сервер).
При наличии событий с кодом 5004 выполните рекомендации из статьи:
https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/system-management-components/security-event-log-forwarding-fails-error-0x138c-5004

Настройка коллектора и агента KUMA

Создание коллектора KUMA

Для создания коллектора в веб-интерфейсе KUMA:

Перейдите в раздел Ресурсы и нажмите на кнопку Подключить источник.
В появившемся окне мастера настройки Создание коллектора на первом шаге (Подключение источников) выберите Имя коллектора и Тенант, к которому будет принадлежать создаваемый коллектор.

На втором шаге мастера (Транспорт) укажите параметры коннектора для взаимодействия с агентом. В данном случае рекомендуется использовать http. В поле URL задайте FQDN/порт (порт, на котором коллектор будет ожидать входящие подключения от агента. Выбирается любой из незанятых, выше 1024). В данном примере будет использоваться 5151. В качестве разделителя укажите \0.

В поле URL можно указать только порт при инсталляции All-in-one.

На вкладке Дополнительные параметры для шифрования передаваемых данных между агентом и коллектором выберите Режим TLS - С верификацией.

На третьем шаге мастера укажите нормализатор. В данном случае рекомендуется использовать «коробочный» нормализатор [OOTB] Microsoft Products for KUMA 3.

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

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

Нажмите Сохранить.
После выполнения вышеуказанных действий в разделе Ресурсы → Активные сервисы появится созданный сервис коллектора.

Установка коллектора KUMA

Чтобы установить коллектор KUMA:

Выполните подключение к CLI сервера, на котором планируется развертывание коллектора KUMA.
Для установки сервиса коллектора в командной строке выполните команду под учетной записью root, скопированную на прошлом шаге.

При необходимости добавьте используемый порт сервиса коллектора в исключения МЭ ОС и обновите параметры службы.

# Пример для firewalld
firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp|udp –permanent
firewall-cmd –reload

# Пример для ufw
ufw allow <порт, выбранный для коллектора>/tcp|udp
ufw reload

После успешной установки сервиса его статус в веб-консоли KUMA изменится на ВКЛ с зеленой индикацией.

Создание сервисной учетной записи

Для функционирования агента KUMA предварительно необходимо создать доменную сервисную учетную запись, с помощью которой будет выполняться запуск службы агента KUMA и обеспечиваться доступ к журналам событий, полученных от рабочих станций/серверов Windows (журнал Forwarded Events).

В качестве более безопасной альтернативы обычной пользовательской учетной записи рекомендуется использование управляемой учетной записи службы (MSA). См. Приложение А. Использование Managed Service Accounts (MSA)

Добавление сервисной учетной записи в группу "Читатели журнала событий"

Для доступа агента KUMA к журналу Forwarded Events добавьте созданную сервисную учетную запись в локальную группу Читатели журнала событий на WEC-сервере.

Чтобы добавить учетную запись в локальную группу Читатели журнала событий:

Нажмите кнопку Win.
Введите lusrmgr.msc и запустите Локальные пользователи и группы от имени администратора.
В появившемся окне перейдите в Группы, выберите группу Читатели журнала событий и нажмите правой кнопкой мыши Свойства.
В свойствах группы нажмите Добавить и в поле Введите имена выбираемых объектов укажите <имя созданной сервисной учетной записи>.
После ввода УЗ нажмите Проверить имена.

Как только УЗ будет найдена нажмите ОК.
В окне свойств группы нажмите еще раз ОК для применения изменений группы.

Назначение прав входа в качестве службы

Разрешите сервисной учетной записи вход в качестве службы (Log on as a service) на WEC-сервере. Это необходимо, чтобы учетная запись могла использоваться для запуска и работы служб (сервисов). В данном случае для запуска и работы службы агента KUMA.

Чтобы разрешить учетной записи вход в качестве службы:

Нажмите кнопку Win, введите secpol.msc и запустите Локальная политика безопасности от имени администратора.
В появившемся окне перейдите в Локальные политики → Назначение прав пользователя, выберите политику Вход в качестве службы и нажмите правой кнопкой мыши Свойства.
В свойствах политики нажмите Добавить пользователя или группу и в поле Введите имена выбираемых объектов укажите <имя созданной сервисной учетной записи>.
После ввода УЗ нажмите Проверить имена.
Как только УЗ будет найдена нажмите ОК.

В окне свойств политики нажмите еще раз ОК для применения изменений группы.

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

Создание ресурса агента KUMA

Для создания ресурса агента в веб-интерфейсе KUMA:

Перейдите на вкладку Ресурсы → Агенты и нажмите на кнопку Добавить агент.
В окне Создание агента на вкладке Общие параметры укажите Имя агента и Тенант, которому он будет принадлежать. В поле Описание можно добавить описание сервиса.

Перейдите на вкладку Подключение 1 и укажите следующие параметры:
- В блоке параметров Коннектор укажите:
  - Название коннектора
  - Тип – WEC
  - Журналы Windows – ForwardedEvents

В блоке параметров Точки назначения укажите параметры точки назначения:
- В поле Название укажите имя точки назначения (в качестве точки назначения для агента будет выступать ранее созданный коллектор).
- В раскрывающемся списке Тип выберите тип точки назначения (в нашем примере http по аналогии с созданным коллектором).
- URL сервиса коллектора, который будет обрабатывать события, собранные агентом KUMA. URL созданного коллектора см. в Разделе Создание коллектора KUMA.
  Доступные форматы URL:
  <имя хоста>:<номер порта>;
  <IPv4-адрес>:<номер порта>;
  <IPv6-адрес><номер порта>.
  При необходимости можно добавить несколько URL для балансировки нагрузки или обеспечения отказоустойчивости.

Перейдите на вкладку Дополнительные параметры и для шифрования передаваемых данных между агентом и коллектором выберите Режим TLS - С верификацией. Также укажите в качестве Разделителя /0.

Дополнительные параметры точки назначения (например, Разделитель и режим TLS) должны совпадать с дополнительными параметрами коллектора, с которым вы хотите связать агент.

Точек назначения может быть несколько. Их можно добавить с помощью кнопки Добавить точку назначения.

Нажмите Создать для создания ресурса агента.

Публикация агента KUMA

Когда ресурс агента создан, можно перейти к созданию сервиса агента в KUMA.

Чтобы создать сервис агента в веб-интерфейсе KUMA:

В веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы нажмите Добавить.
В появившемся окне Выберите сервис выберите только что созданный ресурс агента и нажмите Создать сервис.

Сервис агента создан в веб-интерфейсе KUMA и отображается в разделе Ресурсы → Активные сервисы. Теперь сервис агента необходимо установить на WEC-сервере для сбора событий Windows.

После публикации агента скопируйте идентификатор сервиса для последующей установки сервиса (службы) агента на WEC-сервере.

Установка агента KUMA

Перед установкой агента KUMA убедитесь, что для WEC-сервера, где предполагается установка, открыты следующие сетевые доступы:

Порт TCP/7210 к Ядру KUMA.
К Коллектору KUMA, предназначенного для приема и обработки событий Windows. Порт и протокол, указанные при создании Коллектора (см. Раздел Создание коллектора KUMA).

Также убедитесь, что на WEC-сервере, где предполагается установка агента KUMA, «резолвится» DNS-имя сервера KUMA (для распределенной инсталляции DNS-имя сервера Ядра и сервера коллектора KUMA). При необходимости добавьте соответствующие записи в файл hosts на WEC-сервере, либо создайте A-записи на DNS-сервере организации.

Чтобы установить агент KUMA на WEC-сервер:

Скопируйте файл kuma.exe в папку на WEC-сервере. Для установки рекомендуется использовать папку C:\Users\<имя пользователя>\Desktop\KUMA.
Файл kuma.exe находится внутри установщика в директории /kuma-ansible-installer/roles/kuma/files/.

Запустите командную строку на WEC-сервере с правами администратора и перейдите в папку с файлом kuma.exe.
Выполните следующую команду:

kuma agent --core https://<полное доменное имя сервера ядра KUMA>:<порт, используемый сервером ядра KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса агента, созданного в KUMA> --user <имя пользователя, под которым будет работать агент, включая домен, в формате domain\username> --install

Пример:
kuma agent --core https://kuma.example.com:7210 --id XXXXX --user domain\username –install

Если агент устанавливается из-под доменной учетной записи пользователь указывается в формате <домен>\<имя учетной записи>, например, demo\user

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

kuma.exe license --show

Если вы хотите принять лицензионное соглашение, выполните команду и нажмите y:

kuma.exe license

Введите пароль пользователя, под которым будет работать служба агента.
В процессе установки будет создана папка C:\ProgramData\Kaspersky Lab\KUMA\agent\<идентификатор агента>, в которую будет установлен сервис агента KUMA.

После установки сервис (служба) агента запускается автоматически. Сервис также настроен на перезапуск в случае сбоев. Агент можно перезапустить из веб-интерфейса KUMA, но только когда сервис активен. В противном случае сервис требуется перезапустить вручную на устройстве Windows.

Далее перейдите в веб-интерфейс KUMA и убедитесь в успешности запуска агента - статус сервиса агента KUMA WEC должен измениться на ВКЛ с зеленой индикацией.

Чтобы удалить агент KUMA с WEC-сервера по окончании тестирования продукта:

Запустите командную строку на WEC-сервере с правами администратора и найдите папку с файлом kuma.exe.
Выполните команду ниже:

kuma.exe agent --id <идентификатор сервиса агента, созданного в KUMA> --uninstall

Проверка поступления событий Windows в KUMA

Для проверки, что сбор событий Windows успешно настроен перейдите в Ресурсы → Активные сервисы → выберите ранее созданный коллектор для событий Windows и нажмите Перейти к событиям.

В открывшемся окне События убедитесь, что присутствуют события с устройств Windows.

Приложение А. Использование Managed Service Accounts (MSA)

Управляемые учетные записи служб (Managed Service Accounts – MSA) - это специальный тип учетных записей служб в Active Directory (AD), предназначенный для повышения безопасности и упрощения администрирования.

Создаваемая учетная запись службы (MSA) ассоциируется с определенным сервером. Эта учетная запись имеет автоматически генерируемый сложный пароль (120 символов) и поддерживается устройством без ручного вмешательства. Таким образом, MSA обеспечивает безопасный и удобный способ запуска служб на устройствах Windows.

Обычные сервисные учетные записи, которые используются для запуска служб (например, DOMAIN\ServiceAccount) создают административные сложности:

Ручное управление паролями: Администратор должен регулярно вручную менять пароль, а затем обновлять его в настройках службы на всех серверах, где она работает. Это трудоемко и чревато простоями, если пароль не сменить вовремя.
Риск безопасности: Часто администраторы устанавливают для таких учетных записей сложные пароли и никогда их не меняют, что создает угрозу безопасности.
Принцип одного сервера: Одна учетная запись не должна использоваться на нескольких серверах одновременно по соображениям безопасности (сложность аудита и отзыва).

Основные особенности MSA:

Автоматическое управление паролями: Система сама генерирует очень сложный случайный пароль (120 символов) и регулярно его меняет (по умолчанию каждые 30 дней). Вам никогда не нужно его знать или вводить.
Привязка к одному компьютеру: Один MSA может быть привязан только к одному серверу (компьютеру) в домене. Это обеспечивает изоляцию служб.
Упрощенное администрирование: Вы просто указываете службе использовать MSA, и система сама на периодической основе обновляет пароль.
Нельзя использовать для интерактивного входа: Эту учетную запись нельзя использовать для входа в систему по RDP или в консоли сервера.

Типы MSA:

Standalone Managed Service Account (sMSA) – работает только на одном сервере.
Group Managed Service Account (gMSA) – может использоваться на нескольких серверах в домене (например, в кластере или ферме).

Настройка sMSA

Предварительные требования:

ОС Windows Server 2008 R2 / Windows 7 или выше.
Требования к функциональному уровню домена: Минимальный уровень — Windows Server 2008 R2.
Наличие powershell-модуля ActiveDirectory

Шаги по настройке:

Действия на контроллере домена

Запустите PowerShell и выполните команду для создания sMSA:

New-ADServiceAccount -Name "Имя sMSA" -Description "Описание учетной записи" -Enabled $true -RestrictToSingleComputer

Привяжите sMSA к WEC-серверу:

$Identity = Get-ADComputer -identity "Имя WEC-сервера"

Add-ADComputerServiceAccount -Identity $identity -ServiceAccount "Имя sMSA"

Убедитесь, что привязка sMSA к WEC-серверу выполнена успешно:

Get-ADComputer -Identity "Имя WEC-сервера" -Properties msDS-HostServiceAccount

После создания учетная запись появится в контейнере Managed Service Accounts вашего домена. Чтобы увидеть его в оснастке "Пользователи и компьютеры Active Directory" (ADUC), необходимо включить просмотр расширенных функций (View -> Advanced Features).

Действия на WEC-сервере

sMSA должен быть "установлен" на сервере, где он будет использоваться. Это сообщает системе, что данный сервер имеет право использовать эту управляемую учетную запись.

Запустите PowerShell с правами администратора и выполните команду для установки модуля Active Directory:

Add-WindowsFeature RSAT-AD-PowerShell

Выполните установку sMSA с использованием доменной учетной записи с соответствующими правами (в данном примере использовалась учетная запись с правами администратора домена):

Install-ADServiceAccount -Identity "Имя_sMSA"

Убедитесь, что sMSA успешно установлен:

Test-ADServiceAccount -Identity "Имя_sMSA"

Если команда выполняется без ошибок, значит sMSA успешно установлен на сервере. Результат в случае успеха: True

Назначьте sMSA права Входа в качестве службы (Log on as a service) и добавьте в группу Читатели журнала событий (Event Log Readers)

При установке через Install-ADServiceAccount права Вход в качестве службы (Log on as a service) назначаются автоматически

Add-LocalGroupMember -Group "Event Log Readers" -Member "UserName"

Выполните установку агента KUMA, указав в качестве пользователя учетную запись sMSA в формате DOMAIN\sMSA_Name$ (см. раздел Установка агента KUMA).

Оставьте поле User password пустым

Полезные ссылки

https://techcommunity.microsoft.com/blog/askds/managed-service-accounts-understanding-implementing-best-practices-and-troublesh/397009

Приложение B. Отказоустойчивый сбор событий с WEC-сервером

События на контроллерах домена хранятся очень мало – ротация примерно через 3-5 минут. Поэтому чтобы гарантировать доставку, если по какой-то причине WEС не доступен, предлагается следующая схема:

использовать 2 WEC сервера
все DC отправляют события не на один, а на 2 WEC сервера (события обоих WEC дублируются)
на каждом WEC сервере установлены KUMA Agent
оба KUMA Agent отправляют события в ОДИН и тот же коллектор Windows (это важный момент)
на коллекторе Windows настраивается агрегация события, чтобы дубли событий с обоих WEC серверов были агрегированы в одно событий

С этим одним событием, прошедшее через такую сложную цепочку и работает KUMA. Это позволит выполнять обслуживание, перезагружать WEC коллекторы (но не одновременно), без потери потока данных с контролеров.

MS WEC

Описание схемы работы

Рекомендации для сервера WEC

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

Настройка политики аудита на отдельной рабочей станции/сервере

Windows Event Log Powershell

Windows Event Log Security

Windows Event Log System

Windows Event Log Defender

Настройка политики аудита для группы рабочих станций/серверов средствами GPO

Windows Event Log Powershell

Windows Event Log Security

Windows Event Log System

Windows Event Log Defender

Настройка WEC-сервера

Настройка службы Windows Event Collector (WEC)

Настройка подписки на WEC-сервере

Настройка WinRM и подписки на источниках событий

Для отдельной рабочей станции/сервера

Настройка службы WinRM

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

Для группы рабочих станций/серверов средствами GPO

Настройка службы WinRM

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

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

Настройка коллектора и агента KUMA

Создание коллектора KUMA

Установка коллектора KUMA

Создание сервисной учетной записи

Добавление сервисной учетной записи в группу "Читатели журнала событий"

Назначение прав входа в качестве службы

Создание ресурса агента KUMA

Публикация агента KUMA

Установка агента KUMA

Проверка поступления событий Windows в KUMA

Приложение А. Использование Managed Service Accounts (MSA)

Приложение B. Отказоустойчивый сбор событий с WEC-сервером