Как безопасно экспортировать системные журналы SLES на удаленный сервер Syslog

Наиболее безопасный и практичный способ экспорта системных журналов SUSE Linux Enterprise Server (SLES) на удаленный сборщик syslog — это использование rsyslog по TCP с TLS, проверка сертификата сборщика по имени и создание собственной очереди для пересылки. Простой UDP-протокол syslog не обеспечивает конфиденциальность и аутентификацию узлов. Простой TCP улучшает качество доставки, но при этом оставляет содержимое журналов открытым во время передачи.

В этом руководстве используется драйвер сетевого потока GnuTLS ( gtls) и современный синтаксис действий rsyslog. Процедура предназначена для систем SLES 15 SP7, руководство по администрированию которых было обновлено 1 октября 2026 года. Всегда проверяйте точную версию пакетов и rsyslog на вашем хосте, прежде чем копировать конфигурацию дословно. В документации rsyslog рекомендуется использовать TCP с TLS для современных развертываний и очередь действий для пересылки TCP-пакетов.

Авторитетные источники: документация SUSE Linux Enterprise Server 15 SP7 , документация rsyslog omfwd , настройка TLS-клиента rsyslog и RFC 5425: сопоставление транспортных протоколов TLS для Syslog .

Краткий справочник

Перед настройкой пересылки

Вам потребуется полное доменное имя удаленного сборщика, TCP-порт, на котором он прослушивает запросы, и сертификат центра сертификации (CA), подписывающий сертификат сборщика. Для взаимного TLS также потребуется клиентский сертификат и закрытый ключ для машины SLES. Сертификат сборщика должен быть действителен для имени хоста, которое вы настраиваете в rsyslog, предпочтительно через альтернативное имя субъекта (SAN). Не следует устранять несоответствие имен путем отключения проверки сертификата.

Удаленный сборщик должен быть предварительно настроен для приема TLS-сообщений syslog. В этой статье основное внимание уделяется отправителю SLES, поскольку настройка получателя различается в зависимости от используемого интерфейса: rsyslog, syslog-ng, SIEM-устройства или управляемых служб логирования. Если системы разделены брандмауэром, разрешите хосту SLES инициировать TCP-соединения со сборщиком через настроенный порт. Политика firewalld по умолчанию, учитывающая состояние системы, обычно не требует открытия входящего порта на отправителе SLES.

Шаг 1: Убедитесь, что rsyslog установлен, и определите текущую версию сборки.

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

rpm -q rsyslog
rsyslogd -v
systemctl status rsyslog --no-pager

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

Шаг 2: Установите модуль GnuTLS rsyslog.

В системе SLES драйвер сети TLS поставляется отдельно. Установите модуль GnuTLS и оставьте базовый пакет rsyslog установленным:

sudo zypper install rsyslog rsyslog-module-gtls

Вы можете убедиться, что файлы получены из ожидаемого пакета, с помощью команды rpm -ql rsyslog-module-gtls`.`. Названия пакетов зависят от дистрибутива, поэтому не копируйте названия пакетов из руководств, ориентированных на Debian или RHEL.

Шаг 3: Разместите учетные данные центра сертификации и клиента в безопасном месте.

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

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

sudo install -d -m 0755 /etc/rsyslog.d/certs
sudo install -m 0644 ca.pem /etc/rsyslog.d/certs/ca.pem
sudo install -m 0644 sles-client.crt /etc/rsyslog.d/certs/sles-client.crt
sudo install -m 0600 sles-client.key /etc/rsyslog.d/certs/sles-client.key
sudo chown root:root /etc/rsyslog.d/certs/*

Проверяйте сертификаты центра сертификации и клиента, а не доверяйте именам файлов:

openssl x509 -in /etc/rsyslog.d/certs/ca.pem -noout -subject -issuer
openssl x509 -in /etc/rsyslog.d/certs/sles-client.crt -noout -subject -issuer -dates

В документации к TLS-клиенту rsyslog прямо указано, что закрытый ключ машины должен быть защищен. Если другой пользователь сможет прочитать закрытый ключ, он может выдать себя за клиент логирования.

Шаг 4: Настройка пересылки TLS с проверкой имени сервера.

Создайте отдельный модуль, например, такой /etc/rsyslog.d/60-remote-tls.conf. Разделение удаленной пересылки от конфигурации поставщика упрощает проверку и откат.

global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/sles-client.crt"
    DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/sles-client.key"
)

action(
    type="omfwd"
    target="logs.example.com"
    port="6514"
    protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.com"
    queue.type="linkedList"
)

StreamDriverMode="1"Важно: одного выбора драйвера с поддержкой TLS недостаточно в конфигурациях, где по умолчанию используется обычный TCP. StreamDriverAuthMode="x509/name"Затем проверяется удаленный сертификат и подтверждается соответствие идентификатора сервера разрешенному узлу. По возможности используйте точное имя сборщика в сертификате вместо широкого подстановочного знака.

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

Шаг 5: Проверка, перезапуск, отправка тестового события и проверка доставки.

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

sudo rsyslogd -N1

Если проверка пройдена успешно, перезапустите rsyslog и отправьте уникальное тестовое сообщение:

sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager
logger -t sles-tls-test "remote syslog TLS test $(date -Is)"
sudo journalctl -u rsyslog -n 50 --no-pager

На сборщике найдите тег sles-tls-testи имя хоста отправителя. Успешное удаленное подтверждение свидетельствует о том, что сообщение достигло сборщика, но само по себе не доказывает правильность настройки проверки сертификата. Более надежная проверка заключается в том, чтобы оставить x509/nameвключенной проверку TLS и убедиться в отсутствии ошибок рукопожатия TLS или ошибок, связанных с именем узла, в журнале службы rsyslog.

Если соединение не удается, проверьте разрешение DNS для logs.example.com, убедитесь, что TCP 6514 доступен, проверьте даты действия сертификатов и убедитесь, что сертификат сборщика содержит ожидаемое DNS-имя. Также убедитесь, что сборщик доверяет центру сертификации, выдавшему клиентский сертификат SLES, когда включена взаимная TLS-аутентификация.

Контрольный список для устранения неполадок

• Соединение отклонено: сборщик данных не прослушивает указанный адрес/порт или межсетевой экран отклоняет соединение.
• Ошибка "Тайм-аут": маршрутизация, списки контроля доступа сети или межсетевой экран незаметно отбрасывают трафик.
• Проверка сертификата не удалась: файл центра сертификации неверен, неполный, просрочен или цепочка сертификатов сервера неполная.
• Несоответствие имени узла: имя target/ StreamDriverPermittedPeersне соответствует идентификатору сертификата сборщика.
• Отказано в доступе к ключу: путь к ключу или права доступа не позволяют процессу rsyslog прочитать файл в конфигурации службы SLES.
• Во время сбоя обработка сообщений прекращается: проверьте структуру и пропускную способность очереди действий. В документации omfwd, относящейся к исходному коду, специально рекомендуется использовать очередь для пересылки TCP-сообщений, чтобы недоступность пункта назначения не блокировала нормальную обработку.

Заметки по безопасности, которые легко пропустить

Не заменяйте проверку сертификатов анонимным TLS, если вы полностью не понимаете компромисс. Шифрование без аутентификации сервера всё ещё может раскрыть журналы злоумышленнику, осуществляющему атаку типа «человек посередине». Аналогично, не открывайте входящий TCP-порт 6514 на отправителе SLES только потому, что получатель использует этот порт; переадресация — это исходящее клиентское соединение.

Защищайте закрытые ключи клиентов как учетные данные, меняйте сертификаты до истечения срока их действия и используйте имя хоста сборщика, которое остается стабильным при изменении IP-адреса. Если вам нужны более надежные гарантии доставки, чем при обычной пересылке TCP/TLS, в документации rsyslog в качестве альтернативы, предназначенной для подтвержденной доставки, указан RELP. Это отдельное проектное решение, не связанное с шифрованием транспортного уровня.

Окончательная проверка

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