Microsoft
Подключение источников производителя Microsoft
- MS DNS
- MS DHCP
- MS WMI
- MS WEC
- Настройка подписки WEC с использованием XML фильтра
- MS ETW (DNS Analytics)
- MS Exchange
- MS Windows XP & 2003 SNMP
- Аналог netcat с помощью PowerShell на Windows
- Мониторинг ключей реестра Windows
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
.
После создания папки необходимо разрешить общий доступ на чтение к этой папке. Рекомендуется создать отдельного пользователя для этой операции.
Далее необходимо запустить оснастку DNS Manager, выбрать нужный DNS сервер и перейти в свойства.
В свойствах сервера необходимо перейти на вкладку Debug Logging, включить расширенное логирование и задать путь к файлу, в который будут записывать слоги DNS сервера. Размер лог файла рекомендуется 50 Мб.
Монтирование папки в 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 сервера с правами на чтение для всех пользователей
Создание коллектора KUMA
Для создания коллектора KUMA необходимо в веб-консоли KUMA перейти на вкладку Ресурсы – Коллекторы и нажать на кнопку Добавить коллектор. Также можно на вкладке Ресурсы выбрать пункт Подключить источник. В обоих случая откроется мастер подключения источников событий.
На первом шаге мастера необходимо выбрать Тенант, которому будет принадлежать коллектор и также задать Имя коллектора.
На втором шаге мастера необходимо выбрать тип подключения file и указать папку сервера коллектора, куда примонтирована папка с логами DNS сервера.
На третьем шаге мастера необходимо выбрать предустановленный нормализатор [OOTB] DNS Windows. В случае отсутствия указанного нормализатора, обратитесь к своему менеджеру для его получения.
Шаги мастера с четвертого по шестой можно пропустить, либо заполнить позднее по своему усмотрению.
На седьмом шаге мастера необходимо указать точки назначения типа Хранилище, если требуется сохранение событий в БД и типа Коррелятор, если требуется корреляция событий.
На последнем шаге мастера необходимо нажать на кнопку Сохранить и создать сервис, после чего скопировать появившуюся команду для дальнейшей установки сервиса коллектора.
В результате на вкладке Ресурсы – Активные сервисы появится созданный сервис коллектора.
Установка коллектора KUMA
Для установки сервиса коллектора необходимо подключиться к консоли сервера коллектора KUMA.
Для установки сервиса коллектора необходимо выполнить скопированную команду.
В результате статус коллектора в веб-интерфейсе KUMA изменится на зеленый.
Для проверки поступления событий выберите соответствующий коллектор (галочка слева) и нажмите на кнопку Перейти к событиям. В открывшемся окне события при нажатии на значок лупы должны появиться события DNS сервера.
MS DHCP
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Настройка DHCP сервера
Передача событий из MS DHCP в KUMA осуществляется путем чтения лог файлов DHCP.
Откройте оснастку DHCP и убедитесь, что для DHCP сервера включено логирование.
События DHCP сервера пишутся в папку C:\Windows\system32\dhcp\
. Для данной папки необходимо включить общий доступ на чтение.
После предоставления общего доступа у папки должен быть статус Shared.
Монтирование папки в 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 сервера с правами на чтение для всех пользователей
Создание коллектора KUMA
Для создания коллектора KUMA необходимо в веб-консоли KUMA перейти на вкладку Ресурсы – Коллекторы и нажать на кнопку Добавить коллектор. Также можно на вкладке Ресурсы выбрать пункт Подключить источник. В обоих случая откроется мастер подключения источников событий.
На первом шаге мастера необходимо выбрать Тенант, которому будет принадлежать коллектор и также задать Имя коллектора.
На втором шаге мастера необходимо выбрать тип подключения file и указать маску пути для файлов логов DHCP сервера.
Поддерживаемые маски:
*
– соответствует любой последовательности символов;[' [ '^' ] { диапазон символов } ']
– класс символов (не должен быть пустым);?
– соответствует любому одиночному символу.
Диапазоны символов:
[0-9]
– числа;[a-zA-Z]
– буквы латинского алфавита.
Примеры:
/var/log/*som?[1-9].log
/mnt/dns_logs/*/dns.log
/mnt/proxy/access*.log
На третьем шаге мастера необходимо выбрать предустановленный нормализатор [OOTB] MS DHCP file. В случае отсутствия указанного нормализатора, обратитесь к своему менеджеру для его получения.
Шаги мастера с четвертого по шестой можно пропустить, либо заполнить позднее по своему усмотрению.
На седьмом шаге мастера необходимо указать точки назначения типа Хранилище, если требуется сохранение событий в БД и типа Коррелятор, если требуется корреляция событий.
На последнем шаге мастера необходимо нажать на кнопку Сохранить и создать сервис, после чего скопировать появившуюся команду для дальнейшей установки сервиса коллектора.
В результате на вкладке Ресурсы – Активные сервисы появится созданный сервис коллектора.
Установка коллектора KUMA
Для установки сервиса коллектора необходимо подключиться к консоли сервера коллектора KUMA.
Для установки сервиса коллектора необходимо выполнить скопированную команду.
В результате статус коллектора в веб-интерфейсе KUMA изменится на зеленый.
Для проверки поступления событий выберите соответствующий коллектор (галочка слева) и нажмите на кнопку Перейти к событиям. В открывшемся окне события при нажатии на значок лупы должны появиться события DHCP сервера.
MS WMI
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Схема работы сбора по WMI
Настройка аудита отдельного сервера
Для настройки аудита на рядовом сервере/рабочей станции необходимо:
Запустить оснастку Local Security Policy - secpol.msc
Перейти в раздел Параметры безопасности/Локальные политики/Политика аудита и включить необходимые настройки аудита успешных и не успешных попыток.
В общем случае, необходимо включить следующие параметры аудита
Аудит входа в систему | Успех, Отказ; |
Аудит изменения политики | Успех, Отказ; |
Аудит системных событий | Успех, Отказ; |
Аудит событий схода в систему | Успех, Отказ; |
Аудит управления учетными записями | Успех, Отказ; |
Примеры рекомендованных политик можно найти тут
Настройка аудита при помощи групповой политики
Для централизованной настройки аудита при помощи групповых политик домена, необходимо запустить оснастку Group Policy Management, выбрать нужную политику и перейти к редактированию – запустится Group Policy Management Editor. На примере, представленном ниже, настройка аудита выполняется в рамках Default Domain Policy:
В случае, если предполагается сбор журналов Windows c большого количества серверов, или если установка агентов на контроллеры домена не допускается, рекомендуется использовать перенаправление журналов на отдельные серверы с настроенной службой Windows Event Collector.
Примеры рекомендованных политик можно найти тут
Настройка сервера - источника событий
На сервере – источнике событий должны быть запущены следующие сервисы:
- Remote Procedure Call (RPC);
- RPC Endpoint Mapper.
Обозначенные выше сервисы могут быть запущены из оснастки Службы в Windows.
Также на сервере источнике событий должны быть открыты порты TCP: 135, 445, 5985, 49152-65535. Открыть данные порты для входящих подключений можно с помощью оснастки Брандмауэра защитника Windows в режиме повышенной безопасности.
Для проверки доступности целевых серверов – источников событий с компьютера, на котором планируется установка wmi-агента можно выполнить следующую команду из PowerShell:
Get-WmiObject -Namespace "root\cimv2" -Class Win32_Process -Impersonation 3 -ComputerName <hostname целевой машины>
Проверка работы выполнения удаленных WMI запросов на источнике
Выполните с хоста, где планируется к установке KUMA Agent следующую команду в PowerShell для проверки работы WinRM на удаленой машине:
Test-WSMan -ComputerName <Имя компьютера или IP>
При успешной проверке получим следующий результат:
Для проверки доступа к журналам по 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 перейдите на вкладку Ресурсы – Коллекторы и нажмите на кнопку Добавить коллектор. Также можно на вкладке Ресурсы нажать на кнопку на кнопку Подключить источник событий.
После выполнения указанных действий откроется соответствующий мастер. На первом шаге необходимо выбрать Имя коллектора и Тенант, к которому он будет принадлежать.
На втором шаге мастера необходимо выбрать транспорт. В данном случае рекомендуется использовать http. В поле URL необходимо указать порт, на котором коллектор будет ожидать соединение от агента. В качестве разделителя необходимо указать \0.
На вкладке Дополнительные параметры для шифрованной передачи данных между агентом и коллектором необходимо выбрать Режим TLS - С верификацией.
На третьем шаге мастера необходимо указать нормализатор. В данном случае рекомендуется использовать предустановленный расширенный нормализатор для событий Windows [OOTB] Windows Extended v.0.3.
Шаги мастера настройки с четвертого по шестой можно пропустить и вернуться к их настройке позднее.
На седьмом шаге мастера необходимо указать точки назначения. Для хранения событий необходимо добавить точку назначения типа Хранилище. В случае если предполагается также корреляция по событиям необходимо добавить точку назначения типа Коррелятор.
На завершающем шаге мастера необходимо нажать на кнопку Сохранить и создать сервис. После чего появится строка установки сервиса, которую необходимо скопировать для дальнейшей установки.
Также после выполнения указанных действий на вкладке Ресурсы – Активные сервисы появится созданный сервис коллектора.
Установка коллектора KUMA
Для установки сервиса коллектора необходимо из командной строки выполнить команду, скопированную на прошлом шаге.
Также необходимо добавить порт коллектора в исключения фаервола и обновить параметры службы
firewall-cmd --add-port=5544/tcp --permanent
firewall-cmd --reload
После успешной установки сервиса его в статус в веб-консоли KUMA изменится на зеленый.
Создание агента KUMA
Для создания агента в веб-интерфейсе KUMA перейдите на вкладку Ресурсы – Агенты и нажмите на кнопку Добавить агент.
В открывшейся вкладке Общие параметры необходимо выбрать Имя агента и Тенант, к которому он будет принадлежать.
На вкладке Подключение 1 в параметрах коннектора необходимо задать тип wmi. Для пункта Удаленные хосты необходимо задать параметры подключения к удаленным хостам со следующими ограничениями:
- имя хоста должно содержать полный FQDN хоста или ip-адрес;
- домен хоста должен содержать домен хоста или, в случае отсутствия домена FQDN или ip-адрес хоста;
- тип журналов задается в соответствии с требованиями к логированию;
- в поле секрет необходимо выбрать или создать новый секрет типа credentials с указанием логина и пароля, при этом логин необходимо задавать без доменной части (user – правильно, domain\user – неправильно, user@domain -–неправильно). Учетная запись заданная в параметрах доступа к хосту должна быть членом группы читателей журнала событий (подробнее см. Приложение А).
Указывать и использовать для настройки подключения к хостам учетную запись по умолчанию (Default credentials) не рекомендуется.
Указываем IP в полях Хост и Домен в случае, если используется локальная УЗ на системе для собора логов, иначе имя хоста и его домен. В параметрах Секрет НЕ указывайте домен, достаточно использовать логин и пароль.
В общих параметрах точки назначения необходимо указать тип http (должен совпадать с настройками коллектора). URL нужно указать в формате fqdn:port (FQDN коллектора и порт, должны совпадать с настройками коллектора).
Для версии 3.0+ параметр State (Состояние) должен быть включен:
В дополнительных параметрах необходимо указать Режим TLS С верификацией, если требуется шифровать соединение между коллектором и агентом (настройка должна совпадать с соответствующей на стороне коллектора). Разделитель необходимо указать \0 (должен совпадать с настройками коллектора). Также на изображении ниже приведены дополнительные параметры и их рекомендуемые значения.
После указания всех параметров необходимо сохранить созданный ресурс агента.
Публикация агента KUMA
В разделе Ресурсы – Активные сервисы необходимо опубликовать созданную конфигурацию KUMA Windows Agent.
После публикации сервиса необходимо скопировать id данного сервиса для последующей установки на компьютере под управлением Windows.
Установка агента KUMA
Выполняется на сервере Windows, журналы которого необходимо направить в KUMA. Предварительно FQDN KUMA должен быть добавлен в файл hosts на целевой машине, либо добавлен в DNS-зону организации.
- в файловой системе сервера рекомендуется создать папку
C:\Users\<имя пользователя>\Desktop\KUMA
- скопировать в нее бинарный файл kuma.exe
Файл kuma.exe находится в архиве пакетов установки 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 <Windows User> --install
В результате, в ОС установится сервис KUMA Windows Agent <Windows Agent ID>
Если статус агента веб-интерфейсе 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:
Для отдельного компьютера необходимо перейти в оснастку Управление компьютером, выбрать пункт Локальные пользователи и группы, перейти на вкладку Группы, выбрать группу Event Log Readers и добавить в нее соответствующую учетную запись пользователя или компьютера:
Приложение Б. Назначение прав входа в качестве службы
Для назначения прав входа в качестве службы для компьютеров домена необходимо открыть оснастку 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.
После сохранения настроек для их применения на целевом компьютере необходимо из командной строки, запущенной от имени администратора выполнить команду: gpupdate /Force
Права входа в качестве службы можно настроить локально для отдельного компьютера с помощью оснастки Local Security Policy. Для этого необходимо выбрать пункт Local Policies, перейти на вкладку User Rights Assignment и в свойства Log on as service добавить соответствующую учетную запись пользователя. Дополнительно, необходимо убедиться, что соответствующая учетная запись отсутствует в свойствах Deny log on as service.
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)
Рекомендации для сервера WEC
- Рекомендациям Microsoft по мощностям WEC сервера (4-8 CPU 16 GB) - https://docs.microsoft.com/en-us/troubleshoot/windows-server/admin-development/configure-eventlog-forwarding-performance
- Рекомендация использовать до 1500 станций на один сервер (максимум по указанным выше мощностям 4000 машин)
- на котроллеры домена не надо ставить ничего лишнего
- события с контроллеров домена необходимо собирать с использованием механизмов, рекомендуемых MS. В данном случае это будут серверы WEC
Отказоустойчивый сбор событий с WEC
- на котроллеры домена не надо ставить ничего лишнего
- события с контроллеров домена необходимо собирать с использованием механизмов, рекомендуемых MS. В данном случае это будут серверы WEC
- использовать 2 WEC сервера
- все DC отправляют события не на один, а на 2 WEC сервера (события обоих WEC дублируются)
- на каждом WEC сервере установлены KUMA Agent
- оба KUMA Agent отправляют события в ОДИН и тот же коллектор Windows (это важный момент)
- на коллекторе Windows настраивается агрегация события, чтобы дубли событий с обоих WEC серверов были агрегированы в одно событий
Описание схемы работы с Windows Event Collector
Компоненты схемы:
- Источники событий (рабочие станции/серверы).
- Windows Event Collector сервер или WEC-сервер (сервер, с запущенной службой «Сборщик событий Windows». Данный сервер на основании создаваемых подписок на события получает события от источников и обеспечивает их локальное хранение. Взаимодействие между WEC-сервером и источниками событий осуществляется с использованием протокола удаленного управления Windows (WS-Management protocol). Для настройки доступно два типа подписок:
- Source-initiated subscriptions (Push) — события отправляются источником. Источники настраиваются на отправку событий на WEC-сервер с помощью GPO.
- Collector-initiated subscriptions (Pull) — события собираются WEC-сервером самостоятельно. WEC-сервер подключается к рабочим станциям/серверам и забирает события из локальных журналов.
- Агент KUMA (компонент KUMA, устанавливаемый на WEC-сервер для отправки собранных событий с источников в коллектор KUMA).
- Коллектор KUMA (компонент KUMA, обеспечивающий прием/нормализацию/агрегацию/фильтрацию событий, полученных от агента KUMA, и их дальнейшую отправку в коррелятор и/или хранилище KUMA).
В данном примере мы рассмотрим вариант Source-initiated subscriptions (режим Push) ввиду того, что этот режим более предпочтителен из-за отсутствия необходимости настройки «прослушивания» входящих соединений службой WinRM на источниках событий.
Также о Windows Event Collector можно почитать здесь: https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector.
Настройка политики аудита
По умолчанию на устройствах Windows аудит событий не осуществляется.
Настройка политики аудита на отдельной рабочей станции/сервере
Запустите оснастку Локальная политика безопасности (нажмите кнопку Win -> введите secpol.msc и запустите Локальная политика безопасности от имени администратора).
Перейдите в политику аудита (Локальные политики -> Политика аудита).
Настройте параметры аудита согласно скриншоту (при необходимости включите аудит оставшихся политик).
Примеры рекомендованных политик можно найти тут
Настройка политики аудита для группы рабочих станций/серверов средствами GPO
При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов настройки.
Создайте группу компьютеров средствами «Active Directory – пользователи и компьютеры». Добавьте в данную группу рабочие станции/серверы, с которых предполагается сбор событий.
Для того, чтобы изменения вступили в силу (в данном случае членство в новой группе), необходимо выполнить перезагрузку устройства. Альтернативным вариантом может быть перевыпуск Kerberos-тикетов для устройства с помощью klist.exe.
Если предполагается сбор событий с контроллера домена, в таком случае, контроллер домена можно не добавлять в созданную группу компьютеров, добавив отдельно в Фильтр безопасности при настройке GPO
На контроллере домена запустите оснастку Управление групповой политикой (нажмите Win + R -> gpmc.msc).
Выберите существующий объект групповой политики или создайте новый. В данном примере создается новый объект групповой политики Audit Policy for KUMA (правой кнопкой мыши Объекты групповой политики -> Создать -> введите в имени Audit Policy for KUMA).
Далее выберите созданный объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политики аудита и настройте параметры аудита согласно скриншоту (при необходимости включите аудит оставшихся политик).
Далее вернитесь в Управление групповой политикой -> выберите объект групповой политики Audit Policy for KUMA -> в окне справа Фильтры безопасности удалите группу Прошедшие проверку и добавьте группу KUMA WEC.
Нажмите правой кнопкой мыши на домен и выберите Связать существующий объект групповой политики -> выберите Audit Policy for KUMA и нажмите ОК.
Итоговый вид политики должен выглядеть следующим образом (см. скриншот).
В целом, групповые политики Active Directory можно назначать на OU, сайт или весь домен.
Для того, чтобы новые параметры аудита, заданные в GPO, были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:
- перезагрузка устройства и вход пользователя
- автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени)
- вручную с помощью команды gpupdate (на рабочей станции/сервере)
- вручную из консоли Group Policy Management Console (на контроллере домена, только для OU)
- вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена)
Для проверки успешного применения GPO запустите оснастку Локальная политика безопасности на одной из рабочих станций/сервере (нажмите WIN + R -> введите secpol.msc и запустите Локальная политика безопасности от имени администратора) -> перейдите в политику аудита (Локальные политики > Политика аудита) -> убедитесь, что параметры аудита соответствуют скриншоту.
Примеры рекомендованных политик аудита можно найти тут
Настройка WEC-сервера
Настройка службы Windows Event Collector (WEC)
Проверьте наличие запущенной службы WinRM на WEC-сервере с помощью следующей команды в PowerShell:
Test-WSMan
Вывод в случае если служба WinRM запущена:
Если появилось сообщение, что «Клиенту не удается подключиться к узлу назначения, указанному в запросе. Убедитесь, что служба на узле назначения работает и принимает запросы», запустите на WEC-сервере службу WinRM с помощью следующей команды в PowerShell:
winrm qc
При применении команды согласиться с выполнением изменений. После включения службы WinRM WEC-сервер начнет «прослушивать» соединения на порт TCP/5985 от источников событий.
Команда winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно следующей командой:
winrm set winrm/config/Winrs ‘@{AllowRemoteShellAccess = "false"}’
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’ # проверка, что WinRS отключен
Включите на WEC-сервере службу сборщика событий Windows («Сборщик событий Windows») с помощью следующей команды в PowerShell:
wecutil qc
При включении службы сборщика событий Windows в Windows Firewall автоматически создается разрешающее правило для входящих соединений по TCP/5985.
Настройка подписки на WEC-сервере
Нажмите кнопку Win, введите eventvwr.msc и запустите Просмотр событий от имени администратора. Выберите Подписки -> правой кнопкой мыши Создать подписку -> Укажите имя подписки, например, KUMA WEC и тип подписки Инициировано исходным компьютером.
Выберите группы компьютеров, события которых требуется собирать. В нашем примере – это KUMA WEC (Выбрать группы компьютеров -> Добавить доменный компьютер -> в поле Введите имена выбираемых объектов укажите ранее созданную группу компьютеров и нажмите ОК).
В качестве альтернативы вместо группы компьютеров можно добавить необходимые рабочие станции/серверы по отдельности.
Если предполагается сбор событий с контроллера домена, в таком случае, контроллер домена можно добавить как отдельный доменный компьютер
Задайте собираемые события (Выбрать события -> Настройте параметры, как на скриншоте ниже). В данном примере с источников собираются следующие события (Рекомендованные ID события можно найти тут): 4624,4625,4662,4719,4720,4722,4724,4725,4726,4728,4729,4739,4740,4767,4768,4769,4771,5136.
Нажмите ОК.
Далее перейдите в Дополнительно и для параметра Оптимизация доставки событий укажите Уменьшенная задержка. Нажмите ОК.
В одну подписку можно добавить не более 22 уникальных Event ID (кодов событий). Если указать больше, то на стороне источников событий (Журналы приложений и служб/Microsoft/Windows/Eventlog-ForwardingPlugin/Operational) появится ошибка "Не удается создать подписку <Наименование подписки>. Код ошибки: 5004.", при этом события от источников перестанут поступать на WEC-сервер.
Поэтому, если стоит задача собирать большое количество разных типов событий, в таком случае создайте несколько подписок, в каждой из которых будет свой уникальный набор Event ID.
Если в подписке не задан фильтр по Event ID, то есть используется значение по умолчанию "<Все коды событий>", ограничение в 22 уникальных Event ID отсутствует и выполняется сбор всех журналируемых событий.
При наличии одинаковых Event ID в разных подписках, события будут дублироваться, как на WEC-сервере, так и в KUMA. Поэтому при создании нескольких подписок проверьте наличие дубликатов Event ID.
Настройка WinRM и подписки на источниках событий
Для отдельной рабочей станции/сервера
Настройка службы WinRM
Проверьте наличие запущенной службы WinRM на рабочей станции/сервере с помощью следующей команды в PowerShell:
Test-WSMan
Вывод в случае, если служба WinRM запущена:
Если появилось сообщение, что «Клиенту не удается подключиться к узлу назначения, указанному в запросе. Убедитесь, что служба на узле назначения работает и принимает запросы», запустите на рабочей станции/сервере службу WinRM с помощью следующей команды в PowerShell:
winrm qc
При применении команды согласиться с выполнением изменений, кроме «Служба WinRM не настроена на разрешение удаленного управления компьютером. Разрешите исключение брандмауэра WinRM».
После включения службы WinRM рабочая станция/сервер начнет «прослушивать» соединения на порт TCP/5985. Для отключения данного listener’а (т.к. рабочая станция/сервер инициирует соединение к WEC-серверу, выступая в качестве клиента) выполните следующую команду в PowerShell:
Remove-WSManInstance winrm/config/Listener -SelectorSet @{Address="*";Transport="http"}
Команда winrm qc
одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно следующей командой:
winrm set winrm/config/Winrs ‘@{AllowRemoteShellAccess = "false"}’
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’ # проверка, что WinRS отключен
На источнике событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers («Читатели журнала событий»).
Для этого нажмите кнопку Win -> введите lusrmgr.msc и запустите Локальные пользователи и группы от имени администратора. В появившемся окне выберите перейдите в Группы -> выберите группу Читатели журнала событий -> правой кнопкой мыши Свойства -> Добавить -> в Размещение выберите имя рабочей станции -> в поле Введите имена выбираемых объектов укажите NETWORK SERVICE -> Проверить имена -> как только УЗ будет найдена нажмите ОК.
Для сбора событий журнала Security с контроллера домена необходимо предоставить доступ к журналу встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20), из-под которой запускается сервис WinRM.
Для этого на контроллере домена в PowerShell выполните следующую команду:
wevtutil sl security /ca:'O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)'
Настройка подписки
Нажмите кнопку Win -> введите Политики и запустите Изменение групповой политики от имени администратора. В появившемся окне перейдите в Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Пересылка событий -> Настроить конечный диспетчер подписки. Выберите Включено и нажмите Показать. В появившемся окне введите параметры WEC-сервера:
Server=http://<обязательно FQDN (не IP !!!) WEC-сервера>:5985/wsman/SubscriptionManager/WEC,Refresh=60
где 60 – частота обращения (в секундах) источников событий к WEC-серверу за новыми инструкциями по пересылке журналов.
Источники событий должны иметь возможность «резолвить» FQDN WEC-сервера для отправки событий. Для этого создайте A-запись на DNS-сервере или создайте запись локально в файле hosts
После применения данной настройки перезапустите службу WinRM c помощью PowerShell-команды:
Restart-Service -Name WinRM
Для группы рабочих станций/серверов средствами GPO
Настройка службы WinRM
При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов.
На контроллере домена запустите оснастку Управление групповой политикой (нажмите Win + R -> gpmc.msc).
Выберите ранее использовавшийся объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Системные службы -> в списке служб найдите «Служба удаленного управления Windows (WS-Management)» -> Свойства -> укажите параметры согласно скриншоту ниже. Нажмите Применить и ОК.
Далее перейдите в Конфигурация компьютера -> Настройка -> Параметры панели управления -> Службы -> справа в окне нажмите Создать -> Службы -> укажите параметры согласно скриншоту ниже.
Перейдите во вкладку Восстановление и укажите параметры согласно скриншоту ниже. Нажмите Применить и ОК.
Перейдите в Конфигурация компьютера -> Политики -> Административные шаблоны -> Компоненты Windows -> Удаленное управление Windows -> Служба удаленного управления Windows -> выберите Разрешить удаленное администрирование сервера средствами WinRM и укажите параметры согласно скриншоту ниже.
Перейдите в Конфигурация компьютера -> Политики -> Административные шаблоны -> Компоненты Windows -> Удаленное оболочка Windows -> выберите Разрешить доступ к удаленной оболочке и укажите параметры согласно скриншоту ниже.
Также на источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers («Читатели журнала событий»).
Для этого выберите ранее использовавшийся объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера -> Настройка -> Параметры панели управления -> нажмите правой кнопкой мыши на Локальные пользователи и группы -> Создать -> Локальная группа. В появившемся окне укажите параметры согласно скриншоту ниже. Нажмите Применить и ОК.
При добавлении члена локальной группы введите NETWORK SERVICE и нажмите ОК.
Для того, чтобы новые параметры групповой политики Audit Policy for KUMA были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:
- перезагрузка устройства и вход пользователя
- автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени)
- вручную с помощью команды gpupdate (на рабочей станции/сервере)
- вручную из консоли Group Policy Management Console (на контроллере домена, только для GPO)
- вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена)
Проверьте наличие запущенной службы WinRM на одной из рабочих станций/сервере с помощью следующей команды в PowerShell:
Test-WSMan
Вывод в случае, если служба WinRM запущена:
Убедитесь, что WinRS отключен с помощью следующей команды:
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’
Убедитесь, что порт TCP/5985 не «прослушивается» (т.к. рабочая станция/сервер инициирует соединение к WEC-серверу, выступая в качестве клиента):
netstat -aon -p TCP # выполнить в cmd
Для сбора событий журнала Security с контроллера домена необходимо предоставить доступ к журналу встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20), из-под которой запускается сервис WinRM.
Для этого на контроллере домена в PowerShell выполните следующую команду:
wevtutil sl security /ca:'O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)'
Настройка подписки
Выберите ранее использовавшийся объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера -> Политики -> Административные шаблоны -> Компоненты Windows -> Пересылка событий -> Настроить конечный диспетчер подписки. Выберите Включено и нажмите Показать. В появившемся окне введите параметры WEC-сервера:
Server=http://<обязательно
FQDN сервера-коллектора>:5985/wsman/SubscriptionManager/WEC,Refresh=60
где 60 – частота обращения (в секундах) источников событий к серверу за новыми инструкциями по пересылке журналов.
Источники событий должны иметь возможность «резолвить» FQDN WEC-сервера для отправки событий. Для этого создайте A-запись на DNS-сервере или создайте запись локально в файле hosts
Для того, чтобы новые параметры групповой политики Audit Policy for KUMA были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:
- перезагрузка устройства и вход пользователя
- автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени)
- вручную с помощью команды gpupdate (на рабочей станции/сервере)
- вручную из консоли Group Policy Management Console (на контроллере домена, только для OU)
- вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена)
Проверка поступления событий
Убедитесь, что на WEC-сервер поступают события с рабочих станций/серверов. Для этого нажмите кнопку Win, введите eventvwr.msc и запустите Просмотр событий от имени администратора. Перейдите в Журналы Windows -> Перенаправленные события. Если в появившемся окне Перенаправленные события отображаются события с источников, значит подписка работает корректно.
Для MS Server 2016 и 2019 в случае если события не пересылаются, выполнить шаги по этой инструкции. При добавлении разрешения для URL-адреса с помощью netsh http add urlacl добавьте кавычки "..." в параметре SDDL:netsh http delete urlacl url=http://+:5985/wsman/
netsh http add urlacl url=http://+:5985/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"
netsh http delete urlacl url=https://+:5986/wsman/
netsh http add urlacl url=https://+:5986/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"
В случае если определенный лог не отправляется от источника проверьте на нем в журнале Microsoft/windows/event_forwardingPlugin/Operational
события с кодом 5004 ( ), если там есть такие события, то выполните рекомендации по этой статье: https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/system-management-components/security-event-log-forwarding-fails-error-0x138c-5004
Настройка коллектора и агента KUMA
Создание коллектора KUMA
Для создания коллектора в веб-интерфейсе KUMA перейдите на вкладку Ресурсы -> Коллекторы и нажмите на кнопку Добавить коллектор. Также можно на вкладке Ресурсы нажать на кнопку Подключить источник событий.
После выполнения вышеуказанных действий откроется мастер настройки. На первом шаге выберите Имя коллектора и Тенант, к которому будет принадлежать создаваемый коллектор.
На втором шаге мастера укажите транспорт. В данном случае рекомендуется использовать http. В поле URL задайте FQDN/порт (выбирается любой из незанятых), на котором коллектор будет ожидать соединение от агента. В качестве разделителя укажите \0.
*можно указать только порт при инсталляции All-in-one.
На вкладке Дополнительные параметры для шифрованной передачи данных между агентом и коллектором выберите Режим TLS - С верификацией.
На третьем шаге мастера укажите нормализатор. В данном случае рекомендуется использовать предустановленный расширенный нормализатор для событий Windows актуальный для версии 3.2 - [OOTB] Microsoft Products for KUMA 3.
Шаги мастера настройки с четвертого по шестой можно пропустить и вернуться к их настройке позднее.
На седьмом шаге мастера задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище. В случае если предполагается также корреляция по событиям добавьте точку назначения типа Коррелятор.
На завершающем шаге мастера нажмите на кнопку Создать и сохранить сервис. После чего появится строка установки сервиса, которую необходимо скопировать для дальнейшей установки.
Также после выполнения вышеуказанных действий на вкладке Ресурсы -> Активные сервисы появится созданный сервис коллектора.
Установка коллектора KUMA
Выполните подключение к CLI KUMA (установка коллектора выполняется с правами root).
Для установки сервиса коллектора в командной строке выполните команду, скопированную на прошлом шаге.
При необходимости добавьте порт коллектора в исключения фаервола и обновите параметры службы.
firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp –permanent
firewall-cmd --reload
После успешной установки сервиса его в статус в веб-консоли KUMA изменится на зеленый.
Создание агента KUMA
Для создания агента в веб-интерфейсе KUMA перейдите на вкладку Ресурсы -> Агенты и нажмите на кнопку Добавить агент.
В открывшейся вкладке Общие параметры укажите Имя агента и Тенант, к которому он будет принадлежать.
На вкладке Подключение 1 в параметрах коннектора задайте имя коннектора, тип wec и выберите из выпадающего списка журналы Windows типа ForwardedEvents. Также можно в ручном режиме задать дополнительные журналы Windows.
В секции Точки назначения укажите имя точки назначения, тип http (должен совпадать с настройками коллектора). Задайте URL в формате fqdn:port (FQDN коллектора и порт, должны совпадать с настройками коллектора).
В дополнительных параметрах укажите Режим TLS С верификацией, если требуется шифровать соединение между коллектором и агентом (настройка должна совпадать с соответствующей на стороне коллектора). Укажите разделитель \0 (должен совпадать с настройками коллектора). Также на изображении ниже приведены дополнительные параметры и их рекомендуемые значения.
После настройки дополнительных параметров сохраните созданный ресурс агента.
Публикация агента KUMA
В разделе Ресурсы -> Активные сервисы опубликуйте созданную конфигурацию KUMA Windows Agent. Для этого нажмите Создать сервис -> выберите созданный сервис агента Windows WEC Agent и нажмите Создать сервис.
После публикации сервиса скопируйте id данного сервиса для последующей установки на WEC-сервере.
Установка агента KUMA
Создание сервисной учетной записи
Для функционирования агента KUMA необходимо создать доменную сервисную учетную запись, с помощью которой будет выполняться запуск агента KUMA и обеспечиваться доступ к журналам событий, полученных от источников (рабочих станций/серверов).
Добавление сервисной учетной записи в группу "Читатели журнала событий"
На WEC-сервере добавьте созданную сервисную учетную запись в локальную группу Читатели журнала событий. Для этого нажмите кнопку Win, введите lusrmgr.msc и запустите Локальные пользователи и группы от имени администратора. В появившемся окне выберите перейдите в Группы -> выберите группу Читатели журнала событий -> правой кнопкой мыши Свойства -> Добавить -> в поле Введите имена выбираемых объектов укажите <имя сервисной учетной записи> -> Проверить имена -> как только УЗ будет найдена нажмите ОК.
Назначение прав входа в качестве службы
На WEC-сервере разрешите сервисной учетной записи вход в качестве службы. Для этого нажмите кнопку Win, введите secpol.msc и запустите Локальная политика безопасности от имени администратора. В появившемся окне выберите перейдите в Локальные политики -> Назначение прав пользователя -> Выберите политику Вход в качестве службы -> правой кнопкой мыши Свойства -> Добавить пользователя или группу -> в поле Введите имена выбираемых объектов укажите <имя сервисной учетной записи> -> Проверить имена -> как только УЗ будет найдена нажмите ОК.
Дополнительно убедитесь, что соответствующая сервисная учетная запись отсутствует в свойствах политики Отказать во входе в качестве службы.
Установка агента KUMA
Выполняется на WEC-сервере, который обеспечивает прием событий от источников (рабочих станций/серверов). Предварительно FQDN Core KUMA должен быть добавлен в файл hosts на WEC-сервере, либо добавлен на DNS-сервере.
На WEC-сервере рекомендуется создать папку C:\Users\<имя пользователя>\Desktop\KUMA.
Далее скопируйте в данную папку исполняемый файл kuma.exe.
Файл kuma.exe находится в архиве пакетов установки KUMA.
Для установки агента KUMA запустите командную строку с правами администратора.
Примите лицензионное соглашение: C:\Users\<имя пользователя>\Desktop\KUMA\kuma.exe license
Перейдите в папку C:\Users\<имя пользователя>\Desktop\KUMA
Запустите установку агента командой:
C:\Users\<имя пользователя>\Desktop\KUMA>kuma.exe agent --core https://<DOMAIN-NAME-KUMA-CORE-Server>:7210 --id <Windows Agent ID> –-user <Имя сервисной доменной УЗ> --install
Если агент устанавливается из-под доменной учетной записи пользователь указывается в формате <домен>\<имя учетной записи>, например, demo\user
Во время установки сервиса система запросит пароль. Введите пароль сервисной доменной учетной записи.
В результате, на WEC-сервере будет установлен сервис KUMA Windows Agent <Windows Agent ID>.
Если статус агента в веб-интерфейсе KUMA красный, необходимо удостовериться в доступности портов 7210 и порта коллектора Windows по направлению от агента к KUMA Collector.
Для удаления сервиса агента KUMA по окончанию тестирования продукта выполните следующую команду:
C:\Users\<имя пользователя>\Desktop\KUMA>kuma.exe agent --id <Windows Agent ID> --uninstall
Проверка поступления событий Windows в KUMA
Для проверки, что сбор событий с устройств Windows успешно настроен перейдите в Ресурсы -> Активные сервисы -> выберите ранее созданный коллектор для Windows и нажмите Перейти к событиям.
В открывшемся окне События убедитесь, что присутствуют события с Windows-устройств.
Настройка подписки WEC с использованием XML фильтра
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
При настройке подписки WEC через графический интерфейс не получится выбрать нужные для сбора журналы, если на сервере с WEC не установлены соответствующие роли Windows Server или ПО.
Чтобы выбрать журналы, которые фактически присутствуют на удаленном сервере, но не доступны для выбора на 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 начнет собирать события из журнала контроллера домена 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 состоит из трёх отдельных компонентов:
- Провайдеры (Providers), в некоторых случаях зовутся поставщиками
- Потребители (Consumers)
- Контроллеры (Controllers)
Провайдеры генерируют события, потребители их используют, а контроллеры управляют всей этой деятельностью. Провайдеры - это приложения, которые содержат функционал отправки событий в ETW. Примеры провайдеров: ядро Windows, драйвера устройств, user-mode приложения и другое ПО. Какие необходимо отправлять события решает разработчик в своём коде, упрощенно говоря, если выполняется важная с точки зрения разработчика функция (открывается доступ к SAM), то создается запись в ETW.
Для отправки провайдеры регистрируются в контроллере, контроллер в свою очередь может включить или отключить источник событий. Отключенный источник события не генерирует. Пример контроллеров - это logman или wevtutil. Для связи между провайдером и потребителем контроллер использует так называемые сессии трассировки. Сессия служит в том числе для фильтрации необходимых данных по различными параметрам, потому что потребителю может быть нужна только одна часть информации, а другому потребителю - другая.
Полезные ссылки:
- https://habr.com/ru/articles/502362/
- https://learn.microsoft.com/ru-ru/archive/blogs/teamdhcp/network-forensics-with-windows-dns-analytical-logging
Настройка на стороне Windows
Переходим в EventViewer (Выполнить -> eventvwr.msc). Далее переходим в Журналы приложений и служб\Microsoft\Windows\DNS-Server (на англ. Applications and Services Logs\Microsoft\Windows\DNS-Server)
Далее переходим в свойства Аналитического журнала:
Оставляем максимальный размер журнала по умолчнию в 1 Гб:
Нажимаем на чекбокс Включить ведение журнала, затем ОК
Должно получиться следующее:
Нажимаем Применить и ОК.
При появлении следующего окна, не пугаемся, при включенной ротации аналитического журнала события не отображаются в интерфейсе, чтобы их увидеть (нам это не понадобится) нужно остановить журнал.
Далее необходимо перейти в Управление компьютером и открыть его от Админиcтратора. Переходим Служебные программы - Производительность - Сеансы отслеживания событий запуска.
Создаем группу сборщиков данных:
Задаем имя сборщика, например etwDNS-Analytics:
Добавляем поставщика Microsoft-Windows-DNSServer:
Агент с коннектором ETW работает только с System.Provider.Guid: {EB79061A-A566-4698-9119-3ED2807060E7} - Microsoft-Windows-DNSServer
Нажимаем Далее - Далее - Готово.
Запускаем созданного поставщика, как сеанс отслеживания событий:
Далее в сеансах отслеживания событий, в свойствах - Сеансы отслеживания указываем Режим реального времени
Нажимаем Применить и ОК.
Чтобы просмотреть, какие типы событий можно отслеживать, выполните следующую команду в командной строке powershell:
logman query providers "Microsoft-Windows-DNSServer"
Пример вывода:
Настройка коллектора и агента KUMA
Создание коллектора KUMA
Для создания коллектора в веб-интерфейсе KUMA перейдите на вкладку Ресурсы -> Коллекторы и нажмите на кнопку Добавить коллектор.
После выполнения вышеуказанных действий откроется мастер настройки. На первом шаге выберите Имя коллектора и Тенант, к которому будет принадлежать создаваемый коллектор.
На втором шаге мастера укажите транспорт. В нашем случае используется TCP (можно также использовать http и режимы с верификацией для защищенной отправки). В поле URL задайте FQDN/порт (выбирается любой из незанятых), на котором коллектор будет ожидать соединение от агента. В качестве разделителя укажите \n.
*можно указать только порт при инсталляции All-in-one.
На третьем шаге мастера укажите нормализатор. В данном случае рекомендуется использовать предустановленный расширенный нормализатор для событий Windows [OOTB] Microsoft DNS ETW logs json.
Шаги мастера настройки с четвертого по шестой можно пропустить и вернуться к их настройке позднее.
На седьмом шаге мастера задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище. В случае если предполагается также корреляция по событиям добавьте точку назначения типа Коррелятор.
На завершающем шаге мастера нажмите на кнопку Создать и сохранить сервис. После чего появится строка установки сервиса, которую необходимо скопировать для дальнейшей установки.
Также после выполнения вышеуказанных действий на вкладке Ресурсы -> Активные сервисы появится созданный сервис коллектора.
Установка коллектора KUMA
Выполните подключение к CLI KUMA (установка коллектора выполняется с правами root).
Для установки сервиса коллектора в командной строке выполните команду, скопированную на прошлом шаге.
При необходимости добавьте порт коллектора в исключения фаервола и обновите параметры службы.
firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp –permanent
firewall-cmd --reload
После успешной установки сервиса его в статус в веб-консоли KUMA изменится на зеленый.
Создание агента KUMA
Для создания агента в веб-интерфейсе KUMA перейдите на вкладку Ресурсы -> Агенты и нажмите на кнопку Добавить агент.
В открывшейся вкладке Общие параметры укажите Имя агента и Тенант, к которому он будет принадлежать.
На вкладке Подключение 1 в параметрах коннектора задайте имя коннектора, тип etw и укажите имя сессии (это имя сборщика созданного на этапе настройки на стороне Windows) в нашем случае это etwDNS-Analytics.
В секции Точки назначения укажите имя точки назначения, тип tcp (должен совпадать с настройками коллектора). Задайте URL в формате fqdn:port (FQDN коллектора и порт, должны совпадать с настройками коллектора).
В дополнительных параметрах укажите размер дискового буфера в 1 Гб.
После настройки дополнительных параметров сохраните созданный ресурс агента.
Публикация агента KUMA
В разделе Ресурсы -> Активные сервисы опубликуйте созданную конфигурацию Agent ETW. Для этого нажмите Создать сервис -> выберите созданный сервис агента Agent ETW и нажмите Создать сервис. После публикации сервиса скопируйте его идентификатор нажатием на ПКМ данного сервиса для последующей установки агента на Windows сервере.
Установка агента KUMA
Создание учетной записи
Для функционирования агента KUMA необходимо создать либо доменную сервисную учетную запись, либо локальную УЗ с помощью которой будет выполняться запуск агента KUMA и обеспечиваться доступ к чтению аналитического журнала.
Для УЗ требуются следующие группы и права:
- Пользователи журналов производительности (Performance Log Users group) (чтение журнала, настройка в свойствах пользователя);
- Вход в качестве службы (Log on service) (права на запуск сервиса агента, настройка в политиках безопасности).
После запуска сервиса агента можно переключиться на системную локальную учетку (LocalSystem), сделать это можно через Services на Windows. Иногда такое целесообразно при ротации паролей в УЗ.
Установка агента KUMA
Выполняется на Windows сервере, который обеспечивает прием событий от источников (рабочих станций/серверов). Предварительно FQDN Core KUMA должен быть добавлен в файл hosts на Windows сервере, либо добавлен на DNS-сервере. На Windows сервере рекомендуется создать папку C:\Users\<имя пользователя>\Desktop\KUMA.
Далее скопируйте в данную папку исполняемый файл kuma.exe.
Файл kuma.exe находится в архиве пакетов установки KUMA.
Для установки агента 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
Во время установки сервиса система запросит пароль. Введите пароль сервисной доменной учетной записи.
В результате, на Windows сервере будет установлен сервис KUMA Windows Agent <Windows Agent ID>.
Если статус агента в веб-интерфейсе KUMA красный, необходимо удостовериться в доступности портов 7210 и порта коллектора Windows по направлению от агента к KUMA Collector.
Для удаления сервиса агента KUMA по окончанию тестирования продукта выполните следующую команду:
C:\Users\<имя пользователя>\Desktop\KUMA>kuma.exe agent --id <Windows Agent ID> --uninstall
Проверка поступления событий Windows в KUMA
Для проверки, что сбор событий с устройств Windows успешно настроен перейдите в Ресурсы -> Активные сервисы -> выберите (чекбокс) ранее созданный коллектор для Windows и нажмите Перейти к событиям. Либо ПКМ - Перейти к событиям. В открывшемся окне События убедитесь, что присутствуют события с Windows-устройств.
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 (если есть).
Дождитесь завершения установки и перезагрузите компьютер.
Убедитесь, что службы SNMP запущена (Панель управления - Администрирование - Службы): Служба SNMP (SNMP Service) и Служба ловушек SNMP (SNMP Trap). Если какие-то из перечисленных ниже служб не запущены - Запустите
Настройка сервиса SNMP
Перейдите в Панель управления - Администрирование - Службы - Служба SNMP (Свойства) - Вкладка Ловушки
Добавьте имя сообщества: public
Адрес назначения ловушек: <IP_адрес_коллектора>
На вкладке Безопасность:
- Установите флажок: Посылать ловушку проверки подлинности (Send authentication trap)
- В таблице Приемлемые имена сообществ (Accepted community names) добавьте сообщество: public, с правами READ WRITE
- Установите флажок: Принимать пакеты SNMP от любого узла (Accept SNMP packets from any hosts)
Затем Применить и ОК.
Настройки на стороне KUMA
Создайте коллектор со следующим транспортом:
В дополнительных параметрах в случае Русской локали в ОС кажите явно кодировку:
В качестве парсера рекомендуем использовать комьюнити нормализатор (предварительно импортируйте его в KUMA, пароль импорта: q123123Q!
): ссылка
Задайте маршрут куда отправлять обработанные события коллектором:
Нажмите сохранить и создать сервис, скопируйте строку установки и выполните ее в консоли SSH.
SNMP использует порт 161 UDP для общих сообщений, для ловушек используется порт 162 UDP. Для прослушки порта SNMP обновите параметры службы в Linux (предварительно скопируйте ID коллектора), инструкция как настроить прослушку ниже 1024 порта в Linux: ссылка
Настройка аудита на стороне Windows
Нажмите Пуск - Выполнить - Введите: evntwin
- В переключателе Тип конфигурации (Configuration type) выберите особая (Custom), а затем нажмите на кнопку Правка (Edit)
- В блоке параметров Источники событий (Event sources) найдите и добавьте с помощью кнопки Добавить (Add) события, которые вы хотите отправить в коллектор KUMA с установленным коннектором SNMP Trap (рекомендуется отправлять все из папки Security)
- Нажмите на кнопку Settings, в открывшемся окне установите флажок Не применять глушитель (Don't apply throttle) и нажмите OK
- Нажмите Применить (Apply) и ОК
Генерация тестовых событий на Windows
Создайте и удалите тестового пользователя в системе для генерации событий в Панель управления - Администрирование - Управление компьютером - Локальные пользователи - Папка пользователи.
При корректных настройках в кума должно отобразиться событие:
Аналог 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 !"
Вот как это выглядит в работе:
На стороне KUMA:
Мониторинг ключей реестра Windows
Для мониторинга ключей реестра в KUMA можно использовать стандартные механизмы аудита Windows. Для этого необходимо настроить расширенный аудит на доступ к реестру и определить разделы, операции с ключами которых необходимо мониторить. Данные настройки могут быть выполнены локально на сервере, а также заданы с помощью групповой политики. В статье ниже будет рассказано о локальных настройках.
Настройка политики аудита
Запустите cmd.exe из-под учетной записи Администратора и выполните следующую команду:
auditpol /set /subcategory:"Реестр" /success:enable /failure:enable
Другим вариантом является внесение изменений в локальную политику безопасности. Чтобы выполнить его, откройте редактор Локальной политики безопасности и перейдите в "Параметры безопасности" - "Конфигурация расширенной политики аудита" - "Политики аудита системы" - "Объект локальной групповой политики" - "Доступ к объектам".
Откройте подкатегорию "Аудит реестра" и выставите необходимые значения
Настройка аудита раздела реестра
Откройте оснастку "Редактор реестра" и перейдите к разделу, аудит которого необходимо настроить
Нажмите ПКМ на нужном разделе и выберите пункт Разрешения
В открывшемся окне нажмите на кнопку "Дополнительно"
В новом окне перейдите на вкладку "Аудит" и добавьте необходимое правило аудита раздела. В данном примере настроен аудит полного доступа всех субъектов к текущему разделу и всем его подразделам.
Примените выполненные настройки.
Результат
В результате выполненных настроек в журнале безопасности (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):