Redirecționare securizată SLES Syslog cu rsyslog și Mutual TLS

Pentru a transmite în siguranță jurnalele de sistem SUSE Linux Enterprise Server (SLES), configurați rsyslog să trimită mesaje prin portul TCP 6514 protejat prin TLS, verificați numele certificatului colectorului și confirmați livrarea cu un eveniment de test. SLES 15 SP7 a primit o actualizare opțională rsyslog pe 27 martie 2026 care a adăugat un modul OpenSSL TLS; configurația de mai jos utilizează gtlsîn schimb în mod deliberat modulul GnuTLS ( ) consacrat.

Această procedură acoperă un expeditor SLES 15 numit sles01.example.netși un colector rsyslog numit logs.example.net. Înlocuiți ambele nume și toate căile de certificate cu propriile valori. Folosește TLS mutual, astfel încât colectorul autentifică expeditorul, precum și expeditorul care autentifică colectorul.

1. Verificați rsyslog și calea de înregistrare în jurnal SLES

Pe ambele gazde, instalați daemonul rsyslog și modulul său GnuTLS din depozitele SUSE înregistrate. Instalările existente pot conține deja primul pachet.

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

Verificați /etc/rsyslog.conffragmentele existente /etc/rsyslog.d/înainte de a adăuga reguli. În special, dezactivați orice *.* @@hostregulă de redirecționare necriptată mai veche pentru aceeași destinație; altfel, mesajele pot urma două rute, inclusiv una fără TLS.

SLES folosește systemd-journaldjurnalul pentru evenimente în timp ce rsyslog procesează intrările syslog. Confirmați că evenimentele de care aveți nevoie ajung la rsyslog prin configurația de intrare existentă. Documentele SUSE ForwardToSyslog=yessunt utilizate /etc/systemd/journald.confpentru redirecționarea de la jurnal la syslog; verificați implementarea înainte de a o modifica, deoarece activarea separată a cititorilor de jurnal poate crea evenimente duplicate. Această procedură redirecționează mesajele deja procesate de rsyslog, nu fiecare fișier /var/logautomat.

2. Pregătiți certificate de server și client de încredere

Folosiți o autoritate de certificare (CA) controlată de organizație pentru a emite un certificat cu numele alternativ al subiectului DNS logs.example.netpentru colector și un certificat separat care identifică sles01.example.netexpeditorul. Asigurați-vă că certificatele sunt valide pentru rolurile lor de server sau client TLS și că ambele mașini au încredere în CA emitentă. Urmați procesul PKI pentru generare și reînnoire; nu reutilizați o cheie privată pe mai multe gazde.

Copiați fișierele corespunzătoare printr-un canal securizat aprobat de administrator. În acest exemplu, ambele mașini utilizează /etc/rsyslog.d/tls/ca.pem. Colectorul are în plus server-cert.pemși server-key.pem; expeditorul are client-cert.pemși 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

Restricționați accesul la certificat și cheie la identitatea serviciului rsyslog, acolo unde este necesar. Nu expuneți cheile private în diagnosticare, istoricul shell-ului, depozitele Git sau fluxul de jurnal exportat. Confirmați că procesul rsyslog își poate citi cheia înainte de a reporni daemonul.

3. Activați un receptor TLS autentificat pe colector

Pe logs.example.net, adăugați următoarele instrucțiuni ca /etc/rsyslog.d/30-tls-listener.conf. Dacă imtcpeste deja încărcat în altă parte, păstrați o singură instrucțiune de încărcare a modulelor. Setul de reguli dedicat plasează mesajele primite de la distanță într-un fișier separat, în loc să le amestece cu mesajele sistemului local.

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"activează TLS, în timp ce x509/namerespinge PermittedPeerclienții fără o identitate certificată acceptată. Numele unic permis este intenționat; extinde lista de peer-i aprobați atunci când adaugi alți expeditori în loc să slăbești autentificarea.

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

Executați comenzile firewall numai dacă colectorul folosește firewalld. Restricționați TCP/6514 de intrare la rețelele de expeditori cunoscuți folosind gazda sau firewall-ul din amonte; deschiderea portului nu înlocuiește autentificarea cu certificat. De asemenea, verificați dacă niciun ascultător de text clar preexistent nu este expus în mod neintenționat.

4. Adăugați redirecționarea TLS și o coadă delimitată la SLES

Activat sles01.example.net, asigurați-vă că directorul de lucru rsyslog există și că serviciul poate scrie în el. Directorul afișat aici este ilustrativ; păstrați unul deja configurat workDirectorydacă configurația dvs. pachet oferă unul. Adăugați acest fragment ca /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"
)

Setările TLS autentifică colectorul înainte de trimitere. Coada de acțiuni asistată de disc stochează mesajele în timpul întreruperilor scurte și reîncearcă o acțiune de redirecționare eșuată, dar nu este infinită și nu garantează împotriva pierderii complete de mesaje: spațiul disponibil pe disc, limitele cozii, comportamentul de închidere a proceselor și starea receptorului contează în continuare. Verificați directorul de lucru efectiv al rsyslog și creați-l cu proprietatea corespunzătoare înainte de a vă baza pe stocarea temporară pe disc.

Validați și reporniți expeditorul:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Dacă validarea configurației eșuează, nu reporniți; corectați prima eroare raportată. Într-o implementare rsyslog existentă, directivele globale de certificat pot afecta alte acțiuni TLS. Examinați alte acțiuni de ieșire și utilizați parametrii de certificat per acțiune acceptați dacă necesită acreditări diferite.

5. Verificați chitanța și investigați o strângere de mână eșuată

Mai întâi confirmați că colectorul ascultă pe TCP/6514 și că expeditorul poate ajunge la gazdă prin firewall. Apoi executați următoarea comandă pe expeditorul SLES:

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

În colector, căutați fișierul jurnal la distanță configurat:

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

Găsirea markerului în /var/log/remote-tls.logconfirmă faptul că calea de redirecționare la nivel de aplicație a funcționat pentru acest test. Nu dovedește că fiecare fișier jurnal specific aplicației este colectat. Pentru a testa autentificarea independent, utilizați temporar un certificat diferit, nede încredere, sau un nume de peer nepotrivit într-o fereastră de întreținere controlată și confirmați că conexiunea TLS eșuează; restaurați imediat configurația originală.

Dacă markerul nu apare, urmați ordinea erorilor:

• Niciun ascultător sau conexiune refuzată: verificați systemctl status rsyslogregulile TCP/6514 și ale firewall-ului colectorului.
• TLS sau eșec al certificatului: comparați SAN-urile de certificate cu PermittedPeerși StreamDriverPermittedPeers; verificați lanțul CA, datele de expirare, ceasurile de sistem și permisiunile cheii private.
• Conectat, dar fără evenimente: căutați intrări de jurnal/syslog duplicate sau lipsă, acțiuni de redirecționare suspendate și capacitatea cozii de disc. Verificați journalctl -u rsyslogpe ambele gazde.

Metoda respectă ghidul oficial de înregistrare a înregistrărilor de sistem SLES 15 SP7 , ghidul clientului autentificat cu certificat rsyslog , referința ascultătorului imtcp și referința de redirecționare omfwd . Notificarea de actualizare SUSE din martie 2026 documentează adăugarea opțională a modulului OpenSSL. Configurațiile variază în funcție de pachetele service pack SLES, așadar validați-le pe versiunea rsyslog instalată înainte de a aplica modificările în producție.