Debian 13: auditd без знищення SSD — практичні налаштування для розумного аудиту

December 28, 2025 • February 3, 2026 • Читання: 6 хв • Views: 9

Було корисно?

Ви вмикаєте auditd, бо комплаєнс хоче «видимість». За тиждень графік записів на сховище нагадує їжака, лічильник зношення SSD по SMART починає підніматися, ніби готується до марафону, а кожен огляд інциденту закінчується фразою: «Чому система гірше працює, коли ми намагаємось підвищити безпеку?»

Ось тверезий спосіб запускати Linux-аудит на Debian 13: зберігайте безпековий сигнал, відсікайте шум і припиніть перетворювати диски на носії лише для запису.

Модель мислення: що насправді робить auditd із вашою машиною

auditd — це не «писач лог-файлів». Це збирач у просторі користувача для підсистеми ядра audit. Правила, які ви завантажуєте, вказують ядру, які події емитувати. Ці події потрапляють у чергу ядра (backlog), а потім їх забирає auditd, форматує і записує — здебільшого у /var/log/audit/audit.log. Якщо ви відправляєте їх кудись ще, у більшості конфігурацій вони все одно спочатку існують локально.

Біль від диска походить із двох місць:

Обсяг подій: надто багато аудиторних викликів системних викликів або спостережуваних шляхів, особливо на «гарячих» шляхах коду (менеджери пакетів, рантайми контейнерів, системи побудови, веб-сервери, що пишуть тимчасові файли).
Шаблон запису: записи аудиту малі й часті. Малі часті додавання з певною синхронністю плюс оновлення метаданих можуть перетворитися на генератор випадкових записів залежно від файлової системи, опцій монтування та поведінки ротації логів.

Ядро аудиту також безжальне щодо коректності. Якщо backlog переповнюється, ви можете втратити події. Якщо ви налаштуєте «panic on failure», ви можете втратити всю машину. Комплаєнс любить другий варіант; операції його ненавидять; вам доведеться домовлятися.

Ось сувора правда: ви не зможете «оптимізувати» набір правил аудиту, який не обмежили. Якщо ви почнете з величезного базового набору, що аудитує кожен openat() і кожен execve() на кожному хості, ви отримаєте багато даних — і багато проблем. Ваше завдання — вирішити, на які питання ви реально повинні відповісти під час інциденту, а потім аудитувати достатньо точно, щоб на них відповісти.

Цитата, що працює в операціях: «Надія — не стратегія.» — ідея, часто віднесена до практиків надійності. В аудиті надія виглядає як «ми просто ввімкнемо це скрізь і відфільтруємо пізніше». Ви не встигнете — ви потонете раніше.

Кілька фактів і трохи історії (корисне)

Аудит у Linux передував більшості «cloud native» інструментів. Linux Audit Framework існує з середини 2000-х, він створювався для регульованих середовищ, яким потрібні були докази відсутності підміни.
SELinux і audit розвивалися разом. Багато ранніх впроваджень аудиту відбувалося в середовищах із SELinux, де потрібні були журнали подій для рішень політик і налагодження.
Пайплайн аудиту — спочатку ядро, потім демон. Якщо простір користувача не встигає, черга ядра накопичується; демон — не єдина рухома частина.
«Watch rules» (-w) базуються на шляхах і дорожчі самі по собі. Вони чудові для невеликого набору критичних файлів; вони — ляпас по пальцю для цілих директорій з великою активністю.
Правила для системних викликів можуть експоненційно вирости швидше, ніж ви очікуєте. Аудит доступу до файлів на завантаженому хості — класичний самонанесений DoS, бо файли відкриваються постійно.
Логи аудиту структуровані, але не орієнтовані на людину в першу чергу. Сирий лог призначений для інструментів на кшталт ausearch і aureport, а не для grep-у о 3:00 ранку (хоча ви все одно будете це робити).
Аудит має реальну історію «закривання при помилці». З audit=1 і строгими налаштуваннями системи можна конфігурувати так, щоб невдача аудиту була фатальною. Це не теоретично — люди так роблять.
Debian історично був поміркованим за замовчуванням. Зазвичай ви не отримуєте масивний набір правил «безкоштовно». Пошкодження зазвичай походить від скопійованих базових конфігурацій комплаєнсу, які не були протестовані на вашому навантаженні.

Жарт №1: Логи аудиту схожі на блискітки — як тільки ви запустите галасливе правило, ви знайдете його скрізь місяцями.

Як виглядає «розумний аудит» у продакшні

Перед тим, як торкатися конфігів, визначте цілі. Інакше ви будете нескінченно сперечатися з Security про «відсутні події», не знаючи, що означає «достатньо».

Операційні цілі (практичні, вимірювані)

Немає постійного посилення записів на диск через аудит. Короткі сплески допустимі; постійне тертя — ні. Бюджет витривалості SSD — реальний.
Немає значного падіння затримки критичних сервісів. Вимірюйте p99 затримку до і після ввімкнення аудиту на репрезентативному навантаженні.
Немає втрати подій аудиту під нормальним навантаженням. Під навантаженням інциденту (fork bomb, заповнений диск) ви вирішуєте політику: скидаємо події, обмежуємо або припиняємо роботу.
Логи аудиту запитувані і інтерпретовані. Якщо для відповіді на «хто змінив конфігурацію SSH» потрібен спеціаліст, система згниє.

Цілі безпеки (що ви справді хочете знати)

Адміністративні дії: створення користувачів, використання sudo, зміни привілеїв.
Зміни, пов’язані з обліковими даними та автентифікацією: SSH-ключі, PAM-конфіг, /etc/shadow.
Запуск чутливих бінарів: sudo, su, менеджери пакетів, менеджери сервісів.
Зміни критичної конфігурації: підмножина /etc, юніти systemd, cron, власне конфіг аудиту.
Дії з ядром/модулями там, де це релевантно: завантаження/вивантаження модулів на хостах, де це має значення.

Якщо вам потрібне «виявлення витоку даних», одного auditd замало. Він може допомогти (наприклад, стежити за доступом до конкретного ключового файлу), але це не система мережевого DLP.

Швидкий план діагностики (полювання на вузькі місця за хвилини)

Коли хтось каже «auditd вбиває диски», не сперечайтесь. Запустіть короткий план і дайте машині розповісти сама.

Перше: це обсяг подій чи поведінка диска?

Перевірте швидкість подій аудиту та стан backlog.
Перевірте шаблони вводу/виводу диска (IOPS, затримки, глибина черги).
Перевірте, чи правила аудиту орієнтовані на syscall чи на watch-и.

Друге: ідентифікуйте правило або навантаження, що створює проблему

Знайдіть найактивніші ключі аудиту (якщо ви використовували ключі).
Зіставте часові позначки: сплески аудиту проти деплоїв сервісів, cron, logrotate.
Пошукайте відстежувані директорії з високим обігом файлів.

Третє: вирішіть, який регулятор ви будете крутити

Зменшіть події: звузьте правила, додайте фільтри, видаліть моніторинг директорій.
Зменшіть біль від запису: налаштуйте flush/freq, ротацію, відокремлений файловий простір, уникайте патологічних опцій монтування.
Збільшіть буферизацію: налаштування backlog, але розумійте пам’ять і семантику втрат.
Змініть поведінку при помилці: скидувати події під тиском чи зберегти систему працездатною?

Практичні завдання (команди, вивід, рішення)

Це реальні перевірки, що можна виконати. Кожна закінчується рішенням: залишити, змінити або ескалювати. Виконуйте їх по порядку вперше; згодом набудете інстинктів.

Завдання 1: Підтвердьте, що аудит увімкнений і демон здоровий

cr0x@server:~$ systemctl status auditd --no-pager
● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 09:12:01 UTC; 2h 3min ago
       Docs: man:auditd(8)
   Main PID: 712 (auditd)
      Tasks: 4
     Memory: 3.2M
        CPU: 1min 22s

Що це означає: Він запущений. Якщо сервіс флапає, ймовірно є помилки конфігурації або проблеми з диском.

Рішення: Якщо він неактивний/не працює, спочатку виправте стан сервісу (місце на диску, синтаксис конфігу, права), перед налаштуванням правил.

Завдання 2: Перевірте стан ядра для аудиту: backlog, режим помилок, стан увімкнення

cr0x@server:~$ sudo auditctl -s
enabled 1
failure 1
pid 712
rate_limit 0
backlog_limit 8192
lost 0
backlog 12
backlog_wait_time 60000

Що це означає: Аудит увімкнений. Backlog майже пустий (backlog 12). failure 1 означає поведінку «printk»; існують жорсткіші режими.

Рішення: Якщо lost зростає, ви втрачаєте події аудиту — вважайте це продакшн-інцидентом для хостів під комплаєнсом.

Завдання 3: Швидко виміряйте обсяг подій аудиту (приблизна швидкість)

cr0x@server:~$ sudo awk 'BEGIN{c=0} {c++} END{print c}' /var/log/audit/audit.log
184223

Що це означає: Сирий лічильник у поточному файлі. Порахуйте разом з часовими мітками файлу, щоб оцінити пропускну здатність.

Рішення: Якщо це число зростає шалено швидко (сотні тисяч на годину на невеликому хості), ймовірно у вас занадто широкі правила syscall.

Завдання 4: Перевірте, які ключі аудиту найактивніші (працює, лише якщо ви використовували -k)

cr0x@server:~$ sudo aureport --summary --key | head
Key Summary Report
=========================================
total  file
=========================================
15432  ssh-config
12011  priv-esc
 8430  pkg-mgr
 4122  cron

Що це означає: Ви бачите, які групи правил генерують найбільше подій.

Рішення: Якщо один ключ домінує, перевірте правила за ним. Звузьте охоплення або додайте виключення.

Завдання 5: Знайдіть шляхи з високим обігом, які відслідковуються (watch rules)

cr0x@server:~$ sudo auditctl -l | sed -n '1,12p'
-w /etc/ssh/sshd_config -p wa -k ssh-config
-w /etc/sudoers -p wa -k priv-esc
-w /etc/sudoers.d/ -p wa -k priv-esc
-w /var/log/ -p wa -k logdir
-a always,exit -F arch=b64 -S execve -F euid=0 -k root-exec

Що це означає: Той рядок -w /var/log/ — як неоновий знак «Мені подобається біль». Відслідковування цілої директорії логів — високочастотна операція.

Рішення: Приберіть моніторинг по всій директорії на шляхах з великою активністю (/var/log, /tmp, сховище контейнерів). Замініть на конкретні файли або фільтри syscall.

Завдання 6: Перевірте тиск вводу/виводу на диску і затримки

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0-1-amd64 (server)  12/30/2025  _x86_64_ (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.12    0.00    1.55    6.78    0.00   88.55

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
nvme0n1          2.10  820.0    45.0  9320.0    4.12   5.05  92.30

Що це означає: Дуже багато записів за секунду, висока завантаженість. Це узгоджується з дрібними додаваннями логів.

Рішення: Якщо w/s величезне і await піднімається під час сплесків аудиту, ви ушкоджені диском. Зменшіть обсяг подій і/або згладьте записи за допомогою налаштувань auditd і відокремлення файлової системи.

Завдання 7: Підтвердьте файлову систему для логів аудиту та параметри монтування

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /var/log/audit
/dev/mapper/vg0-varlog ext4 rw,relatime,errors=remount-ro

Що це означає: Логи аудиту на ext4 з relatime. Це розумний вибір.

Рішення: Якщо логи аудиту поділяють зайняту root FS, наполегливо розгляньте виділену FS для /var/log або /var/log/audit, щоб записи аудиту не конкурували з базами даних або шарами контейнерів.

Завдання 8: Підтвердьте, що journald не подвоює проблему

cr0x@server:~$ sudo journalctl -u auditd -n 20 --no-pager
Dec 30 10:11:22 server auditd[712]: Audit daemon started successfully
Dec 30 10:14:05 server auditd[712]: Audit backlog limit exceeded
Dec 30 10:14:05 server auditd[712]: Audit events lost

Що це означає: Ви бачите тиск на backlog. Journald здебільшого не є логом аудиту, але зафіксує повідомлення від auditd.

Рішення: Якщо backlog перевищено, зменшуйте швидкість подій або збільшуйте ємність (backlog/CPU), а не «акуратно крутіть ротацію».

Завдання 9: Слідкуйте за лічильниками backlog і lost у реальному часі

cr0x@server:~$ watch -n 1 'sudo auditctl -s | egrep "lost|backlog |backlog_limit|backlog_wait_time"'
Every 1.0s: sudo auditctl -s | egrep "lost|backlog |backlog_limit|backlog_wait_time"  server: Tue Dec 30 11:16:02 2025

backlog_limit 8192
lost 0
backlog 23
backlog_wait_time 60000

Що це означає: Якщо backlog зростає і залишається високим, auditd не встигає спустошувати події.

Рішення: Якщо backlog росте під час конкретних робіт (наприклад, бекапів), звузьте правила, щоб ці роботи не породжували нерелевантні події.

Завдання 10: Знайдіть найактивніші типи записів у audit.log

cr0x@server:~$ sudo awk '{print $2}' /var/log/audit/audit.log | cut -d'=' -f2 | sort | uniq -c | sort -nr | head
 88421 SYSCALL
 60210 PATH
  9102 CWD
  3210 EXECVE

Що це означає: Багато записів SYSCALL і PATH вказує, що більшість — це аудит системних викликів. Це нормально; питання в тому, чи надто широке охоплення.

Рішення: Якщо PATH домінує, можливо ви широкомасштабно аудитуєте відкриття/атрибути файлів. Звужуйте правила фільтрами по директоріях/файлах і по auid/euid.

Завдання 11: Підтвердіть політику ротації логів аудиту

cr0x@server:~$ sudo grep -E '^(max_log_file|num_logs|max_log_file_action|space_left_action|admin_space_left_action|disk_full_action|flush|freq)' /etc/audit/auditd.conf
max_log_file = 50
num_logs = 10
max_log_file_action = ROTATE
space_left_action = SYSLOG
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
flush = INCREMENTAL_ASYNC
freq = 50

Що це означає: Ротація увімкнена. flush = INCREMENTAL_ASYNC із freq=50 зменшує тиск синхронних записів і водночас обмежує вік втрат.

Рішення: Якщо ви бачите flush = SYNC на зайнятих хостах — очікуйте проблем. Якщо num_logs занадто велике з гігантськими файлами, ви можете локально накопичувати без сенсу.

Завдання 12: Перевірте, що файли правил реально завантажені (і не дубльовані)

cr0x@server:~$ sudo augenrules --check
No change

Що це означає: Скомпільовані правила відповідають тому, що на диску. Немає незастосованих змін.

Рішення: Якщо повідомляє про зміни, перезавантажуйте правила контрольовано; уникайте «гарячого» перевантаження під час пікового трафіку, якщо ви використовуєте immutable режим.

Завдання 13: Перевірте, чи правила є immutable (і чи їх важко змінити в кризу)

cr0x@server:~$ sudo auditctl -s | grep enabled
enabled 1

cr0x@server:~$ sudo auditctl -e 2
Error sending enable request (Operation not permitted)

Що це означає: Якщо ви вже в immutable-режимі (-e 2 встановлено при завантаженні), ви не можете змінити правила без перезавантаження.

Рішення: Використовуйте immutable-режим лише на системах, де це операційно прийнятно та протестовано. Інакше ви ризикуєте довго боротися з невдалим розгортанням.

Завдання 14: Перевірте індикатори зношення SSD (перевірка здорового глузду, не параної)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'percentage|data units written|wear|media'
Percentage Used:                    3%
Data Units Written:                 8,421,332 [4.31 TB]
Media and Data Integrity Errors:    0

Що це означає: Ви можете зіставити зростання записів з увімкненням аудиту. Не вгадуйте — виміряйте.

Рішення: Якщо «Data Units Written» різко зростає після ввімкнення аудиту — розглядайте це як питання планування ємності і налаштуйте відповідно.

Завдання 15: Знайдіть найгаласливіші виконувані файли (поширена причина: менеджери пакетів і оркестрація)

cr0x@server:~$ sudo ausearch -m SYSCALL -ts today | grep -oE 'exe="[^"]+"' | sort | uniq -c | sort -nr | head
  812 exe="/usr/bin/dpkg"
  640 exe="/usr/bin/apt"
  418 exe="/usr/bin/python3.12"
  251 exe="/usr/sbin/cron"

Що це означає: У вас є сплески, пов’язані з активністю пакетного менеджера та cron. Це не злочин; це передбачувано.

Рішення: Якщо ви інтенсивно аудитуєте менеджери пакетів, прийміть сплески під час вікон оновлення — або додайте часові/хостові правила для вікон патчів.

Завдання 16: Побудуйте звіт «хто торкав /etc/shadow» (доказ, що аудит працює)

cr0x@server:~$ sudo ausearch -f /etc/shadow -ts this-week | aureport -f -i | head
File Report
===============================================
# date time            file                 syscall success exe                  auid event
===============================================
1. 12/29/2025 02:10:12 /etc/shadow           openat  yes     /usr/sbin/usermod    admin  19402

Що це означає: Це той тип питання, на який аудит має швидко відповідати. Якщо не може — ваші правила або занадто слабкі, або занадто хаотичні.

Рішення: Залишайте правила, що відповідають реальним інцидентним питанням. Видаліть ті, що створюють шум, але не впливають на рішення.

Правила, що не плавлять диски: стратегія та приклади

Правила аудиту — це місце, куди диски йдуть помирати. Більшість порад щодо «налаштування auditd» — просто «вимкніть аудит». Це ліниво. Реальний крок — перейти від широкого покриття системних викликів до вузького, орієнтованого на намір покриття.

Принцип 1: Віддавайте перевагу цілеспрямованим watch-ам для критичних файлів, а не зайнятим директоріям

Відстежувати /etc/shadow дешево і корисно. Відстежувати /var/log — це лист-про-підрив самому собі.

Корисні приклади watch-ів:

/etc/passwd, /etc/shadow, /etc/group
/etc/sudoers, /etc/sudoers.d/
/etc/ssh/sshd_config і, можливо, /etc/ssh/sshd_config.d/
/etc/audit/ (так, стежте за тим, хто стежить)
Файли unit-ів systemd, що реально важливі: /etc/systemd/system/

Принцип 2: Якщо аудитуєте syscalls, фільтруйте за ідентичністю та наміром

Аудитувати execve для кожного користувача на сервері збірки буде генерувати щоденник довжиною в роман. Натомість:

Аудитуйте привілейовані виконання (euid=0), ініційовані реальними користувачами (auid>=1000).
Аудитуйте зміни (запис/зміни атрибутів) для невеликої множини файлових систем або директорій.
Виключайте відомі джерела шуму (backup, monitoring), якщо політика дозволяє — і документуйте виключення.

Принцип 3: Використовуйте ключі релігійно

Ключі (-k) — це не декор. Це спосіб триажу. Без ключів ви будете дивитися на сирі записи і відчувати, як душа відлітає.

Здоровий базовий набір правил (суб’єктивно)

На Debian правила зазвичай керуються через /etc/audit/rules.d/*.rules і компілюються у /etc/audit/audit.rules за допомогою augenrules.

Приклад: /etc/audit/rules.d/10-sane-baseline.rules (ілюстративно, не максимальний):

cr0x@server:~$ sudo cat /etc/audit/rules.d/10-sane-baseline.rules
## Identity and auth files
-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

## Sudoers and SSH
-w /etc/sudoers -p wa -k priv-esc
-w /etc/sudoers.d/ -p wa -k priv-esc
-w /etc/ssh/sshd_config -p wa -k ssh-config
-w /etc/ssh/sshd_config.d/ -p wa -k ssh-config

## Audit configuration itself
-w /etc/audit/ -p wa -k audit-config

## Systemd unit overrides (where persistence happens)
-w /etc/systemd/system/ -p wa -k systemd-units
-w /etc/systemd/system.conf -p wa -k systemd-units
-w /etc/systemd/journald.conf -p wa -k logging

## Cron persistence
-w /etc/cron.d/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Privileged command execution by real users
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k root-exec
-a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k root-exec

Цей базис робить кілька важливих речей:

Фокусується на утриманні та привілеях, які релевантні інцидентам.
Уникає аудиту системних викликів для відкриття файлів — саме там обсяг подій виходить з-під контролю.
Мітить усе ключами, щоб ви могли виконати триаж за хвилини.

Де люди помиляються: «логувати все» через syscall-правила

Поширений базовий набір комплаєнсу аудитує доступ до файлів широко, часто щось на кшталт «аудитувати всі помилки open/openat», або «аудитувати всі записи будь-ким». На сучасній Linux-системі це майже те саме, що аудитувати сам факт дихання.

Якщо ви мусите аудитувати записи файлів — робіть це вузько:

Конкретні директорії з секретами або регульованими даними.
Конкретні сервісні акаунти, що взаємодіють з цими даними.
Лише успішні записи/зміни атрибутів, якщо невдача не є безпековим сигналом у вашому середовищі.

Контролі шуму, які варто застосовувати

Ви можете фільтрувати відомі джерела шуму за полями на кшталт auid, uid, exe і dir. Пастка: кожне виключення — це майбутнє «сліпе» місце. Переконайтеся, що виключення — це політичне рішення, а не зручність.

Приклад: виключити спеціального користувача агента бекапу з аудиту привілейованих запусків (лише якщо Security згодна):

cr0x@server:~$ sudo cat /etc/audit/rules.d/20-exclusions.rules
## Exclude known automation account from root-exec noise
-a never,exit -F arch=b64 -S execve -F auid=1105 -k exclude-backup
-a never,exit -F arch=b32 -S execve -F auid=1105 -k exclude-backup

Жарт №2: Найшвидший спосіб відкрити «рідкий» шлях виконання — аудитуйте його в продакшні.

Налаштування демона auditd, що мають значення (і чому)

Правила визначають обсяг. auditd.conf визначає, наскільки болісно цей обсяг зберігати і що відбувається, коли щось йде не так.

Стратегія flush: індикатор настрою диска

Ключові налаштування:

flush: як auditd скидає дані на диск.
freq: як часто скидаються дані при використанні інкрементальних режимів.

Практична рекомендація для більшості продакшн-хостів: flush = INCREMENTAL_ASYNC і помірне значення freq (наприклад, 50–200). Це зменшує проблему «дрібні синхронні записи щодня».

Що віддаєте в обмін: більший вік втрат подій при раптовому падінні хоста. Вирішіть, чи це прийнятно залежно від класу хоста. Для жорстких комплаєнс-хостів вас можуть змусити до суворішого скидання. Якщо так — необхідно ще агресивніше звужувати обсяг подій.

Ротація логів: зробіть її нудною

Логи аудиту ротуються інакше, ніж загальні логи; не дозволяйте logrotate вас здивувати. Використовуйте власні руківки auditd для ротації:

max_log_file і num_logs визначають локальне збереження.
max_log_file_action = ROTATE зазвичай правильний вибір.
max_log_file_action = KEEP_LOGS — це шлях до повного диска і філософського інциденту.

Дії при браку дискового простору: вирішуйте, як виглядає відмова

Ці налаштування — це прихована політика:

space_left_action, admin_space_left_action
disk_full_action, disk_error_action

Для загальних продакшн-хостів я надаю перевагу: голосно сповістити, зберегти роботу машини і зберегти те, що можна. Для регульованих кінцевих точок вам можуть наказати призупинити аудит або навіть зупинити систему. Якщо ваша політика — «зупинити при заповненні диска», краще мати окремі файлові системи і моніторинг, що вловить ріст перед обривом.

Backlog і час очікування: поглинайте сплески, але не обманюйте себе

Налаштування backlog ядра допомагає пережити сплески: оновлення пакетів, роботи CI, cron-шторми. Більший backlog може допомогти — поки не перестане, і тоді ви просто відклали втрату.

Використовуйте розмір backlog для легітимних сплесків, але обробляйте постійний backlog як «ваші правила занадто широкі», а не «додайте більше буфера». Буфери не дають пропускну здатність.

Практична позиція Debian 13 щодо immutable mode

Immutable mode (закриті правила до перезавантаження) корисний, щоб не дати зловмиснику відключити аудит після отримання root. Він також корисний, щоб не дозволити вам швидко виправити невдале розгортання.

Моя думка: використовуйте immutable mode лише на хостах, де у вас є:

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

Реалії сховища та файлових систем: ext4, XFS, ZFS, NVMe

Логування аудиту — це навантаження з малими записами. На сучасному сховищі малі записи не автоматично погані — поки ви не перетворите їх на постійний потік з метаданним шумом і форсованими скиданнями.

Розділіть радіус ураження

Якщо ви можете зробити лише одну зміну в сховищі: помістіть /var/log або принаймні /var/log/audit на окрему файлову систему з розумним розміром і моніторингом. Це дає три переваги:

запобігає заповненню root і «вбиванню» хоста через ріст логів,
зменшує конкуренцію вводу/виводу з даними додатків,
дозволяє застосувати оптимізації файлової системи/монтування без торкання всього іншого.

ext4: добре, нудно, передбачувано

ext4 на NVMe зазвичай підходить, якщо уникати патологічних налаштувань. Використовуйте relatime. Не монтуйте з sync. Не кладіть лог аудиту на ту ж FS, що й зайнята база даних, якщо ви любите ігри «хто винен».

XFS: сильний при конкурентності, але не чарівник

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

ZFS: відмінний інструмент, інші режими відмов

Якщо ви пишете логи аудиту на ZFS, доступні інші налаштування. ZFS може перетворювати багато малих записів у різні IO-шаблони залежно від recordsize, sync-настроювань і поведінки SLOG. Це може бути чудово, але легке помилкове налаштування може перетворити «малі додавання» в «багато синхронних транзакцій».

Практична позиція: якщо ви не вже експлуатуєте ZFS зріло, не впроваджуйте його тільки щоб «вирішити auditd». Спочатку виправте обсяг правил.

Витривалість NVMe SSD: не тендітні, але не вічні

Сучасні enterprise SSD можуть витримати багато, але витривалість — це бюджет. Те, що вбиває — це тривалі непотрібні записи. Аудит часто генерує тривалі непотрібні записи при неправильній конфігурації. Використовуйте SMART-лічильники, щоб довести свою точку зору стейкхолдерам.

Транспортування, агрегація та збереження корисності логів аудиту

Локальні логи аудиту необхідні, але недостатні. В реальних інцидентах скомпрометований хост — найменш довірене місце для зберігання істини.

Локально спочатку, віддалено завжди (але не дублюйте записи до смерті)

Багато середовищ відправляють логи аудиту у SIEM через агента, що читає /var/log/audit/audit.log. Це нормально. Слідкуйте за двома проблемами:

Підсилення IO від tail-у: деякі агенти погано поводяться при ротації або роблять часті fsync-и. Протестуйте вашого шипера.
Вибухи парсингу: якщо ваш SIEM-пайплайн не справляється, Security може попросити «зберігати сирі логи локально назавжди». Опирайтесь. Визначте ретеншн і доведіть, що віддалий пайплайн працює.

Зробіть ключі й метадані хоста першокласними

Якщо ви не маркуєте правила ключами і не анотуєте події у пайплайні роллю хоста, середовищем і власником, ви отримаєте глобальне озеро однакового шуму. Ось як «аудит» перетворюється на «дороге сховище з відчуттями».

Політика збереження: не накопичуйте локально без потреби

Локальна ретеншн потрібна для:

короткострокового реагування на інциденти, коли центральне логування затримується,
буферизації на випадок мережевих відмов,
базової судової послідовності.

Це не для багатомісячного архівування, якщо тільки у вас немає специфічної вимоги і плану зберігання. Налаштуйте max_log_file і num_logs відповідно до виміряного обсягу подій і реалістичного вікна відключення для вашого лог-пайплайну.

Три корпоративні міні-історії з практики

Інцидент через хибне припущення: «логи аудиту — це просто логи, їх можна стискати»

У середній компанії з міксом Debian і Ubuntu Security розгорнула «стандартний базовий набір Linux аудиту» в квартал, коли і так було багато навантаження. Базовий набір включав аудит системних викликів для великого набору файлових операцій, бо шаблон писався для значно менших флітів і тихої робочої нагрузки.

Операції припустили, що це поводитиметься як звичайне текстове логування: «Це логи, це послідовні записи; стиснення і ротація впораються». Це припущення швидко померло на CI-хостах. Ці хости вже були зайняті контейнерними завантаженнями, розпаковуванням шарів і записом кешів. Нові правила аудиту фактично записували значну частку того обігу.

Перший симптом був не помилкою аудиту. Це були таймаути збірки і раптові підйоми IO wait. Заточні сервіси, що знаходилися поруч на тих же гіпервізорах, почали повідомляти «випадкові» уповільнення. Потім — справжній сюрприз: деякі хости почали втрачати події аудиту, бо backlog заповнився під час пікованих хвиль збірок.

Виправлення не було героїчним. Вони видалили широкі правила файлових syscall, залишили цілеспрямовані watch-и для identity та persistence файлів, і обмежили аудит привілейованих exec лише для реальних користувачів через auid. Також перемістили /var/log/audit на окрему файлову систему на критичних хостах. Комплаєнс задовольнилося, бо питання «хто змінив identity і привілеї» знову можна було відповісти, і фліт перестав «перетворюватися на пасту».

Оптимізація, що відпрацювала назад: «зробити audit довговічним, поставити flush = SYNC»

Команда у фінансовому секторі хотіла сильні гарантії: «Ніколи не губити події аудиту». Хтось налаштував auditd.conf для максимальної довговічності. Поставили flush = SYNC і загострили дії при вичерпанні простору так, щоб система призупинялася, коли місця стало мало.

На папері це виглядає як відповідальність. На практиці це перетворило рутинну адміністративну роботу на сплески затримок. Кожний сплеск подій перекладався в синхронний тиск на запис. Під час вікон патчів менеджери пакетів генерували густі хвилі подій (exec, зміни конфігів). Затримки зростали. Вікно патчу подовжувалося. Люди робили повторні спроби. Повторний шторм погіршував ситуацію.

Потім зворотний ефект: збій пайплайну логів затримав відправку поза хост. Локальні логи росли швидше, ніж очікували. Виділена файловa система для логів заповнилася раніше, ніж планували. Система призупинила аудит у момент, коли це було критично — під час складного операційного інциденту — через жорсткі дії при браку простору. Вони не втратили саму машину, але втратили трасу аудиту саме за період, який цікавив аудиторів.

Підсумкова конфігурація була менш «чистою», але надійнішою: інкрементальне асинхронне скидання, обережно розмірене локальне збереження, моніторинг використання файлової системи логів і узгоджена політика на випадок тиску на ресурси. «Ніколи не губити події» перетворилося на «не губити події в нормальній роботі; при виснаженні ресурсів — зберегти систему і негайно сповістити». Це працювало.

Нудна, але правильна практика, що врятувала день: ключі, мінімальні правила і репетиція

Команда healthcare SaaS була вже обпікшоюся раніше, тому вони зробили те, що не дуже модно: написали набір правил аудиту з суворим обмеженням, призначили ключі для кожного правила і поклали його під керування конфігурацією з peer review. Кожне правило мало «інцидентне питання» в повідомленні коміту: «Виявити зміни SSH конфігу», «Виявити шляхи привілеїв», «Виявити збереження через cron».

Вони також репетирували. Щоквартально вони проводили столову вправу: симулювали скомпрометований обліковий запис адміністратора, змінювали drop-in для systemd, додавали cron-завдання і змінювали SSH конфіг. Потім перевіряли, що можуть отримати ці події через ausearch швидко, без племінних знань.

Коли стався реальний інцидент — витік облікових даних інженера, які використали для зміни include у sudoers — відповідь була нудною у найкращому сенсі. На черговому викликали priv-esc підсумок ключа, витягли вікно змін і підтвердили акаунт-актор через auid. Відкат, ротація облікових даних і наявність доступного журналу для пояснення керівництву — все пройшло гладко.

Ніхто не святкував набір правил аудиту. Він не мав привабливого дашборду і не «інтегрувався з AI». Просто працював і не вбив диски.

Типові помилки: симптом → первинна причина → виправлення

1) Симптом: IOPS запису диска різко зростає одразу після ввімкнення auditd

Первинна причина: Широкі syscall-правила (зазвичай open/openat або watch-и директорій на гарячих шляхах), що створюють масивний обсяг подій.

Виправлення: Видаліть широкі правила доступу до файлів; замініть їх цілеспрямованими -w watch-ами для критичних файлів і правилами привілейованих execve, відфільтрованими за auid і euid. Використовуйте ключі для ідентифікації топ-винуватців.

2) Симптом: лічильник `lost` зростає; journald показує «backlog limit exceeded»

Первинна причина: Продукція подій аудиту перевищує споживання; auditd не встигає спустошувати чергу; backlog переповнюється.

Виправлення: Спочатку зменшіть швидкість подій (звуження правил). Друге — збільшіть backlog_limit для сплесків. Третє — перевірте конкуренцію CPU і затримки IO; блокування запису auditd може спричинити каскад переповнень backlog.

3) Симптом: Затримки хоста під час патчів або CI робіт

Первинна причина: Аудит привілейованих exec або змін файлів широко; менеджери пакетів і інструменти збірки викликають сплески. Часто поєднується з flush = SYNC.

Виправлення: Залишайте аудит привілейованих запусків, але звузьте (тільки реальні користувачі). Використовуйте INCREMENTAL_ASYNC для flush. Розгляньте виключення для відомих автоматизованих акаунтів, якщо політика дозволяє.

4) Симптом: Root FS заповнюється, система стає нестабільною

Первинна причина: Логи аудиту на root FS, KEEP_LOGS або невідповідна ротація згідно реального обсягу подій. Іноді — падіння відправки віддалених логів плюс надто велике локальне збереження.

Виправлення: Помістіть /var/log/audit на окрему файлову систему. Використовуйте ROTATE. Встановіть ретеншн згідно виміряного обсягу подій і реалістичного вікна відключення. Моніторте використання.

5) Симптом: Ви не можете змінити правила під час інциденту

Первинна причина: Immutable mode увімкнено при завантаженні (-e 2), іноді без операційного плану.

Виправлення: Не вмикайте immutable mode доти, поки правила не будуть валідовані під продакшн-навантаженням і відкат не буде відрепетируваний. Якщо вже увімкнено — реальний варіант лише перезавантаження з виправленими правилами.

6) Симптом: Логи аудиту величезні, але ви все одно не можете відповісти «хто змінив X?»

Первинна причина: Немає ключів, правила розфокусовані і віра, що обсяг = видимість.

Виправлення: Перепишіть правила навколо інцидентних питань. Використовуйте ключі. Протестуйте, виконавши кілька контрольованих змін і перевіривши отримання через ausearch/aureport.

7) Симптом: Високий IO навіть коли система «іidle»

Первинна причина: Відстежування директорій з високим обігом як-от /var/log, /tmp або overlay-сховище контейнерів. «Проста» активність — міф; фонова активність є завжди.

Виправлення: Приберіть watch-и директорій і аудитуйте конкретні критичні файли. Якщо вам потрібен аудит контейнерів, використовуйте телеметрію рантайму, а не blanket path watch-и.

Чеклісти / покроковий план

План A: ви вперше вмикаєте auditd на Debian 13

Визначте інцидентні питання. Приклади: «Хто змінив sudoers?», «Хто модифікував SSH конфіг?», «Яка людина виконувала команди від root?»
Почніть з мінімального набору правил. Watch-и для identity/auth/persistence; привілейовані exec відфільтровані за auid.
Мітте все ключами. Ви будуєте інтерфейс діагностики, а не просто файл журналу.
Встановіть flush = INCREMENTAL_ASYNC і оберіть freq. Почніть з 50; налаштовуйте за обсягом подій і прийнятним вікном втрат.
Відокремте /var/log/audit, якщо хост зайнятий або критичний. Зменшіть радіус ураження.
Налаштуйте ротацію розумно. max_log_file_action = ROTATE, розмір файлів по виміряним обсягам, ретеншн згідно відправки.
Завантажте правила через augenrules і перевірте. Переконайтеся, що немає дублів чи застарілих файлів.
Протестуйте під реальним навантаженням. Слідкуйте за lost, backlog, IO затримками і p99 сервісів.
Визначте політику відмов. При заповненні диска або помилці аудиту: сповіщати, призупинити чи зупинити? Покладіть це письмово.
Лише після цього розглядайте immutable mode. Якщо ви не можете швидко перезавантажити — не блокуйте можливість виправлень.

План B: auditd вже розгорнутий і диски кричать

Підтвердіть втрату подій/поведінку backlog. Якщо ви втрачаєте події — ви вже падаєте з головною метою.
Знайдіть найгарячіші ключі й правила. Використовуйте aureport --key і auditctl -l.
Видаліть очевидні пастки. Watch-и директорій на шляхах з великим обігом, широкі syscall-правила open/openat.
Переключіться на incremental async flush, якщо безпечно. Якщо політика забороняє — потрібно ще більше звузити обсяг подій.
Перемістіть логи аудиту на окрему файлову систему. Робіть це у вікні технічного обслуговування, якщо потрібно. Це знижує ризики.
Переміряйте знову. IO, backlog, втрати подій і вашу спроможність відповідати на ключові інцидентні питання.

FAQ

1) Чи зробить `flush = INCREMENTAL_ASYNC` логи аудиту «небезпечними»?

Це збільшує вік втрат подій при раптовому краші. Для більшості продакшн-систем цей компроміс прийнятний, якщо тримати обсяг подій під контролем і швидко відправляти логи поза хост.

2) Чи слід аудитуувати кожний `execve` в системі?

Ні. Аудитуйте привілейовані execve (euid=0), ініційовані реальними користувачами (auid≥1000). Це захоплює більшість значущих випадків ескалації без потоплення вас в даних.

3) Чому відстежування директорії значно гірше, ніж файлу?

Директорії з обігом створюють постійний потік подій створення/переіменування/зміни атрибутів. На логових або тимчасових директоріях цей потік постійний. Відстежування кількох конкретних файлів дає високий сигнал при низькому обсязі.

4) Чи можна покладатися на journald замість auditd?

Ні, не для семантики ядра аудиту. Journald добре підходить для логів сервісів. Auditd забезпечує структурований захоплення безпекових подій з підсистеми ядра з іншими гарантіями і полями.

5) Який найшвидший доказ того, що мій набір правил корисний?

Виконайте контрольовану зміну: відредагуйте /etc/ssh/sshd_config, запустіть visudo або змініть файл у /etc/sudoers.d, потім витягніть події через ausearch -k ssh-config і ausearch -k priv-esc.

6) Чи справді переміщення `/var/log/audit` на окрему файлову систему допомагає продуктивності?

Іноді. Найбільший виграш — ізоляція: ви припиняєте конкуренцію записів аудиту з IO додатків і зменшуєте ризик заповнення root. Поліпшення продуктивності залежить від стеку зберігання.

7) Наскільки великим має бути `backlog_limit`?

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

8) Чи слід вмикати immutable mode на всіх серверах?

Ні. Використовуйте його вибірково там, де операційна вартість «потрібно перезавантаження для зміни правил» прийнятна і відпрацьована. Інакше це перетворює неправильні конфігурації в тривалі відмови.

9) Нам потрібне «все» для комплаєнсу. Що сказати аудиторам?

Визначте «все» як «все, релевантне для безпекових контролів». Надайте докази: правила зіставлені з контролями (зміни ідентичностей, ескалація привілеїв, збереження), моніториться втрата подій, і логи відправляються поза хост з ретеншном.

10) Чому я бачу кілька записів (SYSCALL, PATH, CWD) на одну дію?

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

Висновок: наступні кроки, які можна виконати сьогодні

Якщо ваше розгортання auditd на Debian 13 шкодить дискам, не починайте з магічних чисел. Почніть зі стиснення вогню подій. Приберіть watch-и директорій на шляхах з інтенсивним обігом. Перестаньте аудитуати широкі файлові syscall-и, якщо у вас нема вузько визначеної мети і виміряного бюджету. Залишайте правила, що відповідають реальним інцидентним питанням, і мітте їх ключами, щоб мати докази.

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