Cum se creează un server de jurnal centralizat cu Rsyslog în CentOS/RHEL 7


Pentru ca administratorul de sistem să identifice sau să depaneze o problemă pe un sistem de server CentOS 7 sau RHEL 7, acesta trebuie să cunoască și să vadă evenimentele care au avut loc pe sistem într-un anumit perioadă de timp de la fișierele jurnal stocate în sistem în directorul /var/log.

Serverul syslog de pe o mașină Linux poate acționa ca punct central de monitorizare într-o rețea în care toate serverele, dispozitivele de rețea, routerele, comutatoarele și majoritatea serviciilor lor interne care generează jurnale, indiferent dacă sunt legate de o problemă internă specifică sau doar de mesaje informative, își pot trimite jurnalele. .

Pe un sistem CentOS/RHEL 7, demonul Rsyslog este serverul principal de jurnal preinstalat, urmat de Systemd Journal Daemon (journald).

Serverul Rsyslog este construit ca serviciu de arhitectură client/server și poate îndeplini ambele roluri simultan. Poate rula ca server și poate colecta toate jurnalele transmise de alte dispozitive din rețea sau poate rula ca client prin trimiterea tuturor evenimentelor interne ale sistemului înregistrate la un server syslog de la distanță.

Când rsyslog este configurat ca client, jurnalele pot fi stocate local în fișiere din sistemul de fișiere local sau pot fi trimise de la distanță, mai degrabă decât să le scrieți în fișierele stocate pe mașină sau să scrieți fișiere jurnal de evenimente local și să le trimiteți la un server syslog la distanță la acelasi timp.

Serverul Syslog operează orice mesaj de jurnal folosind următoarea schemă:

type (facility).priority (severity)  destination(where to send the log)

A. Datele facilității sau tip sunt reprezentate de procesele interne ale sistemului care generează mesajele. În Linux, procesele interne (facilitățile) care generează jurnalele sunt standardizate după cum urmează:

  • auth = mesaje generate de procesele de autentificare (autentificare).
  • cron= mesaje generate de procesele programate (crontab).
  • daemon = mesaje generate de demoni (servicii interne).
  • kernel = mesaje generate de kernel-ul Linux însuși.
  • mail = mesaje generate de un server de e-mail.
  • syslog = mesaje generate de demonul rsyslog însuși.
  • lpr = mesaje generate de imprimante locale sau de un server de imprimare.
  • local0 – local7 = mesaje personalizate definite de un administrator (local7 este de obicei atribuit pentru Cisco sau Windows).

B. Nivelurile de prioritate (severitate) sunt, de asemenea, standardizate. Fiecare prioritate este atribuită cu o abreviere standard și un număr așa cum este descris mai jos. A 7-a prioritate este nivelul superior al tuturor.

  • emerg = Urgență – 0
  • alerta = Alerte – 1
  • err = Erori – 3
  • warn = Avertismente – 4
  • notificare = Notificare – 5
  • informații = Informații – 6
  • depanare = Depanare – 7

Cuvinte cheie speciale Rsyslog:

  • *=toate facilitățile sau prioritățile
  • niciuna=facilitățile nu au priorități acordate De exemplu: mail.none

C. A treia parte pentru schema syslog este reprezentată de directiva destinație . Daemonul Rsyslog poate trimite mesaje de jurnal pentru a fi scrise într-un fișier din sistemul de fișiere local (mai ales într-un fișier din directorul /var/log/) sau pentru a fi transmise către un alt proces local sau pentru a fi trimise către un consola locală a utilizatorului (la stdout) sau trimiteți mesajul către un server syslog de la distanță prin protocolul TCP/UDP sau chiar aruncați mesajul la /dev/null.

Pentru a configura CentOS/RHEL 7 ca server de jurnal central, mai întâi trebuie să verificăm și să ne asigurăm că partiția /var în care sunt înregistrate toate fișierele jurnal este suficient de mare ( minim câțiva GB) pentru a putea stoca toate fișierele jurnal care vor fi trimise de alte dispozitive. Este o decizie bună să utilizați o unitate separată (LVM, RAID) pentru a monta directorul /var/log/.

Cerințe

  1. Procedura de instalare CentOS 7.3
  2. RHEL 7.3 Procedura de instalare

Cum se configurează Rsyslog pe serverul CentOS/RHEL 7

1. În mod implicit, serviciul Rsyslog este instalat automat și ar trebui să ruleze în CentOS/RHEL 7. Pentru a verifica dacă demonul este pornit în sistem, lansați următoarea comandă cu privilegii root.

systemctl status rsyslog.service

Dacă serviciul nu rulează implicit, executați comanda de mai jos pentru a porni demonul rsyslog.

systemctl start rsyslog.service

2. Dacă pachetul rsyslog nu este instalat pe sistemul pe care intenționați să-l utilizați ca server de înregistrare centralizată, lansați următoarea comandă pentru a instala pachetul rsyslog.

yum install rsyslog

3. Primul pas pe care trebuie să-l facem pe sistem pentru a configura demonul rsyslog ca server de jurnal centralizat, astfel încât să poată primi mesaje de jurnal pentru clienții externi, este să deschidem și să editam, folosind editorul de text preferat, fișierul de configurare principal de la /etc/rsyslog.conf, așa cum este prezentat în fragmentul de mai jos.

vi /etc/rsyslog.conf

În fișierul principal de configurare rsyslog, căutați și decomentați următoarele rânduri (eliminați hashtag-ul # semnul de la începutul liniei) pentru a oferi recepția de transport UDP către serverul Rsyslog prin 514 port. UDP este protocolul standard utilizat pentru transmiterea jurnalelor de către Rsyslog.

$ModLoad imudp 
$UDPServerRun 514

4. Protocolul UDP nu are supraîncărcarea TCP, ceea ce îl face mai rapid pentru transmiterea datelor decât protocolul TCP. Pe de altă parte, protocolul UDP nu asigură fiabilitatea datelor transmise.

Cu toate acestea, dacă trebuie să utilizați protocolul TCP pentru recepția jurnalului, trebuie să căutați și să decomentați următoarele rânduri din fișierul /etc/rsyslog.conf pentru a configura demonul Rsyslog pentru a lega și asculta un socket TCP pe 514 port. Prizele de ascultare TCP și UDP pentru recepție pot fi configurate simultan pe un server Rsyslog.

$ModLoad imtcp 
$InputTCPServerRun 514 

5. La pasul următor, nu închideți încă fișierul, creați un șablon nou care va fi folosit pentru primirea mesajelor de la distanță. Acest șablon va instrui serverul local Rsyslog unde să salveze mesajele primite trimise de clienții rețelei syslog. Șablonul trebuie adăugat înainte de începutul blocului DIRECTIVE GLOBALE, așa cum este ilustrat în fragmentul de mai jos.

$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" 
. ?RemoteLogs & ~

Directiva de mai sus $template RemoteLogs instruiește demonul Rsyslog să colecteze și să scrie toate mesajele de jurnal primite în fișiere distincte, pe baza numelui mașinii client și a facilitatii (aplicația) client la distanță care a generat mesajele pe baza proprietățile definite sunt prezente în configurația șablonului: %HOSTNAME% și %PROGRAMNAME%.

Toate aceste fișiere jurnal vor fi scrise în sistemul de fișiere local într-un fișier dedicat numit după numele de gazdă al mașinii client și stocat în directorul /var/log/.

Regula de redirecționare & ~ indică serverului local Rsyslog să oprească procesarea mesajului jurnal primit și să renunțe la mesaje (nu să le scrie în fișierele jurnal interne).

Numele RemoteLogs este un nume arbitrar dat acestei directive șablon. Puteți folosi orice nume găsiți cel mai potrivit pentru șablonul dvs.

Pentru a scrie toate mesajele primite de la clienți într-un singur fișier jurnal numit după adresa IP a clientului la distanță, fără a filtra facilitatea care a generat mesajul, utilizați fragmentul de mai jos.

$template FromIp,"/var/log/%FROMHOST-IP%.log" 
. ?FromIp & ~ 

Un alt exemplu de șablon în care toate mesajele cu semnalizare facilitate de autentificare vor fi înregistrate într-un șablon numit „TmplAuth“.

$template TmplAuth, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" 
authpriv.*   ?TmplAuth

Mai jos este un extras dintr-o definiție a șablonului de pe serverul Rsyslog 7:

template(name="TmplMsg" type="string"
         string="/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
        )

Extrasul șablonului de mai sus poate fi scris și ca:

template(name="TmplMsg" type="list") {
    constant(value="/var/log/remote/msg/")
    property(name="hostname")
    constant(value="/")
    property(name="programname" SecurePath="replace")
    constant(value=".log")
    }

Pentru a scrie șabloane complexe Rsyslog, citiți manualul fișierului de configurare Rsyslog lansând comanda man rsyslog.conf sau consultați documentația online Rsyslog.

6. După ce ați editat fișierul de configurare Rsyslog cu propriile setări, așa cum este explicat mai sus, reporniți demonul Rsyslog pentru a aplica modificările lansând următoarea comandă:

service rsyslog restart

7. Până acum, serverul Rsyslog ar trebui configurat să acționeze ca un server de jurnal centralizat și să înregistreze mesajele de la clienții syslog. Pentru a verifica socket-urile de rețea Rsyslog, rulați comanda netstat cu privilegii de rădăcină și utilizați grep pentru a filtra șirul rsyslog.

netstat -tulpn | grep rsyslog 

8. Dacă aveți SELinux activat în CentOS/RHEL 7, lansați următoarea comandă pentru a configura SELinux pentru a permite traficul rsyslog în funcție de tipul de soclu de rețea.

semanage -a -t syslogd_port_t -p udp 514
semanage -a -t syslogd_port_t -p tcp 514 

9. Dacă firewall-ul este activat și activ, rulați comanda de mai jos pentru a adăuga regulile necesare pentru deschiderea porturilor rsyslog în Firewalld.

firewall-cmd --permanent --add-port=514/tcp
firewall-cmd --permanent --add-port=514/udp
firewall-cmd –reload

Asta e tot! Rsyslog este acum configurat în modul server și poate centraliza jurnalele de la clienți la distanță. În articolul următor, vom vedea cum să configurați clientul Rsyslog pe serverul CentOS/RHEL 7.

Folosind serverul Rsyslog ca punct central de monitorizare pentru mesajele jurnal de la distanță, puteți inspecta fișierele jurnal și puteți observa starea de sănătate a clienților sau puteți depana problemele clientului mai ușor atunci când sistemele se blochează sau sunt supuse unui fel de atac.