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 появляются редко и каждое можно объяснить. Как это выглядит на одной странице — на демо ниже.