Microsoft

Подключение источников производителя Microsoft

MS DNS

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

Для KUMA 3.2 добавился новый способ сбора DNS логов в формате ETW. Подробнее в статье: https://kb.kuma-community.ru/books/podkliucenie-istocnikov/page/ms-etw-dns-analytics-kuma-32 

Настройка DNS сервера

Передача событий из MS DNS в KUMA осуществляется путем чтения лог файла DNS. По умолчанию запись событий в файл на DNS сервере выключена.

Чтобы включить логирование событий DNS в файл необходимо для начала создать папку, в которую будут записываться файлы событий DNS. Например, C:\dns. 

После создания папки необходимо разрешить общий доступ на чтение к этой папке. Рекомендуется создать отдельного пользователя для этой операции.

image.png

Далее необходимо запустить оснастку DNS Manager, выбрать нужный DNS сервер и перейти в свойства.

image.png

В свойствах сервера необходимо перейти на вкладку Debug Logging, включить расширенное логирование и задать путь к файлу, в который будут записывать слоги DNS сервера. Размер лог файла рекомендуется 50 Мб.

image.png

Монтирование папки в KUMA

Для чтения файла логов коллектором KUMA необходимо примонтировать папку содержащую логи DNS сервера на сервер коллектора KUMA.

Для начала необходимо установить утилиту cifs, если она еще не установлена.

yum install -y cifs-utils

Далее необходимо создать файл с учетными данными пользователя для доступа к общей папке /root/.dns-secret со следующим содержимым:

username=<имя пользователя с правами на чтение папки>
password=<пароль пользователя>
domain=<домен, в случае доменного пользователя>

Далее нужно создать папку на сервере коллектора KUMA, куда будет примонтирована папка с логами DNS сервера.

mkdir /mnt/dns

Далее в конец файла /etc/fstab необходимо добавить строку

\\<путь к общей папке сервера> <путь монтирования> cifs credentials=<файл с учетными данными>,cache=none 0 0

Пример:

\\dc-01.sales.lab\dns /mnt/dns cifs credentials=/root/.dns-secret,cache=none 0 0

Далее необходимо примонтировать общую папку командой: 

mount -a

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

ls /mnt/dns

В выводе консоли должен присутствовать файл логов DNS сервера с правами на чтение для всех пользователей

image.png

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

Для создания коллектора KUMA необходимо в веб-консоли KUMA перейти на вкладку Ресурсы – Коллекторы и нажать на кнопку Добавить коллектор. Также можно на вкладке Ресурсы выбрать пункт Подключить источник. В обоих случая откроется мастер подключения источников событий.

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

image.png

На втором шаге мастера необходимо выбрать тип подключения file и указать папку сервера коллектора, куда примонтирована папка с логами DNS сервера.

image.png

На третьем шаге мастера необходимо выбрать предустановленный нормализатор [OOTB] DNS Windows. В случае отсутствия указанного нормализатора, обратитесь к своему менеджеру для его получения.

image.png

Шаги мастера с четвертого по шестой можно пропустить, либо заполнить позднее по своему усмотрению.

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

image.png

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

image.png

В результате на вкладке Ресурсы – Активные сервисы появится созданный сервис коллектора.

image.png

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

Для установки сервиса коллектора необходимо подключиться к консоли сервера коллектора KUMA.

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

image.png

В результате статус коллектора в веб-интерфейсе KUMA изменится на зеленый.

image.png

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

image.png

MS DHCP

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

Настройка DHCP сервера

Передача событий из MS DHCP в KUMA осуществляется путем чтения лог файлов DHCP.

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

image.png

События DHCP сервера пишутся в папку C:\Windows\system32\dhcp\. Для данной папки необходимо включить общий доступ на чтение.

image.png

После предоставления общего доступа у папки должен быть статус Shared.

image.png

Монтирование папки в KUMA

Для чтения файла логов коллектором KUMA необходимо примонтировать папку содержащую логи DHCP сервера на сервер коллектора KUMA.

Для начала необходимо установить утилиту cifs, если она еще не установлена.

yum install -y cifs-utils

Далее необходимо создать файл с учетными данными пользователя для доступа к общей папке /root/.dhcp-secret со следующим содержимым:

username=<имя пользователя с правами на чтение папки>
password=<пароль пользователя>
domain=<домен, в случае доменного пользователя>

Далее нужно создать папку на сервере коллектора KUMA, куда будет примонтирована папка с логами DNS сервера.

mkdir /mnt/dhcp

Далее в конец файла /etc/fstab необходимо добавить строку

\\<путь к общей папке сервера> <путь монтирования> cifs credentials=<файл с учетными данными> 0 0

Пример:

\\dc-01.sales.lab\dhcp /mnt/dhcp cifs credentials=/root/.dhcp-secret 0 0

Далее необходимо примонтировать общую папку командой: 

mount -a

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

ls /mnt/dhcp

В выводе консоли должны присутствовать файлы логов DHCP сервера с правами на чтение для всех пользователей

image.png

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

Для создания коллектора KUMA необходимо в веб-консоли KUMA перейти на вкладку Ресурсы – Коллекторы и нажать на кнопку Добавить коллектор. Также можно на вкладке Ресурсы выбрать пункт Подключить источник. В обоих случая откроется мастер подключения источников событий.

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

image.png

На втором шаге мастера необходимо выбрать тип подключения file и указать маску пути для файлов логов DHCP сервера.

image.png

Поддерживаемые маски:

Диапазоны символов:

Примеры:


На третьем шаге мастера необходимо выбрать предустановленный нормализатор [OOTB] MS DHCP file. В случае отсутствия указанного нормализатора, обратитесь к своему менеджеру для его получения.

image.png


Шаги мастера с четвертого по шестой можно пропустить, либо заполнить позднее по своему усмотрению.

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

image.png


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

image.png

В результате на вкладке Ресурсы – Активные сервисы появится созданный сервис коллектора.

image.png

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

Для установки сервиса коллектора необходимо подключиться к консоли сервера коллектора KUMA.

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

image.png

В результате статус коллектора в веб-интерфейсе KUMA изменится на зеленый.

image.png

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

MS WMI

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

Схема работы сбора по WMI

image.png

Настройка аудита отдельного сервера

Для настройки аудита на рядовом сервере/рабочей станции необходимо:
Запустить оснастку Local Security Policy - secpol.msc

image.png

Перейти в раздел Параметры безопасности/Локальные политики/Политика аудита и включить необходимые настройки аудита успешных и не успешных попыток.

image.png

В общем случае, необходимо включить следующие параметры аудита

Аудит входа в систему Успех, Отказ;
Аудит изменения политики Успех, Отказ;
Аудит системных событий Успех, Отказ;
Аудит событий схода в систему Успех, Отказ;
Аудит управления учетными записями Успех, Отказ;

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

Настройка аудита при помощи групповой политики

Для централизованной настройки аудита при помощи групповых политик домена, необходимо   запустить оснастку Group Policy Management, выбрать нужную политику и перейти к редактированию – запустится Group Policy Management Editor. На примере, представленном ниже, настройка аудита выполняется в рамках Default Domain Policy:

image.png

В случае, если предполагается сбор журналов Windows c большого количества серверов, или если установка агентов на контроллеры домена не допускается, рекомендуется использовать перенаправление журналов на отдельные серверы с настроенной службой Windows Event Collector.

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

Настройка сервера - источника событий

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

Обозначенные выше сервисы могут быть запущены из оснастки Службы в Windows.

image.png

Также на сервере источнике событий должны быть открыты порты TCP: 135, 445, 5985, 49152-65535. Открыть данные порты для входящих подключений можно с помощью оснастки Брандмауэра защитника Windows в режиме повышенной безопасности.

image.png

Для проверки доступности целевых серверов – источников событий с компьютера, на котором планируется установка wmi-агента можно выполнить следующую команду из PowerShell: 

Get-WmiObject -Namespace "root\cimv2" -Class Win32_Process -Impersonation 3 -ComputerName <hostname целевой машины>

Проверка работы выполнения удаленных WMI запросов на источнике

Выполните с хоста, где планируется к установке KUMA Agent следующую команду в PowerShell для проверки работы WinRM на удаленой машине: 

Test-WSMan -ComputerName <Имя компьютера или IP>

При успешной проверке получим следующий результат:

image.png

Для проверки доступа к журналам по WMI, можно выполнить следующую команду (не обязательно дожидаться конца выполнения запроса, если будет ошибка она сразу появится):    

$strComputer = "dc-01.sales.lab"
    $colLogFiles = Get-WmiObject -Class Win32_NTEventLogFile -ComputerName $strComputer | Where-Object {$_.LogFileName -eq 'security'}
    foreach ($objLogFile in $colLogFiles) 
    { 
        "Record Number: " + $objLogFile.NumberOfRecords
        "Maximum Size: " + $objLogFile.MaxFileSize
}

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

Для создания коллектора в веб-интерфейсе KUMA перейдите на вкладку Ресурсы – Коллекторы и нажмите на кнопку Добавить коллектор. Также можно на вкладке Ресурсы нажать на кнопку на кнопку Подключить источник событий.

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

image.png

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

image.png

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

image.png

На третьем шаге мастера необходимо указать нормализатор. В данном случае рекомендуется использовать предустановленный расширенный нормализатор для событий Windows [OOTB] Windows Extended v.0.3.

image.png

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

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

image.png

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

image.png

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

image.png

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

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

image.png

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

firewall-cmd --add-port=5544/tcp --permanent
firewall-cmd --reload

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

image.png

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

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

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

image.png

На вкладке Подключение 1 в параметрах коннектора необходимо задать тип wmi. Для пункта Удаленные хосты необходимо задать параметры подключения к удаленным хостам со следующими ограничениями:

Указывать и использовать для настройки подключения к хостам учетную запись по умолчанию (Default credentials) не рекомендуется.

image.png

Указываем IP в полях Хост и Домен в случае, если используется локальная УЗ на системе для собора логов, иначе имя хоста и его домен. В параметрах Секрет НЕ указывайте домен, достаточно использовать логин и пароль.

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

image.png

Для версии 3.0+ параметр State (Состояние) должен быть включен:

image.png

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

image.png

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

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

В разделе Ресурсы – Активные сервисы необходимо опубликовать созданную конфигурацию KUMA Windows Agent.

image.png

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

image.png

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

Выполняется на сервере Windows, журналы которого необходимо направить в KUMA. Предварительно FQDN KUMA должен быть добавлен в файл hosts на целевой машине, либо добавлен в DNS-зону организации.

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

image.png

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

image.png

В результате, в ОС установится сервис KUMA Windows Agent <Windows Agent ID>

image.png

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

Для удаления сервиса агента по окончанию тестирования продукта из ОС можно посредством следующей команды: 

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

Приложение А. Назначение прав читателя журнала событий

Предоставить права читателя журнала событий в рамках домена можно при помощи оснастки Active Directory Users and Computers домена, добавив соответствующую учетную запись пользователя или компьютера в встроенную группу Event Log Readers:

image.png


Для отдельного компьютера необходимо перейти в оснастку Управление компьютером, выбрать пункт Локальные пользователи и группы, перейти на вкладку Группы, выбрать группу Event Log Readers и добавить в нее соответствующую учетную запись пользователя или компьютера:

image.png

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

Для назначения прав входа в качестве службы для компьютеров домена необходимо открыть оснастку Group Policy Management, выбрать необходимую политику (в данном примере это Default Domain Policy) и нажать на кнопку редактирования политики.


В открывшемся окне необходимо перейти по пути Computer Configuration – Windows Settings – Security Settings – Local Policies – User Rights Assignment и в свойства Log on as service добавить соответствующую учетную запись пользователя. Дополнительно, необходимо убедиться, что соответствующая учетная запись отсутствует в свойствах Deny log on as service.

image.png

После сохранения настроек для их применения на целевом компьютере необходимо из командной строки, запущенной от имени администратора выполнить команду: gpupdate /Force

Права входа в качестве службы можно настроить локально для отдельного компьютера с помощью оснастки Local Security Policy. Для этого необходимо выбрать пункт Local Policies, перейти на вкладку User Rights Assignment и в свойства Log on as service добавить соответствующую учетную запись пользователя. Дополнительно, необходимо убедиться, что соответствующая учетная запись отсутствует в свойствах Deny log on as service.

image.png

MS WEC

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

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

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

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

image.png

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

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

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

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

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

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

Также о Windows Event Collector можно почитать здесь: https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector.

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

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

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

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

image.png

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

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

image.png

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

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

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

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

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

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

image.png

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

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

image.png

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

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

image.png

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

image.png

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

image.png

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

image.png

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

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

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

image.png

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

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

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

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

Test-WSMan

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

image.png

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

winrm qc

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

image.png

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

image.png

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

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

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

image.png

image.png

image.png

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

Нажмите ОК.

image.png

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

image.png

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

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

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

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

image.png

image.png

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

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

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

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

Test-WSMan

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

image.png

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

winrm qc

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

image.png

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

image.png

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

image.png

image.png

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

Restart-Service -Name WinRM

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

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

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

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

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

image.png

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

image.png

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

image.png

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

image.png

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

image.png

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

image.png

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

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

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

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

image.png

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

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

Test-WSMan

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

image.png

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

winrm get winrm/config | findstr ‘AllowRemoteShellAccess’

image.png

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

image.png

image.png

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

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

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

image.png

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

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

image.png

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

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

image.png

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

image.png

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

image.png

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

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

image.png

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

image.png

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

image.png

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

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

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

image.png

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

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

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

image.png

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

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

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

image.png

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

image.png

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

image.png

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

image.png

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

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

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

image.png

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

image.png

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

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

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

image.png

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

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

image.png

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

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

image.png

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

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

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

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

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

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

image.png

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

image.png

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

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

image.png

image.png

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

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

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

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

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

image.png

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

image.png

Настройка подписки WEC с использованием XML фильтра

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

При настройке подписки WEC через графический интерфейс не получится выбрать нужные для сбора журналы, если на сервере с WEC не установлены соответствующие роли Windows Server или ПО.

dc+wec.png

Чтобы выбрать журналы, которые фактически присутствуют на удаленном сервере, но не доступны для выбора на WEC, можно воспользоваться XML фильтром.

Ниже приведен пример XML фильтра для сбора событий из стандартного журнала Security, а также из журнала, который присущ только контроллеру домена - Directory Service.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*</Select>
    <Select Path="Windows-Windows-PowerShell/Operational">*</Select>
    <Select Path="Directory Service">*</Select>
  </Query>
</QueryList>

wec_xml_filter.png

В результате данной настройки WEC начнет собирать события из журнала контроллера домена Directory Service.

Аналогичном образом можно настроить сбор событий из других специфических журналов, а также использовать XML фильтры, если требуется выполнить настройку большого количества подписок WEC. 

MS ETW (DNS Analytics)

Поддерживается в KUMA с версии 3.2

Расширенное ведение журнала DNS и диагностика доступны по умолчанию с версии Windows Server 2016. Эта функция также доступна в Windows Server 2012 R2 при установке исправления для ведения журнала запросов и аудита изменений, доступного по адресу https://support.microsoft.com/kb/2956577 

Event Tracing for Windows (ETW) - это механизм логирования различных событий, создаваемых приложениями и драйверами. Фактически является более расширенной версией стандартного журнала событий. Исторически ETW использовался для задач дебага при разработке, сейчас его можно использовать в том числе и для поиска вредоносной активности.

Включение опции логирования ETW оказывает незначительное влияние на производительность (рекомендуется в нагруженных системах). Например, DNS-сервер, работающий на современном оборудовании и получающий 100 000 запросов в секунду (QPS), может испытывать снижение производительности на 5 % при включении аналитических журналов. Очевидного влияния на производительность при скорости запроса 50 000 QPS и ниже не наблюдается. Однако всегда желательно отслеживать производительность DNS-сервера всякий раз, когда включено дополнительное ведение журнала.

Теория

ETW состоит из трёх отдельных компонентов:

Провайдеры генерируют события, потребители их используют, а контроллеры управляют всей этой деятельностью. Провайдеры - это приложения, которые содержат функционал отправки событий в ETW. Примеры провайдеров: ядро Windows, драйвера устройств, user-mode приложения и другое ПО. Какие необходимо отправлять события решает разработчик в своём коде, упрощенно говоря, если выполняется важная с точки зрения разработчика функция (открывается доступ к SAM), то создается запись в ETW.

Для отправки провайдеры регистрируются в контроллере, контроллер в свою очередь может включить или отключить источник событий. Отключенный источник события не генерирует. Пример контроллеров - это logman или wevtutil. Для связи между провайдером и потребителем контроллер использует так называемые сессии трассировки. Сессия служит в том числе для фильтрации необходимых данных по различными параметрам, потому что потребителю может быть нужна только одна часть информации, а другому потребителю - другая.

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

Настройка на стороне Windows

Переходим в EventViewer (Выполнить -> eventvwr.msc). Далее переходим в Журналы приложений и служб\Microsoft\Windows\DNS-Server (на англ. Applications and Services Logs\Microsoft\Windows\DNS-Server)

image.png

Далее переходим в свойства Аналитического журнала:

image.png

Оставляем максимальный размер журнала по умолчнию в 1 Гб:

image.png

Нажимаем на чекбокс Включить ведение журнала, затем ОК

image.png

Должно получиться следующее:

image.png

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

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

image.png

image.png

Далее необходимо перейти в Управление компьютером и открыть его от Админиcтратора. Переходим Служебные программы - Производительность - Сеансы отслеживания событий запуска.

image.png

Создаем группу сборщиков данных:

image.png

Задаем имя сборщика, например etwDNS-Analytics:

image.png

Добавляем поставщика Microsoft-Windows-DNSServer:

image.png

Агент с коннектором ETW работает только с System.Provider.Guid: {EB79061A-A566-4698-9119-3ED2807060E7} - Microsoft-Windows-DNSServer

Нажимаем Далее - Далее - Готово.

Запускаем созданного поставщика, как сеанс отслеживания событий:

image.png

Далее в сеансах отслеживания событий, в свойствах - Сеансы отслеживания указываем Режим реального времени

image.png

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

Чтобы просмотреть, какие типы событий можно отслеживать, выполните следующую команду в командной строке powershell:

logman query providers "Microsoft-Windows-DNSServer"

Пример вывода:

image.png

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

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

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

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

image.png

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

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

image.png

На третьем шаге мастера укажите нормализатор. В данном случае рекомендуется использовать предустановленный расширенный нормализатор для событий Windows [OOTB] Microsoft DNS ETW logs json.

image.png

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

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

image.png

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

image.png

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

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

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

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

image.png

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

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

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


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

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

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

image.png

На вкладке Подключение 1 в параметрах коннектора задайте имя коннектора, тип  etw и укажите имя сессии (это имя сборщика созданного на этапе настройки на стороне Windows) в нашем случае это etwDNS-Analytics.

image.png

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

image.png

В дополнительных параметрах укажите размер дискового буфера в 1 Гб.

image.png

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

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

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

image.png

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

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

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

Для УЗ требуются следующие группы и права:

После запуска сервиса агента можно переключиться на системную локальную учетку (LocalSystem), сделать это можно через Services на Windows. Иногда такое целесообразно при ротации паролей в УЗ.

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

Выполняется на Windows сервере, который обеспечивает прием событий от источников (рабочих станций/серверов). Предварительно FQDN Core KUMA должен быть добавлен в файл hosts на Windows сервере, либо добавлен на DNS-сервере. На Windows сервере рекомендуется создать папку C:\Users\<имя пользователя>\Desktop\KUMA.

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

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

image.png

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

Перейдите в папку C:\Users\<имя пользователя>\Desktop\KUMA, примите лицензионное соглашение: /opt/kaspersky/kuma/kuma.exe license 

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

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

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

image.png

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

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

image.png

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

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

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

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

Для проверки, что сбор событий с устройств Windows успешно настроен перейдите в Ресурсы -> Активные сервисы -> выберите (чекбокс) ранее созданный коллектор для Windows и нажмите Перейти к событиям. Либо ПКМ - Перейти к событиям. В открывшемся окне События убедитесь, что присутствуют события с Windows-устройств.

image.png


MS Exchange

По Exchange KUMA анализирует Message Tracking Log (MTL) в формате CSV.

Пример лога:

#Software: Microsoft Exchange Server
#Version: 15.01.1034.026
#Log-type: Message Tracking Log
#Date: 2017-09-15T20:01:45.863Z
#Fields: date-time,client-ip,client-hostname,server-ip,server-hostname,source-context,connector-id,source,event-id,internal-message-id,message-id,network-message-id,recipient-address,recipient-status,total-bytes,recipient-count,related-recipient-address,reference,message-subject,sender-address,return-path,message-info,directionality,tenant-id,original-client-ip,original-server-ip,custom-data,transport-traffic-type,log-id,schema-version
2017-09-15T20:01:45.863Z,,,,WINEXC,No suitable shadow servers,,SMTP,HAREDIRECTFAIL,34359738369,<49b4b9a2781a45cba555008075f7bffa@test.com>,8e1061b7-a376-497c-3172-08d4fc7497bf,test1@test.com,,6533,1,,,test,Administrator@test.com,Administrator@test.com,,Originating,,,,S:DeliveryPriority=Normal;S:AccountForest=test.com,Email,63dc9d79-5b4e-4f6c-1358-08d4fc7497c3,15.01.1034.026

Для настройки можно обратиться к этой статье: https://learn.microsoft.com/ru-ru/exchange/mail-flow/transport-logs/transport-logs?view=exchserver-2019

Далее нужную директорию расшарить и подключить ее к KUMA по аналогии с этой статьей: https://kb.kuma-community.ru/books/integracii/page/montirovanie-papki-v-kuma 

MS Windows XP & 2003 SNMP

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

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

Настройка на стороне Windows.

Настройка сервиса SNMP

В статье рассматривается настройка на ОС Windows XP. Перейдите в Панель управления - Установка и удаление программ - Установка компонентов Windows. Установите Средства управления и наблюдения и провайдер WMI SNMP (если есть). 

image.png

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

Убедитесь, что службы SNMP запущена (Панель управления - Администрирование - Службы): Служба SNMP (SNMP Service) и Служба ловушек SNMP (SNMP Trap). Если какие-то из перечисленных ниже служб не запущены - Запустите

Настройка сервиса SNMP

Перейдите в Панель управления - Администрирование - Службы  - Служба SNMP (Свойства) - Вкладка Ловушки

image.png

Добавьте имя сообщества: public
Адрес назначения ловушек: <IP_адрес_коллектора>

На вкладке Безопасность:

image.png

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

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

Создайте коллектор со следующим транспортом:

image.png

В дополнительных параметрах в случае Русской локали в ОС кажите явно кодировку:

image.png

В качестве парсера рекомендуем использовать комьюнити нормализатор (предварительно импортируйте его в KUMA, пароль импорта: q123123Q!): ссылка

Задайте маршрут куда отправлять обработанные события коллектором:

image.png

Нажмите сохранить и создать сервис, скопируйте строку установки и выполните ее в консоли SSH.

SNMP использует порт 161 UDP для общих сообщений, для ловушек используется порт 162 UDP. Для прослушки порта SNMP обновите параметры службы в Linux (предварительно скопируйте ID коллектора), инструкция как настроить прослушку ниже 1024 порта в Linux: ссылка

Настройка аудита на стороне Windows

Нажмите Пуск - Выполнить - Введите: evntwin

image.png

Генерация тестовых событий на Windows

Создайте и удалите тестового пользователя в системе для генерации событий в Панель управления - Администрирование - Управление компьютером - Локальные пользователи - Папка пользователи.

При корректных настройках в кума должно отобразиться событие:

image.png

Аналог netcat с помощью PowerShell на Windows

Часто для проверки поступления события требуется специальные утилиты для отправки тестового сообщения с Windows машины на коллектор, в рамках этой статьи будет представлен скрипт на PowerShell , с помощью которого можно будет отправить тестовое сообщение по IP:PORT по протоколу TCP.

Код скрипта:

Function Send-TCPMessage { 
    Param ( 
            [Parameter(Mandatory=$true, Position=0)]
            [ValidateNotNullOrEmpty()] 
            [string] 
            $EndPoint
        , 
            [Parameter(Mandatory=$true, Position=1)]
            [int]
            $Port
        , 
            [Parameter(Mandatory=$true, Position=2)]
            [string]
            $Message
    ) 
    Process {
        # Setup connection 
        $IP = [System.Net.Dns]::GetHostAddresses($EndPoint) 
        $Address = [System.Net.IPAddress]::Parse($IP) 
        $Socket = New-Object System.Net.Sockets.TCPClient($Address,$Port) 
    
        # Setup stream wrtier 
        $Stream = $Socket.GetStream() 
        $Writer = New-Object System.IO.StreamWriter($Stream)

        # Write message to stream
        $Message | % {
            $Writer.WriteLine($_)
            $Writer.Flush()
        }
    
        # Close connection and stream
        $Stream.Close()
        $Socket.Close()
    }
}

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

Send-TCPMessage -Port 5578 -Endpoint 10.68.85.125 -message "KUMA the best SIEM !"

 

Вот как это выглядит в работе:

image.png

На стороне KUMA:

image.png

 

Мониторинг ключей реестра Windows

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

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

Запустите cmd.exe из-под учетной записи Администратора и выполните следующую команду:

auditpol /set /subcategory:"Реестр" /success:enable /failure:enable

Другим вариантом является внесение изменений в локальную политику безопасности. Чтобы выполнить его, откройте редактор Локальной политики безопасности и перейдите в "Параметры безопасности" - "Конфигурация расширенной политики аудита" - "Политики аудита системы" - "Объект локальной групповой политики" - "Доступ к объектам".

image.png

Откройте подкатегорию "Аудит реестра" и выставите необходимые значения

image.png

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

Откройте оснастку "Редактор реестра" и перейдите к разделу, аудит которого необходимо настроить

image.png

Нажмите ПКМ на нужном разделе и выберите пункт Разрешения

image.png

В открывшемся окне нажмите на кнопку "Дополнительно"

image.png

В новом окне перейдите на вкладку "Аудит" и добавьте необходимое правило аудита раздела. В данном примере настроен аудит полного доступа всех субъектов к текущему разделу и всем его подразделам.

image.png

Примените выполненные настройки.

Результат

В результате выполненных настроек в журнале безопасности (security) Windows будут появляться события в зависимости от настроенного аудита. 

События, которые могут появляться:

- 4663(S): An attempt was made to access an object.
- 4656(S, F): A handle to an object was requested.
- 4658(S): The handle to an object was closed.
- 4660(S): An object was deleted.
- 4657(S): A registry value was modified.
- 5039(-): A registry key was virtualized.
- 4670(S): Permissions on an object were changed.

Как это выглядит в KUMA (на примере события 4657):

image.png

image.png

image.png