Auditd Linux: настройка, правила и интеграция с SIEM для аудита TrueNAS ZFS | AdminWiki | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Auditd Linux: настройка, правила и интеграция с SIEM для аудита TrueNAS ZFS | AdminWiki

17 мая 2026 10 мин. чтения
Содержание статьи

Система аудита безопасности Linux, известная как auditd, - это фундаментальный инструмент для контроля и анализа всех действий в операционной системе. В отличие от стандартного syslog или journald, auditd отслеживает системные вызовы на уровне ядра, предоставляя неизменяемые и детализированные журналы о доступе к файлам, выполнению команд, сетевым подключениям и изменениям конфигураций. Это делает auditd незаменимым для соответствия стандартам безопасности, расследования инцидентов и проактивного мониторинга инфраструктуры, особенно в гибридных средах с TrueNAS, Proxmox VE и контейнеризованными приложениями.

Это руководство предоставляет полный, проверенный на практике цикл работы с auditd: от установки и базовой настройки до создания сложных правил для аудита ZFS на TrueNAS, анализа логов и интеграции с системами SIEM для централизованного мониторинга в 2026 году.

Что такое auditd и почему он критичен для безопасности Linux-серверов

Демон auditd - это компонент подсистемы аудита Linux (Linux Auditing System). Его ключевое отличие от других систем логирования - работа на уровне ядра. Вместо регистрации событий от приложений, auditd перехватывает системные вызовы, такие как open, execve, connect и bind. Это позволяет отслеживать действия, которые могут быть скрыты от прикладного ПО, включая попытки несанкционированного доступа или выполнения привилегированных команд.

Главные преимущества auditd для администратора безопасности:

  • Детализация. Каждая запись в /var/log/audit/audit.log содержит идентификатор пользователя (UID), группы (GID), идентификатор процесса (PID), системный вызов и его аргументы, результат выполнения (успех или неудача) и временную метку.
  • Неизменяемость. Журналы auditd защищены от модификации самими пользователями, включая root, при правильной настройке. Это критично для целостности доказательной базы.
  • Интеграция с SELinux/AppArmor. Auditd регистрирует события, связанные с мандатным контролем доступа, что упрощает отладку политик и обнаружение аномалий.

В контексте инфраструктуры 2026 года auditd решает конкретные задачи:

  • Аудит ZFS на TrueNAS. Отслеживание всех команд zfs и zpool, включая критичные операции вроде destroy. Это дополняет встроенные механизмы логирования TrueNAS.
  • Контроль сетевой безопасности. Мониторинг изменений правил nftables или iptables на хостах Proxmox VE, а также сетевых подключений гостевых систем.
  • Анализ атак на сервисы. Детальный аудит доступа к файлам конфигурации Bind9 и выполнения сетевых команд помогает расследовать инциденты, выходящие за рамки логирования самого сервиса, и обеспечивает контекст для таких инструментов, как Fail2ban.

Установка и базовая настройка auditd на современных дистрибутивах (2026)

Пакет auditd входит в репозитории всех основных дистрибутивов Linux. Инструкции актуальны для версий, поддерживаемых в 2026 году.

Установка

Для систем на базе RHEL, Rocky Linux, AlmaLinux, CentOS Stream и Fedora:

sudo dnf install audit audisp-plugins

Для систем на базе Debian, Ubuntu и TrueNAS Scale (основанной на Debian):

sudo apt update
sudo apt install auditd audispd-plugins

В Astra Linux пакет auditd обычно предустановлен. Для проверки и обновления используйте:

sudo apt install --only-upgrade auditd

Проверка состояния и версии

После установки проверьте состояние демона и его версию:

sudo systemctl status auditd
sudo auditd --version

Базовая конфигурация

Основной файл конфигурации демона - /etc/audit/auditd.conf. Настройте ключевые параметры для рабочей среды:

# Путь к основному файлу журнала
log_file = /var/log/audit/audit.log

# Формат записи: RAW (бинарный для эффективности) или NOLOG (только в память)
log_format = RAW

# Максимальный размер одного файла лога (в мегабайтах)
max_log_file = 50

# Действие при достижении максимального размера: ROTATE (ротация), IGNORE, SUSPEND, SYSLOG
max_log_file_action = ROTATE

# Количество файлов ротации для хранения
num_logs = 10

# Действие при нехватке места на диске (критически важный параметр)
# SYSLOG - отправить предупреждение в syslog, SINGLE - перевести систему в однопользовательский режим
space_left_action = SYSLOG
admin_space_left_action = SINGLE

На TrueNAS Scale, где ZFS управляет томами, рассмотрите размещение логов аудита на отдельном dataset с отключенной опцией destroy для дополнительной защиты.

Написание правил auditd для аудита ZFS на TrueNAS: готовые примеры

Правила auditd определяют, какие события отслеживать. Они загружаются при старте демона из файлов в /etc/audit/rules.d/ (обычно audit.rules). Правила можно добавлять динамически с помощью утилиты auditctl, но для постоянного применения их нужно прописать в конфигурационных файлах.

Вот набор готовых, проверенных правил для аудита операций с ZFS на TrueNAS и контроля критичных системных областей.

Правила для отслеживания команд ZFS и Zpool

# Аудит всех исполняемых файлов zfs и zpool по пути
-w /usr/sbin/zfs -p x -k zfs_command
-w /usr/sbin/zpool -p x -k zpool_command

# Альтернативно: аудит по системному вызову execve для любого процесса с именами "zfs" или "zpool"
-a always,exit -F arch=b64 -S execve -F path=/usr/sbin/zfs -F key=zfs_exec
-a always,exit -F arch=b64 -S execve -F path=/usr/sbin/zpool -F key=zpool_exec

Ключ -k (key) добавляет пользовательскую метку к событиям, что сильно упрощает их фильтрацию в логах и отчетах.

Правила для аудита доступа к критичным каталогам

# Мониторинг любых записей (w) и изменений атрибутов (a) в /etc (конфигурации)
-w /etc -p wa -k etc_changes

# Мониторинг исполнения (x) файлов в /sbin и /usr/sbin (системные утилиты)
-w /sbin -p x -k system_bin_exec
-w /usr/sbin -p x -k system_bin_exec

Правила для отслеживания системных вызовов

# Аудит открытия файлов на чтение или запись с неудачным результатом (может указывать на сканирование)
-a always,exit -F arch=b64 -S open,openat,openat2 -F exit=-EACCES -k access_denied
-a always,exit -F arch=b64 -S open,openat,openat2 -F exit=-EPERM -k access_denied

# Аудит изменения идентификатора пользователя/группы (например, через sudo или su)
-a always,exit -F arch=b64 -S setuid,setgid,setreuid,setregid -F key=identity_change

После добавления правил в /etc/audit/rules.d/audit.rules примените их и перезагрузите демон:

sudo auditctl -R /etc/audit/rules.d/audit.rules
sudo systemctl restart auditd

Для глубокой настройки аудита ZFS на TrueNAS, включая создание алертов на конкретные операции, обратитесь к нашему пошаговому руководству по аудиту безопасности ZFS.

Анализ журналов аудита: aureport, ausearch и реагирование на инциденты

Собранные логи бесполезны без инструментов анализа. В комплекте с auditd идут утилиты aureport и ausearch.

Формирование сводных отчетов с aureport

aureport агрегирует данные из audit.log в удобочитаемые отчеты.

# Сводный отчет по всем событиям за сегодня
sudo aureport

# Отчет о всех неудачных (failed) событиях
sudo aureport --failed

# Отчет о событиях по пользователям
sudo aureport -u

# Отчет о событиях, связанных с файлами
sudo aureport -f

# Отчет о событиях по заданному ключу (например, zfs_command)
sudo aureport -k --key zfs_command

Детальный поиск с ausearch

ausearch позволяет искать конкретные записи по множеству критериев.

# Поиск всех событий для конкретного пользователя (по UID)
sudo ausearch -ua 1000

# Поиск событий по системному вызову (например, execve)
sudo ausearch -sc execve

# Поиск событий по ключу
sudo ausearch -k zfs_command

# Поиск событий за определенный временной период
sudo ausearch -ts "today 00:00" -te "now"

# Поиск неудачных попыток доступа к файлу
sudo ausearch -f /etc/shadow --success no

Практические кейсы анализа

  1. Обнаружение массового выполнения команд. Подозрительно большое количество событий execve от одного пользователя за короткий период может указывать на запуск скрипта-сканнера или майнера.
    sudo aureport -x --summary -i | head -20
  2. Выявление несанкционированного доступа к файлам. Поиск неудачных попыток открытия файлов в /etc, /root или /home/*/.ssh.
    sudo ausearch -k etc_changes --success no -i
  3. Аудит сетевой активности. Анализ событий, связанных с сетевыми вызовами (connect, bind), помогает выявить неожиданные исходящие подключения или попытки прослушивания портов.

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

Интеграция auditd с SIEM: централизованный сбор и анализ логов

Для мониторинга безопасности распределенной инфраструктуры логи auditd необходимо централизованно собирать и анализировать в SIEM-системе (Security Information and Event Management).

Настройка пересылки логов через audisp-syslog

Плагин audisp-syslog позволяет отправлять события auditd в стандартный syslog, откуда их можно переслать на сервер коллектор (например, через rsyslog).

  1. Убедитесь, что плагин установлен (audispd-plugins).
  2. Активируйте его в /etc/audisp/plugins.d/syslog.conf:
    active = yes
  3. Настройте формат в /etc/audisp/syslog.conf (например, отправлять события с ключом zfs_command с приоритетом alert).

Прямая пересылка через rsyslog

Более гибкий метод - настроить rsyslog для чтения файла audit.log и пересылки его содержимого.

Добавьте в конфигурацию rsyslog (/etc/rsyslog.conf или файл в /etc/rsyslog.d/):

module(load="imfile" PollingInterval="10") # Загружаем модуль для чтения файлов

# Определяем входной файл
input(type="imfile"
      File="/var/log/audit/audit.log"
      Tag="auditd"
      Severity="info"
      Facility="local6")

# Отправляем на удаленный SIEM-сервер по TCP с TLS
local6.* action(type="omfwd"
               Protocol="tcp"
               Target="siem.admin-wiki.local"
               Port="6514"
               StreamDriver="gtls"
               StreamDriverMode="1"
               StreamDriverAuthMode="x509/name"
               StreamDriverPermittedPeers="siem.admin-wiki.local")

Парсинг событий auditd в SIEM

События auditd в формате RAW имеют специфичную структуру. Для их корректного разбора в SIEM (Elastic Stack, Splunk, Graylog) нужны соответствующие парсеры или grok-шаблоны.

Пример Grok-шаблона для Logstash (Elastic Stack) для разбора стандартного события:

filter {
  if [type] == "auditd" {
    grok {
      match => { "message" => "type=%{WORD:audit.type} msg=audit\(%{NUMBER:audit.timestamp}:%{NUMBER:audit.serial}\): %{GREEDYDATA:audit.message}" }
    }
    # Дополнительный парсинг audit.message на отдельные поля (pid, uid, exe и т.д.)
    kv {
      source => "audit.message"
      value_split => "="
      field_split => " "
      target => "audit_data"
    }
  }
}

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

Обеспечение сохранности и неизменяемости журналов аудита

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

  1. Выделенный ZFS dataset. На TrueNAS создайте отдельный dataset для /var/log/audit/. Отключите для него возможность уничтожения снапшотов (sudo zfs set destroy_snapshots=off poolname/audit_logs). Установите квоту, чтобы избежать переполнения общего пула.
  2. Настройка logrotate. Настройте /etc/logrotate.d/auditd на ротацию логов без их удаления (опция maxage для архивации старых файлов).
  3. Использование immutable-атрибутов. Для дополнительной защиты установите неизменяемый атрибут на файлы логов после их создания/ротации:
    sudo chattr +i /var/log/audit/audit.log.*
    Учтите, что это может помешать работе auditd при ротации. Атрибут нужно снимать перед ротацией и устанавливать заново после.
  4. Немедленная пересылка. Самая надежная стратегия - настройка немедленной пересылки каждого события на защищенный удаленный сервер-коллектор (см. раздел про интеграцию с SIEM). Локальные логи становятся вторичным источником.

Практические кейсы аудита инфраструктуры: Bind9, Proxmox VE и сетевой безопасности

Рассмотрим применение auditd для решения задач, описанных в контекстных материалах.

Аудит изменений сетевой конфигурации в Proxmox VE

Для отслеживания изменений правил nftables (стандартный фаервол в Proxmox VE) добавьте правило:

-w /usr/sbin/nft -p x -k nftables_change
# Аудит доступа к файлам конфигурации nftables
-w /etc/nftables.conf -p wa -k nftables_config

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

Дополнение к аудиту безопасности Bind9

Помимо анализа логов самого Bind9 (например, для Fail2ban), auditd может отслеживать доступ к критичным файлам:

-w /etc/bind/ -p wa -k bind_config_changes
-w /usr/sbin/named -p x -k named_execution

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

Аудит сетевых команд и подключений

Для выявления неавторизованных сетевых сканирований или подключений можно отслеживать выполнение сетевых утилит:

-w /usr/bin/nmap -p x -k network_scan
-w /usr/bin/nc -p x -k netcat_exec
-w /usr/bin/ssh -p x -k ssh_exec

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

Резюме и лучшие практики эксплуатации auditd в 2026

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

  1. Установите и настройте демон: Инсталлируйте пакеты, отредактируйте auditd.conf, задав политики ротации и реакции на нехватку места.
  2. Определите правила аудита: Начните с готовых правил для критичных активов (ZFS на TrueNAS, системные бинарники, конфигурации). Избегайте избыточного логирования, которое быстро заполнит диски.
  3. Настройте централизованный сбор: Интегрируйте auditd с вашей SIEM-системой через audisp-plugins или rsyslog. Обеспечьте безопасный (TLS) канал передачи.
  4. Защитите журналы: Используйте выделенные тома (ZFS datasets), immutable-атрибуты и немедленную пересылку для обеспечения целостности логов.
  5. Автоматизируйте анализ: Настройте регулярные отчеты (cron + aureport) на почту и создайте дашборды в SIEM для визуализации ключевых метрик безопасности.
  6. Регулярно пересматривайте правила: Адаптируйте правила аудита под изменения в инфраструктуре. Тестируйте новые правила в тестовой среде перед применением в production.

Auditd остается фундаментальным, низкоуровневым инструментом аудита в Linux. Его сила - в детализации и неизменяемости. В связке с системами централизованного сбора логов и SIEM он формирует основу для отказоустойчивой системы безопасности, способной не только регистрировать события, но и обеспечивать контекст для быстрого расследования и реагирования на инциденты в сложной инфраструктуре 2026 года.

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

Поделиться:
Сохранить гайд? В закладки браузера