auditd: правила на изменения учётных записей и проверка через ausearch

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

Статья опирается на логику направления «Мониторинг кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Проверка выполнена в контейнере Debian 12 (auditd) с расширенными правами, необходимыми для доступа к ядерной подсистеме аудита, после неё контейнер и образ удалены.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Правила

apt install auditd

Файл правил, например /etc/audit/rules.d/identity.rules:

## Правила auditd: изменения учётных записей и повышение прав
-w /etc/passwd -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/sudoers -p wa -k identity_changes
-w /etc/sudoers.d/ -p wa -k identity_changes

Ключ -k identity_changes помечает события меткой, по которой их потом легко найти среди остальных. Флаг -p wa означает слежение за записью (write) и изменением атрибутов (attribute change) — на чтение файла события не создаются, иначе объём журнала станет неуправляемым. Примените правила:

augenrules --load
auditctl -l

Результат проверки

После применения правил изменили файл /etc/passwd добавлением строки через bash:

echo "newuser:x:1001:1001::/home/newuser:/bin/bash" >> /etc/passwd

Поиск события по ключу:

ausearch -k identity_changes

В выводе — событие с полями name="/etc/passwd", comm="bash", key="identity_changes", временем и идентификаторами пользователя и сессии, от имени которых выполнялась запись. Поле comm показывает, что изменение сделано именно через оболочку, а не, например, через конкретную утилиту управления пользователями — это особенно полезно при разборе, был ли это обычный административный процесс или что-то нетипичное.

Как использовать при разборе инцидента

• Поиск по времени: ausearch -k identity_changes -ts today покажет события за сегодня; -ts recent — за последние 10 минут.
• Человекочитаемый вывод: ausearch -k identity_changes -i расшифровывает числовые идентификаторы пользователей в имена.
• Сводка вместо сырых событий: aureport -k даёт таблицу по ключам с количеством срабатываний — удобно для регулярного обзора, не только для разбора конкретного инцидента.
• Отправка во внешнюю систему: журнал auditd стоит пересылать в общую систему сбора логов, как и любой другой источник: правила обнаружения в Wazuh могут опираться на события auditd.

Ограничения и ловушки

auditd — единственный процесс, который может слушать подсистему аудита ядра на хосте: запустить второй экземпляр на том же ядре (например, внутри контейнера рядом с демоном на хосте) не получится, система вернёт отказ в доступе. Это нормально для обычного сервера, где демон один, но важно учитывать при тестировании в контейнерах: для проверки на изолированном стенде контейнеру нужны расширенные привилегии и доступ к пространству имён процессов хоста, поэтому такую проверку стоит проводить только на выделенной тестовой машине, а не на проде.

Вторая ловушка — объём журнала: слежение «за всем подряд» (например, флаг -p rwxa вместо точечного -p wa или слежение за часто читаемыми каталогами) быстро создаёт поток событий, который никто не будет разбирать. Начинайте с узкого списка целей (учётные записи, sudoers, сами правила auditd) и расширяйте по мере необходимости.

Порядок внедрения

1. Установите auditd на серверах, где важно знать не только факт изменения, но и кто его сделал.
2. Начните с узкого списка целей: учётные записи, sudoers, сами правила auditd (слежение за изменением правил защищает от их тихого отключения).
3. Настройте пересылку журнала в централизованную систему — локальный журнал теряется при компрометации или переустановке хоста.
4. Проверьте правила тестовым изменением перед тем, как полагаться на них при реальном инциденте.
5. Регулярно просматривайте сводку (aureport), а не только реагируйте на инциденты постфактум.

Диагностика

Где это в модели зрелости

Материал относится к направлению «Мониторинг кибербезопасности» (материалы направления, карта зрелости). Уровень 2 требует, чтобы значимые для безопасности события фиксировались и были доступны для разбора: правила на изменение учётных записей закрывают конкретный, часто упускаемый источник — то, что AIDE покажет только при следующей плановой проверке, auditd показывает в момент события с указанием процесса-инициатора.

Как проверить

1. Правила загружены и видны в auditctl -l, сохранены в файле для применения после перезагрузки.
2. Тестовое изменение целевого файла находится через ausearch по заданному ключу с указанием процесса и пользователя.
3. Журнал пересылается в централизованную систему, а не хранится только локально.
4. Список целей слежения ограничен значимыми файлами, журнал не переполнен шумом от широких правил.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• Документация auditd: github.com/linux-audit/audit-userspace.