Rsyslog over TLS на Linux VDS: центральный сервер логов без лишней магии

Инструкции
17 июл, 2026
Время на чтение: ~22 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Централизованные логи — одна из тех вещей, о которых вспоминают слишком поздно: когда сервер уже недоступен, диск с логами заполнен, контейнер пересоздан, а нужная строка была только в локальном /var/log/auth.log или /var/log/messages. Классический rsyslog умеет отправлять события на удалённый сервер давно, но в 2026 году отправлять их «как есть» по UDP или TCP без шифрования — плохая идея. Логи часто содержат IP-адреса пользователей, URL с параметрами, имена учётных записей, следы ошибок приложений и другую операционную информацию.

В этой инструкции настроим rsyslog over TLS: отдельный central log server на Linux VDS будет принимать remote syslog от клиентов по TCP/6514, проверять клиентские сертификаты, раскладывать записи по каталогам и отдавать файлы на ротацию через logrotate. На стороне клиентов используем модуль omfwd, на стороне сервера — imtcp. Получится понятная схема без тяжёлого ELK/Loki-стека: удобно для небольших и средних инфраструктур, bastion-хостов, веб-серверов, почтовых узлов и баз данных.

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

Архитектура: что именно настраиваем

Будет один сервер логов, например logs.example.net, и несколько клиентов: web01.example.net, db01.example.net, mail01.example.net. Клиенты продолжают писать локальные логи как обычно, но дополнительно пересылают выбранные сообщения на центральный узел. Передача идёт по TCP с TLS. Для строгой проверки включим взаимную аутентификацию: сервер предъявляет сертификат клиентам, а клиенты — свои сертификаты серверу.

Порт по умолчанию для syslog over TLS — 6514/tcp. Технически можно выбрать другой порт, но стандартный проще документировать и фильтровать на firewall. UDP в этой схеме не используем: он быстрый, но не гарантирует доставку и не подходит для TLS в привычном варианте rsyslog.

Минимальная схема выглядит так:

rsyslog на сервере загружает imtcp и слушает 6514/tcp с драйвером gtls;
сервер хранит логи в /var/log/remote/имя-хоста/программа.log;
rsyslog на клиентах использует omfwd и отправляет сообщения на logs.example.net:6514;
firewall разрешает вход на порт лог-сервера только с IP-адресов клиентов;
logrotate ежедневно сжимает и удаляет старые файлы по политике хранения.

Подготовка пакетов

На большинстве серверных дистрибутивов rsyslog уже установлен, но поддержка GnuTLS часто вынесена в отдельный пакет. Проверяйте это сразу: если модуль не установлен, конфигурация с StreamDriver="gtls" не загрузится, а в журнале появится ошибка про отсутствующий драйвер.

Debian и Ubuntu

apt update
apt install -y rsyslog rsyslog-gnutls openssl logrotate
systemctl enable --now rsyslog

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux

dnf install -y rsyslog rsyslog-gnutls openssl logrotate
systemctl enable --now rsyslog

Если на RHEL-based системе используется firewalld, он пригодится дальше для открытия порта. На минимальных образах он может быть не активен — это нормально, ниже есть варианты для ufw, firewalld и nftables.

Администратор готовит TLS-сертификаты для rsyslog

Сертификаты: внутренняя CA и mTLS

Для production-схемы удобно завести небольшую внутреннюю CA: корневой сертификат кладём на все узлы, серверу выдаём сертификат с именем logs.example.net, каждому клиенту — отдельный сертификат с CN/SAN, совпадающим с ожидаемым именем узла. Это проще отозвать, проще аудировать и безопаснее, чем один общий клиентский ключ на все машины.

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

Создаём CA на защищённой машине

mkdir -p ~/rsyslog-ca
cd ~/rsyslog-ca
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ca.key
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=Example Internal Rsyslog CA"

Сертификат для central log server

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out logs.example.net.key
openssl req -new -key logs.example.net.key -out logs.example.net.csr -subj "/CN=logs.example.net" -addext "subjectAltName=DNS:logs.example.net"
openssl x509 -req -in logs.example.net.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out logs.example.net.crt -days 397 -sha256 -copy_extensions copy

Сертификат для клиента

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out web01.example.net.key
openssl req -new -key web01.example.net.key -out web01.example.net.csr -subj "/CN=web01.example.net" -addext "subjectAltName=DNS:web01.example.net"
openssl x509 -req -in web01.example.net.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out web01.example.net.crt -days 397 -sha256 -copy_extensions copy

На лог-сервер переносим ca.crt, logs.example.net.crt и logs.example.net.key. На клиент web01 переносим ca.crt, web01.example.net.crt и web01.example.net.key. Не копируйте ca.key на рабочие серверы без крайней необходимости.

Разложим файлы на сервере и выставим права:

install -d -m 0750 -o root -g root /etc/rsyslog.d/tls
install -m 0644 ca.crt /etc/rsyslog.d/tls/ca.crt
install -m 0644 logs.example.net.crt /etc/rsyslog.d/tls/server.crt
install -m 0600 logs.example.net.key /etc/rsyslog.d/tls/server.key

На клиенте аналогично:

install -d -m 0750 -o root -g root /etc/rsyslog.d/tls
install -m 0644 ca.crt /etc/rsyslog.d/tls/ca.crt
install -m 0644 web01.example.net.crt /etc/rsyslog.d/tls/client.crt
install -m 0600 web01.example.net.key /etc/rsyslog.d/tls/client.key

Настройка центрального rsyslog-сервера

Создадим отдельный конфиг, чтобы не смешивать удалённый приём с системными правилами дистрибутива. Файл можно назвать /etc/rsyslog.d/20-remote-tls-server.conf. В нём задаём TLS-файлы, загружаем imtcp, описываем шаблон пути и отдельный ruleset для удалённых сообщений.

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.crt"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server.crt"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server.key"
)

module(load="imtcp")

template(name="RemoteLogs" type="list") {
  constant(value="/var/log/remote/")
  property(name="hostname" securepath="replace")
  constant(value="/")
  property(name="programname" securepath="replace")
  constant(value=".log")
}

ruleset(name="remote") {
  action(type="omfile" dynaFile="RemoteLogs" dirCreateMode="0750" fileCreateMode="0640")
  stop
}

input(
  type="imtcp"
  port="6514"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/name"
  PermittedPeer=["web01.example.net", "db01.example.net", "mail01.example.net"]
  ruleset="remote"
)

Параметр StreamDriver.Mode="1" включает TLS-only режим: обычное TCP-соединение без TLS не будет принято. StreamDriver.AuthMode="x509/name" заставляет проверять сертификат клиента и его имя. PermittedPeer — список разрешённых CN/SAN. Это важный слой защиты: даже если кто-то знает адрес и порт, без доверенного клиентского сертификата он не сможет слать логи.

Отдельно обратите внимание на securepath="replace" в шаблоне. Имена хостов и программ приходят из сообщений, а значит не стоит использовать их в путях без фильтрации. Этот параметр заменяет небезопасные символы и снижает риск неожиданной записи за пределы нужного каталога.

Создадим каталог для удалённых логов и проверим конфигурацию:

install -d -m 0750 -o root -g adm /var/log/remote
rsyslogd -N1
systemctl restart rsyslog
systemctl status rsyslog --no-pager

На RHEL-based системах группы adm может не быть. В таком случае используйте root или отдельную группу для администраторов логов:

install -d -m 0750 -o root -g root /var/log/remote

Если отдельный лог-сервер только планируется, лучше сразу заложить запас по диску и сети: для таких задач удобен изолированный облачный VDS, который не совмещён с production-приложением.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Firewall: открыть только нужным клиентам

Слушать 6514/tcp на весь интернет не нужно. Даже при mTLS лучше ограничить доступ на уровне firewall: так меньше шума в логах, меньше поверхность атаки и проще читать статистику соединений. Ниже примеры для клиента с адресом 203.0.113.10. Для нескольких серверов добавьте отдельные правила или используйте наборы в nftables.

UFW

ufw allow from 203.0.113.10 to any port 6514 proto tcp
ufw status verbose

firewalld

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port port="6514" protocol="tcp" accept'
firewall-cmd --reload
firewall-cmd --list-rich-rules

nftables

nft add rule inet filter input ip saddr 203.0.113.10 tcp dport 6514 accept
nft list ruleset

После перезапуска rsyslog убедитесь, что порт слушается:

ss -ltnp | grep 6514

Настройка клиента: omfwd и очередь доставки

На клиенте создадим файл /etc/rsyslog.d/60-forward-tls.conf. В нём укажем TLS-файлы клиента и действие omfwd. Хорошая практика — включить очередь: если central log server временно недоступен, rsyslog не будет терять сообщения мгновенно, а попробует отправить их позже. Но чудес не бывает: при долгой недоступности и большом потоке логов очередь может вырасти, поэтому за ней нужно следить.

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.crt"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/client.crt"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/client.key"
)

action(
  type="omfwd"
  Target="logs.example.net"
  Port="6514"
  Protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.example.net"
  Template="RSYSLOG_SyslogProtocol23Format"
  queue.type="LinkedList"
  queue.size="10000"
  queue.filename="fwd_logs_example_net"
  queue.maxdiskspace="1g"
  queue.saveonshutdown="on"
  action.resumeRetryCount="-1"
)

Здесь StreamDriverPermittedPeers="logs.example.net" проверяет имя серверного сертификата. Если сертификат выдан на другое имя или клиент подключается по IP без подходящего SAN, соединение корректно завершится ошибкой. Это нормальное и желательное поведение: иначе TLS защищал бы только шифрование, но не аутентичность сервера.

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

rsyslogd -N1
systemctl restart rsyslog
journalctl -u rsyslog -n 100 --no-pager

Первый тест доставки

На клиенте отправим тестовое сообщение через обычную команду logger. Оно попадёт в локальный syslog и должно уйти на central log server.

logger -p local0.info "rsyslog tls test from web01"

На сервере смотрим, появился ли файл и строка:

find /var/log/remote -maxdepth 3 -type f
grep -R "rsyslog tls test" /var/log/remote

Если файла нет, проверяйте по слоям: слушает ли сервер порт, пропускает ли firewall, совпадает ли имя в сертификате, доверяет ли клиент CA, разрешён ли клиент в PermittedPeer, нет ли ошибок в journalctl -u rsyslog. При TLS-проблемах журнал rsyslog обычно достаточно честно сообщает, что именно не прошло: проверка цепочки, имя peer, права на ключ или невозможность загрузить драйвер.

Дополнительно можно проверить TLS-рукопожатие без отправки syslog-сообщения:

openssl s_client -connect logs.example.net:6514 -servername logs.example.net -CAfile /etc/rsyslog.d/tls/ca.crt -cert /etc/rsyslog.d/tls/client.crt -key /etc/rsyslog.d/tls/client.key

Успешное соединение ещё не гарантирует, что формат syslog правилен, но оно быстро отделяет проблемы сертификатов и firewall от ошибок маршрутизации сообщений внутри rsyslog.

Проверка доставки remote syslog на центральный сервер

Фильтрация: отправлять всё или только важное

Самый простой вариант — отправлять все сообщения клиента. Но на загруженном веб-сервере это может быть слишком шумно: access-логи Nginx или приложения с debug-уровнем быстро съедят диск и канал. Лучше заранее решить, какие facilities и уровни нужны централизованно. Если вы приводите в порядок веб-логи за прокси или CDN, пригодится отдельная инструкция про настройку реального IP в логах Nginx за прокси.

Например, можно пересылать только сообщения уровня warning и выше, а также всё, что относится к авторизации:

auth,authpriv.* action(type="omfwd" Target="logs.example.net" Port="6514" Protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="logs.example.net" Template="RSYSLOG_SyslogProtocol23Format")
*.warning action(type="omfwd" Target="logs.example.net" Port="6514" Protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="logs.example.net" Template="RSYSLOG_SyslogProtocol23Format")

Для production-конфига такой однострочный стиль хуже читается, поэтому чаще оставляют один action-блок и добавляют условия перед ним. Но сама идея важна: central log server должен получать полезный сигнал, а не бесконечный поток мусора. Если нужно централизовать веб-access-логи, подумайте о JSON-формате, отдельном хранилище и ограниченной ретенции.

Logrotate для удалённых логов

Файлы в /var/log/remote будут расти постоянно. Если не настроить logrotate, через несколько недель или дней лог-сервер может упереться в диск. Создадим файл /etc/logrotate.d/remote-rsyslog.

/var/log/remote/*/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    dateext
    create 0640 root adm
    sharedscripts
    postrotate
        systemctl kill -s HUP rsyslog.service || true
    endscript
}

На системах без группы adm замените строку create 0640 root adm на create 0640 root root или на вашу административную группу. Проверить ротацию можно в debug-режиме:

logrotate -d /etc/logrotate.d/remote-rsyslog

Принудительный запуск для теста:

logrotate -f /etc/logrotate.d/remote-rsyslog

Сигнал HUP нужен, чтобы rsyslog переоткрыл файлы после ротации. Без этого демон может продолжать писать в старый inode, и вы увидите странную картину: файл «удалён», место на диске занято, а новые строки не появляются там, где ожидается.

Ретенция, приватность и доступы

Центральный сервер логов часто становится очень чувствительным узлом. В нём сходятся события со всех машин: SSH-входы, sudo-команды, ошибки приложений, иногда фрагменты HTTP-запросов. Поэтому доступ к /var/log/remote должен быть минимальным. Не давайте читать эти файлы всем пользователям «для удобства» и не используйте лог-сервер как обычную рабочую машину.

Практичная политика для небольшой инфраструктуры:

хранить подробные системные логи 14–30 дней;
хранить security-события дольше, если это требуется внутренними правилами;
не отправлять в syslog секреты, токены, пароли и полные тела запросов;
ограничить SSH-доступ к лог-серверу администраторами;
следить за свободным местом и inode на разделе с логами;
документировать, какие хосты имеют клиентские сертификаты и когда они истекают.

Если в логах есть персональные данные, заранее определите срок хранения и круг доступа. Технически logrotate легко поставить на rotate 365, но это не значит, что так нужно делать. Подробнее о сроках хранения, IP-адресах и аккуратной работе с логами веб-серверов мы разбирали в материале про приватность и ретенцию Nginx-логов.

Типовые ошибки и быстрая диагностика

rsyslog не стартует после изменения конфига

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

rsyslogd -N1
journalctl -u rsyslog -n 100 --no-pager

Частые причины: забытый пакет rsyslog-gnutls, опечатка в имени параметра, неправильные кавычки после копирования, недоступный ключ из-за прав 0600 при запуске демона не от root. В стандартных пакетах rsyslog обычно стартует с достаточными правами для чтения конфигурационных ключей, но локальные hardening-настройки могут это изменить.

Клиент пишет про ошибку имени сертификата

Проверьте, что Target совпадает с SAN или CN серверного сертификата, а StreamDriverPermittedPeers содержит именно это имя. Если подключаетесь к logs.example.net, сертификат должен быть выдан на logs.example.net. Подключение по IP потребует IP SAN в сертификате, что обычно менее удобно.

Сервер отклоняет клиента

Сверьте CN/SAN клиентского сертификата со списком PermittedPeer на сервере. Если клиент называется web01.example.net, а в сертификате web01, строгая проверка имени не пройдёт. Это не баг, а защита от подмены узлов.

Сообщения приходят, но hostname странный

Rsyslog берёт имя из самого syslog-сообщения. Проверьте hostname на клиенте:

hostnamectl
hostname -f

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

Логи теряются при недоступности сервера

Проверьте параметры очереди: queue.filename, queue.maxdiskspace, queue.saveonshutdown и action.resumeRetryCount. Для критичных событий можно настроить отдельную disk-assisted очередь и мониторить её размер. Но не превращайте syslog-клиента в бесконечный буфер: если центральный сервер не работает сутки, это должен увидеть мониторинг.

Когда rsyslog over TLS подходит, а когда лучше другой стек

rsyslog over TLS хорош, когда нужно быстро и надёжно собрать системные события с Linux VDS без разворачивания тяжёлой платформы. Он экономен по RAM и CPU, привычен администраторам, работает на старых и новых дистрибутивах, не требует отдельной базы данных и легко переживает умеренные объёмы логов.

Но если вам нужны полнотекстовый поиск по терабайтам, сложные dashboards, корреляция событий, алерты по потокам, парсинг JSON и метрики ingestion, один rsyslog-сервер станет только транспортом или временным решением. В таком случае его можно оставить как приёмник на edge, а дальше отправлять логи в специализированное хранилище. Главное — не начинать с тяжёлой системы только потому, что она популярна. Для многих задач центрального расследования достаточно аккуратно настроенного syslog, TLS, firewall и ротации.

Короткий чек-лист перед production

rsyslog-gnutls установлен на сервере и клиентах.
Сервер слушает только 6514/tcp, UDP не открыт без необходимости.
firewall разрешает вход только с IP клиентов.
Включена проверка имени через x509/name.
У каждого клиента свой сертификат, а не общий ключ на всех.
Приватные ключи имеют права 0600.
Есть logrotate с понятной ретенцией.
Настроен мониторинг свободного места на разделе логов.
Проверена отправка через logger и TLS-подключение через openssl s_client.
Документирована процедура ротации и перевыпуска сертификатов.

После такой настройки central log server становится спокойной базовой частью инфраструктуры: клиенты отправляют события по защищённому каналу, сервер принимает только доверенные узлы, firewall отсекает лишнее, а logrotate не даёт диску незаметно заполниться. Это не самая модная система логирования, зато понятная, предсказуемая и очень полезная в момент, когда нужно быстро восстановить картину событий.

Поделиться статьей