Il blog sull'informatica

L'uso di un buon timeserver rappresenta la prima regola per ottenere dei log affidabili e soprattutto privi di eventuali inconsistenze. Inoltre, grazie ad esso, è possibile sincronizzare la data e l'ora sui vari dispositivi di rete, in modo da non dover necessariamente ricorrere ad un settaggio manuale di tali parametri.

Vediamo adesso come definire un timeserver su di un router Cisco SOHO 77, su di un firewall Cisco PIX 501 e su una macchina linux.

NTP su Cisco SOHO 77

Entriamo nella modalità di configurazione del nostro router:

SOHO77# conf t

e successivamente digitiamo il comando:

SOHO77(config)# sntp server <IP del server NTP>

In questo caso ho utilizzato come server NTP ntp.ubuntu.com, il cui indirizzo IP è 91.189.94.4

Adesso definiamo la timezone:

SOHO77(config)# clock timezone UTC +1

Come potete notare dal comando precedente, ho utilizzato la timezone UTC+1 poichè attualmente in Italia è in vigore l'ora legale.

Controlliamo che tutto sia andato a buon fine digitando il comando:

SOHO77(config)# sh clock

ed infine salviamo la configurazione:

SOHO77(config)# copy run start

NTP su Linux

Passiamo adesso all'installazione di un timeserver sulla nostra macchina linux.

Per fare ciò è sufficiente digitare:

nightfly@nightbox:~$ sudo apt-get install ntp

Ad installazione completata editiamo il file di configurazione relativo ad ntpd, ovvero il demone che funge da timeserver:

nightfly@nightbox:~$ sudo nano /etc/ntp.conf

Inseriamo i seguenti hostname:

# You do need to talk to an NTP server or two (or three).
server ntp.ubuntu.com
server ntp1.inrim.it
server ntp2.inrim.it

Salviamo il file e riavviamo ntpd:

nightfly@nightbox:~$ sudo service ntp restart

NTP su Cisco PIX 501

Bene, ora non ci resta che configurare un server NTP sul nostro firewall. Per fare ciò occorre seguire questi step:

PIX501# conf t

PIX501(config)# ntp server <IP della nostra macchina linux su cui gira ntpd> source inside

PIX501(config)# clock timezone UTC +1

Inoltre, è necessario definire un'ACL apposita sul firewall in questione in modo da consentire il traffico udp sulla porta 123. Ciò si rende necessario poichè il server NTP interno (presente sulla macchina linux) deve poter ricevere gli aggiornamenti da quello esterno.

PIX501(config)# access-list inbound permit udp host 91.189.94.4 host <IP del server NTP interno> eq 123

Controlliamo che tutto sia andato a buon fine digitando:

PIX501# sh clock

ed anche:

PIX501# sh ntp status

il cui output dovrebbe essere simile al seguente:

Clock is synchronized, stratum 4, reference is <IP del server NTP interno>
nominal freq is 99.9967 Hz, actual freq is 99.9966 Hz, precision is 2**6
reference time is d1161f31.f0ef3448 (14:18:41.941 UTC Mon Feb 28 2011)
clock offset is 3.5382 msec, root delay is 78.16 msec
root dispersion is 1386.23 msec, peer dispersion is 880.07 msec

ed infine salviamo la configurazione con un write mem.

Adesso i nostri dispositivi dovrebbero essere sincronizzati alla perfezione con i server NTP di riferimento.

A presto.

Qualche giorno fa ho avuto la necessità di installare un antivirus su una macchina Windows Server 2003 R2. Poichè non ero provvisto di un antivirus per ambienti server, sono andato alla ricerca di un qualche software gratuito atto allo scopo.

Dopo una breve "surfata" su Google, la scelta è ricaduta su ClamWin Antivirus. Tale antivirus (nato inizialmente dal progetto open source ClamAV) mette a disposizione del sysadmin tutta una serie di feature non indifferenti, tra cui un database delle firme costantemente aggiornato e la possibilità di scansionare anche la memoria volatile (RAM) alla ricerca di processi malevoli.

Unica pecca: l'impossibilità di riconoscere i virus all'apertura dei file infetti (limitazione facilmente aggirabile schedulando delle scansioni giornaliere) e l'assenza delle scansioni relative alle email, se non mediante un'impostazione particolare che consente di controllare gli allegati della posta elettronica scaricata attraverso Outlook.

Però, tutto sommato, i vantaggi offerti dal software in questione sono di gran lunga superiori alle sue limitazioni.

Per completezza riporto qualche screenshot.

A presto.

Recentemente ho avuto a che fare con uno scenario piuttosto complesso, in cui gli utenti della LAN riescono a navigare sul Web grazie all'intermediazione di un proxy, nella fattispecie di Squid.

Ora, per facilitare la vita ai net admin, esiste un tool particolare che si integra alla perfezione con Squid e permette di analizzare il traffico generato da ciascun utente, in modo da poter osservare eventuali comportamenti ambigui e monitorare le loro attività sul Web. Tale software prende il nome di sarg, acronimo di Squid Analysis Report Generator.

Fin qui tutto chiaro, peccato però che i vari utenti si autentichino al proxy sfruttando NTLM e che il proxy identifichi gli spazi presenti negli username con la notazione ASCII, ovvero con %20. Quindi, nel momento in cui clicco su un link generato da sarg, del tipo:

nome%20cognome

il server apache che mi risponde interpreta il %20 come uno spazio, ragion per cui anzichè provare ad aprirmi il link:

http://proxy.dominio.com/sarg/nome%20cognome

cercherà di visualizzare il link

http://proxy.dominio.com/sarg/nome cognome

rispondendomi picche. Come fare dunque per risolvere tale problematica? Semplice, sfruttando il mod_rewrite messo a disposizione da Apache.

In particolare, tale feature consente di modificare al volo le URL richieste dall'utente, permettendo la sostituzione del %20 con un backslash, il carattere di escape , il quale serve proprio ad indicare al Web server che il %20 va interpretato in modo letterale e non come uno spazio.

Ma passiamo ai fatti. Per prima cosa identifichiamo la directory in cui è installato sarg, che per la distro CentoOS 5.0 è /var/www/sarg.

Posizioniamoci ora nella directory relativa al file di configurazione di apache, ovvero /etc/httpd/conf ed apriamo tale file di configurazione (httpd.conf) in scrittura:

[root@proxy conf]# vi httpd.conf

Verifichiamo che sia presente la direttiva:

LoadModule rewrite_module modules/mod_rewrite.so

e che non sia commentata.

Adesso inseriamo le seguenti direttive per la directory in cui si trova sarg:

<Directory "/var/www/sarg">

Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all

</Directory>

In realtà, quello che ci interessa è abilitare l'ovverride per la directory di sarg, in modo da consentire il corretto funzionamento del mod_rewrite.

Posizioniamoci adesso nella dir relativa a sarg e creiamo il file .htaccess:

[root@proxyint sarg]# vi .htaccess

e successivamente inseriamo all'interno del file le seguenti direttive:

RewriteEngine On

RewriteRule ([^ ]+) ([^ ]+) ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2%20$3%20$4 [R=301,L]

RewriteRule ([^ ]+) ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2%20$3 [R=301,L]

RewriteRule ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2 [R=301,L]

Adesso verifichiamo che il mod_rewrite funzioni correttamente. Per fare ciò creiamo una directory all'interno di /var/www/sarg e chiamiamola pro%20va:

[root@proxyint sarg]# mkdir pro%20va

Infine, proviamo ad accedere a tale directory mediante il nostro browser, digitando nella barra degli indirizzi la seguente URL:

http://proxy.dominio.com/sarg/pro%20va

Se il server Web vi risponde con un errore 404 (page not found), vuol dire che il mod_rewrite non sta funzionando. Viceversa, se la directory pro%20va è vuota ed il browser vi risponde con la pagina Index of /sarg/pro%20va, vuol dire che tutto sta funzionando alla perfezione (noterete anche la presenza nella URL del backslash codificato in ASCII, ovvero %25).

Da questo momento in poi, ogni volta che proverete ad accedere alle statistiche generate da sarg, verrete correttamente reindirizzati alla pagina che state cercando.

A presto.

Recentemente mi è arrivata un'email di un tizio che non riusciva a rimuovere una variabile di sessione. In particolare, tale variabile rimaneva attiva nonostante la chiamata alla funzione unset(),effettuata nel modo seguente:

unset($_SESSION['variabile']);

Analizzando il codice, ho subito identificato il problema, ovvero la chiusura della sessione con un session_write_close() prima ancora di svuotare la variabile incriminata.

Ergo, la soluzione consiste nel riaprire la sessione, svuotare la variabile e richiudere la sessione immediatamente:

session_start();

unset($_SESSION['variabile']);

session_write_close();

See ya.

Qualsiasi firewall che si rispetti, oltre a dover filtrare il traffico secondo le regole definite dall'utente, deve mettere a disposizione un buon meccanismo di logging. In tal senso, iptables rientra a pieno titolo tra i firewall degni nota.

In particolare, il firewall in questione consente di loggare il traffico mediante rsyslogd, variante del celeberrimo syslogd, ovvero il demone *nix che si occupa del salvataggio dei log. Ma vediamo come realizzare il logging attraverso iptables.

Per prima cosa, dobbiamo decidere cosa loggare. Potremmo infatti "registrare" tutto il traffico che attraversa il firewall, oppure concentrarci esclusivamente sul traffico droppato. Personalmente ritengo che, per le reti di piccola dimensione, la seconda scelta sia sicuramente la migliore.

Ora, poichè iptables interpreta le regole seguendo una logica top-down, affinchè il traffico possa essere loggato è necessario fare in modo che i pacchetti vengano registrati immediatamente prima di essere scartati.

Quindi, il giusto ordine delle rule dovrebbe essere il seguente:

iptables -A INPUT -s 10.0.0.0/8 -i eth1 -j LOG --log-prefix "Spoofed traffic detected: " --log-level 4
iptables -A FORWARD -s 10.0.0.0/8 -i eth1 -j LOG --log-prefix "Spoofed traffic detected: " --log-level 4

iptables -A INPUT -s 10.0.0.0/8 -i eth1 -j DROP
iptables -A FORWARD -s 10.0.0.0/8 -i eth1 -j DROP

Come potete notare, prima ho loggato il traffico spoofato e solo dopo ho scartato i pacchetti incriminati. Inoltre, alcuni parametri interessanti per il logging che ho utilizzato nelle regole precedenti sono:

--log-prefix, che ci permette di identificare più facilmente i log relativi ai pacchetti droppati dal firewall (il prefisso può essere costituito da un massimo di 29 caratteri);

--log-level, che ci consente di definire la "pericolosità" degli eventi registrati dal firewall.

Nella fattispecie, i log level utilizzati da rsyslogd sono i seguenti:

level    verbose     explanation
0         emerg       system is unusable
1         alert          action must be taken immediately
2         crit            the system is in a critical condition
3         err            there is an error condition
4         warning    there is a warning condition
5         notice       a normal but significant condition
6         info          a purely informational message
7        debug       messages generated to debug the application

Detto ciò, per il logging dei pacchetti droppati da iptables ho utilizzato un livello 4, ovvero warning.

Creiamo ora il file di log vero e proprio, in cui verranno salvati gli eventi intercettati dal firewall:

nightfly@nightbox:~$ sudo touch /var/log/iptables.log

Infine, modifichiamo il file di configurazione di rsyslogd:

nightfly@nightbox:~$ sudo nano /etc/rsyslog.d/50-default.conf

ed inseriamo la seguente stringa:

kern.warning                 /var/log/iptables.log

da posizionare subito prima di

kern.*                          -/var/log/kern.log

Riavviamo rsyslogd digitando:

nightfly@nightbox:~$ sudo service rsyslog restart

ed il gioco è fatto.

A presto.

Ieri mi sono cimentato in un pò di sano trobuleshooting sulla mia rete. Guardando i comandi messi a disposizione dalla CLI del PIX ho notato la presenza di un comando interessantissimo, ovvero capture. In pratica, mediante tale comando è possibile catturare il traffico diretto ad una delle interfacce del PIX, semplicemente digitando:

PIX501# capture <nome della capture> interface <nome dell'interfaccia>

Quindi, se ad esempio volessi sniffare il traffico diretto all'interfaccia inside del firewall in questione, mi basterebbe digitare:

PIX501# capture pacchetti interface inside

Ora, per visualizzare i pacchetti catturati basta digitare:

PIX501# sh capture pacchetti

Ovviamente, per ottenere un filtro sull'output, è sufficiente utilizzare la direttiva include. Ad esempio, il comando:

PIX501# sh capture pacchetti | i icmp

mi consentirà di osservare soltanto il traffico icmp diretto all'interfaccia su cui è attiva la capture.

Un'altra operazione utile potrebbe essere quella che ci permette di azzerare il contenuto delle capture per fare un po d'ordine. In questo casa basta scrivere:

PIX501# clear capture pacchetti

Infine, per disattivare lo sniffer basta digitare:

PIX501# no capture pacchetti

Non sottovalutate le potenzialità di questo comando, in quanto uno sniffer può tornare estramamente utile durante le operazioni di troubleshooting.

A presto.

PS: in alternativa, per osservare il traffico icmp diretto al PIX si potrebbe utilizzare il comando debug icmp trace, il quale può essere disabilitato con un semplice no debug icmp trace oppure un undebug all.

Recentemente, lanciando uno sh access-list su un Cisco SOHO 97, ho notato la presenza della seguente ACL:

Extended IP access list sl_def_acl   
 10 deny tcp any any eq telnet log   
 20 deny tcp any any eq www log   
 30 deny tcp any any eq 22 log   
 40 permit tcp any any eq 22 log

Dopo aver cercato un pò sul Web, ho notato che tale ACL è strettamente legata con una feature introdotta nelle IOS a partire dalla 12.3(4)T, ovvero il login quiet mode. In questo modo, quando il router si accorge di un attacco bruteforce diretto ad uno dei suoi servizi in ascolto, applica tale ACL in ingresso alle interfacce vty.

Nella fattispecie, il comando per abilitare il login quiet mode è il seguente:

Router(config)# login quiet-mode access-class

Definiamo inoltre quali sono i parametri che identificano un attacco bruteforce:

Router(config)# login block-for <secondi> attempts <numero tentativi> within <secondi>

Lanciamo un copy run start ed è fatta.

See ya.

PS: come potete notare l'ACL sl_def_acl ha due regole discordanti, ovvero la 30 e la 40. Infatti, le ACL seguono una logica top-down, per cui quando un pacchetto matcha una entry, quelle successive non vengono valutate. Nello specifico, se viene intercettato un tentativo di connessione SSH al router ed è in vigore l'ACL in questione, il permit tcp any any eq 22 non ha alcun senso. Un ottimo workaround consiste nel definire un'ACL custom da dare in pasto al comando login quiet-mode access-class {nostra ACL}.

Tempo fa, durante uno dei rari momenti di relax davanti alla TV, mi sono imbattuto in un servizio de "Le Iene" in cui veniva intervistato un presunto hacker. Se non sapete di cosa sto parlando, date un'occhiata qui:

Ora, fondamentalmente le cose che vengono dette all'inizio sembrano piuttosto sensate e corrette. Mi riferisco alla definizione di hacker come qualcuno di estremamente curioso e capace, spinto solo ed esclusivamente dalla voglia di conoscere i sistemi in modo approfondito e dalla volontà di esplorare ambienti che dovrebbero restare ad eccesso limitato. Ciò implica anche il non voler danneggiare il sistema bucato, limitandosi ad osservarlo nella sua complessità senza intaccarne minimamente la struttura. Questa è la caratteristica peculiare degli hacker, per la precisione degli ethical hacker, tipologia che rientra pienamente nella schiera dei white hat.

Poi però il presunto hacker ammette di aver sviluppato un trojan per analizzare un pc bucato in precedenza... ed in questa pratica c'è ben poco di "etico". Altra affermazione che non mi convince: secondo lui, i virus vengono creati per lo più da ragazzini, spinti semplicemente da finalità ludiche. Sbagliato: ormai sviluppare trojan, virus, worm e malicious software in genere è diventato quasi un business, sia per le società di sicurezza che per coloro i quali vogliono sottrarre dati sensibili agli utenti (la Russian Business Network vi dice qualcosa?), come numeri di carte di credito, password, documenti altamente confidenziali, ecc.

Dopodichè, l'intervistato afferma che sarebbe buona norma criptare i file salvati sull'HD: correttissimo, anzi a tal proposito vi consiglio di utilizzare il software gratuito e multipiattaforma TrueCrypt. 

La cosa che mi lascia maggiormente perplesso, però, è la dimostrazione pratica di un "hacking". Viene infatti mostrato quanto il PC di un normalissimo utente possa risultare vulnerabile ad eventuali attacchi esterni. Ma andiamo con ordine.

Per prima cosa viene inviata alla vittima un'email provvista di allegato. Tale allegato sembrerebbe una normalissima immagine. In realtà, mediante un software sviluppato ad hoc (total binder) all'interno del file immagine è stato incapsulato un eseguibile. Una volta che il malcapitato di turno apre l'allegato, l'eseguibile (un comunissimo trojan horse) si installa in una cartella di sistema e, mediante lo scheduler di Windows, verrà avviato automaticamente al boot del sistema operativo. Fin qui sembrerebbe tutto semplice e quasi banale, ma affinchè un trucchetto del genere riesca devono verificarsi tutta una serie di situazioni concomitanti del tipo:

1) l'utente è così tanto naive da non sapere che gli allegati delle email provenienti da indirizzi sconosciuti non devono mai essere aperti;

2) il PC della vittima è sprovvisto di un antivirus, che gli segnalerebbe il file malevolo ancor prima di aprire l'allegato (chiamasi scansione della mail);

3) il PC della vittima è collegato ad Internet mediante un semplice modem e non attraverso un router. Basterebbe infatti un semplice NAT per fare in modo che il trojan, seppur installato, non riesca a comunicare con la rete pubblica e quindi con l'attaccate.

4) sul pc della vittima non è attivo alcun firewall, nemmeno quello integrato ai sistemi operativi di casa Microsoft.

Morale della favola: tale dimostrazione è solo una spettacolarizzazione di tecniche di cracking banalissime, usate per lo più dagli script kiddie di turno. Nel complesso, non dico che tale servizio sia un tipico esempio di disinformazione, ma poco ci manca.

A presto.

Una delle necessità principali del sistemista di rete riguarda solitamente il monitoraggio dei vari dispositivi che costituiscono il network di cui è amministratore. Per esempio, potrebbe essere necessario avere informazioni sulla raggiungibilità dei dispositivi (attraverso un semplice ping), oppure sul traffico che interessa le varie interfacce di rete (sia in ingresso che in uscita), piuttosto che sul loro stato di funzionamento.

Per fare ciò, occorre utilizzare un protocollo sviluppato ad hoc, ovvero SNMP (Simple Network Management Protocol), che può essere configurato in due modalità: poll e trap. Nel primo caso è il sistemista, attraverso degli opportuni client di monitoraggio, a domandare periodicamente ed in modo semiautomatizzato qual è lo stato dei vari servizi presenti sugli host o sui dispositivi di rete. Nel secondo caso, poichè per il client di monitoraggio potrebbe essere oneroso effettuare troppe query, sono i dispositivi di rete stessi a generare degli alert nel caso in cui si verifichi un problema di raggiungibilità relativo ad un determinato servizio. Tali alert verranno recapitati al client, il quale li mostrerà, se cosi si può dire, al sistemista.

Ora, premesso che in questa breve guida utilizzeremo il protocollo SNMP in modalità poll, vediamo quali sono i dispositivi di rete che vogliamo monitorare, e quale client di monitoraggio utilizzare.

In particolare, i dispositivi di rete su cui concentreremo la nostra attenzione sono un home router, per la precisione un Cisco soho 77, ed un firewall (Cisco PIX 501). Il client di monitoraggio, invece, sarà nagios3.

SNMP su PIX 501

Per prima cosa abilitamo il protocollo SNMP sul firewall. Per fare ciò è necessario seguire i questi step:

PIX501> ena

PIX501# conf t

PIX501(config)# snmp-server host <IP del client di monitoraggio> poll

In questo modo, abbiamo istruito il PIX su quale dovrà essere l'IP sorgente da cui potranno provenire le query SNMP. Le query provenienti da altri IP saranno ovviamente ignorate.

Adesso diciamo al PIX qual è la community string (ovvero una sorta di password) che verrà utilizzata:

PIX501(config)# snmp-server community <community string>

Salviamo adesso la configurazione con un write mem:

PIX501(config)# write mem

Bene, verifichiamo adesso che il protocollo SNMP sia stato abilitato correttamente sul nostro PIX, lanciando una query direttamente dalla linux box che utilizzeremo come stazione di monitoraggio:

nightfly@nightbox:~$ snmpwalk -v 1 -c <community string> <IP dell'interfaccia inside del PIX>

Se riceveremo una risposta del tipo:

IF-MIB::ifNumber.0 = INTEGER: 2
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2

<output omesso>

vuol dire che la query ha restituito dei risultati e che quindi il protocollo è funzionante.

Alcune precisazioni

Come avrete notato dalla query eseguita mediante il comando snmpwalk, la versione del protocollo SNMP abilitata sul PIX è la 1. Tale versione, come la 2, è estremamente vulnerabile in quanto consente la propagazione della community string in chiaro. Converrete con me che tale scelta risulta piuttosto insensata, in quanto il firewall dovrebbe essere la security appliance per antonomasia. L'unica attenuante che mi sento di concedere è che il PIX 501 resta comunque un dispositivo piuttosto datato, il cui sistema operativo integrato (Finesse) non viene più sviluppato da tempo.

Un'altra precisazione riguarda proprio l'uso del comando snmpwalk. Nella fattispecie, mediante tale comando è possibile scorrere l'intero SMI alla ricerca dell'OID che ci interessa. Nel caso in cui, invece, conoscessimo l'OID specifico, si potrebbe utilizzare il comando snmpget, con la seguente sintassi:

nightfly@nightbox:~$ snmpget -v 1 -c <community string> <IP dell'interfaccia inside del PIX> <OID>

A proposito, se non sapete cos'è lo SMI e cosa si intende per OID e MIB date un'occhiata a questo post.

Infine, se come stazione di monitoraggio non avete a disposizione una linux box ma una macchina Windows, potete scaricare il tool Getif (direttamente da qui, è gratuito), il quale vi consentirà di eseguire le query SNMP in modo semplice ed efficace.

SNMP su SOHO 77

Dopo aver abilitato il protocollo SNMP sul firewall, abilitiamolo anche sul router. Per fare ciò occorre digitare i comandi:

soho77> ena

soho77# conf t

soho77(config)# snmp-server enable informs

soho77(config)# snmp-server community <community string>

Salviamo adesso la configurazione:

soho77(config)# end

soho77# copy run start

Effettuiamo la solita query mediante snmpwalk e se otteniamo risposta significa che anche sul router il protocollo in questione è stato abilitato in modo corretto:

nightfly@nightbox:~$ snmpwalk -v 2c -c <community string> <IP del router>

Come avrete già sicuramente notato dal comando precedente, sul router è abilitato il protocollo SNMP versione 2.

Configurazione della stazione di monitoraggio

Dopo aver abilitato il protocollo SNMP sui dispositivi che vogliamo monitorare, vediamo adesso come configurare al meglio la nostra stazione di monitoraggio. In questa guida partirò dal presupposto che tale stazione sarà una macchina linux, su cui verrà installato un apposito client, ovvero nagios3.

Procediamo quindi con l'installazione di tale applicativo:

nightfly@nightbox:~$ sudo apt-get install nagios3

Ad installazione completata spostiamoci nella seguente directory:

nightfly@nightbox:~$ cd /etc/nagios3/conf.d

qui sono presenti i file di configurazione dei vari host. Apriamo in lettura uno dei file di configurazione che vengono generati automaticamente dopo l'installazione di nagios, ad esempio localhost_nagios2.cfg:

nightfly@nightbox:/etc/nagios3/conf.d$ cat localhost_nagios2.cfg

l'output sarà simile al seguente:

define host {
use                     generic-host            ; Name of host template to use
host_name       localhost
alias                   localhost
address             127.0.0.1
}

define service {
use                                  generic-service         ; Name of service template to use
host_name                    localhost
service_description     Disk Space
check_command          check_all_disks!20%!10%
}

Mediante la direttiva define host viene definito l'host template, l'hostname, l'alias e l'indirizzo IP del dispositivo da monitorare.

Invece, mediante la direttiva define service, viene definito il servizio da monitorare per il suddetto host.

Ma come funzionano effettivamente i servizi? Bene, qui la spiegazione diventa inevitabilmente un po' più impegnativa. Per prima cosa occorre precisare che nagios prevede la presenza di alcuni eseguibili presenti all'interno della direcotory /usr/lib/nagios/plugins. Tali eseguibili verranno utilizzati nell'ambito di alcuni comandi creati appositamente. In particolare, una lista di tali comandi è presente all'interno della directory /etc/nagios-plugins/config, il cui contenuto è simile al seguente:

apt.cfg     disk.cfg      dummy.cfg   hppjd.cfg     ldap.cfg  mrtg.cfg     news.cfg  pgsql.cfg  radius.cfg   snmp.cfg     telnet.cfg
breeze.cfg  disk-smb.cfg  flexlm.cfg  http.cfg      load.cfg  mysql.cfg    nt.cfg    ping.cfg   real.cfg     ssh.cfg      users.cfg
dhcp.cfg    dns.cfg       ftp.cfg     ifstatus.cfg  mail.cfg  netware.cfg  ntp.cfg   procs.cfg  rpc-nfs.cfg  tcp_udp.cfg

Come è possibile notare, quindi, esistono diversi comandi raccolti all'interno di opportuni file di configurazione. Più precisamente, tali comandi vengono suddivisi a seconda del protocollo o dell'applicativo che intendono monitorare. Osserviamo adesso uno stralcio del contenuto di un qualsiasi file di configurazione menzionato in precedenza, ad esempio snmp.cfg:

# 'check_compaq_thermalCondition' command definition
define command {
command_name    check_compaq_thermalCondition
command_line     /usr/lib/nagios/plugins/check_snmp -H '$HOSTADDRESS$' -C '$ARG1$' -o .1.3.6.1.4.1.232.6.2.1.0,.1.3.6.1.4.1.232.6.2.2.0,.1.3.6.1.4.1.232.6.2.3.0,.1.3.6.1.4.1.232.6.2.4.0 -u 'ThermalCondition','ThermalTemp','ThermalSystem','ThermalCPUFan' -w 2:2,2:2,2:2,2:2 -c 1:2,1:2,1:2,1:2 -l "Thermal status "
}

In questo caso, mediante l'eseguibile check_snmp, vengono monitorate le condizioni termiche dell'host specificato all'interno della variabile '$HOSTADDRESS$', il cui contenuto è presente proprio nella definizione dell'host contenuta in un file posizionato in /etc/nagios3/conf.d$

La variabile '$ARG1$', invece, serve a specificare la community string da utilizzare. Infine, la flag -o specifica gli OID da usare per ottenere dal sistema interrogato le informazioni desiderate.

Configurare nagios per monitorare il PIX 501

Ora che sappiamo come funzionano i comandi, possiamo crearne uno ad hoc per monitorare lo stato delle interfacce inside ed outside del nostro PIX.

Apriamo in scrittura il file snmp.cfg ed inseriamo la seguente direttiva:

# 'snmp_if' command definition
define command {
command_name    snmp_if
command_line    /usr/lib/nagios/plugins/check_snmp -H '$HOSTADDRESS$' -C '$ARG1$' -o '$ARG2$'
}

Salviamo il file, posizioniamoci all'interno della directory /etc/nagios3/conf.d e creiamo il file hots-pix501_nagios3.cfg:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo touch hots-pix501_nagios3.cfg

A questo punto inseriamo all'interno del file in questione le informazioni relative al PIX:

define host {
host_name   PIX501
alias       PIX501 Inside
address     <ip del PIX>
use         generic-host
}

e definiamo, inoltre, i servizi da monitorare per questo host:

define service {
use                             generic-service         ; Name of service template to use
host_name                       PIX501
service_description             Status Interface Outside
check_command                   snmp_if!vostracommunitystring!.1.3.6.1.2.1.2.2.1.8.1
}

Come potete notare, gli argomenti richiesti nell'ambito della definizione del comando snmp_if vengono riconosciuti grazie al prefisso ! e dati in pasto al comando stesso proprio mediante la configurazione del servizio.

Ovviamente, l'OID che indica lo stato dell'interfaccia outside del PIX è .1.3.6.1.2.1.2.2.1.8.1

Allo stesso modo, possiamo monitorare lo stato dell'interfaccia inside del PIX:

define service {
use                             generic-service         ; Name of service template to use
host_name                       gateway
service_description             Status Interface Inside
check_command                   snmp_if!vostracommunitystring!.1.3.6.1.2.1.2.2.1.8.2
}

Configurare nagios per monitorare il SOHO 77

Per il router il discorso di fa un po' più complesso. In questo caso, oltre a voler monitorare lo stato dell'interfaccia ethernet0 e della dialer0, vogliamo anche monitorare il traffico in ingresso ed in uscita per entrambe le interfacce citate in precedenza. Creiamo dunque il file host-soho77_nagios3.cfg:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo touch hots-soho77_nagios3.cfg

apriamolo in scrittura ed aggiungiamo le seguenti direttive:

define host {
host_name   soho77
alias        router soho77
address     <ip del router>
use         generic-host
}

define service{
use                             generic-service         ; Name of service template to use
host_name                       soho77
service_description             Status Interface eth0
check_command                   snmp_if!vostracommunitystring!.1.3.6.1.2.1.2.2.1.8.2
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       soho77
service_description             Status Interface dia0
check_command                   snmp_if!vostracommunitystring!.1.3.6.1.2.1.2.2.1.8.8
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       soho77
service_description             Traffic Inbound Interface eth0                 check_command                   snmp_if!vostracommunitystring!.1.3.6.1.2.1.2.2.1.10.2

}

define service {
use                             generic-service         ; Name of service template to use
host_name                       soho77
service_description             Traffic Inbound Interface dia0
check_command                   snmp_if!vostracommunitystring!.1.3.6.1.2.1.2.2.1.10.8
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       soho77
service_description             Traffic Outbound Interface eth0
check_command                   snmp_if!vostracommunitystring!.1.3.6.1.2.1.2.2.1.16.2
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       soho77
service_description             Traffic Outbound Interface dia0
check_command                   snmp_if!vostracommunitystring!.1.3.6.1.2.1.2.2.1.16.8
}

salviamo il file e riavviamo dunque nagios digitando:

nightfly@nightbox:~$ sudo service nagios3 restart

ed infine diamo un'occhiata allo status dei vari dispositivi direttamente dall'interfaccia Web messa a nostra disposizione da nagios3:

http://ipstazionedimonitoraggio/nagios3

A questo punto verranno richieste le credenziali di accesso alla pagina (lo username di default è nagiosadmin)

Cliccando infine su host details o su service detail sarà possibile constatare l'effettiva raggiungibilità dei vari dispositivi e lo stato dei servizi attivi.

Spero di essere stato chiaro, per ulteriori chiarimenti contattatemi.

PS: potete fare in modo che nagios3 vi invii una mail per notificare l'eventuale irraggiungibilità di un dispositivo oppure per segnalare qualche problema riscontrato su uno dei servizi attivi nella rete. Per fare ciò è necessario editare il file contacts_nagios2.cfg presente nella directory /etc/nagios3/conf.d:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo nano contacts_nagios2.cfg

Vi basterà modificare quindi il campo email presente in contact:

define contact {
        contact_name                    root
        alias                           Root
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email
        host_notification_commands      notify-host-by-email
        email                           vostroindirizzoemail       

}

Riavviate nagios3 ed il gioco è fatto.

Recentemente mi è capitato di dover monitorare mediante Nagios le chiamate attive su un router Cisco 2851 adibito a voice gateway. Premesso che tale router è dotato di due interfacce seriali, entrambe utilizzate nell'ambito di linee E1, occorre fare alcune precisazioni.

Precisazione #1

Le linee E1 utilizzano ben 30 canali dati (B-channel, dove B sta per Bearer) a 64 Kbps ed un canale di segnalazione (D ovvero Delta) a 128 Kbps. In questo modo è possibile raggiungere delle velocità teoriche di 2Mbps. Esse rappresentano, inoltre, le PRI (Primary Rate Interface) usate in Europa, Asia ed Australia.

Le linee T1 utilizzano invece 23 canali dati (a 64 Kbps) ed un canale di segnalazione (anch'esso a 64 Kbps) . Tale tipologia di PRI viene usata negli Stati Uniti d'America ed in Giappone e permette di raggiungere velocità nominali pari a 1.544 Mbps.

Precisazione #2

Quello che ci interessa è monitorare il numero di chiamate VOIP attive. Per fare ciò è sufficiente utilizzare i seguenti comandi:

Router2851#sh isdn active <nomeinterfaccia>

per visualizzare il numero di chiamate attive

Router2851#sh call resource voice stats

per ottenere informazioni statistiche relative al Digital Signal 0 (DS0), ovvero il canale utilizzato per trasportare il traffico voce (in realtà il termine DS0 si riferisce alle linee T1, per le linee E1 vi è il corrispondente E0, anche se sul router viene menzionato solo DS0).

Configurazione di Nagios

Monitoriamo quindi mediante SNMP le statistiche associate al DS0, usando il seguente OID:

.1.3.6.1.4.1.9.10.19.1.1.9.1.3.0.0

Non ci resta che configurare il comando su Nagios:

nightfly@nightbox:~$ cd /etc/nagios-plugins/config

nightfly@nightbox:~$ sudo nano snmp.cfg

Inseriamo la seguente direttiva:

'snmp_call' command definition
define command {
command_name    snmp_call
command_line    /usr/lib/nagios/plugins/check_snmp -H '$HOSTADDRESS$' -C '$ARG1$' -o '$ARG2$'
}

e successivamente abilitiamo il servizio per il 2851:

nightfly@nightbox:~$ cd /etc/nagios3/conf.d

nightfly@nightbox:~$ sudo nano host-2851_nagios3.cfg

Inseriamo quanto segue:

define service {
use                             generic-service         ; Name of service template to use
host_name                       2851
service_description             Active Calls
check_command                   snmp_call!vostracommunitystring!.1.3.6.1.4.1.9.10.19.1.1.9.1.3.0.0
}

Finalmente sarà possibile monitorare le chiamate attive sul nostro voice gateway.

A presto.