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

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

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

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

Одна особливість: у деяких версіях auditd не перезапускається через systemctl restart — службою керує власна команда. Правила перечитуються так:

sudo augenrules --load
sudo auditctl -l

Друга команда показує, що завантажено насправді. Довіряйте їй, а не вмісту файлів.

Набір правил

Правила кладуть у /etc/audit/rules.d/ окремим файлом. Нижче — мінімальний набір, який себе виправдовує: він відповідає на більшість питань, що виникають під час інциденту, і не забиває диск.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Користувачі та привілеї
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privileges
-w /etc/sudoers.d/ -p wa -k privileges

## Доступ по SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## Заплановані завдання
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Модулі ядра
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

## Використання sudo і su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

Синтаксис короткий: -w — шлях, за яким стежити, -p wa означає реагувати на запис і зміну атрибутів, -p x — на виконання, -k — ключ для подальшого пошуку. Саме ці ключі й дають головну зручність: без них пошук у журналі перетворюється на просіювання гігабайта тексту.

Чого в цьому списку немає й чому

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

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

Як це читати

Пошук за ключем, з розшифруванням числових ідентифікаторів в імена:

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

Прапорець -i необхідний для читабельності: без нього ви отримаєте числа замість імен користувачів і системних викликів. -ts обмежує період (today, recent або конкретна дата).

Зведення за період:

sudo aureport --summary -i
sudo aureport --auth -i --failed

У записі події цікаві три поля: auid — ідентифікатор користувача, який почав сесію, uid — під ким виконувалася дія, і exe — програма, що її виконала. Різниця між auid і uid і є відповіддю на питання «хто саме став root»: uid=0 з auid конкретної людини однозначно називає винуватця, ким би він себе всередині сесії не оголошував.

Диск

Налаштування розміру живуть у /etc/audit/auditd.conf:

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

Окремо подивіться на disk_full_action. У деяких конфігураціях типово стоїть зупинка системи при заповненні диска — поведінка, виправдана на машинах з вимогами аудиту й геть недоречна на вебсервері. Перевірте це значення до того, як диск закінчиться.

Незмінні правила

Рядок -e 2 в кінці файла правил забороняє змінювати правила до перезавантаження — зокрема й тому, хто отримав root. Це помітно підвищує цінність журналу: зловмисник не може вимкнути стеження, не перезавантаживши машину, а перезавантаження помітне саме собою.

Зворотний бік очевидний: власні правила ви теж не зміните без перезавантаження. Вмикайте це після того, як набір правил усталився і ви прожили з ним місяць.

Навіщо це на звичайному сервері

auditd нічого не запобігає. Його цінність проявляється рівно один раз — коли треба відновити послідовність подій, а дані або є, або їх немає. Заднім числом їх не зібрати, тому набір правил ставлять заздалегідь і далі не чіпають.

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