Come creare un server di log centralizzato con Rsyslog in CentOS / RHEL 7

Affinché l’amministratore di sistema possa identificare o risolvere un problema su un sistema server CentOS 7 o RHEL 7, deve conoscere e visualizzare gli eventi accaduti sul sistema in un determinato periodo di tempo dai file di log memorizzati nel sistema nella directory /var/log.

Il server syslog su una macchina Linux può fungere da punto di monitoraggio centrale su una rete in cui tutti i server, i dispositivi di rete, i router, gli switch e la maggior parte dei loro servizi interni che generano log, sia relativi a specifici problemi interni o solo messaggi informativi possono inviare i loro log.

Su un sistema CentOS/RHEL 7, Rsyslog daemon è il server di log principale preinstallato, seguito da Systemd Journal Daemon (journald).

Rsyslog server in build come servizio di architettura client / server e può raggiungere entrambi i ruoli simultanei. Può essere eseguito come server e raccogliere tutti i log trasmessi da altri dispositivi nella rete o può essere eseguito come client inviando tutti gli eventi di sistema interni registrati a un server syslog di endpoint remoto.

Quando rsyslog è configurato come client, i log possono essere memorizzati localmente in file sul filesystem locale o possono essere inviati in remoto piuttosto che scriverli in file memorizzati sulla macchina o scrivere file di log eventi localmente e inviarli a un server syslog remoto allo stesso tempo.

Syslog server gestisce qualsiasi messaggio di log utilizzando lo schema seguente:

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

A. I dati della struttura o del tipo sono rappresentati dai processi di sistema interni che generano i messaggi. In Linux i processi interni (strutture) che generano log sono standardizzati come segue:

  • auth = messaggi generati dai processi di autenticazione (login).
  • cron= messaggi generati da processi pianificati (crontab).
  • daemon = messaggi generati dai demoni (servizi interni).
  • kernel = messaggi generati dal Kernel Linux stesso.
  • mail = messaggi generati da un server di posta.
  • syslog = messaggi generati dal demone rsyslog stesso.
  • lpr = messaggi generati da stampanti locali o da un server di stampa.
  • local0-local7 = messaggi personalizzati definiti da un amministratore (local7 viene solitamente assegnato per Cisco o Windows).

B. Anche i livelli di priorità (gravità) sono standardizzati. Ogni priorità viene assegnata con un’abbreviazione standard e un numero come descritto di seguito. La 7a priorità è il livello più alto di tutti.

  • emerg = Emergenza – 0
  • avvisi = Avvisi – 1
  • err = Errori – 3
  • warn = Avvisi – 4
  • avviso = Notifica – 5
  • info = Informazioni – 6
  • debug = Debug– 7

Speciale Rsyslog parole chiave:

  • * = tutte le strutture o le priorità
  • nessuno = i servizi non hanno dato priorità ad Esempio: mail.none

C. La terza parte dello schema syslog è rappresentata dalla direttiva destination. Il demone Rsyslog può inviare messaggi di log da scrivere in un file sul filesystem locale (per lo più in un file nella directory /var/log/) o da trasmettere a un altro processo locale o da inviare a una console utente locale (a stdout), o inviare il messaggio a un server syslog remoto tramite protocollo TCP/UDP, o anche scartare il messaggio a /dev/null.

Per configurare CentOS/RHEL 7 come server di log centrale, per prima cosa dobbiamo controllare e assicurarci che la partizione /var in cui sono registrati tutti i file di log sia abbastanza grande (un minimo di pochi GB) per poter memorizzare tutti i file di log che verranno inviati da altri dispositivi. È una buona decisione usare un’unità separata (LVM, RAID) per montare la directory /var/log/.

Requisiti

  1. CentOS 7.3 Procedura di Installazione
  2. RHEL 7.3 Procedura di Installazione

Come Configurare Rsyslog in CentOS/RHEL 7 Server

1. Per impostazione predefinita, il servizio Rsyslog viene installato automaticamente e dovrebbe essere in esecuzione in CentOS / RHEL 7. Per verificare se il demone è stato avviato nel sistema, eseguire il seguente comando con i privilegi di root.

# systemctl status rsyslog.service
Controllare Rsyslog Service
Controllare Rsyslog Service

Se il servizio non è in esecuzione per impostazione predefinita, eseguire il comando seguente per avviare il demone rsyslog.

# systemctl start rsyslog.service

2. Se il pacchetto rsyslog non è installato sul sistema che si intende utilizzare come server di registrazione centralizzato, eseguire il seguente comando per installare il pacchetto rsyslog.

# yum install rsyslog

3. Il primo passo che dobbiamo fare sul sistema per configurare rsyslog daemon come server di log centralizzato, in modo che possa ricevere messaggi di log per client esterni, è aprire e modificare, usando il tuo editor di testo preferito, il file di configurazione principale da /etc/rsyslog.conf, come presentato nel seguente estratto.

# vi /etc/rsyslog.conf

Nel file di configurazione principale rsyslog, cerca e decommenta le seguenti righe (rimuovi il segno hashtag # all’inizio della riga) per fornire la ricezione del trasporto UDP al server Rsyslog tramite la porta 514. UDP è il protocollo standard utilizzato per la trasmissione di log da Rsyslog.

$ModLoad imudp $UDPServerRun 514
Configurazione del server Rsyslog
Configurazione del server Rsyslog

4. Il protocollo UDP non ha l’overhead TCP, che lo rende più veloce per la trasmissione dei dati rispetto al protocollo TCP. D’altra parte, il protocollo UDP non garantisce l’affidabilità dei dati trasmessi.

Tuttavia, se è necessario utilizzare il protocollo TCP per la ricezione dei log, è necessario cercare e rimuovere il commento delle seguenti righe da /etc/rsyslog.file conf per configurare il demone Rsyslog per associare e ascoltare un socket TCP sulla porta 514. I socket di ascolto TCP e UDP per la ricezione possono essere configurati contemporaneamente su un server Rsyslog.

$ModLoad imtcp $InputTCPServerRun 514 

5. Nel passaggio successivo, non chiudere ancora il file, creare un nuovo modello che verrà utilizzato per la ricezione di messaggi remoti. Questo modello indica al server Rsyslog locale dove salvare i messaggi ricevuti inviati dai client di rete syslog. Il modello deve essere aggiunto prima dell’inizio del blocco DIRETTIVE GLOBALI come illustrato nell’estratto seguente.

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

Al di sopra di $modello RemoteLogs direttiva indica Rsyslog demone per raccogliere e scrivere tutti i log ricevuti messaggi di file distinti, in base al nome del computer client e client remoto facility (applicazione) che ha generato i messaggi in base all’proprietà definite dall’presenta nella configurazione del modello: %HOSTNAME% e %NOMEPROGRAMMA%.

Tutti questi file di log verranno scritti nel filesystem locale in un file dedicato chiamato dopo il nome host della macchina client e memorizzati nella directory /var/log/.

La regola di reindirizzamento & ~ indica al server Rsyslog locale di interrompere ulteriormente l’elaborazione del messaggio di log ricevuto e scartare i messaggi (non scriverli in file di log interni).

Il nome RemoteLogs è un nome arbitrario assegnato a questa direttiva modello. È possibile utilizzare qualsiasi nome si può trovare più adatto per il modello.

Per scrivere tutti i messaggi ricevuti dai client in un singolo file di registro che prende il nome dall’indirizzo IP del client remoto, senza filtrare la funzione che ha generato il messaggio, utilizzare l’estratto seguente.

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

Un altro esempio di modello in cui tutti i messaggi con auth facility flag verranno registrati in un modello denominato “TmplAuth”.

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

Di seguito è riportato un estratto di una definizione di modello dal server Rsyslog 7:

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

Il modello di cui sopra estratto può anche essere scritto come:

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

Per scrivere modelli Rsyslog complessi, leggere il manuale del file di configurazione Rsyslog emettendo man rsyslog.conf comando o consultare Rsyslog documentazione online.

6. Dopo aver modificato il file di configurazione Rsyslog con le proprie impostazioni come spiegato sopra, riavviare il demone Rsyslog per applicare le modifiche emettendo il seguente comando:

# service rsyslog restart

7. A questo punto, Rsyslog server dovrebbe essere configurato per agire come un server di log centralizzato e registrare i messaggi dai client syslog. Per verificare i socket di rete Rsyslog, eseguire il comando netstat con privilegi di root e utilizzare grep per filtrare la stringa rsyslog.

# netstat -tulpn | grep rsyslog 
Verifica presa di rete Rsyslog
Verifica presa di rete Rsyslog

8. Se SELinux è abilitato in CentOS / RHEL 7, eseguire il seguente comando per configurare SELinux in modo da consentire il traffico rsyslog in base al tipo di socket di rete.

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

9. Se il firewall è abilitato e attivo, eseguire il comando seguente per aggiungere le regole necessarie per l’apertura delle porte rsyslog in Firewalld.

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

Questo è tutto! Rsyslog è ora configurato in modalità server e può centralizzare i log da client remoti. Nel prossimo articolo, vedremo come configurare il client Rsyslog sul server CentOS / RHEL 7.

Utilizzando Rsyslog server come punto di monitoraggio centrale per i messaggi di log remoti è possibile ispezionare i file di log e osservare lo stato di salute dei client o eseguire il debug dei problemi del client più facilmente quando i sistemi si bloccano o sono sotto qualche tipo di attacco.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.