auditd: больше, чем просто логи — узнайте, кто что делал в Linux

Повысьте уровень прозрачности вашей системы Linux — от базовых логов до полноценного аудита

Кто это сделал?

Каждый администратор Linux рано или поздно сталкивается с такими вопросами:

• Кто удалил этот файл?
• Кто внес изменения в эту конфигурацию?
• Кто выполнил эту команду?

Это может привести к сбоям, когда внешне всё выглядит нормально, но на самом деле что-то важное уже не работает.

Мы не можем достоверно определить, кто это сделал, используя только логи или мониторинг, поскольку они обеспечивают лишь частичную видимость. Чтобы полностью понять, что произошло, нам нужен аудит.

В этой статье мы рассмотрим, как работает auditd, как создавать правила аудита и управлять ими, анализировать логи аудита, формировать отчеты и применять лучшие практики для мониторинга и защиты критически важной активности системы.

Введение в аудит

Что такое auditd?

auditd (Audit Daemon) — это сервис пользовательского пространства, который собирает и сохраняет события аудита, генерируемые Linux Audit Framework.

Он создает журнал аудита, показывающий, кто выполнил действие, когда оно произошло и завершилось ли оно успешно, помогая администраторам отслеживать и анализировать активность системы.

Linux Audit Framework

Для эффективного использования auditd необходимо понимать его экосистему. Это не просто отдельный инструмент, а набор компонентов, работающих вместе в рамках Linux Audit Framework.

Linux Audit Framework состоит из нескольких компонентов:

+-------------------+
| Linux Applications|
+---------+---------+
          |
          v
+-------------------+
| Linux Kernel      |
| Audit Subsystem   |
+---------+---------+
          |
          v
+-------------------+
| auditd Daemon     |
+---------+---------+
          |
          v
+-------------------+
| Audit Logs        |
| /var/log/audit/   |
+-------------------+

• Приложение → Выполняет действия, такие как доступ к файлам, выполнение команд, сетевые операции или аутентификация пользователя, которые выполняют системные вызовы (например, open, execve).
• Подсистема аудита ядра → Обнаруживает эти системные вызовы и генерирует события аудита, когда они соответствуют настроенным правилам аудита, применяемым к системным вызовам и событиям ядра.
• auditd → Получает события аудита от ядра и записывает их на диск в структурированном формате.
• Логи аудита → Постоянные записи, создаваемые auditd, обычно хранящиеся в /var/log/audit/audit.log, используемые для поиска, формирования отчетов и криминалистического анализа.

Примечание:
В отличие от стандартных средств логирования, таких как rsyslog или systemd-journald, которые зависят от того, сообщают ли приложения о собственной активности, аудит работает на уровне ядра. Это означает, что его нельзя обойти обычными инструментами пользовательского пространства, и даже если процесс скомпрометирован, его системные вызовы всё равно будут записаны, если только не скомпрометировано само ядро.

Правила аудита

Правила аудита — это директивы конфигурации, которые указывают Linux Audit System (auditd), какие действия необходимо отслеживать и записывать. Эти правила определяют, какие события будут фиксироваться, например доступ к файлам, изменения конфигурации, действия пользователей и системные вызовы.

Правила хранятся в виде файлов .rules в каталоге /etc/audit/rules.d/ и при запуске системы (или при выполнении augenrules --load) компилируются в файл /etc/audit/audit.rules.

Порядок загрузки файлов правил:
Размещайте правила аудита в пронумерованных файлах .rules, чтобы управлять порядком их загрузки. Файлы обрабатываются последовательно в алфавитно-цифровом порядке утилитой augenrules.

/etc/audit/rules.d/
├── 10-base-config.rules     # Kernel/auditd settings# Kernel/auditd settings
├── 20-netsys.rules          # Network-related rules
├── 30-suid.rules            # SUID/SGID execution
├── 40-modules.rules         # Kernel module loading
├── 50-identity.rules        # Identity/auth files
├── 70-system-local.rules    # Local custom rules
└── 99-finalize.rules        # Lock the ruleset

• Использование системы нумерации помогает упорядочить политики аудита, упрощает сопровождение и гарантирует загрузку правил в нужном порядке.

Важно:
правила можно добавить временно с помощью auditctl или сделать постоянными с помощью файлов в каталоге /etc/audit/rules.d/.

Записи аудита

Когда происходит отслеживаемое событие, Linux Audit System генерирует одну или несколько записей аудита, объединенных в одно событие общими временной меткой и серийным номером. Один системный вызов open() может создать записи типов SYSCALL, PATH, CWD и PROCTITLE.

Распространенные типы записей:

• SYSCALL → сведения о системном вызове (имя, аргументы, PID, UID)
• PATH → путь к файлу, участвующему в системном вызове
• CWD → текущий рабочий каталог на момент события
• EXECVE → аргументы, переданные запускаемому процессу
• USER_AUTH → событие аутентификации PAM
• USER_LOGIN → попытка входа в систему (успешная или неуспешная)
• USER_CMD → команда, выполненная через sudo
• CRED_ACQ → получение учетных данных (например, sudo)
• SOCKADDR → информация об адресе сокета (для сетевых событий)
• AVC → отказ SELinux Access Vector Cache
• CONFIG_CHANGE → конфигурация аудита была изменена

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

Распространенные поля записей аудита:

• auid — Audit UID, исходный UID пользователя, вошедшего в систему; сохраняется после su/sudo
• uid/gid — эффективный UID/GID на момент события
• euid/egid — эффективный UID/GID
• comm — имя команды (обрезается до 15 символов)
• exe — полный путь к исполняемому файлу
• key — метка, назначенная правилу для удобной фильтрации
• success — успешно ли выполнен системный вызов (yes/no)
• res — результат событий пользовательского пространства (success/failed)

Примечание:
Поле auid особенно важно, поскольку оно идентифицирует пользователя, который первоначально вошел в систему, и остается неизменным даже после повышения привилегий (например, с помощью sudo или su). Это делает его критически важным для правильной привязки действий к конкретному пользователю.

Файлы конфигурации

/etc/audit/auditd.conf — основной файл конфигурации демона auditd. Он управляет тем, как логи аудита сохраняются, ротируются и обслуживаются.

# /etc/audit/auditd.conf

# Where logs are written
log_file = /var/log/audit/audit.log
log_format = ENRICHED        # Resolves UIDs/GIDs to names in the log
log_group = root

# Log rotation
max_log_file = 50            # Max size of each log file in MB
num_logs = 10                # Number of rotated files to keep
max_log_file_action = ROTATE # ROTATE | SYSLOG | SUSPEND | KEEP_LOGS | EXEC

# What to do when disk space is critically low
space_left = 75              # MB remaining — trigger space_left_action
space_left_action = SYSLOG
admin_space_left = 50        # MB remaining — trigger admin_space_left_action
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

# Performance
backlog_wait_time = 60000    # Microseconds to wait when backlog is full
priority_boost = 4           # Nice level boost for auditd process

Начало работы с auditd

Установка

Большинство современных корпоративных дистрибутивов Linux (RHEL, Rocky Linux, Ubuntu Server) поставляются с уже установленным auditd. Если он отсутствует, мы можем установить его с помощью менеджера пакетов:

# Debian/Ubuntu:
sudo apt update && sudo apt install auditd audispd-plugins -y
sudo systemctl enable --now auditd

# RHEL/CentOS/Fedora:
sudo dnf install audit audit-libs -y
sudo systemctl enable --now auditd

# Verify it's running:
sudo systemctl status auditd
sudo auditctl -s  # Show kernel audit status

Создаем первое правило аудита

Правила аудита определяют, какие действия должен отслеживать auditd.

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

Простой и практичный пример — отслеживание изменений файла конфигурации SSH-сервера. Поскольку этот файл управляет тем, как пользователи подключаются к системе, неожиданные изменения могут иметь серьезные последствия для безопасности.

1. Добавьте правило наблюдения.

sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config

• -w → отслеживать определенный файл или каталог
• -p wa → отслеживание изменений записи (w) и атрибутов (a)
• -k ssh_config → назначить ключ для поиска с именем ssh_config

Эта команда указывает auditd записывать любые изменения, внесенные в файл, включая изменения метаданных файла /etc/ssh/sshd_config, и помечать событие ключом ssh_config.

Примечание:
Всегда используйте параметр -k (key). Назначение уникального текстового ключа правилам значительно упрощает фильтрацию гигабайтов логов с помощью ausearch.

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

sudo auditctl -l

Должно отображаться:

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

3. Сгенерируйте тестовое событие, изменив файл конфигурации SSH.

echo "# auditd test" | sudo tee -a /etc/ssh/sshd_config

• Это создаст событие изменения файла, которое должно быть зафиксировано auditd.

4. Проверьте событие:

sudo ausearch -f /etc/ssh/sshd_config

• Команда вернет одну или несколько записей аудита, показывающих доступ к /etc/ssh/sshd_config или его изменение, включая имя процесса, временную метку и ключ правила аудита.

Примечание:
ausearch — это утилита командной строки, входящая в состав auditd, предназначенная для поиска и извлечения событий из логов аудита Linux.

Понимание правил аудита

Правила аудита определяют, что именно должно отслеживать ядро. Обычно они делятся на три категории:

• Правила управления (Control Rules) → настраивают поведение системы аудита (например, размеры буферов или поведение при сбоях).

# Delete all existing rules (always first)
-D

# Set the backlog buffer — increase for high-traffic systems
-b 8192

# Failure mode: 0=silent, 1=printk, 2=panic
-f 1

# Rate limit audit messages (per second, 0=unlimited)
-r 0

• Правила наблюдения за файловой системой (File System Watches) → отслеживают доступ к определенным файлам или каталогам.

# Syntax: -w <path> -p <permissions> -k <key>
# Permissions: r=read, w=write, x=execute, a=attribute change

# Watch passwd file for any writes or attribute changes
-w /etc/passwd -p wa -k identity

# Watch shadow file
-w /etc/shadow -p wa -k identity

# Watch sudoers
-w /etc/sudoers -p wa -k scope
-w /etc/sudoers.d/ -p wa -k scope

# Watch SSH configs
-w /etc/ssh/sshd_config -p wa -k sshd_config

# Watch audit configuration itself
-w /etc/audit/ -p wa -k audit_config
-w /etc/libaudit.conf -p wa -k audit_config
-w /etc/audisp/ -p wa -k audit_config

• Правила системных вызовов (System Call Rules) → перехватывают определенные операции, выполняемые любым процессом через системные вызовы ядра Linux.

# Syntax:
# -a <list>,<action> -S <syscall> -F <field>=<value> -k <key>
#
# Lists: task, exit, user, exclude, filesystem
# Actions: always, never

# Log all chmod/chown/chattr syscalls by non-root users
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod

# Log all execve calls (process execution) — critical for forensics
-a always,exit -F arch=b64 -S execve -k exec
-a always,exit -F arch=b32 -S execve -k exec

# Log failed file access attempts (unauthorized reads/writes)
-a always,exit -F arch=b64 -S open,openat,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -k access
-a always,exit -F arch=b64 -S open,openat,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -k access

# Log privilege escalation attempts
-a always,exit -F arch=b64 -S setuid,setgid,setreuid,setregid -F auid>=1000 -k priv_esc

# Log kernel module loading/unloading
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modules

Примечание:
Всегда определяйте правила как для b64 (64-битная архитектура), так и для b32 (32-битная совместимость). 32-битный процесс, работающий на 64-битном ядре, использует другие номера системных вызовов, поэтому он не будет соответствовать правилам b64.

Снижение уровня шума: правила исключения

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

# Exclude high-frequency, low-value events from specific processes
-a never,exit -F arch=b64 -F auid=unset -k ignore_unset_auid

# Exclude audit events from the audit daemon itself (prevents recursion)
-a never,exit -F exe=/sbin/auditd

# Exclude noisy cron jobs (audit their config changes, not every execution)
-a never,exit -F arch=b64 -F uid=daemon -S execve

# Exclude specific paths from file watch recursion
# (watch /etc/ but not the high-churn temp files inside it)
-a never,exit -F path=/etc/mtab

# Exclude systemd journal chatter
-a never,exit -F arch=b64 -F exe=/lib/systemd/systemd-journald

Важно:
Правила never должны располагаться перед правилами always для одного и того же события, поскольку ядро обрабатывает правила по порядку и останавливается на первом совпадении.

Поиск по логам с помощью ausearch

По мере работы auditd может генерировать или даже миллионы записей логов, ручной просмотр /var/log/audit/audit.log непрактичен. Вместо этого используется ausearch, чтобы эффективно фильтровать и извлекать только нужные события.

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

Поиск по ключу

Один из наиболее распространенных способов поиска в логах аудита — использование ключа, назначенного правилу аудита.

Например, если мы создали следующее правило:

sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config

• Это добавляет активное правило аудита, которое отслеживает /etc/ssh/sshd_config на предмет изменений записи и атрибутов, помечая соответствующие события ключом ssh_config для упрощения поиска.
• Здесь мы использовали auditctl, чтобы добавить правило только в работающую систему (временно, правило будет потеряно после перезагрузки). Для постоянного использования правило должно быть помещено в /etc/audit/rules.d/.

Мы можем получить соответствующие события с помощью:

sudo ausearch -k ssh_config

• Эта команда выполняет поиск в логах аудита всех событий, помеченных ключом ssh_config, и показывает связанную с ними активность.

Поиск по файлу

Найти события, связанные с конкретным файлом:

sudo ausearch -f /etc/passwd

Это полезно при расследовании того, кто обращался к критически важному файлу или изменял его.

Поиск по пользователю

Отображение событий, связанных с конкретной учетной записью пользователя:

sudo ausearch -ua alice

# Or use a UID
sudo ausearch -ui 1000

Это может помочь отслеживать активность пользователя в ходе конкретного расследования.

Поиск по времени

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

# View events that occurred recently:
sudo ausearch -ts today

# Search events from the last hour:
sudo ausearch -ts recent

# Specify a custom time range:
sudo ausearch -ts "2026-06-10 09:00:00" -te "2026-06-10 10:00:00"

• -ts → время начала
• -te → время окончания

Поиск событий, завершившихся ошибкой

Найдите операции, завершившиеся ошибкой:

# failed events
sudo ausearch -sv no

# successful events
sudo ausearch -sv yes

Это полезно для выявления проблем с правами доступа, неудачных попыток входа в систему или подозрительных попыток доступа.

Поиск по идентификатору процесса

Находит все события аудита, сгенерированные определенным идентификатором процесса (PID).

sudo ausearch -p 1234

Это полезно для отслеживания всего, что сделал один работающий процесс за время своего существования.

Поиск по исполняемому файлу

Фильтрует логи аудита, чтобы показать события, сгенерированные определенным исполняемым файлом.

ausearch -x /usr/bin/sudo

Это помогает определить все действия, выполненные определенной программой.

Поиск по системному вызову

Фильтрует логи аудита, чтобы показать события, связанные с определенным системным вызовом.

ausearch -sc execve

Это полезно для отслеживания низкоуровневых действий ядра, таких как выполнение процессов или доступ к файлам.

Интерпретация вывода (преобразование числовых идентификаторов, удобное форматирование)

Логи аудита используют числовые идентификаторы (например, идентификаторы пользователей, групп и системных вызовов), которые трудно читать, но их можно преобразовать в читаемые имена, чтобы упростить анализ.

ausearch -k identity -i

• -k identity → фильтровать логи аудита по ключу identity
• -i → преобразовать числовые значения в читаемые имена (UID → имя пользователя, номера системных вызовов → имена системных вызовов и т.д.)

# Example Output

# Without -i:
uid=1000 syscall=59 success=no

# With -i:
uid=alice syscall=execve success=no

Вывод в определенных форматах

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

ausearch -k exec -i --format text  # Human-readable
ausearch -k exec --format csv      # CSV for analysis

Это упрощает чтение и интеграцию с другими инструментами.

Комбинирование фильтров

Мы можем комбинировать несколько фильтров в ausearch, чтобы сузить результаты и сделать расследование более точным. Это позволяет одновременно выполнять поиск по ключу, времени, пользователю, процессу или другим атрибутам.

# Search all events related to SSH configuration changes in readable format.
ausearch -k ssh_config -i

# Find all sudo executions recorded today, with human-readable output.
ausearch -k exec -x /usr/bin/sudo --start today -i

# Trace everything done by a specific process ID.
ausearch -p 1234 -i

# Show identity-related changes (users/groups) that occurred today.
ausearch -k identity --start today --end now -i

# Find permission changes made by a specific user.
ausearch -k perm_mod -ui 1000 -i

Формирование отчетов с помощью aureport

Хотя ausearch идеально подходит для расследования отдельных событий, aureport создает сводные отчеты на основе логов аудита. Он обрабатывает данные аудита и отображает статистику, что упрощает обнаружение тенденций, подозрительной активности и проблем безопасности.

Сводная информация по всем типам событий

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

sudo aureport --summary

Summary Report
======================
Range of time in logs: 06/10/2026 08:00:00 - 06/10/2026 12:00:00time in logs: 06/10/2026 08:00:00 - 06/10/2026 12:00:00

Login Summary
----------------------
root     3
alice    12
bob      5

Authentication Summary
----------------------
success  50
failed   5

Event Summary
----------------------
type=USER_LOGIN    20
type=USER_AUTH     35
type=SYSTEM_BOOT    1

Отчет о входе/аутентификации

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

sudo aureport -au              # authentication events (detailed)
sudo aureport -au --summary    # authentication statistics
sudo aureport -au --failed     # failed authentication attempts

Отчеты об активности пользователей

Сформируйте отчет о событиях, связанных с пользователями:

sudo aureport --user

Это позволяет получить сводную информацию об активности по идентификатору пользователя и может помочь выявить необычное поведение.

Отчет об исполняемых файлах

Формирует сводный отчет по выполненным программам, отслеживая системный вызов execve. Он показывает, какие исполняемые файлы запускались в системе и как часто они использовались.

sudo aureport -x --summary

Executable Summary
======================
/usr/bin/sudo        40
/usr/bin/passwd      10
/usr/bin/vim         18
/bin/systemctl        7

Отчеты о доступе к файлам

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

File Report
=================================
# date time file event
1 06/10/26 10:15:42 /etc/passwd WRITE
2 06/10/26 10:20:18 /etc/shadow ATTRIB

Это полезно для отслеживания того, какие файлы читаются, записываются, создаются или удаляются, а также какие пользователи или процессы выполняют эти действия.

Отчет об изменениях учетных записей пользователей

Сформируйте отчет об изменениях учетных записей пользователей, чтобы отслеживать изменения, внесенные в системные учетные записи.

sudo aureport -m

Это помогает определить, когда пользователи были созданы, удалены или изменены, а также когда были изменены группы или настройки аутентификации.

Отчет о системных вызовах

Сформируйте отчет о системных вызовах для анализа взаимодействия программ с ядром Linux. Системные вызовы представляют собой низкоуровневые операции, такие как открытие файлов, выполнение программ или доступ к системным ресурсам.

sudo aureport -s

Отчет за определенный диапазон времени

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

# Shows all audit activity from the start of the current day up to the present time.
sudo aureport --start today    

# Shows only events that occurred between 9 AM and 12 PM.
sudo aureport --start "09:00:00" --end "12:00:00"

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

Важно:
Используйте параметр -i, чтобы преобразовать числовые значения, такие как идентификаторы пользователей (UID), идентификаторы групп (GID) и номера системных вызовов, в читаемые имена. Это делает вывод отчета аудита более удобным для чтения и интерпретации. Например: sudo aureport -au -i.

Мониторинг потерянных событий

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

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

1. Проверьте состояние подсистемы аудита:

sudo auditctl -s

# Output:
enabled 1
failure 1
pid 1234
rate_limit 0
backlog_limit 8192
lost 0
backlog 0

Обратите пристальное внимание на поле lost:

• lost = 0 → означает, что ни одно событие аудита не было потеряно.
• lost > 0 → указывает, что некоторые записи аудита не были сохранены и были потеряны, что может свидетельствовать о перегрузке системы, ограничениях буфера или проблемах с логированием, которые необходимо расследовать.

Увеличение размера буфера Backlog

Если возникают потерянные события, увеличьте размер буфера аудита.

# Temporary change:
sudo auditctl -b 16384

# Persistent configuration (rules file): under /etc/audit/rules.d/
-b 16384
sudo augenrules --load  # Reload the rules

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

Сокращение количества правил

Если увеличение размера backlog не помогает, пересмотрите правила аудита:

sudo auditctl -l

Обратите внимание на:

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

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

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

Практические правила для production

Вместо того чтобы создавать правила с нуля, отраслевым стандартом является размещение модульных файлов .rules в каталоге /etc/audit/rules.d/ и их загрузка с помощью augenrules --load.

Ниже приведены основные production-ready конфигурации, которые должен реализовать каждый инженер по безопасности:

## /etc/audit/rules.d/99-production.rules
## Production hardening ruleset

## ─── SECTION 1: Control ───────────────────────────────────────────────────────
-D
-b 8192
-f 1
--backlog_wait_time 60000

## ─── SECTION 2: Identity & Auth Files ───────────────────────────────────────
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
-w /etc/nsswitch.conf -p wa -k identity

## ─── SECTION 3: Sudoers & Privilege Escalation ───────────────────────────────
-w /etc/sudoers -p wa -k scope
-w /etc/sudoers.d/ -p wa -k scope
-a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/usr/bin/su -k priv_esc
-a always,exit -F arch=b32 -S setuid -F a0=0 -F exe=/usr/bin/su -k priv_esc
-a always,exit -F arch=b64 -S setresuid -F a0=0 -F exe=/usr/bin/newgrp -k priv_esc

## ─── SECTION 4: File Permission Changes ──────────────────────────────────────
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -k perm_mod
-a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -k perm_mod

## ─── SECTION 5: Unsuccessful File Access ────────────────────────────────────
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k access

## ─── SECTION 6: Kernel Module Operations ────────────────────────────────────
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module,finit_module -k modules
-a always,exit -F arch=b64 -S delete_module -k modules

## ─── SECTION 7: Network Configuration Changes ───────────────────────────────
-a always,exit -F arch=b64 -S sethostname,setdomainname -k network_modifications
-w /etc/hosts -p wa -k network_modifications
-w /etc/network/ -p wa -k network_modifications
-w /etc/sysconfig/network -p wa -k network_modifications
-w /etc/netplan/ -p wa -k network_modifications

## ─── SECTION 8: System Calls — Time ──────────────────────────────────────────
-a always,exit -F arch=b64 -S adjtimex,settimeofday -k time_change
-a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -k time_change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -k time_change
-w /etc/localtime -p wa -k time_change

## ─── SECTION 9: Process Execution ───────────────────────────────────────────
-a always,exit -F arch=b64 -S execve -k exec
-a always,exit -F arch=b32 -S execve -k exec

## ─── SECTION 10: Mount / Unmount Operations ──────────────────────────────────
-a always,exit -F arch=b64 -S mount,umount2 -F auid>=1000 -F auid!=-1 -k mounts
-a always,exit -F arch=b32 -S mount,umount2 -F auid>=1000 -F auid!=-1 -k mounts

## ─── SECTION 11: File Deletion ───────────────────────────────────────────────
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=-1 -k delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=-1 -k delete

## ─── SECTION 12: SSH ─────────────────────────────────────────────────────────
-w /etc/ssh/sshd_config -p wa -k sshd
-w /etc/ssh/sshd_config.d/ -p wa -k sshd

## ─── SECTION 13: Cron & Scheduled Tasks ─────────────────────────────────────
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## ─── SECTION 14: SUID / SGID Execution ──────────────────────────────────────
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid
-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid
-a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid

## ─── SECTION 15: Audit Configuration ────────────────────────────────────────
-w /etc/audit/ -p wa -k audit_config
-w /etc/libaudit.conf -p wa -k audit_config
-w /etc/audisp/ -p wa -k audit_config
-w /sbin/auditctl -p x -k audit_tools
-w /sbin/auditd -p x -k audit_tools

## ─── FINALIZE: Make rules immutable (requires reboot to change) ──────────────
## Uncomment in production after thorough testing
# -e 2

• Флаг -e 2 в конце делает конфигурацию аудита неизменяемой до следующей перезагрузки, что критически важно для защиты от несанкционированных изменений в средах с повышенными требованиями к безопасности.

Лучшие практики использования auditd

Auditd — это мощный инструмент аудита, однако неправильно настроенная конфигурация может генерировать чрезмерное количество логов, занимать дисковое пространство и усложнять расследование инцидентов. Цель состоит в том, чтобы собирать полезные события, связанные с безопасностью, не перегружая при этом систему.

• В первую очередь отслеживайте критически важные файлы → начните аудит с файлов, которые напрямую влияют на безопасность системы и управление доступом пользователей.

#Common examples:
/etc/passwd
/etc/shadow
/etc/group
/etc/sudoers
/etc/ssh/sshd_config

# These files are often the first place attackers or administrators make changes.

• Используйте понятные ключи → Всегда задавайте понятные ключи с помощью параметра -k. Осмысленные ключи значительно упрощают поиск и создание отчетов.

-k ssh_config
-k user_changes
-k sudo_usage
-k privileged_commands

• Не пытайтесь аудировать всё → Распространенной ошибкой является попытка логировать каждое возможное событие, что может привести к огромному объему логов и повлиять на производительность системы.
• Отслеживайте привилегированную активность → Отслеживайте действия, выполняемые с повышенными привилегиями.

sudo auditctl -a always,exit \
  -F arch=b64 \
  -S execve \
  -F euid=0 \
  -k privileged_commands

• Делайте правила постоянными → Правила, добавленные с помощью auditctl, исчезают после перезагрузки. Храните production-правила в каталоге /etc/audit/rules.d/.
• Определяйте правила аудита как для b64 (64-битной архитектуры), так и для b32 (32-битной совместимости) → В 64-битном ядре 32-битные процессы используют другие номера системных вызовов, и без отдельных правил они могут не попасть в аудит.
• Включите ротацию логов → В загруженных системах логи аудита могут быстро расти. Правильно настроенная ротация предотвращает неожиданное заполнение диска.
• Контролируйте доступное место на диске → Если логи аудита невозможно записать, мы можем потерять видимость важных событий.
• Регулярно используйте ausearch и aureport → Сбор данных аудита полезен только в том случае, если кто-то регулярно их анализирует.
• Пересылайте логи в централизованную систему → Для production-сред не полагайтесь исключительно на локальное хранение логов.
• Периодически пересматривайте правила аудита → Требования к аудиту со временем меняются. Политика аудита должна развиваться вместе с нашей инфраструктурой.
• Периодически проверяйте состояние аудита → Убедитесь, что события не теряются, выполнив команду sudo auditctl -s и проверив, что значение поля lost остается равным 0.

Заключение

auditd — это мощный инструмент безопасности Linux, который создает подробные журналы аудита важных событий системы, таких как изменения файлов, выполнение команд, аутентификация и повышение привилегий.

В этой статье мы рассмотрели основы auditd, включая принцип его работы, создание правил аудита, управление файлами конфигурации, поиск логов с помощью ausearch, формирование отчетов с помощью aureport и применение лучших практик для production-сред.

Помните, что эффективный аудит сосредоточен на действиях, критически важных для безопасности, а не на регистрации всех событий. Администраторы должны регулярно пересматривать правила, контролировать потерянные события и обеспечивать правильное хранение и защиту логов.

Спасибо за чтение! Надеюсь, это руководство поможет вам повысить безопасность и улучшить наблюдаемость Linux-систем.

Какие правила auditd являются для вас обязательными на каждом Linux-сервере?