Archivi tag: snmpd

Configurazione del demone snmpd su CentOS 6

Utilizzare il protocollo SNMP per il monitoraggio dei dispositivi di rete è sempre una buona scelta, tenendo bene a mente, però, che le versioni 1 e 2 non prevedono cifratura della community string e quindi sono vulnerabili ad eventiali attacchi MITM. Inoltre, in determinate circostanze, tale protocollo può essere impiegato anche per il monitoraggio delle macchine *nix, soprattutto per ciò che concerne lo stato delle interfacce di rete ed il loro throughput.

snmpInstallazione e configurazione di snmpd

Vediamo adesso come configurare il demone snmpd su una macchina CentOS 6.

Per prima cosa occorre installare i seguenti pacchetti tramite yum:

[root@server ~]# yum install net-snmp net-snmp-utils

A questo punto passiamo alla configurazione del demone vera e propria, editando il file /etc/snmp/snmp.conf. 

Definiamo, dapprima, le utenze ed i gruppi, mediante le seguenti direttive:

com2sec local      localhost        secret
com2sec mynetwork  192.168.1.0/24 secret

group local      v2c        local
group mynetwork  v2c        mynetwork

In particolare, mediante la keyword com2sec stiamo definendo l’utente local, il cui IP/hostname sorgente dovrà essere localhost e la cui community string dovrà essere secret. Discorso analogo vale per l’utente mynetwork.

Invece, per ciò che concerne la definizione dei gruppi, la keyword da utilizzare è group, seguita dal nome del gruppo, dalla versione del protocollo SNMP (v2c) e dal nome degli utenti che ne fanno parte (local nel primo caso e mynetwork nel secondo).

Successivamente è necessario abilitare l’intera alberatura degli OID, mediante la seguente direttiva:

view all    included  .1                               80

Infine, passiamo alla definizione delle ACL per i gruppi appena creati:

#               context sec.model sec.level prefix   read  write notif
access  local     ""      any       noauth   exact   all   none none
access  mynetwork ""      any       noauth   exact   all   none none

dove la prima riga indica il significato di ciascun campo utilizzato dopo la keyword access ed il gruppo a cui l’ACL si riferisce. Dalla suddetta configurazione è facile notare come entrambi i gruppi (local e mynetwork) abbiano solo la possibilità di effettuare GET SNMP (read) ma non SET (write).

Per completezza, è possibile editare dei campi facoltativi quali syslocation e syscontact:

syslocation Italy server.vostrodominio.com
syscontact Nome Cognome <vostro.indirizzo@email.it>

Riavviamo snmpd per rendere effettive le suddette modifiche:

[root@server ~]# service snmpd restart

ed effettuiamo una query di prova, avvalendoci del tool snmpwalk:

[root@server ~]# snmpwalk -v 2c -c secret localhost

Se otterremo in output l’intera alberatura SNMP supportata dalla macchina significa che il demone sta funzionando come dovrebbe.

 Configurazione di Nagios

Per fare in modo che il nostro NMS sia in grado di monitorare lo stato ed il throughput delle interfacce di rete, occorre definire i seguenti comandi all’interno del file /etc/nagios/objects/commands.cfg:

# 'check_snmp_if_status' command definition
define command{
        command_name    check_snmp_if_status
        command_line    $USER1$/check_snmp -H $HOSTADDRESS$ -C $ARG1$ -P $ARG2$ -o $ARG3$ -r $ARG4$
        }

# 'check_local_mrtgtraf' command definition
define command{
        command_name    check_local_mrtgtraf
        command_line    $USER1$/check_mrtgtraf -F "$ARG1$" -a "$ARG2$" -w "$ARG3$" -c "$ARG4$" -a "$ARG5$"
        }

ed i seguenti servizi all’interno del file di configurazione associato alla macchina da monitorare:

define service{
        use                             local-service         ; Name of service template to use
        host_name                       localhost
        service_descripion             WAN Interface eth0 Operational Status
        check_command                   check_snmp_if_status!secret!IF-MIB::ifOperStatus.2!1
        }

define service{
        use                             local-service         ; Name of service template to use
        host_name                       localhost
        service_descripion             LAN Interface eth1 Operational Status
        check_command                   check_snmp_if_status!secret!2c!IF-MIB::ifOperStatus.3!1
        }

define service{
        use                             local-service   ; Name of service template to use
        host_name                       localhost
        service_descripion             WAN Interface eth0 Bandwidth Usage
        check_command                   check_local_mrtgtraf!/var/www/mrtg/localhost_2.log!AVG!100000000,200000000!110000000,120000000!10
        }

define service{
        use                             local-service   ; Name of service template to use
        host_name                       localhost
        service_descripion             LAN Interface eth1 Bandwidth Usage
        check_command                   check_local_mrtgtraf!/var/www/mrtg/localhost_3.log!AVG!100000000,200000000!110000000,120000000!10
        }

Nella fattispecie, il monitoraggio del throughput viene realizzato mediante il plugin check_mrtgtraf, il cui scopo è quello di analizzare i file di log generati da MRTG (vedi questo post per ulteriori dettagli).

Ricarichiamo la configurazione di Nagios per rendere effettive le suddette modifiche:

[root@server ~]# service nagios reload

ed abbiamo finito.

Alla prossima.

Mettere in ascolto snmpd su un’interfaccia specifica

Recentemente ho riscontrato diverse grane con il demone snmpd installato su una macchina CentoOS 5.

snmpLogo.jpg

Durante le operazioni di troubleshooting ho deciso di mettere in ascolto il demone in questione su una specifica interfaccia, avendo a che fare con un host dual-homed. Per la precisione, tale host presentava due interfacce di rete più una loopback, ovvero:

eth0 IP 10.0.0.1

eth1 IP 192.168.2.1

lo IP 127.0.0.1

Dove la eth1 è utilizzata per l’heartbeat del cluster.

Lanciando un netstat -ano | grep :161 ottenevo il seguente output:

udp        0      0 0.0.0.0:161                 0.0.0.0:*                               off (0.00/0/0)

Ciò significava che il demone stava in ascolto su tutte le interfacce. Ad ulteriore riprova di ciò lanciavo un snmpwalk -v2c -c publickey dapprima diretto verso l’IP dell’eth0, poi verso l’IP dell’eth1 ed infine verso l’IP della loopback. In tutti casi alla query era seguita una risposta.

Bene, decidevo quindi che l’snmpd doveva rimanere in ascolto solo sull’IP dell’eth0. Mi posizionavo dunque nella directory /etc/init.d ed accedevo al file snmpd mediante un editor di testo:

 [nightfly@linuxbox ~]# cd /etc/init.d
 [nightfly@linuxbox init.d]# nano snmpd

Nella fattispecie, la riga di mio interesse era la seguente:

OPTIONS="-LS4d -Lf /dev/null -p /var/run/snmpd.pid -a"

Che ho modificato nel seguente modo:

OPTIONS="-LS4d -Lf /dev/null -p /var/run/snmpd.pid 10.0.0.1 -a"

Successivamente, riavviavo il demone snmp mediante il comando:

[nightfly@linuxbox init.d]# service snmpd restart

e verificavo che fosse effettivamente attivo lanciando il comando:

[nightfly@linuxbox init.d]# service snmpd status

ottenendo come output:

snmpd (pid  2499) is running...

Tutto sembrava funzionare alla grande. Verificavo infine che il demone fosse in ascolto solo sull’indirizzo 10.0.0.1:

udp        0      10.0.0.1:161                 0.0.0.0:*                               off (0.00/0/0)


Con mio grande piacere constatavo che finalmente snmpd stava in ascolto su una sola interfaccia, eliminando il problema dei continui restart dello stesso.

A presto.