auditd и journald на Linux: современный аудит событий безопасности

Журналы безопасности нужны не для заполнения диска, а для ответа на конкретные вопросы: кто вошёл на сервер, какие привилегии получил, что изменил и когда началась проблема. В Linux обычно используются два дополняющих механизма: systemd-journald собирает сообщения ядра и сервисов, а auditd фиксирует события аудита на уровне системных вызовов и правил.

Ни один из них не заменяет мониторинг приложения, firewall и управление доступом. Практичная архитектура включает локальный сбор, контролируемый retention, централизованную копию и понятные сценарии реакции.

Роли journald и auditd

• journald — сообщения systemd units, ядра, stdout/stderr приложений, приоритеты и структурированные поля;
• auditd — входы, изменения учётных записей, доступ к контролируемым файлам, выполнение привилегированных действий;
• централизованное хранилище — защита истории от потери вместе с сервером и поиск по нескольким узлам;
• SIEM или alerting — корреляция и уведомление ответственного.

Базовая работа с journalctl

journalctl --since today
journalctl -p warning..alert --since today
journalctl -u ssh --since '24 hours ago'
journalctl -u nginx --since '1 hour ago'
journalctl -k --since today
journalctl --disk-usage

Фильтрация по unit надёжнее поиска случайной строки. Для расследования используйте точный временной диапазон и UTC, чтобы сопоставлять события разных систем.

journalctl --since '2026-08-29 10:00:00' --until '2026-08-29 10:30:00' -o short-iso
journalctl _PID=1234
journalctl _UID=1001

Постоянное хранение journald

На некоторых системах журнал может храниться только в памяти. Проверьте каталог /var/log/journal и настройте drop-in /etc/systemd/journald.conf.d/60-retention.conf:

[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
MaxRetentionSec=30day
Compress=yes
Seal=yes

sudo systemctl restart systemd-journald
journalctl --verify
journalctl --disk-usage

Значения зависят от диска и объёма событий. Лимит должен предотвращать заполнение файловой системы, но сохранять достаточный период для расследования.

Установка и проверка auditd

sudo apt update
sudo apt install auditd audispd-plugins
sudo systemctl enable --now auditd
sudo auditctl -s
sudo aureport --summary

Правила runtime, добавленные через auditctl, исчезают после перезагрузки. Постоянные правила размещаются в /etc/audit/rules.d/*.rules и загружаются штатным механизмом пакета.

Что стоит контролировать

Учётные записи и sudo

-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/sudoers.d/ -p wa -k privilege

SSH-ключи и конфигурация

-w /etc/ssh/sshd_config -p wa -k ssh_config
-w /etc/ssh/sshd_config.d/ -p wa -k ssh_config

systemd units и cron

-w /etc/systemd/system/ -p wa -k systemd_units
-w /etc/cron.d/ -p wa -k scheduled_tasks
-w /etc/crontab -p wa -k scheduled_tasks

Не добавляйте рекурсивное наблюдение за всей файловой системой. Это создаёт огромный поток, нагрузку и ложные сигналы. Выберите критичные объекты по модели угроз.

Поиск и отчёты auditd

sudo ausearch -k identity --start today
sudo ausearch -k privilege --start today
sudo ausearch -m USER_LOGIN --start today
sudo aureport --auth
sudo aureport --failed
sudo aureport --executable

Событие auditd может состоять из нескольких записей с одним идентификатором. Для расследования сохраняйте весь набор, а не одну строку, найденную grep.

Контроль объёма и отказоустойчивость

В /etc/audit/auditd.conf определяются размер файлов, количество ротаций и поведение при нехватке места. Настройка должна соответствовать критичности системы. Полная остановка production из-за заполнения audit-раздела может быть оправдана в регулируемой среде, но опасна для обычного web-проекта. Решение фиксируется владельцем риска.

Для журналов выделите отдельный раздел или жёсткие лимиты. Мониторинг свободного места должен предупреждать заранее.

Централизованный сбор

Локальные события отправляйте в отдельное хранилище через rsyslog, systemd-journal-remote или агент выбранной платформы. Канал шифруйте, сервер приёма аутентифицируйте, а буфер на источнике ограничивайте.

На стороне хранилища настройте неизменяемость или ограничение удаления, отдельные роли доступа и синхронизацию времени. Без корректного времени расследование превращается в угадывание последовательности событий.

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

• вход root или неожиданного администратора;
• серия неуспешных входов с последующим успешным;
• изменение sudoers или authorized_keys;
• создание пользователя и добавление в sudo-группу;
• новый systemd unit или cron-задача;
• остановка auditd или агента доставки;
• очистка журналов;
• появление нового слушающего порта.

У каждого алерта должен быть приоритет, владелец, допустимое время реакции и короткая инструкция. Ежемесячно удаляйте бесполезные правила и уточняйте шумные.

Сценарий расследования подозрительного входа

1. зафиксировать время, IP и пользователя;
2. проверить соседние события SSH и sudo;
3. сопоставить вход с заявкой или рабочим расписанием;
4. проверить процессы, соединения, cron и systemd;
5. сохранить журналы вне узла;
6. при подтверждении компрометации изолировать сервер и отозвать секреты;
7. восстановить узел из доверенного источника.

Синхронизация времени и единый формат

Если часы серверов расходятся, цепочка событий будет неверной. Настройте NTP, используйте UTC для централизованного хранения и сохраняйте исходный timezone как поле события. Проверяйте состояние синхронизации и создавайте алерт при большом смещении.

timedatectl status
timedatectl timesync-status
journalctl -o short-iso-precise --since today

Журналирование приложений

Системный аудит не объяснит, какой пользователь приложения изменил заказ или выгрузил данные. Приложение должно писать структурированные события с request ID, actor ID, типом операции и результатом. Пароли, токены, cookies, номера карт и полные персональные данные в журнал попадать не должны.

Разделяйте диагностические и аудиторские события. Уровень DEBUG можно временно включить для расследования, но нельзя постоянно хранить чувствительное содержимое запросов. Политику маскирования проверяйте автоматическими тестами.

Защита журналов

Доступ на чтение журналов тоже привилегия: в них встречаются имена пользователей, IP, пути и фрагменты запросов. Разделите роли операторов, разработчиков и аудиторов. Для центрального хранилища включите шифрование канала и диска, неизменяемый retention там, где это требуется, и отдельный журнал действий администраторов самого хранилища.

Тестирование правил

Каждое правило должно проверяться контролируемым событием. Создайте тестового пользователя, выполните неуспешный вход, измените тестовый файл и убедитесь, что событие дошло до центральной системы и сформировало ожидаемый алерт. Затем проверьте runbook: может ли дежурный понять сигнал и выполнить действия без автора правила.

Следите за потерянными событиями, очередью агента и задержкой доставки. Отсутствие сообщений может означать не спокойствие, а поломку pipeline — поэтому нужен heartbeat от источников.

Метрики качества мониторинга

• доля критичных узлов, отправляющих события;
• задержка доставки от источника до поиска;
• число потерянных или отброшенных сообщений;
• доля алертов с назначенным владельцем;
• среднее время подтверждения и реакции;
• доля правил, проверенных за последний квартал.

FAQ

Достаточно ли journald без auditd?

Для диагностики сервиса часто да, но для контролируемого аудита изменений и привилегированных действий auditd даёт дополнительные данные.

Можно ли хранить журналы только локально?

Для некритичного стенда — возможно. Для production нужна удалённая копия, иначе журналы потеряются или будут изменены вместе с сервером.

Сколько хранить события?

Срок определяется угрозами, договорными и нормативными требованиями, объёмом и стоимостью хранения.