Inoltro sicuro dei log Syslog SLES con rsyslog e TLS reciproco

Per inoltrare in modo sicuro i log di sistema di SUSE Linux Enterprise Server (SLES), configurare rsyslog per inviare i messaggi tramite la porta TCP 6514 protetta da TLS, verificare il nome del certificato del collettore e confermare la consegna con un evento di test. SLES 15 SP7 ha ricevuto un aggiornamento facoltativo di rsyslog il 27 marzo 2026 che ha aggiunto un modulo TLS OpenSSL; la configurazione seguente utilizza deliberatamente il gtlsmodulo GnuTLS ( ) già esistente.

Questa procedura riguarda un mittente SLES 15 denominato sles01.example.nete un raccoglitore rsyslog denominato logs.example.net. Sostituisci entrambi i nomi e tutti i percorsi dei certificati con i tuoi valori. Utilizza TLS reciproco, quindi il raccoglitore autentica il mittente e viceversa.

1. Verificare rsyslog e il percorso di registrazione di SLES

Su entrambi gli host, installa il demone rsyslog e il relativo modulo GnuTLS dai repository SUSE a cui sei registrato. Le installazioni esistenti potrebbero già contenere il primo pacchetto.

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

Prima di aggiungere regole, rivedi /etc/rsyslog.confgli snippet esistenti /etc/rsyslog.d/. In particolare, disabilita qualsiasi *.* @@hostregola di inoltro non crittografata precedente per la stessa destinazione; altrimenti i messaggi potrebbero percorrere due percorsi, incluso uno senza TLS.

SLES utilizza systemd-journaldgli eventi del journal mentre rsyslog elabora gli input syslog. Verificare che gli eventi necessari raggiungano rsyslog tramite la configurazione di input esistente. SUSE documenta ForwardToSyslog=yesl' /etc/systemd/journald.confinoltro dal journal a syslog; controllare la propria implementazione prima di modificarla, poiché l'abilitazione separata dei lettori di journal può creare eventi duplicati. Questa procedura inoltra automaticamente i messaggi già elaborati da rsyslog, non tutti i file presenti /var/log.

2. Preparare certificati server e client attendibili

Utilizza un'autorità di certificazione (CA) controllata dall'organizzazione per emettere un certificato con il nome alternativo del soggetto DNS logs.example.netper il collettore e un certificato separato che identifichi sles01.example.netil mittente. Assicurati che i certificati siano validi per i rispettivi ruoli di server o client TLS e che entrambe le macchine si fidino della CA emittente. Segui la tua procedura PKI per la generazione e il rinnovo; non riutilizzare la stessa chiave privata su più host.

Copia i file appropriati tramite un canale sicuro approvato dall'amministratore. In questo esempio, entrambe le macchine utilizzano /etc/rsyslog.d/tls/ca.pem. Il raccoglitore dispone inoltre server-cert.pemdi e server-key.pem; il mittente dispone di client-cert.peme 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

Limita l'accesso ai certificati e alle chiavi all'identità del servizio rsyslog, ove necessario. Non esporre le chiavi private nei file di diagnostica, nella cronologia della shell, nei repository Git o nel flusso di log esportato. Verifica che il processo rsyslog possa leggere la propria chiave prima di riavviare il demone.

3. Abilitare un ricevitore TLS autenticato sul collettore

Su logs.example.net, aggiungi quanto segue come /etc/rsyslog.d/30-tls-listener.conf. Se imtcpè già caricato altrove, mantieni solo un'istruzione module-load. Il set di regole dedicato inserisce i messaggi ricevuti da remoto in un file separato invece di mescolarli con i messaggi del sistema locale.

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"Abilita TLS x509/namee PermittedPeerrifiuta i client privi di un'identità di certificato accettata. Il singolo nome consentito è intenzionale; estendere l'elenco dei peer approvati quando si aggiungono altri mittenti anziché indebolire l'autenticazione.

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

Eseguire i comandi del firewall solo se il raccoglitore utilizza firewalld. Limitare il traffico TCP/6514 in entrata alle reti di mittenti noti utilizzando il firewall dell'host o quello a monte; l'apertura della porta non sostituisce l'autenticazione tramite certificato. Verificare inoltre che nessun listener di testo in chiaro preesistente sia esposto involontariamente.

4. Aggiungere l'inoltro TLS e una coda delimitata a SLES

Su sles01.example.net, assicurarsi che la directory di lavoro di rsyslog esista e sia scrivibile dal servizio. La directory mostrata qui è a scopo illustrativo; mantenere una directory già configurata workDirectoryse il pacchetto di installazione ne fornisce una. Aggiungere questo frammento come /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"
)

Le impostazioni TLS autenticano il collettore prima dell'invio. La coda di azioni assistita da disco memorizza temporaneamente i messaggi durante brevi interruzioni e riprova un'azione di inoltro non riuscita, ma non è infinita né garantisce l'assenza totale di perdita di messaggi: lo spazio su disco disponibile, i limiti della coda, il comportamento di arresto del processo e lo stato di salute del ricevitore sono comunque fattori importanti. Verificare la directory di lavoro effettiva di rsyslog e crearla con i permessi appropriati prima di fare affidamento sul buffering su disco.

Convalida e riavvia il mittente:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Se la convalida della configurazione non riesce, non riavviare; correggere il primo errore segnalato. In un'implementazione rsyslog esistente, le direttive globali del certificato potrebbero influire su altre azioni TLS. Esaminare le altre azioni in uscita e utilizzare i parametri del certificato per azione supportati se richiedono credenziali diverse.

5. Verificare la ricezione e indagare su una stretta di mano fallita

Innanzitutto, verifica che il collettore sia in ascolto sulla porta TCP/6514 e che il mittente possa raggiungere l'host attraverso il firewall. Quindi, esegui il seguente comando sul mittente SLES:

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

Sul collettore, cercare il file di log remoto configurato:

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

Trovare il marcatore /var/log/remote-tls.logconferma che il percorso di inoltro a livello di applicazione ha funzionato per questo test. Non dimostra che tutti i file di log specifici dell'applicazione vengano raccolti. Per testare l'autenticazione in modo indipendente, utilizzare temporaneamente un certificato diverso e non attendibile o un nome peer non corrispondente in una finestra di manutenzione controllata e verificare che la connessione TLS fallisca; ripristinare immediatamente la configurazione originale.

Se l'indicatore non compare, seguire la procedura di risoluzione dei problemi in ordine:

• Nessun listener o connessione rifiutata: verificare systemctl status rsyslogle regole del firewall TCP/6514 e del collettore.
• Errore TLS o del certificato: confrontare i SAN del certificato con PermittedPeere StreamDriverPermittedPeers; verificare la catena CA, le date di scadenza, gli orologi di sistema e le autorizzazioni della chiave privata.
• Connesso ma senza eventi: verificare la presenza di input di journal/syslog duplicati o mancanti, azioni di inoltro sospese e capacità della coda del disco. Eseguire un controllo journalctl -u rsyslogsu entrambi gli host.

Il metodo segue la guida ufficiale alla registrazione del sistema SLES 15 SP7 , la guida al client rsyslog autenticato tramite certificato , il riferimento al listener imtcp e il riferimento all'inoltro omfwd . L'avviso di aggiornamento SUSE di marzo 2026 documenta l'aggiunta opzionale del modulo OpenSSL. Le configurazioni variano a seconda dei service pack di SLES, quindi è necessario convalidare la versione di rsyslog installata prima di applicare le modifiche in produzione.