Archivi tag: event handler

auto_clean_zombies: event handler per Nagios in grado di ripulire il sistema dai processi zombie

In questo post ho illustrato il codice di uno scrip da me realizzato, in grado di ripulire il sistema dai processi zombie. Ora vedremo come fare ad integrare, sotto forma di event handler, il predetto scrip con Nagios. Per prima cosa è necessario creare l’event handler vero e proprio (che funge da wrapper), il quale richiamerà lo scrip clean_zombies in caso di necessità:

#!/bin/bash

case "$1" in
OK)
        ;;
WARNING)
        ;;
UNKNOWN)
        ;;
CRITICAL)
       case "$2" in
                SOFT)
                        case "$3" in
                        3)
                                echo -n "Cleaning zombie processes (3rd soft critical state)..."
                                usr/bin/sudo /root/scrips/clean_zombies
                                ;;
                                esac
                        ;;
                HARD)
                        echo -n "Cleaning zombie processes (3rd soft critical state)..."
                        usr/bin/sudo /root/scrips/clean_zombies
                        ;;
                esac
                ;;
        esac

exit 0

Successivamente occorre creare un apposito comando all’interno del file /etc/nagios/object/commands.cfg:

# 'auto_clean_zombies' command definition
define command {
        command_name      auto_clean_zombies
        command_line      /usr/lib64/nagios/plugins/eventhandlers/auto_clean_zombies $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$
        }

A questo punto possiamo assegnare l’event handler al servizio Total Processes definito nel file di configurazione dell’host per il quale si intende monitorare il numero dei processi:

define service{
        use                            local-service         
        host_name                      localhost
        service_descripion             Total Processes
        event_handler                  auto_clean_zombies
        check_command                  check_local_procs!280!400!RSZDT
        }

Inoltre, affinchè l’untente nagios possa lanciare il suddetto scrip senza che vi sia la necessità di inserire la password di autenticazione, occorre editare il file /etc/sudoers nel seguente modo:

nagios   ALL=NOPASSWD:   /root/scrips/clean_zombies

Ricarichiamo la configurazione di Nagios:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito. Alla prossima.

CentOS 6: monitorare le ACL del nostro router Cisco mediante Nagios ed snmptt

Durante gli ultimi mesi ho discusso ampiamente della configurazione di Nagios per la ricezione dei check passivi, quali trap SNMP o security alert. Adesso vi mostrerò come integrare le predette tipologie di allarmi in modo da riuscire a monitorare le ACL del nostro router Cisco.

Premessa

Esiste un modo più veloce per ottenere il monitoraggio delle ACL rispetto a quello che sto per illustrare. Esso consiste, fondamentalmente, nella configurazione di un syslog server (dotato dell’applicativo swatch per l’analisi in tempo reale dei file di log) a cui il nostro router Cisco dovrà puntare. Nel caso in cui un determinato pattern (ad esempio / denied /) dovesse essere matchato da swatch, quest’ultimo genererà un’opportuna notifica email da inoltrare all’amministratore di rete.

La mia configurazione, invece, si basa sulla logica seguente: il router Cisco genererà delle opportune trap SNMP segnalando ciò che avviene a livello di ACL (traffico consentito oppure negato). Esse verranno intercettate da snmptrapd e tradotte da snmptt, per poi essere elaborate dall’event handler submit_check_result e date in pasto a Nagios. Ho optato per tale configurazione poichè sulla mia linux box che funge da syslog server e da NMS sono già attivi sia snmptrapd che snmptt e quindi ho ritenuto conveniente sfruttarli piuttosto che mettere in funzione swatch.

nagiosConfigurazione del router Cisco

La configurazione del router Cisco si basa in 3 passaggi: settaggio della direttiva log per ciascuna entry che andrà a formare l’ACL da monitorare,  settaggio del syslog server a cui inviare le trap ed abilitazione di queste ultime.

Ad esempio, l’ACL di nostro interesse dovrà essere formata da entry di questo tipo:

access-list 102 deny ip host 255.255.255.255 any log

Inoltre, per definire la community string RO (read only) e l’indirizzo IP del server che si occuperà della ricezione delle trap, occorrerà digitare le seguenti direttive:

snmp-server host 192.168.1.1 keypublic
snmp-server community keypublic RO

mentre le trap potranno essere abilitate nel modo seguente:

snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps tty
snmp-server enable traps config-copy
snmp-server enable traps config
snmp-server enable traps resource-policy
snmp-server enable traps cpu threshold
snmp-server enable traps syslog
snmp-server enable traps firewall serverstatus

 Contenuto dello scrip submit_check_result

Secondo quanto già riportato in questo post, sappiamo che snmptt effettua una traduzione “statica” delle trap (mediante il comando snmpttconvertmib). Per tale motivo, affinchè si possa indurre Nagios a generare dei security alert solo dopo la ricezione di trap ben determinate, occorre modificare il codice sorgente relativo all’event handler submit_check_result. Di seguito riporto il contenuto dello scrip in questione da me customizzato:

 echocmd="/bin/echo"

CommandFile="/var/spool/nagios/cmd/nagios.cmd"

# get the current date/time in seconds since UNIX epoch
datetime=`date +%s`

# create the command line to add to the command file
if [[ $1 == "ip router" ]];then

        if [[ $4 =~ "denied igmp" ]];then

                exit 0;

        elif  [[ $4 =~ "denied" ]];then

                service="Router ACL Connection Denied";

                output="$4 | connection_denied=1"
                cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;router;$service;$3;$output";

        else

                cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;router;$2;$3;$4";

        fi

else

   cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;$1;$2;$3;$4";

fi

# append the command to the end of the command file
`$echocmd $cmdline >> $CommandFile`

Nella fattispecie, vengono dapprima identificate le trap che riguardano il router. Successivamente, nel caso in cui esse contengano il pattern igmp denied, lo scrip uscirà senza effettuare alcuna operazione. Tale “scrematura” è stata necessaria poichè il mio ISP effettua regolarmente del polling IGMP mediante il proprio querier 192.168.100.1 (per il servizio IPTV).

Nel caso in cui, invece, le trap dovessero contenere la stringa denied, la variabile cmdline verrà popolata con l’host name dell’oggetto monitorato da Nagios (per il quale si dovrà aggiornare lo stato del servizio che si occupa di tenere d’occhio le ACL). Nel mio caso tale host name è semplicemente router. Inoltre, l’output  verrà rimaneggiato in modo da tenere traccia delle performance data (graficizzandole mediante l’uso di pnp4nagios).

MIB da utilizzare e configurazione di Nagios

Per prima cosa occorre scaricare le MIB CISCO-SYSLOG-MIB e CISCO-SYSLOG-MIB-V1SMI dal repository FTP della Cisco, effettuandone il parsing mediante snmpttconvertmib.

Successivamente, su Nagios occorrerà definire per l’host name router il servizio che si occuperà di monitorare le ACL:

define service{
        use                             local-service
        host_name                       router
        service_descripion              Router ACL Connection Denied
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

Come ultimo step, a configurazione ultimata possiamo riavviare Nagios per rendere effettive le suddette modifiche:

[root@NMS ~]# service nagios reload

ed abbiamo finito.

A presto.

CentOS 6: configurare Nagios per la ricezione delle trap SNMP

In questo post abbiamo visto come configurare Nagios per la ricezione dei check passivi. In quest’altro post, invece, ho spiegato come configurare snmptrapd per la ricezione delle trap SNMP provenienti dai dispositivi monitorati. Adesso vedremo come ricevere su Nagios le suddette trap.

Ingredienti

Oltre a Nagios ed al demone che si occupa della ricezione delle trap (ovvero snmptrapd), è necessario installare sulla macchina che funge da NMS un demone in grado di tradurre le informazioni ricevute in qualcosa di più umanemente comprensibile. Infatti, la difficile interpretazione dei dati riportati dalle trap SNMP rappresenta, sicuramente, uno dei maggiori ostacoli che un sysadmin deve affrontare. Il demone che svolge tale mansione prende il nome di snmptt.

Logica di funzionamento

A grandi linee, il giro del fumo si può riassumere come segue: il dispositivo monitorato genera, di sua sponte, una trap SNMP per segnalare un qualche tipo di anomalia. Essa verrà, successivamente, inoltrata all’NMS, sul quale è attivo il demone snmptrapd (in ascolto sulla porta UDP/162), il quale si occuperà di “passare” tali informazioni ad snmptt. A questo punto, snmptt “tradurrà” i dati che gli sono stati inviati, provvedendo anche inoltrare il relativo output ad uno scrip Nagios (submit_check_result, che potete scaricare da qui) in grado di carpirne il contenuto ed utilizzare quest’ultimo per aggiornare lo stato del servizio dotato di check passivo. Quanto detto fin’ora è riportato (in modo schematico) nell’immagine sottostante.

snmptt

Configurazione di Nagios

Come al solito, il primo step per la realizzazione del nostro ambiente, consiste nella configurazione dell’NMS. Il servizio di monitoraggio delle trap potrà essere simile al seguente:

 define service{
        use                   local-service
        host_name             localhost
        service_descripion   SNMP TRAP Interceptor
        check_command         check_passive
        passive_checks_enabled  1
        active_checks_enabled   0
        is_volatile             1
        check_freshness         1
        freshness_threshold     600
        flap_detection_enabled  0
        }

mentre il comando check_passive presenterà la seguente struttura:

# 'check_passive' command definition
define command{
        command_name check_passive
        command_line $USER1$/check_dummy 2 "No alerts received in 600 seconds"
}

Configurazione di snmptrapd

Rispetto alla configurazione vista qui, l’unica variazione consiste nell’aggiunta delle seguente direttiva:

traphandle default /usr/sbin/snmptt

e la configurazione in todo dovrà essere simile alla seguente:

traphandle default /usr/sbin/snmptt

authCommunity log,execute,net keypublic
format1 %l-%m-%y %h:%j:%k from %A: %b %P %N %W %v\n
format2 %l-%m-%y %h:%j:%k from %A: %b %P %N %W %v\n

Installazione e configurazione di snmptt

Per installare il software in questione è sufficiente utilizzare yum:

[root@NMS ~]# yum install snmptt net-snmp-perl

Una volta installato, si può procedere con la sua configurazione mediante l’editing del file /etc/snmp/snmptt.ini. Ecco le modifiche da me apportate:

net_snmp_perl_enable = 1
log_system_enable = 1
log_system_file = /var/log/snmptt/snmpttsystem.log

A questo punto occorrerà procedere con la “traduzione” delle MIB SNMP. Le si può pensare come una sorta di DB testuale, in cui è presente una descrizione “human friendly” di alcuni OID, anche per ciò che concerne le trap.

Il software che svolge tale mansione prende il nome di snmpttconvertmib e si potranno convertire trap presenti nelle MIB lanciando il seguente comando:

[root@NMS ~]# for i in *MIB*;do snmpttconvertmib --in=/usr/share/snmp/mibs/$i --out=/etc/snmp/snmptt.conf  --exec='/usr/lib64/nagios/plugins/eventhandlers/submit_check_result $r "SNMP TRAP Interceptor" 1';done

dove i parametri passati a submit_check_result sono:

1) $r, ovvero l’hostname del dispositivo che ha generato la trap;

2) SNMP TRAP Interceptor, ovvero il nome del servizio di Nagios che deve essere aggiornato mediante check passivo;

3) 1, evvero l’exit code da girare all’NMS (che, in tal caso, corrisponderà a WARNING).

Le trap “tradotte” andranno a popolare il file /etc/snmp/snmptt.conf, le cui entry saranno simili alle seguenti:

EVENT ucdShutdown .1.3.6.1.4.1.2021.251.2 "Status Events" Normal
FORMAT This trap is sent when the agent terminates $*
EXEC /usr/lib64/nagios/plugins/eventhandlers/submit_check_result $r TRAP 1 "This trap is sent when the agent terminates $*"
SDESC
This trap is sent when the agent terminates
Variables:
EDESC

Prima di continuare, una piccola nota a margine: per ciò che concerne i dispositivi Cisco, vi consiglio di consultare questo sito (per l’indentificazione ed il download delle MIB) e quest’altro (per la traduzione degli OID).

Inoltre, affinchè lo scrip submit_check_result sia in grado di scrivere all’interno del file nagios.cmd (dove vengono inoltrati tutti i comandi esterni), è necessario sostituire la stringa:

CommandFile="/usr/local/nagios/var/rw/nagios.cmd"

con:

CommandFile="/var/spool/nagios/cmd/nagios.cmd"

A configurazione di snmptt ultimata, possiamo fare in modo che il demone in questione venga eseguito automaticamente al boot:

[root@NMS ~]# chkconfig snmptt on

ed avviarlo:

[root@NMS ~]# service snmptt start

Inoltre, riavviamo snmptrapd per rendere effettive le modifiche apportate in precedenza:

[root@NMS ~]# service snmptrapd restart

e ricarichiamo la configurazione di Nagios:

[root@NMS ~]# service nagios reload

 Test e troubleshooting

La prima cosa da fare per capire se snmptt stia funzionando correttamente consiste nell’abilitazione delle opzioni di debug (presenti all’interno di snmptt.ini). Le direttive coinvolte sono le seguenti:

DEBUGGING = 0
DEBUGGING_FILE = /var/log/snmptt/snmptt.debug

Inoltre, è possibile (e opportuno) inviare al nostro handler una trap di test, recante il seguente formato:

[root@NMS ~]# snmptrap -v 1 -c keypublic 127.0.0.1 '.1.3.6.1.6.3.1.1.5.3' '0.0.0.0' 6 33 '55' .1.3.6.1.6.3.1.1.5.3 s “teststring000”

Se la suddetta trap verrà opportunamente gestita da snmptt e dell’event handler di Nagios (submit_check_result), con il successivo aggiornamento del servizio lato NMS, vorrà dire che il nostro sistema sta funzionando come dovrebbe.

Per ora è tutto. Alla prossima.