Operations Management Suite configurazione dell’agente Linux come Syslog Collector gateway verso Log Analitycs

 Syslog è un protocollo che consente il trasporto di messaggi di log, e di informazione più in generale, è nato all’inizio degli anni ’80 tuttavia è stato definito come RFC dall’IETF soltanto vent’anni dopo. In questo lasso di tempo diverse implementazioni hanno generato differenti “servizi”, la prima  RFC che ne documenta il funzionamento è la 3164  mentre una sua evoluzione è descritta dalla RFC 5424

I servizi più comuni che lo utilizzano in ambienti *NIX hanno nome SYSLOG, SYLOG-NG, RSYSLOG ma molti altri prodotti, sia commerciali, che rilasciati sotto licenza Open Source lo implementano al fine di permettere la raccolta di eventi generati da molteplici apparati e sistemi.

Ormai non è affatto raro trovare apparati di rete, firewall, telecamere ma anche prodotti legati al mondo industriale, come ad esempio PLC e controllori di processo più in generale, che implementano il protocollo Syslog al fine di inviare ad un unico collettore i propri eventi di funzionamento.

Struttura del Sylog

Inizialmente implementato sul protocollo UDP, in porta 514 (recenti implementazioni lo rendono disponibile anche in TCP) il pacchetto trasporta le informazioni suddivise in:

  • Facility
  • Severity
  • Hostname
  • Timestamp
  • Message

Possiamo considerare le Facility come le entità che generano il messaggio di Syslog e ognuna di queste definisce poi una Severity che gradua la “gravità” dell’evento stesso.

Le Facility sono codificate da un numero e si riferiscono a componenti diverse del sistema; kernel, demoni di sistema, autenticazione ecc.

Cod. Facility
0 Kernel messages
1 User-level messages
2 Mail system
3 System daemons
4 Security/authorization messages
5 Messages generated internally by Syslogd
6 Line printer subsystem
7 Network news subsystem
8 UUCP subsystem
9 Clock daemon
10 Security/authorization messages
11 FTP daemon
12 NTP subsystem
13 Log audit
14 Log alert
15 Clock daemon
16 local0
17 local1
18 local2
19 local3
20 local4
21 local5
22 local6
23 local7

Le severity seguono la stessa struttura e sono:

Cod. Severity
0 Emergency: System is unusable.
1 Alert: Action must be taken immediately.
2 Critical: Critical conditions.
3 Error: Error conditions.
4 Warning: Warning conditions.
5 Notice: Normal but significant condition.
6 Informational: Informational messages.
7 Debug: Debug-level messages.

Un pacchetto Syslog potrà avere per ogni Facility un codice di Severity differente, l’informazione dell’hostname che lo ha generato,l’ora di generazione ed in aggiunta una descrizione ulteriore relativa all’evento.

Syslog è quindi un “mezzo di trasporto” che viene utilizzato da differenti mittenti che classificano i propri messaggi secondo la codifica delle Facility, dipende quindi da ognuno dei servizi che generano messaggi log classificare i propri secondo la struttura del protocollo stesso.

Ad esempio SSHD di default utilizza la facility AUTHPRIV per i suoi messaggi relativi al logon degli utenti e quindi all’interno della configurazione del syslog, relativamente a questa facility, è indicato il percorso del file dove vengono salvati gli eventi.

Configurazione del Servizio Rsyslog su Linux

Su sistemi Linux ( RH,Centos, Oracle Linux) normalmente il demone rsyslog ha il file di configurazione in /etc/rsyslog.conf e la struttura di default prevede il salvataggio in locale dei messaggi che vengono generati dal sistema

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don’t log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* -/var/log/maillog
# Log cron stuff
cron.* /var/log/cron
# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.

 

authpriv.* istruisce syslog a salvare tutte le severity di questa facility nel file /var/log/secure, se volessimo differenziare le varie severity in percorsi distinti dovremmo dichiararlo per ognuna

authpriv.info                     /var/log/file1

authpriv.notice                /var/log/file2

ecc.

 

Redirezione dei messaggi verso un collettore in rete

Come detto in precedenza il protocollo syslog è in grado di trasportare i vari messaggi verso un collettore, ossia un ulteriore syslog che riceve ed archivia.

Per configurare un sistema in modo che invii tutti o solamente alcuni messaggi verso un altro server è sufficiente nel file .conf dichiarare l’host anziché un file locale come visto sopra.

La facility AUTHPRIV archiviata verso l’host 192.168.0.1 diventerà così:

authpriv.*                                           @192.168.0.1

mentre se l’host di destinazione invece che in UDP fosse configurato per ricevere in TCP dovremmo impostare

authpriv.*                                           @@192.168.0.1

ed ancora, se la porta di destinazione dell’host ricevente non fosse la standard 514 ma supponiamo la 25224 TCP dovremmo dichiarare

authpriv.*                                           @@192.168.0.1:25224

Operations Management Suite Agent in Linux

L’agente OMS per Linux quando installato sul sistema si comporta come un ricevitore di messaggi Syslog che poi redirige verso il servizio di log analizer in cloud. Il file di configurazione è in:

/etc/opt/microsoft/omsagent/conf/omsagent.conf

e per impostazione predefinita riceve i messaggi che sono generati localmente al sistema secondo questa configurazione:

<source>
type syslog
port 25224
bind 127.0.0.1
protocol_type udp
tag oms.syslog
</source>

Questo richiede (se si vogliono redirigere eventi Syslog verso il Log Analyzer) che il file di configurazione del Syslog venga modificato in modo da reindirizzare gli eventi sulla porta ed indirizzo su cui è configurato l’agente stesso.

Secondo quanto visto sopra, se volessimo inviare ad OMS i messaggi relativi a SSH configurato per utilizzare la Facility AUTHPRIV, dovremo impostare il file conf di Syslog in questo modo

authpriv.*                                           @127.0.0.1:25224

Modificando ulteriormente la configurazione dell’agente OMS, è possibile fare sì che questo diventi a sua volta un gateway di messaggi raccolti da vari Syslog verso il servizio di Log Analyzer di OMS, impostando omsagent.conf in questo modo:

<source>
type syslog
port 25224
bind 192.168.0.1   ( ip del sistema )
protocol_type udp
tag oms.syslog
</source>

e configurando i vari sitemi ad inviare i messaggi verso l’agente, otterremo il risultato di avere un gateway unico verso OMS senza dover installare ulteriori agenti.

Chiaramente così facendo si perde la possibilità, offerta dall’installazione diretta dell’agente sul sistema, di avere a disposizione ulteriori dati come ad esempio valori di occupazione dischi, ram, cpu etc.

 

20160916-oms-agnt-lnx-1

report ottenuto eseguendo il monitoraggio degli accessi in SSH su sistemi linux con le configurazioni descritte sopra

Problemi riscontrati

Durante la configurazione di alcuni sistemi (abbastanza datati) con demone Syslog, non era possibile cambiare la porta di destinazione sia TCP che UDP

 

Riferimenti

OMS agent su GitHub

Portale OMS esecuzione di query

OMS agent considerazioni generali

 

 

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...