Bezpieczne przekazywanie dziennika systemowego SLES za pomocą rsyslog i wzajemnego protokołu TLS

Aby bezpiecznie przekazywać logi systemowe SUSE Linux Enterprise Server (SLES), należy skonfigurować rsyslog do wysyłania wiadomości przez port TCP 6514 chroniony protokołem TLS, zweryfikować nazwę certyfikatu kolektora i potwierdzić dostarczenie zdarzeniem testowym. 27 marca 2026 r. w systemie SLES 15 SP7 pojawiła się opcjonalna aktualizacja rsyslog, która dodała moduł OpenSSL TLS. Poniższa konfiguracja celowo wykorzystuje gtlszamiast tego istniejący moduł GnuTLS ( ).

Ta procedura obejmuje nadawcę SLES 15 o nazwie sles01.example.neti kolektor rsyslog o nazwie logs.example.net. Zastąp obie nazwy i wszystkie ścieżki certyfikatów własnymi wartościami. Korzysta ona z wzajemnego protokołu TLS, więc kolektor uwierzytelnia nadawcę, jak również nadawcę uwierzytelniającego kolektor.

1. Sprawdź rsyslog i ścieżkę logowania SLES

Na obu hostach zainstaluj demona rsyslog i jego moduł GnuTLS z zarejestrowanych repozytoriów SUSE. Istniejące instalacje mogą już zawierać pierwszy pakiet.

sudo zypper install rsyslog rsyslog-module-gtls
rpm -q rsyslog rsyslog-module-gtls
sudo systemctl enable --now rsyslog
rsyslogd -v

Przed dodaniem reguł przejrzyj /etc/rsyslog.confistniejące fragmenty kodu /etc/rsyslog.d/. W szczególności wyłącz wszelkie starsze, niezaszyfrowane *.* @@hostreguły przekierowywania dla tego samego miejsca docelowego; w przeciwnym razie wiadomości mogą być przesyłane dwiema trasami, w tym jedną bez TLS.

SLES używa systemd-journaldzdarzeń dziennika, podczas gdy rsyslog przetwarza dane wejściowe syslog. Upewnij się, że potrzebne zdarzenia docierają do rsyslog poprzez istniejącą konfigurację danych wejściowych. Dokumenty SUSE ForwardToSyslog=yessą przeznaczone /etc/systemd/journald.confdo przekazywania z dziennika do sysloga; sprawdź wdrożenie przed jego zmianą, ponieważ oddzielne włączenie czytników dziennika może powodować duplikowanie zdarzeń. Ta procedura przekazuje komunikaty już przetworzone przez rsyslog, a nie /var/logautomatycznie każdy plik.

2. Przygotuj zaufane certyfikaty serwera i klienta

Użyj urzędu certyfikacji (CA) kontrolowanego przez organizację do wystawienia certyfikatu z alternatywną nazwą podmiotu DNS logs.example.netdla kolektora oraz oddzielnego certyfikatu identyfikującego sles01.example.netnadawcę. Upewnij się, że certyfikaty są ważne dla ich ról serwera TLS lub klienta i że oba komputery ufają wystawiającemu urzędowi certyfikacji. Postępuj zgodnie z procedurą PKI dotyczącą generowania i odnawiania; nie używaj ponownie klucza prywatnego na różnych hostach.

Skopiuj odpowiednie pliki przez bezpieczny kanał zatwierdzony przez administratora. W tym przykładzie oba komputery używają /etc/rsyslog.d/tls/ca.pem. Kolektor dodatkowo ma server-cert.pem□ server-key.pem; nadawca ma client-cert.pem□ client-key.pem.

sudo install -d -m 0750 /etc/rsyslog.d/tls
sudo chmod 0600 /etc/rsyslog.d/tls/*-key.pem
sudo chmod 0644 /etc/rsyslog.d/tls/ca.pem

W razie potrzeby ogranicz dostęp do certyfikatów i kluczy dla tożsamości usługi rsyslog. Nie ujawniaj kluczy prywatnych w diagnostyce, historii powłoki, repozytoriach Git ani w wyeksportowanym strumieniu dziennika. Przed ponownym uruchomieniem demona upewnij się, że proces rsyslog może odczytać swój klucz.

3. Włącz uwierzytelnionego odbiorcę TLS na kolektorze

W przypadku logs.example.net, dodaj poniższy kod jako /etc/rsyslog.d/30-tls-listener.conf. Jeśli imtcpjest już załadowany gdzie indziej, zachowaj tylko jedno polecenie ładowania modułu. Dedykowany zestaw reguł umieszcza wiadomości odebrane zdalnie w osobnym pliku, zamiast mieszać je z lokalnymi wiadomościami systemowymi.

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server-key.pem"
)
module(load="imtcp")
ruleset(name="remote_tls") {
  action(type="omfile" file="/var/log/remote-tls.log")
}
input(
  type="imtcp"
  port="6514"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/name"
  PermittedPeer="sles01.example.net"
  ruleset="remote_tls"
)

StreamDriver.Mode="1"Włącza TLS, jednocześnie x509/nameodrzucając PermittedPeerklientów bez zaakceptowanej tożsamości certyfikatu. Pojedyncza dozwolona nazwa jest celowa; rozszerza listę zatwierdzonych nadawców podczas dodawania kolejnych nadawców zamiast osłabiać uwierzytelnianie.

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo firewall-cmd --permanent --add-port=6514/tcp
sudo firewall-cmd --reload
sudo ss -ltn | grep ':6514'

Uruchom polecenia zapory tylko wtedy, gdy kolektor korzysta z firewalld. Ogranicz ruch przychodzący TCP/6514 do znanych sieci nadawców, używając swojego hosta lub zapory sieciowej nadrzędnej; otwarcie portu nie zastępuje uwierzytelniania certyfikatem. Sprawdź również, czy żaden istniejący wcześniej nasłuchiwacz tekstu jawnego nie został przypadkowo ujawniony.

4. Dodaj przekazywanie TLS i ograniczoną kolejkę do SLES

Włącz sles01.example.net, upewnij się, że katalog roboczy rsyslog istnieje i jest dostępny do zapisu przez usługę. Pokazany tutaj katalog jest przykładowy; zachowaj już skonfigurowany, workDirectoryjeśli pakiet instalacyjny go zawiera. Dodaj ten fragment kodu jako /etc/rsyslog.d/60-tls-forward.conf:

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/client-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/client-key.pem"
)
*.* action(
  type="omfwd"
  target="logs.example.net"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.example.net"
  queue.type="LinkedList"
  queue.filename="tls_forward"
  queue.size="10000"
  queue.maxDiskSpace="1g"
  queue.saveOnShutdown="on"
  action.resumeRetryCount="-1"
)

Ustawienia TLS uwierzytelniają kolektor przed wysłaniem. Kolejka akcji wspomagana dyskiem buforuje wiadomości podczas krótkich przerw w działaniu i ponawia próby przekazania w przypadku nieudanej operacji, ale nie jest nieskończona ani nie gwarantuje całkowitej utraty wiadomości: nadal istotne są dostępne miejsce na dysku, limity kolejki, zachowanie procesu podczas zamykania i stan odbiornika. Przed skorzystaniem z buforowania dyskowego sprawdź efektywny katalog roboczy rsyslog i utwórz go z odpowiednimi prawami własności.

Sprawdź poprawność i uruchom ponownie nadawcę:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Jeśli walidacja konfiguracji się nie powiedzie, nie uruchamiaj ponownie; popraw pierwszy zgłoszony błąd. W istniejącym wdrożeniu rsyslog globalne dyrektywy certyfikatów mogą wpływać na inne akcje TLS. Sprawdź inne akcje wychodzące i użyj obsługiwanych parametrów certyfikatu dla każdej akcji, jeśli wymagają innych poświadczeń.

5. Sprawdź odbiór i zbadaj nieudane uzgadnianie

Najpierw sprawdź, czy kolektor nasłuchuje na protokole TCP/6514 i czy nadawca może połączyć się z hostem przez zaporę. Następnie uruchom następujące polecenie na nadawcy SLES:

logger -t sles-tls-check "TLS forwarding probe"

Na kolektorze wyszukaj skonfigurowany zdalny plik dziennika:

sudo grep 'TLS forwarding probe' /var/log/remote-tls.log
sudo journalctl -u rsyslog -n 50 --no-pager

Znalezienie znacznika w /var/log/remote-tls.logpotwierdza, że ​​ścieżka przekierowania na poziomie aplikacji zadziałała w tym teście. Nie dowodzi to jednak, że każdy plik dziennika specyficzny dla aplikacji jest gromadzony. Aby niezależnie przetestować uwierzytelnianie, tymczasowo użyj innego, niezaufanego certyfikatu lub niezgodnej nazwy partnera w kontrolowanym oknie konserwacji i potwierdź, że połączenie TLS nie powiedzie się; natychmiast przywróć pierwotną konfigurację.

Jeżeli znacznik się nie pojawi, postępuj zgodnie z kolejnością wystąpienia błędu:

• Brak nasłuchiwania lub odrzucone połączenie: sprawdź systemctl status rsyslogreguły zapory TCP/6514 i kolektora.
• Błąd TLS lub certyfikatu: porównaj numery SAN certyfikatu z numerem PermittedPeeri StreamDriverPermittedPeers; sprawdź łańcuch urzędu certyfikacji, daty wygaśnięcia, zegary systemowe i uprawnienia klucza prywatnego.
• Połączono, ale brak zdarzeń: sprawdź zduplikowane lub brakujące dane wejściowe dziennika/sysloga, wstrzymane akcje przekierowywania i pojemność kolejki dyskowej. Sprawdź journalctl -u rsyslogna obu hostach.

Metoda ta jest zgodna z oficjalnym przewodnikiem logowania systemowego SLES 15 SP7 , przewodnikiem klienta uwierzytelnianego certyfikatem rsyslog , dokumentacją programu nasłuchującego imtcp oraz dokumentacją przekazywania omfwd . Informacja o aktualizacji SUSE z marca 2026 roku dokumentuje dodanie opcjonalnego modułu OpenSSL. Konfiguracje różnią się w zależności od pakietu Service Pack SLES, dlatego przed wprowadzeniem zmian w środowisku produkcyjnym należy sprawdzić poprawność zainstalowanej kompilacji rsyslog.