Cum se exportă în siguranță jurnalele de sistem SLES către un server Syslog la distanță

Cea mai sigură metodă practică de a exporta jurnalele de sistem SUSE Linux Enterprise Server (SLES) către un colector syslog la distanță este să utilizați rsyslog prin TCP cu TLS, să validați certificatul colectorului după nume și să atribuiți acțiunii de redirecționare propria coadă. Syslog-ul UDP simplu este simplu, dar nu oferă confidențialitate sau autentificare peer. TCP simplu îmbunătățește comportamentul de livrare, dar lasă în continuare conținutul jurnalelor expus în tranzit.

Acest ghid utilizează driverul de flux de rețea GnuTLS ( gtls) și sintaxa modernă a acțiunilor rsyslog. Procedura este destinată sistemelor SLES 15 SP7, al căror Ghid de administrare a fost actualizat la 1 octombrie 2026. Verificați întotdeauna pachetele exacte și versiunea rsyslog de pe gazdă înainte de a copia o configurație ad litteram. Documentația rsyslog din amonte recomandă TCP cu TLS pentru implementări moderne și recomandă o coadă de acțiuni pentru redirecționarea TCP.

Referințe autorizate: documentația SUSE Linux Enterprise Server 15 SP7 , documentația rsyslog omfwd , configurarea clientului rsyslog TLS și RFC 5425: Maparea transportului TLS pentru Syslog .

Referință rapidă

Înainte de a configura redirecționarea

Aveți nevoie de numele de domeniu complet calificat al colectorului la distanță, portul TCP pe care îl ascultă și certificatul autorității de certificare (CA) care semnează certificatul colectorului. Pentru TLS mutual, aveți nevoie și de un certificat client și de o cheie privată pentru mașina SLES. Certificatul colectorului trebuie să fie valid pentru numele de gazdă pe care îl configurați în rsyslog, de preferință printr-un nume alternativ al subiectului (SAN). Nu rezolvați o nepotrivire de nume prin dezactivarea verificării certificatului.

Colectorul la distanță trebuie să fie deja configurat să accepte syslog TLS. Acest articol se concentrează pe expeditorul SLES, deoarece configurarea receptorului variază între rsyslog, syslog-ng, dispozitivele SIEM și serviciile de înregistrare în jurnal gestionate. Dacă un firewall separă sistemele, permiteți gazdei SLES să inițieze conexiuni TCP către colector pe portul configurat. O politică firewalld implicită cu stare nu necesită de obicei deschiderea unui port de intrare pe expeditorul SLES.

Pasul 1: Confirmați că rsyslog este instalat și identificați versiunea curentă

Începeți prin a verifica versiunea pachetului și a daemonului. Acest lucru previne confuziile atunci când exemplele mai vechi utilizează directive care nu sunt suportate de versiunea de pe serverul dumneavoastră.

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

Dacă rsyslog nu este instalat, instalați-l din repozitoriile SLES activate. Mențineți sistemul actualizat prin procesul normal de actualizare SUSE înainte de a expune o conexiune de jurnalizare de lungă durată.

Pasul 2: Instalați modulul GnuTLS rsyslog

Pe SLES, driverul de rețea TLS este inclus în pachet separat. Instalați modulul GnuTLS și păstrați pachetul de bază rsyslog prezent:

sudo zypper install rsyslog rsyslog-module-gtls

Puteți confirma că fișierele provin din pachetul așteptat cu rpm -ql rsyslog-module-gtls. Numele pachetelor sunt specifice distribuției, așa că nu copiați numele pachetelor din ghiduri orientate spre Debian sau RHEL.

Pasul 3: Plasați în siguranță acreditările CA și clientului

Folosiți certificate emise de organizația sau platforma dvs. de jurnalizare. Pentru un sistem de producție, evitați crearea unui nou CA privat pe gazda care trimite jurnalele. Un laborator poate utiliza un CA de testare, dar materialul de încredere pentru producție ar trebui să urmeze procesul PKI al organizației dvs.

Creați un director deținut de root, copiați fișierele și restricționați cheia privată. Înlocuiți numele de fișiere exemplu cu căile furnizate de echipa 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/*

Inspectați CA-ul și certificatul clientului în loc să acordați încredere numelor de fișiere:

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

Documentația clientului rsyslog TLS avertizează explicit că cheia privată a mașinii trebuie protejată. Dacă un alt utilizator poate citi cheia privată, utilizatorul respectiv poate să se dea drept clientul de înregistrare în jurnal.

Pasul 4: Configurați redirecționarea TLS cu verificarea numelui serverului

Creați un drop-in dedicat, cum ar fi /etc/rsyslog.d/60-remote-tls.conf. Păstrarea redirecționării la distanță separată de configurația furnizorului facilitează revizuirea și revenirea la configurație.

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"este important: alegerea unui driver compatibil TLS nu este suficientă în configurațiile în care modul este implicit TCP simplu. StreamDriverAuthMode="x509/name"apoi verifică certificatul la distanță și verifică dacă identitatea serverului se potrivește cu peer-ul permis. Folosiți numele exact al colectorului din certificat în loc de un wildcard larg ori de câte ori este practic.

Acțiunea de mai sus redirecționează fiecare mesaj care ajunge la ea. Dacă doriți doar anumite facilități sau priorități, adăugați un filtru înainte de acțiune. De exemplu, un mediu axat pe securitate poate redirecționa evenimentele de autentificare și daemon, păstrând în același timp local jurnalele de depanare a aplicațiilor cu volum mare. Filtrarea ar trebui să fie determinată de nevoile de retenție, răspuns la incidente și conformitate, mai degrabă decât de presupunerea generală că fiecare mesaj trebuie să părăsească gazda.

Pasul 5: Validare, repornire, trimitere eveniment test și verificare livrare

Validați configurația completă rsyslog înainte de a reporni serviciul. Aceasta este cea mai rapidă metodă de a detecta erorile de sintaxă și referințele lipsă la module:

sudo rsyslogd -N1

Dacă validarea reușește, reporniți rsyslog și trimiteți un mesaj de test unic:

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

În colector, căutați eticheta sles-tls-testși numele de gazdă al expeditorului. O apariție la distanță reușită dovedește că mesajul a ajuns la colector, dar nu dovedește în sine că verificarea certificatului a fost configurată corect. Verificarea mai puternică este să mențineți x509/nameactivată și să confirmați că nu există erori de handshake TLS sau de nume de peer în jurnalul serviciului rsyslog.

Dacă conexiunea eșuează, testați rezoluția DNS pentru logs.example.com, confirmați că TCP 6514 este accesibil, verificați datele de valabilitate ale certificatului și verificați dacă certificatul colectorului conține numele DNS așteptat. De asemenea, confirmați că colectorul are încredere în CA-ul care a emis certificatul client SLES atunci când este activat TLS reciproc.

Listă de verificare pentru depanare

• Conexiune refuzată: colectorul nu ascultă adresa/portul configurat sau un firewall respinge conexiunea.
• Expirare: rutarea, ACL-urile de rețea sau un firewall întrerup traficul în mod silențios.
• Verificarea certificatului a eșuat: fișierul CA este greșit, incomplet, a expirat sau lanțul de certificate al serverului este incomplet.
• Nepotrivire nume peer: numele target/ StreamDriverPermittedPeersnu corespunde cu identitatea certificatului colectorului.
• Permisiune refuzată asupra cheii: calea cheii sau permisiunile nu permit procesului rsyslog să citească fișierul în configurația serviciului SLES.
• Mesajele se opresc în timpul unei întreruperi: verificați designul și capacitatea cozii de acțiuni. Documentația omfwd din amonte recomandă în mod specific o coadă pentru redirecționarea TCP, astfel încât o destinație indisponibilă să nu blocheze procesarea normală.

Note de securitate ușor de ratat

Nu înlocuiți validarea certificatelor cu TLS anonim decât dacă înțelegeți pe deplin compromisul. Criptarea fără autentificarea serverului poate expune în continuare jurnalele unui atacator activ de tip man-in-the-middle. De asemenea, nu deschideți portul TCP 6514 de intrare pe expeditorul SLES doar pentru că destinația folosește acel port; redirecționarea este o conexiune client de ieșire.

Protejați cheile private ale clientului ca și credențiale, rotiți certificatele înainte de expirare și utilizați un nume de gazdă al colectorului care rămâne stabil în timpul modificărilor adresei IP. Dacă aveți nevoie de garanții de livrare mai puternice decât redirecționarea TCP/TLS normală, documentația rsyslog indică RELP ca alternativă concepută pentru livrare cu confirmare de primire. Aceasta este o alegere de design separată de criptarea transportului.

Verificare finală

O implementare corectă ar trebui să îndeplinească patru condiții observabile: validarea configurației rsyslog returnează cu succes, serviciul rămâne activ după repornire, colectorul primește evenimentul de test unic și jurnalul expeditorului nu afișează erori de încredere TLS sau de nume de peer. După ce aceste verificări sunt trecute, documentați datele de expirare a certificatelor și dependența colectorului la distanță, astfel încât mentenanța viitoare să nu întrerupă în mod silențios înregistrarea centralizată a datelor.