Windows event forwarding настройка

Время на прочтение17 мин

Количество просмотров99K

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!

Картинка с сайта: habr.com

Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.

Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Политики аудита Windows

Пройдем последовательно по настройкам, эффективным для решения задач аудита ИБ и выработки целостной политики аудита безопасности.

Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.

Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра — следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.

Настройка Windows Event Forwarding, интеграция с IBM QRadar

Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

Для включения сервиса сбора логов следует выполнить нижеописанные шаги:

 1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»false»}

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).

4. Проверить состояние службы WinRM на сервере-колекторе можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management).

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

6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера…» (Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address…) и указать адрес сервера-коллектора в следующем формате:

Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

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

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*</Select>
  </Query>
</QueryList>

Картинка с сайта: habr.com

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.

9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.

Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US  (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).

После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM-системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.

Утилита Sysmon

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги  https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:\folder\sysmon64.exe -accepteula -i C:\folder\sysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe  –  файл-установщик.

Поддерживается запуск установки из сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:\Windows\sysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

XPath-запросы

Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box  «Отобразить аналитический и отладочный журналы».

Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.

Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку  «Подробности», а там выбрать radio-button  «Режим XML», в котором в формате  «ключ-значение» будут представлены данные события безопасности.

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

1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:

<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>

 2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">*[EventData[Data[@Name='DestinationPort'] = '443']]</Select>
  </Query>
</QueryList>

3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
  </Query>
</QueryList>

4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором  «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4624)]]</Select>
<Suppress Path="Security">*[EventData[(Data[@Name='TargetUserSid'] and (Data='S-1-5-18' or Data='S-1-5-19' or Data='S-1-5-20') and Data[@Name='LogonType'] and (Data='4' or Data='5'))]]
or
*[EventData[(Data[@Name='LogonProcessName'] and (Data='Advapi') and Data[@Name='AuthenticationPackageName'] and (Data='Negotiate' or Data='NTLM'))]]
</Suppress>
  </Query>
</QueryList>

IRP-система штатными средствами Windows

Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.

Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв  «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке  «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку  «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант  «При событии», а в открывшейся форме отображения установить radio-button  «Настраиваемое». После этих действий появится кнопка  «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.

Картинка с сайта: habr.com

Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and 
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

 Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
*[System[(EventID=10)]] 
and 
*[EventData[Data[@Name='TargetImage']='C:\Windows\System32\lsass.exe']] 
and 
*[EventData[(Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038'))]]
</Select>
  </Query>
</QueryList>

 Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически  бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.

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

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

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

Схема работы сбора с WEC (Windows Event Collector)

Картинка с сайта: kb.kuma-community.ru

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

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

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

С этим одним событием, прошедшее через такую сложную цепочку и работает 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 и запустите Локальная политика безопасности от имени администратора).

Картинка с сайта: kb.kuma-community.ru

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

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

В целом, групповые политики Active Directory можно назначать на OU, сайт или весь домен.

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

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

Test-WSMan

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

Картинка с сайта: kb.kuma-community.ru

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

winrm qc

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

Картинка с сайта: kb.kuma-community.ru

Команда 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 и тип подписки Инициировано исходным компьютером.

Картинка с сайта: kb.kuma-community.ru

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

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

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

Картинка с сайта: kb.kuma-community.ru

Картинка с сайта: kb.kuma-community.ru

Картинка с сайта: kb.kuma-community.ru

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

Нажмите ОК.

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

Картинка с сайта: kb.kuma-community.ru

Картинка с сайта: kb.kuma-community.ru

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

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

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

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

Test-WSMan

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

Картинка с сайта: kb.kuma-community.ru

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

winrm qc

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

Картинка с сайта: kb.kuma-community.ru

После включения службы 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 -> Проверить имена -> как только УЗ будет найдена нажмите ОК.

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

Картинка с сайта: kb.kuma-community.ru

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

Restart-Service -Name WinRM

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

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

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

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

Test-WSMan

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

Картинка с сайта: kb.kuma-community.ru

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

winrm get winrm/config | findstr ‘AllowRemoteShellAccess’ 

Картинка с сайта: kb.kuma-community.ru

Убедитесь, что порт 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

Картинка с сайта: kb.kuma-community.ru

Картинка с сайта: kb.kuma-community.ru

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

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

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

Убедитесь, что на WEC-сервер поступают события с рабочих станций/серверов. Для этого нажмите кнопку Win, введите eventvwr.msc и запустите Просмотр событий от имени администратора. Перейдите в Журналы Windows ->  Перенаправленные события. Если в появившемся окне Перенаправленные события отображаются события с источников, значит подписка работает корректно.

Картинка с сайта: kb.kuma-community.ru

Для MS Server 2016 и 2019 в случае если события не пересылаются, выполнить шаги по этой инструкции. При добавлении разрешения для URL-адреса с помощью netsh http add urlacl добавьте кавычки «…» в параметре SDDL:
netsh http delete urlacl url=http://+:5985/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 перейдите на вкладку Ресурсы -> Коллекторы и нажмите на кнопку Добавить коллектор. Также можно на вкладке Ресурсы нажать на кнопку Подключить источник событий.

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

Картинка с сайта: kb.kuma-community.ru

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

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

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

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

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

Картинка с сайта: kb.kuma-community.ru

Для установки агента 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

Картинка с сайта: kb.kuma-community.ru

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

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

Картинка с сайта: kb.kuma-community.ru

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

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

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

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

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

Картинка с сайта: kb.kuma-community.ru

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

Картинка с сайта: kb.kuma-community.ru

Introduction:

In summary:

• Windows Event Forwarding allows for event logs to be sent, either via a push or pull mechanism, to one or more centralized Windows Event Collector (WEC) servers.
• WEF is agent-free, and relies on native components integrated into the operating system. WEF is supported for both workstation and server builds of Windows.
• WEF supports mutual authentication and encryption through Kerberos (in a domain), or can be extended through the usage of TLS (additional authentication or for non-domain-joined machines).
• WEF has a rich XML-based language to control which event IDs are submitted, suppress noisy events, batch events together, and configure submission frequency. Subscription XML supports a subset of XPath, which simplifies the process of writing expressions to select the events you’re interested in.

A WEF connection requires a few basic components:

• Group Policy Objects (GPOs) to control security auditing and event logging.
• One or more servers with a configured Windows Event Log Collector service (often referred to as the “WEF Server” or “WEF Collector”).
• Functional Kerberos for all endpoints (domain) or a valid TLS certificate (non-domain) for the Event Log Collector servers.
• Windows Remote Management (WinRM) enabled on all workstations and servers that will forward events.
• Firewall rules permitting WinRM connectivity between the devices.
• GPOs to specify the URL of the WEF subscription manager(s).
• One or more event log subscriptions. A subscription is a collection of events based on Event IDs or other criteria to tell the endpoints which event logs to forward.

The following actions occur upon first receiving appropriate GPOs on a workstation:

• The workstation configures security auditing and starts writing to the local event log.
• The workstation connects to the subscription manager(s) using WinRM, authenticated either via Kerberos or TLS. In both cases, transport-layer encryption is applied.
• The workstation registers itself in the registry of the Event Log Collector, and downloads a list of all relevant WEF Subscriptions.
• The workstation periodically sends events to the Event Log Collector(s) as defined in the subscription files. Additionally, the workstation connects on a periodic heartbeat.

As new devices are added to the domain and receive the appropriate security logging and WEF subscription GPOs, they will automatically begin forwarding events, reducing the administrative burden of ensuring log coverage and quality.

Event forwarding (also called SUBSCRIPTIONS) is a mean to send Windows event log entries from source computers to a collector. A same computer can be a collector or a source.

There are two methods available to complete this challenge – collector initiated (also called PULL) and source initiated (also called PUSH):

This technology uses WinRM (HTTP protocol on port TCP 5985 with WinRM 2.0) . Be careful with the Window firewall and configure it to allow WinRM incoming requests.

WinRM is the ‘server’ component and WinRS is the ‘client’ that can remotely manage the machine with WinRM configured.

Differences you should be aware of:

WinRM 1.1 (obsolete)
Vista and Server 2008
Port 80 for HTTP and Port 443 for HTTPS

WinRM 2.0
Windows 7 and Server 2008 R2, 2012 R2, windows 10, Server 2016 …
Port 5985 for HTTP and Port 5986 for HTTPS

Tool:

https://www.logbinder.com/

Reference articles for WEF and Event forwarding:

Deploying WinRM using Group Policy: http://www.vkernel.ro/blog/how-to-enable-winrm-http-via-group-policy

Microsoft official document well documented:

https://docs.microsoft.com/en-us/windows/threat-protection/use-windows-event-forwarding-to-assist-in-instrusion-detection

https://www.jpcert.or.jp/english/pub/sr/ir_research.html

https://hackernoon.com/the-windows-event-forwarding-survival-guide-2010db7a68c4

http://blogs.technet.com/b/jepayne/archive/2015/11/24/monitoring-what-matters-windows-event-forwarding-for-everyone-even-if-you-already-have-a-siem.aspx

Fresh How-to from Intrusion detection perspective:

https://medium.com/@palantir/windows-event-forwarding-for-network-defense-cb208d5ff86f

How-to easy to follow from Intrusion detection perspective:

https://www.root9b.com/sites/default/files/whitepapers/R9B_blog_005_whitepaper_01.pdf

https://joshuadlewis.blogspot.fr/2014/10/advanced-threat-detection-with-sysmon_74.html

Basic configuration:

on source computers and collector computer:  winrm quickconfig     and add the collector computer account to the local administrators group

To verify a listener has been created type winrm enumerate winrm/config/listener

Картинка с сайта: itworldjd.wordpress.com

Just to round off this quick introduction to WinRM, to delete a listener use winrm delete winrm/config/listener?address=*+Transport=HTTP

on collector computer: wecutil qc. Add the computer account of the collector computer to the Event Log Readers Group on each of the source computers

on collector computer: create a new subscription from event viewer (follow the wizard)

WinRS: WinRS (Windows Remote Shell) is the client that connects to a WinRM configured machine (as seen in the first part of this post). WinRS is pretty handy, you’ve probably used PSTools or SC for similar things in the past. Here are a few examples of what you do.

Connecting to a remote shell
winrs -r:http://hostnameofclient "cmd"
Stop / Starting remote service
winrs -r:http://hostnameofclient "net start/stop spooler"
Do a Dir on the C drive
winrs -r:http://hostnameofclient "dir c:\"

Картинка с сайта: itworldjd.wordpress.com

Forwarded Event Logs:

This is configured using ‘subscribers’, which connect to WinRM enabled machines.

To configure these subscribers head over to event viewer, right click on forwarded events and select properties. Select the 2nd tab along subscriptions and press create.

This is where you’ll select the WinRM enabled machine and choose which events you would like forwarded.

Картинка с сайта: itworldjd.wordpress.com

Right click the subscription and select show runtime status.

Картинка с сайта: itworldjd.wordpress.com

Now it took me a minute or two to figure this one out. Was it a firewall issue (this gives the same error code), did I miss some configuration steps? Well no, it was something a lot more basic than that. Remember earlier on we were talking about the port changes in WinRM 1.1 to 2.0?

That’s right, I was using server 2008 R2 to set the subscriptions which automatically sets the port to 5985. The client I configured initially was server 2008 so uses version 1.1. If you right click the subscription and click properties -> advanced you’ll be able to see this. I changed this to port 80 and checked the runtime status again.

[DC2.domain.local] – Error – Last retry time: 03/02/2011 20:20:30. Code (0x5): Access is denied. Next retry time: 03/02/2011 20:25:30.”

Head back to the advanced settings and change the user account from machine account to a user with administrative rights. After making these changes the forwarded events started to flow.

Картинка с сайта: itworldjd.wordpress.com

Additional considerations:

In a workgroup environment, you can follow the same basic procedure described above to configure computers to forward and collect events. However, there are some additional steps and considerations for workgroups:

• You can only use Normal mode (Pull) subscriptions

• You must add a Windows Firewall exception for Remote Event Log Management on each source computer.
• You must add an account with administrator privileges to the Event Log Readers group on each source computer. You must specify this account in the Configure Advanced Subscription Settings dialog when creating a subscription on the collector computer.
• Type winrm set winrm/config/client @{TrustedHosts="<sources>"} at a command prompt on the collector computer to allow all of the source computers to use NTLM authentication when communicating with WinRM on the collector computer. Run this command only once. Where <sources> appears in the command, substitute a list of the names of all of the participating source computers in the workgroup. Separate the names by commas. Alternatively, you can use wildcards to match the names of all the source computers. For example, if you want to configure a set of source computers, each with a name that begins with “msft”, you could type this command winrm set winrm/config/client @{TrustedHosts="msft*"} on the collector computer. To learn more about this command, type winrm help config.

If you configure a subscription to use the HTTPS protocol by using the HTTPS option in Advanced Subscription Settings , you must also set corresponding Windows Firewall exceptions for port 443. For a subscription that uses Normal (PULL mode) delivery optimization, you must set the exception only on the source computers. For a subscription that uses either Minimize Bandwidth or Minimize Latency (PUSH mode) delivery optimizations, you must set the exception on both the source and collector computers.

If you intend to specify a user account by using the Specific User option in Advanced Subscription Settings when creating the subscription, you must ensure that account is a member of the local Administrators group on each of the source computers in step 4 instead of adding the machine account of the collector computer. Alternatively, you can use the Windows Event Log command-line utility to grant an account access to individual logs. To learn more about this command-line utility, type wevtutil sl -? at a command prompt.

Video:

Tutorials:

1st: Event forwarding between computers in a Domain

http://tutorial.programming4.us/windows_7/Forwarding-Events-(part-1)—How-to-Configure-Event-Forwarding-in-AD-DS-Domains.aspx

2nd: Event forwarding between computers in workgroup

http://tutorial.programming4.us/windows_7/Forwarding-Events-(part-2)—How-to-Troubleshoot-Event-Forwarding—How-to-Configure-Event-Forwarding-in-Workgroup-Environments.aspx

Additional article talking about Event forwarding too:

http://joshuadlewis.blogspot.fr/2014/10/advanced-threat-detection-with-sysmon_74.html