Базовое описание и архитектура auditd

9 | 10.09.2026 16:56 | #Auditd

1. Обзор архитектуры.

Linux Audit — встроенная в ядро Linux подсистема аудита, предназначенная для регистрации событий, связанных с безопасностью операционной системы. Она позволяет отслеживать действия пользователей и процессов, обращения к файлам, выполнение системных вызовов, изменение конфигурации, использование привилегий и другие значимые операции.

Центральным компонентом подсистемы является демон auditd. Он получает события от ядра Linux через интерфейс аудита, обрабатывает их и сохраняет в журнале, который по умолчанию расположен в /var/log/audit/audit.log. Дополнительно события могут передаваться другим приложениям или на удалённые системы сбора и анализа, например в SIEM.

Основные компоненты Linux Audit:

подсистема аудита ядра Linux — формирует события;
auditd — принимает события и записывает их в журнал;
auditctl — используется для управления параметрами аудита и загруженными правилами;
augenrules — объединяет правила из каталога /etc/audit/rules.d/ и загружает их в подсистему аудита;
ausearch — выполняет поиск событий в журналах аудита;
aureport — формирует сводные отчёты;
плагины диспетчера событий — обеспечивают дополнительную обработку и передачу событий во внешние системы.

Общий порядок обработки событий выглядит следующим образом:

пользователь, процесс или доверенное приложение выполняет действие в операционной системе.
ядро Linux проверяет действие в соответствии с загруженными правилами аудита.
при выполнении условий правила ядро формирует событие аудита.
в событие добавляется контекст выполнения: идентификаторы пользователя и процесса, временная метка, результат операции и другие сведения.
событие помещается во внутреннюю очередь ядра — backlog.
демон auditd получает событие из очереди.
событие записывается в журнал аудита и при необходимости передаётся подключённым плагинам.

1.1. Зависимости времени выполнения.

Для работы auditd необходимы следующие компоненты:

coreutils;
initscripts-service — рекомендуется, но не является обязательным требованием;
ядро Linux версии 5.15 или выше;
systemd.

Примечание. Хотя рассматриваемая реализация предусматривает использование systemd для запуска демона аудита, могут применяться и другие системы инициализации. Например, в Alpine Linux используется init-скрипт для OpenRC.

1.2. Загрузка правил аудита.

Правила аудита загружаются из пространства пользователя в подсистему аудита ядра при помощи auditctl.

Утилита auditctl позволяет:

создавать и загружать правила;
просматривать действующие правила;
удалять отдельные правила;
очищать набор правил;
настраивать размер очереди backlog;
определять поведение системы при критических ошибках;
получать текущее состояние подсистемы аудита.

Для Audit 3.x правила из отдельных файлов обычно объединяются и загружаются программой augenrules. Как правило, исходные файлы размещаются в каталоге:

/etc/audit/rules.d/

Команда augenrules обрабатывает файлы с расширением .rules, объединяет их в порядке сортировки имён и формирует итоговый файл:

/etc/audit/audit.rules

Начиная с Audit 4.x для управления загрузкой правил предусмотрена служба:

audit-rules.service

Она управляется через systemctl и также использует auditctl для передачи правил в ядро.

Примечание. Конкретный механизм загрузки правил, расположение файлов и названия служб могут отличаться в зависимости от дистрибутива Linux и версии пакета Audit. Перед настройкой необходимо проверить фактическую конфигурацию установленной системы.

1.3. Формирование событий доверенными приложениями.

Не все события аудита возникают только в результате срабатывания правил системных вызовов. Некоторые доверенные приложения самостоятельно передают сообщения подсистеме аудита.

К таким приложениям относятся, например, компоненты shadow-utils, используемые для управления локальными пользователями и группами.

При получении такого сообщения ядро добавляет сведения об источнике события, временную метку и другую контекстную информацию, после чего помещает событие в очередь для передачи демону auditd.

Таким образом, источниками событий Linux Audit могут быть:

правила аудита системных вызовов;
правила наблюдения за файлами и каталогами;
подсистемы ядра Linux;
механизмы аутентификации;
доверенные приложения;
службы, использующие интерфейс Linux Audit.

2. Особенности работы демона auditd.

При настройке auditd необходимо учитывать заполнение дискового пространства, особенности защиты службы через systemd, а также корректный порядок запуска, остановки и перезагрузки демона.

space_left_action
admin_space_left_action

systemd-analyze security auditd.service

systemctl daemon-reload
systemctl status auditd
auditctl -s
auditctl -l

Пользователь → systemctl → D-Bus → systemd → auditd

auid=4294967295

auid=-1

RefuseManualStop=yes

systemctl stop auditd

service auditd restart
service auditd reload
service auditd rotate
service auditd resume
service auditd state

/usr/libexec/initscripts/legacy-actions/

auditctl <SIGNAL>

find /usr/libexec/initscripts/legacy-actions/ -maxdepth 2 -type f
service auditd status

10 - Конфигурация ядра и auditctl
20 - Правила, которые могли бы соответствовать общим правилам,
     но для которых требуется другое соответствие (override)
30 - Основные правила
40 - Необязательные правила
50 - Правила, специфичные для сервера
70 - Локальные системные правила
90 - Завершение настройки (immutable)

10-base_description.rules
20-exceptions.rules
25-denied.rules
30-base_rules.rules
40-extended_rules.rules
45-containers.rules
50-web-servers.rules
55-databases.rules
60-middleware.rules
65-monitoring.rules
70-devops.rules
75-network-services.rules
80-virtualization.rules
90-custom.rules
99-finalize.rules

###############################################################################
# БАЗОВАЯ КОНФИГУРАЦИЯ
###############################################################################

# Удалить все ранее загруженные правила (должно быть ПЕРВОЙ директивой).
-D

# Размер очереди событий ядра.
# Увеличено до 32768: набор включает аудит execve для всех
# атрибутируемых процессов, при всплесках 8192 приводит к сообщениям
# "audit: backlog limit exceeded" и БЕЗВОЗВРАТНОЙ потере событий.
# при включении логирования при загрузке ОС, 8192 не хватало
-b 32768

# Реакция на сбой подсистемы аудита: 1 = сообщение в kernel log.
-f 1

# КРИТИЧНО. Продолжать обработку файла при ошибке в отдельном правиле.
# Без этой директивы auditctl ПРЕКРАЩАЕТ обработку файла на первой ошибке,
# и все последующие правила молча не применяются.
# Ошибку вызывает watch на отсутствующий КАТАЛОГ (watch на отсутствующий файл
# ошибкой не является). В гетерогенном парке такие каталоги неизбежны.
# ОБЯЗАТЕЛЬНОЕ ДОПОЛНЕНИЕ: -i маскирует ошибки, поэтому после установки
# ОБЯЗАТЕЛЬНО выполняется проверка полноты загрузки активных правил.
-i

# Время ожидания при переполнении очереди. По умолчанию задача блокируется,
# что при всплеске может подтормаживать нагруженный сервер.
# Значение 0 = не ждать (события отбрасываются вместо блокировки).
# Включать ТОЛЬКО вместе с мониторингом счётчика lost
# и по результатам пилота.
#--backlog_wait_time 0
# в centos 10 по-умолчанию 60000

###############################################################################
# Linux Audit Policy — ИСКЛЮЧЕНИЯ
#
# Назначение : безопасное снижение избыточных служебных событий.
# Размещение : /etc/audit/rules.d/20-exceptions.rules (root:root, 640)
#
# ВАЖНО:
# Исключения допускаются ТОЛЬКО если они не создают слепых зон
# по субъекту или контексту выполнения. Исключения вида
# "-a never,exit -F subj_type=crond_t" или "-F exe=<путь>" ЗАПРЕЩЕНЫ:
# они полностью выключают аудит для целого класса процессов.
#
# EPS: правило снижает объём событий; новых событий не создаёт.
###############################################################################

# Подавление парных служебных записей о конце события.
# Данные не теряются, объём снижается.
-a always,exclude -F msgtype=EOE

# ЗАПРЕЩЕНО исключать msgtype=CWD  — теряется рабочий каталог процесса,
#                                    относительные пути становятся неинтерпретируемыми.
# ЗАПРЕЩЕНО исключать msgtype=AVC  — теряются срабатывания SELinux.

###############################################################################
# Linux Audit Policy — ФИНАЛИЗАЦИЯ
#
# -e 1 — аудит включён, правила изменяемы (требуется для штатной эксплуатации).
# -e 2 — правила неизменяемы до перезагрузки; если этот режим утверждён,
#        директива задаётся здесь и применяется ПОСЛЕДНЕЙ.
#
# ВАЖНО: изменение -e 1 на -e 2 меняет эксплуатационный режим и выполняется
# только после проверки совместимости с обновлением и сопровождением системы.
# EPS: не генерирует дополнительный поток событий.
###############################################################################
-e 1

augenrules --check
augenrules --load
auditctl -l
auditctl -s

-e 2

type=<something> msg=audit(1679598373.352:1256072):

type=<something>

msg=audit(1679598373.352:1256072)

1679598373.352:1256072

key=value

type=SYSCALL msg=audit(1679598373.352:1256072):
type=EXECVE msg=audit(1679598373.352:1256072):
type=CWD msg=audit(1679598373.352:1256072):
type=PATH msg=audit(1679598373.352:1256072):
type=PROCTITLE msg=audit(1679598373.352:1256072):

audit(1679598373.352:1256072)

Чтобы прочитать полный текст, необходимо зарегистрироваться.

Регистрация

6. Поиск и формирование отчётов.

Предусмотренным способом просмотра событий аудита является использование программы ausearch.

Записи составных событий могут поступать вперемешку. Утилиты ausearch, aureport и библиотека auparse группируют записи до завершения события, а затем представляют их в последовательном порядке.

С помощью ausearch можно искать события:

определённого типа;
определённого процесса;
конкретного файла;
определённого пользователя;
конкретного системного вызова;
по ключу правила;
по результату выполнения операции;
за указанный временной период.

Примечание. Следует учитывать, что данные команды выполняются непосредственно в операционной системе.

Примечание. Следует учитывать, что данные команды выполняются непосредственно в операционной системе.

6.1. Примеры использования ausearch.

Поиск безуспешных входов:

ausearch -m USER_LOGIN --success no -i

Поиск событий для файла shadow за текущий день:

ausearch --start today -f shadow -i

Поиск безуспешных открытий файлов для пользователя с loginuid=1000:

ausearch -m PATH --success no --syscall open --loginuid 1000 -i

Поиск событий по ключу правила:

ausearch -k identity_change -i

Поиск событий выполнения определённой программы:

ausearch -x /usr/bin/passwd -i

Поиск событий за текущий день:

ausearch --start today -i

Поиск событий за заданный временной диапазон:

ausearch --start 08/28/2026 10:00:00 --end 08/28/2026 12:00:00 -i

Параметр -i преобразует числовые значения идентификаторов, системных вызовов и других полей в интерпретированный, удобный для чтения вид.

Для машинной обработки рекомендуется использовать исходный формат без -i.

6.2. Формирование отчётов с помощью aureport.

Для получения сводной информации используется программа aureport. Она позволяет группировать и суммировать поля событий аудита.

Ежемесячный сводный отчёт:

aureport --start this-month --summary

Сводка по файлам, к которым осуществлялся доступ сегодня:

aureport --start today --file --summary

События системных вызовов, сгруппированные по ключу:

aureport --start today --key --summary

Все изменения учётных записей за текущий месяц:

aureport --start this-month --mods -i

Отчёт обо всех файлах журналов аудита и содержащихся в них временных диапазонах:

aureport -t

6.3. Совместное использование ausearch и aureport.

Иногда стандартный отчёт aureport содержит слишком много данных. В таком случае сначала можно отфильтровать события с помощью ausearch, а затем передать результат в aureport.

Для этого вывод ausearch должен быть представлен в формате raw.

Сводка файлов, к которым обращался пользователь с auid=1000:

ausearch --start today --auid 1000 --raw | aureport --file --summary

Сводка файлов, к которым обращался редактор vi:

ausearch --start this-week -x vi --raw | aureport --file --summary

Сводка программ, связанных с событиями с ключом unsuccessful-access:

ausearch --start this-month --key unsuccessful-access --raw |
aureport -x --summary -i

Сводка хостов, с которых пользователи входили в систему:

ausearch --start this-week -m USER_LOGIN --raw |
aureport --host --summary

6.4. Форматы вывода ausearch.

Параметр --format позволяет изменить формат представления результатов.

Для вывода в формате CSV используется команда:

ausearch --start today --format csv

Для преобразования событий в текстовое описание используется:

ausearch --start today --format text

Этот формат формирует простые предложения, описывающие смысл событий.

Для новых типов событий соответствующее текстовое описание может отсутствовать. В таком случае корректная интерпретация может появиться после обновления программного обеспечения Audit.

7. Производительность и мониторинг.

Система аудита предоставляет сведения, позволяющие оценить её состояние и производительность.

Основная команда проверки подсистемы:

auditctl -s

Команда отображает:

режим работы подсистемы;
состояние блокировки конфигурации;
количество потерянных событий;
текущий размер очереди ядра;
предельный размер очереди;
параметры поведения при ошибках.

Пример вывода:

enabled 1
failure 1
pid 842
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
backlog_wait_time 60000
backlog_wait_time_actual 0
loginuid_immutable 0 unlocked

7.1. Очередь backlog.

Очередь backlog — это очередь записей, которые ядро удерживает в ожидании передачи демону auditd.

Основные показатели:

backlog_limit — максимально допустимое количество записей в очереди;
backlog — текущее количество записей, ожидающих передачи;
lost — количество потерянных записей;
backlog_wait_time — время ожидания освобождения места в очереди.

Для системы, в которой активно используется аудит, значение backlog_limit рекомендуется устанавливать около 8192 или выше. Конкретное значение должно определяться на основании фактической нагрузки.

Текущее значение backlog обычно должно оставаться небольшим. Кратковременный рост очереди во время повышенной активности допустим, но постоянное приближение к backlog_limit указывает на проблему.

Особенно важно контролировать поле lost. В штатном состоянии его значение должно оставаться равным нулю. Рост значения означает, что часть событий не была передана демону и не попала в журнал аудита.

Пример проблемной работы auditd.

Значение lost 421 означает, что ядро потеряло 421 audit записей — они не были переданы/обработаны auditd из-за переполнения kernel audit backlog. Эта активность фиксировалась при загрузке операционной системы. Значение backlog 0 означает, что сейчас очередь пустая. Но во время загрузки произошёл всплеск событий и 421 запись была потеряна.

7.2. Получение внутреннего состояния auditd.

Для получения внутренних показателей демона используется команда:

auditctl --signal state

После её выполнения демон записывает сведения о своём состоянии в файл:

/run/audit/auditd.state

Просмотреть файл можно командой:

cat /run/audit/auditd.state

Пример содержимого:

audit version = 4.0.5
current time = 06/02/25 20:21:31
process priority = -4
writing to logs = yes
current log size = 2423 KiB
max log size = 8192 KiB
logs detected last rotate/shift = 0
space left on partition = yes
Logging partition free space 45565 MiB
space_left setting 75 MiB
admin_space_left setting 50 MiB
logging suspended = no
file system space action performed = no
admin space action performed = no
disk error detected = no
Number of active plugins = 1
current plugin queue depth = 0
max plugin queue depth used = 5
plugin queue size = 2000
plugin queue overflow detected = no
plugin queueing suspended = no
listening for network connections = no
glibc arena (total memory) is: 388 KiB, was: 388 KiB
glibc uordblks (in use memory) is: 92 KiB, was: 90 KiB
glibc fordblks (total free space) is: 295 KiB, was: 297 KiB

По этим данным можно оценить:

выполняется ли запись в журнал;
приостановлено ли журналирование;
текущий и максимальный размер журнала;
наличие свободного места;
выполнение действий при недостатке места;
наличие ошибок файловой системы;
количество активных плагинов;
текущее и максимальное заполнение очереди плагинов;
наличие переполнения очереди;
использование памяти процессом.

Начиная с audit-4.0.5 можно настроить периодическое обновление файла состояния параметром report_interval в /etc/audit/auditd.conf. Это позволяет использовать файл для регулярного сбора показателей мониторинга.

7.3. Основные показатели контроля.

При мониторинге подсистемы аудита следует обращать внимание на следующие значения:

Показатель	Назначение	Нормальное состояние
`enabled`	Режим работы подсистемы аудита	`1` или `2`
`lost`	Количество потерянных записей	`0`
`backlog`	Текущее количество записей в очереди ядра	Существенно меньше `backlog_limit`
`backlog_limit`	Предельный размер очереди	Соответствует нагрузке
`writing to logs`	Выполняется ли запись журнала	`yes`
`logging suspended`	Приостановлена ли запись	`no`
`disk error detected`	Обнаружена ли ошибка записи	`no`
`plugin queue overflow detected`	Обнаружено ли переполнение очереди плагинов	`no`
`plugin queueing suspended`	Приостановлена ли передача плагинам	`no`

Значение enabled интерпретируется следующим образом:

0 — аудит отключён;
1 — аудит включён, конфигурацию можно изменять;
2 — аудит включён в неизменяемом режиме; изменение правил возможно только после перезагрузки системы.

7.4. Базовая проверка работоспособности.

Базовая проверка может выполняться следующими командами:

systemctl status auditd --no-pager
auditctl -s
auditctl -l
ausearch -m DAEMON_START,DAEMON_END,DAEMON_ABORT,DAEMON_CONFIG -i
df -h /var/log/audit

Дополнительно можно проверить последние записи журнала:

tail -n 50 /var/log/audit/audit.log

Проверка считается успешной, если:

демон auditd работает;
подсистема аудита включена;
правила загружены;
значение lost не увеличивается;
очередь backlog не приближается к backlog_limit;
запись журнала не приостановлена;
ошибки диска отсутствуют;
очереди плагинов не переполнены;
в файловой системе достаточно свободного места.

8. Итоговая схема проверки

После установки или изменения конфигурации рекомендуется последовательно проверить:

состояние службы auditd;
состояние подсистемы аудита ядра;
список загруженных правил;
создание тестового события;
появление события в /var/log/audit/audit.log;
поиск события через ausearch;
отсутствие потерянных событий;
состояние дискового пространства;
состояние очереди ядра;
состояние очередей плагинов.

Важно. Список правил auditd, фактически загруженных в ядро и применяемых в текущий момент, можно вывести командой auditctl -l.
Следует учитывать, что список загруженных правил может отличаться от содержимого файлов правил auditd. Например, общий набор правил может содержать правила, предназначенные только для определённых операционных систем, дистрибутивов или конфигураций. Если соответствующие файлы, каталоги, системные вызовы или другие объекты отсутствуют в конкретной системе, такие правила могут завершаться ошибкой при загрузке.
Поведение при возникновении ошибки определяется параметром -f (failure mode) в начале правил. При использовании -f 1 ошибка загрузки отдельного правила регистрируется, однако обработка последующих правил продолжается. Таким образом, неподдерживаемое или неприменимое правило может быть пропущено, а остальные корректные правила — загружены.
Если режим -f 1 не установлен и средство загрузки правил прекращает обработку при возникновении ошибки, правила, расположенные после ошибочного правила, могут остаться незагруженными. Поэтому после загрузки набора правил рекомендуется проверять фактически применённую конфигурацию с помощью auditctl -l.

Пример создания и поиска тестового события:

touch /tmp/audit-test-file
auditctl -w /tmp/audit-test-file -p wa -k audit_test
echo test >> /tmp/audit-test-file
ausearch -k audit_test -i
auditctl -W /tmp/audit-test-file -k audit_test
rm /tmp/audit-test-file

Ожидаемый результат:

команда добавления правила завершается без ошибки;
изменение файла создаёт событие аудита;
ausearch находит событие с ключом audit_test;
в событии присутствуют сведения о пользователе, процессе и изменённом файле;
временное правило успешно удаляется после завершения проверки.

Примечание. Временное правило, добавленное через auditctl, действует до его ручного удаления, перезагрузки системы или повторной загрузки постоянного набора правил.

Ссылки:

GitHub - linux-audit/audit-userspace: Linux audit userspace repository · GitHub