auditd — демон аудита Linux, который работает на уровне ядра и записывает в журнал все критические события: входы пользователей, изменение файлов, запуск привилегированных команд и системные вызовы. Это основа compliance (PCI DSS, SOC 2, ISO 27001) и forensics-анализа.

Установка auditd

apt install auditd audispd-plugins -y
systemctl enable --now auditd
auditctl -s  # Статус службы

Правила аудита (/etc/audit/rules.d/audit.rules)

# Мониторинг входов
-w /var/log/auth.log -p wa -k auth_log
-w /etc/passwd -p wa -k user_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/group -p wa -k group_changes
-w /etc/sudoers -p wa -k sudoers_changes

# Мониторинг веб-директории
-w /var/www/ -p wa -k web_changes

# Привилегированные команды
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

# Изменения сетевых настроек
-w /etc/hosts -p wa -k host_changes
-w /etc/network/ -p wa -k network_changes

# Применить правила
augenrules --load

Анализ журналов аудита

ausearch -k auth_log --start today
ausearch -k web_changes -i | grep "name=" | tail -20
ausearch -ua 0 --start "1 hour ago"  # Команды от root за час

aureport --summary
aureport --login --start today
aureport --file --start this-week | head -30

Мониторинг в реальном времени

tail -f /var/log/audit/audit.log | grep -E "type=USER_LOGIN|type=USER_AUTH"
audispd  # Отправка событий в реальном времени

Централизованный сбор логов: Отправляйте auditd-события на центральный SIEM (Graylog, ELK Stack) через audisp-remote. Это защищает логи от удаления злоумышленником, получившим root на вашем сервере.

Разбор типичных ошибок и сообщений auditd

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

No rules — вывод auditctl -l, когда в ядре нет ни одного правила. Типичная причина: правки внесли в файл под /etc/audit/rules.d/, но не выполнили augenrules --load — auditd.service на старте собирает финальный набор правил из этих фрагментов, а не читает их вживую.
You must be root to run this program. — auditctl и ausearch читают журнал аудита, к которому доступ есть только у root; запускайте через sudo.
Error sending enable request (Operation not permitted) — попытка изменить правила, когда аудит переведён в неизменяемый режим (-e 2). Снять такой режим можно только перезагрузкой сервера, это осознанная защита от отключения аудита атакующим с root-доступом.
<no matches> — так ausearch сообщает, что по указанному ключу или временному диапазону событий не нашлось. Проверьте название -k и что нужное правило вообще загружено (auditctl -l).
audit: backlog limit exceeded — эта строка в dmesg или journalctl -k означает, что ядро отбрасывает записи аудита быстрее, чем демон успевает их забирать. Буфер увеличивается строкой -b 8192 в audit.rules.

auditd в сравнении с другими инструментами мониторинга

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

Инструмент	Уровень наблюдения	Что видит	Где хранит данные
auditd	Ядро (системные вызовы)	Все действия, попадающие под заданные правила: вход, exec, запись в файл	/var/log/audit/audit.log
syslog/rsyslog	Приложения	Только то, что само приложение решило записать в лог	/var/log/syslog или свои файлы
osquery	Периодические SQL-запросы	Снимки состояния: процессы, пакеты, сетевые соединения по расписанию	Локальная БД или отправка во внешнюю систему
Wazuh / SIEM-агент	Агрегатор	Собирает события auditd, логи и результаты FIM в одном месте	Центральный сервер SIEM

Периодические снимки состояния системы разобраны в статье osquery для инвентаризации сервера, а сведение событий из разных источников в одну систему — в материале про Wazuh SIEM.

Когда auditd не подходит

auditd закрывает не все задачи мониторинга, и рассчитывать только на него не стоит.

Он не видит сетевой трафик до сервера — это задача firewall и систем уровня IPS, а не auditd.
Широкие правила вроде -S execve без фильтров на высоконагруженном сервере создают заметный оверхед и быстрее переполняют backlog-буфер, чем узкие правила с фильтрами по euid или пути.
Внутри контейнера Docker без доступа к ядру хоста auditd бесполезен: политика аудита применяется на уровне ядра хоста целиком, а не отдельного namespace.
На одиночном сервере без выгрузки логов во внешнее хранилище журнал аудита не защищён: получив root, атакующий отредактирует или удалит audit.log так же легко, как любой другой файл.

Проверка, что аудит реально работает

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

# Добавить временное тестовое правило (живёт только в памяти ядра)
auditctl -w /tmp/audit-test -p wa -k audit_test

# Вызвать событие
touch /tmp/audit-test

# Убедиться, что событие записано в журнал
ausearch -k audit_test --start recent

# Убрать тестовое правило
auditctl -W /tmp/audit-test -p wa -k audit_test

Если ausearch вернул запись с type=PATH и именем /tmp/audit-test, а не <no matches> — цепочка «правило → ядро → демон → журнал» работает целиком, а не только на бумаге.