Unix
- Настройка AuditD на Unix системах
- Сбор событий auditd с помощью Syslog-ng
- Сбор событий AuditD с помощью Rsyslog
- Передача многострочных файлов при помощи rsyslog
Настройка 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"); # <PRI> задан вручную, т.к. при flags(no-parse) ${PRI} не извлекается из события. Тег auditd задан руками, иначе будет дефолтное 0d.
template_escape(no);
};
destination d_kuma {
tcp("<IP-адрес/FQDN коллектора KUMA>" 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"); # <PRI> задан вручную, т.к. при flags(no-parse) ${PRI} не извлекается из события. Тег auditd задан руками, иначе будет дефолтное 0d.
template_escape(no);
};
destination d_kuma {
udp("<IP-адрес/FQDN коллектора KUMA>" 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"); # <PRI> задан вручную, т.к. при flags(no-parse) ${PRI} не извлекается из события. Тег auditd задан руками, иначе будет дефолтное 0d.
template_escape(no);
};
destination d_kuma {
tcp("<IP-адрес/FQDN коллектора KUMA>" 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:
- Удалите или переименуйте ранее созданный файл конфигурации для отправки событий по TCP, например,
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"); # <PRI> задан вручную, т.к. при flags(no-parse) ${PRI} не извлекается из события. Тег auditd задан руками, иначе будет дефолтное 0d.
template_escape(no);
};
destination d_kuma {
network("<IP-адрес/FQDN коллектора KUMA>" 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:
- Удалите или переименуйте ранее созданный файл конфигурации для отправки событий по TCP, например,
syslog-ng -s
-
- Если ошибки при проверке конфигурации отсутствуют перезапустите сервис syslog-ng, выполнив следующую команду:
systemctl restart syslog-ng
Рабочая станция/сервер Linux настроены. События передаются в коллектор KUMA с использованием TLS и валидацией сертификата.
Справочные материалы
https://syslog-ng.github.io/admin-guide/README
Сбор событий 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.* @<ip адрес коллектора KUMA>:<порт коллектора KUMA>
Для отправки событий по протоколу TCP последнюю строчку следует заменить на:
local6.* @@<ip адрес коллектора KUMA>:<порт коллектора 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 @@<ip адрес коллектора KUMA>:<порт коллектора 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.* @<ip адрес коллектора KUMA>:<порт коллектора 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, <internal>)
(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"