Archivi tag: rsyslog

CentOS 6 ed rsyslog: creare un sistema di log centralizzato per i dispositivi di rete

Networking, SO: Linux, , , , , , , , ,

Scenario

Diversi uffici periferici (in gergo branch office), connessi all’ufficio centrale (main office) mediante dei tunnel IPSec site-to-site dedicati (classici link VPN utilizzati per creare una intranet con topologia a stella).

Problema

Creare un sistema di log centralizzato per tutti i dispositivi di rete, compresi i router degli uffici periferici.

Soluzione

Utilizzare una Linux box (CentOS 6) con a bordo il demone che funge da syslog server, ovvero rsyslog.

syslog

Configurazione della Linux box e del syslog server

Per prima cosa occorre fare in modo che la nostra Linux box sia in grado di ricevere correttamente (sulla porta UDP 514) i log inoltrati dai dispositivi di rete. Per fare ciò è sufficiente creare la seguente regola di netfilter (ultilizzando iptables):

-A INPUT -m state --state NEW -m udp -p udp -s 192.168.0.0/16 --dport 514 -j ACCEPT

ed aggiungerla all’interno del file /etc/sysconfig/iptables, per poi lanciare un:

[root@linuxbox ~]# service iptables restart

in modo da rendere la suddetta regola operativa (da notare che 192.168.0.0/16 è la subnet classe B che raggruppa tutte le /24 utilizzate dai branch office).

Una volta fatto ciò è necessario aggiungere la seguente direttiva all’interno del file di configurazione rsyslog, ovvero /etc/rsyslog.conf:

$template CiscoVPN,"/var/log/cisco/system-%HOSTNAME%.log"

*.* -?CiscoVPN

e creare la dir di target in cui verranno salvati i log, ovvero /var/log/cisco:

[root@linuxbox ~]# mkdir -p /var/log/cisco

A questo punto possiamo riavviare rsyslog in modo da rendere effettive le suddette modifiche:

[root@linuxbox ~]# service rsyslog restart

Configurazione dei dispositivi di rete

Per semplicità mi soffermerò solo ed esclusivamente nella configurazione dei router (Cisco) dei branch office. Tale operazione consiste in 2 fasi: la definizione di una sorgente SNTP affidabile ed identica per tutti i network device (in modo da poter effettuare un’eventuale correlazione tra gli eventi) e la configurazione del syslog server target.

Per configurare la sorgente SNTP è sufficiente lanciare il comando:

Router(config)# sntp server <IP del server SNTP>

Ad esempio, se volessimo utilizzare come server SNTP ntp1.inrim.it, dovremmo digitare:

Router(config)# sntp server 193.204.114.232

Per quanto riguarda la configurazione del target dei log, è sufficiente lanciare i seguenti comandi:

Router(config)# service timestamps log
Router(config)# logging source-interface Vlan1
Router(config)# logging <IP del syslog server>

Il primo comando serve a fare in modo che il timestamp dell’evento venga aggiunto automaticamente alla entry del log; il secondo comando specifica l’interfaccia dalla quale i log devono essere inviati (essendo in VPN, l’interfaccia di riferimento è quella della LAN, in questo caso la Vlan 1);  l’ultimo comando specifica molto banalmente l’indirizzo IP del syslog server.

Infine, controlliamo che i log vengano popolati in real time, lanciando il comando:

[root@linuxbox ~] #tail -f /var/log/system-<hostname>.log

dove <hostname> è l’hostname del dispositivo di rete di cui volete consultare il file di log.

Se tutto funziona a dovere possiamo dire di aver finalmente realizzato il nostro sistema di log centralizzato.

A presto.

Monitorare rsyslogd mediante Nagios

Networking, , , , ,

Ho già trattato diversi argomenti in cui veniva discussa la corretta configurazione di un logserver basato su sitemi *nix. Ora vedremo come monitorare mediante nagios3 il demone che si occupa della raccolta dei log.

Nella fattispecie, il demone in questione è rsyslogd, evoluzione del più datato syslogd. Esso consente di salvare le informazioni inviate dai vari dispositivi di rete su di un apposito file creato all’occorrenza, in modo da tenere traccia degli eventi più rilevanti.

Ora, tale demone (per default) rimane in ascolto sulla porta 514 ed utilizza per il protocollo UDP per il trasporto. Ciò significa che non è previsto alcun meccanismo di SYN SYN/ACK ACK come invece avviene per il protocollo TCP (molto più affidabile ma allo stesso tempo molto più oneroso in termini di banda).

Detto ciò, vediamo come monitorare lo stato di tale servizio sfruttando nagios3. Per prima cosa scarichiamo questo PERL scrip.

nagios.gif

Successivamente salviamo il file appena scaricato nella directory /usr/lib/nagios/plugins e rinominiamolo in check_syslog:

nightfly@nightbox:/usr/lib/nagios/plugins$ sudo mv check_syslog_02.pl check_syslog

A questo punto rendiamo lo scrip eseguibile digitando:

nightfly@nightbox:/usr/lib/nagios/plugins$ sudo chmod +x check_syslog

Definiamo il comando attraverso il quale verificheremo il corretto funzionamento di rsyslogd. Per fare ciò occorre creare il file syslogd.cfg il cui contenuto dovrà essere:

# 'check_syslog' command definition
 define command{
         command_name    check_syslog
         command_line    /usr/lib/nagios/plugins/check_syslog -l '$HOSTADDRESS$' -f '$ARG1$'
         }

Posizioniamoci ora nella directory /etc/nagios3/conf.d ed editiamo il file di configurazione relativo al logserver aggiungendo il seguente servizio:

define service{
         use                             generic-service         ; Name of service template to use
         host_name                       localhost
         service_description             Rsyslog
                 check_command                   check_syslog!/var/log/syslog
         }

A questo punto occorre operare sui permessi di lettura/scrittura associati al file syslog. Per prima cosa posizioniamoci nella directory /var/log e lanciamo un ls -ila | grep syslog:

2097425 -rw-r-----  1 syslog      adm       171910 2011-03-21 11:54 syslog

Come possiamo notare il gruppo che ha la possibilita di accedere al file in lettura è adm. Aggiungiamo l’utente nagios al gruppo adm editando il file group presente nella dir /etc:

adm:x:4:nagios

Riavviamo nagios3:

nightfly@nightbox:/etc$ sudo service nagios3 restart

ed abbiamo finito.

A presto.