MS WEC

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

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

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

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

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

сбора

Сбор событий Windows с WECиспользованием (Windows Event Collector)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

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

 

Отказоустойчивый сбор событий с WEC

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

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

Источники событий (рабочие станции/серверы). 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 можно почитать здесь: https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector.

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

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

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

Запустите оснастку Локальная политика безопасности (нажмите кнопку Win -> введите secpol.msc и запустите Локальная политика безопасности от имени администратора).

Перейдите в политику аудита (Локальные политики -> Политика аудита).

Настройте параметры аудита согласно скриншоту (при необходимости включите аудит оставшихся политик).

Примеры рекомендованных политик можно найти тут

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

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

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

Для того, чтобы изменения вступили в силу (в данном случае членство в новой группе), необходимо выполнить перезагрузку устройства. Альтернативным вариантом может быть перевыпуск Kerberos-тикетов для устройства с помощью klist.exe.

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

На контроллере домена запустите оснастку Управление групповой политикой (нажмите Win + R -> gpmc.msc).

Выберите существующий объект групповой политики или создайте новый. В данном примере создается новый объект групповой политики Audit Policy for KUMA (правой кнопкой мыши Объекты групповой политики -> Создать -> введите в имени Audit Policy for KUMA).

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

В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политики аудита и настройте параметры аудита согласно скриншоту (при необходимости включите аудит оставшихся политик).

Далее вернитесь в Управление групповой политикой -> выберите объект групповой политики 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 запустите оснастку Локальная политика безопасности на одной из рабочих станций/сервере (нажмите WIN + R -> введите secpol.msc и запустите Локальная политика безопасности от имени администратора) -> перейдите в политику аудита (Локальные политики >  Политика аудита) -> убедитесь, что параметры аудита соответствуют скриншоту.

Примеры рекомендованных политик аудита можно найти тут

Настройка 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-сервере

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

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

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

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

Задайте собираемые события (Выбрать события -> Настройте параметры, как на скриншоте ниже). В данном примере с источников собираются следующие события (Рекомендованные ID события можно найти тут): 4624,4625,4662,4719,4720,4722,4724,4725,4726,4728,4729,4739,4740,4767,4768,4769,4771,5136.

Нажмите ОК.

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

В одну подписку можно добавить не более 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 (не IP !!!) 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 инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов.

На контроллере домена запустите оснастку Управление групповой политикой (нажмите 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

Для сбора событий журнала 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)'

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

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

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

Server=http://<обязательно FQDN сервера-коллектора>:5985/wsman/SubscriptionManager/WEC,Refresh=60

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

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

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

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

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

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

Убедитесь, что на 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 сервер), если там есть такие события, то выполните рекомендации по этой статье: 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/порт (выбирается любой из незанятых), на котором коллектор будет ожидать соединение от агента. В качестве разделителя укажите \0.

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

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

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

Шаги мастера настройки с четвертого по шестой можно пропустить и вернуться к их настройке позднее.

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

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

Также после выполнения вышеуказанных действий на вкладке Ресурсы -> Активные сервисы появится созданный сервис коллектора.

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

Выполните подключение к CLI KUMA (установка коллектора выполняется с правами root).

Для установки сервиса коллектора в командной строке выполните команду, скопированную на прошлом шаге.

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

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

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

Создание агента KUMA

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

В открывшейся вкладке Общие параметры укажите Имя агента и Тенант, к которому он будет принадлежать.

На вкладке Подключение 1 в параметрах коннектора задайте имя коннектора, тип wec и выберите из выпадающего списка журналы Windows типа ForwardedEvents. Также можно в ручном режиме задать дополнительные журналы Windows.

В секции Точки назначения укажите имя точки назначения, тип http (должен совпадать с настройками коллектора). Задайте URL в формате fqdn:port (FQDN коллектора и порт, должны совпадать с настройками коллектора).

В дополнительных параметрах укажите Режим TLS С верификацией, если требуется шифровать соединение между коллектором и агентом (настройка должна совпадать с соответствующей на стороне коллектора). Укажите разделитель \0 (должен совпадать с настройками коллектора). Также на изображении ниже приведены дополнительные параметры и их рекомендуемые значения.

После настройки дополнительных параметров сохраните созданный ресурс агента.

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

В разделе Ресурсы -> Активные сервисы опубликуйте созданную конфигурацию KUMA Windows Agent. Для этого нажмите Создать сервис -> выберите созданный сервис агента Windows WEC Agent и нажмите Создать сервис.

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

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

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

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

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

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

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

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

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

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

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

Выполняется на WEC-сервере, который обеспечивает прием событий от источников (рабочих станций/серверов). Предварительно FQDN Core KUMA должен быть добавлен в файл hosts на WEC-сервере, либо добавлен на DNS-сервере.

На WEC-сервере рекомендуется создать папку C:\Users\<имя пользователя>\Desktop\KUMA.

Далее скопируйте в данную папку исполняемый файл kuma.exe.

Файл kuma.exe находится в архиве пакетов установки KUMA.

Для установки агента KUMA запустите командную строку с правами администратора.

Примите лицензионное соглашение: C:\Users\<имя пользователя>\Desktop\KUMA\kuma.exe license

Перейдите в папку C:\Users\<имя пользователя>\Desktop\KUMA 

Запустите установку агента командой:

C:\Users\<имя пользователя>\Desktop\KUMA>kuma.exe agent --core https://<DOMAIN-NAME-KUMA-CORE-Server>:7210 --id <Windows Agent ID> –-user <Имя сервисной доменной УЗ> --install

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

Во время установки сервиса система запросит пароль. Введите пароль сервисной доменной учетной записи.

В результате, на WEC-сервере будет установлен сервис KUMA Windows Agent <Windows Agent ID>.

Если статус агента  в веб-интерфейсе KUMA красный, необходимо удостовериться в доступности портов 7210 и порта коллектора Windows по направлению от агента к KUMA Collector. 

Для удаления сервиса агента KUMA по окончанию тестирования продукта выполните следующую команду:

C:\Users\<имя пользователя>\Desktop\KUMA>kuma.exe agent --id <Windows Agent ID> --uninstall

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

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

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

---

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

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

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

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

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

2. Риск безопасности: Часто администраторы устанавливают для таких учетных записей сложные пароли и никогда их не меняют, что создает угрозу безопасности.

3. Принцип одного сервера: Одна учетная запись не должна использоваться на нескольких серверах одновременно по соображениям безопасности (сложность аудита и отзыва).

Основные особенности 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