Настройка журналов auditd. Мониторинг событий на сервере Linux.

testsoft.net soc monitor view (kibana)

В этой статье рассказывается о настройках “auditd” на сервере Linux. Первая часть статьи посвящена базовым (стартовым) настройкам аудита. Во второй части статьи речь пойдет об организации дополнительного мониторинга сервера. Например, web-сервера, находящегося в “открытом” интернет пространстве.

ЧАСТЬ 1. БАЗОВАЯ НАСТРОЙКА.
устанавливаем пакет auditd на сервер:
apt-get install auditd

root@usa-wordpress-1:/etc# apt-get install auditd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libauparse0
Suggested packages:
  audispd-plugins
The following NEW packages will be installed:
  auditd libauparse0
0 upgraded, 2 newly installed, 0 to remove and 137 not upgraded.
Need to get 243 kB of archives.
After this operation, 803 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://mirrors.digitalocean.com/ubuntu bionic-updates/main amd64 libauparse0 amd64 1:2.8.2-1ubuntu1.1 [48.8 kB]
Get:2 http://mirrors.digitalocean.com/ubuntu bionic-updates/main amd64 auditd amd64 1:2.8.2-1ubuntu1.1 [194 kB]
Fetched 243 kB in 0s (2658 kB/s)
Selecting previously unselected package libauparse0:amd64.
(Reading database ... 97358 files and directories currently installed.)
Preparing to unpack .../libauparse0_1%3a2.8.2-1ubuntu1.1_amd64.deb ...
Unpacking libauparse0:amd64 (1:2.8.2-1ubuntu1.1) ...
Selecting previously unselected package auditd.
Preparing to unpack .../auditd_1%3a2.8.2-1ubuntu1.1_amd64.deb ...
Unpacking auditd (1:2.8.2-1ubuntu1.1) ...
Setting up libauparse0:amd64 (1:2.8.2-1ubuntu1.1) ...
Setting up auditd (1:2.8.2-1ubuntu1.1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /lib/systemd/system/auditd.service.
Processing triggers for systemd (237-3ubuntu10.50) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for libc-bin (2.27-3ubuntu1.2) ...

Устанавливаем автозапуск:
systemctl enable auditd

root@usa-wordpress-1:/etc# systemctl enable auditd
Synchronizing state of auditd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable auditd

Проверяем статус работы auditd:
systemctl status auditd

root@usa-wordpress-1:/etc# systemctl status auditd
● auditd.service - Security Auditing Service
   Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2022-01-03 12:25:17 UTC; 14min ago
     Docs: man:auditd(8)
           https://github.com/linux-audit/audit-documentation
 Main PID: 30760 (auditd)
    Tasks: 2 (limit: 1151)
   CGroup: /system.slice/auditd.service
           └─30760 /sbin/auditd

Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: backlog 0
Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: backlog_wait_time 15000
Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: enabled 1
Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: failure 1
Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: pid 30760
Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: rate_limit 0
Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: backlog_limit 8192
Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: lost 0
Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: backlog 1
Jan 03 12:25:17 usa-wordpress-1 augenrules[30767]: backlog_wait_time 0

Проверяем появление логов в папке “/var/log/audit/”
ls -la /var/log/audit/

root@usa-wordpress-1:/etc# ls -la /var/log/audit/
total 16
drwxr-x---  2 root adm    4096 Jan  3 12:25 .
drwxrwxr-x 13 root syslog 4096 Jan  3 12:25 ..
-rw-r-----  1 root adm    4443 Jan  3 12:39 audit.log

Базовые правила находятся в папке:
ls -la /etc/audit/rules.d/

root@usa-wordpress-1:/etc# ls -la /etc/audit/rules.d/
total 12
drwxr-x--- 2 root root 4096 Jan  3 13:03 .
drwxr-x--- 3 root root 4096 Jan  3 12:25 ..
-rw-r----- 1 root root  240 Jan  8  2021 audit.rules

И имеют следующий вид:
vi /etc/audit/rules.d/audit.rules

## First rule - delete all
-D

## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192

## This determine how long to wait in burst of events
--backlog_wait_time 0

## Set failure mode to syslog
-f 1

В результате настройки auditd “из коробки” log-файлы будут иметь следующий вид:
tail -f /var/log/audit/audit.log

root@usa-wordpress-1:/etc# tail -f /var/log/audit/audit.log
type=CRED_DISP msg=audit(1641213541.998:36): pid=31008 uid=0 auid=0 ses=3236 msg='op=PAM:setcred acct="root" exe="/usr/sbin/cron" hostname=? addr=? terminal=cron res=success'
type=USER_END msg=audit(1641213541.998:37): pid=31008 uid=0 auid=0 ses=3236 msg='op=PAM:session_close acct="root" exe="/usr/sbin/cron" hostname=? addr=? terminal=cron res=success'
type=SERVICE_START msg=audit(1641213548.474:38): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=phpsessionclean comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1641213548.474:39): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=phpsessionclean comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_LOGIN msg=audit(1641213571.763:40): pid=31083 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr=176.111.173.226 terminal=sshd res=failed'
type=USER_LOGIN msg=audit(1641213571.763:41): pid=31083 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr=176.111.173.226 terminal=sshd res=failed'
type=USER_ERR msg=audit(1641213581.107:42): pid=31083 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:bad_ident acct="?" exe="/usr/sbin/sshd" hostname=176.111.173.226 addr=176.111.173.226 terminal=ssh res=failed'
type=USER_LOGIN msg=audit(1641214023.198:43): pid=31207 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr=121.61.115.66 terminal=sshd res=failed'
type=USER_LOGIN msg=audit(1641214023.202:44): pid=31207 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr=121.61.115.66 terminal=sshd res=failed'
type=USER_ERR msg=audit(1641214023.974:45): pid=31207 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:bad_ident acct="?" exe="/usr/sbin/sshd" hostname=121.61.115.66 addr=121.61.115.66 terminal=ssh res=failed'

Обратите внимание, что время указывается в формате unix “msg=audit(1641213541.998:36)”, число “1641213541” переводится в “Mon Jan 03 2022 12:39:01 GMT+0000”. Разберем базовые типы событий безопасности в журнале “auditd”. Тип события указывется после слова “type=”.

1.1 События входа в систему
События успешного/неуспешного входа в систему являются основными для информационной безопасности:
• USER_LOGIN – вход пользователя в систему.
• res=failed – неудачная попытка входа.
• res=success – удачная попытка входа.

type=USER_LOGIN msg=audit(1641213571.763:41): pid=31083 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr=192.168.88.253 terminal=sshd res=failed'

Значение строки: неуспешная (res=failed) попытка подключится по ssh (exe=”/usr/sbin/sshd”) к системе с IP адреса 192.168.88.253

type=USER_LOGIN msg=audit(1641225049.611:197): pid=32144 uid=0 auid=0 ses=3246 msg='op=login id=0 exe="/usr/sbin/sshd" hostname=192.168.88.253 addr=192.168.88.253 terminal=/dev/pts/0 res=success'

Значение строки: успешное (res=success) подключение по ssh (exe=”/usr/sbin/sshd”) с IP адреса 192.168.88.253, с использованием терминала (terminal=/dev/pts/0), пользователя root (id=0)

1.2 События создания/удаления/изменения пользователей
• ADD_USER – событие добавления пользователя.
• ADD_GROUP – событие добавления группы.
• USER_CHAUTHTOK – изменение атрибутов учетной записи пользователя.
• USER_ACCT – изменение учетной записи пользователя в пространстве пользователя.
• DEL_USER – событие удаления пользователя.
• DEL_GROUP – событие удаления группы.

type=ADD_USER msg=audit(1641226619.455:235): pid=32391 uid=0 auid=0 ses=3249 msg='op=adding user id=1000 exe="/usr/sbin/useradd" hostname=usa-wordpress-1 addr=? terminal=pts/0 res=success'
type=ADD_GROUP msg=audit(1641226619.447:234): pid=32391 uid=0 auid=0 ses=3249 msg='op=adding group acct="testsoft" exe="/usr/sbin/useradd" hostname=usa-wordpress-1 addr=? terminal=pts/0 res=success'

Значение строк: создан новый пользователь и группа “testsoft” в системе.

type=USER_CHAUTHTOK msg=audit(1641228693.605:376): pid=850 uid=0 auid=0 ses=3263 msg='op=adding user to group acct="testsoft" exe="/usr/sbin/usermod" hostname=usa-wordpress-1 addr=? terminal=pts/0 res=success'
type=USER_CHAUTHTOK msg=audit(1641228693.605:377): pid=850 uid=0 auid=0 ses=3263 msg='op=adding user to shadow group acct="testsoft" exe="/usr/sbin/usermod" hostname=usa-wordpress-1 addr=? terminal=pts/0 res=success'

Значение строк: пользователь “testsoft” добавлен в группу “sudo”.
Выполнена команда: “sudo usermod -aG sudo testsoft”.

type=USER_ACCT msg=audit(1641230486.196:475): pid=1384 uid=0 auid=0 ses=3267 msg='op=user testsoft removed by root from group sudo acct="sudo" exe="/usr/bin/gpasswd" hostname=usa-wordpress-1 addr=? terminal=pts/0 res=success'

Значение строки: пользователь “root” удалил пользователя “testsoft” из группы “sudo”.
Выполнена команда: “gpasswd -d testsoft sudo”.

type=DEL_GROUP msg=audit(1641230938.487:489): pid=1414 uid=0 auid=0 ses=3267 msg='op=deleting shadow group acct="testsoft" exe="/usr/sbin/userdel" hostname=usa-wordpress-1 addr=? terminal=pts/0 res=success'
type=DEL_GROUP msg=audit(1641230938.487:488): pid=1414 uid=0 auid=0 ses=3267 msg='op=deleting group acct="testsoft" exe="/usr/sbin/userdel" hostname=usa-wordpress-1 addr=? terminal=pts/0 res=success'
type=DEL_USER msg=audit(1641230938.479:487): pid=1414 uid=0 auid=0 ses=3267 msg='op=deleting user entries id=1000 exe="/usr/sbin/userdel" hostname=usa-wordpress-1 addr=? terminal=pts/0 res=success'

Значение строки: удален пользователь и группа “testsoft”.
Выполнена команда: “userdel testsoft”.

1.3 События старта/остановки сервисов
• SERVICE_START – событие запуска сервиса.
• SERVICE_STOP – событие остановки сервиса.

type=SERVICE_START msg=audit(1641234390.679:568): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=ssh comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1641234390.615:567): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=ssh comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Значение строк: пользователем root остановлен и запущен сервис “ssh”.
Выполнена команда: “service sshd restart”.

1.4 События вызова системных функций
SYSCALL – Вызов системной функции ядра.
PROCTITLE – Запись содержит командную строку, которая вызвала событие SYSCALL.

type=PROCTITLE msg=audit(1641234187.230:560): proctitle=69707461626C6573002D77002D49006632622D737368640031002D7300382E382E382E38002D6A0052454A454354002D2D72656A6563742D776974680069636D702D706F72742D756E726561636861626C65 
type=SYSCALL msg=audit(1641234187.230:560): arch=c000003e syscall=54 success=yes exit=0 a0=4 a1=0 a2=40 a3=56311562ac20 items=0 ppid=1709 pid=1710 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/xtables-multi" key=(null)

Значение “proctitle=” возможно привести в читаемый вид при помощи ASCII HEX DECODE. В примере это команда: “iptables -w -I f2b-sshd 1 -s 8.8.8.8 -j REJECT –reject -withicmp -port -unreachable”.

auditd basic config
Распределение типов событий “auditd” с сервера testsoft.net во время написания статьи.

ЧАСТЬ 2. СОЗДАНИЕ СОБСТВЕННЫХ ПРАВИЛ АУДИТА
После запуска “auditd” с базовыми настройками, все работает “без заморочек” и сразу. Есть возможность узнать кто заходил в систему, изменял свойства пользователей, стартовал и останавливал процессы в системе. Но, по опыту расследований могу сказать, что базовые настройки “auditd” не дают полной картины проиходящего. А связано это с тем, что в Linux системах есть свойста, которые не затрагивает настройка из “коробки”. Любой мониторинг и защита Linux серверов начинается с правильных настроек “auditd”, а уже потом идут log-файлы (логи) прикладного програмного обеспечения, web-серверов, баз данных и т.д. Для начала научимся создавать новые правила для мониторинга событий. Самый простой способ сделать это – добавить строки (внизу) в файл audit.rules, который имеет следующий вид:
vi /etc/audit/rules.d/audit.rules

## First rule - delete all
-D

## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192

## This determine how long to wait in burst of events
--backlog_wait_time 0

## Set failure mode to syslog
-f 1

Также можно добавить новый файл в директорию “/etc/audit/rules.d/”, в котором будут находится новые правила (такой способ мне нравится больше).

2.1 Определение правил файловой системы
Начнем с аудита действий файловой системы. Новое правило будет иметь следующий синтактсис:

-w <путь к файлу> -p <разрешения/доступ> -k <ключ>

<путь к файлу> – файл или каталог для мониторинга.
<разрешения/доступ> – тип доступа, который регистрируются в журнале:
• r — доступ на чтение к файлу или каталогу.
• w — доступ на запись к файлу или каталогу.
• x — выполнить доступ к файлу или каталогу.
• a — изменение атрибута файла или каталога.

<ключ> – это необязательный параметр, который помогает определить, какая строка или правило сработало. Обычно ключи используются для фильтрации событий в SIEM системах, но они помогают поиску событий и в самой системе, например, с помощью инструмента “grep”.

Создадим файл “testsoft.rules” и добавим в него строки правил для мониторинга событий записи (w) и изменения атрибутов (a) в следующих каталогах:
vi /etc/audit/rules.d/testsoft.rules

# File System Rules - system path write and change
-w /etc -p wa -k filesystem
-w /home -p rwa -k filesystem
-w /root -p rwa -k filesystem
-w /bin -p wa -k filesystem
-w /boot -p wa -k filesystem
-w /usr/bin -p wa -k filesystem
-w /sbin -p wa -k filesystem
-w /usr/sbin -p wa -k filesystem
-w /usr/local/bin -p wa -k filesystem
-w /usr/local/sbin -p wa -k filesystem
-w /usr/libexec -p wa -k filesystem
-w /lib -p wa -k filesystem
-w /lib64 -p wa -k filesystem
-w /usr/lib -p wa -k filesystem
-w /usr/lib64 -p wa -k filesystem
-w /var/spool/cron -p wa -k filesystem

# File System Rules - new file in web directory
-w /var/www -p wa -k filesystem_www

Обратите внимание, что строка правила “-w /var/www -p wa -k filesystem_www” имеет отдельный ключ. Использование отдельного ключа для событий в директории “/var/www/” позволит проводить аудит появления новых файлов в директории web-сервера. Быстро обнаруженный “чужой” файл сэкономит время при расследовании инцидента, т.к. большая часть атак на web-ресурсы предполагает создание/загрузку файла с помощью которого нападающий будет управлять вашим сервером (различные варианты webshell).

Теперь, появление любого файла в директории “/var/www/”, отобразится в журнале linux:
ausearch -k filesystem_www

time->Thu Jan  6 16:34:45 2022
type=PROCTITLE msg=audit(1641486885.967:25118): proctitle=7669002F7661722F7777772F68746D6C2F612D6E756B612D6E756B612E706870
type=PATH msg=audit(1641486885.967:25118): item=1 name="/var/www/html/a-nuka-nuka.php" inode=258397 dev=fc:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1641486885.967:25118): item=0 name="/var/www/html/" inode=258071 dev=fc:01 mode=040755 ouid=33 ogid=33 rdev=00:00 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1641486885.967:25118): cwd="/root"
type=SYSCALL msg=audit(1641486885.967:25118): arch=c000003e syscall=257 success=yes exit=4 a0=ffffff9c a1=55b866ca5670 a2=41 a3=1b6 items=2 ppid=30061 pid=31244 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3513 comm="vi" exe="/usr/bin/vim.basic" key="filesystem_www"

Обратите внимание на значение “nametype=CREATE” – это событие создания файла.

2.2 Определение правил системных вызовов
Теперь стоит обратить внимание на мониторинг событий системных вызовов операционной системы linux. Новое правило будет иметь следующий синтактсис:

-a <действие>,<фильтр> -F <поле>=<значение> -S <системный вызов> -k <ключ>

<действие> – определяет когда регистрируется событие:
• always -событие регистрируется всегда;
• never – событие не регистрируется.

<фильтр> – указывает, какой фильтр, соответствующий правилам ядра, применяется к событию:
• task – создание процессов;
• entry – вход в системный вызов;
• exit – выхода из системного вызова;
• user – события, происходящие в пользовательском пространстве;
• exclude – исключения событий.

<поле>=<значение> – задает дополнительные параметры, идентификатор группы, идентификатор процесса и т.д.
<системный вызов> – имя системного вызова, cписок всех системных вызовов можно найти в файле “unistd_64.h”.
<ключ> – это необязательный параметр, который помогает определить, какая строка или правило сработало.

Для просмотра событий на своих проектах я спользую SIEM системы (Arcsight, Elastic), поэтому корреляция и разделение потока событий происходит там. Если у вас нет централизованной системы сбора логов, то для поиска событий на хостах вам поможет использование ключей. Например, событиям запуска системных вызовов с euid=0 (root) можно задать ключ “execve_root”:

# Root execve events
-a always,exit -F arch=b64 -F euid=0 -S execve -k execve_root
-a always,exit -F arch=b32 -F euid=0 -S execve -k execve_root

И использовать ключ для поиска событий на хосте:
ausearch -k execve_root
tail -100 /var/log/audit/audit.log | grep execve_root
grep -r -w -i execve_root /var/log/audit/audit.log | grep sshd

Для примера, оставлю cсылки на существующие проекты GitHub по схемам сбора логов “auditd”: Auditd MITRE attack framework, Auditd attack rules. Обратите внимание, как происходит разделение событий по типам с помощью ключей.

На своих проектах я использую простую конфигурацию “auditd”: в SIEM систему передаются все системные вызовы с хоста. Добавляем новые строки правил в файл “testsoft.rules”:

# All system call events
-a always,exit -F arch=b64 -S execve -k execve
-a always,exit -F arch=b32 -S execve -k execve

Далее подключаем мониторинг обращений (чтение) к файлам операционной системы Linux:

# Read file events
-a always,exit -F path=/etc/passwd -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/shadow -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/sudoers -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/group -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/security/opasswd -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/hostname -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/resolv.conf -F perm=r -F auid!=-1 -S all -k read_etc

Мониторинг использования ptrace:

#  Watch ptrace events
-a always,exit -F arch=b32 -S ptrace -F a0=0x4 -k ptrace_event
-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -k ptrace_event
-a always,exit -F arch=b32 -S ptrace -F a0=0x5 -k ptrace_event
-a always,exit -F arch=b64 -S ptrace -F a0=0x5 -k ptrace_event
-a always,exit -F arch=b32 -S ptrace -F a0=0x6 -k ptrace_event
-a always,exit -F arch=b64 -S ptrace -F a0=0x6 -k ptrace_event
-a always,exit -F arch=b32 -S ptrace -k ptrace_event
-a always,exit -F arch=b64 -S ptrace -k ptrace_event

 

ЧАСТЬ 3. ДОБАВЛЕНИЕ ИСКЛЮЧЕНИЙ
Подключив журналирование событий при помощи “auditd”, вы сталакнетесь с увеличением количества записей (атомарных событий) в лог-файлах. Например, этот сайт работает на VPS, который “смотрит” всеми портами в “открытый” интернет. Это приводит к тому, что количество атомарных событий по обращению к 22 порту (ssh) стабильно держится на уровне ~50.000 за 24 часа. И это только с одного хоста. Для того чтобы не “раздувать” лог-файлы и снизить нагрузку на SIEM систему используют фильрацию событий на самих хостах. Например, посмотрим на диаграмму распределения типов событий “auditd” после применения настроек из второй части статьи (без фильрации):

Распределение событий auditd при настройке без фильров событий.
Распределение событий auditd при настройке без фильров событий.

Просмотр описания события “CRYPTO_KEY_USER” говорит о том, что в событиях содержится только сервисная информация об использовании криптографического алгоритма. В моих правилах SIEM системы данный тип событий никак не отображается, поэтому его можно отключить. Добавляем новую строку в файл “testsoft.rules” с исключением:
vi /etc/audit/rules.d/testsoft.rules

# Exclude events
-a always,exclude -F msgtype=CRYPTO_KEY_USER

После перезапуска сервиса “auditd”, событие “CRYPTO_KEY_USER” не будет записываться в журнал “auditd”. Посмотрим количество событий за 1 час до и после:

События "auditd" без фильрации
События “auditd” без фильрации

События "auditd" после применения фильтров
События “auditd” после применения фильтров

Для каждой системы или сервера исключения будут уникальными, к сожалению здесь нет единого решения. Одинаковым будет только синтаксис добавления исключений. Несколько дополнительных примеров как можно добавлять исключения в журнал “auditd”:
Исключение по пути “/opt/link/”, который присутствует в записи о событии:

-a never,exit -F arch=b32 -F path=/opt/link/
-a never,exit -F arch=b64 -F path=/opt/link/

Исключение по пути к исполняемуму файлу (prog), который использовался для вызова процесса:

-a always,exclude -F exe=/usr/sbin/prog

Как видно с помощью параметра “-F” можно настраивать точечные исключания (пример с документации redhat):

-a always,exit -F dir=/opt/application -F perm=w -F uid!=bob -F uid!=alice -F auid!=root -F uid>=1000 -F gid!=admins -F success=1

Событие будет формироваться в случае успешной записи в по пути “/opt/application”, и дополнительно выполнены следующие условия:
действие не выполнено пользователем “bob”;
действие не выполнено пользователем “alice”;
действие не выполнено пользователем, который первоначально вошел в систему как “root”;
действие выполнено пользователем uid котого больше 1000;
действие выполнено пользователем из группы “admins”.

4. ИТОГОВЫЕ НАСТРОЙКИ AUDITD
Итоговый файл “testsoft.rules” будет выглядить так:
vi /etc/audit/rules.d/testsoft.rules

# File System Rules - system path write and change
-w /etc -p wa -k filesystem
-w /home -p rwa -k filesystem
-w /root -p rwa -k filesystem
-w /bin -p wa -k filesystem
-w /boot -p wa -k filesystem
-w /usr/bin -p wa -k filesystem
-w /sbin -p wa -k filesystem
-w /usr/sbin -p wa -k filesystem
-w /usr/local/bin -p wa -k filesystem
-w /usr/local/sbin -p wa -k filesystem
-w /usr/libexec -p wa -k filesystem
-w /lib -p wa -k filesystem
-w /lib64 -p wa -k filesystem
-w /usr/lib -p wa -k filesystem
-w /usr/lib64 -p wa -k filesystem
-w /var/spool/cron -p wa -k filesystem

# File System Rules - new file in web directory
-w /var/www -p wa -k filesystem_www

# All system call monitoring
-a always,exit -F arch=b64 -S execve -k execve
-a always,exit -F arch=b32 -S execve -k execve

# Read file events
-a always,exit -F path=/etc/passwd -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/shadow -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/sudoers -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/group -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/security/opasswd -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/hostname -F perm=r -F auid!=-1 -S all -k read_etc
-a always,exit -F path=/etc/resolv.conf -F perm=r -F auid!=-1 -S all -k read_etc

#  Watch ptrace events
-a always,exit -F arch=b32 -S ptrace -F a0=0x4 -k ptrace_event
-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -k ptrace_event
-a always,exit -F arch=b32 -S ptrace -F a0=0x5 -k ptrace_event
-a always,exit -F arch=b64 -S ptrace -F a0=0x5 -k ptrace_event
-a always,exit -F arch=b32 -S ptrace -F a0=0x6 -k ptrace_event
-a always,exit -F arch=b64 -S ptrace -F a0=0x6 -k ptrace_event
-a always,exit -F arch=b32 -S ptrace -k ptrace_event
-a always,exit -F arch=b64 -S ptrace -k ptrace_event

# Exclude events
-a always,exclude -F msgtype=CRYPTO_KEY_USER

Сохраняем файл, и перезапускаем “auditd”:
service auditd restart
Проверяем, что нет ошибок:
service auditd status

root@usa-wordpress-1:~# service auditd status
● auditd.service - Security Auditing Service
   Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2022-01-06 15:37:43 UTC; 3s ago
     Docs: man:auditd(8)
           https://github.com/linux-audit/audit-documentation
  Process: 30151 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
  Process: 30136 ExecStart=/sbin/auditd (code=exited, status=0/SUCCESS)
 Main PID: 30147 (auditd)
    Tasks: 2 (limit: 1151)
   CGroup: /system.slice/auditd.service
           └─30147 /sbin/auditd

Jan 06 15:37:43 usa-wordpress-1 augenrules[30151]: backlog_wait_time 0
Jan 06 15:37:43 usa-wordpress-1 augenrules[30151]: enabled 1
Jan 06 15:37:43 usa-wordpress-1 augenrules[30151]: failure 1
Jan 06 15:37:43 usa-wordpress-1 augenrules[30151]: pid 30147
Jan 06 15:37:43 usa-wordpress-1 augenrules[30151]: rate_limit 0
Jan 06 15:37:43 usa-wordpress-1 augenrules[30151]: backlog_limit 8192
Jan 06 15:37:43 usa-wordpress-1 augenrules[30151]: lost 0
Jan 06 15:37:43 usa-wordpress-1 augenrules[30151]: backlog 1
Jan 06 15:37:43 usa-wordpress-1 augenrules[30151]: backlog_wait_time 0
Jan 06 15:37:43 usa-wordpress-1 systemd[1]: Started Security Auditing Service.

Дополнительные ссылки по настройкам “auditd”:
REDHAT. Audit record types.
REDHAT. Understanding audit log files.
REDHAT. Defining audit rules
REDHAT. How to exclude specific events when using auditd
GITHUB. Linux auditd configuration mapped to MITRE Attack Framework
GITHUB. Auditd attack rules
GITHUB. Audit documentation