Подключение источников В данном разделе приведены настройки по подключению источников событий. Официальная документация по настройке источников: https://support.kaspersky.com/KUMA/3.4/ru-RU/256206.htm  Официальная документация по настройке источников Ссылка: https://support.kaspersky.com/KUMA/3.4/ru-RU/256206.htm Настройка получения событий Auditd Настройка получения событий KATA/EDR Настройка получения событий Kaspersky Security Center в формате CEF Настройка получения событий Kaspersky Security Center из MS SQL Настройка получения событий с устройств Windows с помощью Агента KUMA (WEC) Настройка получения событий с устройств Windows с помощью Агента KUMA (WMI) Настройка получения событий DNS-сервера с помощью агента ETW Настройка получения событий PostgreSQL Настройка получения событий ИВК Кольчуга-К Настройка получения событий КриптоПро NGate Настройка получения событий Ideco UTM Настройка получения событий KWTS Настройка получения событий KLMS Настройка получения событий KSMG Настройка получения событий KICS for Networks Настройка получения событий PT NAD Настройка получения событий c помощью плагина MariaDB Audit Plugin Настройка получения событий СУБД Apache Cassandra Настройка получения событий FreeIPA Настройка получения событий VipNet TIAS Настройка получения событий Nextcloud Настройка получения событий Snort Настройка получения событий Suricata Настройка получения событий FreeRADIUS Настройка получения событий VMware vCenter Настройка получения событий zVirt Настройка получения событий Zeek IDS Настройка получения событий Windows с помощью Kaspersky Endpoint Security для Windows Настройка получения событий Сodemaster Mirada Настройка получения событий Postfix Настройка получения событий CommuniGate Pro Настройка получения событий Yandex Cloud Настройка получения событий Microsoft 365 Kaspersky Подключение источников производителя Kaspersky KSC CEF Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/241235.htm Функция экспорта событий Kaspersky Security Center в SIEM-системы в формате CEF доступна при наличии лицензии Kaspersky Endpoint Security для бизнеса Расширенный или выше . С версии KSC от 15.1 наличие лицензии не важно. Подробнее: https://support.kaspersky.ru/ksc/15.1/12521   Настройка передачи событий KSC в формате CEF Чтобы настроить передачу событий от Сервера администрирования Kaspersky Security Center в SIEM-систему KUMA: 1. В дереве консоли Kaspersky Security Center выберите узел Сервер администрирования . 2. В рабочей области узла выберите вкладку События . 3. Перейдите по ссылке  Настроить параметры уведомлений и экспорта событий  и в раскрывающемся списке выберите  Настроить экспорт в SIEM-систему . Откроется окно  Свойства : События . 4. Установите флажок  Автоматически экспортировать события в базу SIEM-системы . 5. В раскрывающемся списке SIEM-система  выберите  ArcSight (CEF-формат) . 6. Укажите адрес сервера SIEM-системы KUMA и порт для подключения к серверу в соответствующих полях. По кнопке  Экспортировать архив  Kaspersky Security Center экспортирует уже созданные события в базу SIEM-системы KUMA с указанной даты. По умолчанию Kaspersky Security Center экспортирует события с текущей даты. 7. Нажмите на кнопку  ОК . Настройка коллектора KUMA 1. В веб-интерфейсе KUMA перейдите в раздел Ресурсы → Коллекторы . 2. В списке коллекторов найдите коллектор с нормализатором [OOTB] KSC и откройте его для редактирования. Что делать, если ресурс не доступен для редактирования Начиная с версии KUMA 2.1 OOTB ресурсы недоступны для редактирования. В таком случае необходимо скопировать OOTB-ресурс и произвести редактирование в копии этого ресурса. Важно! При копировании OOTB ресурса, копируется и становится доступным для редактирования только сам ресурс. Связанные ресурсы нужно копировать и привязывать отдельно. 3. На шаге Транспорт в поле URL укажите порт, по которому коллектор будет получать события Kaspersky Security Center. 4. Порт должен совпадать с портом сервера SIEM-системы KUMA, указанным в настройках на стороне KSC. 5. На шаге Парсинг событий проверьте, что выбран нормализатор [OOTB] KSC . 6. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 7. На шаге Проверка параметров нажмите Сохранить и создать сервис . 8. Скопируйте появившуюся команду для установки коллектора KUMA. KSC MS SQL ✔️ Рекомендуется - Рекомендуемый способ сбора для этого источника событий Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/245386.htm SQL Server должен поддерживать TLS 1.2 - дополнительную информацию можно изучить тут: https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server Для отключения защищенного подключения к БД можно воспользоваться следующей опцией в коннекторе: sqlserver://user:password@server:port?database=DBName &encrypt=disable Настройка БД MS SQL Для сбора событий из БД MS SQL необходимо создать учетную запись с соответствующеми правами. Для этого выполните следующие действия: 1. Перейдите на сервер, где установлена БД MS SQL для KSC. С помощью Microsoft SQL Server Management Studio подключитесь к БД из-под учетной записи, обладающей правами администратора в БД. 2. Перейдите в соответствующий экземпляр БД MS SQL на вкладку Security и для вкладки Logins выберите New Login... 3. Добавьте учетную запись пользователя, с помощью которой будет осуществляться доступ к БД KSC 4. Установите для учетной записи БД KSC в качестве БД по умолчанию (по умолчанию в KSC используется БД KAV). 5. Настройте учетной записи права db_datareader и public для БД KSC в соответствии с изображением ниже. 6. Убедитесь, что созданной учетной записи разрешено подключение к БД. Для проверки прав созданной учетной записи можно запустить Microsoft SQL Management Studio от имени созданного пользователя (с зажатым Shift нажать ПКМ и выбрать Запуск от имени другого пользователя). Затем перейти в любую таблицу БД KSC и сделать выборку по этой таблице. Настройка SQL Server Browser Для подключения к серверу MS SQL для сбора событий необходимо настроить соответствующую службу и разрешить входящие подключения. Для этого выполните следующие действия: 1. Откройте оснастку SQL Server Configuration Manager. Запустите службу SQL Server Browser и задайте автоматический запуск службы. 2. Включите TCP/IP протокол для соответствующего экземпляра БД. 3. В свойствах протокола, на вкладке IP Addresses для поля IPALL в TCP Port укажите значение 1433. 4. Перезапустите службу экземпляра SQL сервера. 5. Разрешите на сервере входящие подключения по порту 1433. Это можно сделать в оснастке Брандмауэр защитника Windows в режиме повышенной безопасности. Создание секрета KUMA Для подключения к БД MS SQL со стороны KUMA необходимо создать строку подключения. Для этого выполните следующие действия: 1. В веб-интерфейсе KUMA перейдите на вкладку Ресурсы →   Секреты и нажмите на кнопку Добавить секрет . 2. Укажите  Имя секрета, выберите Тенант , к которому будет относиться создаваемый секрет. 3. Задайте секрету тип  urls и в поле URL укажите строку вида (в квадратных скобках опциональный параметр, квадратные скобки прописывать не надо): sqlserver://[%5C]:@:1433/<наименование БД> Если для подключения к БД на сервере MSSQL была создана локальная учетная запись и выбран тип Windows Authentication необходимо указать строку вида: sqlserver://%5C:@:1433/<наименование БД> По умолчанию наименование БД импользуется KAV : Примеры sqlserver://test.local%5Cuser:password123!@10.0.0.1:1433/KAV sqlserver://srv-mssql%5Clocaluser:password123!@10.0.0.1:1433/KAV sqlserver://user:password123!@server.demo.lab:1433/KAV %5C – используется для разделения домена и пользователя и представляет собой знак  \  в URL-формате. Если в пароле пользователя используются спецсимволы их также необходимо перевести в URL формат в соответствии с таблицей ниже. ! # $ % & ' ( ) * + %21 %23 %24 %25 %26 %27 %28 %29 %2A %2B , / : ; = ? @ [ ] \ %2C %2F %3A %3B %3D %3F %40 %5B %5D %5C Можно использовать следующий ресурс для преобразования https://www.urlencoder.org/ пример:  Если в пароле присутствуют другие спецсимволы, которые отсутствуют в таблице выше, либо просто для удобства, то с версии KUMA 3.2 можно использовать опцию - Секрет отдельно для указания логина и пароля. 4. Сохраните созданный секрет. Обратите внимание, после сохранения секрета поле URL будет пустым во избежание утечки чувствительной информации. Настройка коннектора 1. Для подключения к БД MS SQL необходимо настроить коннетор. Для этого выполните следующие действия 2. В веб-интерфейсе KUMA перейдите в раздел Ресурсы → Коннекторы . 3. В списке коннекторов справа найдите коннектор [OOTB] KSC SQL и откройте его для редактирования. Что делать, если ресурс не доступен для редактирования Начиная с версии KUMA 2.1 OOTB ресурсы недоступны для редактирования. В таком случае необходимо скопировать OOTB-ресурс и произвести редактирование в копии этого ресурса. Важно! При копировании OOTB ресурса, копируется и становится доступным для редактирования только сам ресурс. Связанные ресурсы нужно копировать и привязывать отдельно. 4. На вкладке Основные параметры в выпадающих списках URL выберите секрет, созданный для подключения к БД MS SQL. 5. Нажмите Сохранить . Запрос из коробки собирает события с таймзоной в UTC, для изменения на другую таймзону - измените запроса Настройка коллектора 1. В веб-интерфейсе KUMA перейдите в раздел Ресурсы → Коллекторы . 2. В списке коллекторов найдите коллектор с нормализатором [OOTB] KSC from SQL  и откройте его для редактирования. Что делать, если ресурс не доступен для редактирования Начиная с версии KUMA 2.1 OOTB ресурсы недоступны для редактирования. В таком случае необходимо скопировать OOTB-ресурс и произвести редактирование в копии этого ресурса. Важно! При копировании OOTB ресурса, копируется и становится доступным для редактирования только сам ресурс. Связанные ресурсы нужно копировать и привязывать отдельно. 3. На шаге Транспорт  выберите коннектор [OOTB] KSC SQL 4. На шаге Парсинг событий проверьте, что выбран нормализатор [OOTB] KSC from SQL . 6. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 7. На шаге Проверка параметров нажмите Сохранить и создать сервис . 8. Скопируйте появившуюся команду для установки коллектора KUMA. Альтернативный вариант создания коллектора В случае, если предполагается использование коробочных ресурсов без изменений: 1. В веб-интерфейсе KUMA перейдите в раздел  Ресурсы → Секреты 2. Откройте на редактирование секрет [OOTB] KSC MSSQL connection 3. Задайте в секрете строку подключения в соответствии с разделом " Создание секрета KUMA " 4. Сохраните созданный секрет с помощью кнопки " Сохранить " 5. В веб-интерфейсе KUMA перейдите в раздел  Ресурсы → Коллекторы . 6. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 7. На шаге Проверка параметров нажмите Сохранить и создать сервис . 8. Скопируйте появившуюся команду для установки коллектора KUMA. KSC PostgreSQL Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Настройка PostgreSQL Настройки на сервере БД PostgreSQL можно выполнять в консоли (SSH, терминал ОС) или средствами утилиты pgAdmin (требуется установка). В данной статье сервер БД PostgreSQL работает под управлением ОС Astra Linux, а все настройки выполняются в консоли. Для удобства в базе данных PostgreSQL Kaspersky Security Center предусмотрен набор публичных представлений. Таким образом можно создавать запросы непосредственно к публичным представлениям и извлекать из них данные о событиях. "Коробочный" коннектор KUMA  [OOTB] KSC PostgreSQL  содержит уже готовые запросы к публичным представлениям v_akpub_ev_event и v_akpub_host . Коннектор [OOTB] KSC PostgreSQL  позволяет экспортировать события из БД PostgreSQL Kaspersky Security Center (KSC) версии 15.0.  Проверена работоспособность коннектора с KSC 14.2 Windows (БД PostgreSQL). Проверка имени БД KSC Чтобы проверить имя базы данных  KSC можно воспользоваться следующей статьей: https://support.kaspersky.ru/ksc-linux/15/228689 (KSC Linux) Альтернативным вариантом является проверка имени БД в консоли сервера, на котором установлена БД KSC: Измените текущего пользователя на postgres sudo -i -u postgres Запустите интерактивный терминал PostgreSQL и выведите список баз данных сервера psql \l # вывод списка баз данных сервера Создание роли БД и предоставление прав После каждого обновления KSC права на представления сбрасываются и их нужно снова настраивать В консоли сервера, где установлена БД PostreSQL KSC, измените текущего пользователя на postgres  sudo -i -u postgres Запустите интерактивный терминал PostgreSQL psql Также для создания роли БД и предоставления ей соответствующих прав можно использовать существующую учетную запись с атрибутом  role creation  и правами доступа к публичным представлениям. Пример подключения к БД:  psql -U <имя УЗ> -d <имя БД KSC> Создайте роль пользователя kuma CREATE USER kuma WITH PASSWORD '<задайте пароль>'; Подключитесь к БД KSC (см. Раздел " Проверка имени БД KSC ". По умолчанию KAV) \connect KAV Предоставьте права роли KUMA GRANT SELECT ON v_akpub_ev_event TO kuma; GRANT SELECT ON v_akpub_host TO kuma; GRANT SELECT ON v_akpub_virus_activity TO kuma; GRANT SELECT ON v_akpub_hst_prdstate TO kuma; GRANT SELECT ON v_akpub_host_status TO kuma; Настройка удаленного доступа к БД PostgreSQL и метода аутентификации Откройте файл /etc/postgresql/<версия БД PostgreSQL>/main/pg_hba.conf и в секции IPv4 local connections  добавьте следующую строку host <имя БД,например, KAV> kuma /32 scram-sha-256 Откройте файл конфигурации /etc/postgresql/<версия БД PostgreSQL>/main/postgresql.conf и в секции CONNECTIONS AND AUTHENTICATION укажите IP-адрес интерфейса сервера БД, на котором будут "прослушиваться" входящие соединения После внесения изменений и сохранения файла конфигурации выполните рестарт сервиса PostgreSQL systemctl restart postgresql При необходимости разрешите входящие соединения на порт БД PostgreSQL (по умолчанию, TCP/5432) в параметрах локального FW. Создание секрета KUMA 1. В веб-интерфейсе KUMA перейдите на вкладку  Ресурсы →   Секреты 2. Выберите секрет  [OOTB] KSC PostgreSQL connection  и нажмите Дублировать. 3. В появившемся окне задайте: Название секрета URL (формат URL можно взять из Описания к секрету). В поле URL укажите: Имя ранее созданной роли (в нашем примере это kuma ) и ее пароль ( требования к паролю ); IP-адрес или FQDN сервера БД; Наименование БД KSC (по умолчанию KAV. См. Проверка имени БД KSC ). Если в пароле используются спецсимволы необходимо перевести данные спецсимволы в URL формат в соответствии с таблицей ниже. Примеры postgres://kuma:p%40ssword123%21@server.demo.lab/KAV ! # $ % & ' ( ) * + %21 %23 %24 %25 %26 %27 %28 %29 %2A %2B , / : ; = ? @ [ ] \ %2C %2F %3A %3B %3D %3F %40 %5B %5D %5C Можно использовать следующий ресурс для преобразования https://www.urlencoder.org/ Пример:   По умолчанию коллектор KUMA при обращении к БД PostgreSQL будет пытаться построить TLS-туннель. Если на стороне сервера БД не настроено использование SSL/TLS (что НЕ рекомендуется!) в URL секрета необходимо добавить "?sslmode=disable" , чтобы строка приняла следующий вид:  postgres://user:password@server/database ?sslmode=disable 4. Нажмите Сохранить . Обратите внимание, после сохранения секрета поле URL будет пустым во избежание утечки чувствительной информации. Настройка коннектора 1. В веб-интерфейсе KUMA перейдите в раздел  Ресурсы → Коннекторы 2. В списке коннекторов справа найдите коннектор [OOTB] KSC PostgreSQL и нажмите Дублировать 3. В появившемся окне задайте: Название коннектора На вкладке  Основные параметры в выпадающих списках URL выберите секрет, созданный ранее для подключения к БД PostgreSQL KSC. 4. Нажмите Сохранить . Настройка коллектора 1. В веб-интерфейсе KUMA перейдите в раздел Ресурсы  и нажмите Подключить источник 2. В появившемся окне задайте Название коллектора и Тенант 3. На шаге Транспорт  выберите ранее созданный коннектор 4. На шаге Парсинг событий  выберите нормализатор [OOTB] KSC from SQL . 5. На шаге Маршрутизация  задайте следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. 6. На шаге Проверка параметров нажмите Сохранить и создать сервис . 7. Скопируйте появившуюся команду и выполните установку сервиса коллектора. Проверка поступления событий KSC в KUMA Для проверки, что экспорт событий из БД KSC успешно настроен, перейдите в Ресурсы -> Активные сервисы -> выберите ранее созданный коллектор  KSC PostgreSQL и нажмите Перейти к событиям . В открывшемся окне  События убедитесь, что присутствуют события KSC. KSC MariaDB Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Настройка MariaDB В MariaDB настройки на сервере базы данных можно выполнять несколькими способами: через консоль (SSH, терминал ОС) или с помощью графических интерфейсов, таких как phpMyAdmin или MySQL Workbench В данной статье сервер БД MariaDB работает под управлением ОС Ubuntu 22.04.5, а все настройки выполняются в консоли. Для удобства в базе данных MariaDB Kaspersky Security Center предусмотрен набор публичных представлений. Таким образом можно создавать запросы непосредственно к публичным представлениям и извлекать из них данные о событиях. "Коробочный" коннектор KUMA [OOTB] KSC MySQL содержит уже готовые запросы к публичным представлениям  v_akpub_ev_event  и  v_akpub_host . Для обеспечения корректной работы MariaDB с Kaspersky Security Center рекомендуется использовать версии MariaDB начиная с 10.5.17 или более новые. Проверка имени БД KSC Чтобы проверить имя базы данных KSC можно воспользоваться следующей статьей: Просмор имени базы данных Kaspersky Security Center Linux - (KSC Linux) - https://support.kaspersky.ru/ksc-linux/15.1/228689 Альтернативным вариантом является проверка имени БД в консоли сервера, на котором установлена БД KSC: Подключитесь к серверу базы данных mariadb -h localhost -u admin -p где, вместо admin задайте логин своего пользователя MariaDB Запустите интерактивный терминал MariaDB и выведите список баз данных сервера SHOW DATABASES; Создание роли БД и предоставление прав Подключитесь к серверу базы данных mariadb -h localhost -u admin -p Создайте роль пользователя для сбора событий, в данном примере - kuma_siem CREATE USER kuma_siem IDENTIFIED by 'password'; Предоставьте права роли KUMA к публичным представлениям: GRANT SELECT ON `KAV`.`v_akpub_hst_prdstate` TO `kuma_siem`@`%`; GRANT SELECT ON `KAV`.`v_akpub_ev_event` TO `kuma_siem`@`%`; GRANT SELECT ON `KAV`.`v_akpub_host_status` TO `kuma_siem`@`%`; GRANT SELECT ON `KAV`.`v_akpub_virus_activity` TO `kuma_siem`@`%`; GRANT SELECT ON `KAV`.`v_akpub_host` TO `kuma_siem`@`%` Права предоставляются в виде: GRANT SELECT ON `название базы данных`.`таблица` TO `имя пользователя БД`@`хост с которого идет подключение`; # % - все хосты Проверьте права пользователя SHOW GRANTS FOR 'kuma_siem'@'%'; При необходимости разрешите входящие соединения на порт БД MariaDB (по умолчанию, TCP/3306) в параметрах локального FW, а также в настройках конфигурационного файла my.cnf Создание секрета KUMA 1. В веб-интерфейсе KUMA перейдите на вкладку Ресурсы →   Секреты → Добавить 2. Создайте секрет MariaDB, В появившемсе окне задайте URL (формат URL можно взять из  Описания  к секрету). В поле URL укажите: Имя ранее созданной роли (в нашем примере это  kuma_siem ) и ее пароль; Протокол подключения IP-адрес или FQDN сервера БД ; Порт подключения (по умолчанию 3306 ) Наименование БД KSC (по умолчанию KAV . См.  Проверка имени БД KSC ). mysql://<имя пользователя БД>:<Пароль>@<протокол подключения>(:<порт>)/<имя Базы данных> Например: mysql://kuma_siem:password@tcp(10.10.10.10:3306)/KAV Если в пароле используются спецсимволы необходимо перевести данные спецсимволы в URL формат в соответствии с таблицей ниже. Примеры mysql://kuma:p%40ssword123%2@tcp(ip:port)/KAV ! # $ % & ' ( ) * + %21 %23 %24 %25 %26 %27 %28 %29 %2A %2B , / : ; = ? @ [ ] \ %2C %2F %3A %3B %3D %3F %40 %5B %5D %5C Можно использовать следующий ресурс для преобразования  https://www.urlencoder.org/ 3. Нажмите Сохранить Обратите внимание, после сохранения секрета поле URL будет пустым во избежание утечки чувствительной информации. Настройка коннектора 1. В веб-интерфейсе KUMA перейдите в раздел  Ресурсы  →  Коннекторы 2. В списке коннекторов найдите коннектор [OOTB] KSC MySQL , отметьте его галочкой и нажмите  Дублировать 3. В появившемся окне задайте:    Название коннектора На вкладке Основные параметры в разделе Соединение в выпадающих списках URL выберите секрет, созданный ранее для подключения к БД MariaDB KSC Обратите внимание, что в коннекторе используется несколько запросов! URL подключения необходимо заменить для ВСЕХ запросов. 4. В запросе смените название БД ( ksc_srv ) на имя БД KSC, в нашем случае KAV (по умолчанию) Обратите внимание, что в коннекторе используется несколько запросов! Название БД необходимо заменить для  ВСЕХ запросов. Настройка коллектора 1. В веб-интерфейсе KUMA перейдите в раздел  Ресурсы  и нажмите  Подключить источник 2. В появившемся окне задайте  Название коллектора  и  Тенант 3. На шаге  Транспорт  выберите ранее созданный коннектор 4. На шаге  Парсинг событий  выберите сдублированный нормализатор  [OOTB] KSC from SQL . 5. На шаге  Маршрутизация  задайте следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. 6. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 7. Скопируйте появившуюся команду и выполните установку сервиса коллектора. Проверка поступления событий  KSC в KUMA  Для проверки, что экспорт событий из БД KSC успешно настроен, перейдите в  Ресурсы -> Активные сервисы ->  выберите ранее созданный коллектор  KSC PostgreSQL  и нажмите  Перейти к событиям В открывшемся окне События убедитесь, что присутствуют события KSC. Полезные ссылки  Настройка сервера MariaDB x64 для работы с Kaspersky Security Center Linux - https://support.kaspersky.ru/ksc-linux/15/210277 Коннекторы типа sql в kuma - https://support.kaspersky.ru/kuma/3.2/220746 KLMS Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/254786.htm Настройка передачи событий KLMS в KUMA Чтобы настроить передачу событий KLMS в KUMA: 1. Подключитесь к серверу KLMS по проколу SSH под учетной записью с правами администратора перейдите в меню Technical Support Mode. 2. С помощью утилиты  klms-control выгрузите настройки в файл settings.xml : sudo /opt/kaspersky/klms/bin/klms-control --get-settings EventLogger -n -f /tmp/settings.xml 3. Убедитесь, что параметры файла /tmp/settings.xml имеют следующие значения, при необходимости внесите изменения: 1 Local1 4. Примените настройки с помощью следующей команды: sudo /opt/kaspersky/klms/bin/klms-control --set-settings EventLogger -n -f /tmp/settings.xml 5. Для отправки событий по протоколу UDP внесите следующие изменения в конфигурационный файл /etc/rsyslog.conf . $WorkDirectory /var/lib/rsyslog $ActionQueueFileName ForwardToSIEM $ActionQueueMaxDiskSpace 1g $ActionQueueSaveOnShutdown on $ActionQueueType LinkedList $ActionResumeRetryCount -1 local1.* @:<порт коллектора> Если вы хотите отправлять события по протоколу TCP, последняя строчка должна выглядеть следующим образом: local1.* @@:<порт коллектора> 6. Сохраните внесённые изменения. 7. Перезапустите сервис rsyslog с помощью следующей команды: sudo systemctl restart rsyslog.service Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий KLMS. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне KLMS. 2. На шаге Парсинг событий выберите нормализатор [OOTB] KLMS syslog CEF . 3. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 4. На шаге Проверка параметров нажмите Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Настройка получения событий KLMS (онлайн-справка KUMA): https://support.kaspersky.com/help/KUMA/2.1/ru-RU/254786.htm   KSMG 1.1 Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/254785.htm Настройка передачи событий KSMG в KUMA Данная инструкция применима для KSMG версии 1.1 Чтобы настроить передачу событий KSMG в KUMA: 1. Подключитесь к серверу KSMG по проколу SSH под учетной записью с правами администратора перейдите в меню Technical Support Mode. 2. С помощью утилиты  ksmg-control выгрузите настройки в файл settings.xml : sudo /opt/kaspersky/ksmg/bin/ksmg-control --get-settings EventLogger -n -f /tmp/settings.xml 3. Убедитесь, что параметры файла /tmp/settings.xml имеют следующие значения, при необходимости внесите изменения: 1 Local1 4. Примените настройки с помощью следующей команды: sudo /opt/kaspersky/ksmg/bin/ksmg-control --set-settings EventLogger -n -f /tmp/settings.xml 5. Для отправки событий по протоколу UDP внесите следующие изменения в конфигурационный файл /etc/rsyslog.conf . $WorkDirectory /var/lib/rsyslog $ActionQueueFileName ForwardToSIEM $ActionQueueMaxDiskSpace 1g $ActionQueueSaveOnShutdown on $ActionQueueType LinkedList $ActionResumeRetryCount -1 local1.* @:<порт коллектора> Если вы хотите отправлять события по протоколу TCP, последняя строчка должна выглядеть следующим образом: local1.* @@:<порт коллектора> 6. Сохраните внесённые изменения. 7. Перезапустите сервис rsyslog с помощью следующей команды: sudo systemctl restart rsyslog.service Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий KSMG. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне KSMG. 2. На шаге Парсинг событий выберите нормализатор [OOTB] KSMG . 3. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 4. На шаге Проверка параметров нажмите Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Настройка получения событий KSMG (онлайн-справка KUMA): https://support.kaspersky.com/help/KUMA/2.1/ru-RU/254785.htm Публикация событий в SIEM-систему (онлайн-справка KSMG): https://support.kaspersky.com/help/KSMG/1.1.3/ru-RU/151504.htm   KSMG 2.0 Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Настройка передачи событий KSMG в KUMA Настройка отправкм логов для актуальной версии KSMG 2.1.1VA доступно из справки - https://support.kaspersky.com/KSMG/2.1.1VA/ru-RU/218660.htm   Данная инструкция применима для KSMG версии от 2.1.1VA и KUMA 4.0: В меню KSMG необходимо перейти в "Параметры" -> Журналирование на внешнем сервере -> Поставить флажок в "Использовать журналирование на внешнем сервере" и далее настроить соответсвющие параметры для коннекта с KUMA, нажать сохранить. Возможные категории: событий Журнал аудита безопасности системы  (authpriv). Журнал событий системных служб  (daemon). Журнал запуска задач по расписанию  (cron). Журнал встроенного MTA  (mail). Журнал Kaspersky Secure Mail Gateway  (local1). Журнал Kaspersky Secure Mail Gateway в формате CEF  (local2). По умолчанию категория не выбрана. Далее проверка событий через коллектор, который настроен на сбор событий с KSMG: Передача событий KSMG < 2.1.1VA в KUMA 3.4 1. Подключитесь к серверу KSMG по проколу SSH под учетной записью с правами администратора перейдите в меню Technical Support Mode. 2. Внесите следующие изменения в файл с параметрами экспорта событий /opt/kaspersky/ksmg/share/templates/core_settings/event_logger.json.template : "siemSettings": { "enabled": true, "facility": "Local2", "logLevel": "Info", "formatting": } Прочие параметры оставьте без изменений. Перед внесением изменений в файл /etc/rsyslog.conf рекомендуется сделать его резервную копию. Ошибка при редактировании файла может привести к некорректной работе системы. 3. В файле  /etc/rsyslog.conf измените строку: *.info;mail.none;authpriv.none;cron.none;local0.none;local1.none /var/log/messages на *.info;mail.none;authpriv.none;cron.none;local0.none;local1.none;local2.none /var/log/messages 4. Добавьте в файл /etc/rsyslog.conf следующую строку: local2.* -/var/log/ksmg-cef-messages 5. Создайте файл /var/log/ksmg-cef-messages и настройте права доступа к нему. Для этого выполните команды: touch /var/log/ksmg-cef-messages chown root:klusers /var/log/ksmg-cef-messages chmod 640 /var/log/ksmg-cef-messages 6. Настройте правила ротации файлов с экспортированными событиями. Для этого добавьте в файл /etc/logrotate.d/ksmg-syslog следующие строки: /var/log/ksmg-cef-messages { size 500M rotate 10 notifempty sharedscripts postrotate /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true endscript } 7. Перезапустите сервис rsyslog с помощью следующей команды: service rsyslog restart Если вам не требуется сохранять файлы локально, пропустите шаги 4–7 из инструкции выше 8. В веб-интерфейсе приложения в разделе Параметры  →  Журналы и события   →  События   внесите изменение в значение любого параметра и нажмите на кнопку  Сохранить . Это необходимо для синхронизации параметров между узлами кластера и применения изменений, внесенных в конфигурационный файл. После этого вы можете вернуть исходное значение измененного параметра. 9. Внесите следующие изменения в файл /etc/rsyslog.conf : $ActionQueueFileName ForwardToSIEM $ActionQueueMaxDiskSpace 1g $ActionQueueSaveOnShutdown on $ActionQueueType LinkedList $ActionResumeRetryCount -1 local2.* @:<порт коллектора> Если вы хотите отправлять события по протоколу TCP, последняя строчка должна выглядеть следующим образом: local2.* @@:<порт коллектора> 10. Перезапустите службу rsyslog. Для этого выполните команду: service rsyslog restart Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий KSMG. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне KSMG. 2. На шаге Парсинг событий выберите нормализатор [OOTB] KSMG . 3. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 4. На шаге Проверка параметров нажмите Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. В случае если события не поступают перезапустите сервис rsyslog несколько раз Полезные ссылки Публикация событий в SIEM-систему (онлайн-справка KSMG): https://support.kaspersky.com/KSMG/2.0.1/ru-RU/151504.htm  KWTS 6.0 Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/254373.htm Настройка передачи событий KWTS в KUMA Данная инструкция применима для KWTS версии 6.0 Чтобы настроить передачу событий KWTS в KUMA: 1. Подключитесь к серверу KWTS по проколу SSH под учетной записью с правами администратора перейдите в меню Technical Support Mode. Перед внесением изменений создайте резервные копии следующих файлов: - /opt/kaspersky/kwts/share/templates/core_settings/event_logger.json.template - /etc/rsyslog.conf 2. Внесите следующие изменения в файл с параметрами экспорта событий /opt/kaspersky/kwts/share/templates/core_settings/event_logger.json.template : "siemSettings": { "enabled": true, "facility": "Local5", "logLevel": "Info", "formatting": { Прочие параметры оставьте без изменений. 3. Внести изменения в файл /etc/rsyslog.conf : $WorkDirectory /var/lib/rsyslog $ActionQueueFileName ForwardToSIEM $ActionQueueMaxDiskSpace 1g $ActionQueueSaveOnShutdown on $ActionQueueType LinkedList $ActionResumeRetryCount -1 local5.* @:<порт коллектора> Если вы хотите отправлять события по протоколу TCP, последняя строчка должна выглядеть следующим образом: local5.* @@:<порт коллектора> 4. Перезапустите сервис rsyslog с помощью следующей команды: sudo systemctl restart rsyslog.service 5. В веб-интерфейсе приложения в разделе Параметры  → Syslog   включите опцию Записывать информацию о профиле трафика и нажмите на кнопку Сохранить . Дополнительный вариант логирования Так как в CEF могут логироваться не все события, в некоторых случаях целесообразно будет также оправлять в KUMA лог из /var/log/kwts-messages . В этом логе, например, содержится GUID, который позволяет связать события в КАТА и KWTS при отправке файлов на проверку в KATA. Для отправки на KUMA этих событий необходимо в файле /etc/rsyslog.conf добавить отправку событий с facility local1 в KUMA. Однако коллектор для этих целей потребуется другой, т.к. логи в данном случае будут не в формате CEF, а в kv. Также это потребует и разработки кастомного парсера. Чтобы настроить отправку local1 в KUMA нужно в конец файла дописать следующее для отправки по UDP: local1.* @:<порт коллектора> Если вы хотите отправлять события по протоколу TCP, последняя строчка должна выглядеть следующим образом: local1.* @@:<порт коллектора> После перезапустите сервис rsyslog с помощью следующей команды: sudo systemctl restart rsyslog.service Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий KWTS. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне KWTS. 2. На шаге Парсинг событий выберите нормализатор [OOTB] KWTS syslog CEF . 3. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 4. На шаге Проверка параметров нажмите Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Настройка получения событий KWTS (онлайн-справка KUMA):  https://support.kaspersky.com/help/KUMA/2.1/ru-RU/254373.htm   KATA Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/240690.htm   Настройка KATA Для настройки пересылки событий из KATA в SIEM KUMA необходимо выполнить следующие действия: 1. Перейти в веб-консоль центрального узла Kaspersky Anti Targeted Attack из-под учетной записи Администратора, предварительно отметив параметр Local administrator 2. Перейти в раздел  Settings – SIEM System и настроить параметры отправки событий в KUMA SIEM: Host/IP : ip или fqdn адрес коллектора KUMA Port : порт коллектора KUMA Protocol : TCP или UDP Host ID : напр., kata-cn Heartbeat : интервал в минутах Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий Kaspersky Anti Targeted Attack Platform. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне KATA. 2. На шаге Парсинг событий выберите нормализатор [OOTB] KATA. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Настройка получения событий KATA/EDR (онлайн-справка KUMA): https://support.kaspersky.com/help/KUMA/3.2/ru-RU/240690.htm   KATA/NDR 7.0 Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Данная инструкция предназначена строго для версии KATA/NDR 7.0 . Инструкция для предыдущих версии находится в соответствующем разделе базы знаний. Данная способ позволяет собирать события NDR . Для сбора событий KATA воспользуйтесь соответствующей инструкцией. Настройка KATA/NDR Для настройки пересылки событий из KATA/NDR в SIEM KUMA необходимо выполнить следующие действия: 1. Перейти в веб-консоль KATA/NDR из-под учетной записи Администратора 2. Перейти в раздел  Параметры – Коннекторы  и нажать на кнопку Добавить коннектор 3. В открывшемся окне настроить параметры отправки событий в KUMA SIEM: Тип коннектора : SIEM; Имя коннектора : произвольное название, например, KUMA Syslog; Адрес сервера : 127.0.0.1; Узел размещения коннектора : выбрать нужный из выпадающего списка; Пользователь программы : выбрать нужного из выпадающего списка; Адрес SIEM сервера : IP-адрес сервера коллектора KUMA; Номер порта : порт коллектора KUMA; Транспортный протокол : TCP или UDP. Разрешить отправку записей аудита : вкл, если требуется передача событий аудита Разрешить отправку сообщений программы : вкл, если требуется передача сообщений программы 3. По завершении заполнения необходимых полей нажать кнопку  Сохранить . В результате в интерфейсе KATA/NDR созданный коннектор перейдет в состояние Работает . Настройка отправки событий По умолчанию события безопасности KATA/NDR не передаются ни в какие смежные системы, о чем свидетельствует колонка Тип события - Не отправляются . Поэтому, чтобы события безопасности передавать в другие системы необходимо определить перечень таких событий для каждой системы, для который мы настроили коннектор. Для настройки отправки событий необходимо: 1.    Войти в интерфейс KATA/NDR от имени пользователя Старший офицер безопасности 2.    Перейти на вкладку Параметры – Типы событий 3.    Выбрать один или несколько типов событий, которые необходимо передавать 4.    Нажать на кнопку Выбрать коннекторы 5.    Установить флаг напротив тех систем, в которые необходимо предавать выбранные события 6.    Подтвердить выбор нажатием кнопки ОК После завершения настроек добавленные события будут отмечены флагом в колонке соответствующего коннектора Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий KATA/NDR. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне KATA/NDR. Также обязательно задайте в качестве разделителя \0 . 2. На шаге Парсинг событий выберите соответствующий нормализатор Какой нормализатор можно использовать Сделайте копию коробочного нормализатора [OOTB] KICS4Net v3.х В копии нормализатора, в главном парсере, на вкладке Обогащение измените значение константы для поля DeviceProduct на NDR  Сохраните нормализатор и используйте его в коллекторе KATA/NDR 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. KEDR 4.0-4.1 Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/234627.htm   Настройка KEDR Чтобы импортировать в KUMA события Kaspersky Endpoint Detection and Response 4.1, выполните следующие действия на стороне Kaspersky Endpoint Detection and Response: 1. Войдите в консоль управления того сервера Central Node, с которого вы хотите экспортировать события, по протоколу SSH или через терминал. 2. В ответ на приглашение системы введите имя учетной записи администратора и пароль, заданный при установке Kaspersky Endpoint Detection and Response. Отобразится меню администратора компонента программы. 3. В меню администратора компонента программы выберите режим Technical Support Mode. 4. Нажмите на клавишу Enter. Отобразится окно подтверждения входа в режим Technical Support Mode. 5. Подтвердите, что хотите выполнять действия с программой в режиме Technical Support Mode. Для этого выберите Yes и нажмите на клавишу Enter. 6. Выполните команду  sudo -i 7. В конфигурационном файле /etc/sysconfig/apt-services в поле KAFKA_PORTS удалите значение 10000 . Если к серверу Central Node подключены серверы Secondary Central Node или компонент Sensor, установленный на отдельном сервере, вам требуется разрешить соединение с сервером, на котором вы изменили конфигурационный файл, по порту  10000 . Настоятельно не рекомендуется использовать этот порт для каких-либо внешних подключений, кроме KUMA. Чтобы ограничить подключение по порту 10000 только для KUMA, выполните команду: iptables -I INPUT -p tcp ! -s KUMA_IP_address --dport 10000 -j DROP 8. Выполните команду  systemctl restart apt_ipsec.service 9. В конфигурационном файле  /usr/bin/apt-start-sedr-iptables в поле WEB_PORTS добавьте значение 10000 через запятую без пробела. 10. Выполните команду  sudo sh /usr/bin/apt-start-sedr-iptables Настройка KUMA 1. На сервере KUMA добавьте IP-адрес сервера Central Node в формате  centralnode в один из следующих файлов: %WINDIR%\System32\drivers\etc\hosts – в случае сбора телеметрии KEDR агентом KUMA для Windows. Как отредактировать файл hosts в Windows 1. Запустите cmd.exe от имени администратора 2. Выполните команду  notepad.exe %WINDIR%\System32\drivers\etc\hosts 3. Внести изменения в файл и сохраните ( Ctrl + S ) /etc/hosts file – в случае сбора телеметрии KEDR коллектором или агентом KUMA для Linux. 2. В веб-интерфейсе KUMA создайте коннектор типа Kafka. При создании коннектора укажите следующие параметры: - В поле URL укажите :10000 - В поле Topic укажите EndpointEnrichedEventsTopic . - В поле Consumer group укажите любое уникальное имя. 3. В веб-интерфейсе KUMA создайте коллектор. 4. На шаге Транспорт укажите коннектор, созданный на шаге 2. 5. На шаге Парсинг событий выберите нормализатор [OOTB] KEDR telemetry . 6. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 7. На шаге Проверка параметров нажмите Сохранить и создать сервис . 8. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Настройка получения событий KATA/EDR (онлайн-справка KUMA): https://support.kaspersky.com/help/KUMA/2.1/ru-RU/234627.htm   KEDR 5.0-6.0 Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/234627.htm   Настройка KEDR При импорте событий из Kaspersky Endpoint Detection and Response 5.0 действует ряд ограничений: - Импорт событий доступен только для неотказоустойчивой версии Kaspersky Endpoint Detection and Response. - Импорт событий доступен, если в программе Kaspersky Endpoint Detection and Response используются лицензионные ключи KATA и KEDR. - Импорт событий не доступен, если в составе программы Kaspersky Endpoint Detection and Response используется компонент Sensor, установленный на отдельном сервере. Чтобы импортировать в KUMA события Kaspersky Endpoint Detection and Response 5.0, выполните следующие действия на стороне Kaspersky Endpoint Detection and Response: 1. Войдите в консоль управления того сервера Central Node, с которого вы хотите экспортировать события, по протоколу SSH или через терминал. 2. В ответ на приглашение системы введите имя учетной записи администратора и пароль, заданный при установке Kaspersky Endpoint Detection and Response. Отобразится меню администратора компонента программы. 3. В меню администратора компонента программы выберите режим Technical Support Mode. 4. Нажмите на клавишу Enter. Отобразится окно подтверждения входа в режим Technical Support Mode. 5. Подтвердите, что хотите выполнять действия с программой в режиме Technical Support Mode. Для этого выберите Yes и нажмите на клавишу Enter. 6. Выполните команду  sudo -i 7. В конфигурационном файле /usr/local/lib/python3.8/dist-packages/firewall/create_iptables_rules.py укажите дополнительный порт 10000 для константы WEB_PORTS : WEB_PORTS = f'10000,80,{AppPort.APT_AGENT_PORT},{AppPort.APT_GUI_PORT}' Для KATA 6.0 файл находится по пути /opt/venv/lib/python3.11/site-packages/firewall/create_iptables_rules.py  и строку надо отредактировать в таком виде: WEB_PORTS = '10000,80,' + ','.join( 8. Выполните команды: Кластерная подсеть по умолчанию: 198.18.0.0/16 kata-firewall stop kata-firewall start --cluster-subnet <маска сети для адресации серверов кластера> Настройка KUMA 1. На сервере KUMA добавьте IP-адрес сервера Central Node в формате kafka.services.external.dyn.kata в один из следующих файлов: %WINDIR%\System32\drivers\etc\hosts – в случае сбора телеметрии KEDR агентом KUMA для Windows. Как отредактировать файл hosts в Windows 1. Запустите cmd.exe от имени администратора 2. Выполните команду  notepad.exe %WINDIR%\System32\drivers\etc\hosts 3. Внести изменения в файл и сохраните ( Ctrl + S ) /etc/hosts file – в случае сбора телеметрии KEDR коллектором или агентом KUMA для Linux. 2. В веб-интерфейсе KUMA создайте коннектор типа Kafka. При создании коннектора укажите следующие параметры: - В поле URL укажите :10000 - В поле Topic укажите EndpointEnrichedEventsTopic . - В поле Consumer group укажите любое уникальное имя. 3. В веб-интерфейсе KUMA создайте коллектор. 4. На шаге Транспорт укажите коннектор, созданный на шаге 2. 5. На шаге Парсинг событий выберите нормализатор [OOTB] KEDR telemetry . 6. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 7. На шаге Проверка параметров нажмите Сохранить и создать сервис . 8. Скопируйте появившуюся команду для установки коллектора KUMA. Случай с несколькими серверами KEDR При наличии двух серверов EDR брокер на обоих узлах в метаданных передает одно и то же имя centralnode. Таким образом, выгрузка телеметрии через Кафку одновременно с двух разных узлов EDR становится невозможной, так как они просят клиента обращаться по одному и тому же некорректному адресу http://centralnode:10000 . Для решения проблемы: 1. на одной CN выгрузим параметры, с которым контейнер стартует: console-settings-updater get /kata/configuration/product/kafka | python3 -m json.tool > /tmp/kafka.conf 2. Откроем в редакторе файл:  vim kafka.conf и исправляем строку "external_address": "kafka.services.external.dyn.kata" на  "external_address": "kafka 2 .services.external.dyn.kata" 3. Загружаем файл обратно в контейнер: console-settings-updater set /kata/configuration/product/kafka @/tmp/kafka.conf KEDR 5.1+ (Телеметрия EDR по API) ✔️ Рекомендуется - Рекомендуемый способ сбора для этого источника событий Данная инструкция предназначена для версии KUMA с 3.0.2+, а также версий KATA 5.1+ Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/261000.htm Создание секрета Для подключения KEDR со стороны KUMA по API необходимо создать секрет для аутентификации. Для этого выполните следующие действия: 1. В веб-интерфейсе KUMA перейдите на вкладку Ресурсы → Секреты и нажмите на кнопку Добавить . 2. Укажите Имя секрета, выберите Тенант , к которому будет относиться создаваемый секрет. 3. Нажмите Сгенерировать и скачать сертификат и закрытый ключ шифрования соединения , после чего произойдет скачивание архива. 4. Распакуйте архив. Внутри будут файл сертификата и файл закрытого ключа. 5. Укажите Файл сертификата и Закрытый ключ в соответствии с рисунком: 6. Сохраните секрет Настройка коллектора После того как был создан секрет, требуется создать коллектор в веб-интерфейсе KUMA для событий KEDR. 1. На шаге Транспорт укажите тип kata/kedr и URL  в формате :<порт, по умолчанию 443>), в поле Секрет укажите ранее созданный секрет. 2. На шаге Парсинг событий выберите нормализатор  [OOTB] KEDR telemetry . 3. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 4. На шаге Проверка параметров  нажмите Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. В Дополнительных параметрах транспорта параметр Время ожидания получения событий означает время, за которое KATA собирает события для отправки. Настройка KATA Для настройки сбора событий телеметрии из KATA в SIEM KUMA необходимо выполнить следующие действия: 1. Перейти в веб-консоль центрального узла Kaspersky Anti Targeted Attack из-под учетной записи Администратора, предварительно отметив параметр  Local administrator 2. Перейти в раздел External systems и нажать Accept (для дальнейшего удобства вы можете изменить содержимое поля Name, например, на KUMA). Также следует проверить, что значение в поле ID совпадает со значением поля Внешний ID в настройках транспорта коллектора KUMA. Полезные ссылки Подробные сведения о получении событий от Kaspersky Endpoint Detection and Response: https://support.kaspersky.com/KATA/5.1/ru-RU/248949.htm Импорт событий Kaspersky Endpoint Detection and Response с помощью коннектора kata/edr: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/261000.htm KICS 3.1 и ниже Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Данная инструкция предназначена строго для версии KICS for Networks 3.1 или ниже . Инструкция для версии 4.0 и выше находится в соответствующем разделе базы знаний. Настройка KICS for Networks Для настройки пересылки событий из KICS4Net в SIEM KUMA необходимо выполнить следующие действия: 1. Перейти в веб-консоль KICS for Networks из-под учетной записи Администратора 2. Перейти в раздел  Параметры – Коннекторы и настроить параметры отправки событий в KUMA SIEM: Тип коннектора : SIEM; Имя коннектора : произвольное название, например, KUMA; Адрес сервера : IP-адрес MGMT интерфейса сервера KICS for Networks; Адрес узла коннектора : IP-адрес узла, на котором Вы устанавливаете коннектор (Если используется коннектор, располагаемый на сервере KICS for Networks, то указывается IP адрес MGMT интерфейса сервера. Если пакет с коннектором будет установлен на другом узле, то необходимо указать IP адрес этого узла); Пароль для доступа к сертификату коннектора : пароль для архива с сертификатом сервера KICS for Networks, который будет сформирован после применения настроек коннектора; Адрес SIEM сервера : IP-адрес сервера коллектора KUMA; Номер порта : порт коллектора KUMA; Транспортный протокол : TCP или UDP. 3. По завершении заполнения необходимых полей нажать кнопку  Сохранить . После сохранения настроек в списке коннекторов появится созданный коннектор. Для KICS for Networks 3.1 и ниже автоматически загрузится файл свертки с сертификатом сервера KICS for Networks, который необходимо перенести на узел, где установлен коннектор. Вновь созданный коннектор перейдет в режим Ожидание регистрации до того момента, как вы создадите службу на узле, где установлен коннектор. 4. Для создании службы необходимо на узле, где установлен коннектор, перейти в раздел /opt/kaspersky/kics4net-connectors/sbin cd /opt/kaspersky/kics4net-connectors/sbin и запустить скрипт registrar.py python3 registrar.py create Далее потребуется указать имя коннектора, имя архива с файлом свертки и пароль к архиву файла свертки, подтвердить запуск службы после ее создания. В результате в интерфейсе KICS for Networks созданный коннектор перейдет в состояние Зарегистрирован . Настройка отправки событий По умолчанию события безопасности KICS for Networks не передаются ни в какие смежные системы, о чем свидетельствует колонка Тип события - Не отправляются . Поэтому, чтобы события безопасности передавать в другие системы необходимо определить перечень таких событий для каждой системы, для который мы настроили коннектор. Для настройки отправки событий необходимо: 1.    Перейти на вкладку Параметры – Типы событий 2.    Выбрать один или несколько типов событий, которые необходимо передавать 3.    Нажать на кнопку Выбрать коннекторы 4.    Установить флаг напротив тех систем, в которые необходимо предавать выбранные события 5.    Подтвердить выбор нажатием кнопки ОК После завершения настроек добавленные события будут отмечены флагом в колонке соответствующего коннектора Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий KICS for Networks. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне KICS for Networks. 2. На шаге Парсинг событий выберите нормализатор [OOTB] KICS4Net v3.х . 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Настройка создания коннектора KICS for Networks (онлайн-справка KICS for Networks): https://support.kaspersky.com/help/KICSforNetworks/3.1/ru-RU/136497.htm   KICS 4.0 и выше Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Данная инструкция предназначена строго для версии KICS for Networks 4.0 или ниже . Инструкция для версии 3.1 и ниже находится в соответствующем разделе базы знаний. Настройка KICS for Networks Для настройки пересылки событий из KICS for Networks в SIEM KUMA необходимо выполнить следующие действия: 1. Перейти в веб-консоль KICS for Networks из-под учетной записи Администратора 2. Перейти в раздел  Параметры – Коннекторы и настроить параметры отправки событий в KUMA SIEM: Тип коннектора : SIEM; Имя коннектора : произвольное название, например, KUMA; Адрес сервера : IP-адрес MGMT интерфейса сервера KICS for Networks; Адрес узла коннектора : IP-адрес узла, на котором Вы устанавливаете коннектор (Если используется коннектор, располагаемый на сервере KICS for Networks, то указывается IP адрес MGMT интерфейса сервера. Если пакет с коннектором будет установлен на другом узле, то необходимо указать IP адрес этого узла); Пароль для доступа к сертификату коннектора : пароль для архива с сертификатом сервера KICS for Networks, который будет сформирован после применения настроек коннектора; Адрес SIEM сервера : IP-адрес сервера коллектора KUMA; Номер порта : порт коллектора KUMA; Транспортный протокол : TCP или UDP. 3. По завершении заполнения необходимых полей нажать кнопку  Сохранить . Начиная с версии 4.0 коннектор автоматически осуществит регистрацию в продукте.  В результате в интерфейсе KICS for Networks созданный коннектор перейдет в состояние  Зарегистрирован . Настройка отправки событий По умолчанию события безопасности KICS for Networks не передаются ни в какие смежные системы, о чем свидетельствует колонка Тип события - Не отправляются . Поэтому, чтобы события безопасности передавать в другие системы необходимо определить перечень таких событий для каждой системы, для который мы настроили коннектор. Для настройки отправки событий необходимо: 1.    Перейти на вкладку Параметры – Типы событий 2.    Выбрать один или несколько типов событий, которые необходимо передавать 3.    Нажать на кнопку Выбрать коннекторы 4.    Установить флаг напротив тех систем, в которые необходимо предавать выбранные события 5.    Подтвердить выбор нажатием кнопки ОК После завершения настроек добавленные события будут отмечены флагом в колонке соответствующего коннектора Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий KICS for Networks. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне KICS for Networks. 2. На шаге Парсинг событий выберите соответствующий нормализатор. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Настройка создания коннектора KICS for Networks (онлайн-справка KICS for Networks): https://support.kaspersky.com/help/KICSforNetworks/4.0/ru-RU/136497.htm   Создание коллектора KUMA Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Создание коллектора KUMA Для создания коллектора в веб-интерфейсе KUMA: Перейдите в раздел Ресурсы и нажмите на кнопку Подключить источник . В появившемся окне мастера настройки Создание коллектора на первом шаге  Подключение источников укажите Имя коллектора и выберите Тенант , к которому будет принадлежать создаваемый коллектор. Опционально заполните Описание . На втором шаге мастера  Транспорт  укажите параметры коннектора для взаимодействия с подключаемым источником: В раскрывающемся списке Тип выберите тип коннектора. Например, TCP или UDP. URL для подключения – DNS-имя/IP-адрес сервера коллектора KUMA :Порт , на котором коллектор будет ожидать входящие подключения. Можно выбрать любой свободный порт выше 1024. В поле URL можно указать только порт при инсталляции All-in-one. Для настройки защищенной передачи событий между источником и коллектором KUMA на вкладке Дополнительные параметры выберите один из режимов TLS. На стороне источника также необходимо настроить параметры TLS. На третьем шаге мастера Парсинг событий выберите нормализатор.  Шаги мастера настройки с четвертого по шестой ( Фильтрация событий, Агрегация событий и Обогащение событий ) являются опциональными, их можно пропустить и вернуться к настройке позднее. На седьмом шаге мастера Маршрутизация задайте точки назначения. Для хранения событий добавьте точку назначения типа  Хранилище . В случае если предполагается также анализ потока событий правилами корреляции добавьте точку назначения типа Коррелятор . На завершающем шаге мастера нажмите на кнопку Создать и сохранить сервис . После чего появится строка установки сервиса, которую необходимо скопировать для дальнейшей установки. Нажмите Сохранить . После выполнения вышеуказанных действий в разделе Ресурсы → Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Чтобы установить коллектор KUMA: Выполните подключение к CLI сервера, на котором планируется развертывание коллектора KUMA. Для установки сервиса коллектора в командной строке выполните команду под учетной записью root, скопированную на прошлом шаге. При необходимости добавьте используемый порт сервиса коллектора в исключения МЭ ОС и обновите параметры службы. Пример для firewalld firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp|udp –permanent firewall-cmd –reload Пример для ufw ufw allow <порт, выбранный для коллектора>/tcp|udp ufw reload После успешной установки сервиса его статус в веб-консоли KUMA изменится на ВКЛ с зеленой индикацией. Справочные материалы Статья онлайн-справки Создание коллектора . 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 .  После создания папки необходимо разрешить общий доступ на чтение к этой папке. Рекомендуется создать отдельного пользователя для этой операции. Далее необходимо запустить оснастку 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 WEC ✔️ Рекомендуется  -   Рекомендуемый способ сбора для этого источника событий Настройка сбора событий с устройств Windows при помощи Агента KUMA (WEC). Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.ru/kuma/4.0/248413 Описание схемы работы Сбор событий Windows с использованием Windows Event Collector (WEC) позволяет централизованно собирать события с множества устройств Windows в сети. В основе данного способа лежит технология Windows Event Forwarding (WEF), которая обеспечивает передачу событий с источников (рабочие станции и серверы) на центральный сервер-коллектор (WEC). Этот подход упрощает мониторинг и управление событиями в масштабах всей сети, обеспечивая единую точку сбора данных. Компоненты схемы: Источники событий: рабочие станции и серверы Windows. Windows Event Collector или WEC-сервер - сервер, с запущенной службой «Сборщик событий Windows».  Данный сервер на основании создаваемых подписок на события получает события от источников и обеспечивает их локальное хранение. Взаимодействие между WEC-сервером и источниками событий осуществляется с использованием протокола удаленного управления Windows (WS-Management protocol). Для настройки доступно два типа подписок: Source-initiated subscriptions (Push) — события отправляются источником. Источники настраиваются на отправку событий на WEC-сервер с помощью GPO. Collector-initiated subscriptions (Pull) — события собираются WEC-сервером самостоятельно. WEC-сервер подключается к рабочим станциям/серверам и забирает события из локальных журналов. Агент KUMA - компонент KUMA, устанавливаемый на WEC-сервер для отправки собранных событий с источников в коллектор KUMA. Коллектор KUMA - компонент KUMA, обеспечивающий прием/нормализацию/агрегацию/фильтрацию событий, полученных от агента KUMA, и их дальнейшую отправку в коррелятор и/или хранилище KUMA. В данном примере мы рассмотрим вариант Source-initiated subscriptions (режим Push ) ввиду того, что этот режим более предпочтителен из-за отсутствия необходимости настройки «прослушивания» входящих соединений службой WinRM на источниках событий. Подробнее о Windows Event Collector и технологии Windows Event Forwarding: https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection Рекомендации для сервера WEC Один WEC-сервер на 2000-4000 источников событий (хосты Windows) 4-8 CPU и 16 ГБ RAM для обработки событий с 2000-4000 источников, зависит от обширности профиля аудита (при рекомендуемых MS Common ID событий - до 1500 устройств) Для сбора событий с контроллеров домена также использовать схему с WEC-сервером. https://learn.microsoft.com/en-us/troubleshoot/windows-server/admin-development/configure-eventlog-forwarding-performance Настройка политики аудита По умолчанию на устройствах Windows аудит событий не осуществляется. Рекомендуется настраивать политику аудита Windows, исходя из перечня событий аудита, которые нужны для работы «коробочных» правил корреляции KUMA (например, вход в систему, запуск процессов и т.д.). При необходимости перечень журналируемых событий аудита в дальнейшем можно расширить. Перечень событий аудита Windows, используемых в "коробочных" правилах корреляции: https://support.kaspersky.ru/kuma/4.0/250594 Настройка политики аудита на отдельной рабочей станции/сервере Windows Event Log Powershell Чтобы настроить аудит событий, связанных с выполнением команд и скриптов в PowerShell на отдельной рабочей станции/сервере: Запустите оснастку Редактор локальной групповой политики : нажмите кнопку Win → введите gpedit.msc и запустите Редактор локальной групповой политики от имени администратора. Перейдите в Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Windows PowerShell .  Выберите Включить ведение журнала модулей . В появившемся окне Включить ведение журнала модулей : Укажите Включено . В секции Параметры нажмите Показать . В окне Вывод содержания в качестве значения укажите «*» и нажмите ОК . В окне Включить ведение журнала модулей нажмите ОК . Выберите Включить регистрацию блоков сценариев PowerShell . В появившемся окне Включить регистрацию блоков сценариев PowerShell укажите Включено и нажмите ОК . Убедитесь, что состояние параметров политики соответствует скриншоту ниже. Windows Event Log Security Чтобы настроить аудит событий, связанных с входами пользователей, аутентификацией, доступом к ресурсам, изменениями учетных записей и т.д. на отдельной рабочей станции/сервере: Запустите оснастку Редактор локальной групповой политики : нажмите кнопку Win → введите gpedit.msc и запустите Редактор локальной групповой политики от имени администратора. Перейдите в Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Конфигурация расширенной политики аудита → Политики аудита системы - Объект локальной групповой политики . Настройте параметры аудита согласно скриншотам ниже. При использовании Расширенной политики аудита необходимо включить параметр "Аудит: принудительное переопределение параметров категории политики аудита параметрами подкатегории политики аудита (Windows Visa или более поздние версии)  в целях переопределения параметров, указанных в  Политике аудита . Дополнительно необходимо включить журналирование команд, выполняемых в командной строке (cmd): Запустите оснастку Редактор локальной групповой политики : нажмите кнопку Win → введите gpedit.msc и запустите Редактор локальной групповой политики от имени администратора. Перейдите в Конфигурация компьютера → Административные шаблоны → Система → Аудит создания процессов . Активируйте параметр политики Включать командную строку в события создания процессов . В данном статье не рассматривается настройка аудита событий доступа к объектам (ветки реестра, папки и файлы и т.д.) и событий доступа к службе каталогов. Windows Event Log System Дополнительные настройки для журнала System не требуются. Windows Event Log Defender Дополнительные настройки для журнала Microsoft-Windows-Windows Defender/Operational не требуются. Настройка политики аудита для группы рабочих станций/серверов средствами GPO При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов настройки. Чтобы настроить политику аудита для группы рабочих станций/серверов средствами GPO: Создайте группу компьютеров средствами Active Directory – пользователи и компьютеры , задайте имя группе, например, KUMA WEC . Добавьте в данную группу рабочие станции/серверы, с которых предполагается сбор событий. Если предполагается сбор событий с контроллеров домена, в таком случае, контроллеры домена можно не добавлять в созданную группу компьютеров , добавив отдельно в Фильтр безопасности при настройке GPO Для того, чтобы изменения вступили в силу (в данном случае членство в новой группе), выполните перезагрузку устройства. Альтернативным вариантом может быть перевыпуск Kerberos-тикетов для устройства с помощью klist.exe. На контроллере домена запустите оснастку Управление групповой политикой : нажмите Win + R → gpmc.msc . Выберите существующий объект групповой политики или создайте новый. В данном примере создается новый объект групповой политики Audit Policy for KUMA : ПКМ Объекты групповой политики → Создать → введите в имени Audit Policy for KUMA . Далее выберите созданный объект групповой политики Audit Policy for KUMA и нажмите Изменить . Windows Event Log Powershell Чтобы настроить аудит событий, связанных с выполнением команд и скриптов в PowerShell: Перейдите в Конфигурация компьютера → Политики → Административные шаблоны → Компоненты Windows → Windows PowerShell .  Выберите Включить ведение журнала модулей . В появившемся окне Включить ведение журнала модулей : Укажите Включено . В секции Параметры нажмите Показать . В окне Вывод содержания в качестве значения укажите «*» и нажмите ОК . В окне Включить ведение журнала модулей нажмите ОК . Выберите Включить регистрацию блоков сценариев PowerShell . В появившемся окне Включить регистрацию блоков сценариев PowerShell укажите Включено и нажмите ОК . Убедитесь, что состояние параметров политики соответствует скриншоту ниже. Windows Event Log Security Чтобы настроить аудит событий, связанных с входами пользователей, аутентификацией, доступом к ресурсам, изменениями учетных записей и т.д.: Перейдите в Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Конфигурация расширенной политики аудита → Политики аудита . Настройте параметры аудита согласно скриншотам ниже. При использовании Расширенной политики аудита необходимо включить параметр "Аудит: принудительное переопределение параметров категории политики аудита параметрами подкатегории политики аудита (Windows Visa или более поздние версии)  в целях переопределения параметров, указанных в  Политике аудита . Дополнительно необходимо включить журналирование команд, выполняемых в командной строке (cmd): Перейдите в Конфигурация компьютера → Политики → Административные шаблоны → Система → Аудит создания процессов . Активируйте параметр политики Включать командную строку в события создания процессов . В данном статье не рассматривается настройка аудита событий доступа к объектам (ветки реестра, папки и файлы и т.д.) и событий доступа к службе каталогов. Windows Event Log System Дополнительные настройки для журнала System не требуются. Windows Event Log Defender Дополнительные настройки для журнала Microsoft-Windows-Windows Defender/Operational не требуются. Далее вернитесь в Управление групповой политикой → выберите объект групповой политики 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 выполните следующую команду на одной из рабочих станций/сервере: auditpol.exe /get /category:* | Select-String -Pattern "Успех" Убедитесь, что параметры аудита соответствуют скриншоту ниже. Настройка 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-сервере Чтобы настроить подписку на WEC-сервере: Нажмите кнопку Win , введите eventvwr.msc и запустите Просмотр событий от имени администратора. Выберите Подписки → правой кнопкой мыши Создать подписку → Укажите имя подписки, например, KUMA WEC и тип подписки Инициировано исходным компьютером . Выберите группу устройств, события которой требуется собирать. В нашем примере – это ранее созданная группа KUMA WEC: нажмите Выбрать группы компьютеров →   Добавить доменный компьютер →  в поле Введите имена выбираемых объектов укажите ранее созданную группу компьютеров и нажмите ОК . В качестве альтернативы вместо группы компьютеров можно добавить необходимые рабочие станции/серверы по отдельности. Если предполагается сбор событий с контроллера домена, в таком случае, контроллер домена можно добавить как отдельный доменный компьютер Задайте собираемые события: Выбрать события → перейдите на вкладку XML и установите флажок Изменить запрос вручную . Вставьте в поле следующий фильтр событий: Нажмите ОК . Рекомендации по настройке аудита событий Windows: https://kb.kuma-community.ru/books/kuma-how-to/page/poleznye-ssylki-po-ib Далее в окне Свойства подписки нажмите Дополнительно и для параметра Оптимизация доставки событий укажите Уменьшенная задержка . Нажмите ОК . В одну подписку можно добавить не более 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://:5985/wsman/SubscriptionManager/WEC,Refresh=60 где 60 – частота обращения (в секундах) источников событий к WEC -серверу за новыми инструкциями по пересылке журналов. Microsoft рекомендует настраивать параметр Refresh в зависимости от частоты внесения изменений в подписки. Если подписки изменяются нечасто, для параметра Refresh можно установить значение в несколько часов, например, Refresh=43200 (обновление раз в 12 часов). Источники событий должны иметь возможность «резолвить» FQDN WEC-сервера для отправки событий. Для этого создайте A-запись на DNS-сервере или создайте запись локально в файле hosts После применения данной настройки перезапустите службу WinRM c помощью PowerShell- команды: Restart-Service -Name WinRM Для группы рабочих станций/серверов средствами GPO Настройка службы WinRM При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов. Чтобы настроить службу WinRM для группы рабочих станций/серверов средствами GPO: На контроллере домена запустите оснастку  Управление групповой политикой : нажмите 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)' Настройка подписки Чтобы настроить подписку для группы рабочих станций/серверов средствами GPO: На контроллере домена запустите оснастку   Управление групповой политикой: нажмите Win + R   → gpmc . msc . Выберите ранее использовавшийся объект групповой политики   Audit Policy for KUMA   и нажмите   Изменить . В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера → Политики → Административные шаблоны → Компоненты Windows → Пересылка событий → Настроить конечный диспетчер подписки . Выберите Включено и нажмите Показать . В появившемся окне введите параметры  WEC -сервера: Server=http://:5985/wsman/SubscriptionManager/WEC,Refresh=60 где 60 – частота обращения (в секундах) источников событий к серверу за новыми инструкциями по пересылке журналов. Microsoft рекомендует настраивать параметр Refresh в зависимости от частоты внесения изменений в подписки. Если подписки изменяются нечасто, для параметра Refresh можно установить значение в несколько часов, например, Refresh=43200 (обновление раз в 12 часов). Источники событий должны иметь возможность «резолвить» FQDN WEC -сервера для отправки событий. Для этого создайте A -запись на DNS -сервере или создайте запись локально в файле hosts Для того, чтобы новые параметры групповой политики Audit Policy for KUMA были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях: перезагрузка устройства и вход пользователя автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени) вручную с помощью команды  gpupdate (на рабочей станции/сервере) вручную из консоли  Group Policy Management Console (на контроллере домена, только для OU ) вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена) Проверка поступления событий Убедитесь, что на WEC-сервер поступают события с рабочих станций/серверов: На  WEC -сервере нажмите кнопку   Win , введите   eventvwr . msc   и запустите   Просмотр событий от имени администратора. Перейдите в   Журналы  Windows  →   Перенаправленные события.   Если в появившемся окне   Перенаправленные события   отображаются события с источников, значит подписка работает корректно. Для MS Server 2016 и 2019 в случае если события не пересылаются, выполнить шаги по  этой инструкции . При добавлении разрешения для URL-адреса с помощью netsh http add urlacl  добавьте кавычки "..." в параметре SDDL: netsh http delete urlacl url=http://+:5985/wsman/ netsh http add urlacl url=http://+:5985/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)" netsh http delete urlacl url=https://+:5986/wsman/ netsh http add urlacl url=https://+:5986/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)" В случае если события определенного журнала не отправляются с источника событий проверьте на данном источнике в журнале Microsoft/Windows/Event_forwardingPlugin/Operational наличие событий с кодом 5004 (ошибка отправки журналов на WEC-сервер). При наличии событий с кодом 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/порт (порт, на котором коллектор будет ожидать входящие подключения от агента. Выбирается любой из незанятых, выше 1024). В данном примере будет использоваться 5151. В качестве разделителя укажите \0. В поле URL можно указать только порт при инсталляции All-in-one. На вкладке Дополнительные параметры для шифрования передаваемых данных между агентом и коллектором выберите Режим TLS - С верификацией . На третьем шаге мастера укажите нормализатор. В данном случае рекомендуется использовать «коробочный» нормализатор [OOTB] Microsoft Products for KUMA 3 . Шаги мастера настройки с четвертого по шестой являются опциональными, их можно пропустить и вернуться к настройке позднее. На седьмом шаге мастера задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище . В случае если предполагается также анализ потока событий правилами корреляции добавьте точку назначения типа Коррелятор . На завершающем шаге мастера нажмите на кнопку Создать и сохранить сервис . После чего появится строка установки сервиса, которую необходимо скопировать для дальнейшей установки. Нажмите Сохранить . После выполнения вышеуказанных действий в разделе Ресурсы → Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Чтобы установить коллектор KUMA: Выполните подключение к CLI сервера, на котором планируется развертывание коллектора KUMA. Для установки сервиса коллектора в командной строке выполните команду под учетной записью root, скопированную на прошлом шаге. При необходимости добавьте используемый порт сервиса коллектора в исключения МЭ ОС и обновите параметры службы. # Пример для firewalld firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp|udp –permanent firewall-cmd –reload # Пример для ufw ufw allow <порт, выбранный для коллектора>/tcp|udp ufw reload После успешной установки сервиса его статус в веб-консоли KUMA изменится на ВКЛ с зеленой индикацией . Создание сервисной учетной записи Для функционирования агента KUMA предварительно необходимо создать доменную сервисную учетную запись, с помощью которой будет выполняться запуск службы агента KUMA и обеспечиваться доступ к журналам событий, полученных от рабочих станций/серверов Windows (журнал Forwarded Events).  В качестве более безопасной альтернативы обычной пользовательской учетной записи  рекомендуется использование управляемой учетной записи службы (MSA). См. Приложение А. Использование Managed Service Accounts (MSA) Добавление сервисной учетной записи в группу "Читатели журнала событий" Для доступа агента KUMA к журналу Forwarded Events добавьте созданную сервисную учетную запись в локальную группу Читатели журнала событий на WEC-сервере. Чтобы добавить учетную запись в локальную группу Читатели журнала событий : Нажмите кнопку Win . Введите lusrmgr.msc и запустите Локальные пользователи и группы от имени администратора. В появившемся окне перейдите в Группы , выберите группу Читатели журнала событий и нажмите правой кнопкой мыши Свойства . В свойствах группы нажмите Добавить и в поле Введите имена выбираемых объектов укажите <имя созданной сервисной учетной записи>. После ввода УЗ нажмите Проверить имена . Как только УЗ будет найдена нажмите ОК . В окне свойств группы нажмите еще раз ОК для применения изменений группы. Назначение прав входа в качестве службы Разрешите сервисной учетной записи вход в качестве службы (Log on as a service) на WEC-сервере. Это необходимо, чтобы учетная запись могла использоваться для запуска и работы служб (сервисов). В данном случае для запуска и работы службы агента KUMA. Чтобы разрешить учетной записи вход в качестве службы: Нажмите кнопку Win , введите secpol.msc и запустите Локальная политика безопасности от имени администратора. В появившемся окне перейдите в Локальные политики → Назначение прав пользователя , выберите политику В ход в качестве службы и нажмите правой кнопкой мыши Свойства . В свойствах политики нажмите Добавить пользователя или группу и в поле Введите имена выбираемых объектов укажите <имя созданной сервисной учетной записи>. После ввода УЗ нажмите Проверить имена . Как только УЗ будет найдена нажмите  ОК . В окне свойств политики нажмите еще раз ОК для применения изменений группы. Дополнительно убедитесь, что соответствующая сервисная учетная запись отсутствует в свойствах политики Отказать во входе в качестве службы. Создание ресурса агента KUMA Для создания ресурса агента в веб-интерфейсе KUMA: Перейдите на вкладку Ресурсы → Агенты и нажмите на кнопку Добавить агент . В окне Создание агента на вкладке Общие параметры укажите Имя агента и Тенант , которому он будет принадлежать. В поле Описание можно добавить описание сервиса. Перейдите на вкладку Подключение 1 и укажите следующие параметры: В блоке параметров Коннектор укажите: Название коннектора Тип – WEC Журналы Windows – ForwardedEvents В блоке параметров Точки назначения укажите параметры точки назначения: В поле Название укажите имя точки назначения (в качестве точки назначения для агента будет выступать ранее созданный коллектор). В раскрывающемся списке Тип выберите тип точки назначения (в нашем примере http по аналогии с созданным коллектором). URL сервиса коллектора, который будет обрабатывать события, собранные агентом KUMA. URL созданного коллектора см. в Разделе Создание коллектора KUMA. Доступные форматы URL: <имя хоста>:<номер порта>; :<номер порта>; <номер порта>. При необходимости можно добавить несколько URL для балансировки нагрузки или обеспечения отказоустойчивости. Перейдите на вкладку Дополнительные параметры и для шифрования передаваемых данных между агентом и коллектором выберите Режим TLS - С верификацией . Также укажите в качестве Разделителя /0. Дополнительные параметры точки назначения (например, Разделитель и режим TLS) должны совпадать с дополнительными параметрами коллектора, с которым вы хотите связать агент. Точек назначения может быть несколько. Их можно добавить с помощью кнопки Добавить точку назначения . Нажмите Создать для создания ресурса агента. Публикация агента KUMA Когда ресурс агента создан, можно перейти к созданию сервиса агента в KUMA. Чтобы создать сервис агента в веб-интерфейсе KUMA: В веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы нажмите Добавить . В появившемся окне Выберите сервис выберите только что созданный ресурс агента и нажмите Создать сервис . Сервис агента создан в веб-интерфейсе KUMA и отображается в разделе Ресурсы → Активные сервисы . Теперь сервис агента необходимо установить на WEC-сервере для сбора событий Windows. После публикации агента скопируйте идентификатор сервиса для последующей установки сервиса (службы) агента на WEC-сервере.  Установка агента KUMA Перед установкой агента KUMA убедитесь, что для WEC-сервера, где предполагается установка, открыты следующие сетевые доступы: Порт TCP/7210 к Ядру KUMA. К Коллектору KUMA, предназначенного для приема и обработки событий Windows. Порт и протокол, указанные при создании Коллектора (см. Раздел Создание коллектора KUMA). Также убедитесь, что на WEC-сервере, где предполагается установка агента KUMA, «резолвится» DNS-имя сервера KUMA (для распределенной инсталляции DNS-имя сервера Ядра и сервера коллектора KUMA). При необходимости добавьте соответствующие записи в файл hosts на WEC-сервере, либо создайте A-записи на DNS-сервере организации. Чтобы установить агент KUMA на WEC-сервер: Скопируйте файл kuma.exe в папку на WEC-сервере. Для установки рекомендуется использовать папку C:\Users\<имя пользователя>\Desktop\KUMA. Файл kuma.exe находится внутри установщика в директории /kuma-ansible-installer/roles/kuma/files/. Запустите командную строку на WEC-сервере с правами администратора и перейдите в папку с файлом kuma.exe. Выполните следующую команду: kuma agent --core https://<полное доменное имя сервера ядра KUMA>:<порт, используемый сервером ядра KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса агента, созданного в KUMA> --user <имя пользователя, под которым будет работать агент, включая домен, в формате domain\username> --install Пример: kuma agent --core https://kuma.example.com:7210 --id XXXXX --user domain\username –install Если агент устанавливается из-под доменной учетной записи пользователь указывается в формате <домен>\<имя учетной записи>, например, demo\user Для запуска агента требуется подтверждение лицензионного соглашения. В процессе установки вам будет предложено ознакомиться с текстом лицензионного соглашения и у вас будет возможность принять соглашение или отказаться. Если этого не произошло автоматически, вы можете воспользоваться следующей командой, чтобы ознакомиться с текстом лицензионного соглашения: kuma.exe license --show Если вы хотите принять лицензионное соглашение, выполните команду и нажмите y: kuma.exe license Введите пароль пользователя, под которым будет работать служба агента. В процессе установки будет создана папка C:\ProgramData\Kaspersky Lab\KUMA\agent\<идентификатор агента>, в которую будет установлен сервис агента KUMA.  После установки сервис (служба) агента запускается автоматически. Сервис также настроен на перезапуск в случае сбоев. Агент можно перезапустить из веб-интерфейса KUMA, но только когда сервис активен. В противном случае сервис требуется перезапустить вручную на устройстве Windows. Далее перейдите в веб-интерфейс KUMA и убедитесь в успешности запуска агента - статус сервиса агента KUMA WEC должен измениться на ВКЛ с зеленой индикацией .  Чтобы удалить агент KUMA с WEC-сервера по окончании тестирования продукта: Запустите командную строку на WEC-сервере с правами администратора и найдите папку с файлом kuma.exe. Выполните команду ниже: kuma.exe agent --id <идентификатор сервиса агента, созданного в KUMA> --uninstall Проверка поступления событий Windows в KUMA Для проверки, что сбор событий Windows успешно настроен перейдите в Ресурсы → Активные сервисы → выберите ранее созданный коллектор для событий Windows и нажмите Перейти к событиям . В открывшемся окне События убедитесь, что присутствуют события с устройств Windows.  Приложение А. Использование Managed Service Accounts (MSA) Управляемые учетные записи служб (Managed Service Accounts – MSA) - это специальный тип учетных записей служб в Active Directory (AD), предназначенный для повышения безопасности и упрощения администрирования. Создаваемая учетная запись службы (MSA) ассоциируется с определенным сервером. Эта учетная запись имеет автоматически генерируемый сложный пароль (120 символов) и поддерживается устройством без ручного вмешательства. Таким образом, MSA обеспечивает безопасный и удобный способ запуска служб на устройствах Windows. Обычные сервисные учетные записи, которые используются для запуска служб (например, DOMAIN\ServiceAccount ) создают административные сложности: Ручное управление паролями:  Администратор должен регулярно вручную менять пароль, а затем обновлять его в настройках службы на всех серверах, где она работает. Это трудоемко и чревато простоями, если пароль не сменить вовремя. Риск безопасности:  Часто администраторы устанавливают для таких учетных записей сложные пароли и никогда их не меняют, что создает угрозу безопасности. Принцип одного сервера: Одна учетная запись не должна использоваться на нескольких серверах одновременно по соображениям безопасности (сложность аудита и отзыва). Основные особенности MSA: Автоматическое управление паролями:  Система сама генерирует очень сложный случайный пароль (120 символов) и регулярно его меняет (по умолчанию каждые 30 дней). Вам никогда не нужно его знать или вводить. Привязка к одному компьютеру:  Один MSA может быть привязан только к  одному  серверу (компьютеру) в домене. Это обеспечивает изоляцию служб. Упрощенное администрирование: Вы просто указываете службе использовать MSA, и система сама на периодической основе обновляет пароль. Нельзя использовать для интерактивного входа: Эту учетную запись нельзя использовать для входа в систему по RDP или в консоли сервера. Типы MSA: Standalone Managed Service Account (sMSA) – работает только на одном сервере. Group Managed Service Account (gMSA) – может использоваться на нескольких серверах в домене (например, в кластере или ферме). Настройка sMSA Предварительные требования: ОС Windows Server 2008 R2 / Windows 7 или выше. Требования к функциональному уровню домена: Минимальный уровень — Windows Server 2008 R2. Наличие powershell-модуля ActiveDirectory Шаги по настройке: Действия на контроллере домена Запустите PowerShell и выполните команду для создания sMSA: New-ADServiceAccount -Name "Имя sMSA" -Description "Описание учетной записи" -Enabled $true -RestrictToSingleComputer Привяжите sMSA к WEC-серверу: $Identity = Get-ADComputer -identity "Имя WEC-сервера" Add-ADComputerServiceAccount -Identity $identity -ServiceAccount "Имя sMSA" Убедитесь, что привязка sMSA к WEC-серверу выполнена успешно: Get-ADComputer -Identity "Имя WEC-сервера" -Properties msDS-HostServiceAccount После создания учетная запись появится в контейнере  Managed Service Accounts вашего домена. Чтобы увидеть его в оснастке "Пользователи и компьютеры Active Directory" (ADUC) , необходимо включить просмотр  расширенных функций (View -> Advanced Features). Действия на WEC-сервере sMSA должен быть "установлен" на сервере, где он будет использоваться. Это сообщает системе, что данный сервер имеет право использовать эту управляемую учетную запись. Запустите PowerShell с правами администратора и выполните команду для установки модуля Active Directory: Add-WindowsFeature RSAT-AD-PowerShell Выполните установку sMSA с использованием доменной учетной записи с соответствующими правами (в данном примере использовалась учетная запись с правами администратора домена): Install-ADServiceAccount -Identity "Имя_sMSA" Убедитесь, что sMSA успешно установлен: Test-ADServiceAccount -Identity "Имя_sMSA" Если команда выполняется без ошибок, значит sMSA успешно установлен на сервере. Результат в случае успеха:  True Назначьте sMSA права Входа в качестве службы (Log on as a service) и добавьте в группу Читатели журнала событий (Event Log Readers) При установке через Install-ADServiceAccount права Вход в качестве службы (Log on as a service) назначаются автоматически Add-LocalGroupMember -Group "Event Log Readers" -Member "UserName" Выполните установку агента KUMA, указав в качестве пользователя учетную запись sMSA в формате DOMAIN\sMSA_Name$ (см. раздел Установка агента KUMA ). Оставьте поле User password пустым Полезные ссылки https://techcommunity.microsoft.com/blog/askds/managed-service-accounts-understanding-implementing-best-practices-and-troublesh/397009 Приложение B. Отказоустойчивый сбор событий с WEC-сервером События на контроллерах домена хранятся очень мало – ротация примерно через 3-5 минут. Поэтому чтобы гарантировать доставку, если по какой-то причине WEС не доступен, предлагается следующая схема: использовать 2 WEC сервера все DC отправляют события не на один, а на 2 WEC сервера (события обоих WEC дублируются) на каждом WEC сервере установлены KUMA Agent оба KUMA Agent отправляют события в ОДИН и тот же коллектор Windows (это важный момент) на коллекторе Windows настраивается агрегация события, чтобы дубли событий с обоих WEC серверов были агрегированы в одно событий С этим одним событием, прошедшее через такую сложную цепочку и работает KUMA. Это позволит выполнять обслуживание, перезагружать WEC коллекторы (но не одновременно), без потери потока данных с контролеров. Настройка подписки WEC с использованием XML фильтра Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. При настройке подписки  WEC через графический интерфейс не получится выбрать нужные для сбора журналы, если на сервере с WEC не установлены соответствующие роли Windows Server или ПО. Чтобы выбрать журналы, которые фактически присутствуют на удаленном сервере, но не доступны для выбора на WEC , можно воспользоваться XML фильтром. Ниже приведен пример XML фильтра для сбора событий из стандартного журнала  Security , а также из журнала, который присущ только контроллеру домена - Directory Service . В результате данной настройки 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тратора. Переходим Служебные программы - Производительность - Сеансы отслеживания событий запуска (perfmon.msc). Создаем группу сборщиков данных: Задаем имя сборщика, например etwDNS-Analytics: Добавляем поставщика Microsoft-Windows-DNSServer : Агент с коннектором ETW работает только с System.Provider.Guid: {EB79061A-A566-4698-9119-3ED2807060E7} - Microsoft-Windows-DNSServer Нажимаем Далее - Далее - Готово . В сеансах отслеживания событий, в свойствах - Сеансы отслеживания указываем Режим реального времени Нажимаем Применить и ОК . Запускаем созданного поставщика, как сеанс отслеживания событий: Для персистентности режима реального времени, в редакторе реестра (regedit.exe) по пути HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger далее название ранее созданного сеанса в ключе LogFileMode установите значение 100. Чтобы просмотреть, какие типы событий можно отслеживать, выполните следующую команду в командной строке 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://:7210 --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 --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 Адрес назначения ловушек: На вкладке Безопасность: Установите флажок: Посылать ловушку проверки подлинности (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): MS WMI Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в онлайн-справке на продукт: https://support.kaspersky.ru/kuma/3.4/257568 Описание схемы сбора событий Windows с помощью WMI Компоненты схемы: Источники событий:  рабочие станции и серверы Windows. Агент KUMA  - компонент KUMA, устанавливаемый на выделенный сервер/рабочую станцию. Агент подключается к службе WMI на удаленной рабочей станции/сервере и получает события Windows. Требования к устройствам для установки агентов: https://support.kaspersky.ru/kuma/3.4/217889 Коллектор KUMA - компонент KUMA, обеспечивающий прием/нормализацию/агрегацию/фильтрацию событий, полученных от агента KUMA, и их дальнейшую отправку в коррелятор и/или хранилище KUMA. Сбор событий с помощью агента WMI рекомендуется использовать в следующих случаях: - Если отсутствует возможность использовать технологию WEF и WEC-сервер для реализации централизованного сбора событий. - Если необходимо выполнить сбор событий с небольшого количества хостов - не более 500 хостов для одного агента KUMA. Настройка политики аудита По умолчанию на устройствах Windows аудит событий не осуществляется. Настройка политики аудита на отдельной рабочей станции/сервере Чтобы настроить политику аудита на отдельной рабочей станции/сервере: Запустите оснастку  Локальная политика безопасности : нажмите кнопку Win → введите secpol.msc и запустите Локальная политика безопасности от имени администратора. Перейдите в политику аудита Локальные политики → Политика аудита. Настройте параметры аудита согласно скриншоту (при необходимости включите аудит оставшихся политик). Примеры рекомендованных политик можно найти  тут Настройка политики аудита для группы рабочих станций/серверов средствами GPO При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов настройки. Чтобы настроить политику аудита для группы рабочих станций/серверов средствами GPO: Создайте группу компьютеров средствами Active Directory – пользователи и компьютеры , задайте имя группе, например, KUMA WMI . Добавьте в данную группу рабочие станции/серверы, с которых предполагается сбор событий. Для того, чтобы изменения вступили в силу (в данном случае членство в новой группе), выполните перезагрузку устройства. Альтернативным вариантом может быть перевыпуск Kerberos-тикетов для устройства с помощью klist.exe. На контроллере домена запустите оснастку Управление групповой политикой : нажмите Win + R → gpmc.msc . Выберите существующий объект групповой политики или создайте новый. В данном примере создается новый объект групповой политики Audit Policy for KUMA : ПКМ Объекты групповой политики → Создать → введите в имени Audit Policy for KUMA . Далее выберите созданный объект групповой политики Audit Policy for KUMA и нажмите Изменить . В открывшемся окне Редактор управления групповыми политиками перейдите в   Конфигурация компьютера → Политики → Конфигурация Windows → Параметры безопасности → Локальные политики → Политики аудита и настройте параметры аудита согласно скриншоту (при необходимости включите аудит оставшихся политик). Далее вернитесь в Управление групповой политикой → выберите объект групповой политики Audit Policy for KUMA → в окне справа Фильтры безопасности удалите группу Прошедшие проверку и добавьте группу KUMA WMI. Нажмите ПКМ на домен и выберите Связать существующий объект групповой политики → выберите Audit Policy for KUMA и нажмите ОК . Итоговый вид политики должен выглядеть следующим образом (см. скриншот). В целом, групповые политики Active Directory можно назначать на OU, сайт или весь домен. Для того, чтобы новые параметры аудита, заданные в GPO, были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях: перезагрузка устройства и вход пользователя; автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени); вручную с помощью команды gpupdate (на рабочей станции/сервере); вручную из консоли Group Policy Management Console (на контроллере домена, только для OU); вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена). Для проверки успешного применения GPO запустите оснастку Локальная политика безопасности на одной из рабочих станций/сервере: Нажмите WIN+R → введите secpol.msc и запустите Локальная политика безопасности от имени администратора. Перейдите в политику аудита Локальные политики →   Политика аудита . Убедитесь, что параметры аудита соответствуют скриншоту. Примеры рекомендованных политик можно найти  тут Настройка служб и брандмауэра Настройка служб и брандмауэра на отдельной рабочей станции/сервере Предварительно на рабочей станции/сервере (источнике событий) необходимо убедиться, что службы Удаленный вызов процедур и Сопоставитель конечных точек RPC запущены. Для этого: Откройте окно Выполнить , нажав комбинацию клавиш Win+R . В открывшемся окне введите запрос services.msc и нажмите OK . В окне Службы найдите следующие службы: Удаленный вызов процедур (Remote Procedure Call) Сопоставитель конечных точек RPC (RPC Endpoint Mapper) Убедитесь, что в графе Состояние у этих служб отображается статус Выполняется . Агент KUMA может получать события журналов Windows с помощью WMI RPC, если открыты порты для входящих соединений на рабочей станции/сервере, с которого планируется сбор событий.  Чтобы открыть порты для входящих соединений на рабочей станции/сервере (источнике событий): Откройте окно Выполнить , нажав комбинацию клавиш Win+R . В открывшемся окне введите запрос wf.msc и нажмите OK . В появившемся окне Монитор брандмауэра Защитника Windows в режиме повышенной безопасности перейдите в раздел Правила для входящих подключений и в панели Действия нажмите Создать правило. Откроется Мастер создания правила для нового входящего подключения . В Мастере создания правила для нового входящего подключения на шаге Тип правила выберите Для порта . На шаге Протоколы и порты в качестве протокола выберите Протокол TCP . В поле Определенные локальные порты укажите номера портов: 135 445 49152-65535 На шаге Действие выберите Разрешить подключение (выбрано по умолчанию). На шаге Профиль снимите флажки Частный и Публичный . На шаге Имя укажите имя правила для нового входящего подключения и нажмите Готово . Настройка коллектора и агента KUMA Для передачи событий с рабочих станций/серверов Windows в KUMA используется связка агента и коллектора KUMA. Передача данных организована следующим образом: Агент с помощью коннектора WMI подключается к удаленным рабочим станциям/серверам, указанным в конфигурации, и получает события. Агент без предварительной обработки передает события коллектору KUMA, указанному в точке назначения. Можно настроить агент таким образом, чтобы разные журналы отправлялись в разные коллекторы. Коллектор принимает события от агента, выполняет полный цикл обработки события и отправляет обработанные события в точку назначения (Хранилище и/или Коррелятор). Агент KUMA состоит из двух частей: одна часть создается внутри веб-интерфейса KUMA, а вторая устанавливается на рабочей станции/сервере. Создание агента производится в несколько этапов: Создание набора ресурсов агента в веб-интерфейсе KUMA. Создание сервиса агента в веб-интерфейсе KUMA. Установка серверной части агента на сервере, с которого требуется сбор событий или с которого будет осуществляться удаленный доступ для сбора событий с других рабочих станций/серверов. Сервис агента в веб-интерфейсе KUMA создается на основе набора ресурсов для агента, в котором объединяются коннекторы и точки назначения. Создание коллектора Для создания коллектора в веб-интерфейсе KUMA: Перейдите в раздел Ресурсы и нажмите на кнопку Подключить источник . В появившемся окне мастера настройки Создание коллектора на первом шаге ( Подключение источников ) выберите Имя коллектора и Тенант , к которому будет принадлежать создаваемый коллектор. На втором шаге мастера ( Транспорт ) укажите параметры коннектора для взаимодействия с агентом. В данном случае рекомендуется использовать http. В поле URL задайте FQDN/порт (порт, на котором коллектор будет ожидать входящие подключения от агента. Выбирается любой из незанятых, выше 1024). В данном примере будет использоваться 5156. В качестве разделителя укажите \0 . В поле URL можно указать только порт при инсталляции All-in-one. В версии KUMA 3.4 в качестве типа коннектора можно указать  internal  вместо http.  Это позволит отправлять служебную информацию о маршруте события, которая будет доступна в карточке события. На вкладке Дополнительные параметры для шифрования передаваемых данных между агентом и коллектором выберите Режим TLS - С верификацией . На третьем шаге мастера укажите нормализатор. В данном случае рекомендуется использовать «коробочный» нормализатор [OOTB] Microsoft Products for KUMA 3 . Шаги мастера настройки с четвертого по шестой являются опциональными, их можно пропустить и вернуться к настройке позднее. На седьмом шаге мастера задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище . В случае если предполагается также анализ потока событий правилами корреляции добавьте точку назначения типа Коррелятор . На завершающем шаге мастера нажмите на кнопку Создать и сохранить сервис . После чего появится строка установки сервиса, которую необходимо скопировать для дальнейшей установки. Нажмите Сохранить . После выполнения вышеуказанных действий в разделе Ресурсы → Активные сервисы появится созданный сервис коллектора. Установка коллектора Чтобы установить коллектор KUMA: Выполните подключение к CLI сервера, на котором планируется развертывание коллектора KUMA. Для установки сервиса коллектора в командной строке выполните команду под учетной записью root, скопированную на прошлом шаге. При необходимости добавьте используемый порт сервиса коллектора в исключения МЭ ОС и обновите параметры службы. # Пример для firewalld firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp|udp –permanent firewall-cmd –reload # Пример для ufw ufw allow <порт, выбранный для коллектора>/tcp|udp ufw reload После успешной установки сервиса его статус в веб-консоли KUMA изменится на ВКЛ с зеленой индикацией. Создание сервисной учетной записи Для функционирования агента KUMA предварительно необходимо создать доменную сервисную учетную запись, с помощью которой будет выполняться запуск службы агента KUMA и обеспечиваться доступ к журналам событий на рабочих станциях и серверах Windows (в нашем примере будет использоваться одна учетная запись). Допускается использовать отдельные учетные записи (в том числе локальные) для запуска службы агента KUMA и доступа к журналам событий на рабочих станциях и серверах Windows. Добавление сервисной учетной записи в группу "Читатели журнала событий" Для доступа агента KUMA к журналам событий Windows добавьте созданную сервисную учетную запись в локальную группу Читатели журнала событий на каждой рабочей станции/сервере. Чтобы добавить учетную запись в локальную группу Читатели журнала событий : Нажмите кнопку Win . Введите lusrmgr.msc и запустите Локальные пользователи и группы от имени администратора. В появившемся окне перейдите в Группы , выберите группу Читатели журнала событий и нажмите правой кнопкой мыши Свойства . В свойствах группы нажмите Добавить и в поле Введите имена выбираемых объектов укажите <имя созданной сервисной учетной записи>. После ввода УЗ нажмите Проверить имена . Как только УЗ будет найдена нажмите ОК . В окне свойств группы нажмите еще раз ОК для применения изменений группы. Назначение прав входа в качестве службы На рабочей станции/сервере, где планируется установка агента KUMA,  разрешите сервисной учетной записи вход в качестве службы (Log on as a service). Это необходимо, чтобы учетная запись могла использоваться для запуска и работы служб (сервисов). В данном случае для запуска и работы службы агента KUMA. Чтобы разрешить учетной записи вход в качестве службы: Нажмите кнопку Win , введите secpol.msc и запустите Локальная политика безопасности от имени администратора. В появившемся окне перейдите в Локальные политики → Назначение прав пользователя , выберите политику Вход в качестве службы и нажмите правой кнопкой мыши Свойства . В свойствах политики нажмите Добавить пользователя или группу и в поле Введите имена выбираемых объектов укажите <имя созданной сервисной учетной записи>. После ввода УЗ нажмите Проверить имена. Как только УЗ будет найдена нажмите ОК . В окне свойств политики нажмите еще раз ОК для применения изменений группы. Дополнительно убедитесь, что соответствующая сервисная учетная запись отсутствует в свойствах политики Отказать во входе в качестве службы. Создание секрета в KUMA После создания сервисной учетной записи необходимо добавить секрет в веб-интерфейсе KUMA. Этот ресурс будет хранить учетные данные для подключения агента KUMA к рабочим станциям/серверам. Чтобы создать секрет в KUMA выполните следующие действия: Откройте раздел веб-интерфейса KUMA Ресурсы → Секреты . Отобразится список доступных секретов. Нажмите на кнопку  Добавить , чтобы создать новый секрет. В появившемся окне Создание секрета введите данные секрета: В поле Название укажите имя для добавляемого секрета. В раскрывающемся списке Тенант выберите тенант, которому будет принадлежать создаваемый ресурс. В раскрывающемся списке Тип выберите credentials . В поле Пользователь укажите имя созданной сервисной учетной записи. При использовании доменной учетной записи ДОМЕН УКАЗЫВАТЬ НЕ НУЖНО . Значение домена для доступа к устройству будет применяться из столбца Домен таблицы Удаленные хосты (см. Раздел Создание ресурса агента KUMA ). В поле Пароль укажите пароль учетной записи. Нажмите Создать . Из соображений безопасности после сохранения секрета строки, указанные в полях Пользователь и Пароль , скрываются. Создание ресурса агента KUMA Для создания ресурса агента в веб-интерфейсе KUMA: Перейдите на вкладку Ресурсы → Агенты и нажмите на кнопку Добавить агент . В окне  Создание агента на вкладке Общие параметры укажите Имя агента и Тенант , которому он будет принадлежать. В поле Описание можно добавить описание сервиса. Перейдите на вкладку Подключение 1 и укажите следующие параметры: В блоке параметров Коннектор укажите: Название коннектора Тип – WMI Учетные данные по умолчанию , если при подключении к удаленным рабочим станциям/серверам для сбора событий Windows будет использоваться одна сервисная учетная запись. В блоке параметров Удаленные хосты укажите параметры удаленных устройств Windows, с которых требуется собирать события: Сервер – IP-адрес или имя устройства, с которого необходимо собирать события, например wd10. Домен – название домена, в котором расположено устройство. Например, truecompany.local. Тип журналов – название журналов Windows, события которых требуется получить. По умолчанию в этом раскрывающемся списке отображаются только предварительно настроенные журналы, но вы можете расширить список пользовательскими журналами. Для этого введите название пользовательских журналов в поле Журналы Windows, после чего нажмите на клавишу ENTER .  Журналы, доступные по умолчанию: Application. ForwardedEvents. Security. System. HardwareEvents. Секрет – учетные данные для доступа к удаленной рабочей станции/серверу Windows с правами на чтение журналов. Если оставить вариант По умолчанию будут использоваться учетные данные из секрета, указанного в поле Учетные данные, используемые по умолчанию .  Вы можете добавить несколько удаленных устройств Windows, нажав на кнопку Добавить . В случае если используется локальная УЗ для доступа к журналам удаленной рабочей станции/сервера укажите IP-адрес рабочей станции/сервера в полях Сервер и Домен . В блоке параметров Точки назначения укажите параметры точки назначения: В поле Название укажите имя точки назначения (в качестве точки назначения для агента будет выступать ранее созданный коллектор). В раскрывающемся списке Тип выберите тип точки назначения (в нашем примере http по аналогии с созданным коллектором). URL сервиса коллектора, который будет обрабатывать события, собранные агентом KUMA. URL созданного коллектора см. в Разделе Создание коллектора KUMA . Доступные форматы URL: <имя хоста>:<номер порта>; :<номер порта>; <номер порта>. При необходимости можно добавить несколько URL для балансировки нагрузки или обеспечения отказоустойчивости. Перейдите на вкладку Дополнительные параметры и для шифрования передаваемых данных между агентом и коллектором выберите Режим TLS - С верификацией . Также укажите в качестве Разделителя /0. Дополнительные параметры точки назначения (например, Разделитель и режим TLS ) должны совпадать с дополнительными параметрами коллектора, с которым вы хотите связать агент. Точек назначения может быть несколько. Их можно добавить с помощью кнопки Добавить точку назначения . Нажмите Создать для создания ресурса агента. Публикация агента Когда ресурс агента создан, можно перейти к созданию сервиса агента в KUMA. Чтобы создать сервис агента в веб-интерфейсе KUMA: В веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы нажмите Добавить . В появившемся окне Выберите сервис выберите только что созданный ресурс агента и нажмите Создать сервис . Сервис агента создан в веб-интерфейсе KUMA и отображается в разделе Ресурсы → Активные сервисы . Теперь сервис агента необходимо установить на рабочей станции/сервере, которая будет использоваться для удаленного сбора событий Windows c других рабочих станций/серверов. В нашем примере агент KUMA устанавливается на ту же рабочую станцию, с которой предполагается сбор событий. После публикации агента скопируйте идентификатор сервиса для последующей установки сервиса (службы) агента на рабочей станции.  Установка агента KUMA Перед установкой агента KUMA убедитесь, что для рабочей станции/сервера, где предполагается установка, открыты следующие сетевые доступы: Порт TCP/7210 к Ядру KUMA. К Коллектору KUMA, предназначенного для приема и обработки событий Windows. Порт и протокол, указанные при создании Коллектора (см. Раздел Создание коллектора KUMA). Также убедитесь, что на рабочей станции/сервере, где предполагается установка агента KUMA, «резолвится» DNS-имя сервера KUMA (для распределенной инсталляции DNS-имя сервера Ядра и сервера коллектора KUMA). При необходимости добавьте соответствующие записи в файл hosts, либо создайте A-записи на DNS-сервере организации. Чтобы установить агент KUMA на устройство Windows: Скопируйте файл kuma.exe в папку на устройстве Windows. Для установки рекомендуется использовать папку C:\Users\<имя пользователя>\Desktop\KUMA. Файл kuma.exe находится внутри установщика в директории /kuma-ansible-installer/roles/kuma/files/. Запустите командную строку на устройстве Windows с правами администратора и перейдите в папку с файлом kuma.exe. Выполните следующую команду: kuma agent --core https://<полное доменное имя сервера ядра KUMA>:<порт, используемый сервером ядра KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса агента, созданного в KUMA> --user <имя пользователя, под которым будет работать агент, включая домен, в формате domain\username> --install Пример : kuma agent --core https://kuma.example.com:7210 --id XXXXX --user domain\username --install Для запуска агента требуется подтверждение лицензионного соглашения. В процессе установки вам будет предложено ознакомиться с текстом лицензионного соглашения и у вас будет возможность принять соглашение или отказаться. Если этого не произошло автоматически, вы можете воспользоваться следующей командой, чтобы ознакомиться с текстом лицензионного соглашения: kuma.exe license --show      Если вы хотите принять лицензионное соглашение, выполните команду и нажмите y : kuma.exe license Введите пароль пользователя, под которым будет работать служба агента. В процессе установки будет создана папка C:\ProgramData\Kaspersky Lab\KUMA\agent\<идентификатор агента>, в которую будет установлен сервис агента KUMA.  После установки сервис (служба) агента запускается автоматически. Сервис также настроен на перезапуск в случае сбоев. Агент можно перезапустить из веб-интерфейса KUMA, но только когда сервис активен. В противном случае сервис требуется перезапустить вручную на устройстве Windows. Далее перейдите в веб-интерфейс KUMA и убедитесь в успешности запуска агента - статус сервиса агента KUMA WMI должен измениться на ВКЛ с зеленой индикацией .  Чтобы удалить агент KUMA с устройства Windows по окончании тестирования продукта: Запустите командную строку на устройстве Windows с правами администратора и перейдите в папку с файлом kuma.exe. Выполните команду ниже: kuma.exe agent --id <идентификатор сервиса агента, созданного в KUMA> --uninstall Проверка поступления событий Windows в KUMA Для проверки, что сбор событий Windows успешно настроен перейдите в Ресурсы → Активные сервисы → выберите ранее созданный коллектор для событий Windows и нажмите Перейти к событиям . В открывшемся окне События убедитесь, что присутствуют события с устройств Windows. Настройка получения событий Windows с помощью Kaspersky Endpoint Security (KES) Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в онлайн-справке на продукт: https://support.kaspersky.ru/kuma/3.4/280730 https://support.kaspersky.com/help/KESWin/12.6/ru-RU/274395.htm Список передаваемых событий ограничен! Подробнее  Приложение. События журналов Windows, отправляемые в KUMA После выполнения настройки KES будет отправлять события с журнала с самой начальной даты (полная перечитка) В Kaspersky Endpoint Security для Windows, начиная с версии 12.6, появилась возможность отправлять события из журналов Windows в коллектор KUMA. Это позволяет получить в KUMA события из журналов Windows со всех хостов, на которых установлен Kaspersky Endpoint Security для Windows версии 12.6 и выше, без необходимости установки агентов KUMA типа  WEC или WMI , развертывания WEC -сервера  и создания групповых политик для запуска/конфигурации сервисов Windows . Для того, чтобы настроить сбор событий Windows с помощью Kaspersky Endpoint Security необходимо: иметь действующую лицензию KUMA.   использовать KSC 14.2 и выше. использовать  KES для Windows 12.6 или выше. Настройка получения событий  Windows с помощью Kaspersky Endpoint Security состоит из следующих этапов: Создание и установка коллектора  KUMA для получения событий Windows . Запрос ключа в технической поддержке  KUMA . Если в предоставленной Вам лицензии не было ключа активации компонента  Интеграции c KUMA , направьте в техническую поддержку письмо следующего содержания: «У нас приобретена лицензия KUMA и используется KES для Windows версии 12.6. Мы планируем активировать компонент Интеграции c KUMA . Просим предоставить файл ключа для активации соответствующего функционала». Новым пользователям KUMA не требуется писать запрос в техническую поддержку, поскольку новым пользователям будет предоставлено 2 ключа с лицензиями для KUMA и для активации функционала  KES для Windows . В ответ на письмо вам будет предоставлен файл ключа  Kaspersky Endpoint Security для Windows KUMA Integration Add-on . Настройка на стороне KSC и KES для Windows 12.6. Файл ключа, активирующий компонент Интеграции c KUMA , необходимо импортировать в KSC и распространить по конечным устройствам KES. Также необходимо в политике KES добавить адрес сервера коллектора KUMA и настроить сетевые параметры подключения. Проверка поступления событий  Windows в коллектор KUMA . Создание коллектора KUMA Для создания коллектора в веб-интерфейсе KUMA: Перейдите в раздел  Ресурсы и нажмите на кнопку Подключить источник . В появившемся окне мастера настройки Создание коллектора на первом шаге ( Подключение источников ) выберите   Имя коллектора   и   Тенант , к которому будет принадлежать создаваемый коллектор. На втором шаге мастера ( Транспорт ) укажите параметры коннектора для взаимодействия с подключаемым источником: Тип – tcp / udp . В данном примере выберите tcp . URL – FQDN :порт (порт, на котором коллектор будет ожидать входящие подключения. Выбирается любой из незанятых, выше 1024). В данном примере будет использоваться 5155. В поле URL можно указать только порт при инсталляции All-in-one. На третьем шаге мастера укажите нормализатор. В данном случае рекомендуется использовать «коробочный» нормализатор [OOTB] Microsoft Products via KES WIN . При отсутствии в списке нормализатора [OOTB] Microsoft Products via KES WIN выполните загрузку нормализатора из репозитория. На шаге Фильтрация событий нажмите Добавить фильтр и выберите фильтр [OOTB] Microsoft Products via KES WIN - Event filter for collector. Шаги мастера настройки с пятого по шестой являются опциональными, их можно пропустить и вернуться к настройке позднее. На седьмом шаге мастера задайте точки назначения. Для хранения событий добавьте точку назначения типа   Хранилище . В случае если предполагается также анализ потока событий правилами корреляции добавьте точку назначения типа   Коррелятор . На завершающем шаге мастера нажмите на кнопку   Создать и сохранить сервис . После чего появится строка установки сервиса, которую необходимо скопировать для дальнейшей установки. Нажмите Сохранить . После выполнения вышеуказанных действий в разделе   Ресурсы   →   Активные сервисы   появится созданный сервис коллектора. Установка коллектора KUMA Чтобы установить коллектор KUMA: Выполните подключение к  CLI  сервера, на котором планируется развертывание коллектора KUMA . Для установки сервиса коллектора в командной строке выполните команду под учетной записью root , скопированную на прошлом шаге. При необходимости добавьте используемый порт сервиса коллектора в исключения МЭ ОС и обновите параметры службы. После успешной установки сервиса его статус в веб-консоли KUMA изменится на ВКЛ с зеленой индикацией . Настройка KSC и KES Настройка Kaspersky Endpoint Security и Kaspersky Security Center состоит из следующих этапов: Установка компонента для интеграции  c KUMA . Вы можете установить компонент для интеграции с KUMA во время установки или обновления приложения, а также с помощью задачи  Изменение состава компонентов приложения (данный вариант будет использован в нашем примере). Активация компонента для интеграции c KUMA . Полученный файл ключа  Kaspersky Endpoint Security для Windows KUMA Integration Add - on , активирующий функционал отправки событий Windows в коллектор KUMA , импортируется в Kaspersky Security Center и распространяется по конечным устройствам с Kaspersky Endpoint Security . Подключение к KUMA. В политике для Kaspersky Endpoint Security добавляется адрес сервера KUMA и выполняется настройка сетевых параметров подключения. Чтобы добавить компонент для интеграции с KUMA с помощью задачи  Изменение состава компонентов приложения в Kaspersky Endpoint Security для Windows : Kaspersky Security Center Web Console Перейдите в раздел  Активы (Устройства) → Задачи. В Списке задач нажмите на кнопку Добавить . Запустится мастер создания задачи. Настройте параметры задачи: В раскрывающемся списке  Приложение выберите используемое приложение Kaspersky Endpoint Security для Windows (в нашем примере 12.8.0). В раскрывающемся списке Тип задачи выберите Изменение состава компонентов приложения . В поле Название задачи введите название создаваемой задачи. В блоке Устройства, которым будет назначена задача выберите Задать адреса устройств вручную или импортировать из списка . Нажмите на кнопку Далее . В окне Область действия задачи нажмите Добавить устройства. В окне справа Добавить устройства выберите Выбрать устройства, обнаруженные в сети Сервером администрирования. Укажите тестовое устройство или тестовую группу администрирования для добавления компонента. Нажмите Добавить и затем Далее . В окне Завершение создания задачи установите флажок Открыть окно свойств задачи после ее создания и нажмите кнопку Готово . В открывшемся окне свойств задачи перейдите на вкладку Параметры приложения и в секции Выбор компонентов для установки поставьте флажок напротив компонента Интеграция с KUMA . Если используется пароль для удаления продукта - необходимо поставить флажок напротив Использовать пароль для изменения состава компонентов приложения  и указать пользователя и пароль. Нажмите  Сохранить . Задача добавления компонента интеграции с KUMA создана. Для выполнения задачи установите флажок напротив задачи и нажмите на кнопку Запустить . # Пример для firewalld firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp|udp –permanent firewall-cmd –reload # Пример для ufw ufw allow <порт, выбранный для коллектора>/tcp|udp ufw reload Результат выполнения задачи можно посмотреть в свойствах задачи на вкладке Общие . Для завершения обновления Kaspersky Endpoint Security после добавления нового компонента нужно перезагрузить устройство. В результате на выбранных устройствах будет установлен компонент Интеграция с KUMA . Убедитесь, что компонент был успешно добавлен на устройства. Для этого в локальном интерфейсе Kaspersky Endpoint Security перейдите в раздел Безопасность . Добавление компонента для интеграции с KUMA с помощью задачи Изменение состава компонентов приложения в Консоли администрирования (MMC): https://support.kaspersky.com/help/KESWin/12.6/ru-RU/181472.htm Далее необходимо активировать компонент Интеграция с KUMA с помощью полученного файла ключа. Чтобы импортировать в Kaspersky Security Center полученный файл ключа: Kaspersky Security Center Web Console Перейдите в раздел Операции → Лицензии "Лаборатории Касперского" . Нажмите на кнопку Добавить . Появившемся окне справа выберите вариант Добавить файл ключа и нажмите Выберите файл ключа . Укажите полученный файл ключа Kaspersky Endpoint Security для Windows KUMA Integration Add - on (имя файла *. key ). В окне появится информация об импортированном ключе. Нажмите Сохранить. Файл ключа успешно импортирован в Kaspersky Security Center. Импорт файла ключа в Kaspersky Security Center с помощью консоли администрирования (MMC): https://support.kaspersky.com/help/KESWin/12.6/ru-RU/177935.htm Чтобы распространить ключ по конечным устройствам Kaspersky Endpoint Security: Kaspersky Security Center Web Console Перейдите в раздел Активы (Устройства) → Задачи. В Списке задач нажмите на кнопку Добавить . Запустится мастер создания задачи. Настройте параметры задачи: В раскрывающемся списке  Приложение выберите используемое приложение Kaspersky Endpoint Security для Windows (в нашем примере 12.8.0). В раскрывающемся списке Тип задачи выберите Добавление ключа . В поле Название задачи введите название создаваемой задачи. В блоке Устройства, которым будет назначена задача выберите Задать адреса устройств вручную или импортировать из списка . Нажмите на кнопку Далее . В окне Область действия задачи нажмите Добавить устройства . В окне справа Добавить устройства выберите Выбрать устройства, обнаруженные в сети Сервером администрирования . Укажите тестовое устройство или тестовую группу администрирования для добавления ключа. Нажмите Добавить и затем Далее . В окне Выбор лицензионного ключа укажите ранее импортированный ключ Kaspersky Endpoint Security для Windows KUMA Integration Add - on . Нажмите Далее . В окне  Информация о лицензии ознакомьтесь с информацией и нажмите Далее . В окне  Завершение создания задачи снимите флажок Открыть окно свойств задачи после ее создания  и нажмите кнопку Готово . Задача добавления ключа создана. Для выполнения задачи установите флажок напротив задачи и нажмите на кнопку  Запустить . Результат выполнения задачи можно посмотреть в свойствах задачи на вкладке Общие . В результате на выбранных устройствах будет еще один активный ключ для интеграции Kaspersky Endpoint Security с KUMA. Убедитесь, что активный ключ для интеграции с KUMA был успешно добавлен на устройства. Для этого в локальном интерфейсе Kaspersky Endpoint Security перейдите в раздел  Лицензия . Распространение ключа по конечным устройствам Kaspersky Endpoint Security с помощью консоли администрирования (MMC): https://support.kaspersky.com/help/KESWin/12.6/ru-RU/177935.htm Далее для отправки событий Windows с помощью Kaspersky Endpoint Security необходимо в политике Kaspersky Endpoint Security добавить адрес сервера KUMA и настроить сетевые параметры подключения: Kaspersky Security Center Web Console Перейдите в раздел Активы (Устройства) → Политики и профили политик. Нажмите на название используемой политики Kaspersky Endpoint Security для перехода в свойства политики. В окне свойств политики перейдите на вкладку Параметры приложения и далее в раздел Интеграция с KUMA . Нажмите на Интеграция с KUMA . В появившемся окне Интеграция с KUMA : Включите переключатель Интеграцию с KUMA . Нажмите Добавить. В окне справа укажите:    IP -адрес сервера KUMA (для распределенной инсталляции укажите IP -адрес сервера коллектора KUMA ).    Порт для подключения (см. параметры ранее созданного коллектора Раздел Создание коллектора KUMA )     Используемый Протокол (см. параметры ранее созданного коллектора Раздел Создание коллектора KUMA ).    Нажмите Сохранить . Нажмите ОК . Далее нажмите  Сохранить . Для версии KES 12.11 и выше также необходимо указать перечень журналов, из которых будет осуществляться отправка событий. Настройка производится на вкладке "Общие настройки" - "Исключения и типы объектов". Ниже приведен пример добавления журналов для MMC-консоли. Добавление журнала Зайдите в настройки политики и откройте исключения. В перечне журналов выберите галочкой интересующие, либо добавьте из через нопку "Добавить". В конце настройки проверьте, что все у всех пунктов настройки закрыты замки в политике. В результате на выбранных устройствах будет активирован компонент для интеграции Kaspersky Endpoint Security с KUMA. Убедитесь, что компонент успешно активирован, для этого в локальном интерфейсе Kaspersky Endpoint Security: П ерейдите в раздел Безопасность . Убедитесь, что индикация статуса компонента Интеграция с KUMA изменилась на зеленый . Нажмите на    и в открывшемся окне Отчеты убедитесь, что появилось событие Успешное подключение к серверу KUMA . Опционально для протокола TCP Вы можете настроить защищенное соединение с использованием протокола TLS: https://support.kaspersky.com/help/KESWin/12.6/ru-RU/274395.htm Настройка политики Kaspersky Endpoint Security для отправки событий Windows в KUMA с помощью консоли администрирования (MMC): https://support.kaspersky.com/help/KESWin/12.6/ru-RU/274395.htm Проверка поступления событий Windows в KUMA Для проверки, что сбор событий Windows с помощью Kaspersky Endpoint Security успешно настроен перейдите в   Ресурсы   →   Активные сервисы   → выберите ранее созданный коллектор для   событий Windows  и нажмите   Перейти к событиям. В открывшемся окне   События   убедитесь, что присутствуют события с   устройств Windows . Настройка tls для Windows KES  Для настройки защищенного соединения вам нужен TLS-сертифика, далее добавить его в Kaspersky Endpoint Security.  Перед настройкой убедитесь, что события поступают на коллектор без использования tls , а далее переходите к настройке  TCP + TLS : Для настройки транспорта с использованием tcp + tls в меню переходим в Ресурсы -> Активные Сервисы -> Выберите сервис коллектора, отвечающий за прием событий с KES Далее переходим в раздел транспорт и в основных настройка в параметр “Тип” ставим tcp В том же разделе переходим в “Дополнительные параметры”, в параметре “Режим TLS ” ставим значение Включено С охраняем параметры, перезагружаем коллектор. Получение сертификата Дя экспорта сертификата, который необходим для загрузки в KES в меню KUMA нажимаем в левом нижнем углу на имя учетной записи пользователя“” -> Дополнительная информация -> Microservice CA сертификат . Сертификат автоматически начнет скачиваться на компьютер После необходимо поменять расширение файла на crt для его дальнейшего импорта в KSC , иначе он не добавится core-internal-ca-ca.cert -> core-internal-ca-ca.crt Добавление TLS- сертификата в Kaspersky Endpoint Security Этап настройка в KSC : в   веб-консоли KSC в меню выбираем “Активы(Устройства)” -> “Политики и профили политик” -> Открываем политику, которая применяется на устройство Переходим во вкладку “Параметры приложения” Далее открываем “Интеграция с KUMA ” Разворачиваем “Интеграция с KUMA ” Необходимо проставить галочку в параметр “Использовать шифрование TLS ”, а также поменять/поставить в параметр “ ip -адрес” FQDN сервера коллектора KUMA (сервера KUMA в случае All - in - One ) вместо ipv 4 Далее переходим в “Настройки подключения к серверам KUMA ”. Необходимо загрузить сертификат, который мы скачивали ранее После чего придет уведомление об успешной загрузки сертификата TLS . Необходимо все сохранить и вернуться на страницу “Политики и профили политик” Автоматически политика начнет применяться ко всем устройствам, а чтобы убедиться в ее успешном применении нужно нажать флаг политики, станет доступен параметр среди действий “Результаты применения" Где можно увидеть статус применения политики на устройства Важные примечания: устройства, которые будут отправлять события в коллектор с использованием tls , должны корректно «резолвить» имя сервера c коллектором KUMA   . Для этого рекомендуется добавить A -запись сервера KUMA /сервера коллектора KUMA на DNS -серверы организации. Далее переходим в События в KUMA и проверяем наличие событий, поступающих от KES . Sysmon Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Что такое Sysmon System Monitor (Sysmon) — это инструмент мониторинга ОС от Microsoft, который входит в пакет Sysinternals Suite. Представляет собой системную службу и драйвер устройства Windows, которые после установки постоянно работают в системе, в том числе после перезагрузки. Типы событий, создаваемые Sysmon: https://learn.microsoft.com/ru-ru/sysinternals/downloads/sysmon#event-id-1-process-creation Sysmon предоставляет подробную информацию о создании процессов, сетевых подключениях и изменениях времени создания файлов. За счет сбора событий Sysmon средствами сбора событий Windows (Windows Event Collection) или SIEM-системами и последующего их анализа,  можно выявлять вредоносную или аномальную активность и понять, как злоумышленники и вредоносное ПО действуют в вашей сети. Служба работает как защищенный процесс, что блокирует широкий спектр взаимодействий из пользовательского режима. Sysmon не анализирует генерируемые им события и не пытается скрыть свое присутствие от злоумышленников. Описание схемы работы Схема работы абсолютно идентична схеме работы, приведенной в разделе Описание схемы работы с Windows Event Collector статьи MS WEC . Установка и настройка Sysmon Sysmon использует файл конфигурации, который содержит набор правил (фильтров), указывающих Sysmon какие именно события операционной системы (создание процессов, сетевые подключения, изменение файлов и т.д.) нужно регистрировать в журнале. В статье используется готовый шаблон файла конфигурации из репозитория - https://github.com/SwiftOnSecurity/sysmon-config . По умолчанию в шаблоне включены достаточно "шумные" правила для мониторинга DNS-запросов. Если их мониторинг не требуется просто удалите эту секцую или закомментируйте правила. На отдельной рабочей станции/сервере Выполните загрузку Sysmon.exe с официального сайта  Sysinternals : Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "<Путь для загрузки файла>\<Имя файла>" Распакуйте архив средствами проводника Windows или с помощью PowerShell-команды: Expand-Archive -Path "<Путь, куда был загружен файл>\<Имя файла>" -DestinationPath "<Путь для загрузки файла>\<Имя файла>" -Force Загрузите готовый конфигурационный  файл Sysmon. Можно использовать конфигурационные файлы из других репозиториев, например, отсюда или создать собственный (подробнее см. здесь ): Invoke-WebRequest -Uri "https://github.com/SwiftOnSecurity/sysmon-config/blob/master/sysmonconfig-export.xml" -OutFile "<Путь для загрузки файла>\<Имя файла>" Запустите PowerShell с правами администратора и выполните установку Sysmon с ранее загруженной (или собственной) конфигурацией: <Путь до файла>\Sysmon.exe -accepteula -i "<Путь до файла конфигурации>\<Имя файла конфигурации>" Проветье статус службы Sysmon: Get-Service -Name Sysmon Нажмите кнопку Win , введите eventvwr.msc и запустите Просмотр событий (Event Viewer) от имени администратора. Перейдите в  Журналы приложений и служб → Microsoft →   Windows →   Sysmon →   Operational . Если в появившемся окне Operational отображаются события Sysmon, значит cлужба Sysmon установлена и настроена корректно.   На группе рабочих станций/серверов средствами GPO При наличии опыта администрирования  Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ. Ниже описан один из вариантов установки и настройки Sysmon. Выполните загрузку Sysmon.exe с официального сайта  Sysinternals : Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "<Путь для загрузки файла>\<Имя файла>" Распакуйте архив средствами проводника Windows или с помощью PowerShell-команды: Expand-Archive -Path "<Путь, куда был загружен файл>\<Имя файла>" -DestinationPath "<Путь для загрузки файла>\<Имя файла>" -Force Загрузите готовый конфигурационный  файл Sysmon. Можно использовать конфигурационные файлы из других репозиториев, например, отсюда или создать собственный (подробнее см. здесь ): Invoke-WebRequest -Uri "https://github.com/SwiftOnSecurity/sysmon-config/blob/master/sysmonconfig-export.xml" -OutFile "<Путь для загрузки файла>\<Имя файла>" На контроллере домена создайте папку sysmon  по пути \\<Имя контроллера домена>\SYSVOL\<Название домена>\scripts\ . Почему SYSVOL? Репликация и доступность: Папка SYSVOL автоматически реплицируется между всеми контроллерами домена (DC). Это означает, что файлы Sysmon будут доступны с любого контроллера домена по пути \\\SYSVOL\\scripts\sysmon\. Таким образом обеспечивается высокая доступность исполняемого файла Sysmon.exe и файла конфигурации. Гарантированный доступ с компьютеров домена: По умолчанию у всех компьютеров в домене есть право на чтение из SYSVOL. Вам не потребуется вручную настраивать права NTFS или общие ресурсы (Network Shares). Безопасность: Поскольку запись в SYSVOL по умолчанию разрешена только администраторам домена, риск случайного или злонамеренного изменения скриптов или файлов Sysmon посторонними лицами минимален. Скопируйте файл Sysmon.exe и файл конфигурации sysmonconfig-export.xml на контроллер домена в \\<Имя контроллера домена>\SYSVOL\<Название домена>\scripts\sysmon. Создайте скрипт установки deploy_sysmon.cmd  (укажите актуальное имя домена в значении переменной SYSMON_NETWORK_PATH ): @echo off setlocal EnableDelayedExpansion rem --- Проверка установлен ли уже Sysmon --- sc query Sysmon >nul 2>&1 if !ERRORLEVEL! EQU 0 ( echo [INFO] Sysmon is already installed. Exiting. goto :clean_exit ) rem --- Пути --- set "SYSMON_NETWORK_PATH=\\\SYSVOL\\scripts\sysmon" set "CONFIG_FILE=%SYSMON_NETWORK_PATH%\sysmonconfig-export.xml" set "SYSMON_EXE=%SYSMON_NETWORK_PATH%\Sysmon.exe" rem --- Локальный путь для копирования --- set "SYSMON_LOCAL_DIR=C:\Windows\Temp\SysmonDeploy" set "SYSMON_LOCAL_EXE=%SYSMON_LOCAL_DIR%\Sysmon.exe" set "CONFIG_LOCAL_FILE=%SYSMON_LOCAL_DIR%\sysmonconfig-export.xml" rem --- Создание локальной папки --- if not exist "%SYSMON_LOCAL_DIR%" mkdir "%SYSMON_LOCAL_DIR%" rem --- Копирование файлов с контроллера домена в локальную папку --- echo Copying files from SYSVOL... copy /Y "%SYSMON_EXE%" "%SYSMON_LOCAL_DIR%\" >nul copy /Y "%CONFIG_FILE%" "%SYSMON_LOCAL_DIR%\" >nul rem --- Установка Sysmon --- echo [INFO] Installing Sysmon... "%SYSMON_LOCAL_EXE%" -i "%CONFIG_LOCAL_FILE%" -accepteula rem --- Очистка временных файлов --- rd /S /Q "%SYSMON_LOCAL_DIR%" >nul 2>&1 :clean_exit endlocal echo Sysmon deployment task completed. Вместо использования имени конкретного контроллера домена в скрипте используется полное имя домена. Это обеспечивает отказоустойчивость: если "вернувшийся" в запросе контроллер домена будет недоступен, устройства автоматически обратятся к другому контроллеру домена за файлами. GPO можно применять к группе компьютеров, к OU, к сайт или всему домену. Первоначально рекомендуется выполнить развертывание службы Sysmon на нескольких некритичных рабочих станциях и далее после успешного тестирования постепенно масштабировать GPO на другие группы компьютеров и/или OU. В нашем примере будет использоваться группа компьютеров - создайте группу компьютеров средствами Active Directory – пользователи и компьютеры , задайте имя группе, например, KUMA Sysmon . Добавьте в данную группу несколько некритичных рабочих станций, на которых предполагается развертывание службы Sysmon. Для того, чтобы изменения вступили в силу (в данном случае членство в новой группе), выполните перезагрузку устройства. Альтернативным вариантом может быть перевыпуск Kerberos-тикетов для устройства с помощью klist.exe.   Проверить, что устройство стало членом группы можно с помощью команды: gpresult /r /scope:computer На контроллере домена запустите оснастку  Управление групповой политикой : нажмите Win + R → gpmc.msc. Создайте новый объект групповой политики, например, Deploy Sysmon:  ПКМ Объекты групповой политики → Создать → введите в качестве имени объекта  Deploy Sysmon. Далее выберите созданный объект групповой политики Deploy Sysmon и нажмите Изменить. Перейдите в Конфигурация компьютера → Политики → Конфигурация Windows → Сценарии (Запуск/Завершение) → Автозагрузка (Computer Configuration → Policies → Windows Settings → Scripts (Startup/Shutdown) → Startup) Нажмите Добавить и в появившемся окне Добавление сценария нажмите Обзор. В окне Проводника  в папку \\<Наименование домена>\SysVol\<Наименование домена>\Policies\\Machine\Scripts\Startup скопируйте ранее созданный скрипт deploy_sysmon.cmd , далее выберите скрипт и нажмите Открыть . Нажмите ОК . В окне Свойства: Автозагрузка нажмите ОК . Таким образом, скрипт, устанавливающий службу Sysmon будет выполняться при запуске ОС. Далее вернитесь в окно Управление групповой политикой → выберите объект групповой политики Deploy Sysmon → в окне справа Фильтры безопасности удалите группу Прошедшие проверку и добавьте группу KUMA Sysmon. Нажмите ПКМ на домен и выберите Связать существующий объект групповой политики → выберите KUMA Sysmon и нажмите ОК.  Итоговый вид политики должен выглядеть следующим образом (см. скриншот).  Для того, чтобы скрипт установки Sysmon из новой GPO был применен на рабочих станциях, необходимо перезагрузить устройства и выполнить вход под УЗ пользователя. Для проверки, что GPO была успешно применена и Sysmon был установлен, на одном из тестовых устройств: Проверьте статус службы Sysmon: Get-Service -Name Sysmon Нажмите кнопку Win , введите eventvwr.msc и запустите Просмотр событий (Event Viewer) от имени администратора. Перейдите в Журналы приложений и служб → Microsoft →   Windows →   Sysmon →   Operational . Если в появившемся окне Operational отображаются события Sysmon, значит cлужба Sysmon установлена и настроена корректно.   Настройка WEC-сервера Рекомендуемые системные требования для WEC-сервера Best Practice от MS Настройка службы Windows Event Collector (WEC) Если служба Windows Event Collector (WEC) еще не настроена см. раздел Настройка службы Windows Event Collector (WEC) Настройка подписки для событий Sysmon на WEC-сервере Чтобы настроить подписку для событий Sysmon на WEC-сервере: Нажмите кнопку Win , введите  eventvwr.msc  и запустите  Просмотр событий  от имени администратора. Выберите Подписки → правой кнопкой мыши  Создать подписку →  Укажите имя подписки, например, KUMA Sysmon и тип подписки Инициировано исходным компьютером. Выберите отдельные компьютеры или группу компьютеров, на которых установлен Sysmon и события которых требуется собирать. В нашем примере – это группа компьютеров KUMA Sysmon: нажмите Выбрать группы компьютеров → Добавить доменный компьютер → в поле Введите имена выбираемых объектов  укажите ранее созданную группу компьютеров и нажмите  ОК . Если предполагается сбор событий с контроллера домена, в таком случае, контроллер домена можно добавить как отдельный доменный компьютер . Задайте собираемые события: Выбрать события →  перейдите на вкладку XML и установите флажок Изменить запрос вручную . Вставьте в поле следующий фильтр событий: Нажмите ОК . Далее в окне Свойства подписки нажмите Дополнительно и для параметра  Оптимизация доставки событий укажите Уменьшенная задержка . Нажмите ОК. Настройка WinRM и подписки на источниках событий Для отдельной рабочей станции/сервера Если WinRM и подписка на источниках событий еще не настроены см. раздел Настройка WinRM и подписки на источниках событий (Для отдельной рабочей станции/сервера) Для группы рабочих станций/серверов Если WinRM и подписка на источниках событий еще не настроены см. раздел Настройка WinRM и подписки на источниках событий (Для группы рабочих станций/серверов). В качестве объекта групповой политики используйте  Deploy Sysmon . Проверка поступления событий Убедитесь, что на WEC-сервер поступают события Sysmon с рабочих станций/серверов: На WEC-сервере нажмите кнопку Win , введите eventvwr.msc и запустите Просмотр событий от имени администратора. Перейдите в Журналы Windows → Перенаправленные события (Forwarded Events) . В панели справа выберите Фильтр текущего журнала. В окне Фильтровать текущий журнал в поле Источники событий укажите Microsoft-Windows-Sysmon  и нажмите ОК . Если в окне  Перенаправленные события (Forwarded Events) отображаются события Sysmon, значит подписка работает корректно. Для 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)" В случае если от источников не поступают события Sysmon проверьте на WEC-сервере в журнале 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 на WEC-сервере и настроили сервис коллектор для сбора событий Windows (см. статью  MS WEC ), в таком случае дополнительных действий не требуется и можно переходить к шагу Проверка поступления событий Windows в KUMA. В случае если агент KUMA и сервис коллектора для событий Windows ранее не настраивались - см. раздел Настройка коллектора и агента KUMA . Проверка поступления событий Windows в KUMA Для проверки, что сбор событий Sysmon успешно настроен перейдите в Ресурсы → Активные сервисы → выберите коллектор для событий Windows/Sysmon и нажмите Перейти к событиям . 2. В открывшемся окне События  добавьте в поисковый запрос условие DeviceProduct = 'Sysmon' и убедитесь, что события Sysmon доступны. Полезные ссылки Статья MS о Sysmon - https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon Шаблон файла конфигурации Sysmon - https://github.com/SwiftOnSecurity/sysmon-config Unix Настройка AuditD на Unix системах Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная справка: https://support.kaspersky.ru/help/KUMA/3.4/ru-RU/239849.htm   Архитектура Auditd Настройка AuditD Для начала необходимо проврить установлена нужная служба auditd, посмотрим активные правила: auditctl -l В случае наличия подобной ошибки: Необходимо установить следующие пакеты:  apt-get install auditd audispd-plugins Либо (если RHEL подобные ОС):  yum install audit audispd-plugins На GitHub'е доступен community-скрипт для автоматической настройки auditd и отправки событий с Linux-хостов с помощью rsyslog: https://github.com/KUMA-Community/kuma_auditd Рекомендуем использовать следующие правила для аудита: wget -O audit.rules https://raw.githubusercontent.com/Neo23x0/auditd/master/audit.rules Загрузить файл с правилами аудита с портала box.kaspersky.com -  тут . Другие правила аудита можно найти в этой статье - https://kb.kuma-community.ru/link/14#bkmrk-linux   Рекомендуем добавить записи в конец файла  audit.rules , для быстрого добавления используйте команду ниже (после выполните systemctl restart auditd.service ): cat << EOF >> /etc/audit/rules.d/audit.rules # root authorized_keys -w /root/.ssh/authorized_keys -p wa -k rootkey # motd audit -w /etc/update-motd.d/ -p wa -k motd # udev audit -w /etc/udev/rules.d/ -p wa -k udev # xdg audit -w /etc/xdg/autostart/ -p wa -k xdg -w /usr/share/autostart/ -p wa -k xdg # Package Manager (APT/YUM/DNF) -w /etc/yum/pluginconf.d/ -p wa -k package_man -w /etc/apt/apt.conf.d/ -p wa -k package_man -w /etc/dnf/plugins/dnfcon.conf -p wa -k package_man # exta systemd -w /usr/lib/systemd/ -p wa -k systemd -w /lib/systemd/ -p wa -k systemd -w /usr/local/lib/systemd/ -p wa -k systemd -w /usr/local/share/systemd/user -p wa -k systemd_user -w /usr/share/systemd/user -p wa -k systemd_user # setcap audit -w /usr/sbin/setcap -p x -k setcap # rc audit -w /etc/rc.local -p wa -k rclocal ## extra Shell/profile configurations -w /etc/bash.bashrc -p wa -k shell_profiles -w /etc/bash.bash_logout -p wa -k shell_profiles -w /root/.profile -p wa -k shell_profiles -w /root/.bashrc -p wa -k shell_profiles -w /root/.bash_logout -p wa -k shell_profiles -w /root/.bash_profile -p wa -k shell_profiles -w /root/.bash_login -p wa -k shell_profiles # extra search files -w /usr/bin/find -p x -k T1083_File_And_DIrectory_Discovery ## Kernel Related Events -w /usr/sbin/modprobe -p x -k T1547_Boot_or_Logon_Autostart_Execution -w /usr/sbin/insmod -p x -k T1547_Boot_or_Logon_Autostart_Execution -w /usr/sbin/lsmod -p x -k T1547_Boot_or_Logon_Autostart_Execution -w /usr/sbin/rmmod -p x -k T1547_Boot_or_Logon_Autostart_Execution -w /usr/sbin/modinfo -p x -k T1547_Boot_or_Logon_Autostart_Execution -w /etc/modprobe.conf -p wa -k T1547.006_6 -w /etc/sysctl.conf -p wa -k sysctl # extra file manipulation -w /usr/bin/ftp -p x -k T1105_remote_file_copy -w /usr/bin/sftp -p x -k T1105_remote_file_copy -w /usr/bin/rsync -p x -k T1105_remote_file_copy -w /usr/bin/cp -p x -k T1005_Data_from_Local_System -w /usr/bin/dd -p x -k T1005_Data_from_Local_System -a always,exit -F arch=b32 -S execve -S execveat -F exe=/usr/bin/shred -F -k T1070.004_1 -a always,exit -F arch=b64 -S execve -S execveat -F exe=/usr/bin/shred -F -k T1070.004_2 # split cmd audit -w /usr/bin/split -p x -k split EOF Другие  правила аудита и полезные материалы по AuditD можно найти - тут . Далее нужно переместить правила в директорию по умолчанию и применить правила перезапуском сервиса: cp audit.rules /etc/audit/rules.d/ systemctl restart auditd.service systemctl enable auditd.service В случае ошибки рестарта службы auditd (Failed to restart auditd.service) На RHEL подобных ОС, может встретиться следующая ошибка: Failed to restart auditd.service: Operation refused, unit auditd.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status auditd.service' for details. nano /usr/lib/systemd/system/auditd.service Измените параметр RefuseManualStop на: RefuseManualStop=no Затем обновите параметры службы: systemctl daemon-reload Для проверки убедитесь что следующий лог наполняется информацией: tail -f /var/log/audit/audit.log Рекомендуемый парсер (без агрегации/склейки событий) для правил корреляции Community - [2024-09-23] Unix AuditD (REGEX) (из Community-Pack) Для использования агрегации логов используйте коробочный парсер [OOTB] Linux auditd syslog for KUMA 3.2  c включенным переключателем "auditd", который доступен в KUMA 3.2, подробнее: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/220739.htm Для использования агрегации логов с помощью агента используйте коробочный парсер  [OOTB] Linux auditd file for KUMA 3.2  c включенным переключателем "auditd",  подробнее: https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ekstra-vozmoznosti-agenta-kuma Известные проблемы Бывают случаи, когда из-за ротации самого себя auditd (собственная ротация) падает в статусе сервиса: Sep 24 00:11:42 example.org auditd[756]: Audit daemon rotating log files В таком статусе лог файл не пополняется, рекомендуется использовать системную ротацию logrotate. Сначала отключается собственная ротация auditd, правим конфиг: nano /etc/audit/auditd.conf Правим занчение (выделено жирным): max_log_file_action = ignore Затем настраивается системная ротация logrotate. touch /etc/logrotate.d/auditd chmod 644 /etc/logrotate.d/auditd; chown root:root /etc/logrotate.d/auditd nano /etc/logrotate.d/auditd Пишем в файле auditd: # daily rotation keep last 2 days and compress old /var/log/audit/audit.log { daily missingok notifempty sharedscripts rotate 2 compress delaycompress postrotate /usr/bin/systemctl kill -s USR1 auditd.service >/dev/null 2>&1 || true endscript } Перезапускаем службы logrotate и auditd: systemctl restart logrotate.service; systemctl restart auditd.service Классический сбор событий auditd с помощью Rsyslog Проведите настроку по этой инструкции: https://kb.kuma-community.ru/books/podkliucenie-istocnikov/page/sbor-sobytii-auditd-s-pomoshhiu-rsyslog   Удаленная отправка логов auditd Не поддерживается коробочным парсером [OOTB] Linux auditd syslog for KUMA 3.2 Иногда  если место на сервере ограничено и хранить объемный лог audutd нет возможности , для этого можно настроить отправку логов сразу на удаленный сервер, для этого будем использовать плагин audispd-plugins, который мы загружали выше. Отключим локальное ведение логов аудита в файле /etc/audit/auditd.conf выставляем значение write_logs = no : root@kuma# nano /etc/audit/auditd.conf local_events = yes write_logs = no name_format = HOSTNAME Не прописывайте name_format = HOSTNAME если планируете использовать коробочный парсер [OOTB] Linux auditd syslog for KUMA 3.2 Теперь нам нужно исправить файл по примеру ниже для отправки логов на удаленный сервер: root@kuma# nano /etc/audit/plugins.d/au-remote.conf active = yes direction = out path = /sbin/audisp-remote type = always #args = format = string Далее нужно отредактировать файл /etc/audit/audisp-remote.conf следующим образом: root@kuma# nano /etc/audit/audisp-remote.conf # # This file controls the configuration of the audit remote # logging subsystem, audisp-remote. # remote_server = 192.168.0.100 port = 16666 transport = tcp queue_file = /var/spool/audit/remote.log mode = immediate queue_depth = 10240 format = ascii network_retry_time = 2 max_tries_per_record = 3 max_time_per_record = 5 heartbeat_timeout = 0 network_failure_action = stop disk_low_action = ignore disk_full_action = warn_once disk_error_action = warn_once remote_ending_action = reconnect generic_error_action = syslog generic_warning_action = syslog queue_error_action = stop overflow_action = syslog startup_failure_action = warn_once_continue ##krb5_principal = ##krb5_client_name = auditd ##krb5_key_file = /etc/audisp/audisp-remote.key Теперь нужно перезапустить сервис auditd для применения обновленных конфигураций : systemctl restart auditd.service Сырые события будут без заголовка syslog, парсер Unix из комьюнити-пака обработает корректно такие логи: node=kuma-aio.local type=PROCTITLE msg=audit(1704808440.087:50482): proctitle=2F7362696E2F617564697463746C002D52002F6574632F61756469742F61756469742E72756C6573 Сбор событий auditd с помощью Syslog-ng Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Создание коллектора KUMA Для создания коллектора в веб-интерфейсе KUMA: Перейдите в раздел Ресурсы и нажмите на кнопку Подключить источник . В появившемся окне мастера настройки Создание коллектора на первом шаге ( Подключение источников ) выберите Имя коллектора и Тенант , к которому будет принадлежать создаваемый коллектор. На втором шаге мастера ( Транспорт ) укажите параметры коннектора для взаимодействия с подключаемым источником: Тип – tcp/udp. В данном примере tcp. URL – FQDN:порт (порт, на котором коллектор будет ожидать входящие подключения. Выбирается любой из незанятых, выше 1024). В данном примере 5152. Auditd – включено В поле URL можно указать только порт при инсталляции All-in-one. Начиная с версии 3.2, в KUMA появился переключатель Auditd, который позволяет группировать полученные от коннектора строки событий auditd в одно событие auditd. На третьем шаге мастера укажите нормализатор. В данном случае рекомендуется использовать «коробочный» нормализатор для событий auditd Linux [OOTB] Linux auditd syslog for KUMA 3.2 . Шаги мастера настройки с четвертого по шестой являются опциональными, их можно пропустить и вернуться к настройке позднее. На седьмом шаге мастера задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище . В случае если предполагается также анализ потока событий правилами корреляции добавьте точку назначения типа Коррелятор . На завершающем шаге мастера нажмите на кнопку Создать и сохранить сервис . После чего появится строка установки сервиса, которую необходимо скопировать для дальнейшей установки. Нажмите Сохранить . После выполнения вышеуказанных действий в разделе Ресурсы → Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Чтобы установить коллектор KUMA: Выполните подключение к CLI сервера, на котором планируется развертывание коллектора KUMA. Для установки сервиса коллектора в командной строке выполните команду под учетной записью root, скопированную на прошлом шаге. При необходимости добавьте используемый порт сервиса коллектора в исключения МЭ ОС и обновите параметры службы. Пример для firewalld firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp|udp –permanent firewall-cmd –reload Пример для ufw ufw allow <порт, выбранный для коллектора>/tcp|udp ufw reload После успешной установки сервиса его статус в веб-консоли KUMA изменится на ВКЛ с зеленой индикацией. Настройка источника событий Для передачи событий c рабочей станции/сервера в коллектор KUMA будет использоваться сервис syslog-ng. При разработке статьи использовалась версия 3.19 syslog-ng. На рабочей станции/сервере Linux убедитесь, что сервис syslog-ng уже установлен в ОС: systemctl status syslog-ng.service Если сервис syslog-ng не установлен на сервере, установите его, выполнив следующие команды (пример для Astra Linux и Ubuntu): apt install syslog-ng systemctl enable syslog-ng.service systemctl start syslog-ng.service Далее в папке /etc/syslog-ng/conf.d/ создайте файл конфигурации (например, 30-kuma-tcp.conf или 30-kuma-udp.conf ) со следующим содержанием в зависимости от используемого протокола: Для отправки событий по протоколу TCP # syslog-ng audit forwarding to KUMA (TCP) # Version: 1 # Date: 26.01.2026 # Purpose: Forward auditd logs without parsing, loss-minimized source s_audit { file("/var/log/audit/audit.log" flags(no-parse) # Читаем audit.log без парсинга (flags(no-parse)), чтобы "не ломать" формат auditd. follow-freq(1) tags("tag_audit_log") persist-name("kuma_audit_source")); # Необходим для сохранения состояния источника между рестартами syslog-ng. }; template t_audit_format { template("<134>${ISODATE} ${HOST} auditd ${MSG}\n"); # задан вручную, т.к. при flags(no-parse) ${PRI} не извлекается из события. Тег auditd задан руками, иначе будет дефолтное 0d. template_escape(no); }; destination d_kuma { tcp("" port(<Порт коллектора KUMA>) template(t_audit_format) disk-buffer( mem-buf-size(10000) # Размер буфера в RAM, в количестве сообщений. Пока есть место — ничего не пишется на диск. Можно увеличить при большом потоке событий. disk-buf-size(1G) # Максимальный размер буфера на диске. Когда RAM-буфер будет заполнен, запись продолжится на диск. Можно увеличить при большом потоке событий. reliable(yes) # Для гарантированной доставки. События не теряются при рестаре syslog-ng, проблем с сетью, перезапуске коллектора. ) ); }; filter f_audit_kuma { tags("tag_audit_log"); }; log { source(s_audit); filter(f_audit_kuma); destination(d_kuma); }; Для отправки событий по протоколу UDP # syslog-ng audit forwarding to KUMA (UDP) # Version: 1 # Date: 26.01.2026 # Purpose: Forward auditd logs without parsing, loss-minimized source s_audit { file("/var/log/audit/audit.log" flags(no-parse) # Читаем audit.log без парсинга (flags(no-parse)), чтобы "не ломать" формат auditd. follow-freq(1) tags("tag_audit_log") persist-name("kuma_audit_source")); # Необходим для сохранения состояния источника между рестартами syslog-ng. }; template t_audit_format { template("<134>${ISODATE} ${HOST} auditd ${MSG}\n"); # задан вручную, т.к. при flags(no-parse) ${PRI} не извлекается из события. Тег auditd задан руками, иначе будет дефолтное 0d. template_escape(no); }; destination d_kuma { udp("" port(<Порт коллектора KUMA>) template(t_audit_format) disk-buffer( mem-buf-length(10000) # Размер буфера в RAM, в количестве сообщений. Пока есть место — ничего не пишется на диск. Можно увеличить при большом потоке событий. disk-buf-size(1G) # Максимальный размер буфера на диске. Когда RAM-буфер будет заполнен, запись продолжится на диск. Можно увеличить при большом потоке событий. ) ); }; filter f_audit_kuma { tags("tag_audit_log"); }; log { source(s_audit); filter(f_audit_kuma); destination(d_kuma); }; Далее выполните проверку конфигурации syslog-ng: syslog-ng -s Если ошибки при проверке конфигурации отсутствуют перезапустите сервис syslog-ng, выполнив следующую команду: systemctl restart syslog-ng Рабочая станция/сервер Linux настроены. События передаются в коллектор KUMA. Проверка поступления событий Linux в KUMA Для проверки, что сбор событий с устройств Linux успешно настроен перейдите в Ресурсы → Активные сервисы → выберите ранее созданный коллектор для Linux и нажмите Перейти к событиям . В открывшемся окне События убедитесь, что присутствуют события с устройств Linux.  Приложение А. Отправка событий с использованием TLS (без валидации сертификата коллектора) Предварительно рекомендуется протестировать отправку событий auditd без использования шифрования - см. раздел Настройка источника событий . Для передачи событий auditd c рабочей станции/сервера в коллектор KUMA c использованием TLS без валидации сертификата: В веб-интерфейсе KUMA: Перейдите в раздел Ресурсы → Активные сервисы  и выберите ранее созданный коллектор для приема и обработки событий auditd.  В появившемся окне Редактирование коллектора перейдите на вкладку Дополнительные параметры  и в параметре Режим TLS  выберите Включено . Перейдите на шаг Проверка параметров и нажмите Сохранить и перезапустить сервисы . Нажмите Сохранить . На рабочей станции/сервере Linux: В папке /etc/syslog-ng/conf.d/ создайте файл конфигурации (например, 30-kuma-tcp-tls-wo-cert-validation.conf ) со следующим содержанием: # syslog-ng audit forwarding to KUMA (TCP with TLS without certificate validation) # Version: 1 # Date: 26.01.2026 # Purpose: Forward auditd logs without parsing, loss-minimized source s_audit { file("/var/log/audit/audit.log" flags(no-parse) # Читаем audit.log без парсинга (flags(no-parse)), чтобы "не ломать" формат auditd. follow-freq(1) tags("tag_audit_log") persist-name("kuma_audit_source")); # Необходим для сохранения состояния источника между рестартами syslog-ng. }; template t_audit_format { template("<134>${ISODATE} ${HOST} auditd ${MSG}\n"); # задан вручную, т.к. при flags(no-parse) ${PRI} не извлекается из события. Тег auditd задан руками, иначе будет дефолтное 0d. template_escape(no); }; destination d_kuma { tcp("" port(<Порт коллектора KUMA>) template(t_audit_format) disk-buffer( mem-buf-size(10000) # Размер буфера в RAM, в количестве сообщений. Пока есть место — ничего не пишется на диск. Можно увеличить при большом потоке событий. disk-buf-size(1G) # Максимальный размер буфера на диске. Когда RAM-буфер будет заполнен, запись продолжится на диск. Можно увеличить при большом потоке событий. reliable(yes) # Для гарантированной доставки. События не теряются при рестаре syslog-ng, проблем с сетью, перезапуске коллектора. ) tls(peer-verify(required-untrusted)) ); }; filter f_audit_kuma { tags("tag_audit_log"); }; log { source(s_audit); filter(f_audit_kuma); destination(d_kuma); }; Удалите или переименуйте ранее созданный файл конфигурации для отправки событий по TCP, например, 30-kuma-tcp.conf .backup Далее выполните проверку конфигурации syslog-ng: syslog-ng -s Если ошибки при проверке конфигурации отсутствуют перезапустите сервис syslog-ng, выполнив следующую команду: systemctl restart syslog-ng Рабочая станция/сервер Linux настроены. События передаются в коллектор KUMA с использованием TLS. Приложение Б. Отправка событий с использованием TLS (c валидацией сертификата коллектора) Предварительно рекомендуется протестировать отправку событий auditd без использования шифрования - см. раздел Настройка источника событий . Перед выполнением шагов по настройке создайте PFX-файл, содержащий закрытый ключ и сертификат, для использования в коллекторе auditd. Важно , чтобы в поле CN или subject_alt_name сертификата были указаны FQDN сервера коллектора или его IP-адрес. Для передачи событий auditd c рабочей станции/сервера в коллектор KUMA c использованием TLS с валидацией сертификата: В веб-интерфейсе KUMA: Перейдите в раздел Ресурсы → Активные сервисы  и выберите ранее созданный коллектор для приема и обработки событий auditd.  В появившемся окне Редактирование коллектора перейдите на вкладку Дополнительные параметры : В параметре Режим TLS  выберите Нестандартный PFX . В параметре Нестандартный PFX  нажмите Создать . В появившемся окне Создание секрета укажите: Название секрета, например, [DEMO] Auditd Collector Certificate Файл PKCS - выберите ранее созданный для коллектора auditd PFX-файл. Введите Пароль PFX-файла Нажмите Создать . Перейдите на шаг Проверка параметров и нажмите Сохранить и перезапустить сервисы . Нажмите Сохранить . На рабочей станции/сервере Linux: Загрузите в папку /etc/syslog-ng/cert  сертификат удостоверяющего центра (CA), который выдал сертификат для коллектора auditd. Перейдите в папку /etc/syslog-ng/cert и выполните команду: openssl x509 -noout -hash -in <Имя CA-сертификата>.pem Результатом выполнения команды будет хэш (например, e1442ae8) — последовательность символов, сгенерированная на основе Distinguished Name сертификата. Выполните следующую команду, чтобы создать символическую ссылку на сертификат, используя хэш, полученный на предыдущем шаге, и добавьте суффикс  .0 : ln -s <Имя CA-сертификата>.pem <Хэш>.0 В результате папка /etc/syslog-ng/cert должна содержать CA-сертификат и символическую ссылку: Далее в папке /etc/syslog-ng/conf.d/ создайте файл конфигурации (например, 30-kuma-tls-validation.conf ) со следующим содержанием: # syslog-ng audit forwarding to KUMA (TCP with TLS and certificate validation) # Version: 1 # Date: 10.02.2026 # Purpose: Forward auditd logs without parsing, loss-minimized source s_audit { file("/var/log/audit/audit.log" flags(no-parse) # Читаем audit.log без парсинга (flags(no-parse)), чтобы "не ломать" формат auditd. follow-freq(1) tags("tag_audit_log") persist-name("kuma_audit_source")); # Необходим для сохранения состояния источника между рестартами syslog-ng. }; template t_audit_format { template("<134>${ISODATE} ${HOST} auditd ${MSG}\n"); # задан вручную, т.к. при flags(no-parse) ${PRI} не извлекается из события. Тег auditd задан руками, иначе будет дефолтное 0d. template_escape(no); }; destination d_kuma { network("" port(<Порт коллектора KUMA>) template(t_audit_format) disk-buffer( mem-buf-size(10000) # Размер буфера в RAM, в количестве сообщений. Пока есть место — ничего не пишется на диск. Можно увеличить при большом потоке событий. disk-buf-size(1G) # Максимальный размер буфера на диске. Когда RAM-буфер будет заполнен, запись продолжится на диск. Можно увеличить при большом потоке событий. reliable(yes) # Для гарантированной доставки. События не теряются при рестаре syslog-ng, проблем с сетью, перезапуске коллектора. ) transport("tls") tls( ca_dir("/etc/syslog-ng/cert/") peer-verify(required-trusted) ) ); }; filter f_audit_kuma { tags("tag_audit_log"); }; log { source(s_audit); filter(f_audit_kuma); destination(d_kuma); }; Удалите или переименуйте ранее созданный файл конфигурации для отправки событий по TCP, например, 30-kuma-tcp.conf .backup Далее выполните проверку конфигурации syslog-ng: syslog-ng -s Если ошибки при проверке конфигурации отсутствуют перезапустите сервис syslog-ng, выполнив следующую команду: systemctl restart syslog-ng Рабочая станция/сервер Linux настроены. События передаются в коллектор KUMA с использованием TLS и валидацией сертификата. Справочные материалы https://syslog-ng.github.io/admin-guide/README https://syslog-ng.github.io/admin-guide/100_TLS-encrypted_message_transfer/001_Encrypting_log_messages_with_TLS/000_Configuring_TLS_client Сбор событий AuditD с помощью Rsyslog Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/239760.htm Создание коллектора KUMA Для создания коллектора KUMA необходимо в веб-консоли KUMA перейти на вкладку Ресурсы – Коллекторы и нажать на кнопку Добавить коллектор . Также можно на вкладке Ресурсы выбрать пункт Подключить источник . В обоих случая откроется мастер подключения источников событий. На первом шаге мастера необходимо выбрать Тенант , которому будет принадлежать коллектор и также задать Имя коллектора. На втором шаге мастера необходимо выбрать тип подключения udp или tcp и указать порт , на котором коллектор будет ожидать входящие подключения. В данном примере выбран UDP/5144. На третьем шаге мастера необходимо выбрать предустановленный нормализатор [OOTB] Linux Audit and iptables Syslog (либо парсер AuditD из PreSales Pack) . В случае отсутствия указанного нормализатора, обратитесь к своему менеджеру для его получения. Шаги мастера с четвертого по шестой можно пропустить, либо заполнить позднее по своему усмотрению. На седьмом шаге мастера необходимо указать точки назначения типа Хранилище , если требуется сохранение событий в БД и типа Коррелятор , если требуется корреляция событий. На последнем шаге мастера необходимо нажать на кнопку Сохранить и создать сервис , после чего скопировать появившуюся команду для дальнейшей установки сервиса коллектора. В результате на вкладке  Ресурсы – Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Для установки сервиса коллектора необходимо подключиться к консоли сервера коллектора KUMA. Для установки сервиса коллектора необходимо выполнить скопированную команду. Также необходимо добавить порт коллектора в исключения фаервола и обновить параметры службы firewall-cmd --add-port=5144/udp --permanent firewall-cmd --reload В результате статус коллектора в веб-интерфейсе KUMA изменится на зеленый . Настройка сервера источника логов На GitHub'е доступен community-скрипт для автоматической настройки отправки событий с Linux-хостов: https://github.com/KUMA-Community/kuma_auditd В случае наличия ошибок с доступом журналов, попробуйте отключить SELinux. Отключение SELinux вручную — SELINUX = Disabled в /etc/selinux/config и затем setenforce 0, команда getenforce для проверки. На сервере источнике логов проверьте наличие сервиса  RSyslog в системе: systemctl status rsyslog.service В случае отсутствия сервиса его необходимо установить и запустить: yum install rsyslog systemctl enable rsyslog.service systemctl start rsyslog.service Далее в папке /etc/rsyslog.d необходимо создать файл  audit.conf следующего содержания: vi /etc/rsyslog.d/audit.conf $ModLoad imfile $InputFileName /var/log/audit/audit.log $InputFileTag tag_audit_log: $InputFileStateFile audit_log $InputFileSeverity info $InputFileFacility local6 $InputRunFileMonitor local6.* @:<порт коллектора KUMA> Для отправки событий по протоколу TCP последнюю строчку следует заменить на: local6.* @@:<порт коллектора KUMA> После сохранения изменений в файле необходимо перезапустить сервис Rsyslog командой: systemctl restart rsyslog.service Проверка поступления событий Для проверки поступления событий выберите соответствующий коллектор и нажмите на кнопку Перейти к событиям . В открывшемся окне события при нажатии на значок лупы должны появиться события Auditd . Отправка с TLS Предварительно нужно установить дополнительный пакет для использования TLS: apt install rsyslog-gnutls Далее создем конфиг: nano /etc/rsyslog.d/50-auditd-tls.conf Со следующим содержимым (без верификации сертификата сервера): # Load necessary modules $ModLoad imfile $ModLoad omfwd $ModLoad gtls # TLS settings $DefaultNetstreamDriver gtls $ActionSendStreamDriverMode 1 # TLS-only $ActionSendStreamDriverAuthMode anon # No server certificate validation # No CA or client certs needed for anon mode # Configure file monitoring for auditd log $InputFileName /var/log/audit/audit.log $InputFileTag tag_audit_log: $InputFileStateFile audit_log $InputFileSeverity info $InputFileFacility local6 $InputRunFileMonitor # Forward log lines matching the audit log tag if $programname == 'tag_audit_log' then @@:<порт коллектора KUMA> Конфиг TLS с верификацией сервера $ActionSendStreamDriverAuthMode x509/name $ActionSendStreamDriverPermittedPeer rsyslog-server $DefaultNetstreamDriverCAFile /etc/rsyslog/ca.crt После изменений в файле необходимо перезапустить сервис Rsyslog командой: systemctl restart rsyslog.service Отправка лога без заголовка syslog Иногда необходимо отпралять события без заголовка, в этом случае используются шаблоны, ниже пример использования в конфиге: $template onlyMSG,"%msg%\n" $ModLoad imfile $InputFileName /var/log/audit/audit.log $InputFileTag tag_audit_log: $InputFileStateFile audit_log $InputFileSeverity info $InputFileFacility local6 $InputRunFileMonitor local6.* @:<порт коллектора KUMA>;onlyMSG Передача многострочных файлов при помощи rsyslog Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. В примере был использован  лог Firebird , его изначальный вид: Пример лога 2025-05-09T01:00:10.7510 (20580:0x7f5c02298210) EXECUTE_STATEMENT_START         /opt/firebird_test/mydatabase.fdb (ATT_85882, SYSDBA:NONE, NONE, )                 (TRA_424990, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE) ------------------------------------------------------------------------------- CREATE TABLE test (id INT, name VARCHAR(30)) Для получения многострочных файлов понадобится файл конфигурации, его необходимо создать в папке /etc/rsyslog.d/ conf_firebird.conf module(load="imfile") template(name="raw_frbd" type="string" string="%hostname% %msg%") # File firebird input(type="imfile" File="/var/log/app1.log" tag="frbd_log" startmsg.regex="^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}\\.[0-9]{4}" ruleset="forward_to_remote") # Rules send to KUMA collector ruleset(name="forward_to_remote") { action(type="omfwd" Target="10.10.10.10" Port="5001" Protocol="tcp" Template="raw_frbd" queue.type="linkedlist" queue.size="10000") } В зависимости от содержимого файла необходимо будет корректно подобрать регулярное выражение в параметре: startmsg.regex="your_regex" Network Подключение сетевых источников событий: маршрутизаторы, коммутаторы, FW, NGFW и т.п. Usergate Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Настройка Usergate Для настройки отправки событий с Usergate в KUMA выполните следующие действия: 1. В веб-интерфейсе Usergate перейдите на вкладку  Журналы и отчеты . 2. Выберите  Экспорт журналов и нажмите кнопку Добавить . 3. На вкладке  Общие поставьте галочку напротив параметра Включено и задайте имя правилу экспорта журналов. 4. На вкладке  Удаленный сервер задайте следующие настройки: Тип сервера - Syslog Адрес -   коллектора KUMA Порт - порт коллектора KUMA Транспорт - UDP или TCP (настройка должна совпадать с настройками коллектора KUMA). Протокол - Syslog (RFC 5424) . Критичность  и Объект выберите в соответствии с потребностями в логировании. В поле Имя хоста по умолчанию указано имя хоста Usergate с символом @ . Замените символ « @ » на символ « . » для корректной нормализации событий Usergate на стороне KUMA. 5. На вкладке  Журналы для экспорта поставьте галочки напротив Журналов , которые необходимо экспортировать в KUMA. Для каждого экспортируемого журнала выберите Формат CEF .   6. Сохраните внесенные изменения. Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий Usergate. 1. На шаге  Транспорт  укажите тип и порт в соответствии с настройками на стороне Usergate. 2. На шаге  Парсинг  событий выберите нормализатор  [OOTB] Syslog-CEF. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Экспорт журналов (документация UserGate): https://docs.usergate.com/eksport-zhurnalov_178.html   ViPNet Coordinator Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Настройка ViPNet Coordinator Для отправки событий ViPNet Coordinator в KUMA выполните следующее: 1. Подключитесь к консоли ViPNet Coordinator локально или через ssh. 2. Перейдите режим в Администратора с помощью следующей команды: enable 3. Из командной строки в режиме Администратора выполните команду: machine set loghost После выполненных настроек ViPNet Coordinator будет отправлять системный журнал на адрес коллектора KUMA по протоколу UDP и 514-му порту. В случае если коллектор KUMA является открытым узлом по отношению к ViPNet Coordinator, то также необходимо создать фильтр открытой сети, разрешающий исходящий трафик по протоколу UDP на 514-й порт коллектора KUMA. Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий ViPNet Coordinator. 1. На шаге  Транспорт  укажите тип UDP и порт 514. 2. На шаге  Парсинг  событий выберите нормализатор [OOTB] VipNet Coordinator syslog. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Дополнительная настройка коллектора После установки коллектора, необходимо внести изменения в файл сервиса коллектора для того, чтобы коллектор мог слушать входящие соединения на порту 514. Для этого выполните следующие действия: 1. Остановите выполнение сервиса коллектора командой  systemctl stop kuma-collector- 2. Откройте на редактирование файл коллектора /usr/lib/systemd/system/kuma-collector-.service 3. В разделе  [Service] добавьте следующую строку AmbientCapabilities=CAP_NET_BIND_SERVICE 4. Сохраните полученный файл 5. Обновите параметры сервисов следующей командой  systemctl daemon-reload 6. Запустите службу коллектора следующей командой systemctl start kuma-collector- Ideco UTM Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/255211.htm Настройка Ideco UTM Для передачи событий из Ideco UTM в KUMA выполните следующие действия: 1. Подключитесь к веб-интерфейсу Ideco UTM под учётной записью, обладающей административными привилегиями. 2. В меню Пересылка системных сообщений переведите переключатель Syslog в положение включено. 3. В параметре IP-адрес укажите IP-адрес коллектора KUMA. 4. В параметре Порт введите порт, который прослушивает коллектор KUMA. 5. Нажмите Сохранить для применения внесённых изменений. Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий Ideco UTM. 1. На шаге  Транспорт  укажите тип UDP и порт в соответствии с настройками на стороне Ideco UTM. 2. На шаге  Парсинг  событий выберите нормализатор [OOTB] Ideco UTM syslog. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Настройка получения событий Ideco UTM (онлайн-справка KUMA): https://support.kaspersky.com/help/KUMA/2.1/ru-RU/255211.htm Расшифровка передаваемых логов: https://docs.ideco.dev/settings/monitor/syslog   Cisco IOS Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ  является официальной рекомендацией вендора. Настройка Cisco IOS Войдите на источник Cisco IOS коммутатор или маршрутизатор. Введите следующую команду для входа в маршрутизатор в привилегированный режим: enable Переключитесь в режим конфигурации (configure terminal):  conf t Перед включением ведения журнала убедитесь, что ваш маршрутизатор правильно настроен для получения времени от сервера NTP, или настройте его вручную, чтобы получать время. Используйте команду set clock или ntp server x.x.x.x для синхронизации часов. Включите журналирование:  logging on Укажите IP-адрес коллектора и порт (можно использовать UDP или TCP транспорт):  logging host transport udp port <порт коллектора> Укажите уровень важности событий (рекомендуется informational): logging trap informational Уровни критичности в CISCO: Level Keyword Level Description Syslog Definition emergencies 0 Система нестабильна LOG_EMERG alerts 1 Требуются немедленные действия LOG_ALERT critical 2 Критические условия LOG_CRIT errors 3 Условия ошибки (по умолчанию) LOG_ERR warnings 4 Условия предупреждения LOG_WARNING notifications 5 Нормальное, но значимое состояние LOG_NOTICE informational 6 Только информационные сообщения LOG_INFO debugging 7 Отладка сообщений LOG_DEBUG Укажите интерфейса источника для отправки событий: logging source-interface <Имя интерфейса> <Имя интерфейса> - это имя интерфейса, например, dmz, lan, ethernet0 или ethernet1. Настройте средство для системного журнала: logging facility syslog Настройте идентификатор событий:  logging origin-id ip Настройте временные метки событий и идентификаторы событий в логировании:  service timestamps log datetime year show-timezone service sequence numbers Маршрутизатор по умолчанию не проверяет, авторизован ли пользователь в консольном порту или к нему подключено устройство; если ведение журнала консоли включено, на консольный порт всегда отправляются сообщения, которые могут вызвать нагрузку на процессор. Поэтому ниже включим логирование только необходимых событий. (вместо включения logging console warning ) Включите регистрацию событий входа пользователей: logging userinfo login on-success log login on-failure log ip ssh logging events Включите регистрацию событий выполнения конфигурационных команд: archive log config logging enable notify syslog contenttype plaintext Опционально . Включите регистрацию событий VPN: crypto logging ezvpn crypto logging session crypto logging ikev2 Выйдите из режима конфигурирования: end Сохраните изменения даже после перезагрузки: на старых Cisco: write memory на новых Cisco (копирование рабочей конфигурации): copy running-config startup-config Чтобы отобразить состояние системного журнала (syslog) и содержимое стандартного буфера сообщений системного журнала, используйте команду из привилегированного режима:  show logging FortiGate (CEF) Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Настройка коллектора KUMA Создание коллектора KUMA Для приема и обработки событий с FortiGate необходимо создать сервис коллектора в KUMA. Для этого в веб-интерфейсе перейдите на вкладку Ресурсы  и нажмите на кнопку Подключить источник.  В появившемся окне Создание коллектора: На шаге Подключение источников укажите Имя коллектора  и  Тенант , к которому будет принадлежать создаваемый коллектор На шаге Транспорт укажите Тип и Порт (данные параметры должны соответствовать настройкам на стороне FortiGate: set mode и set port соответственно) Для распределенной инсталяции укажите hostname:port сервера коллектора в поле URL На шаге Парсинг событий укажите нормализатор. Рекомендуется использовать предустановленный нормализатор [OOTB] Syslog-CEF  ( https://support.kaspersky.com/help/KUMA/3.0.3/ru-RU/255782.htm) . Если планируете использовать правила корреляции для FortiGate из Community-Pack необходимо использовать нормализатор [2024-04-22] FortiGate Syslog-CEF , также доступный в Community-Pack Шаги мастера настройки с четвертого по шестой можно пропустить и вернуться к их настройке позднее. На седьмом шаге Маршрутизация задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище . В случае если предполагается также корреляция по событиям добавьте точку назначения типа  Коррелятор . На завершающем шаге Проверка параметров нажмите на кнопку Сохранить и создать сервис . После чего появится команда установки сервиса, которую необходимо скопировать для дальнейшей установки. Также после выполнения вышеуказанных действий на вкладке  Ресурсы >   Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Выполните подключение к  CLI   KUMA  (установка коллектора выполняется с правами  root ). Для установки сервиса коллектора в командной строке выполните команду, скопированную на прошлом шаге. При необходимости добавьте порт коллектора в исключения фаервола и обновите параметры службы. firewall-cmd --add-port=<порт, выбранный для коллектора>/udp –permanent firewall-cmd --reload После успешной установки сервиса его в статус в веб-интерфейсе KUMA изменится на зеленый . Настройка FortiGate Для настройки отправки событий в формате CEF с FortiGate в KUMA выполните следующие действия: Подключитесь к CLI FortiGate по SSH Перейдите в секцию настройки параметров Syslog: config log syslogd setting Выполните настройку параметров Syslog: set status enable # включить отправку событий на удаленный Syslog-сервер set server set mode udp # отправлять события по UDP set port <порт, заданный в параметрах коллектора KUMA> set source-ip # IP-адрес, который будет использоваться в качестве Source IP при взаимодействии c коллектором KUMA [опционально] set format cef # отправлять события в формате CEF set interface-select-method # если выбран specify указать вручную исходящий интерфейс для взаимодействия с коллектором KUMA с помощью команды set interface <наименование интерфейса> [опционально] end Проверка поступления событий FortiGate в KUMA Для проверки, что сбор событий с FortiGate успешно настроен перейдите в Ресурсы >  Активные сервисы > выберите ранее созданный коллектор для FortiGate и нажмите  Перейти к событиям. В открывшемся окне События убедитесь, что присутствуют события с FortiGate. Полезные ссылки Отправка событий в формате CEF - https://community.fortinet.com/t5/FortiGate/Technical-Note-FortiGate-Logs-can-be-sent-to-syslog-servers-in/ta-p/190617 Check Point NGFW (CEF) Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Настройка коллектора KUMA Создание коллектора KUMA Для приема и обработки событий Check Point NGFW необходимо создать сервис коллектора в KUMA. Для этого в веб-интерфейсе перейдите в раздел Ресурсы  и нажмите на кнопку Подключить источник.  В появившемся окне Создание коллектора: На шаге Подключение источников укажите Название коллектора  и  Тенант , которому будет принадлежать создаваемый коллектор На шаге Транспорт укажите Тип коннектора и URL (порт, выделенный сервису)  Для распределенной инсталяции укажите hostname:port сервера коллектора в поле  URL Указанные параметры должны соответствовать настройкам на стороне Check Point На шаге Парсинг событий  нажмите Добавить парсинг событий  и укажите нормализатор. Рекомендуется создать и использовать в качестве нормализатора для событий Check Point дубликат предустановленного нормализатора [OOTB] CEF. В параметрах нормализатора перейдите в окно  Основной парсинг событий  и выберите вкладку  Обогащение.  На вкладке   Обогащение  нажмите Добавить обогащение  и настройте параметры обогащения согласно скриншоту ниже для корректной работы SOC и Community корреляционных правил. Шаги мастера настройки с четвертого по шестой ( Фильтрация событий , Агрегация событий и Обогащение событий ) можно пропустить и вернуться к их настройке позднее. На седьмом шаге Маршрутизация задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище (Storage) . В случае если предполагается также анализ потока событий правилами корреляции добавьте точку назначения типа  Коррелятор (Correlator) . На завершающем шаге Проверка параметров нажмите на кнопку Сохранить и создать сервис . После чего появится команда установки сервиса, которую необходимо скопировать для дальнейшей установки. Также после выполнения вышеуказанных действий в разделе Ресурсы >   Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Выполните подключение к  CLI сервера KUMA (установка сервиса коллектора выполняется с правами root ). Для установки сервиса коллектора выполните команду, скопированную на прошлом шаге. При необходимости добавьте порт коллектора в исключения фаервола и обновите параметры службы. firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp –permanent firewall-cmd --reload После успешной установки сервиса его статус в веб-интерфейсе KUMA изменится на  Вкл с зеленой индикацией . Настройка Check Point NGFW Отправка событий Check Point NGFW осуществляется средствами Log Exporter с Management Server/Log Server. Настройку конфигурации Log Exporter можно выполнить двумя способами: С помощью SmartConsole (начиная с версии R81) В CLI SmartConsole Создайте новый объект Log Exporter/SIEM: Выберите Objects > More object types > Server > Log Exporter/SIEM В поле Object Name  введите имя для создаваемого объекта  Log Exporter Перейдите во вкладку General : В секции Export Configuration  активируйте флаг Enabled В секции Server Configuration : В поле Target Server  укажите IP-адрес или FQDN сервера коллектора KUMA (FQDN поддерживается, начиная с R81 SmartConsole Build 569) В поле Target Port укажите порт, указанный на шаге Транспорт  при создании сервиса коллектора В поле Protocol  выберите протокол (TCP или UDP), указанный на шаге Транспорт  при создании сервиса коллектора  Перейдите во вкладку Data Manipulation: В поле Format  выберите Common Event Format (CEF) (Опционально) активируйте флаг Aggregate log updates before export  для экспорта событий, содержащих полные данные, а не только изменения, произошедшие с момента последнего лога для одного и того же события. (Опционально) Перейдите во вкладку Attachments: Активируйте флаги Add link to Log Details in SmartView Add link to Log Attachment in SmartView Add Log Attachment ID Нажмите ОК Выполните настройку параметров объекта Management Server или Dedicated Log Server / SmartEvent Server: В навигационной панели слева выберите Gateways & Servers Откройте объект Management Server or Dedicated Log Server / SmartEvent Server Слева выберите Logs > Export Нажмите [+] и выберите объект Log Exporter / SIEM,  созданный ранее Нажмите OK Нажмите Menu > Install database Выберите все объекты Нажмите Install CLI Подключитесь к Management Server / Log Server Перейдите в режим Expert Настройте параметры Log Exporter cp_log_export add name <Наименование конфигурации Log Exporter> target-server target-port <Порт, указанный на шаге Транспорт при создании сервиса коллектора> protocol {tcp | udp} format cef Запустите новый инстанс Log Exporter cp_log_export restart name <Наименование конфигурации> Проверка поступления событий Check Point NGFW в KUMA Для проверки, что сбор событий с Check Point NGFW успешно настроен перейдите в  Ресурсы >  Активные сервисы > выберите ранее созданный коллектор Check Point NGFW > ПКМ > Перейти к событиям. В открывшемся окне События убедитесь, что присутствуют события Check Point NGFW. Полезные ссылки Настройка отправки событий Check Point с помощью Log Exporter - https://support.checkpoint.com/results/sk/sk122323 Описание полей событий Check Point - https://support.checkpoint.com/results/sk/sk144192 АПКШ Континент 3.9 Информация, приведенная на данной странице, является дополнением к официальной статье по Настройке получения событий АПКШ Континент . Статья разработана командой pre-sales и НЕ является официальной рекомендацией вендора. Подготовительные действия для получения событий АПКШ Континент Создание роли базы данных Для получения событий АПКШ Континент 3.9 из MS SQL требуется учетная запись с минимальным набором прав для подключения и чтения данных в таблицах: ALERTLOG, SERVERACCESSLOG, SYSTEMLOG, PACKETLOG, FILTERS. Чтобы создать роль для доступа к таблицам БД АПКШ Континент выполните следующие действия: Войдите на сервер с установленной MS SQL. С помощью SQL Server Management Studio подключитесь к MS SQL под учетной записью с правами администратора. В панели Object Explorer раскройте вкладку БД АПКШ Континент и далее вкладку Security. Во вкладке Roles нажмите правой кнопкой мыши на вкладку Database Roles и в контекстном меню выберите  New Database Role. В появившемся окне Database Role - New на вкладке General  укажите : Имя роли ( Role Name ); Владельца (Owner) ; На вкладке Защищаемые объекты (Securables) добавьте защищаемые объекты (таблицы ALERTLOG, SERVERACCESSLOG, SYSTEMLOG, PACKETLOG, FILTERS) и настройте разрешения к ним согласно скриншотам ниже: Итоговый перечень защищаемых объектов: После добавления таблиц нажмите ОК для создания роли. Создание учётной записи Чтобы создать учетную запись в MS SQL для доступа к таблицам БД АПКШ Континент выполните следующие действия: В панели Object Explorer раскройте вкладку Security. Нажмите правой кнопкой мыши на вкладку Logins и в контекстном меню выберите New Login. Откроется окно Login - New. На вкладке  General:  Выберите SQL Server authentication  для использования внутренней системы аутентификации SQL Server - другими словами, для использования локальной учетной записи. Если необходимо, можно использовать доменную учетную запись - для этого выберите вариант Windows Authentication . Далее рассматривается вариант с использованием SQL Server authentication. В поле  Login Name укажите имя создаваемой учетной записи (например, kuma). В поле Password  и Confirm Password укажите пароль для создаваемой учетной записи. Опционально активируйте Enforce password policy и остальные параметры, связанные с паролем учетной записи. В качестве Default database (база данных по умолчанию) выберите базу данных, используемую АПКШ Континент. На вкладке User Mapping настройте права для учетной записи: В разделе Users mapped to this login выберите БД, используемую АПКШ Континент. В разделе Database role membership for установите флажок возле ранее созданной роли (в нашем примере kuma_log_access). На вкладке Status настройте права для подключения учетной записи к базе данных: В разделе Permission to connect to database engine выберите Grant . В разделе Login выберите Enabled . Нажмите ОК . Настройка утилиты kuma-kont Создание конфигурационного файла kuma-kont-config.yaml Пример конфигурационного файла kuma-kont-config.yaml: Если при запуске утилиты kuma-kont присутствуют ошибки вида "Unsupported TLS version..." и нет возможности включить поддержку TLS 1.2 на стороне сервера MS SQL, добавьте параметр ";encrypt=disable" к имени БД. Рекомендуется установить соотвествующие обновления на сервере MS SQL для поддержки TLS 1.2. Вариант с отключением шифрования не рекомендуется к использованию, так как данные буду передаваться в открытом виде. FortiGate-FortiAnalyzer (CEF) Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. FortiAnalyzer — это аналитическая платформа для управления событиями, журналами и формирования отчетности, разработанная компанией Fortinet. В данной статье рассматривается настройка отправки событий FortiGate, которые централизованно собираются и хранятся в FortiAnalyzer. Настройка коллектора KUMA Создание коллектора KUMA Для приема и обработки событий FortiGate, отправляемых с FortiAnalyzer, необходимо создать сервис коллектора в KUMA. Для этого в веб-интерфейсе перейдите в раздел Ресурсы  и нажмите на кнопку Подключить источник.  В появившемся окне Создание коллектора: На шаге Подключение источников укажите Название коллектора  и  Тенант , которому будет принадлежать создаваемый коллектор На шаге Транспорт укажите Тип коннектора и URL (порт, выделенный сервису). Для распределенной инсталяции укажите hostname:port сервера коллектора в поле  URL Указанные параметры должны соответствовать настройкам на стороне FortiAnalyzer На шаге Парсинг событий  нажмите Добавить парсинг событий  и укажите нормализатор. Рекомендуется использовать community-нормализатор FortiGate-FortiAnalyzer (CEF).  Как альтернативный вариант, можно использовать предустановленный нормализатор [OOTB] CEF,  но данный нормализатор не обеспечивает парсинг специфичных полей FortiGate, например, virus, attack и других.  Шаги мастера настройки с четвертого по шестой ( Фильтрация событий , Агрегация событий и Обогащение событий ) можно пропустить и вернуться к их настройке позднее. На седьмом шаге Маршрутизация задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище (Storage) . В случае если предполагается также анализ потока событий правилами корреляции добавьте точку назначения типа  Коррелятор (Correlator) . На завершающем шаге Проверка параметров нажмите на кнопку Сохранить и создать сервис . После чего появится команда установки сервиса, которую необходимо скопировать для дальнейшей установки. Также после выполнения вышеуказанных действий в разделе Ресурсы >   Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Выполните подключение к  CLI сервера KUMA (установка сервиса коллектора выполняется с правами root ). Для установки сервиса коллектора выполните команду, скопированную на прошлом шаге. При необходимости добавьте порт коллектора в исключения фаервола и обновите параметры службы. # Пример для firewalld firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp –permanent firewall-cmd --reload После успешной установки сервиса в столбце Статус в веб-интерфейсе KUMA появится  зеленая индикация . Настройка FortiAnalyzer Пересылка событий FortiGate в KUMA выполняется средствами механизма Log Forwarding, доступного в FortiAnalyzer. Для настройки пересылки в веб-интерфейсе FortiAnalyzer: Перейдите в System Settings > Log Forwarding Нажмите Create New В появившемся окне Create New Log Forwarding  укажите: Name - KUMA CEF Status - Включено Remote Server Type - Common Event Format (CEF) Server FQDN/IP - Server Port - <Укажите порт, указанный на шаге Транспорт  при создании сервиса коллектора> Reliable Connection - Включено Опционально фильтры в секции Log Forwarding Filters Нажмите ОК Убедитесь, что параметры нового сервера для пересылки событий сохранены. Проверка поступления событий FortiGate в KUMA Для проверки, что пересылка событий FortiGate с FortiAnalyzer успешно настроена перейдите в Ресурсы >  Активные сервисы > выберите ранее созданный коллектор FortiGate-FortiAnalyzer > ПКМ > Перейти к событиям. В открывшемся окне События убедитесь, что присутствуют события FortiGate. Полезные ссылки Настройка пересылки событий с помощью Log Forwarding: https://docs.fortinet.com/document/fortianalyzer/7.2.9/administration-guide/621804/log-forwarding Описание типов и полей событий FortiGate: https://docs.fortinet.com/document/fortigate/7.2.8/fortios-log-message-reference/search Континент версия 4 Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ  является официальной рекомендацией вендора. Настройки Континента Откройте Менеджер конфигурации Континента.  В настройках узла безопасности раскройте пункт  Журналирование и оповещение , затем  нажмите и пропишете IP адрес и порт коллектора KUMA, рекомендуется использовать протокол TCP. Уровени детализации журнала в Континенте (Рекомендуемый уровень детализации Высокий ):  Уровень детализации журнала Уровень важности события Отладочный Отладка (DEBUG) Минимальный Информация (INFO) Низкий Ошибка (ERR) Средний Критическая ошибка (CRIT) Высокий Тревога (ALERT) Предустановленный Предупреждение (Warning)  Пример настройки ниже: Нажмите Применить и ОК . Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий Usergate. 1. На шаге  Транспорт  укажите тип и порт в соответствии с настройками на стороне Континента. 2. На шаге  Парсинг  событий выберите нормализатор [2024-05-03] Unix AuditD (REGEX) из папки нормализоторов Community-Pack. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Справка по Континенту версия 4 - тут Статья в HABR по интеграции Континента и KUMA -  https://habr.com/ru/companies/tssolution/articles/792078/   Mikrotik Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Инструкция применима для MikroTik с RouterOS 6 и 7+ Настройка Mikrotik Настройка может выполняется с помощью WinBox (рассматривается этот метод), либо через веб-интерфейс MikroTik RouterOS под учетной записью с правами администратора или через командную строку. Перейдите в раздел System - Logging , во вкладке Actions добавляем новый элемент (по умолчанию используется протокол UDP): Cохраните настройку, нажав Apply и OK . Настройка через командную строку: /system logging action /system/logging/action> add bsd-syslog=yes name=kuma remote=(KUMA_IP) remote=KUMA_PORT syslog-facility=syslog target=remote Каждое событие в журналах Mikrotik может находиться одновременно в разных Topics, пример ниже:  В правилах логирования необходимо укаказать Topics, не пересекающиеся в других правилах. Иными словами, нужно создать отдельные правила с указанием отдельных Topics и если необходимо указать исключения, для категорий событий, которые не нужно отправлять на коллектора, установите флаг  ! перед Topics. В раскрывающемся списке Action выберите созданное ранее действие kuma, затем нажмите ОК . Настройка через командную строку: /system logging add topics=critical prefix=critical action=kuma При включении определенных Topics, особенно firewall может возрастать нагрузка на МЭ MikroTik, обращайте внимание на нагрузку системы после влючения логирования, особенно это касается моделей со слабой аппаратной начинкой   Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий MikroTik. 1. На шаге  Транспорт  укажите тип и порт в соответствии с настройками на стороне MikroTik. 2. На шаге  Парсинг  событий выберите нормализатор [OOTB] MikroTik syslog. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Huawei (Syslog и NetFlow) Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Настройка Syslog Настройка может выполняться через командную строку под учетной записью с правами администратора. #Настройка syslog info-center channel 6 name Syslog_KUMA info-center source default channel 6 log level informational info-center loghost source <Название интерфейса, с которого будет происходить отправка событий> info-center loghost port <Порт коллектора KUMA> facility local7 severity warning #Включение регистрации событий ввода команд info-center command-log enable info-center command-log size 100 info-center command-log timestamp quit save Настройка NetFlow Настройка может выполняться через командную строку под учетной записью с правами администратора. #Укажите интерфейс, из которого будут экспортироваться данные о потоке. Замените цифру «3» фактическим номером интерфейса , если он отличается. slot 3 (Replace "3" with your actual slot number if different.) ip netstream sampler fix-packets 500 inbound ip netstream sampler fix-packets 500 outbound #Настройка параметров экспорта NetStream.Задайте параметры экспорта NetStream, включая версию, исходный IP-адрес и IP-адрес хоста. ip netstream timeout active 1 ip netstream timeout inactive 15 ip netstream export version 9 #вариативно, 5 или 9 версия ip netstream export index-switch 32 ip netstream export template timeout-rate 1 ip netstream export source <адрес устройства> ip netstream export host 2055 #порт по умолчанию - 2055, при необходимости меняем ip netstream export template option sampler ip netstream export template option timeout-rate 1 ip netstream as-mode 32 #Включите NetFlow на интерфейсах, которые будут экспортировать данные о потоке. ip netstream inbound quit save Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллекторы в веб-интерфейсе KUMA для событий Huawei. Отдельно - коллектор для Syslog и отдельный коллектор для приёма NetFlow. Создание коллектора для приёма Syslog: 1. На шаге  Транспорт  укажите тип и порт в соответствии с настройками Syslog на стороне Huawei. 2. На шаге  Парсинг  событий выберите нормализатор [OOTB] Huawei USG Basic (либо другой нормализатор, подходящий под Ваше устройство) . 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Создание коллектора для приёма NetFlow: 1. На шаге  Транспорт  укажите тип и порт в соответствии с настройками Netflow на стороне Huawei. Задаём: Тип  netflow url  :2055 (либо порт - который был задан на этапе настройки со стороны Huawei) 2. На шаге  Парсинг  событий выберите нормализатор [OOTB] NetFlow v5 или [OOTB] NetFlow v9, в зависимости от выбранной версии на этапе настройки Huawei. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. pfSense Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Настройка коллектора KUMA Создание коллектора KUMA Для приема и обработки событий pfSense необходимо создать сервис коллектора в KUMA. Для этого в веб-интерфейсе перейдите в раздел  Ресурсы  и нажмите на кнопку Подключить источник.  В появившемся окне Создание коллектора: На шаге Подключение источников укажите Название коллектора  и  Тенант , которому будет принадлежать создаваемый коллектор На шаге Транспорт укажите Тип коннектора и URL (порт, выделенный сервису)  Для распределенной инсталяции укажите hostname:port сервера коллектора в поле  URL. Указанные параметры должны соответствовать настройкам на стороне pfSense. Демон syslog поддерживает отправку syslog-сообщений только с помощью протокола UDP. Для отправки событий по протоколу TCP необходимо использовать пакет syslog-ng. На шаге Парсинг событий  нажмите Добавить парсинг событий  и укажите нормализатор. Рекомендуется использовать в качестве нормализатора для событий pfSense "коробочный" нормализатор [OOTB] pfSense Syslog. Шаги мастера настройки с четвертого по шестой ( Фильтрация событий , Агрегация событий и Обогащение событий ) можно пропустить и вернуться к их настройке позднее. На седьмом шаге Маршрутизация задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище (Storage) . В случае если предполагается также анализ потока событий правилами корреляции добавьте точку назначения типа  Коррелятор (Correlator) . На завершающем шаге Проверка параметров нажмите на кнопку Сохранить и создать сервис . После чего появится команда установки сервиса, которую необходимо скопировать для дальнейшей установки. Также после выполнения вышеуказанных действий в разделе Ресурсы >   Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Выполните подключение к  CLI сервера KUMA (установка сервиса коллектора выполняется с правами root ). Для установки сервиса коллектора выполните команду, скопированную на прошлом шаге. При необходимости добавьте порт коллектора в исключения фаервола и обновите параметры службы. Если используется firewall-cmd: firewall-cmd --add-port=5152/udp –permanent firewall-cmd –reload Если используется ufw: ufw allow 5152/udp ufw reload После успешной установки сервиса его статус в веб-интерфейсе KUMA изменится на Вкл с зеленой индикацией . Настройка pfSense Отправка событий pfSense осуществляется с помощью демона syslog. Для настройки отправки событий в KUMA: Перейдите в раздел Статус > Системный журнал и далее во вкладку Настройки. В секции Общие Опции Журналирвания: В качестве значения параметра Log Message Format выберите syslog (RFC 5424, with RFC 3339 microsecond-precision timestamps). В секции Опции Удаленного Журналирования : Включите параметр Отправлять сообщения журнала на удаленный сервер syslog . В параметре Серверы удаленного журнала укажите IP-адрес:порт сервера KUMA (для распределенной инсталляции - IP-адрес:порт сервера коллектора KUMA). В параметре Содержание Удаленного Сервера Журнала  выберите типы событий для отправки. Нажмите Сохранение . Проверка поступления событий pfSense в KUMA Для проверки, что сбор событий с pfSense успешно настроен перейдите в Ресурсы >  Активные сервисы > выберите ранее созданный коллектор pfSense > ПКМ > Перейти к событиям. В открывшемся окне События убедитесь, что присутствуют события pfSense. События, отправляемые способом, описанным выше, пересылаются в открытом (незашифрованном) виде. Рекомендуется использование пакета Stunnel или пакета syslog-ng, который поддерживает передачу syslog-сообщений в зашифрованном виде. Полезные ссылки Раздел Remote Logging with Syslog  документации Вендора: https://docs.netgate.com/pfsense/en/latest/monitoring/logs/remote.html PaloAlto Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Palo Alto Networks (PAN-OS)  — источник событий безопасности и сетевой активности, поступающих с NGFW . Логи включают данные о сессиях, трафике, угрозах, системных событиях, аутентификации и администрировании. Используются для корреляции инцидентов, выявления атак и анализа сетевого поведения.  Типы собираемых событий Аутентификация Изменение конфигурации Информация о сетевых сессиях Способ интеграции - Syslog Примеры событий  <14>Oct 23 19:57:20 DEMO-NGFW 1,2025/10/23 19:57:20,007954000611466,TRAFFIC,end,2562,2025/10/23 19:57:20,172.16.1.101,8.8.8.8,1.2.9.5,8.8.8.8,Allow - to Internet,,,dns-base,vsys1,Zone1,Zone2,ethernet1/5,ethernet1/4,Rule1,2025/10/23 19:57:20,226468,1,62119,53,1757,53,0x400019,udp,allow,262,99,163,2,2025/10/23 19:56:48,0,any,,7553303471644639363,0x0,172.16.0.0-172.31.255.255,United States,,1,1,aged-out,0,0,0,0,,DEMO-NGFW,from-policy,,,0,,0,,N/A,0,0,0,0,c950b3fc-0861-4869-b734-cda049e8efb9,0,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,2025-10-23T19:57:20.110+05:00,,,infrastructure,networking,network-protocol,3,"used-by-malware,has-known-vulnerability,pervasive-use",dns,dns-base,no,no,0 <12>Oct 23 20:07:11 DEMO-NGFW 1,2025/10/23 20:07:11,007954000611466,SYSTEM,auth,2562,2025/10/23 20:07:11,,auth-fail,,0,0,general,medium,"failed authentication for user 'admin'.  Reason: Invalid username/password. From: 172.16.1.2.",7553303475874058474,0x0,0,0,0,0,,DEMO-NGFW,0,0,2025-10-23T20:07:11.169+05:00 <14>Oct 23 20:05:01 DEMO-NGFW 1,2025/10/23 20:05:01,007954000611466,SYSTEM,auth,2562,2025/10/23 20:05:01,,auth-success,,0,0,general,informational,"authenticated for user 'admin'.   From: 172.16.1.2.",7553303475874058376,0x0,0,0,0,0,,DEMO-NGFW,0,0,2025-10-23T20:05:01.544+05:00 <14>Oct 23 20:09:16 DEMO-NGFW 1,2025/10/23 20:09:16,007954000611466,SYSTEM,general,2562,2025/10/23 20:09:16,,general,,0,0,general,informational,"Connection to Update server: updates.paloaltonetworks.com completed successfully, initiated by 18.22.91.5",7553303475874058563,0x0,0,0,0,0,,DEMO-NGFW,0,0,2025-10-23T20:09:16.798+05:00 <14>Oct 23 20:07:20 DEMO-NGFW 1,2025/10/23 20:07:20,007954000611466,SYSTEM,general,2562,2025/10/23 20:07:20,,general,,0,0,general,informational,"User admin logged in via Web from 172.16.1.2 using https",7553303475874058485,0x0,0,0,0,0,,DEMO-NGFW,0,0,2025-10-23T20:07:20.811+05:00 <14>Oct 23 20:10:21 DEMO-NGFW 1,2025/10/23 20:10:20,007954000611466,SYSTEM,vpn,2562,2025/10/23 20:10:21,,ike-generic-event,,0,0,general,informational,"unknown ikev2 peer",7553303475874058609,0x0,0,0,0,0,,DEMO-NGFW,0,0,2025-10-23T20:10:21.145+05:00 Пошаговая настройка отправки событий web UI Рекомендуется настраивать фильтрацию сетевых событий (src, dst, port) на принимающем сервере для снижения утилизации лицензии Настройка производится через Web-интерфейс Palo Alto NGFW, для выполнения настроек откройте в браузере Web-консоль и войдите под учетной записью с правами администратора. Добавление Syslog-профиля Перейдите в раздел “ Device ” → “ Server Profiles ” → “ Syslog ”, нажмите “ Add ” для добавления нового профиля. 2. В окне создания профиля ( Syslog Server Profile ) укажите удобное имя в поле “ Name ” и нажмите “ Add ” для добавления Syslog-сервера, в параметрах сервера укажите: Name - произвольное имя для индентификации Syslog-сервера; Syslog Server - DNS-имя или IP-адрес принимающего Syslog-сервера; Transport - выберите UDP / TCP / SSL (используется шифрование поверх TCP) Port - порт принимающего Syslog-сервера; Format = BSD (по умолчанию) Facility = LOG_USER (по умолчанию) Сохраните изменения - “ ОК ” Настройка отправки системных событий Передите в раздел “ Device ” → “ Log Settings ” Добавьте идентичные настройки для блоков: System Configuration User-ID GlobalProtect Для добавления конфигурации нажмите “Add” в каждой необходимой секции ( System, Configuration, User-ID, GlobalProtect ) и заполните следующие параметры: Создайте аналогичные профили настроек для Configuration, User-ID, GlobalProtect Name - произвольное имя для индентификации профиля настроек; Filter = All Logs (по умолчанию) Syslog - в данном разделе добавьте ранее созданный Syslog Server Profile Сохраните изменения - “ ОК ” Добавление профиля отправки событий Перейдите в раздел “ Objects ” → “ Log Forwarding ”, нажмите “ Add ” для добавления нового профиля 2. В открывшемся окне ( Log Forwarding Profile ) укажите произвольное имя (поле ” Name ”) и нажмите “ Add ” для добавления списка соответствия 3. Добавьте список соответствия для событий о сетевых сессиях (traffic), для этого в окне добавления списка соответствия ( Log Forwarding Profile Match List ) укажите: Name - произвольное имя списка соответствия (должно быть уникально в рамках одного Log Forwarding Profile) Log type = traffic Filter = All Logs Syslog - в данном разделе добавьте ранее созданный Syslog Server Profile Сохраните изменения - “ ОК ” 4.  Добавьте список соответствия для событий аутентификации (auth), для этого в окне добавления списка соответствия ( Log Forwarding Profile Match List ) укажите: Name - произвольное имя списка соответствия (должно быть уникально в рамках одного Log Forwarding Profile) Log type = auth Filter = All Logs Syslog - в данном разделе добавьте ранее созданный Syslog Server Profile Сохраните изменения - “ ОК ” 5. Добавьте список соответствия для событий об угрозах (threat), для этого в окне добавления списка соответствия ( Log Forwarding Profile Match List ) укажите: Name - произвольное имя списка соответствия (должно быть уникально в рамках одного Log Forwarding Profile) Log type = threat Filter = All Logs Syslog - в данном разделе добавьте ранее созданный Syslog Server Profile Сохраните изменения - “ ОК ” 6. Добавьте список соответствия для событий о фильтрации URL (url), для этого в окне добавления списка соответствия ( Log Forwarding Profile Match List ) укажите: Name - произвольное имя списка соответствия (должно быть уникально в рамках одного Log Forwarding Profile) Log type = url Filter = All Logs Syslog - в данном разделе добавьте ранее созданный Syslog Server Profile Сохраните изменения - “ ОК ” В результате, в окне Log Forwarding Profile , у вас должно быть 4 списка соответствия, для сохранения нажмите “ OK ” Настройка логирования сетевых сессий в правилах Firewall Для того, чтобы NGFW логировал события о сетевых сессиях и мог их передать на внешний Syslog-сервер необходимо включить логирование в правилах FW. Рекомендуется включать логирование во всех правилах для полноценной видимости трафика. Перейдите в раздел “ Policies ” → “ Security ” Откройте необходимое правило (рекомендуется сделать для всех правил), в разделе “ Action ” укажите: Log at Session End - включить Log forwarding - выберите профиль отправки отправки событий, созданный на предыдущем этапе Сохраните изменения - “ ОК ” Настройка адреса источника Для того, чтобы NGFW отправлял события по Syslog необходимо выбрать сетевой интерфейс NGFW и адрес на этом интерфейсе с которого будет осуществляться отправка. Перейдите в раздел “ Device ” → “ Setup ” → “ Services ”, откройте настройки маршрутизации для сервисов ( Service Route Configuration ); В открывшемся окне ( Service Route Configuration ), во вкладке IPv4 выберите “Syslog” В настройках маршрутизации сервиса Syslog укажите: Source Interface - выберите сетевой интерфейс NGFW, с которого должна осуществляться отправка Source Address - выберите IP-адрес с которого будут отправляться события Сохраните изменения - “ ОК ” В окне “ Service Route Configuration ” сохраните изменения - ОК Примените изменения В Web-консоли, в верхнем правом углу нажмите “ Commit ”, валидируйте изменения и приметите их - “ Commit ” Cisco FMC Cisco Firepower Management Center (Cisco FMC) - централизованная платформа управления и администрирования решений Cisco Firepower. Cisco FMC используется для настройки, мониторинга и сопровождения устройств Firepower Threat Defense (FTD), включая управление политиками безопасности, обновлениями, лицензированием и интеграциями. В рамках задач информационной безопасности Cisco FMC является источником событий технического и административного аудита. События FMC позволяют отслеживать действия администраторов, изменения конфигурации, операции управления устройствами и системные события, что используется для контроля доступа, расследования инцидентов и формирования технического аудита в системах класса SIEM. Документация: https://www.cisco.com/c/en/us/support/security/defense-center/series.html Типы собираемых событий: Аутентификация и завершение сессий администраторов Административные действия и выполнение команд Изменения конфигурации и объектов управления Операции управления устройствами (добавление, удаление, изменение параметров) Системные и сервисные события управления События, связанные с применением и обновлением конфигураций Настройка отправки Audit log: Войдите в веб-консоль Cisco Firepower Management Center под учетной записью, обладающей административными правами. В правом верхнем углу интерфейса нажмите на значок System (шестерёнка). В открывшемся меню выберите Configuration . В левой части окна перейдите в раздел Audit Log . В параметре Send Audit Log to Syslog выберите значение Enabled . В параметре Send Configuration Changes выберите формат отправки событий ( Send as JSON ). В поле Hosts (Up to 5) укажите адрес сервера приёма syslog. В параметре Facility выберите используемую facility в соответствии с принятой схемой. В параметре Severity укажите уровень важности собираемых событий, рекомендуется INFO В поле Tag укажите произвольную метку для идентификации источника в SIEM, например FMC Нажмите кнопку Test Syslog Server Убедитесь, что отображается сообщение об успешной доступности syslog-сервера (S yslog server has been reached ). Cisco FTD Cisco Firepower Threat Defense (Cisco FTD) - межсетевой экран нового поколения, объединяющий функции классического firewall, системы предотвращения вторжений (IPS), контроля приложений и сетевого трафика. Cisco FTD используется для защиты сетевых сегментов, контроля доступа и мониторинга сетевой активности на границе и внутри корпоративной инфраструктуры. В рамках задач информационной безопасности Cisco FTD является источником событий сетевого и технического аудита. События FTD позволяют отслеживать действия администраторов, изменения конфигурации, а также факты установления и завершения сетевых соединений, что используется для мониторинга трафика, выявления инцидентов и последующего анализа в системах класса SIEM. Документация: https://www.cisco.com/c/en/us/support/security/firepower-ngfw/series.html Типы собираемых событий События аудита и административных действий События сетевых соединений Служебные и системные события безопасности Настройка Cisco FTD через FMC для отправки событий в SIEM Настройка логирования и отправки сетевого трафика (Access Control Policy) Войдите в веб-консоль Cisco FMC под учетной записью с правами администратора. В главном меню слева перейдите в раздел Policies . Выберите Access Control. Откройте используемую Access Control Policy . В списке правил выберите правило, нажмите Edit, одним из следующих способов: нажмите на значок ✎ (Edit) справа от имени правила; либо щёлкните по правилу правой кнопкой мыши и выберите Rule Actions → Edit Rule . В верхней правой части открывшегося окна нажмите на надпись Logging . В окне Logging Settings for Rule установите следующие параметры: **Log at beginning of connection (** Опционально . Включается при необходимости фиксации начала сетевого соединения и в соответствии с требованиями и рекомендациями по журналированию безопасности) Log at end of connection В разделе Send Connection Events to выберите: Firewall Management Center (опционально, при необходимости отображения логов в FMC) Syslog server Нажмите Show overrides . Установите флаг Override default syslog destination . При первичной настройке нажмите кнопку + для cоздания syslog-назначения. В открывшемся окне задайте конфигурацию syslog-назначения: В поле Name укажите имя конфигурации, например to_siem; задайте адрес,в поле Host, и порт, в поле Port , сервера приёма syslog; выберите Facility в соответствии с требованиями SIEM, например syslog; выберите Severity в соответствии с требованиями SIEM, например INFO; Опционально, в поле Tag укажите произвольную метку для идентификации источника в SIEM, например FTDNE Сохраните конфигурацию syslog-назначения, нажав на кнопку Save . В окне Select a syslog alert configuration, выберите созданный syslog destination, в нашем примере to_siem В окне Logging Settings for Rule нажмите Confirm для сохранения настроек логирования правила. Нажмите кнопку Apply в правом нижнем углу страницы Повторите шаги 5–10 и 14-16 для всех правил в вашей Access Control Policy, шаги 11-13 по созданию syslog destination выполнять не нужно, используйте ранее созданный syslog destintation. В нашем примере to_siem В нижней части страницы ранее открытой Access Control Policy , справа от надписи Default Action , нажмите на значок шестеренки ⚙ В открывшемся окне Default Logging and Inspection, включите: Log at beginning of connection ( Опционально . Включается при необходимости фиксации начала сетевого соединения и в соответствии с требованиями и рекомендациями по журналированию безопасности) Log at end of connection Firewall Management Center (опционально, при необходимости отображения логов в FMC) Syslog server Нажмите Show overrides . Установите флаг Override default syslog destination . В окне Select a syslog alert configuration, выберите созданный syslog destination, в нашем примере to_siem Нажмите кноппку Apply . В правом верхнем углу нажмите Save для сохранения изменений в политике Выполните Deploy для примения конфигурации к целевомым устройствам FTD В списке профилей Platform Settings выберите профиль, нажмите Edit, одним из следующих способов: нажмите на значок ✎ (Edit) справа от имени правила; либо щёлкните по профилю правой кнопкой мыши и выберите Edit . В настройках профиля перейдите на вкладку Syslog В открытом профиле Syslog перейдите на вкладку Logging Setup . В разделе Basic Logging Settings установите следующие параметры: Enable logging — включено. Enable logging on the failover standby unit — включено. Send syslogs in EMBLEM format — включено. Send debug messages as syslogs — выключено. Memory Size of the Internal Buffer (bytes) — 524288 Продейлайте шаги 3-10, 14-24 для всех используемых Access Control Policy в вашей компании Настройка логирования и отправки собтий аудита FTD (Platform Settings) Войдите в веб-консоль Cisco FMC под учетной записью с правами администратора. В левом меню выберите Devices . В открывшемся окне выберите Platform Settings   В списке профилей Platform Settings выберите профиль, нажмите Edit, одним из следующих способов: нажмите на значок ✎ (Edit) справа от имени правила; либо щёлкните по профилю правой кнопкой мыши и выберите Edit . В настройках профиля перейдите на вкладку Syslog В открытом профиле Syslog перейдите на вкладку Logging Setup . В разделе Basic Logging Settings установите следующие параметры: Enable logging — включено. Enable logging on the failover standby unit — включено. Send syslogs in EMBLEM format — включено. Send debug messages as syslogs — выключено. Memory Size of the Internal Buffer (bytes) — 524288 Сохраните изменения, нажав Save в правом верхнем углу Перейдите на вкладку Event Lists . Нажмите кнопку Add . В открывшемся окне в поле Name укажите имя списка, например: to_siem ерейдите на вкладку Message ID, нажимая на кнопку +Add, добавьте следующие идентификаторы событий, разрешно добавлять значения по одному, либо диапазоном: 199017-199021 111008 111010-111012 110003 110005 110006 110201-110206 110101-110106 110301-110304 Нажмите OK. Сохраните изменения, нажав Save в правом верхнем углу Перейдите на вкладку Logging Destinations . В строке Syslog Servers нажмите на значок редактирования ✎ Edit Если у вас отсутсвует  Syslog Servers в качестве Logging Destination, нажмите +Add, у вас откроется окно с такими же параметрами для конфигурации. В открывшемся окне Edit Logging Filter установите следующие параметры: Logging Destination → Syslog Servers Event Class → Use Event List → Выбирте созданный ранее Event List, в нашем примере to_siem Нажмите OK. Сохраните изменения, нажав Save в правом верхнем углу Перейдите на вкладку Syslog Settings . Установите параметры: Facility — LOCAL4 (20) . Enable timestamp on syslog messages — включено. Timestamp Format — Legacy (MMM dd yyyy HH:mm:ss) или RFC 5424 (**yyyy-MM-ddTHH:mm:ss**) . Enable syslog device ID — включено. Device ID — Host Name . Выберите Enable All Syslog Messages . Logging Level — 5 - notifications . Сохраните изменения, нажав Save в правом верхнем углу Перейдите на вкладку Syslog Servers становите: Allow user traffic to pass when TCP syslog server is down — включено. Message Queue Size (Messages) — 8192 . Нажмите Add чтобы добавить новый syslog server . Заполните параметры: IP Address - IP-адрес системы, принимающей syslog-сообщения (SIEM / log-collector). Protocol - протокол передачи журналов: UDP - стандартный вариант передачи syslog-сообщений; (рекомендуемый формат) TCP - используется при необходимости гарантированной доставки; Secure Syslog (TLS) - используется при передаче логов по защищённому каналу. Port - порт приёма syslog-сообщений на стороне принимающей системы, согласно настройкам вашей SIEM. Log Messages in Cisco EMBLEM format (UDP only) - включить при использовании UDP для передачи сообщений в расширенном формате Cisco EMBLEM. Enable secure syslog - включается при использовании защищённого соединения (TLS). Reachable By - установить Device Management Interface - рекомендуется для отправки событий аудита и управления Нажмите OK. Сохраните изменения, нажав Save в правом верхнем углу Выполните Deploy конфигурации на FTD. Если в Platform Settings используется несколько профилей , необходимо выполнить настройки, описанные в пунктах 4–29, для каждого профиля отдельно Cisco ISE Информация об источнике Cisco Identity Services Engine (Cisco ISE) - централизованная платформа управления сетевым доступом, аутентификацией и авторизацией пользователей и устройств в корпоративной сети. Используется для реализации политик контроля доступа на основе идентичности при работе с проводными, беспроводными и VPN-подключениями, а также для интеграции с сетевым оборудованием и системами информационной безопасности. В рамках задач информационной безопасности Cisco ISE является источником событий аутентификации и авторизации, административных действий и учёта сессий доступа. Эти события применяются для мониторинга доступа, анализа инцидентов и формирования аудита в системах класса SIEM. Настройка отправки событий Cisco ISE во внешнюю SIEM по syslog Подключение к интерфейсу управления: В адресной строке браузера введите IP-адрес или доменное имя Cisco ISE. Выполните вход под учетной записью, входящей в группу администраторов. Создание профиля внешнего syslog-сервера: В главном меню выберите Administration → System → Logging . В левой части окна выберите Remote Logging Targets . В панели инструментов нажмите кнопку Add . В поле Name укажите имя профиля внешнего syslog-сервера. В поле IP/Host Address укажите IP-адрес или доменное имя сервера приёма syslog. В поле Port укажите порт, используемый для приёма syslog-сообщений. В поле Target Type выберите тип отправки ( UPD syslog / TCP syslog / Secure TCP ) В поле Facility Code выберите facility (например, LOCAL0 – LOCAL7 ) согласно принятой схеме на стороне SIEM В поле Maximum Length укажите максимальную длину syslog-сообщения 8192 Comply to RFC 3164 - Включите при необходимости, если SIEM ожидает формат сообщений по RFC 3164 Установите Status = Enabled Нажмите кнопку Submit пример законченной конфигурации: Настройка категорий журналирования В левой части окна выберите Logging Categories . Выберите категорию AAA Audit и в панели инструментов нажмите кнопку Edit . В списке Available выберите созданный профиль syslog-сервера, в нашем случае to_siem . Переместите выбранный профиль в список Selected, нажав на > . Параметры Severity и Local Log Severity - Значение уровня важности событий используется по умолчанию и не требует изменений в рамках данной настройки. Local Log - Параметр локального журналирования остается без изменений и настраивается в соответствии с требованиями и особенностями текущей конфигурации Cisco ISE. Нажмите кнопку Save . Повторите шаги с 1 по 5 для следующих категорий событий: Failed Attempts Passed Authentications Administrator Authentication and Authorization Accounting RADIUS Accounting TACACS Accounting Administrative and Operational Audit Проверка настройки отправки событий В веб-интерфейсе Cisco ISE перейдите в раздел Administration → System → Logging → Logging Categories . В списке категорий просмотрите колонку Targets . Для ранее настроенных категорий событий убедитесь, что в колонке Targets указан созданный профиль внешнего syslog-сервера, в нашем случае to_siem . Проверка выполняется для ранее настроенных категорий: AAA Audit Failed Attempts Passed Authentications Administrator Authentication and Authorization Accounting RADIUS Accounting TACACS Accounting Administrative and Operational Audit Если для указанных категорий в колонке Targets отображается созданный профиль, в нашем случае to_siem, настройка выполнена корректно, и события будут отправляться во внешнюю систему SIEM После выполнения указанных шагов Cisco ISE начинает отправлять выбранные категории событий во внешнюю систему SIEM по протоколу syslog Radware DefencePro Информация об источнике Radware DefensePro — это аппаратно-программная платформа защиты сети, предназначенная для предотвращения DDoS-атак, обнаружения аномалий трафика и защиты сервисов на уровнях L2–L7. Устройство обеспечивает анализ трафика в реальном времени, применяет поведенческие и сигнатурные модели, автоматически блокирует сетевые атаки и передаёт информацию о состоянии защищаемой инфраструктуры. Типы собираемых событий: Обнаружение и фиксация сетевых атак (Attack Start / Attack Update / Attack End) Поведенческие события и аномалии трафика Системные и аппаратные события (Health / System Status) События безопасности и протокольных нарушений Аудит действий пользователей Настройка отправки событий через Syslog Для интеграции Radware DefensePro с внешними системами мониторинга и SIEM необходимо настроить передачу событий по протоколу Syslog. Ниже представлены два поддерживаемых способа конфигурирования: через интерфейс APSolute Vision и через Web UI DefensePro . Вы можете использовать любой из методов в зависимости от доступного интерфейса управления устройством Настройка через APSolute Vision В интерфейсе APSolute перейдите в: "Configuration" > "Setup" → "Reporting Settings" → "Syslog" В ряде версий APSolute OS 10.x путь к настройкам syslog может отображаться как  "Setup" > "System" > "Logging" > "Syslog" .Это связано только с изменением структуры меню. Функциональность настройки syslog полностью соответствует инструкции Установите флажок "Enable Syslog" Выполните одно из действий: Чтобы добавить новый syslog-сервер, нажмите кнопку "Add" . Чтобы изменить существующую запись, дважды щёлкните по ней в таблице. Заполните следующие параметры, в соответствии с конфигруацией и требованиями вашей SIEM, и нажмите "Submit": "Enable Syslog Server" — включает или отключает отправку сообщений. "Syslog Server" — IP-адрес сервера, принимающего syslog (SIEM). "Source Port" — порт, который DefensePro использует для отправки сообщений. По умолчанию: 514 Значение 0 означает использование случайного порта. "Destination Port" — порт на стороне SIEM, принимающий syslog-сообщения. По умолчанию: 514 "Facility" — категория syslog-сообщений. По умолчанию: Local Use 6 "Protocol" — выбирается протокол передачи сообщений (выберите UDP ) Убедитесь, что включены все типы отчётов: "Send Security-Event Reports to Syslog" — отправка событий безопасности и атак. "Send Health-Event Reports to Syslog" — отправка событий состояния системы и оборудования. "Send Audit-Event Reports to Syslog" — отправка аудита действий пользователей. " Syslog Server CA Certificate " — используется только при передаче syslog поверх TLS (Syslog over TLS). При использовании UDP или обычного TCP это поле не заполняется. Настройка через Web UI DefensePro Войдите в Web UI DefensePro. Перейдите "Services" → "Syslog Reporting" В поле "Syslog Server Operational Status" выберите "Enabled" . Нажмите "Create" , чтобы добавить новую запись, или выберите существующую для редактирования. Заполните следующие параметры, в соответствии с конфигруацией и требованиями вашей SIEM, ****и нажмите "Set": "Syslog Server" — IP-адрес сервера SIEM/syslog. "Syslog Server Source Port" — исходящий порт DefensePro (обычно 514 ). "Syslog Server Destination Port" — порт приёма на SIEM (обычно 514 ). "Syslog Server Facility" — оставьте Local Use 6 , если нет иных требований. "Syslog Server Protocol" — выберите "UDP Protocol" . "Syslog Health Sending" — "Enabled" , отправка системных событий. "Syslog Security Sending" — "Enabled" , отправка security/attack событий. "Syslog User Audit Sending" — "Enabled" , отправка аудита действий пользователей. " Syslog Server CA Certificate " — используется только при передаче syslog поверх TLS (Syslog over TLS). При использовании UDP или обычного TCP это поле не заполняется. Fortinet FortiWeb Информация об источнике Fortinet FortiWeb — это специализированный Web Application Firewall, предназначенный для защиты веб-приложений и API от угроз уровня HTTP/HTTPS. Решение выявляет и блокирует атаки из OWASP Top 10, поведенческие аномалии, попытки brute force/credential stuffing, вредоносных ботов, нарушения схем API и ошибки протоколов. FortiWeb может работать в режимах reverse-proxy, transparent и load balancer, контролируя весь трафик между клиентом и backend-серверами. Помимо классического WAF-функционала, FortiWeb использует машинное обучение для анализа нормального поведения запросов, включает антибот-механизмы, инспекцию загрузок файлов, защиту API, контроль целостности cookie и Web-DLP для предотвращения утечки чувствительных данных (PCI/PII, файлы, ключевые слова). Система формирует отдельные журналы системных событий, трафика, атак, DLP-срабатываний, аномалий ML и ошибок backend-служб, обеспечивая подробную видимость веб-активности и инцидентов безопасности. Типы собираемых событий: System Events — изменение конфигурации, логины/логауты админов, ошибки служб, обновления сигнатур, состояние HA. Traffic Events — HTTP/HTTPS запросы, методы, URL, статус-коды, размеры запросов/ответов, время обработки. Attack Events (WAF Security) — SQLi, XSS, Command Injection, Path Traversal, File Inclusion, Protocol Anomalies, Brute Force, Credential Stuffing. Machine Learning Anomalies — отклонения от нормального поведения, аномальная структура запросов, параметры, частота запросов. Bot Mitigation — обнаружение вредоносных ботов, скраперов, автоматизированных клиентов, нарушения браузерных проверок. DLP Events — потенциальная утечка данных: PCI/PII, конфиденциальные шаблоны, ключевые слова, файлы в upload. File Upload Protection — результаты антивирусной проверки, недопустимые типы файлов, ошибки анализа архивов. API Protection Events — нарушения схемы OpenAPI, неправильные методы, неожиданные параметры, ошибки JSON/XML. Threat Intelligence Hits — совпадения с FortiGuard: злонамеренные IP, ботнет-источники, подозрительный трафик. Backend / Server Errors — недоступность backend-сервисов, ошибки health check, сбои reverse-proxy. Если в инфраструктуре используется FortiAnalyzer в качестве централизованного сборщика логов, настройка прямой передачи Syslog с устройства в SIEM не требуется . В этом случае необходимо убедиться, что: устройство зарегистрировано в FortiAnalyzer; события от устройства отображаются в FortiAnalyzer. Передача событий в SIEM выполняется централизованно с FortiAnalyzer Создание Syslog Policy Зайдите в веб-интерфейс FortiWeb под учетной записью с правами администратора В левом меню перейдите: “ Log&Report” → “Log Policy”→ “Syslog Policy” Нажмите “ Create New” В поле “ Name” укажите имя policy, например siem и нажмите OK В этом же окне “ Edit Syslog Policy” нажмите “ Create New” В открывшимся окне “ New Syslog Server” заполните: IP Address(IPv4) – IP адрес коллектора/syslog-сервера SIEM. Port – порт, на котором слушает коллектор (часто 514 для UDP/TCP или 6514 для TLS). Protocol – UDP , TCP или TLS в соответствии с требованиями SIEM. Format – **** CEF , либо другой формат в соответствии с требованиями SIEM. В разделе “ Available Custom Fields” вы можете добавить созданные у вас “ Custom Fields” , для этого выделите необходимые поля и нажмите на стрелочку вправо “ →”. После чего выбранные “ Custom Fields” должны оказаться в блоке “ Selected Custom Fields” Нажмите “ OK” , далее еще раз в окне “ Edit Syslog Policy” нажмите “ ОК” Включение отправки логов через Syslog Перейдите в меню: “ Log&Report” → “Log Config” → “Global Log Settings” В блоке “ Syslog” включите тумблер ( Enable ) В поле “ Syslog Policy” выберите созданную syslog policy, в нашем случае siem В поле “ Log Level” установите минимальный уровень, который хотите отправлять (по умолчанию Information ) В поле “ Facility” выберите одно из local-use значений (например, local7 ) или то, которое принято в вашей SIEM-стандартизации В блоке “ Log Type” отметьте все типы журналов для отправки: Event Log – системные события, логины админов, изменения конфигурации. Attack Log – срабатывания WAF, DLP, ML, ботов и т.д. Traffic Log – журналы HTTP/HTTPS-трафика В итоге у вас должна получиться следующая конфигурация Нажмите “ Apply” для сохранения настроек Web IIS Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Настройка IIS сервера 1. Откройте диспетчер служб IIS и перейдите в настройки требуемого сайта 2. В разделе IIS выберите "Ведение журнала". Задайте формат журнала "IIS" и укажите папку для хранения логов. После выполнения настроек в окне "Действия" нажмите применить. Формат логов должен быть именно IIS для возможности использования коробочного нормализатора Подробнее про данный формат логов: https://learn.microsoft.com/en-us/windows/win32/http/iis-logging   3. По умолчанию лог IIS будет записан в папку  C:\inetpub\logs\LogFiles . Для данной папки необходимо включить общий доступ на чтение. Монтирование папки в KUMA Для чтения файла логов коллектором KUMA необходимо примонтировать папку содержащую логи IIS сервера на сервер коллектора KUMA. 1. Для начала необходимо установить утилиту  cifs , если она еще не установлена. yum install -y cifs-utils 2. Далее необходимо создать файл с учетными данными пользователя для доступа к общей папке  /root/.iis-secret со следующим содержимым: username=<имя пользователя с правами на чтение папки> password=<пароль пользователя> domain=<домен, в случае доменного пользователя> 3. Далее нужно создать папку на сервере коллектора KUMA, куда будет примонтирована папка с логами DNS сервера. mkdir /mnt/iis 4. Далее в конец файла  /etc/fstab необходимо добавить строку \\<путь к общей папке сервера> <путь монтирования> cifs credentials=<файл с учетными данными>,cache=none 0 0 Пример: \\iis.demo.lab\dhcp /mnt/iis cifs credentials=/root/.iis-secret,cache=none 0 0 5. Далее необходимо примонтировать общую папку командой:  mount -a Для проверки успешности монтирования можно выполнить следующую команду:  ls /mnt/iis 6. Убедитесь, что у пользователя kuma есть права на чтение файлов логов из данной директории, а также возможность просматривать директории по пути к логам. Альтернативно, можно назначить пользователя kuma владельцем примонтированной папки: chown -R kuma:kuma /mnt/iis Создание коллектора KUMA Для создания коллектора KUMA необходимо в веб-консоли KUMA перейти на вкладку Ресурсы – Коллекторы и нажать на кнопку Добавить коллектор . Также можно на вкладке Ресурсы выбрать пункт Подключить источник . В обоих случая откроется мастер подключения источников событий. На первом шаге мастера необходимо выбрать Тенант , которому будет принадлежать коллектор и также задать Имя коллектора . На втором шаге мастера необходимо выбрать тип подключения file и указать маску пути для файлов логов IIS сервера.  На третьем шаге мастера необходимо выбрать предустановленный нормализатор [OOTB] IIS Log File Format . В случае отсутствия указанного нормализатора, обратитесь к своему менеджеру для его получения. Шаги мастера с четвертого по шестой можно пропустить, либо заполнить позднее по своему усмотрению. На седьмом шаге мастера необходимо указать точки назначения типа Хранилище , если требуется сохранение событий в БД и типа Коррелятор , если требуется корреляция событий. На последнем шаге мастера необходимо нажать на кнопку Сохранить и создать сервис , после чего скопировать появившуюся команду для дальнейшей установки сервиса коллектора. В результате на вкладке Ресурсы – Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Для установки сервиса коллектора необходимо подключиться к консоли сервера коллектора KUMA. Для установки сервиса коллектора необходимо выполнить скопированную команду. В результате статус коллектора в веб-интерфейсе KUMA изменится на зеленый . Для поиска событий IIS можно использовать следующий запрос SELECT * FROM `events` WHERE DeviceProduct = 'IIS' ORDER BY Timestamp DESC LIMIT 250 Apache Access Syslog Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Настройка Apache Для настройки пересылки access-лога веб-сервера apache в KUMA необходимо выполнить следующие действия: 1. Подключитесь к веб-серверу Apache 2. Создайте конфигурационный файл /etc/rsyslog.d/apache-access.log.conf и добавьте в него следующие строки: $ModLoad imfile $InputFileName /var/log/apache2/access.log $InputFileTag apache_access: $InputFileStateFile stat-apache-access $InputFileSeverity info $InputFileFacility local3 $InputRunFileMonitor $InputFilePollInterval 10 local3.* @:<порт коллектора> Если вы хотите отправлять события по протоколу TCP, последняя строчка должна выглядеть следующим образом: local3.* @@:<порт коллектора> 3. Перезапустите службу rsyslog. Для этого выполните команду: systemctl restart rsyslog Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий Apache Access Log. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне Apache. 2. На шаге Парсинг событий выберите нормализатор [OOTB] Apache Access Syslog (Common or Combined Log Format) . 3. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения Хранилище и Коррелятор не добавлены, создайте их. 4. На шаге Проверка параметров нажмите Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Кибер Бэкап (Cyber Backup) Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Настройка коллектора KUMA Настройка коллектора KUMA для приема и обработки событий Кибер Бэкап приведена в отдельной общей статье по созданию сервиса коллектора. На шаге Парсинг событий в качестве нормализатора для событий Кибер Бэкап выберите нормализатор [OOTB] Cyberprotect Cyber Backup syslog . Настройка Кибер Бэкап По умолчанию журнал аудита хранится в базе данных продукта Кибер Бэкап, однако для централизованного хранения и обработки можно настроить отправку записей журнала аудита в SIEM-систему. Для событий может использоваться протокол TCP, UDP или TLS. Чтобы настроить отправку событий  Кибер Бэкап в коллектор KUMA: В веб-интерфейсе Кибер Бэкап перейдите в Настройки → Параметры Syslog. В окне Параметры Syslog активируйте параметр Передавать журнал аудита на Syslog-сервер  и укажите: В поле Адрес удаленного сервера IP-адрес/DNS-имя сервера коллектора KUMA. Порт для подключения (используйте значение, заданное на шаге Транспорт при создании коллектора). Используемый протокол  (используйте значение, заданное на шаге Транспорт при создании коллектора). Формат сообщения , в котором будут отправляться события. Выберите CEF (RFC 3164) . Нажмите Отправить тестовое сообщения для проверки интеграции. Нажмите Сохранить . Опционально в Кибер Бэкап поддерживается настройка защищенного соединения с использованием протокола TLS. Проверка поступления событий Кибер Бэкап в KUMA Для проверки, что сбор событий  Кибер Бэкап успешно настроен перейдите в Ресурсы >  Активные сервисы > выберите ранее созданный коллектор для Кибер Бэкап > ПКМ > Перейти к событиям. В открывшемся окне  События убедитесь, что присутствуют события   Кибер Бэкап . Полезные ссылки Документация Кибер Бэкап 1С 1C:Предприятие (новые версии) Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Инсрукция на примере версии 8.3 Настройки на стороне 1С Конфигурация 1С выполняется от учетной записи, с правами локального администратора Windows. Выгрузка журнала регистрации информационной базы в локальную папку (JSON) Запустите 1С:Предприятие . Выберите в списке информационную базу и нажмите кнопку 1С:Предприятие, затем введите данные учетной записи администратора и нажмите кнопку Войти . В левой части окна нажмите НСИ и администрирование . Откройте вкладку Печатные формы, отчеты и обработки . Если не установлен флажок Дополнительные отчеты и обработки , установите его. Откройте вкладку Дополнительные отчеты и обработки . В панели инструментов вкладки нажмите кнопку Добавить из файла , затем в окне проводника Выберите файл внешнего отчета или обработки . Скачать архив  registration_log_json_upload.zip со сценарием для внешней обработки. Выберите файл и нажмите кнопку Открыть . Откроется вкладка дополнительная обработка (создание). В панели инструментов вкладки нажмите Значок сохранить. На вкладке Команды выберите строку Выгрузка журнала регистрации в формате JSON . Нажмите кнопку Выполнить . Откроется вкладка Выгрузка журнала регистрации в формате JSON. В поле директория для хранения файлов введите путь для сохранения файлов журнала регистрации‚ например С:\1С_Журнал . В поле Интервал выгрузки в минутах введите количество минут. за которые события журнала регистрации будут выгружаться в отдельный файл, рекомендуется 15 минут. В поле Дата выгрузки выберите дату, с которой начнется выгрузка журнала регистрации. Нажмите кнопку Сохранить настройки и подтвердите сохранение. Закройте вкладку Выгрузка журнала регистрации в формате JSON. На вкладке Команды в строке Выгрузка журнала регистрации в формате JSON установите флажок . Откроется окно Расписание . Выберите вкладку Дневное и в поле Повторять через введите 900 (количество секунд в 15 минутах). Время начала и окончания оставьте без изменений (пустым). Нажмите кнопку ОК . На вкладке Команды в строке Удаление старых файлов установите флажок . Откроется окно Расписание . Выберите вкладку Общие и в поле Повторять каждые введите 1 . Нажмите кнопку ОК . Нажмите кнопку Записать и закрыть .  Должно получиться следующее: Настройка журналирования событий технологического журнала Дополнительная информация по настройке - https://infostart.ru/1c/articles/2020498/   Чтобы настроить журналирование событий технологического журнала на сервере «1С:Предприятия»: Создайте конфигурационный файл logcfg.xml . Если вы используете Windows — в папке <Папка установки "1С:Предприятия">\bin\conf . Добавьте в файл служебные строки: Добавьте в файл в элемент строки с указанием пути для сохранения файлов журнала и времени хранения событий (в часах). Если вы используете Windows, укажите путь к общей папке: Добавьте в файл в элемент строки с фильтрами событий из подпунктов ниже, затем  Сохраните конфигурационный файл. Настройте общий доступ к папкам с файлами журналов (сетевую файловую шару). Фильтры по типам событий Успешная или неуспешная авторизация через толстый клиент, конфигуратор или СОМ-соединение Успешная авторизация через толстый клиент Ошибка авторизации через тонкий клиент Ошибка авторизации через веб-клиент Успешная авторизация через веб-клиент Успешно установлено соединение с сервером «1С:предприятия» Подключение к дизайнеру заблокировано другим пользователем Просмотр списка пользователей. подключенных к серверу «1С:Предприятия» Просмотр пользователем параметров информационной базы    Пример конфигурационного файла logcfg.xml Монтирование папки к KUMA Монтирование папки с журналом можно сделать по аналогии с  этой инструкцией. Пересылка многострочных XML-файлов 1C с помощью Linux-агента Зачастую создание файловых информационных ресурсов на хостах компании недопустимо с точки зрения действующих требований департамента информационной безопасности. В связи с этим использование стандартного коллектора 1с-xml с возможностью вычитки события через примонтированную к серверу коллектора шару реализовать невозможно. 1. Настройка коллектора и агента KUMA для нормализации многострочных XML-файлов 1C Конфигурация коллектора Название поля Значение поля Описание Collector name [xml][1C] - Multiline Название коллектора Transport → Kind tcp Тип Transport → URL :5180 Локальный порт, который слушает коллектор Event parsing → Name [OOTB] 1C EventJournal Normalizer Нормализатор для многострочных XML-файлов 1C Конфигурация агента Название поля Значение поля Описание Agent name [xml][1C] - Multiline Название агента Config → Connector → Name local - 1C-XML Название коннектора Config → Connector → Kind 1c-xml Тип Config → Connector → URL /opt/1c Директория xml-файлов 1C Config → Destinations → Name 1C-XML Название точки назначения Config → Destinations → Kind tcp Тип Config → Destinations → URL :5180 Сервер и порт коллектора для приема журналов 1C 2. Установка Linux-агента на хост для сбора XML-журналов 1C Для разового запуска Агента воспользуйтесь следующей командой: sudo /opt/kaspersky/kuma/kuma agent --core https://:7210 --id --wd /opt/kaspersky/agent/ Для автоматизации процесса сбора событий установите агент в качестве службы . Также можно воспользоваться утилитой supervisor . Для этого создайте конфигурационный файл (например, 1с.conf) в директории /etc/supervisor/conf.d/ со следующими настройками: [program:agent_5f45aee7-655c-4014-aacd-07e4548de8ae] command=sudo /opt/kaspersky/kuma/kuma agent --core https://:7210 --id --wd /opt/kaspersky/agent/ autostart=true autorestart=true Для применения конфигурации перезагрузите службу: sudo systemctl restart supervisor Для просмотра статуса и наличия ошибок воспользуйтесь следующей командой: sudo supervisorctl status 3. Проверка получения событий В веб-интерфейсе KUMA выберите коллектор и перейдите к событиям (Resources → Collector → Go to events). На основном экране появятся нормализованные события 1C, полученные с Linux-агента. 1С Битрикс (Bitrix) интеграция с KUMA Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Настройки на стороне 1С Создание пользователя для чтения логов 1) Подключитесь к машине на которой установлен 1С:Управление сайтом и запустите консоль mysql под рутом (по умолчанию не требует пароля). mysql -u root Если вы не знаете пароль, то его возможно восстановть, но это рекомендуется сначала делать на тестовом стенде:  https://dev.1c-bitrix.ru/community/forums/messages/forum32/topic63387/message727606/#message727606   2) В БД необходимо создать нового пользователя с правами на чтение журнала событий, вместо 10.10.10.10 укажите IP KUMA. CREATE USER 'kuma'@'10.10.10.10' IDENTIFIED BY 'password'; GRANT SELECT ON sitemanager.b_event_log TO 'kuma'@'10.10.10.10'; FLUSH PRIVILEGES; Настройки на стороне KUMA 1) Импортируйте ресурс (пароль q123123Q!q123123Q! ): https://box.kaspersky.com/f/4228c6d6741a429daff4/ 2) Измените секрет для подключения (Ресурсы -> Секреты -> 1С: Управление сайтом ), если используются спец символы, то пароль можно будет использовать следующий ресурс для преобразования  https://www.urlencoder.org/ mysql://kuma:password@tcp(10.10.10.11:3306)/sitemanager 5) При создании коллектора выберите коннектор и парсер - 1C:Управление сайтом, затем укажите точки назначения и создайте сервис. NXLog агент Альтернатива агента KUMA Windows Агент NXLog NXLog Community Edition может использоваться в качетсве альтернативного агента для сбора и отправки событий с файлов или Event журналов Windows, ниже будут примеры конфигураций для этих настроек: Сбор с файлов Загрузить Агент: https://nxlog.co/products/nxlog-community-edition/download Детали по маскам пути файлов: https://docs.nxlog.co/refman/v5.5/im/file.html Лог ошибок агента:  C:\Program Files\nxlog\data\nxlog.log Конфигурация агента находится по пути:  C:\Program Files\nxlog\conf\nxlog.conf После каждой правки конфигурации необходмо перезагружать службу агента NXLog Ниже пример конфигурации агента по cборe событий с файлов журналов WIndows DHCP и DNS с отправкой на коллектора KUMA по протоколу TCP:   Module  im_file   File    "C:\dhcp\Dhcp*.log"   #File    "C:\Windows\System32\dhcp\DhcpSrvLog*log"   Module  im_file   File    "C:\dns\dns.log"   Module        om_tcp   Host          10.68.85.125   Port          5177   Module        om_tcp   Host          10.68.85.125   Port          5178   Path          win_dhcp_file => to_kuma_dhcp   Path          win_dns_file => to_kuma_dns Чтение и отправка Event журналов Ниже пример конфигурации агента по cборe событий с журналов WIndows EventLog и отправка по HTTP:   Module      xm_xml   Module  im_msvistalog   #Module  im_mseventlog   Exec    to_xml();   Module  om_http   URL     http://10.68.85.129:5140/input   Path          win_log => to_kuma Linux Агент NXLog NXLog Community Edition может использоваться в качетсве альтернативного агента для сбора и отправки событий с файлов на ОС Linux. Необходимые пакеды для установки агента: https://box.kaspersky.com/f/ca3202dbb39b4b5c929c/   Загрузить Агент (для установки на Oracle Linux используйте RHEL пакет): https://nxlog.co/products/nxlog-community-edition/download Конфигурация агента находится по пути: /etc/nxlog/nxlog.conf Конфигурация сервиса находится по пути:  /etc/systemd/system/multi-user.target.wants/nxlog.service Опции запуска: ExecStartPre=/usr/bin/nxlog -v ExecStart=/usr/bin/nxlog -f ExecStop=/usr/bin/nxlog -s ExecReload=/usr/bin/nxlog -r Cloud/Container/VM Настройка аудита VMware ESXi и vCenter VMware ESXi Через веб-интерфейс Проверьте корректность настроек времени и часового пояса, проверить синхронизацию с NTP-сервером (принять во внимание, что ОС VMware ESXi работает только по UTC). Выполнить резервное копирование конфигурации ESXi-хоста. Через web-интерфейс подключиться к ESXi-хосту используя учетную запись root. В главном меню в разделе навигации развернуть вкладку Host и перейти по пути:   Host – Manage – Advanced Settings . В окне поиска набрать Syslog.global.LogHost , выбрать параметр Syslog.global.LogHost и отредактировать его. Укажите протокол, адрес и порт коллектора KUMA и нажмите Save . Далее перейдите на вкладку Networking – Firewall rules .  Найдите правило syslog, выделите его (можно воспользоваться поиском) и включите его, нажав на  Actions – Enable . Через SSH Настройку аудита можно выполнить через SSH. Включить доступ по SSH на ESXi-хосте, перейти по пунктам: Host  – Actions – Services – Enable Secure Shell (SSH) . Подключитесь к ESXi-хосту по SSH используя учетную запись root (например через Putty). Наберите команду: esxcli system syslog config set --loghost=udp://192.168.1.250:514 (конфигурирование подключения к syslog-серверу, ip-адрес в команде не является легитимным и указан исключительно для примера). Наберите команду:  esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true (включение разрешающего правила фильтрации для syslog). Наберите команду:  esxcli network firewall refresh (обновление настроек межсетевого экрана ESXi-хоста). Наберите команду:  esxcli system syslog config get (проверка настроек syslog-службы ESXi-хоста): Набрать команду: esxcli system syslog reload (перезагрузка syslog-службы ESXi-хоста). Авторизоваться на ESXi-хосте, через его web-интерфейс под учетной записью с административными правами и отключить доступ по SSH (примечание: Согласно рекомендациям VMware, доступы по SSH и к ESXi-shell нужны только во время диагностических и аварийных работ). (Опционально) Если необходимо отправлять события Syslog на другой порт назначения , необходимо добавить правило для МЭ ESXi, для этого зайдите на хост по SSH. Создайте файл (используются классические Linux команды) со следующим содержимым, например для порта 5140 (назовем файл syslogPort-5140.xml): syslogPort-5140 outbound udp dst 5140 outbound tcp dst 5140 false false Для использования этого правила выполните команды ниже, и активируйте его: cp syslogPort-5140.xml  /etc/vmware/firewall/ esxcli network firewall unload esxcli network firewall load VMware vCenter Сделайте snapshot или выполните резервное копирование vCenter. Через web-браузер подключитесь к vCenter Server Appliance Management Inteface (VAMI) используя административную учетную запись (например, administrator@vsphere.local). Наберите в web-браузере: https://vcenter.test.local:5480 и ввести административные учетные данные (имя vcenter.test.local не является легитимным и указан для примера). Убедитесь в корректности настроек времени в разделе Time (часовой пояс указан в качестве примера, а тип синхронизации в «Филиале» будет индивидуально зависеть от указанных местных настроек). Перейти в раздел Syslog , чтобы настроить Forwarding. Нажать кнопку CONFIGURE , укажите протокол, адрес и порт коллектора KUMA и нажмите Save . Отправьте тестовое сообщение: Kubernetes (k8s) via Rsyslog Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Общее Настройка логирования Kubernetes (k8s) выполняется путем модификации kube-apiserver. Подробное описание механизма аудита k8s приведено на официальном сайте . Данная инструкция предназначена для настройки аудита k8s для последующей передачи логов в KUMA. Настройка k8s 1. Необходимо подключиться к ноде k8s с ролью control plane 2. На ноде создаем директорию, куда будет помещена политика аудита sudo mkdir /etc/kubernetes/audit/ 3. В созданной директории создаем файл с политикой аудита  /etc/kubernetes/audit/audit-policy.yaml любым удобным способом. Содержимое файла может варьироваться от целей логирования, ниже приведен пример политики с официального сайта. Будьте внимательны, конфигурации в k8s как правило задаются в виде файлов YAML, которые чувствительны к отступам. Валидируйте файлы перед их применением во избежание ошибок. Пример политики аудита k8s apiVersion: audit.k8s.io/v1 # This is required. kind: Policy # Don't generate audit events for all requests in RequestReceived stage. omitStages: - "RequestReceived" rules: # Log pod changes at RequestResponse level - level: RequestResponse resources: - group: "" # Resource "pods" doesn't match requests to any subresource of pods, # which is consistent with the RBAC policy. resources: ["pods"] # Log "pods/log", "pods/status" at Metadata level - level: Metadata resources: - group: "" resources: ["pods/log", "pods/status"] # Don't log requests to a configmap called "controller-leader" - level: None resources: - group: "" resources: ["configmaps"] resourceNames: ["controller-leader"] # Don't log watch requests by the "system:kube-proxy" on endpoints or services - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" # core API group resources: ["endpoints", "services"] # Don't log authenticated requests to certain non-resource URL paths. - level: None userGroups: ["system:authenticated"] nonResourceURLs: - "/api*" # Wildcard matching. - "/version" # Log the request body of configmap changes in kube-system. - level: Request resources: - group: "" # core API group resources: ["configmaps"] # This rule only applies to resources in the "kube-system" namespace. # The empty string "" can be used to select non-namespaced resources. namespaces: ["kube-system"] # Log configmap and secret changes in all other namespaces at the Metadata level. - level: Metadata resources: - group: "" # core API group resources: ["secrets", "configmaps"] # Log all other resources in core and extensions at the Request level. - level: Request resources: - group: "" # core API group - group: "extensions" # Version of group should NOT be included. # A catch-all rule to log all other requests at the Metadata level. - level: Metadata # Long-running requests like watches that fall under this rule will not # generate an audit event in RequestReceived. omitStages: - "RequestReceived" 4. Далее создаем директорию, в которую будут записаны логи аудита k8s sudo mkdir -p /var/log/kubernetes/audit/ 5. Далее необходимо будет внести изменения в конфигурацию пода kube-apiserver. Перед этим настоятельно рекомендуется сделать резервную копию конфигурации, например, следующей командой из вашей рабочей директории: sudo cp /etc/kubernetes/manifests/kube-apiserver.yaml . 6. Вносим изменение в kube-apiserver с помощью команды: sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml 7. В секции  spec.containers.command указываем следующие флаги, соблюдая отступы: - --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml - --audit-log-path=/var/log/kubernetes/audit/audit.log Где /etc/kubernetes/audit/audit-policy.yaml - путь к политике аудита, а /var/log/kubernetes/audit/audit.log - путь к файлу для записи логов. 8. Дополнительно можно определить другие параметры логирования, такие как размер файла логов и количество файлов (подробное описание параметров можно найти  тут ): - --audit-log-maxsize=500 - --audit-log-maxbackup=3 Настройка секции spec.containers.command 9. Далее в том же файле создаем соответствующие тома и точки монтирования для политики и директории для хранения логов 10. В секцию volumes добавляем следующее соблюдая отступы: - hostPath: path: /etc/kubernetes/audit/audit-policy.yaml type: File name: audit - hostPath: path: /var/log/kubernetes/audit/ type: DirectoryOrCreate name: audit-log Здесь  /etc/kubernetes/audit/audit-policy.yaml - путь к политике аудита, а /var/log/kubernetes/audit/audit.log - путь к файлу для записи логов. Настройка секции volumes 11. В секцию volumeMounts добавляем следующее соблюдая отступы: - mountPath: /etc/kubernetes/audit/audit-policy.yaml name: audit readOnly: true - mountPath: /var/log/kubernetes/audit/ name: audit-log readOnly: false Настройка секции volumeMounts 12. Сохраняем все внесенные в файл измнения. Т.к. была изменена конфигурация kube-apiserver, то под будет пересоздан, что может потребовать примерно до 1 минуты времени. Если под не смог подняться, необходимо проверить все внесенные изменения на предмет ошибок и опечаток, а также изучить логи по пути /var/log/pods/ Если все было сделано правильно, то под kube-apiserver поднимется и в директории /var/log/kubernetes/audit/ появится файл audit.log и начнет наполняться логами k8s. Настройка Rsyslog Настройки ниже приведены для deb-систем. 1. Установка rsyslog apt install rsyslog 2. Включение и запуск службы rsyslog systemctl enable rsyslog.service systemctl start rsyslog.service 3. Создание файла конфигурации для отправки через rsyslog файла лога k8s nano /etc/rsyslog.d/k8s.conf Пример содержимого файла с отправкой по TCP: $ModLoad imfile $InputFileName /var/log/kubernetes/audit/audit.log $InputFileTag tag_k8s_log: $InputFileStateFile k8s_log $InputFileSeverity info $InputFileFacility local6 $InputRunFileMonitor local6.* @@10.10.10.10:7777 Где 10.10.10.10 - адрес коллектора KUMA, 7777 - порт коллектора KUMA Для отправки событий по протоколу UDP последнюю строчку следует заменить на: local6.* @10.10.10.10:7777 4. После сохранения изменений в файле необходимо перезапустить сервис Rsyslog командой: systemctl restart rsyslog.service Настройка коллектора KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий k8s . 1. На шаге  Транспорт  укажите тип и порт в соответствии с настройками на стороне  Kubernetes . 2. На шаге  Парсинг  событий выберите нормализатор  k8s via syslog . 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Пакет контента для k8s: https://github.com/KUMA-Community/kuma_content/tree/main/rules/app/kubernetes Документация по настройке аудита k8s: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/   Kubernetes (k8s) via webhook Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Данный способ является экспериментальным. Рекомендуемый способ приведен в статье k8s via rsyslog Общее Настройка логирования Kubernetes (k8s) выполняется путем модификации kube-apiserver. Подробное описание механизма аудита k8s приведено на официальном сайте . Данная инструкция предназначена для настройки аудита k8s для последующей передачи логов в KUMA. Настройка k8s 1. Необходимо подключиться к ноде k8s с ролью control plane 2. На ноде создаем директорию, куда будет помещена политика аудита sudo mkdir /etc/kubernetes/audit/ 3. В созданной директории создаем файл с политикой аудита  /etc/kubernetes/audit/audit-policy.yaml любым удобным способом. Содержимое файла может варьироваться от целей логирования, ниже приведен пример политики с официального сайта. Будьте внимательны, конфигурации в k8s как правило задаются в виде файлов YAML, которые чувствительны к отступам. Валидируйте файлы перед их применением во избежание ошибок. Пример политики аудита k8s apiVersion: audit.k8s.io/v1 # This is required. kind: Policy # Don't generate audit events for all requests in RequestReceived stage. omitStages: - "RequestReceived" rules: # Log pod changes at RequestResponse level - level: RequestResponse resources: - group: "" # Resource "pods" doesn't match requests to any subresource of pods, # which is consistent with the RBAC policy. resources: ["pods"] # Log "pods/log", "pods/status" at Metadata level - level: Metadata resources: - group: "" resources: ["pods/log", "pods/status"] # Don't log requests to a configmap called "controller-leader" - level: None resources: - group: "" resources: ["configmaps"] resourceNames: ["controller-leader"] # Don't log watch requests by the "system:kube-proxy" on endpoints or services - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" # core API group resources: ["endpoints", "services"] # Don't log authenticated requests to certain non-resource URL paths. - level: None userGroups: ["system:authenticated"] nonResourceURLs: - "/api*" # Wildcard matching. - "/version" # Log the request body of configmap changes in kube-system. - level: Request resources: - group: "" # core API group resources: ["configmaps"] # This rule only applies to resources in the "kube-system" namespace. # The empty string "" can be used to select non-namespaced resources. namespaces: ["kube-system"] # Log configmap and secret changes in all other namespaces at the Metadata level. - level: Metadata resources: - group: "" # core API group resources: ["secrets", "configmaps"] # Log all other resources in core and extensions at the Request level. - level: Request resources: - group: "" # core API group - group: "extensions" # Version of group should NOT be included. # A catch-all rule to log all other requests at the Metadata level. - level: Metadata # Long-running requests like watches that fall under this rule will not # generate an audit event in RequestReceived. omitStages: - "RequestReceived" 4. В этой же директории создаем файл /etc/kubernetes/audit/audit-webhook.yaml любым удобным способом. Пример содержимого файла приведен ниже: apiVersion: v1 kind: Config preferences: {} clusters: - name: kube-auditing cluster: server: http://10.10.10.10:7777/input users: [] contexts: - name: default-context context: cluster: kube-auditing user: "" current-context: default-context Где 10.10.10.10 - адрес коллектора KUMA, а 7777 - порт коллектора. Все прочие параметры из примера можно оставлять без изменений.5. Далее создаем директорию, в которую будут записаны логи аудита k8s 5. Далее необходимо будет внести изменения в конфигурацию пода kube-apiserver. Перед этим настоятельно рекомендуется сделать резервную копию конфигурации, например, следующей командой из вашей рабочей директории: sudo cp /etc/kubernetes/manifests/kube-apiserver.yaml . 6. Вносим изменение в kube-apiserver с помощью команды: sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml 7. В секции  spec.containers.command указываем следующие флаги, соблюдая отступы: - --audit-webhook-config-file=/etc/kubernetes/audit/audit-webhook.yaml - --audit-webhook-mode=batch - --audit-webhook-batch-max-size=1 Где /etc/kubernetes/audit/audit-policy.yaml - путь к политике аудита. Настройка секции spec.containers.command 9. Далее в том же файле создаем соответствующий том и точку монтирования для политик 10. В секцию volumes добавляем следующее соблюдая отступы: - hostPath: path: /etc/kubernetes/audit/ type: DirectoryOrCreate name: k8s-audit Здесь  /etc/kubernetes/audit/ - путь к директории с политикой аудита и настройками webhook Настройка секции volumes 11. В секцию volumeMounts добавляем следующее соблюдая отступы: - mountPath: /etc/kubernetes/audit/ name: k8s-audit readOnly: true Настройка секции volumeMounts 12. Сохраняем все внесенные в файл измнения. Т.к. была изменена конфигурация kube-apiserver, то под будет пересоздан, что может потребовать примерно до 1 минуты времени. Если под не смог подняться, необходимо проверить все внесенные изменения на предмет ошибок и опечаток, а также изучить логи по пути /var/log/pods/ Настройка коллектора KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий k8s . 1. На шаге  Транспорт  укажите тип и порт в соответствии с настройками на стороне  Kubernetes ( audit-webhook.yaml) . 2. На шаге  Парсинг  событий выберите нормализатор  k8s via webhook . 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Пакет контента для k8s: https://github.com/KUMA-Community/kuma_content/tree/main/rules/app/kubernetes Документация по настройке аудита k8s: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/   Docker via syslog Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Общее Настройка логирования Docker выполняется путем модификации /etc/docker/daemon.json , либо точечно для каждого контейнера через указание соответствующих параметров при запуске. В данной статье будет рассмотрен первый вариант. Настройка Docker 1. Необходимо подключиться к ноде Docker 2. На ноде создать файл конфигурации /etc/docker/daemon.json , либо внести изменения в существующий. Пример файла конфигурации представлен ниже. { "log-driver": "syslog", "log-opts": { "syslog-address": "tcp://10.10.10.10:6688", "tag": "{{.ID}}/{{.Name}}", "syslog-format": "rfc5424" } } Где, 10.10.10.10 - адрес коллектора KUMA, 66888 - порт коллектора KUMA. При необходимости можно также переопределить протокол передачи, формат логов и тегирование. Подробности см. по ссылке в конце статьи. 3. После внесения изменения в файл необходимо перезапустить службу Docker'а: systemctl restart docker.service В результате внесенных изменений события от Docker будут перенаправляться на сервис коллектора KUMA в соответствии с указанными параметрами. Альтернативно можно настроить логирование на стороне Docker в файл и перенаправлять его содержимое через rsyslog или путем монтирования папки/установки агента KUMA. Настройка коллектора KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий Docker . 1. На шаге  Транспорт  укажите тип и порт в соответствии с настройками на стороне  Docker . 2. На шаге  Парсинг  событий выберите нормализатор  [OOTB] Syslog . В дальнейшем можно использовать кастомные парсеры в зависимости от приложений, работающих в контейнерах Docker. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: - Хранилище . Для отправки обработанных событий в хранилище. - Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Документация по настройке syslog в Docker:  https://docs.docker.com/engine/logging/drivers/syslog/   Proxmox Virtual Environment Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Типы собираемых событий Аутентификация Создание / Удаление LXC-контейнеров и VM ( vzcreate , qmcreate , vzdestroy , qmdestroy ) Запуск / Остановка LXC-контейнеров и VM ( qmshutdown , qmstop , vzshutdown , vzstop ) Запуск / завершение задач Настройка сбора событий с помощью Rsyslog RSyslog — системный демон для журналирования в Linux. Он собирает события от различных источников (файлы логов, системные службы, journald) и отправляет их дальше по стандартному протоколу Syslog (UDP/TCP, а также с поддержкой TLS) 1. Проверьте статус сервиса RSyslog. Если сервис отсутствует - выполните установку пакета: ### Debian, Ubuntu (apt-get) apt-get install rsyslog ### RHEL (yum) yum install rsyslog или для поддержи TLS-шифрования при отправке логов установите библиотеку gtls для RSyslog: ### Debian, Ubuntu (apt-get) apt install rsyslog-gnutls ### RHEL (yum) yum install rsyslog-gnutls 2. Запустите сервис: systemctl enable rsyslog.service systemctl start rsyslog.service 3.Проверьте статус: systemctl status rsyslog.service 4. Создайте файл конфигурации для загрузки необходимых модулей   /etc/rsyslog.d/00-modules.conf Раскомментируйте секцию “ For journald ”. Для работы TLS: раскомментируйте секцию “ For tls ” module(load="imfile") ### For tls #module(load="gtls") #global(DefaultNetstreamDriver="gtls") ### For journald module(load="imjournal" StateFile="imjournal.state") 5. Добавьте файл конфигурации для логов  /etc/rsyslog.d/pve.conf if ($inputname == "imuxsock" and   ($programname == "pvedaemon"   )) then {           action(               name="fwd_pve_journal_tcp"               type="omfwd"               target="IP or FQDN" # IP or FQDN of Sysylog server (FQDN only for TLS)               port="port" # port of Sysylog server               protocol="tcp" # tcp or udp               # StreamDriver="gtls" # For TLS               # StreamDriverMode="1"  # For TLS               # StreamDriverAuthMode="anon" # For TLS without Verification               # StreamDriverAuthMode="x509/name" # For TLS with Verification               # StreamDriverPermittedPeer="FQDN" # For TLS with Verification               # tls.cacert="/etc/rsyslog/ca.crt" # For TLS with Verification               queue.type="LinkedList"               queue.size="10000"               action.resumeRetryCount="-1"       )       stop } 6. примените конфигурационные файлы RSyslog, перезапустите сервис, убедитесь в отсутствии ошибок  systemctl restart rsyslog.service systemctl status rsyslog.service Dr.Web Enterprise Security Suite Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ  является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://cdn-download.drweb.com/pub/drweb/esuite/13.0.1/documentation/html/ru/admin_manual/index.html?notifications_configure.htm   Настройка на стороне Dr.WEB Enterprise Security Suite Настройка производится под встроенным УЗ admin в его разделе Администрирование → Конфигурация оповещений У него два блока настроек оповещений: первый настроен под email; второй (SIEM KUMA) под Syslog. Для настройки в этой версии сервера Dr.Web лучше прямо под встроенным УЗ admin в консоль заходить. У других админов этот блок может быть не всегда виден, либо не работать кнопка тестового события, либо ещё что-то. Настройка коллектора KUMA по аналогии с этой главой (предварительно выберите тип коннектора UDP ) - ссылка Рекомендуемый парсер (без агрегации/склейки событий) для правил корреляции Community - [2024-09-23] Dr. Web CEF (из Community-Pack) PostgreSQL Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/251880.htm   Установка плагина pgAudit Чтобы установить плагин pgAudit: 1. В командном интерпретаторе выполните команды под учетной записью с правами администратора: sudo apt update sudo apt -y install postgresql-<версия базы данных PostgreSQL>-pgaudit Версию плагина необходимо выбрать в зависимости от версии СУБД PostgresSQL. Информацию о версиях СУБД PostgreSQL и необходимых версиях плагина см.по ссылке: https://github.com/pgaudit/pgaudit#postgresql-version-compatibility . Пример: sudo apt -y install postgresql-12-pgaudit 2. Найдите конфигурационный файл  postgres.conf . Для этого в командной строке СУБД PostgresSQL выполните команду: SHOW config_file; В ответе будет указано расположение конфигурационного файла. 3. Создайте резервную копию конфигурационного файла postgres.conf . Откройте файл postgres.conf и скопируйте или замените имеющиеся значения на указанные ниже. ## pgAudit settings shared_preload_libraries = 'pgaudit' ## database logging settings log_destination = 'syslog' ## syslog facility syslog_facility = 'LOCAL0' ## event ident syslog_ident = 'Postgres' ## sequence numbers in syslog syslog_sequence_numbers = on ## split messages in syslog syslog_split_messages = off ## message encoding lc_messages = 'en_US.UTF-8' ## min message level for logging client_min_messages = log ## min error message level for logging log_min_error_statement = info ## log checkpoints (buffers, restarts) log_checkpoints = off ## log query duration log_duration = off ## error description level log_error_verbosity = default ## user connections logging log_connections = on ## user disconnections logging log_disconnections = on ## log prefix format log_line_prefix = '%m|%a|%d|%p|%r|%i|%u| %e ' ## log_statement log_statement = 'none' ## hostname logging status. dns bane resolving affect #performance! log_hostname = off ## logging collector buffer status #logging_collector = off ## pg audit settings pgaudit.log_parameter = on pgaudit.log='ROLE, DDL, MISC, FUNCTION' 4. Перезапустите службу СУБД PostgreSQL при помощи команды: sudo systemctl restart postgresql 5. Чтобы загрузить плагин pgAudit в СУБД PostgreSQL, в командной строке СУБД PostgreSQL выполните команду: CREATE EXTENSION pgaudit; Настройка Syslog для отправки событий Чтобы настроить передачу событий от сервера, на котором установлена PostgreSQL, в коллектор: 1. Проверьте, что на сервере источника событий установлен сервис rsyslog. Для этого выполните следующую команду: sudo systemctl status rsyslog.service Если сервис rsyslog не установлен на сервере, установите его, выполнив следующие команды: yum install rsyslog sudo systemctl enable rsyslog.service sudo systemctl start rsyslog.service В каталоге /etc/rsyslog.d/ создайте файл pgsql-to-siem.conf со следующим содержанием: If $programname contains 'Postgres' then @:<порт коллектора> Если вы хотите отправлять события по протоколу TCP, содержимое файла должно быть таким: If $programname contains 'Postgres' then @@:<порт коллектора> В конфигурационный файл /etc/rsyslog.conf добавьте следующие строки: $IncludeConfig /etc/rsyslog.d/pgsql-to-siem.conf $RepeatedMsgReduction off Перезапустите сервис rsyslog, выполнив следующую команду: sudo systemctl restart rsyslog.service Настройка KUMA После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий pgAudit. 1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне pgAudit. 2. На шаге Парсинг событий выберите нормализатор [OOTB] PostgreSQL pgAudit syslog. 3. На шаге  Маршрутизация  проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения: Хранилище . Для отправки обработанных событий в хранилище. Коррелятор . Для отправки обработанных событий в коррелятор. Если точки назначения  Хранилище  и  Коррелятор  не добавлены, создайте их. 4. На шаге  Проверка параметров  нажмите  Сохранить и создать сервис . 5. Скопируйте появившуюся команду для установки коллектора KUMA. Полезные ссылки Настройка получения событий pgAudit (онлайн-справка KUMA):   https://support.kaspersky.com/help/KUMA/2.1/ru-RU/251880.htm   Битрикс24 (Bitrix24) CRM Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Настройка Битрикс24 CRM В данной статье рассматривается вариант, когда в качестве базы данных Битрикс24 CRM используется MySQL. Все настройки выполняются  в консоли сервера БД с помощью утилиты mysql . Вы можете использовать наиболее привычный для Вас способ. Протестировано на версии Битрикс24 CRM 24.0.400 Создание пользователя БД и предоставление прав В консоли сервера выполните подключение к БД MySQL с правами администратора (по умолчанию root ). mysql -u root -p Если пароль для пользователя root не установлен, попробуйте подключиться без -p Создайте нового пользователя, который сможет подключаться к серверу MySQL только с IP-адреса сервера KUMA (коллектора KUMA в случае распределенной инсталляции). CREATE USER 'kuma'@'10.10.10.10' IDENTIFIED BY '<задайте пароль>'; Предоставьте пользователю права доступа. В данном случае предоставляется право выполнять операцию SELECT (только чтение) к таблице  b_event_log в базе данных sitemanager . GRANT SELECT ON sitemanager.b_event_log TO 'kuma'@'10.10.10.10'; MySQL автоматически обновит привилегии для нового пользователя. Чтобы убедиться, что права были предоставлены корректно, выполните следующую команду для отображения прав созданного пользователя: SHOW GRANTS FOR 'kuma'@'10.10.10.10'; По умолчанию сервер MySQL настроен на работу только с локальным подключением через localhost. При необходимости разрешите удаленные запросы и входящие соединения на порт TCP/3306 (используется по умолчанию) на локальном МЭ. Настройка KUMA Импорт набора ресурсов Битрикс24 CRM MySQL Выполните импорт набора ресурсов KUMA для Битрикс24 CRM MySQL (пароль  q123123Q!q123123Q! ). Настройка секрета В веб-интерфейсе KUMA внесите изменения в ресурс Секрета Битрикс24 CRM MySQL, импортированный на предыдущем шаге, указав актуальные учетные данные для подключения к БД MySQL: Перейдите в Ресурсы > Секреты . Выберите секрет Битрикс24 CRM MySQL  и укажите Пользователя и Пароль. Настройка коннектора В веб-интерфейсе KUMA внесите изменения в ресурс Коннектора Битрикс24 CRM MySQL, импортированный на предыдущем шаге, указав актуальный URL-адрес сервера MySQL: Перейдите в раздел Ресурсы > Коннекторы. Выберите коннектор Битрикс24 CRM MySQL  и укажите актуальный URL-адрес сервера MySQL. В поле URL можно указать FQDN или IP-адрес сервера MySQL: mysql://user:password@tcp(mysql.example.com:3306)/sitemanager mysql://user:password@tcp(10.10.10.11:3306)/sitemanager В качестве идентификатора используется столбец ID. При необходимости Вы можете использовать столбец TIMESTAMP_X (если требуется собирать события, начиная с определенной даты) . Для этого измените значение в параметре Столбец идентификатора и внесите изменения в применяемый SQL-запрос. Создание коллектора Для сбора событий Битрикс24 CRM необходимо создать сервис коллектора в KUMA. Для этого в веб-интерфейсе KUMA перейдите в раздел Ресурсы  и нажмите на кнопку  Подключить источник. В появившемся окне мастера настройки Создание коллектора: На первом шаге ( Подключение источников ) выберите Имя коллектора и Тенант , к которому будет относиться создаваемый коллектор. На втором шаге мастера ( Транспорт ) укажите ранее созданный коннектор для подключения к БД MySQL. На третьем шаге мастера укажите импортированный ранее нормализатор  Битрикс24 CRM MySQL. Шаги мастера настройки с четвертого по шестой ( Фильтрация событий ,  Агрегация событий  и  Обогащение событий ) можно пропустить и вернуться к их настройке позднее. На седьмом шаге  Маршрутизация  задайте точки назначения. Для хранения событий добавьте точку назначения типа  Хранилище (Storage) . В случае если предполагается также анализ потока событий правилами корреляции добавьте точку назначения типа  Коррелятор (Correlator) . На завершающем шаге мастера Проверка параметров  нажмите на кнопку  Сохранить   и создать сервис . После чего появится команда установки сервиса, которую необходимо скопировать для дальнейшей установки. Нажмите Сохранить . После выполнения вышеуказанных действий в разделе Ресурсы > Активные сервисы появится созданный сервис коллектора. Установка коллектора KUMA Выполните подключение к  CLI  сервера  KUMA (коллектора KUMA при распределенной инсталляции). Для установки сервиса коллектора в командной строке выполните команду под учетной записью  root , скопированную на прошлом шаге. После успешной установки сервиса его статус в веб-интерфейсе KUMA изменится на  Вкл  с  зеленой индикацией . Проверка поступления событий Для проверки, что сбор событий Битрикс24 CRM из БД MySQL успешно настроен перейдите в Ресурсы  >  Активные сервисы > выберите ранее созданный коллектор Битрикс24 CRM MySQL > нажмите ПКМ >  Перейти к событиям. В открывшемся окне   События   убедитесь, что присутствуют события Битрикс24 CRM . ClickHouse (сбор событий аудита БД) Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и  НЕ является официальной рекомендацией вендора. Для настройки базового аудита Clickhouse понадобится: 1. Для логирования обычных запросов (в том числе grant, create, drop) включить логирование в основном файле  (по умолчанию включено): /etc/clickhouse-server/config.xml  в секции logger как минимум необходимо задать формат information ######################################### information ######################################### 2. Для логирования подключений, таких как: Login пользователя Failure logon Logout пользователя потребуется создать отдельный файл  /etc/clickhouse-server/config.d/session_log.xml  с содержимым: system session_log
7500 И отдельный файл  /etc/clickhouse-server/config.d/listen_port.xml С содержимым (для возможности удалённого подключения к БД): :: 3. Перезапустить службу командой systemctl restart clickhouse-server В базе system появится новая таблица со следующими колонками: Создаём пользователя для подключения к БД для KUMA и выдаём ему необходимые права следующим командами (с использованием ранее настроенного аудита): ###Шаг 1. Создание пользователя для коллектора KUMA CREATE USER kuma HOST IP '10.10.10.1/32' IDENTIFIED WITH sha256_password BY 'supersecretpassword'; ####Шаг 2. Создание VIEW для вывода нескольких запросов CREATE VIEW combined_logs AS SELECT event_time AS timestamp, query_kind AS deviceAction, user AS userName, toString(initial_address) AS sourceAddress, exception AS msg, query AS requestUrl, query_duration_ms AS dcs1, memory_usage AS dcs2 FROM system.query_log WHERE (query_kind IN ('Grant', 'Create', 'Drop')) OR (query_duration_ms > 600000) OR (memory_usage > 1000000000) UNION ALL SELECT event_time AS timestamp, type AS deviceAction, user AS userName, toString(client_address) AS sourceAddress, failure_reason AS msg, NULL AS requestUrl, NULL AS dcs1, NULL AS dcs2 FROM system.session_log WHERE type IN ('LoginFailure', 'LoginSuccess') ORDER BY timestamp DESC ####Шаг 3. Назначение прав на VIEW GRANT SELECT ON combined_logs TO kuma GRANT SELECT ON system.session_log TO kuma GRANT SELECT ON system.query_log TO kuma Пример как выглядит вывод VIEW: Настройка инстанса завершена, можно приступать к подключению логов в KUMA. Итого данной View мы выводим следующие события: Login пользователя Failure logon Logout пользователя Длительный запрос в базу (более 10 минут, как пример)(условие query_duration_ms > '600000' в запросе ) Большое потребление памяти при запросе (более 1 Гб, как пример)(условие memory_usage > '1000000000') Создание пользователя Назначение прав пользователю Удаление пользователя В KUMA необходимо создать коллектор с транспортом sql (плейсхолдер для Clickhouse - ?) и параметрами как на скриншоте (для примера указаны разные версии): Корректный запрос: SELECT * FROM combined_logs WHERE timestamp > parseDateTimeBestEffort(?) Выбираем нормализатор Clickhouse ( доступен в Community pack ), добавляем необходимые точки назначения и инсталлируем службу коллектора. Либо, если нам не нужны события входа в БД можем использовать запрос только в таблицу по умолчанию: ###Шаг 1. Создание пользователя для коллектора KUMA CREATE USER kuma HOST IP '10.10.10.1/32' IDENTIFIED WITH sha256_password BY 'supersecretpassword'; ####Шаг 2. Назначение прав на выполнение SELECT к system.query_log GRANT SELECT ON system.query_log TO kuma ####Шаг 3. Используем запрос для KUMA коллектора SELECT event_time AS timestamp, query_kind AS deviceAction, user AS userName, toString(initial_address) AS sourceAddress, exception AS msg, query AS requestUrl, query_duration_ms AS dcs1, memory_usage AS dcs2 FROM system.query_log WHERE query_kind IN ('Grant', 'Create', 'Drop') OR query_duration_ms > '600000' OR memory_usage > '1000000000' AND timestamp > ? ORDER BY timestamp DESC ALD Pro отправка логов Ссылка на документацию вендора: https://wiki.astralinux.ru/kb/nastrojka-syslog-ng-dlya-peredachi-logov-v-siem-sistemu-348162837.html   Файл pdf: Настройка_syslog_ng_для_передачи_логов_в_SIEM_систему_v1_20250218.pdf