Hoe exporteer ik SLES-systeemlogboeken veilig naar een externe Syslog-server?

De veiligste en meest praktische manier om SUSE Linux Enterprise Server (SLES) systeemlogboeken naar een externe syslog-collector te exporteren, is door rsyslog via TCP met TLS te gebruiken, het certificaat van de collector op naam te valideren en de doorstuuractie een eigen wachtrij te geven. Syslog via UDP is eenvoudig, maar biedt geen vertrouwelijkheid of peer-authenticatie. TCP verbetert de levering, maar de inhoud van de logboeken blijft tijdens de overdracht onbeschermd.

Deze handleiding maakt gebruik van de GnuTLS-netwerkstreamdriver ( gtls) en de moderne rsyslog-actiesyntaxis. De procedure is bedoeld voor SLES 15 SP7-systemen, waarvan de beheerdershandleiding is bijgewerkt op 1 oktober 2026. Controleer altijd de exacte pakketten en rsyslog-versie op uw host voordat u een configuratie letterlijk overneemt. De officiële rsyslog-documentatie beveelt TCP met TLS aan voor moderne implementaties en adviseert een actiewachtrij voor TCP-doorsturen.

Gezaghebbende referenties: SUSE Linux Enterprise Server 15 SP7-documentatie , rsyslog omfwd-documentatie , rsyslog TLS-clientconfiguratie en RFC 5425: TLS-transportmapping voor Syslog .

Snel naslagwerk

Voordat u doorsturen configureert

U hebt de volledig gekwalificeerde domeinnaam van de externe collector nodig, de TCP-poort waarop deze luistert en het certificaat van de certificeringsinstantie (CA) die het collectorcertificaat ondertekent. Voor wederzijdse TLS hebt u ook een clientcertificaat en een privésleutel voor de SLES-machine nodig. Het collectorcertificaat moet geldig zijn voor de hostnaam die u in rsyslog configureert, bij voorkeur via een Subject Alternative Name (SAN). Los een naamconflict niet op door certificaatverificatie uit te schakelen.

De externe collector moet al geconfigureerd zijn om TLS-syslog te accepteren. Dit artikel richt zich op de SLES-zender, omdat de configuratie van de ontvanger verschilt tussen rsyslog, syslog-ng, SIEM-apparaten en beheerde logservices. Als een firewall de systemen scheidt, moet de SLES-host TCP-verbindingen met de collector kunnen initiëren via de geconfigureerde poort. Een standaard stateful firewalld-beleid vereist meestal geen opening van een inkomende poort op de SLES-zender.

Stap 1: Controleer of rsyslog is geïnstalleerd en achterhaal de huidige build.

Begin met het controleren van de pakket- en daemonversie. Dit voorkomt verwarring wanneer oudere voorbeelden instructies gebruiken die niet worden ondersteund door de build op uw server.

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

Als rsyslog niet is geïnstalleerd, installeer het dan vanuit uw ingeschakelde SLES-repository's. Zorg ervoor dat uw systeem up-to-date blijft via uw normale SUSE-updateproces voordat u een langdurige logverbinding tot stand brengt.

Stap 2: Installeer de GnuTLS rsyslog-module

Op SLES is het TLS-netwerkstuurprogramma apart verpakt. Installeer de GnuTLS-module en zorg ervoor dat het basispakket rsyslog aanwezig blijft:

sudo zypper install rsyslog rsyslog-module-gtls

Je kunt controleren of de bestanden uit het verwachte pakket komen met rpm -ql rsyslog-module-gtls. Pakketnamen zijn distributiespecifiek, dus kopieer geen pakketnamen uit handleidingen die specifiek voor Debian of RHEL zijn bedoeld.

Stap 3: Bewaar de CA- en clientgegevens op een veilige plaats.

Gebruik certificaten die zijn uitgegeven door uw organisatie of logplatform. Voor een productiesysteem moet u voorkomen dat u een nieuwe privé-CA aanmaakt op de host die de logs verzendt. In een testomgeving kunt u een test-CA gebruiken, maar voor een productieomgeving moet het vertrouwensmodel van uw organisatie voor PKI worden gehanteerd.

Maak een map aan die eigendom is van de rootgebruiker, kopieer de bestanden en beperk de toegang tot de privésleutel. Vervang de voorbeeldbestandsnamen door de paden die uw PKI-team u heeft verstrekt:

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/*

Controleer het CA- en clientcertificaat in plaats van op bestandsnamen te vertrouwen:

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

De documentatie van de rsyslog TLS-client waarschuwt expliciet dat de privésleutel van de machine beschermd moet worden. Als een andere gebruiker de privésleutel kan lezen, kan die gebruiker zich mogelijk voordoen als de logclient.

Stap 4: Configureer TLS-doorsturen met servernaamverificatie

Maak een aparte drop-in aan, bijvoorbeeld /etc/rsyslog.d/60-remote-tls.conf. Door de externe doorsturing gescheiden te houden van de leveranciersconfiguratie, worden controle en terugdraaien eenvoudiger.

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"Het is belangrijk om te weten dat het kiezen van een TLS-compatibele driver alleen niet voldoende is in configuraties waar de standaardmodus gewoon TCP is. StreamDriverAuthMode="x509/name"Vervolgens wordt het externe certificaat geverifieerd en wordt gecontroleerd of de serveridentiteit overeenkomt met de toegestane peer. Gebruik waar mogelijk de exacte collectornaam in het certificaat in plaats van een brede wildcard.

De bovenstaande actie stuurt elk bericht dat binnenkomt door. Als u alleen bepaalde faciliteiten of prioriteiten wilt doorsturen, voeg dan een filter toe vóór de actie. Een op beveiliging gerichte omgeving kan bijvoorbeeld authenticatie- en daemon-gebeurtenissen doorsturen, terwijl grote hoeveelheden applicatie-debuglogs lokaal worden bewaard. Filtering moet worden gebaseerd op bewaarvereisten, incidentrespons en compliance, in plaats van op de algemene aanname dat elk bericht de host moet verlaten.

Stap 5: Valideren, opnieuw opstarten, een testgebeurtenis verzenden en de levering controleren

Controleer de volledige rsyslog-configuratie voordat u de service opnieuw start. Dit is de snelste manier om syntaxfouten en ontbrekende moduleverwijzingen op te sporen.

sudo rsyslogd -N1

Als de validatie slaagt, start rsyslog opnieuw en verstuur een uniek testbericht:

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

Zoek op de collector naar de tag sles-tls-testen de hostnaam van de afzender. Een succesvolle externe verschijning bewijst dat het bericht de collector heeft bereikt, maar dit bewijst op zichzelf niet dat de certificaatverificatie correct is geconfigureerd. Een betere controle is om de verificatie x509/nameingeschakeld te houden en te controleren of er geen TLS-handshake- of peer-naamfouten in het rsyslog-servicelogboek staan.

Als de verbinding mislukt, test dan de DNS-resolutie voor logs.example.com, bevestig dat TCP-poort 6514 bereikbaar is, controleer de geldigheidsdatums van het certificaat en verifieer of het collectorcertificaat de verwachte DNS-naam bevat. Controleer ook of de collector de CA vertrouwt die het SLES-clientcertificaat heeft uitgegeven wanneer wederzijdse TLS is ingeschakeld.

Checklist voor probleemoplossing

• Verbinding geweigerd: de collector luistert niet op het geconfigureerde adres/poort of een firewall blokkeert de verbinding.
• Time-out: routering, netwerk-ACL's of een firewall blokkeren stilletjes verkeer.
• Certificaatverificatie mislukt: het CA-bestand is onjuist, onvolledig, verlopen of de certificaatketen van de server is onvolledig.
• Naam van de peer komt niet overeen: de naam target/ StreamDriverPermittedPeerskomt niet overeen met de identiteit van het collectorcertificaat.
• Toegang tot de sleutel geweigerd: het sleutelpad of de machtigingen staan ​​het rsyslog-proces niet toe het bestand te lezen onder de SLES-serviceconfiguratie.
• Berichten stoppen tijdens een storing: controleer het ontwerp en de capaciteit van de actiewachtrij. De upstream omfwd-documentatie beveelt specifiek een wachtrij aan voor TCP-doorsturen, zodat een niet-beschikbare bestemming de normale verwerking niet blokkeert.

Beveiligingsinstructies die gemakkelijk over het hoofd gezien kunnen worden

Vervang certificaatvalidatie niet door anonieme TLS, tenzij u de afweging volledig begrijpt. Versleuteling zonder authenticatie van de server kan nog steeds logbestanden blootstellen aan een actieve man-in-the-middle-aanvaller. Open evenmin TCP-poort 6514 inkomend op de SLES-zender, alleen omdat de bestemming die poort gebruikt; doorsturen is een uitgaande clientverbinding.

Bescherm de privésleutels van de client als referenties, vervang certificaten voordat ze verlopen en gebruik een collectorhostnaam die stabiel blijft bij wijzigingen in het IP-adres. Als u sterkere leveringsgaranties nodig hebt dan bij normale TCP/TLS-doorsturing, verwijst de rsyslog-documentatie naar RELP als een alternatief dat is ontworpen voor bevestigde levering. Dit is een aparte ontwerpkeuze, los van transportversleuteling.

Eindverificatie

Een correcte implementatie moet aan vier waarneembare voorwaarden voldoen: de validatie van de rsyslog-configuratie moet succesvol zijn, de service moet actief blijven na een herstart, de collector moet de unieke testgebeurtenis ontvangen en het verzendlogboek mag geen TLS-vertrouwens- of peer-naamfouten bevatten. Zodra deze controles geslaagd zijn, moeten de vervaldatums van de certificaten en de afhankelijkheid van de externe collector worden gedocumenteerd, zodat toekomstig onderhoud de gecentraliseerde logging niet ongemerkt verstoort.