How to Export SLES System Logs to a Remote Syslog Server Securely

The safest practical way to export SUSE Linux Enterprise Server (SLES) system logs to a remote syslog collector is to use rsyslog over TCP with TLS, validate the collector certificate by name, and give the forwarding action its own queue. Plain UDP syslog is simple, but it does not provide confidentiality or peer authentication. Plain TCP improves delivery behavior but still leaves log contents exposed in transit.

This guide uses the GnuTLS network stream driver (gtls) and modern rsyslog action syntax. The procedure is aimed at SLES 15 SP7 systems, whose Administration Guide was updated on October 1, 2026. Always check the exact packages and rsyslog version on your host before copying a configuration verbatim. The upstream rsyslog documentation recommends TCP with TLS for modern deployments and recommends an action queue for TCP forwarding.

Authoritative references: SUSE Linux Enterprise Server 15 SP7 documentation, rsyslog omfwd documentation, rsyslog TLS client setup, and RFC 5425: TLS Transport Mapping for Syslog.

Quick reference

Before you configure forwarding

You need the fully qualified domain name of the remote collector, the TCP port it listens on, and the certificate authority (CA) certificate that signs the collector certificate. For mutual TLS, you also need a client certificate and private key for the SLES machine. The collector certificate must be valid for the hostname you configure in rsyslog, preferably through a Subject Alternative Name (SAN). Do not solve a name mismatch by disabling certificate verification.

The remote collector must already be configured to accept TLS syslog. This article focuses on the SLES sender because receiver setup varies between rsyslog, syslog-ng, SIEM appliances, and managed logging services. If a firewall separates the systems, allow the SLES host to initiate TCP connections to the collector on the configured port. A default stateful firewalld policy usually does not require opening an inbound port on the SLES sender.

Step 1: Confirm rsyslog is installed and identify the current build

Inizia controllando la versione del pacchetto e del demone. Questo evita confusione quando gli esempi più vecchi utilizzano direttive non supportate dalla build sul tuo server.

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

Se rsyslog non è installato, installalo dai repository SLES abilitati. Mantieni il sistema aggiornato tramite la normale procedura di aggiornamento di SUSE prima di esporre una connessione di logging a lungo termine.

Passaggio 2: Installare il modulo rsyslog di GnuTLS

Su SLES, il driver di rete TLS è distribuito separatamente. Installa il modulo GnuTLS e mantieni presente il pacchetto base rsyslog:

sudo zypper install rsyslog rsyslog-module-gtls

È possibile confermare che i file provengono dal pacchetto previsto con rpm -ql rsyslog-module-gtls. I nomi dei pacchetti sono specifici della distribuzione, quindi non copiare i nomi dei pacchetti da guide orientate a Debian o RHEL.

Passaggio 3: Conservare in un luogo sicuro le credenziali CA e del client.

Utilizzate certificati rilasciati dalla vostra organizzazione o dalla piattaforma di logging. Per un sistema di produzione, evitate di creare una nuova CA privata sull'host che invia i log. Un ambiente di test può utilizzare una CA di prova, ma il materiale di fiducia per l'ambiente di produzione deve seguire il processo PKI della vostra organizzazione.

Crea una directory di proprietà dell'utente root, copia i file e limita l'accesso alla chiave privata. Sostituisci i nomi dei file di esempio con i percorsi forniti dal tuo team 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/*

Esaminate l'autorità di certificazione (CA) e il certificato client anziché fidarvi dei nomi dei file:

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

La documentazione del client TLS rsyslog avverte esplicitamente che la chiave privata della macchina deve essere protetta. Se un altro utente è in grado di leggere la chiave privata, potrebbe essere in grado di impersonare il client di logging.

Passaggio 4: Configurare l'inoltro TLS con verifica del nome del server

Crea un drop-in dedicato, ad esempio /etc/rsyslog.d/60-remote-tls.conf. Mantenere l'inoltro remoto separato dalla configurazione del fornitore semplifica la revisione e il ripristino.

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"È importante: la sola scelta di un driver compatibile con TLS non è sufficiente nelle configurazioni in cui la modalità predefinita è TCP semplice. StreamDriverAuthMode="x509/name"Successivamente, verifica il certificato remoto e controlla che l'identità del server corrisponda al peer autorizzato. Utilizzare il nome esatto del collettore nel certificato anziché un carattere jolly generico, ove possibile.

L'azione descritta sopra inoltra tutti i messaggi che la raggiungono. Se si desidera inoltrare solo determinate funzionalità o priorità, è necessario aggiungere un filtro prima dell'azione. Ad esempio, un ambiente incentrato sulla sicurezza potrebbe inoltrare gli eventi di autenticazione e dei daemon, mantenendo localmente i log di debug delle applicazioni ad alto volume. Il filtraggio dovrebbe essere guidato dalle esigenze di conservazione, risposta agli incidenti e conformità, piuttosto che dal presupposto generalizzato che ogni messaggio debba lasciare l'host.

Passaggio 5: Convalida, riavvia, invia un evento di prova e verifica la consegna

Prima di riavviare il servizio, verifica la configurazione completa di rsyslog. Questo è il modo più rapido per individuare errori di sintassi e riferimenti a moduli mancanti.

sudo rsyslogd -N1

Se la convalida ha esito positivo, riavvia rsyslog e invia un messaggio di prova univoco:

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

Sul collettore, cerca il tag sles-tls-teste il nome host del mittente. Un'apparizione remota riuscita dimostra che il messaggio ha raggiunto il collettore, ma di per sé non dimostra che la verifica del certificato sia stata configurata correttamente. Un controllo più rigoroso consiste nel mantenere la x509/nameverifica abilitata e confermare che non vi siano errori di handshake TLS o di peer-name nel log del servizio rsyslog.

Se la connessione fallisce, verifica la risoluzione DNS per logs.example.com, conferma che TCP 6514 sia raggiungibile, controlla le date di validità dei certificati e verifica che il certificato del collettore contenga il nome DNS previsto. Verifica inoltre che il collettore si fidi dell'autorità di certificazione (CA) che ha emesso il certificato client SLES quando è abilitato il TLS reciproco.

Lista di controllo per la risoluzione dei problemi

• Connessione rifiutata: il collettore non è in ascolto sull'indirizzo/porta configurato oppure un firewall sta bloccando la connessione.
• Timeout: il routing, gli ACL di rete o un firewall stanno bloccando silenziosamente il traffico.
• Verifica del certificato non riuscita: il file CA è errato, incompleto, scaduto oppure la catena di certificati del server è incompleta.
• Mancata corrispondenza del nome del peer: il nome target/ StreamDriverPermittedPeersnon corrisponde all'identità del certificato del collettore.
• Permesso negato sulla chiave: il percorso della chiave o i permessi non consentono al processo rsyslog di leggere il file nella configurazione del servizio SLES.
• I messaggi si interrompono durante un'interruzione: rivedere la progettazione e la capacità della coda di azioni. La documentazione di omfwd a monte raccomanda specificamente una coda per l'inoltro TCP in modo che una destinazione non disponibile non blocchi la normale elaborazione.

Note sulla sicurezza che è facile non notare

Non sostituire la convalida del certificato con TLS anonimo a meno che tu non ne comprenda appieno i compromessi. La crittografia senza autenticazione del server può comunque esporre i log a un attacco man-in-the-middle attivo. Allo stesso modo, non aprire la porta TCP 6514 in entrata sul mittente SLES solo perché la destinazione utilizza tale porta; l'inoltro è una connessione client in uscita.

Proteggete le chiavi private dei client come credenziali, ruotate i certificati prima della loro scadenza e utilizzate un nome host del collettore che rimanga stabile anche in caso di modifiche all'indirizzo IP. Se avete bisogno di garanzie di consegna più solide rispetto al normale inoltro TCP/TLS, la documentazione di rsyslog indica RELP come alternativa progettata per la consegna con conferma. Si tratta di una scelta progettuale distinta dalla crittografia del trasporto.

Elaborazione finale

Una corretta implementazione deve soddisfare quattro condizioni osservabili: la convalida della configurazione di rsyslog deve avere esito positivo, il servizio deve rimanere attivo dopo il riavvio, il collector deve ricevere l'evento di test univoco e il log del mittente non deve mostrare errori di attendibilità TLS o di peer-name. Una volta superati questi controlli, è necessario documentare le date di scadenza dei certificati e la dipendenza dal collector remoto, in modo che la manutenzione futura non interrompa silenziosamente la registrazione centralizzata.