Linux-аудит с auditd: как мы выполнили требования ЦБ и PCI DSS для банка

Банк «БанкИнфо» обратился к нам в itfresh.ru после предписания ЦБ: на 14 Linux-серверах (Ubuntu 22.04 и CentOS 8) не настроен аудит действий пользователей. По требованиям PCI DSS (раздел 10) и положению ЦБ 683-П каждое действие администратора на серверах с платёжными данными должно логироваться.

Текущее состояние:

• 14 серверов — 4 web, 3 application, 2 database, 3 batch processing, 2 management
• Аудит — auditd установлен (по умолчанию), но правила не настроены. Логируется только PAM (логины)
• Пользователи — 8 администраторов с sudo, 4 сервисных аккаунта, root-доступ не заблокирован
• Централизация — отсутствует, логи хранятся локально, ротируются через 4 недели
• SIEM — есть (Wazuh), но auditd-логи в него не поступают

Задача: настроить полноценный аудит на всех 14 серверах, обеспечить централизованный сбор логов и интеграцию с SIEM для выполнения требований PCI DSS и 683-П.

Auditd — штатный демон аудита в Linux, работающий на уровне ядра. Он перехватывает системные вызовы и записывает их в лог. Первый шаг — настройка основного конфигурационного файла:

# /etc/audit/auditd.conf

# Файл лога
log_file = /var/log/audit/audit.log
log_format = ENRICHED          # Добавляет имена пользователей/групп к UID/GID
log_group = root

# Размер и ротация
max_log_file = 50              # Максимальный размер файла (MB)
num_logs = 10                  # Количество ротируемых файлов
max_log_file_action = ROTATE   # Ротировать при достижении лимита

# Буферизация
flush = INCREMENTAL_ASYNC      # Баланс между производительностью и надёжностью
freq = 50                      # Flush каждые 50 записей

# Критично для compliance: что делать при переполнении
space_left = 150               # Предупреждение при 150 MB свободного места
space_left_action = SYSLOG     # Отправить в syslog
admin_space_left = 50          # Критический порог
admin_space_left_action = HALT # ОСТАНОВИТЬ систему (требование PCI DSS!)
disk_full_action = HALT        # При заполнении диска — остановить систему
disk_error_action = HALT       # При ошибке диска — остановить систему

# Производительность
priority_boost = 4             # Приоритет процесса auditd
name_format = HOSTNAME         # Добавлять hostname в записи

# Порт для приёма удалённых логов (на центральном сервере)
# tcp_listen_port = 60
# tcp_listen_queue = 5
# tcp_max_per_addr = 1

Важный момент: disk_full_action = HALT означает, что сервер остановится, если диск для audit-логов заполнится. Это жёсткое требование PCI DSS 10.7 — лучше остановить сервер, чем потерять аудит-логи. Для production-серверов банка это был осознанный выбор.

File watch rules — простейший тип правил. Отслеживают доступ к файлам и директориям:

# /etc/audit/rules.d/30-file-watches.rules

# === PCI DSS 10.2.7: доступ к системным файлам ===

# Отслеживаем изменения учётных записей
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k identity
-w /etc/sudoers.d/ -p wa -k identity

# Отслеживаем изменения SSH-конфигурации
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

# Отслеживаем изменения сетевой конфигурации
-w /etc/hosts -p wa -k network_config
-w /etc/sysconfig/network -p wa -k network_config
-w /etc/netplan/ -p wa -k network_config
-w /etc/resolv.conf -p wa -k network_config

# Отслеживаем изменения в cron (потенциальные backdoors)
-w /etc/crontab -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 /var/spool/cron/ -p wa -k cron

# Отслеживаем изменения в PAM (аутентификация)
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/ -p wa -k pam

# Отслеживаем изменения в auditd (попытка отключить аудит)
-w /etc/audit/ -p wa -k audit_config
-w /etc/audit/auditd.conf -p wa -k audit_config
-w /etc/audit/rules.d/ -p wa -k audit_config

# Отслеживаем логи (попытка удалить логи)
-w /var/log/audit/ -p wa -k audit_logs
-w /var/log/auth.log -p wa -k auth_logs
-w /var/log/syslog -p wa -k sys_logs

Флаги доступа: r — чтение, w — запись, x — выполнение, a — изменение атрибутов. Ключ (-k) — произвольная метка для поиска в логах.

Syscall rules перехватывают системные вызовы ядра. Это мощнее файловых правил, но сложнее в настройке:

# /etc/audit/rules.d/40-syscalls.rules

# === PCI DSS 10.2.2: действия root и привилегированных пользователей ===

# Отслеживаем все команды, выполненные от root (uid=0)
-a always,exit -F arch=b64 -F euid=0 -S execve -k root_commands
-a always,exit -F arch=b32 -F euid=0 -S execve -k root_commands

# Отслеживаем использование sudo
-a always,exit -F path=/usr/bin/sudo -F perm=x -k sudo_usage
-a always,exit -F path=/usr/bin/su -F perm=x -k su_usage

# === PCI DSS 10.2.5: изменения идентификации и аутентификации ===

# Отслеживаем смену пользователя (setuid/setgid)
-a always,exit -F arch=b64 -S setuid -S setreuid -S setresuid -k setuid
-a always,exit -F arch=b64 -S setgid -S setregid -S setresgid -k setgid

# === PCI DSS 10.2.6: инициализация аудит-логов ===

# Отслеживаем попытки удаления/очистки логов
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat \
  -F dir=/var/log -k log_deletion
-a always,exit -F arch=b64 -S truncate -S ftruncate \
  -F dir=/var/log -k log_truncation

# === Отслеживаем сетевые подключения ===

# Исходящие подключения (detect reverse shells)
-a always,exit -F arch=b64 -S connect -F a2=16 -F success=1 -k network_connect

# Прослушивание портов (detect backdoors)
-a always,exit -F arch=b64 -S bind -k network_bind
-a always,exit -F arch=b64 -S listen -k network_listen

# === Отслеживаем загрузку/выгрузку модулей ядра ===
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_modules
-a always,exit -F arch=b64 -S delete_module -k kernel_modules

# === Отслеживаем монтирование файловых систем ===
-a always,exit -F arch=b64 -S mount -S umount2 -k mounts

# === Отслеживаем изменение системного времени ===
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time_change
-w /etc/localtime -p wa -k time_change

Блокируем возможность отключения auditd:

# /etc/audit/rules.d/99-finalize.rules

# Делаем конфигурацию immutable (нельзя изменить без перезагрузки)
-e 2

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

Auditd генерирует тысячи записей в минуту. Для анализа используются ausearch (поиск конкретных событий) и aureport (сводные отчёты):

# ausearch — поиск конкретных событий

# Все действия конкретного пользователя за последний час
ausearch -ua admin_petrov -ts recent

# Все изменения в /etc/passwd
ausearch -k identity -ts today

# Все sudo-команды за последние сутки
ausearch -k sudo_usage -ts yesterday

# Конкретное событие по номеру
ausearch -a 12345 --interpret

# Пример вывода (с --interpret для читаемости):
# type=SYSCALL msg=audit(04/05/2026 14:23:15.442:12345) :
#   arch=x86_64 syscall=execve success=yes exit=0
#   ppid=4521 pid=4522 auid=admin_petrov uid=root
#   comm=useradd exe=/usr/sbin/useradd
#   key=root_commands
# type=EXECVE msg=audit(04/05/2026 14:23:15.442:12345) :
#   argc=3 a0=useradd a1=-m a2=new_user

# aureport — сводные отчёты

# Сводка по авторизации за день
aureport -au -ts today
# Authentication Report
# =====================
# date      time     acct    host     term   exe      success
# 04/05/26  08:12:01 admin_petrov 10.0.1.5  ssh  /usr/sbin/sshd yes
# 04/05/26  08:15:33 deploy_bot   10.0.1.100 ssh /usr/sbin/sshd yes
# 04/05/26  09:01:44 unknown      185.x.x.x ssh  /usr/sbin/sshd no

# Сводка по исполняемым файлам
aureport -x -ts today --summary

# Сводка по аномалиям
aureport --anomaly -ts today

# Сводка по изменениям конфигурации
aureport -c -ts today

# Отчёт по ключевым событиям (для аудиторов)
aureport -k -ts this-month --summary
# Key Summary Report
# ===================
# total  key
# 4521   root_commands
# 1247   sudo_usage
#  892   identity
#   45   sshd_config
#   12   audit_config
#    3   kernel_modules

Для ежедневного мониторинга мы написали скрипт, отправляющий сводку в Telegram:

#!/bin/bash
# /opt/scripts/audit_daily_report.sh
# Запускается по cron: 0 9 * * * /opt/scripts/audit_daily_report.sh

HOSTNAME=$(hostname)
DATE=$(date -d 'yesterday' +%m/%d/%Y)

LOGINS=$(aureport -au -ts yesterday -te today 2>/dev/null | tail -1 | awk '{print $1}')
FAILED=$(aureport -au -ts yesterday -te today --failed 2>/dev/null | tail -1 | awk '{print $1}')
SUDO=$(ausearch -k sudo_usage -ts yesterday -te today 2>/dev/null | grep -c 'type=SYSCALL')
FILE_CHANGES=$(ausearch -k identity -ts yesterday -te today 2>/dev/null | grep -c 'type=SYSCALL')
ANOMALIES=$(aureport --anomaly -ts yesterday -te today 2>/dev/null | wc -l)

MSG="📋 *Audit Report: ${HOSTNAME}*
Date: ${DATE}

Logins: ${LOGINS}
Failed logins: ${FAILED}
Sudo commands: ${SUDO}
Identity changes: ${FILE_CHANGES}
Anomalies: ${ANOMALIES}"

curl -s "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
  -d "chat_id=${CHAT_ID}&text=${MSG}&parse_mode=Markdown" >/dev/null

Локальные audit-логи уязвимы: злоумышленник с root-доступом может удалить их. Решение — централизованный сбор через audisp-remote на выделенный сервер:

# === На каждом сервере (отправитель) ===

sudo apt install -y audispd-plugins

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

# /etc/audit/audisp-remote.conf
remote_server = 10.0.10.50       # Центральный сервер
port = 60
transport = tcp

# Что делать, если центральный сервер недоступен
network_failure_action = stop    # Остановить аудит (PCI DSS)
disk_full_action = stop
network_retry_time = 30
max_tries_per_record = 3

# Шифрование (если поддерживается)
# enable_krb5 = yes
# krb5_principal = auditd/server@BANK.LOCAL

# === На центральном сервере (приёмник) ===

# /etc/audit/auditd.conf (добавляем)
tcp_listen_port = 60
tcp_listen_queue = 5
tcp_max_per_addr = 1
tcp_client_max_idle = 0

# Перезапускаем auditd
sudo systemctl restart auditd

# Проверяем приём логов
sudo ss -tlnp | grep 60
# LISTEN  0  5  *:60  *:*  users:(("auditd",pid=1234,fd=5))

# Логи со всех серверов приходят в /var/log/audit/audit.log
# Различаем по полю node=
ausearch -k sudo_usage --node web-server-01

Структура хранения на центральном сервере:

# Разделяем логи по серверам через rsyslog
# /etc/rsyslog.d/50-audit-split.conf
template(name="AuditByHost" type="string"
  string="/var/log/audit/hosts/%HOSTNAME%/audit.log")

if $programname == 'audisp-remote' then {
  action(type="omfile" dynaFile="AuditByHost")
  stop
}

# Результат:
# /var/log/audit/hosts/web-server-01/audit.log
# /var/log/audit/hosts/web-server-02/audit.log
# /var/log/audit/hosts/db-server-01/audit.log
# ...

PCI DSS раздел 10 и SOX (Sarbanes-Oxley) требуют конкретных аудит-событий. Мы составили маппинг правил:

# /etc/audit/rules.d/50-pci-dss.rules

# PCI DSS 10.2.1: доступ к данным карт
-w /opt/app/cardholder/ -p rwxa -k cardholder_access
-w /opt/app/payment/data/ -p rwxa -k cardholder_access

# PCI DSS 10.2.4: неудачные попытки входа
-w /var/log/faillog -p wa -k login_failures
-w /var/log/lastlog -p wa -k login_failures
-w /var/run/faillock/ -p wa -k login_failures

# PCI DSS 10.2.5: повышение привилегий
-a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/usr/bin/su -k privilege_escalation
-a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/usr/bin/sudo -k privilege_escalation
-w /usr/bin/passwd -p x -k password_change
-w /usr/sbin/usermod -p x -k user_modification
-w /usr/sbin/userdel -p x -k user_deletion
-w /usr/sbin/useradd -p x -k user_creation
-w /usr/sbin/groupmod -p x -k group_modification

# SOX: отслеживание финансовых данных
-w /opt/app/finance/reports/ -p rwxa -k sox_financial_data
-w /opt/app/finance/transactions/ -p rwxa -k sox_financial_data

# Применяем правила и проверяем
sudo augenrules --load
sudo auditctl -l | wc -l
# 67 rules loaded

# Тестируем: редактируем /etc/passwd
sudo useradd testuser

# Ищем событие
ausearch -k identity -ts recent --interpret
# type=SYSCALL ... exe=/usr/sbin/useradd key=identity
# type=USER_ACCT ... op=adding-user acct=testuser

# Удаляем тестового пользователя
sudo userdel testuser

Auditd с полным набором правил создаёт нагрузку на систему. Мы замерили impact на серверах банка:

Для минимизации overhead мы исключаем шумные процессы:

# /etc/audit/rules.d/20-excludes.rules

# Исключаем шумные системные процессы
-a always,exclude -F msgtype=CWD
-a always,exclude -F msgtype=EOE
-a never,exit -F arch=b64 -F exe=/usr/sbin/zabbix_agentd -k exclude_zabbix
-a never,exit -F arch=b64 -F exe=/usr/bin/node_exporter -k exclude_prometheus
-a never,exit -F arch=b64 -F dir=/proc -k exclude_proc
-a never,exit -F arch=b64 -F dir=/sys -k exclude_sys

Интеграция с Wazuh SIEM: Wazuh agent читает audit.log и отправляет на SIEM-сервер:

# /var/ossec/etc/ossec.conf (на каждом сервере)
<ossec_config>
  <localfile>
    <log_format>audit</log_format>
    <location>/var/log/audit/audit.log</location>
  </localfile>
</ossec_config>

# Wazuh декодирует auditd-записи и генерирует алерты:
# Rule 80784: Audit: command executed by root
# Rule 80790: Audit: user account was modified
# Rule 80700: Audit: watched file was accessed
# Rule 80710: Audit: configuration was changed

Результаты внедрения auditd на 14 серверах банка:

Auditd — мощный инструмент, который есть в каждом Linux-дистрибутиве. Его не нужно устанавливать — нужно только правильно настроить правила. Если вашей компании нужен Linux-аудит для compliance — обращайтесь к нам в itfresh.ru.