Настройка правил журналирования службы auditd

AlexeyAK

New member
Сообщения
1
#1
Имеем: чистую Astra Linux 1.6 SE релиз Smolensk с пакетом обнов от октября.
Версия auditd 2.6.7-2 последняя из репа астры.

При настройке службы auditd для выгрузки логов в MP SIEM возникает проблема на этапе применения рекомендуемых правил журналирования.
Система сразу уходит в backlog limit exceeded при установке log_format = enriched и ребуте системы.

Журнал забит SYS_CALL’ами чуть больше чем полностью. Так например служба nscd забивает лог тысячами сообщений в секунду по правилу:
Код:
-a always,exit -F arch=b64 -S accept4 -k pt_siem_api_accept
а при каждом вызове aureport -s лог удваивается в количестве записей (по одной записи aureport на каждую выведенную строчку) по правилу:
Код:
-a always,exit -S all -F path=/etc/passwd -F perm=r -F auid!=-1 -k pt_siem_etc_read.
Ну и также тысячи других сообщений, которые явно выведут оператора SIEM из себя.

Решение нашёл в удалении ncsd и установке фильтров-исключений на некоторые службы системы, но исключений получается несколько десятков.
Удивляет спам в аудит вызовов sendmail, cupds, pactrl, pulseaudio, а также десятков fly-* и других сервисов при простое системы.

Cписок рекомендуемых правил журналирования и настроек формата событий во вложении.
 

Вложения

Последнее редактирование:

oko

New member
Сообщения
769
#2
*в сторону*
Обожаю Позитивные поделия за их умелую политику не выкладывать в общий доступ ни мануалы, ни детализацию принципов работы. С другой стороны, при покупке MaxPatrol обычно берется техподдержка - так что нехай Позитивные ребята отрабатывают полученные бабки...
Ну и RHEL-порты systemd-служб в Debian - отдельная песня, ага...

to AlexeyAK
Primo, в чистой ALSE с крайними обновлениями даже при учете установки с графикой nscd отсутствует по умолчанию. Так что спам в логе у вас явно не по дефолту произошел...
Secundo, проверил auditd с ENRICHED, но без ключей для MaxPatrol (по причине ее отсутствия) - быстрый рост /var/log/audit/audit.log, но загрузка/работа/завершение работы стабильные...
Вы далее события аудита передаете по syslog в SIEM на удаленном хосте? Или у них какой-то промежуточный агент, инсталлированный в ALSE, используется? Модуль экстрасенсорики подсказывает, что в вашем случае проблема либо в дисковой подсистеме, либо в настроенных лимитах (при чистой установке их не трогал), связанных с чрезмерной нагрузкой из-за потока событий, передаваемых в SIEM (что, повторюсь, в чистой ALSE не наблюдается)...