Настройка сбора событий с устройств Windows при помощи Агента KUMA (WEC).
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/248413.htm
Схема работы сбора с WEC (Windows Event Collector)
Рекомендации для сервера WEC
- Рекомендациям Microsoft по мощностям WEC сервера (4-8 CPU 16 GB) — https://docs.microsoft.com/en-us/troubleshoot/windows-server/admin-development/configure-eventlog-forwarding-performance
- Рекомендация использовать до 1500 станций на один сервер (максимум по указанным выше мощностям 4000 машин)
- на котроллеры домена не надо ставить ничего лишнего
- события с контроллеров домена необходимо собирать с использованием механизмов, рекомендуемых MS. В данном случае это будут серверы WEC
Отказоустойчивый сбор событий с WEC
- на котроллеры домена не надо ставить ничего лишнего
- события с контроллеров домена необходимо собирать с использованием механизмов, рекомендуемых MS. В данном случае это будут серверы WEC
В одной инсталляции, события на контроллерах домена хранятся очень мало – ротация примерно через 3-5 минут. Поэтому чтобы гарантировать доставку, если по какой-то причине WEС не доступен, предлагается следующая схема:
- использовать 2 WEC сервера
- все DC отправляют события не на один, а на 2 WEC сервера (события обоих WEC дублируются)
- на каждом WEC сервере установлены KUMA Agent
- оба KUMA Agent отправляют события в ОДИН и тот же коллектор Windows (это важный момент)
- на коллекторе Windows настраивается агрегация события, чтобы дубли событий с обоих WEC серверов были агрегированы в одно событий
С этим одним событием, прошедшее через такую сложную цепочку и работает KUMA. Это позволит выполнять обслуживание, перезагружать 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-серверу за новыми инструкциями по пересылке журналов.
Источники событий должны иметь возможность «резолвить» 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 – частота обращения (в секундах) источников событий к серверу за новыми инструкциями по пересылке журналов.
Источники событий должны иметь возможность «резолвить» 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 и обеспечиваться доступ к журналам событий, полученных от источников (рабочих станций/серверов).
Добавление сервисной учетной записи в группу «Читатели журнала событий»
На 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-устройств.
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
This blog discusses, mentions, or contains links to an Elastic training program that is now retired. For more Elastic resources, please visit the Getting Started page.
Last week we covered the essentials of event logging: Ensuring that all your systems are writing logs about the important events or activities occurring on them. This week we will cover the essentials of centrally collecting these Event Logs on a Window Event Collector (WEC) server, which then forwards all logs to Elastic Security.
WEF and WEC
Modern versions of Windows include the Windows Remote Management (WinRM) services that implement the WS-Management (WSman) protocol, and just to add to the acronym spaghetti soup, this is all part of Windows Management Instrumentation (WMI). One component of WinRM is the Windows Event Forwarding (WEF) service, this is why WinRM and co. need to be enabled. WEF can forward Windows Event Logs to a Windows Server running the Windows Event Collector (WEC) service.
There are two modes of forwarding:
- Source Initiated: The WEF service connects to the WEC server
- Collector Initiated: The WEC service connects to the WEF service
Both use WSman to forward the logs and require WinRM to be running.
There are a number of pitfalls and hurdles when setting up WEF and WEC. Following our WEC Cookbook, you can avoid these. However, for a higher-level view with richer context, we will discuss them here, as well as the solution taken in the Cookbook.
‘Forwarded Events’ event log file
In the Windows Event Log system there are Channels. These Channels are ultimately backed by an event log file that stores all the event logs written to that Channel. A Windows system comes with a set of predefined Channels and applications can add their own Channels by registering new “Providers.”
This means that out of the box, a WEC server only has the Channels that a normal Windows server has anyway for its own logs. Then where should one store all the logs that are being forwarded to the WEC server? There are three options; let’s look at them:
1. Store in the local Channel matching the remote Channel (i.e., the remote “Security” Channel events are stored in the WEC’s local “Security” Channel).
Pitfalls:
- All your remote logs are mixed with your local logs
- The WEC server may loop its own event logs to this Channel
- Log management and access control are made very difficult
2. Store all the remote logs in the local “Forwarded Events” Channel.
Pitfalls:
- Poor write performance, since all writes are to a single file
- Poor search/read performance, as events are not partitioned in separate files
- Poor data life cycle management, as this is per log file, therefore all forwarded events are treated as equal
- Poor resource utilisation of the WEC server, because all work is bottle-necked to a single file
- Poor access management, separate files would allow differentiated file access controls
- Poor coverage/visibility — due to the issues above, many heavily restrict what event logs are forwarded, leaving gaps in their visibility
3. Create new Channels for the WEC server.
This is not as obvious as it might seem, and most would be forgiven for not knowing that it was an option.
Many WEC servers have been set up with options 1 or 2 (above), until Microsoft’s own internal Security team wrote a blog post (about 15 years ago) on how they used the Windows SDK to implement option 3. Here is a similar revision posted in 2016.
New WEC event Channels
Armed with the ability to create arbitrary event Channels, what should we create? How should we organise and architect our WEC server? There are many schools of thought — the WEC Cookbook groups enterprise assets together so that you can manage your log’s access control and data lifecycle accordingly.
Before we delve deeper, let’s look at another approach. Some of you might have come across Palantir’s WEC architecture and guideline. Here, they created a Channel per event log type: Powershell, WMI, DNS, Firewall, etc. These Channels contain logs from all asset types (Domain Controllers, Domain Server, Domain Workstation) and Departments/Biz-Units/OU. They’re also not organised into a hierarchy, so they’d just be a long list in Event Viewer. The Channels therefore also have their WEC subscriptions. Palantir also has a recommended audit policy.
I like to point out other approaches, such as this one from Palantir, as not one size fits all and their approach might suit your organisation better then the one set out in our Cookbook.
If you have looked at Palantir’s Channel list, you will have noticed their “WEC#-Something” format, where the number ‘#’ increases every seven Channels. This is because in the Windows Event Log system, Channels are defined by what is known as a “Provider” and can only define up to eight Channels:
However, an off-by-bug in the “ecmangen” tool that all of us non-Windows-SDK-developer security people used made it frustrating to have more than seven Channels per Provider in it.
Instead of fixing the many bugs in it, it appears that Microsoft dropped ecmangen from the Windows SDK. Meaning you either use an older SDK or create the Manifest XML file yourself — perhaps with your favourite XML editor.
Like everyone else, I used ecmangen (originally) and stuck to seven Channels to make life easier. The current Cookbook is based on PowerShell scripts that generate the XML. Ecmangen is no longer needed, so you are free to have eight Channels if you want, although the Cookbook still only uses seven recommended Channels.
Note: Think of a Provider as a box of eight Channels, where each Channel is ultimately a separate log file.
Organise by asset
Taking advantage of the fact that you can have as many Providers as you want, we can use this to organise by asset. In your AD environment, you have probably already grouped domain members by asset type (e.g., Domain servers, Domain Controllers, workstations, etc.) and/or by the department (dare I say organisational unit) that those assets are in.
So in the Cookbook you can easily create Providers to match your AD’s organisation, along the lines of Providers per department (Biz Unit or OU) and/or per Asset type and/or per Asset criticality (Lab/Test/Production).
When you seperate by asset type you get the added benefit of being able to better manage access control and log life cycle. If you need to look at the logs of a specific asset type you know where they are.
To make things simple all Providers then get the same set of (up to eight Channels). Then systems are mapped to a Provider (via OU) and the event logs on that system map to Channels in that Provider.
Out of the box, the “wec_config.ps1” script that is used to configure the WEC server to match your AD architecture has some Providers and asset assignment defined:
- Domain Controllers: I think member assignment is clear here
- Domain Servers: The servers in your domain
- Domain Clients: User workstations (desktop/laptops)
- Domain Privileged: More privileged systems (e.g., Jumphosts or WEC Server)
- Domain Members: Catch-all for normal domain members; not in the other groups
- Domain Misc: Miscellaneous, for those hosts that don’t fit
You are encouraged to refine and edit the list to match your AD environment.
Then the out-of-the-box Channel list is:
- Application: “Application” and similar logs
- Security: “Security” and similar logs
- Sysmon: “Microsoft-Windows-Sysmon/Operational”
- System: “System”, “HardwareEvents”, DNS-Client, DHCP-Client, “Setup” and similar logs
- Script: “Windows PowerShell” and similar logs
- Service: DNS-Server, DHCP-Server, and other service logs
- Misc: Any other miscellaneous logs
Again, you are free to change this to suit your needs.
WEC subscriptions
A WEC subscription defines the following:
- An event log (XPath) filter, selecting what events should be forwarded
- A destination Channel, stating where to store the received events on the WEC server
- Type:
- Collector Initiated, the WEC connects to the WEF service
- Target computers, a list of computers to connect to
- Source Initiated, the WEF connects to the WEC server
- Computer groups, the AD groups whose (computer) members may access this subscription
- Collector Initiated, the WEC connects to the WEF service
- Event delivery options to control bandwidth/latency and/or HTTP/HTTPS
- Format type: RenderedText or just the Event XML
The cookbook scripts (notably setup_subscriptions.ps1) configure the Event XML format type. These are much smaller, so it means more throughput, more logs stored, less load, and less bandwidth. However, the drawback is that if the source Provider (on the remote system) is not registered locally on the WEC server’s Event Log System, then the Event Viewer won’t be able to display a text description of the message in your local language. However, sending Rendered Text events is so resource intensive that it’s difficult to justify.
I mentioned at the start that WEF is a function of WinRM. Well, this WinRM component runs as the local system’s “Network Service” user. This means that WEF can’t actually read most of your system logs, and your WEC server will receive a very nondescript Event ID 111 message and no other logs. For this reason, the Cookbook guides you through creating a GPO to add “Network Service” to the local “Event Log Readers” group.
How does WinRM get the configuration for WEF? In the same GPO as mentioned above, we also publish a WSman URL that lists all the WEC subscriptions on that server. In fact, we can list multiple WSman subscriptions URLs from multiple WEC servers, and the WEF service will try to get and execute them all — thus allowing for redundant WEC servers.
All the subscriptions? I don’t want my Workstation sending event logs to my Domain Controller log files! The WSman entries that represent a subscription have AD group permissions applied to them as set up in the Subscription configuration. This means if the computer that WEF is running on is not a member of an AD group that has permission to read the subscription, it can’t get and execute the subscription. It also means that if you’re not careful and a computer is a member of more than one WEC subscription AD group, you will get multiples of the same event log from that WEF host on your WEC!
Computer Groups? But I want to map computers based on the OU that they are placed in! Unfortunately, that is not how WEF/WEC/WinRM/WSman work. However, the Cookbook provides a mechanism to keep a given group’s membership in sync with specified OU locations. Thus you can pretend everything is done via OU!
Bringing it all together
There is a lot of complexity and moving parts to get right when setting up WEF & WEC for good observability or security use cases.
Fear not, however, for our Cookbook is here, accompanied by a set of Powershell scripts to automate most of the steps. This means there is less room for mistakes, actions are reproducible, and thus mistakes are more easily fixable.
It all starts with the wec_config.ps1 script, which you are expected to edit to your heart’s content. All the following scripts will take their lead from that. Therefore, you can easily, for example, change the event log filter used to select what event logs get forwarded in wec_config.ps1, and then re-run setup_subscriptions.ps1 to apply the change.
Let’s take a look at what the scripts do (the Cookbook goes into far more detail on how to use them):
- wec_config.ps1 — The configuration of your WEC server, sourced by the other scripts
- gen_manifest.ps1 — This will create the Manifest XML that describes all your Providers and their Channels for the Windows SDK (no need to use ecmangen anymore!)
- build_man2dll.ps1 — Taking your manifest, this will build the Windows Event Subsystem Module DLL that implements all your new Providers and Channels on any system you install it (usually the WEC server)
- install_channels.ps1 — Takes the DLL and Manifest and installs them on the Local system
- configure_channels.ps1 — Will apply the Log Path and Log Size configuration (from wec_config.ps1) to all your newly installed Channels
- setup_subscriptions.ps1 — Will setup (create or reconfigure) all the subscriptions for your Provider/Channels on the WEC server
- map_ou2group.ps1 — You probably want to use your AD’s OUs, but WEC Subscriptions select computers via AD Groups. This script will sync the membership of given groups to the computers under specified OUs, again using the configuration in wec_config.ps1
- gen_winlogbeat_config.ps1 — The config that ships with Winlogbeat won’t know about all your extra WEC subscription Channels, so this will update that configuration for you
- beat_cmd.ps1 — A helper script for interacting with Beat commands on PowerShell
Unfortunately, all the configuration on the AD side, such as Group Policies, still have to be done manually — but the Cookbook has step-by-step guides with screenshots. I may write scripts for that too one day, stay tuned.
Finally Winlogbeat needs to be configured to send all the WEC logs to Elastic Security. The cookbook will guide you through this too.
Conclusion
I hope after reading this blog post, and possibly the Cookbook itself, you have a good idea of the decisions you need to make before you start, as well as now having all the guidance and tools you need to create that perfect WEC server for your enterprise.
Now that you have the proper audit policies in place, WEF configured, and a WEC server setup to forward your AD domain’s event logs to Elastic Security, in our following blog post we will look at what you can do with this extremely important and useful log data in Elastic Security.
If you’re new to Elastic Security, you can experience our latest version on Elasticsearch Service on Elastic Cloud. Also be sure to take advantage of our Quick Start training to set yourself up for success.
See other Cookbook guides that I have written: https://ela.st/tjs-cookbook-lib
Introduction
Windows Event Collection (WEC) – also known as Windows Event Forwarding (WEF) – is a native agent-less way to aggregate event logs onto central collectors that is built-in to Windows. With WEC, you can get the Windows Security Log and any other important event logs from thousands of Windows endpoints without
- Installing an agent or anything else
- Inefficient polling for new events
- Opening any ports on source (forwarder) computers
- Needing credentials for accessing logs on remote systems
All you need to do is set up a Windows server as a windows event collector by creating one or more WEC subscriptions on it. Then, via group policy or Intune, you target your forwarder systems at the collector. Voila, events show up in the designated event log on the collector where they can then be directed to your SIEM or other downstream consumers.
Each subscription allows you to specify which forwarders should send which logs and events to which destination log on the collector.
You can collect events from Active Directory domain member computers, which automatically leverages Kerberos, or non-domain member computers via client certificate authentication. Either way, event data is encrypted over the network.
WEC/WEF is built on top of Windows Remote Management (WinRM), which runs on both forwarders and collectors. Some of the more advanced features of Windows Event Forwarding involve WinRM configuration settings.
Concepts
In this section, we introduce you to key concepts that comprise Windows Event Collection and explain their relationships.
- Collector
- Forwarder
- Subscription
- Event Log
- XPath Query (aka Event Filter)
For collecting events from computers not part of the Active Directory environment, some additional concepts take on significance. We deal with these topics specifically under WEC in a Non-AD Environment.
- Server Certificates for Collectors
- Client Certificates for Forwarders
- Certificate Authorities on Subscriptions
- Certificate Mappings on Collectors
- HTTPS Listeners on Collectors
Supercharger for Windows Event Collection
Supercharger provides
- At a glance, single pane of glass view of entire Windows Event Collection (WEC) environment
- Pre-built security filters with noise suppression based on Randy Franklin Smith’s UltimateItSecurity.com
- Wizard-based create/update/delete/view of subscriptions
- Step-by-step guidance for new WEC implementations
Install Supercharger Free
Single Pane of Glass
Supercharger’s manager/agent architecture installs in minutes and displays your global WEC environment on a single
pane of glass. Check the status of event forwarding from your browser or even your phone.
Centrally Manage Subscriptions
Create/edit/delete subscriptions with a click.
Filter the Noise with Help from UltimateItSecurity.com
Pre-built managed filters leverage our deep knowledge of the Windows Security Log. Point and click to create Xpath queries that
collect the events you want while leaving the noise behind.
New to Windows Event Collection?
Step-by-step guidance for new WEC implementations
Manage, Scale and Heal Windows Event Collection with Supercharger
Download •
Enterprise Pricing •
Ask Sales