Аудит безопасности Linux: auditd, входы и контроль действий

Какие журналы нужны для аудита безопасности Linux

Linux Audit Framework получает от ядра структурированные события аудита по активным правилам. Служба auditd записывает их обычно в /var/log/audit/audit.log. Это источник для контроля доступа к выбранным файлам, системных вызовов и запусков процессов, но не универсальная запись всего, что делал администратор.

Определите события до настройки auditd

Правило аудита должно отвечать на конкретный вопрос: «кто изменил конфигурацию приложения», «кто запускал привилегированную программу», «кто менял учётные записи». У каждого правила укажите цель, владельца, критичные объекты, ожидаемый поток событий и срок хранения. Это помогает отделить полезные записи от шума и поддерживать конфигурационное соответствие.

• Для обычного сервера обычно начинают с критичных конфигураций конкретной роли: например, каталога конфигурации приложения, файлов учётных записей и настроек удалённого доступа.
• Для серверов с административными входами полезен контроль запусков процессов с эффективным UID 0, но только после оценки объёма.
• Для расследования входов сохраняют события auditd, сообщения SSH/PAM и данные о сессиях.
• Не добавляйте наблюдение за всем /etc, /usr, /var или всеми системными вызовами без сценария: это может резко увеличить поток записей, нагрузку и время поиска.

Проверьте службу auditd и активные правила

sudo auditctl -s && sudo auditctl -l

sudo find /etc/audit/rules.d -maxdepth 1 -type f -name '*.rules' -print 2>/dev/null; sudo test -r /etc/audit/audit.rules && sudo sed -n '1,220p' /etc/audit/audit.rules

Добавьте постоянное правило auditd для файла или каталога

Для современных правил контроля файлов предпочтителен syscall-формат с path для одного файла или dir для каталога. Поле perm=wa означает запись и изменение атрибутов; не добавляйте r, если чтение не является сценарием контроля, поскольку оно часто создаёт лишние события. Ключ -k задаёт понятную метку, по которой затем ищут записи.

# Тестовый файл: создайте его до загрузки правила.
-a always,exit -F arch=b64 -F path=/etc/audit-test.conf -F perm=wa -k audit-test-file

# Пример для существующего каталога конфигурации конкретного приложения.
# Замените путь и ключ на свои. Правило действует рекурсивно ниже каталога,
# но не переходит на вложенную смонтированную файловую систему.
# -a always,exit -F arch=b64 -F dir=/etc/myapp -F perm=wa -k myapp-config-change

arch=b64 соответствует 64-битным системным вызовам. Если хост запускает 32-битные приложения, добавляют эквивалентное правило с arch=b32 после проверки поддержки архитектуры. Старый watch-синтаксис -w путь -p wa -k ключ может встречаться в готовых политиках, но документация audit userspace рекомендует syscall-правила с path или dir как более производительный вариант.

sudo augenrules --load && sudo auditctl -l

Контроль запусков привилегированных команд

Для контроля запусков от имени привилегированной учётной записи можно аудитировать системный вызов execve, когда эффективный UID процесса равен 0. Условие auid>=1000 обычно исключает системные учётные записи, а auid!=unset — процессы без исходной пользовательской сессии. Границу UID выбирают по локальной политике, а не копируют без проверки.

# Запуски программ с EUID 0 из пользовательских сессий.
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k privileged-exec

# Добавьте аналог с arch=b32, только если на хосте допустимы 32-битные приложения.
# -a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k privileged-exec

Как читать и искать события через ausearch и aureport

Одно действие обычно состоит из нескольких записей с общим идентификатором события. Поля имеют разный смысл: AUID — login UID, назначенный при входе и наследуемый процессами сессии; для процессов вне пользовательского входа он может быть unset. UID — реальный UID процесса; EUID — эффективный UID, участвующий во многих проверках доступа, но не заменяющий FSUID, capabilities и другие механизмы полномочий; ses — идентификатор сессии аудита; exe — путь к исполняемому файлу; key — метка сработавшего правила аудита.

Например, пользователь ivan входит по SSH и запускает sudo vi /etc/audit-test.conf. У процесса редактора EUID обычно будет 0, поскольку права получены через sudo, но AUID останется UID ivan. Именно AUID связывает действие с исходной пользовательской сессией; поиск только по UID или EUID может дать другой ответ.

sudo ausearch -k audit-test-file -ts today -i

Для анализа привилегированных запусков используйте ключ: sudo ausearch -k privileged-exec -ts today -i. В найденном событии сопоставьте AUID, EUID, ses, exe, путь и результат. aureport удобен для сводки, но исходные записи ausearch важнее, когда нужно понять контекст одной операции.

Где проверить входы SSH и локальные сессии Linux

Для входов SSH используйте несколько источников. В Debian и Ubuntu сообщения аутентификации часто находятся в /var/log/auth.log; в RHEL-совместимых системах — в /var/log/secure. Это зависит от rsyslog, journald и конфигурации PAM/sshd: файл может отсутствовать, а сообщения могут храниться только в journal или быть перенаправлены в другое место.

sudo journalctl -u sshd.service -u ssh.service --since today

sudo grep -E 'sshd|sudo|session' /var/log/auth.log /var/log/secure 2>/dev/null | tail -n 200

Настройте хранение и ротацию журнала auditd

Проверьте /etc/audit/auditd.conf до добавления шумных правил. Существенные параметры обычно включают log_file, log_file_mode, max_log_file, num_logs, max_log_file_action, пороги свободного места space_left и admin_space_left, а также действия space_left_action, admin_space_left_action, disk_full_action и disk_error_action. Допустимые значения действий зависят от версии auditd и политики дистрибутива.

• max_log_file задаёт максимальный размер отдельного файла журнала в мегабайтах, а num_logs — количество файлов, сохраняемых при ротации.
• max_log_file_action = ROTATE обычно используется для ротации файлов; вариант keep_logs сохраняет файлы и требует особенно тщательного контроля места.
• Пороги space_left и admin_space_left задают раннее и критическое предупреждение о свободном месте. Реакцией могут быть журналирование, уведомление, выполнение программы, приостановка аудита, переход в однопользовательский режим или остановка системы — выбирайте только предусмотренные вашей версией действия.
• Действие при полном диске — компромисс между сохранением аудита и доступностью сервиса. Решение должно быть утверждено владельцем сервера: остановка или однопользовательский режим может вызвать простой, а игнорирование события — потерю наблюдаемости.
• Ограничьте доступ к каталогу и файлам аудита: обычно читать их должны только root и уполномоченная группа. Проверьте владельца и режимы прав после ротации.

sudo grep -E '^(log_file|log_file_mode|max_log_file|num_logs|max_log_file_action|space_left|space_left_action|admin_space_left|admin_space_left_action|disk_full_action|disk_error_action)' /etc/audit/auditd.conf; sudo df -h /var/log /var/log/audit 2>/dev/null

Когда включать immutable rules

Режим -e 2 — это неизменяемое правило аудита: после его применения активные правила нельзя изменить до перезагрузки. Его размещают последней строкой постоянного набора правил, например в завершающем файле с лексикографически поздним именем. Это повышает устойчивость конфигурации, но не заменяет защиту привилегированных учётных записей и внешнее хранение журналов.

# Добавляйте только после проверки всех остальных правил.
-e 2

Диагностика auditd service failed, immutable rules и заполнения диска

Границы auditd и Lynis

Lynis можно запускать локально командой sudo lynis audit system, если инструмент установлен и его использование одобрено для хоста. Он проверяет конфигурацию и формирует рекомендации, но не подтверждает факт компрометации и не заменяет поиск по журналам. Результаты Lynis рассматривайте как гипотезы для проверки в рамках hardening Linux-сервера и управления уязвимостями сервера.