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> — ланцюжок «правило → ядро → демон → журнал» працює повністю, а не лише на папері.