Linux Audit System: auditd для безопасности сервера

Установка и первый запуск:

# Debian / Ubuntu
apt install auditd audispd-plugins -y
systemctl enable --now auditd

# RHEL / CentOS / Rocky
dnf install audit audit-libs -y
systemctl enable --now auditd

# Проверяем статус
systemctl status auditd
auditctl -s  # Состояние подсистемы ядра

После запуска auditd начинает писать в /var/log/audit/audit.log. Пока без правил — только базовые события аутентификации.

Главный конфиг — /etc/audit/auditd.conf. Ключевые параметры, которые мы меняем на каждом сервере:

# Максимальный размер лог-файла (МБ)
max_log_file = 100

# Что делать при заполнении: rotate — ротация
max_log_file_action = rotate

# Сколько файлов хранить
num_logs = 10

# Что делать при нехватке места (space_left_action)
space_left_action = SYSLOG
admin_space_left_action = SUSPEND

# Запись на диск: sync — надёжнее, но медленнее
flush = INCREMENTAL_ASYNC

На серверах с требованиями compliance мы ставим max_log_file = 200 и num_logs = 30 — 6 ГБ истории. Для большинства клиентов хватает 10 файлов по 100 МБ.

Два типа правил: watch (наблюдение за файлами) и syscall (перехват системных вызовов):

# Watch-правило: наблюдение за файлом или каталогом
# -w путь -p права -k ключ
auditctl -w /etc/passwd -p wa -k user_changes
#   -p wa: w=запись, a=смена атрибутов
#   доступные флаги: r(чтение), w(запись), x(выполнение), a(атрибуты)

# Syscall-правило: перехват системных вызовов
# -a действие,фильтр -F поле=значение -S системный_вызов -k ключ
auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec
#   always,exit — всегда при выходе из syscall
#   arch=b64 — 64-битные вызовы (добавьте b32 для 32-битных)
#   euid=0 — только от root

Правила, заданные через auditctl, живут до перезагрузки. Постоянные правила — в файлах /etc/audit/rules.d/*.rules.

Вот правила, которые мы кладём в /etc/audit/rules.d/security.rules на каждый новый сервер:

# /etc/audit/rules.d/security.rules

# Неизменяемость самих правил (требует перезагрузки для изменения)
# -e 2

# Учётные записи и аутентификация
-w /etc/passwd -p wa -k user_accounts
-w /etc/shadow -p wa -k user_accounts
-w /etc/group -p wa -k user_accounts
-w /etc/gshadow -p wa -k user_accounts
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# SSH-ключи
-w /root/.ssh/ -p wa -k ssh_root
-w /home/ -p wa -k ssh_home

# Конфигурация системы
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/pam.d/ -p wa -k pam_config
-w /etc/cron.d/ -p wa -k cron_config
-w /etc/crontab -p wa -k cron_config

# Все команды от root
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
-a always,exit -F arch=b32 -S execve -F euid=0 -k root_commands

# Повышение привилегий
-a always,exit -F arch=b64 -S setuid -k priv_escalation
-a always,exit -F arch=b64 -S setresuid -k priv_escalation
-a always,exit -F arch=b64 -S setreuid -k priv_escalation

# Изменение прав доступа
-a always,exit -F arch=b64 -S chmod -k file_perm
-a always,exit -F arch=b64 -S chown -k file_perm
-a always,exit -F arch=b64 -S fchmod -k file_perm
-a always,exit -F arch=b64 -S fchown -k file_perm

# Применяем правила
augenrules --load

Основные сценарии использования ausearch:

# По ключу (нашим меткам из правил)
ausearch -k user_accounts -i
ausearch -k sudoers --start today -i

# По пользователю
ausearch -ua john -i
ausearch -ui 1001 --start yesterday --end today -i

# По времени
ausearch --start "02/14/2026 08:00:00" --end "02/14/2026 18:00:00" -i

# По типу события
ausearch -m USER_LOGIN -i   # Все входы в систему
ausearch -m SYSCALL -i -k root_commands | tail -50

# По результату (success/failure)
ausearch --success no -m USER_AUTH -i  # Только неудачные входы

# -i расшифровывает числовые UID/GID в имена

При расследовании инцидентов мы начинаем с ausearch -k sudoers -i — сразу видно, кто и когда менял sudoers, что обычно предшествует эскалации привилегий.

aureport строит агрегированные отчёты — удобно для ежедневного/еженедельного мониторинга:

# Общая сводка за период
aureport --start today

# Отчёт по аутентификации
aureport -au --start today

# Топ выполненных команд
aureport -x --summary

# Неудачные события
aureport --failed --start today

# Отчёт по изменениям файлов
aureport -f --start yesterday --end today

# Сводка по пользователям
aureport -u --summary

# Для cron (ежедневный отчёт)
aureport --start yesterday --end today > /tmp/audit_daily.txt
mail -s "Audit Report $(hostname) $(date +%F)" admin@itfresh.ru < /tmp/audit_daily.txt

Добавляем мониторинг под конкретные задачи клиентов:

# Мониторинг базы данных PostgreSQL
-w /var/lib/postgresql/ -p rwa -k pg_data
-w /etc/postgresql/ -p wa -k pg_config

# Мониторинг веб-корня (загрузки файлов)
-w /var/www/html/uploads/ -p wxa -k web_uploads

# Резервные копии
-w /backup/ -p rwa -k backup_access

# Конфигурация nginx
-w /etc/nginx/ -p wa -k nginx_config

# Монтирование устройств (риск вынести данные)
-a always,exit -F arch=b64 -S mount -k mount_ops
-a always,exit -F arch=b64 -S umount2 -k mount_ops

# Создание/удаление файлов в критичных каталогах
-a always,exit -F arch=b64 -S creat -F dir=/var/www -k web_file_create
-a always,exit -F arch=b64 -S unlinkat -F dir=/var/www -k web_file_delete

Флаг -p r (чтение) генерирует очень много событий на активных каталогах. Используйте его точечно — только там, где это действительно нужно для compliance.

Настройка отправки audit-событий на центральный сервер через audisp-remote:

# На всех клиентах — установка плагина
apt install audispd-plugins -y

# /etc/audisp/plugins.d/au-remote.conf
active = yes
direction = out
path = /sbin/audisp-remote
type = always
args = /etc/audisp/audisp-remote.conf
format = string

# /etc/audisp/audisp-remote.conf
remote_server = 10.0.0.50  # IP центрального сервера
port = 60
transport = tcp
enable_krb5 = no

# На центральном сервере — принимаем подключения
# /etc/audit/auditd.conf
tcp_listen_port = 60
tcp_max_per_addr = 10

systemctl restart auditd

Для крупных инсталляций мы используем rsyslog как промежуточный транспорт и отправляем события в Elasticsearch или Graylog — там уже полноценный SIEM с дашбордами и алертами.

Последовательность действий при расследовании инцидента с данными:

# Шаг 1: Смотрим все события за период инцидента
ausearch --start "02/10/2026 00:00:00" --end "02/10/2026 23:59:59" -i \
  | grep -E "DELETE|DROP|TRUNCATE" | head -50

# Шаг 2: Кто подключался к PostgreSQL-порту
ausearch -k pg_data --start "02/10/2026" -i

# Шаг 3: Запуск psql от разных пользователей
ausearch -k root_commands -i | grep psql

# Шаг 4: Полная история конкретного пользователя за день
ausearch -ua dbadmin --start "02/10/2026" --end "02/10/2026" -i \
  | ausearch -m SYSCALL -i | grep -A3 "comm=\"psql\""

# Шаг 5: Успешные и неуспешные подключения к БД
ausearch -m USER_AUTH --start yesterday -i | grep postgres

В том случае выяснилось: подключение было с внутреннего IP, пользователь — системный аккаунт деплоя, который кто-то использовал вручную в 3 ночи. Без auditd этого было бы не установить.