Главная
» Как сделать
»
Безопасная пересылка Syslog-сообщений SLES с использованием rsyslog и взаимного TLS.
Безопасная пересылка Syslog-сообщений SLES с использованием rsyslog и взаимного TLS.
Для безопасной пересылки системных журналов SUSE Linux Enterprise Server (SLES) настройте rsyslog для отправки сообщений через защищенный TLS TCP-порт 6514, проверьте имя сертификата сборщика и подтвердите доставку тестовым событием. 27 марта 2026 года в SLES 15 SP7 было выпущено необязательное обновление rsyslog, добавившее модуль OpenSSL TLS; в приведенной ниже конфигурации намеренно используется gtlsуже существующий модуль GnuTLS ( ).
Данная процедура описывает отправителя SLES 15 с именем sles01.example.netи сборщика rsyslog с именем logs.example.net. Замените оба имени и все пути к сертификатам своими значениями. Используется взаимный TLS, поэтому сборщик аутентифицирует отправителя, а отправитель аутентифицирует сборщика.
1. Проверьте rsyslog и путь к файлу логов SLES.
На обоих хостах установите демон rsyslog и его модуль GnuTLS из зарегистрированных репозиториев SUSE. В существующих установках первый пакет может уже присутствовать.
Перед добавлением правил ознакомьтесь /etc/rsyslog.confс существующими фрагментами кода /etc/rsyslog.d/. В частности, отключите все старые *.* @@hostправила пересылки незашифрованных сообщений для одного и того же адресата; в противном случае сообщения могут проходить по двум маршрутам, включая один без TLS.
SLES использует systemd-journaldжурнал событий, в то время как rsyslog обрабатывает входящие данные syslog. Убедитесь, что необходимые вам события поступают в rsyslog через существующую конфигурацию ввода. ForwardToSyslog=yesВ документации SUSE /etc/systemd/journald.confописана процедура пересылки журнальных сообщений в syslog; проверьте свою конфигурацию перед внесением изменений, поскольку отдельное включение читателей журналов может привести к дублированию событий. Эта процедура пересылает сообщения, уже обработанные rsyslog, а не каждый файл /var/logавтоматически.
Перед включением TLS проверьте установку rsyslog и убедитесь, что у отправителя имеются отдельные файлы центра сертификации, сертификата и ключа.
2. Подготовьте доверенные сертификаты сервера и клиента.
Используйте контролируемый организацией центр сертификации (ЦС) для выдачи сертификата с альтернативным именем субъекта DNS logs.example.netдля сборщика и отдельного сертификата, идентифицирующего sles01.example.netотправителя. Убедитесь, что сертификаты действительны для их ролей TLS-сервера или клиента и что обе машины доверяют выдавшему их ЦС. Следуйте процедуре PKI для генерации и продления сертификатов; не используйте один и тот же закрытый ключ на разных хостах.
Скопируйте соответствующие файлы по защищенному каналу, одобренному администратором. В этом примере обе машины используют /etc/rsyslog.d/tls/ca.pem. Сборщик дополнительно имеет server-cert.pemи server-key.pem; отправитель имеет client-cert.pemи client-key.pem.
При необходимости ограничьте доступ к сертификатам и ключам для учетной записи службы rsyslog. Не раскрывайте закрытые ключи в диагностических данных, истории командной оболочки, репозиториях Git или экспортируемом потоке логов. Перед перезапуском демона убедитесь, что процесс rsyslog может прочитать свой ключ.
3. Включите аутентифицированный TLS-приемник на сборщике данных.
Вставьте logs.example.netследующее в качестве параметра /etc/rsyslog.d/30-tls-listener.conf. Если imtcpмодуль уже загружен в другом месте, оставьте только одно оператор загрузки модуля. Специальный набор правил помещает удаленно полученные сообщения в отдельный файл, вместо того чтобы смешивать их с локальными системными сообщениями.
StreamDriver.Mode="1"Включает TLS, но x509/nameотклоняет PermittedPeerклиентов без подтвержденного сертификата. Единственное разрешенное имя выбрано намеренно; расширение списка одобренных узлов при добавлении других отправителей вместо ослабления аутентификации.
Выполняйте команды брандмауэра только в том случае, если сборщик использует firewalld. Ограничьте входящий трафик TCP/6514 известными сетями отправителей, используя брандмауэр вашего хоста или вышестоящего сервера; открытие порта не заменяет аутентификацию по сертификату. Также убедитесь, что ни один из существующих прослушивателей открытого текста не был непреднамеренно раскрыт.
Приемник TLS использует порт 6514, режим GnuTLS 1 и аутентификацию по имени сертификата; в статье приведена полная конфигурация приемника.
4. Добавить пересылку TLS и ограниченную очередь в SLES.
Убедитесь sles01.example.net, что рабочий каталог rsyslog существует и доступен для записи службой. Показанный здесь каталог является иллюстративным; сохраните уже настроенный каталог, workDirectoryесли он предусмотрен в вашем установочном пакете. Добавьте этот фрагмент кода следующим образом /etc/rsyslog.d/60-tls-forward.conf:
Настройки TLS аутентифицируют сборщик перед отправкой. Очередь действий с поддержкой диска буферизует сообщения во время коротких сбоев и повторяет неудачную попытку пересылки, но она не бесконечна и не гарантирует полной потери сообщений: доступное дисковое пространство, ограничения очереди, поведение процесса при завершении работы и состояние получателя по-прежнему имеют значение. Перед тем как полагаться на буферизацию диска, проверьте эффективный рабочий каталог rsyslog и создайте его с соответствующими правами доступа.
Проверьте и перезапустите отправителя:
sudo rsyslogd -N1
sudo systemctl restart rsyslog
Если проверка конфигурации не удалась, не перезапускайте систему; исправьте первую обнаруженную ошибку. В существующей системе rsyslog глобальные директивы сертификата могут влиять на другие действия TLS. Проверьте другие исходящие действия и используйте поддерживаемые параметры сертификата для каждого действия, если они требуют других учетных данных.
Пересылайте системные сообщения на logs.example.net, используя действие omfwd с поддержкой TLS; добавьте настройки сертификата и отказоустойчивую очередь из прилагаемого кода.
5. Проверить получение и расследовать случай неудачного рукопожатия.
Сначала убедитесь, что сборщик данных прослушивает порт TCP/6514 и что отправитель может связаться с хостом через брандмауэр. Затем выполните следующую команду на отправителе SLES:
logger -t sles-tls-check "TLS forwarding probe"
На сборщике данных найдите настроенный удаленный файл журнала:
Обнаружение маркера /var/log/remote-tls.logподтверждает, что путь пересылки на уровне приложения сработал для этого теста. Это не доказывает, что собираются все файлы журналов, специфичные для приложения. Для независимой проверки аутентификации временно используйте другой, недоверенный сертификат или несовпадающее имя узла в контролируемом окне обслуживания и подтвердите, что соединение TLS не устанавливается; немедленно восстановите исходную конфигурацию.
Проверьте rsyslog и отправьте тестовое сообщение с уникальной меткой, затем проверьте журнал сборщика на наличие зондирующего сообщения, вместо того чтобы предполагать его доставку.
Если индикатор не появляется, выполните действия по устранению неполадок в указанном порядке:
Нет прослушивателя или соединение отклонено: проверьте systemctl status rsyslogправила брандмауэра TCP/6514 и правила сбора данных.
Ошибка TLS или сертификата: сравните SAN-коды сертификатов с PermittedPeerи StreamDriverPermittedPeers; проверьте цепочку центров сертификации, даты истечения срока действия, системные часы и права доступа к закрытому ключу.
Подключено, но событий нет: проверьте наличие дублирующихся или отсутствующих входных данных журнала/системного журнала, приостановленных действий пересылки и емкости очереди диска. Проверьте journalctl -u rsyslogна обоих хостах.