Настройка централизованного сбора логов аудита: rsyslog + auditd с TLS | Практическое руководство | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Настройка централизованного сбора логов аудита: rsyslog + auditd с TLS | Практическое руководство

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

Зачем нужен централизованный сбор логов аудита и что мы построим

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

Централизованная система решает три ключевые задачи:

  • Единая точка мониторинга – все события безопасности видны в одном месте.
  • Оперативное расследование инцидентов – вы отслеживаете атаку по всей инфраструктуре за минуты.
  • Соответствие требованиям стандартов – PCI DSS, ISO 27001 и других регуляторов требуют защищенного хранения и анализа логов аудита.

Архитектура решения, которую мы построим:

  1. Агенты – серверы с установленными auditd (генерация событий) и rsyslog (отправка).
  2. Защищенный канал – TLS-шифрование для предотвращения перехвата и подмены логов.
  3. Сервер-коллектор – центральный rsyslog, принимающий и классифицирующий логи.
  4. Структурированное хранилище – логи автоматически сортируются по хостам-источникам.

Инструкция проверена на современных системах с systemd (RHEL/CentOS 8/9, Ubuntu 20.04/22.04) и дает готовое решение для немедленного внедрения.

Подготовка инфраструктуры и установка необходимых компонентов

Перед началом убедитесь, что все узлы используют совместимые версии ПО. Несоответствие версий rsyslog может привести к проблемам с передачей.

Требования:

  • Поддерживаемые дистрибутивы: RHEL/CentOS 8/9, Ubuntu 20.04/22.04 и их производные.
  • Доступ с правами root или через sudo на всех узлах.
  • Открытые порты между агентами и коллектором (по умолчанию 514/TCP или 6514/TLS).
  • Свободное место на диске коллектора для хранения логов.

Установка и проверка auditd на серверах-агентах

Auditd – демон аудита Linux, который фиксирует события безопасности на уровне ядра.

Установка:

# Для RHEL/CentOS/Fedora
yum install audit audit-libs  # или dnf install audit audit-libs

# Для Ubuntu/Debian
apt update && apt install auditd audispd-plugins

Проверка и запуск:

# Проверяем, что служба активна
systemctl status auditd

# Запускаем и добавляем в автозагрузку
systemctl start auditd
systemctl enable auditd

# Генерируем тестовое событие для проверки работы
auditctl -w /etc/shadow -p wa -k shadow_access

# Смотрим запись в логе
tail -f /var/log/audit/audit.log

В логе должна появиться запись о доступе к файлу /etc/shadow.

Установка и базовая настройка rsyslog на всех узлах

Rsyslog – высокопроизводительная система обработки системных логов с поддержкой модулей.

Установка с необходимыми модулями:

# Для RHEL/CentOS/Fedora
yum install rsyslog rsyslog-gnutls rsyslog-relp

# Для Ubuntu/Debian
apt install rsyslog rsyslog-gnutls rsyslog-relp

Проверка версии и модулей:

rsyslogd -v

# Проверяем поддержку TLS и RELP
rsyslogd -N 1 | grep -E "(gtls|relp)"

Базовая конфигурация для работы в режиме агента:

Файл /etc/rsyslog.conf должен содержать минимальную конфигурацию:

$ModLoad imuxsock  # provides support for local system logging
$ModLoad imjournal # provides access to the systemd journal
$ModLoad imtcp     # TCP input module (для коллектора)
$ModLoad omrelp    # RELP output module (альтернатива TLS)

Перезапустите службу после изменений:

systemctl restart rsyslog
systemctl status rsyslog

Настройка сервера-коллектора (приемник логов)

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

Конфигурация модуля приема и правил фильтрации

Создайте структуру каталогов для хранения логов:

mkdir -p /var/log/remote/
chown syslog:syslog /var/log/remote/
chmod 750 /var/log/remote/

Добавьте в /etc/rsyslog.conf на коллекторе:

# Модуль для приема TCP-соединений
$ModLoad imtcp
$InputTCPServerRun 514

# Шаблон для структурированного хранения
$template RemoteHostAuth,"/var/log/remote/%HOSTNAME%/auth.log"
$template RemoteHostAudit,"/var/log/remote/%HOSTNAME%/audit.log"
$template RemoteHostSyslog,"/var/log/remote/%HOSTNAME%/syslog.log"

# Правила фильтрации
if ($fromhost-ip startswith "192.168.") then {
  # Логи аудита
  if ($programname == 'auditd' or $msg contains 'type=AVC') then {
    action(type="omfile" fileTemplate="RemoteHostAudit")
    stop
  }
  # Логи аутентификации
  if ($syslogfacility-text == 'authpriv' or $programname == 'sshd') then {
    action(type="omfile" fileTemplate="RemoteHostAuth")
    stop
  }
  # Остальные системные логи
  action(type="omfile" fileTemplate="RemoteHostSyslog")
}

Эта конфигурация сортирует логи по хостам-источникам и разделяет их по типам событий.

Организация безопасного и удобного хранения

Настройте права доступа для защиты конфиденциальных логов:

# Только root и syslog имеют доступ
chmod 640 /var/log/remote/*/*.log
chown root:syslog /var/log/remote/*/*.log

Добавьте конфигурацию logrotate для автоматической ротации логов. Создайте файл /etc/logrotate.d/remote-logs:

/var/log/remote/*/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 640 root syslog
    sharedscripts
    postrotate
        systemctl reload rsyslog > /dev/null 2>&1 || true
    endscript
}

Мониторинг дискового пространства критически важен. Настройте оповещения при достижении 80-90% заполнения раздела с логами.

Настройка безопасной пересылки логов с агентов на коллектор (TLS)

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

Генерация и распространение сертификатов

Создайте инфраструктуру PKI на сервере-коллекторе:

# Создаем директорию для CA
mkdir /etc/rsyslog.d/tls
cd /etc/rsyslog.d/tls

# Генерируем приватный ключ CA
openssl genrsa -out ca.key 4096

# Создаем самоподписанный сертификат CA
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
  -subj "/C=RU/ST=Moscow/L=Moscow/O=Company/CN=Logging CA"

# Генерируем приватный ключ сервера
openssl genrsa -out server.key 4096

# Создаем запрос на сертификат для сервера
openssl req -new -key server.key -out server.csr \
  -subj "/C=RU/ST=Moscow/L=Moscow/O=Company/CN=log-collector.company.local"

# Подписываем сертификат сервера CA
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt

# Генерируем сертификаты для клиентов (агентов)
# Повторите для каждого агента:
openssl genrsa -out client-agent1.key 4096
openssl req -new -key client-agent1.key -out client-agent1.csr \
  -subj "/C=RU/ST=Moscow/L=Moscow/O=Company/CN=agent1.company.local"
openssl x509 -req -days 365 -in client-agent1.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out client-agent1.crt

Распространение сертификатов:

  • ca.crt – распространите на все агенты
  • server.crt и server.key – оставьте на коллекторе
  • client-agentX.crt и client-agentX.key – передайте на соответствующий агент

Установите строгие права на приватные ключи:

chmod 600 /etc/rsyslog.d/tls/*.key
chown root:root /etc/rsyslog.d/tls/*.key

Конфигурация rsyslog для работы поверх TLS

На сервере-коллекторе создайте файл /etc/rsyslog.d/tls-server.conf:

# Загружаем модуль для TLS
$ModLoad imtcp
$DefaultNetstreamDriver gtls

# Настройки TLS
$DefaultNetstreamDriverCAFile /etc/rsyslog.d/tls/ca.crt
$DefaultNetstreamDriverCertFile /etc/rsyslog.d/tls/server.crt
$DefaultNetstreamDriverKeyFile /etc/rsyslog.d/tls/server.key

# Разрешаем только TLS соединения
$InputTCPServerStreamDriverMode 1  # TLS required
$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerRun 6514

На агенте создайте файл /etc/rsyslog.d/tls-client.conf:

# Загружаем модуль для отправки
$ModLoad omfwd

# Настройка TLS
$DefaultNetstreamDriverCAFile /etc/rsyslog.d/tls/ca.crt
$DefaultNetstreamDriverCertFile /etc/rsyslog.d/tls/client-agent1.crt
$DefaultNetstreamDriverKeyFile /etc/rsyslog.d/tls/client-agent1.key

# Отправка логов аудита на коллектор
if $programname == 'auditd' or $msg contains 'type=AVC' then {
  action(
    type="omfwd"
    Target="log-collector.company.local"
    Port="6514"
    Protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    streamdriver.CheckExtendedKeyPurpose="on"
    queue.filename="forwardingq"
    queue.maxdiskspace="1g"
    queue.saveonshutdown="on"
    queue.type="LinkedList"
    action.resumeRetryCount="-1"
  )
  stop
}

Перезапустите rsyslog на всех узлах:

systemctl restart rsyslog

Проверьте, что служба запустилась без ошибок:

systemctl status rsyslog
tail -f /var/log/rsyslog/rsyslog.log

Интеграция auditd с rsyslog для отправки событий

Auditd по умолчанию пишет события только в локальный файл. Для отправки в rsyslog используется плагин audispd.

Настройте плагин syslog в файле /etc/audisp/plugins.d/syslog.conf:

active = yes
direction = out
path = builtin_syslog
type = builtin
args = LOG_INFO
format = string

В файле /etc/audit/auditd.conf убедитесь, что включена запись логов и настроена достаточная глубина очереди:

write_logs = yes
log_format = RAW
log_group = root
flush = INCREMENTAL_ASYNC
freq = 50
max_log_file_action = KEEP_LOGS
num_logs = 5
disp_qos = lossless
disp_priority = 10

Для немедленного применения изменений перезапустите auditd:

systemctl restart auditd

Теперь события auditd будут передаваться в локальный rsyslog через сокет, а оттуда – на центральный коллектор по защищенному TLS-каналу.

Проверка работоспособности всей системы

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

Генерация тестовых событий и отслеживание потока

Выполните на агенте команды для генерации событий аудита:

# 1. Попытка неудачного входа по SSH (с неверным паролем)
ssh localhost -o PasswordAuthentication=yes

# 2. Использование sudo
sudo ls /root

# 3. Доступ к защищенному файлу
cat /etc/shadow 2>/dev/null || true

# 4. Прямая отправка тестового сообщения через logger
logger -p authpriv.warn "Test audit message from $(hostname)"

Отслеживайте поток событий на каждом этапе:

# На агенте: проверяем локальный лог auditd
tail -f /var/log/audit/audit.log

# На агенте: проверяем отправку в rsyslog
tail -f /var/log/rsyslog/rsyslog.log | grep -E "(audit|action)"

# На коллекторе: проверяем получение логов
tail -f /var/log/remote/[HOSTNAME]/audit.log

Если события не появляются на коллекторе в течение 30 секунд, начинайте диагностику.

Диагностика частых проблем

1. Проверка статуса служб:

systemctl status auditd rsyslog

2. Проверка открытых портов:

# На коллекторе
ss -tlnp | grep :6514

# На агенте
ss -tlnp | grep rsyslog

3. Проверка брандмауэра и SELinux:

# Для firewalld
firewall-cmd --list-all | grep 6514

# Для iptables
iptables -L -n -v | grep 6514

# SELinux контекст для порта
semanage port -l | grep rsyslog

4. Проверка сертификатов:

# Проверка срока действия
openssl x509 -in /etc/rsyslog.d/tls/server.crt -noout -dates

# Проверка цепочки доверия
openssl verify -CAfile /etc/rsyslog.d/tls/ca.crt /etc/rsyslog.d/tls/server.crt

5. Детальная отладка rsyslog:

Временно включите отладку в /etc/rsyslog.conf:

$DebugLevel 2  # Уровень отладки от 0 до 2
$DebugFile /var/log/rsyslog-debug.log

После диагностики не забудьте отключить отладку и перезапустить службу.

Расширенная настройка: ключевые правила auditd и управление системой

Базовая система работает. Теперь оптимизируйте её под конкретные требования безопасности.

Ключевые правила auditd для мониторинга:

Создайте файл /etc/audit/rules.d/security-monitoring.rules:

# Мониторинг попыток входа/выхода
-a always,exit -S all -F pid=1000 -F uid=0 -k authentication

# Отслеживание использования sudo
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d/ -p wa -k sudoers_changes

# Изменения в критичных файлах
-w /etc/passwd -p wa -k identity_management
-w /etc/shadow -p wa -k identity_management
-w /etc/group -p wa -k identity_management
-w /etc/gshadow -p wa -k identity_management

# Изменения в конфигурации SSH
-w /etc/ssh/sshd_config -p wa -k ssh_config

# Системные вызовы для подозрительной активности
-a always,exit -S execve -F path=/bin/bash -k shell_activity
-a always,exit -S mount -k filesystem_mount

# Доступ к файлам с конфиденциальными данными
-w /var/log/secure -p ra -k auth_access
-w /var/log/audit/ -p ra -k audit_access

Примените правила:

# Загружаем правила
auditctl -R /etc/audit/rules.d/security-monitoring.rules

# Проверяем активные правила
auditctl -l

Управление ротацией логов на коллекторе:

Модифицируйте конфигурацию logrotate для аудита:

/var/log/remote/*/audit.log {
    daily
    missingok
    rotate 90  # Храним 90 дней для соответствия требованиям
    compress
    delaycompress
    dateext
    dateformat -%Y%m%d
    create 640 root syslog
    sharedscripts
    postrotate
        systemctl reload rsyslog > /dev/null 2>&1 || true
    endscript
}

Мониторинг объема логов:

Добавьте в crontab регулярную проверку:

# Ежедневная проверка свободного места
0 2 * * * df -h /var/log/remote/ | mail -s "Log storage report" admin@company.local

# Еженедельный отчет по объему логов по хостам
0 3 * * 1 du -sh /var/log/remote/*/ | sort -hr | head -20 > /var/log/storage-report.txt

Интеграция с системами мониторинга:

Настроенная система становится источником данных для SIEM-решений. Вы можете использовать готовые методики аудита безопасности для анализа собранных логов и построения дашбордов.

Для анализа веб-логов в аналогичной централизованной системе обратитесь к руководству по практическому анализу логов Nginx и Apache.

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

Для автоматизации рутинных задач администрирования используйте практическое руководство по Linux.

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