Jak bezpiecznie eksportować logi systemu SLES do zdalnego serwera Syslog

Najbezpieczniejszym i praktycznym sposobem eksportowania logów systemowych SUSE Linux Enterprise Server (SLES) do zdalnego kolektora syslog jest użycie rsyslog przez TCP z TLS, sprawdzenie certyfikatu kolektora według nazwy i przypisanie akcji przekazywania własnej kolejki. Zwykły syslog UDP jest prosty, ale nie zapewnia poufności ani uwierzytelniania równorzędnego. Zwykły TCP poprawia sposób dostarczania, ale nadal pozostawia zawartość logów widoczną podczas przesyłania.

W tym przewodniku wykorzystano sterownik strumienia sieciowego GnuTLS ( gtls) oraz nowoczesną składnię akcji rsyslog. Procedura jest przeznaczona dla systemów SLES 15 SP7, których Podręcznik administratora został zaktualizowany 1 października 2026 r. Zawsze sprawdzaj dokładne pakiety i wersję rsyslog na hoście przed skopiowaniem konfiguracji w całości. Dokumentacja rsyslog zaleca protokół TCP z TLS dla nowoczesnych wdrożeń i zaleca kolejkę akcji dla przekierowania TCP.

Wiarygodne źródła: dokumentacja SUSE Linux Enterprise Server 15 SP7 , dokumentacja rsyslog omfwd , konfiguracja klienta TLS rsyslog i RFC 5425: TLS Transport Mapping for Syslog .

Krótki przewodnik

Przed skonfigurowaniem przekierowania

Potrzebujesz w pełni kwalifikowanej nazwy domeny zdalnego kolektora, portu TCP, na którym nasłuchuje, oraz certyfikatu urzędu certyfikacji (CA), który podpisuje certyfikat kolektora. W przypadku obustronnego protokołu TLS potrzebujesz również certyfikatu klienta i klucza prywatnego dla maszyny SLES. Certyfikat kolektora musi być ważny dla nazwy hosta skonfigurowanej w rsyslog, najlepiej za pośrednictwem alternatywnej nazwy podmiotu (SAN). Nie rozwiązuj problemu niezgodności nazw, wyłączając weryfikację certyfikatu.

Zdalny kolektor musi być już skonfigurowany do akceptowania protokołu TLS syslog. Ten artykuł koncentruje się na nadawcy SLES, ponieważ konfiguracja odbiornika różni się w zależności od systemu rsyslog, syslog-ng, urządzeń SIEM i zarządzanych usług rejestrowania. Jeśli zapora oddziela systemy, należy zezwolić hostowi SLES na inicjowanie połączeń TCP z kolektorem na skonfigurowanym porcie. Domyślna polityka firewalld z obsługą stanu zazwyczaj nie wymaga otwierania portu przychodzącego na nadawcy SLES.

Krok 1: Sprawdź, czy rsyslog jest zainstalowany i zidentyfikuj bieżącą kompilację

Zacznij od sprawdzenia wersji pakietu i demona. Zapobiegnie to pomyłkom, gdy starsze przykłady używają dyrektyw, które nie są obsługiwane przez kompilację na Twoim serwerze.

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

Jeśli rsyslog nie jest zainstalowany, zainstaluj go z włączonych repozytoriów SLES. Przed udostępnieniem długotrwałego połączenia rejestrującego, zainstaluj poprawki systemu w ramach standardowego procesu aktualizacji SUSE.

Krok 2: Zainstaluj moduł rsyslog GnuTLS

W systemie SLES sterownik sieciowy TLS jest spakowany osobno. Zainstaluj moduł GnuTLS i zachowaj obecny pakiet bazowy rsyslog:

sudo zypper install rsyslog rsyslog-module-gtls

Możesz potwierdzić, że pliki pochodzą z oczekiwanego pakietu za pomocą rpm -ql rsyslog-module-gtls. Nazwy pakietów są specyficzne dla dystrybucji, dlatego nie kopiuj nazw pakietów z podręczników dotyczących Debiana lub RHEL.

Krok 3: Bezpieczne przechowywanie danych uwierzytelniających CA i klienta

Używaj certyfikatów wydanych przez Twoją organizację lub platformę rejestrującą. W przypadku systemu produkcyjnego unikaj tworzenia nowego prywatnego urzędu certyfikacji na hoście wysyłającym logi. Laboratorium może korzystać z testowego urzędu certyfikacji, ale materiały dotyczące zaufania w środowisku produkcyjnym powinny być zgodne z procesem PKI Twojej organizacji.

Utwórz katalog z uprawnieniami użytkownika root, skopiuj pliki i ogranicz klucz prywatny. Zastąp przykładowe nazwy plików ścieżkami podanymi przez zespół ds. infrastruktury klucza publicznego (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/*

Sprawdź urząd certyfikacji i certyfikat klienta zamiast ufać nazwom plików:

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

Dokumentacja klienta rsyslog TLS wyraźnie ostrzega, że ​​klucz prywatny komputera musi być chroniony. Jeśli inny użytkownik może odczytać klucz prywatny, może on podszyć się pod klienta logującego.

Krok 4: Skonfiguruj przekazywanie TLS z weryfikacją nazwy serwera

Utwórz dedykowany punkt dostępowy, taki jak /etc/rsyslog.d/60-remote-tls.conf. Oddzielenie zdalnego przekierowania od konfiguracji dostawcy ułatwia przeglądanie i wycofywanie zmian.

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"Ważne: sam wybór sterownika obsługującego TLS nie wystarczy w konfiguracjach, w których domyślnym trybem jest zwykły TCP. StreamDriverAuthMode="x509/name"Następnie weryfikuje zdalny certyfikat i sprawdza, czy tożsamość serwera jest zgodna z dozwolonym serwerem. W miarę możliwości należy używać dokładnej nazwy kolektora w certyfikacie zamiast szerokiego symbolu wieloznacznego.

Powyższa akcja przekazuje dalej każdą wiadomość, która do niej dotrze. Jeśli chcesz przekazywać tylko wybrane obiekty lub priorytety, dodaj filtr przed akcją. Na przykład, środowisko skoncentrowane na bezpieczeństwie może przekazywać dalej zdarzenia uwierzytelniania i demona, jednocześnie przechowując lokalnie dużą liczbę dzienników debugowania aplikacji. Filtrowanie powinno być ukierunkowane na potrzeby retencji, reagowania na incydenty i zgodności, a nie na ogólne założenie, że każda wiadomość musi opuścić hosta.

Krok 5: Sprawdź poprawność, uruchom ponownie, wyślij zdarzenie testowe i sprawdź dostarczenie

Przed ponownym uruchomieniem usługi sprawdź poprawność pełnej konfiguracji rsyslog. To najszybszy sposób na wykrycie błędów składniowych i brakujących odwołań do modułów:

sudo rsyslogd -N1

Jeśli walidacja zakończy się powodzeniem, uruchom ponownie rsyslog i wyślij unikalną wiadomość testową:

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

W kolektorze wyszukaj tag sles-tls-testi nazwę hosta nadawcy. Pomyślne zdalne pojawienie się wiadomości dowodzi, że wiadomość dotarła do kolektora, ale samo w sobie nie dowodzi, że weryfikacja certyfikatu została skonfigurowana poprawnie. Silniejszym zabezpieczeniem jest pozostawienie x509/namewłączonej opcji i upewnienie się, że w dzienniku usługi rsyslog nie ma błędów uzgadniania TLS ani błędów nazw równorzędnych.

Jeśli połączenie się nie powiedzie, przetestuj rozpoznawanie nazw DNS dla logs.example.com, upewnij się, że TCP 6514 jest osiągalny, sprawdź daty ważności certyfikatu i zweryfikuj, czy certyfikat kolektora zawiera oczekiwaną nazwę DNS. Upewnij się również, że kolektor ufa urzędowi certyfikacji, który wydał certyfikat klienta SLES, gdy włączony jest wzajemny protokół TLS.

Lista kontrolna rozwiązywania problemów

• Odmowa połączenia: kolektor nie nasłuchuje na skonfigurowanym adresie/porcie lub zapora odrzuca połączenie.
• Przekroczenie limitu czasu: routing, listy kontroli dostępu sieci lub zapora sieciowa po cichu odrzucają ruch.
• Weryfikacja certyfikatu nie powiodła się: plik urzędu certyfikacji jest błędny, niekompletny, wygasł lub łańcuch certyfikatu serwera jest niekompletny.
• Niezgodność nazwy partnera: nazwa target/ StreamDriverPermittedPeersnie pasuje do tożsamości certyfikatu kolekcjonera.
• Odmowa uprawnień do klucza: ścieżka klucza lub uprawnienia nie pozwalają procesowi rsyslog na odczytanie pliku w konfiguracji usługi SLES.
• Wiadomości zatrzymują się podczas awarii: sprawdź projekt i pojemność kolejki akcji. Dokumentacja omfwd dla nadrzędnego serwera (upstream) wyraźnie zaleca kolejkę do przekierowywania TCP, aby niedostępny adres docelowy nie blokował normalnego przetwarzania.

Notatki bezpieczeństwa, które łatwo przeoczyć

Nie zastępuj walidacji certyfikatu anonimowym protokołem TLS, chyba że w pełni rozumiesz kompromis. Szyfrowanie bez uwierzytelnienia serwera nadal może narazić logi na atak typu man-in-the-middle. Podobnie, nie otwieraj przychodzącego połączenia TCP 6514 na nadawcy SLES tylko dlatego, że adresat używa tego portu; przekierowanie jest połączeniem wychodzącym klienta.

Chroń klucze prywatne klienta jako dane uwierzytelniające, wymieniaj certyfikaty przed ich wygaśnięciem i używaj nazwy hosta kolektora, która pozostaje stabilna pomimo zmian adresów IP. Jeśli potrzebujesz silniejszych gwarancji dostarczenia niż standardowe przekazywanie TCP/TLS, dokumentacja rsyslog wskazuje na RELP jako alternatywę przeznaczoną do potwierdzanego dostarczenia. Jest to odrębna opcja projektowa od szyfrowania transportu.

Ostateczna weryfikacja

Prawidłowe wdrożenie powinno spełniać cztery obserwowalne warunki: walidacja konfiguracji rsyslog zakończy się pomyślnie, usługa pozostanie aktywna po ponownym uruchomieniu, kolektor odbierze unikalne zdarzenie testowe, a dziennik nadawcy nie wykaże błędów zaufania TLS ani błędów nazwy partnera. Po pomyślnym zakończeniu tych kontroli należy udokumentować daty wygaśnięcia certyfikatów i zależność zdalnego kolektora, aby w przyszłości konserwacja nie spowodowała przerwania scentralizowanego rejestrowania.