Auditd Linux: посібник з безпеки (2026)

Що таке auditd і навіщо він потрібен

Linux Audit Daemon (auditd) — це системний компонент ядра Linux, який забезпечує детальне журналювання подій безпеки на рівні системних викликів. На відміну від звичайних механізмів логування, де додатки самі генерують записи, auditd працює безпосередньо на рівні ядра. Він перехоплює системні виклики ще до того, як вони потрапляють до простору користувача — і це принципова різниця.

Навіщо він потрібен у 2026 році? Якщо коротко — без нього складно уявити серйозну інфраструктуру. Ось основні сценарії використання:

Виявлення несанкціонованого доступу та спроб ескалації привілеїв
Відповідність вимогам стандартів PCI-DSS, HIPAA, GDPR та ISO 27001
Розслідування кіберінцидентів та цифрова криміналістика
Моніторинг змін конфігурації та доступу до критичних файлів
Побудова системи виявлення загроз (Detection Engineering)

Мені подобається думати про auditd як про «чорну скриньку» сервера. Він фіксує кожну дію на рівні, де підробити або сховати сліди вкрай складно. Саме тому для команд безпеки це незамінний інструмент.

Архітектура підсистеми аудиту Linux

Перш ніж переходити до налаштувань, варто зрозуміти, як усе працює під капотом. Підсистема аудиту Linux складається з компонентів у двох просторах.

Простір ядра (Kernel Space)

kauditd — модуль ядра, який перехоплює системні виклики та генерує події аудиту. Кожен системний виклик з простору користувача проходить через ланцюжок фільтрів:

user — фільтрує події простору користувача до передачі в auditd
task — застосовується при створенні нових процесів (fork/clone)
filesystem — фільтрує події файлової системи
exclude — виключає певні типи подій
exit — головний фільтр, що обробляє події при завершенні системного виклику

Простір користувача (User Space)

auditd — демон, який отримує події від ядра та записує їх у лог-файли
auditctl — утиліта для керування правилами аудиту в реальному часі
ausearch — інструмент пошуку подій у журналах аудиту
aureport — генерація зведених звітів
audispd (audisp) — диспетчер подій для передачі в зовнішні системи

Встановлення та базове налаштування

Отже, переходимо до практики. Встановлення auditd — справа нескладна, але є нюанси залежно від дистрибутива.

Встановлення на Debian/Ubuntu

sudo apt-get update
sudo apt-get install -y auditd audispd-plugins
sudo systemctl enable auditd
sudo systemctl start auditd

Встановлення на RHEL/CentOS/Fedora

sudo dnf install -y audit audit-libs audispd-plugins
sudo systemctl enable auditd
sudo systemctl start auditd

Перевірка статусу

sudo auditctl -s

Ця команда покаже поточний стан підсистеми аудиту: чи увімкнений аудит, PID процесу auditd, розмір черги (backlog), кількість втрачених подій (lost) та швидкість генерації подій. Якщо бачите enabled 1 — все працює.

Активація аудиту на етапі завантаження

Це важливий крок, який часто пропускають. Щоб аудит охоплював усі процеси від самого початку завантаження, додайте параметр ядра audit=1 у конфігурацію GRUB:

# Відредагуйте /etc/default/grub
GRUB_CMDLINE_LINUX="audit=1"

# Оновіть конфігурацію GRUB
sudo update-grub    # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg  # RHEL/CentOS

Конфігураційні файли auditd

auditd.conf — конфігурація демона

Файл /etc/audit/auditd.conf визначає поведінку демона auditd. Давайте розберемо ключові параметри:

# Шлях до файлу журналу
log_file = /var/log/audit/audit.log

# Формат журналу (ENRICHED додає розшифровку UID/GID)
log_format = ENRICHED

# Група з доступом до лог-файлу
log_group = adm

# Максимальний розмір файлу журналу (МБ)
max_log_file = 50

# Дія при досягненні ліміту: ROTATE, SYSLOG, SUSPEND, KEEP_LOGS
max_log_file_action = ROTATE

# Кількість файлів для ротації
num_logs = 10

# Режим синхронізації запису на диск
flush = incremental_async

# Частота примусової синхронізації (кожні N записів)
freq = 100

# Дія при заповненні диска
disk_full_action = SUSPEND
disk_error_action = SUSPEND

Порада з практики: каталог /var/log/audit/ краще розмістити на окремому розділі диска. Чому? Це запобігає ситуації, коли інші процеси з'їдають весь дисковий простір і аудит просто зупиняється. На моєму досвіді, саме ця помилка трапляється найчастіше на нових серверах.

audit.rules — правила аудиту

Правила аудиту зберігаються у файлі /etc/audit/rules.d/audit.rules. Формат правил ідентичний синтаксису команди auditctl, тільки без самої команди на початку рядка. При запуску системи ці правила завантажуються автоматично.

Типи правил аудиту та їх створення

Правила auditd поділяються на три категорії. Розглянемо кожну окремо.

1. Правила контролю (Control Rules)

Визначають поведінку самої підсистеми аудиту:

# Встановити розмір черги повідомлень
-b 8192

# Режим обробки помилок: 0=silent, 1=printk, 2=panic
-f 1

# Зробити конфігурацію незмінною (має бути останнім правилом)
-e 2

2. Правила спостереження за файлами (File Watch Rules)

Відстежують доступ до конкретних файлів або каталогів. Це, мабуть, найпоширеніший тип правил:

# Моніторинг змін у файлі паролів
-w /etc/passwd -p wa -k user-modify

# Моніторинг файлу тіньових паролів
-w /etc/shadow -p wa -k shadow-modify

# Моніторинг конфігурації SSH
-w /etc/ssh/sshd_config -p wa -k sshd-config

# Моніторинг конфігурації sudoers
-w /etc/sudoers -p wa -k sudoers-modify
-w /etc/sudoers.d/ -p wa -k sudoers-modify

# Моніторинг cron-завдань
-w /etc/crontab -p wa -k cron-modify
-w /var/spool/cron/ -p wa -k cron-modify

Прапорці доступу: r — читання, w — запис, x — виконання, a — зміна атрибутів. Параметр -k додає ключ (тег) для зручної фільтрації — і повірте, без нього потім шукати щось у логах буде дуже невдячною справою.

3. Правила системних викликів (Syscall Rules)

Відстежують конкретні системні виклики. Це найпотужніший, але й найбільш ресурсозатратний тип правил:

# Моніторинг виконання програм
-a always,exit -F arch=b64 -S execve -k exec-cmd

# Моніторинг видалення файлів
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rmdir -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k file-delete

# Моніторинг завантаження модулів ядра
-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k kernel-module

# Моніторинг зміни часу
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time-change

Щодо продуктивності: об'єднуйте правила системних викликів, де це можливо. Кожне правило оцінюється для кожного системного виклику кожного процесу, тож менша кількість правил — менше навантаження. Наприклад, замість окремих правил для unlink, unlinkat, rmdir — краще використати одне комбіноване правило (як у прикладі вище).

Правила auditd з прив'язкою до MITRE ATT&CK

А тепер — найцікавіше. Фреймворк MITRE ATT&CK систематизує тактики, техніки та процедури (TTP) кіберзловмисників. Коли ви прив'язуєте правила auditd до конкретних технік ATT&CK, моніторинг перетворюється з пасивного журналювання на активну систему виявлення загроз. Це саме те, що робить різницю між «у нас є логи» і «ми бачимо атаку».

T1003.008 — Доступ до /etc/passwd та /etc/shadow (Credential Dumping)

# Виявлення спроб читання файлів облікових даних
-w /etc/shadow -p ra -k T1003_Credential_Access
-w /etc/passwd -p ra -k T1003_Credential_Access
-w /etc/gshadow -p ra -k T1003_Credential_Access

Зверніть увагу на прапорець r — тут ми відстежуємо не лише зміни, а й читання. Легітимне читання /etc/shadow зазвичай обмежується модулями PAM та службами на кшталт sshd або login. Якщо бачите доступ від інтерактивних оболонок (bash, zsh) або скриптових інтерпретаторів (python, perl) — це вже підозріло.

T1068 — Експлуатація для ескалації привілеїв

# Моніторинг змін у критичних бінарних файлах
-w /usr/bin/ -p wa -k T1068_Exploitation_Priv_Esc
-w /usr/sbin/ -p wa -k T1068_Exploitation_Priv_Esc
-w /usr/local/bin/ -p wa -k T1068_Exploitation_Priv_Esc

# Моніторинг змін у SUID/SGID файлах
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F a2&06000 -k T1068_SUID_SGID

T1033 — Розвідка користувачів системи (System Owner/User Discovery)

# Моніторинг доступу до файлів з інформацією про сеанси
-w /var/run/utmp -p r -k T1033_User_Discovery
-w /var/log/wtmp -p r -k T1033_User_Discovery
-w /var/log/btmp -p r -k T1033_User_Discovery

# Моніторинг виконання утиліт розвідки
-w /usr/bin/who -p x -k T1033_User_Discovery
-w /usr/bin/w -p x -k T1033_User_Discovery
-w /usr/bin/last -p x -k T1033_User_Discovery
-w /usr/bin/id -p x -k T1033_User_Discovery

T1070 — Видалення індикаторів на хості (Indicator Removal)

# Виявлення спроб видалення файлів та очищення слідів
-a always,exit -F arch=b64 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid=0 -k T1070_Indicator_Removal

# Моніторинг очищення журналів
-w /var/log/ -p wa -k T1070_Log_Tampering

T1562.012 — Вимкнення або модифікація системи аудиту

# Захист від вимкнення самого auditd
-w /etc/audit/ -p wa -k T1562_Audit_Tampering
-w /etc/audit/auditd.conf -p wa -k T1562_Audit_Tampering
-w /etc/audit/rules.d/ -p wa -k T1562_Audit_Tampering
-w /usr/sbin/auditctl -p x -k T1562_Audit_Tampering
-w /usr/sbin/auditd -p x -k T1562_Audit_Tampering

Чесно кажучи, це один із найважливіших наборів правил у всій конфігурації. Першою дією багатьох зловмисників є саме спроба вимкнути аудит. Якщо логи раптово припиняються одночасно з привілейованим виконанням команд — це серйозний індикатор компрометації, і вам варто негайно розслідувати ситуацію.

Готові набори правил для початку

Не обов'язково писати все з нуля. Спільнота підтримує кілька відмінних репозиторіїв з готовими наборами правил auditd, прив'язаних до MITRE ATT&CK:

auditd-attack від bfuzzy — повний набір правил, зіставлених із фреймворком ATT&CK
Florian Roth's auditd config (Neo23x0) — оптимізований набір для виявлення загроз

Обидва — чудова відправна точка. Але (і це важливо) будь-які правила обов'язково протестуйте у тестовому середовищі перед впровадженням у продакшн. Я бачив ситуації, коли занадто агресивні правила значно сповільнювали навантажені сервери.

Оптимізація продуктивності auditd для продакшн-серверів

Неправильно налаштований auditd може суттєво «просадити» продуктивність сервера. Давайте розберемо ключові параметри, на які варто звернути увагу.

Розмір черги (backlog_limit)

Типове значення за замовчуванням — 320. Для продакшн-серверів це критично мало.

При перевищенні ліміту ядро генерує повідомлення audit: backlog limit exceeded, і події починають губитися. Підвищуємо:

# Рекомендоване значення для продакшн-серверів
-b 8192

Щодо пам'яті — один буфер аудиту займає приблизно 8970 байт. Черга на 8192 записи використовує близько 70 МБ оперативної пам'яті. Для більшості серверів це цілком прийнятно.

Порядок правил

Правила обробляються послідовно, і порядок реально впливає на продуктивність. Розмістіть правила для найчастіших подій на початку набору, а рідкісні «виключення» — в кінці. Таким чином зменшується кількість порівнянь для кожного системного виклику.

Параметри синхронізації

# У файлі /etc/audit/auditd.conf
flush = incremental_async
freq = 100

Ці параметри дають гарний баланс між надійністю та продуктивністю: дані синхронізуються з диском кожні 100 записів. Достатньо, щоб не втратити занадто багато подій при збої, але без зайвого навантаження на дискову підсистему.

Моніторинг здоров'я auditd

# Перевірити статус підсистеми аудиту
sudo auditctl -s

# Ключові показники:
# backlog — поточний розмір черги (має бути значно менший за backlog_limit)
# lost — кількість втрачених подій (має бути 0 або близько до 0)
# rate_limit — обмеження швидкості (0 = без обмежень)

Візьміть за звичку перевіряти ці показники після кожної зміни правил. Якщо lost більше нуля — щось не так.

Аналіз журналів аудиту: ausearch та aureport

Зібрати логи — це лише половина справи. Потрібно ще вміти їх ефективно аналізувати.

Пошук подій за допомогою ausearch

# Пошук подій за ключем (тегом)
sudo ausearch -k user-modify

# Пошук подій для конкретного файлу
sudo ausearch -f /etc/passwd

# Пошук подій за часовим діапазоном
sudo ausearch -ts today -te now -k exec-cmd

# Пошук подій конкретного користувача (за UID)
sudo ausearch -ua 1000

# Пошук невдалих подій
sudo ausearch --success no

# Виведення в інтерпретованому (зручному) форматі
sudo ausearch -k sshd-config -i

Прапорець -i в останній команді — справжній рятівник. Він перетворює числові UID, GID та системні виклики на зрозумілі імена, що значно спрощує аналіз.

Генерація звітів за допомогою aureport

# Загальний звіт за період
sudo aureport --start today

# Звіт про спроби автентифікації
sudo aureport -au

# Звіт про невдалі події
sudo aureport --failed

# Звіт про виконані команди
sudo aureport -x

# Звіт про доступ до файлів
sudo aureport -f

# Звіт про аномалії
sudo aureport --anomaly

Інтеграція з SIEM через Laurel

Тут починається найцікавіша частина для тих, хто працює з SIEM-системами. Стандартний формат журналів auditd, відверто кажучи, не дуже зручний для автоматичного аналізу: події розбиті на кілька рядків, пов'язаних ідентифікатором повідомлення, а шляхи до файлів та аргументи команд часто закодовані в hex.

Laurel — це плагін постобробки подій для auditd, який вирішує всі ці проблеми. Він об'єднує розрізнені записи в єдиний JSON-об'єкт, розшифровує закодовані дані та збагачує події додатковою метаінформацією.

Встановлення Laurel

# Встановлення залежностей
sudo apt-get install -y libclang-dev libacl1-dev

# Створення системного користувача
sudo useradd --system --home-dir /var/log/laurel --create-home _laurel

# Збирання з вихідного коду
git clone https://github.com/threathunters-io/laurel.git
cd laurel
cargo build --release
sudo install -m755 target/release/laurel /usr/local/sbin/laurel

# Створення каталогу конфігурації
sudo mkdir -p /etc/laurel

Конфігурація плагіна

Створіть файл конфігурації /etc/audit/plugins.d/laurel.conf:

active = yes
direction = out
type = always
format = string
path = /usr/local/sbin/laurel
args = --config /etc/laurel/config.toml

Пересилання до SIEM через rsyslog

Після збагачення даних через Laurel, структуровані JSON-логи можна переслати до SIEM за допомогою rsyslog:

# Додайте до /etc/rsyslog.d/laurel.conf
$ModLoad imfile
$InputFileName /var/log/laurel/audit.log
$InputFileTag AuditD:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor

# Пересилання до віддаленого сервера
local6.* @@siem-server.example.com:514

sudo systemctl restart rsyslog

У підсумку ви отримуєте повноцінний конвеєр: Ядро Linux → auditd → Laurel (JSON-збагачення) → rsyslog → SIEM. Це дає високоякісну, структуровану телеметрію безпеки, з якою приємно працювати.

Практичний приклад: повний набір правил для веб-сервера

Ось готовий набір правил для типового продакшн веб-сервера. Збережіть його у файлі /etc/audit/rules.d/audit.rules і адаптуйте під свої потреби:

# Очистити поточні правила
-D

# Встановити розмір буфера
-b 8192

# Режим обробки помилок (1 = логувати)
-f 1

# === Моніторинг облікових записів ===
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity

# === Моніторинг конфігурації мережі ===
-w /etc/hosts -p wa -k network-config
-w /etc/network/ -p wa -k network-config
-w /etc/sysconfig/network -p wa -k network-config

# === Моніторинг SSH ===
-w /etc/ssh/sshd_config -p wa -k sshd-config
-w /root/.ssh/ -p wa -k ssh-keys

# === Моніторинг критичних системних файлів ===
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

# === Моніторинг виконання програм ===
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user-exec

# === Моніторинг завантаження модулів ядра ===
-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k kernel-modules

# === Моніторинг монтування файлових систем ===
-a always,exit -F arch=b64 -S mount -S umount2 -F auid>=1000 -F auid!=4294967295 -k mount-ops

# === Захист конфігурації аудиту ===
-w /etc/audit/ -p wa -k audit-config
-w /etc/audit/auditd.conf -p wa -k audit-config
-w /etc/audit/rules.d/ -p wa -k audit-config

# === Зробити конфігурацію незмінною (ОСТАННЄ ПРАВИЛО!) ===
-e 2

Після збереження файлу перезавантажте правила:

sudo augenrules --load

Або перезапустіть сервіс:

sudo systemctl restart auditd

Увага: якщо ви активували прапорець -e 2 (незмінна конфігурація), для зміни правил знадобиться повне перезавантаження сервера. Про це легко забути в найбільш невідповідний момент, тож тримайте це в голові.

Поширені помилки та як їх уникнути

За роки роботи з auditd я помітив кілька помилок, які повторюються знову і знову:

Занадто багато правил без фільтрації — підхід «логувати все» звучить привабливо, але на практиці перевантажує систему та ускладнює аналіз. Починайте з мінімального набору і розширюйте за потребою.
Ігнорування продуктивності — завжди перевіряйте auditctl -s після додавання нових правил. Якщо значення lost зростає — зменшіть кількість правил або збільшіть backlog_limit.
Впровадження без тестування — правила auditd можуть призвести до несподіваних наслідків, аж до зависання сервера (при -f 2). Не пропускайте тестове середовище.
Логи на тому ж розділі — якщо основний розділ заповнюється, auditd не зможе записувати події, що може призвести до зупинки системи (залежно від налаштувань disk_full_action).
Правила без ключів (-k) — без тегів пошук у великих лог-файлах перетворюється на справжнє пекло. Завжди додавайте ключі.

Часті запитання (FAQ)

Чим відрізняється auditd від syslog?

Syslog збирає повідомлення від додатків та служб, що самі генерують логи. Auditd працює на рівні ядра, перехоплюючи системні виклики незалежно від додатків. Навіть якщо зловмисник видалить або модифікує бінарний файл програми, auditd все одно зафіксує цю дію. По суті, auditd забезпечує набагато глибшу та стійкішу до маніпулювання видимість подій.

Чи впливає auditd на продуктивність сервера?

Так, але вплив залежить від кількості та типу правил. Правила спостереження за файлами (-w) мають мінімальний вплив. Правила системних викликів (-S) створюють більше навантаження, оскільки оцінюються для кожного виклику. Для продакшн-серверів рекомендується об'єднувати правила, оптимізувати порядок їх розміщення, встановити flush = incremental_async та backlog_limit на 8192. При правильному налаштуванні вплив зазвичай не перевищує 2-5%.

Як захистити журнали auditd від зловмисників?

Ось основні методи: активувати незмінну конфігурацію (-e 2), розмістити логи на окремому розділі, пересилати події в реальному часі на віддалений SIEM-сервер через Laurel та rsyslog, використовувати незмінне (immutable) сховище для резервних копій логів, а також моніторити спроби вимкнення самого auditd (правила T1562.012, про які ми говорили вище).

Які правила auditd потрібні для відповідності PCI-DSS?

PCI-DSS (вимога 10) вимагає журналювання: доступу до даних карток, дій адміністраторів, доступу до журналів аудиту, невдалих спроб автентифікації, змін привілеїв, створення та видалення системних об'єктів. Правила auditd покривають усі ці вимоги через моніторинг файлів облікових даних, команд sudo, конфігурації системи та спроб входу.

Чи можна використовувати auditd разом із eBPF-інструментами?

Так, і багато хто саме так і робить. Auditd забезпечує базовий рівень аудиту з фокусом на відповідність стандартам та криміналістику. eBPF-інструменти (Tetragon, Falco та інші) додають можливості моніторингу в реальному часі, динамічне відстеження поведінки та примусове застосування політик. Вони чудово доповнюють один одного: auditd — надійна, перевірена часом основа, а eBPF — сучасний рівень з мінімальними накладними витратами.