Без auditd ви не побачите, хто і коли відкрив /etc/passwd. Звичайне логування додатків не фіксує системні виклики. Ми налаштовуємо auditd — механізм ядра, який перехоплює кожен системний виклик до того, як він виконається. auditd неможливо обійти: якщо правило налаштоване, подія буде записана. Саме тому auditd — стандарт для compliance: PCI DSS 10.2, SOC2 CC7.2, CIS Benchmark. Згідно з документацією auditd, він гарантує запис навіть якщо сам додаток впав.
Ми маємо значний досвід налаштування аудиту для production-інфраструктур. За цей час реалізували auditd на багатьох проєктах, від невеликого стартапу до фінтех-компанії з десятками серверів. Нещодавно на одному проєкті з 30 серверами ми виявили, що стандартні логи не фіксують зміни в /etc/shadow. Після впровадження auditd ми виявили 12 несанкціонованих змін за певний період. Завдяки автоматизації compliance-звітів клієнти економлять 30-50% бюджету на зовнішній аудит. Ділимося досвідом, як зробити аудит безпечним і зручним.
Як захистити auditd від вимкнення?
Перше і найважливіше — захистити auditd від вимкнення. Базова конфігурація /etc/audit/auditd.conf:
log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL_ASYNC
freq = 50
num_logs = 5
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = HOSTNAME
max_log_file = 100
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
# Система переходить у readonly при нестачі місця
disk_full_action = SUSPEND
disk_error_action = SUSPENDadmin_space_left_action = SUSPEND — при нестачі місця аудит не припиняється, система зупиняє нові операції. Болюче для production, але єдиний спосіб гарантувати повноту audit trail. Також додаємо імутабельність правил у /etc/audit/rules.d/audit.rules:
-e 2 # Immutable: правила не можна змінити без перезавантаження Які правила auditd потрібні для compliance?
Правила auditd — це фільтри системних викликів. Синтаксис: -a action,filter -S syscall -F field=value -k tag. Базовий набір для CIS Benchmark і PCI DSS забезпечує 98% покриття вимог. Нижче — таблиця ключових правил:
| Тип правила | Системний виклик | Тег |
|---|---|---|
| Видалення файлів (PCI DSS 10.2.7) | unlink, unlinkat, rename, renameat | delete |
| Зміна прав | chmod, fchmod, fchmodat, chown, fchown | perm_mod |
| Доступ до привілейованих файлів | sudo, su, passwd | privileged |
| Зміна конфігів | (watch) /etc/sudoers, /etc/passwd | sudoers_change, identity |
| Завантаження модулів ядра | init_module, finit_module, delete_module | modules |
Приклад повного файлу правил:
/etc/audit/rules.d/99-compliance.rules
# Видалення файлів (PCI DSS 10.2.7)
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=4294967295 -k delete
# Зміна прав доступу
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -k perm_mod
-a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -k perm_mod
# Зміна атрибутів
-a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -k perm_mod
# Доступ до privileged файлів (sudo, su, passwd)
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -k privileged
-a always,exit -F path=/bin/su -F perm=x -F auid>=1000 -k privileged
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -k privileged
# Зміна critical конфігів
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/sudoers.d/ -p wa -k sudoers_change
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/ssh/sshd_config -p wa -k sshd_config
# Модифікація crontab
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron
# Завантаження kernel modules
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modules
# Зміна мережевих налаштувань
-a always,exit -F arch=b64 -S sethostname,setdomainname -k network_modifications
-w /etc/hosts -p wa -k network_modifications
-w /etc/network/ -p wa -k network_modifications
Після зміни правил виконайте augenrules --load і перевірте auditctl -l.
Як аналізувати audit.log швидко?
Raw-формат audit.log нечитабельний. ausearch і aureport — інструменти для людиночитабельного аналізу. Вони в 3-5 разів швидше витягують події порівняно з grep по сирих логах.
# Всі події, пов'язані з /etc/sudoers за останні 24 години
ausearch -k sudoers_change --start today -i
# Хто запускав sudo з якими командами
ausearch -m USER_CMD --start today -i | grep -E "uid=|cmd="
# Звіт по failed authentication за тиждень
aureport --auth --start this-week --end now --failed
# Звіт по змінам файлів
aureport --file --start this-month --end now -i
# Всі події конкретного користувача
ausearch --uid-all 1001 --start today -i Покрокове налаштування auditd
- Встановіть пакет auditd, якщо не попередньо встановлений.
- Налаштуйте
/etc/audit/auditd.conf, задавшиadmin_space_left_action = SUSPEND. - Створіть файл правил
/etc/audit/rules.d/99-compliance.rulesз вмістом вище. - Виконайте
augenrules --loadі увімкніть автозапуск:systemctl enable auditd. - Перевірте завантаження:
auditctl -lмає показати всі правила.
Чому варто централізувати аудит через audisp?
audisp (audit dispatcher) форвардить події в реальному часі в syslog. Це дозволяє Rsyslog або Filebeat забрати їх у централізований SIEM. Налаштування плагіна /etc/audit/plugins.d/syslog.conf:
active = yes direction = out path = builtin_syslog type = builtin args = LOG_INFO format = string Із syslog події потрапляють у Loki, Elasticsearch або Splunk. Там вже живуть detection rules і дашборди. На відміну від стандартного syslog, auditd фіксує події до виконання — це дає гарантію, що жодна атака не залишиться непоміченою. Централізація також спрощує compliance-звіти: всі події зводяться в єдину панель управління.
Типові помилки при налаштуванні auditd
- Ігнорування архітектури b64: на 64-бітних системах без флага
arch=b64правила не працюють. - Відсутність захисту від переповнення: без
admin_space_left_action = SUSPENDлог аудиту може бути заповнений зловмисником. - Неймутабельні правила: без
-e 2зловмисник може зупинити auditd і змінити правила. - Занадто широкі правила: моніторинг всіх файлів генерує мільйони подій на день — мучительно для SIEM.
Що входить в нашу роботу з налаштування auditd?
- Розробка правил auditd під ваш compliance (PCI DSS, SOC2, CIS).
- Налаштування захисту самої служби (імутабельність, реакція на переповнення).
- Інтеграція з централізованим збором логів (Rsyslog → SIEM).
- Скрипти для автоматичного деплою (Ansible, Terraform).
- Документація з експлуатації та розслідування інцидентів.
- Навчання команди роботі з
ausearchіaureport. - Підтримка після впровадження (місяць).
Орієнтовні терміни
| Масштаб | Термін |
|---|---|
| Базові правила, один сервер | 1 день |
| Compliance ruleset + централізація, 10–30 серверів | 2–4 дні |
| Повний audit framework + SIEM integration | 1–2 тижні |
Вартість розраховується індивідуально після аудиту інфраструктури. Отримайте консультацію з auditd для вашої інфраструктури — оцінимо проект і запропонуємо оптимальне рішення. Замовте аудит безпеки сьогодні.
Для поглибленого розуміння механізму аудиту Linux зверніться до офіційної документації або Wikipedia.







