Zenoss (4.2.x) gestire le trap SNMP inviate da Cisco ASA

Zenoss è un sistema di monitoraggio molto flessibile, ben integrato con Windows per mezzo di WMI ed SNMP.

Tramite questo protocollo è un ottimo sistema di controllo per dispostivi di rete, sistemi operativi ed oggetti che utilizzano l’SNMP come protocollo di gestione/controllo.

Un plugin di estensione dello Zenoss è scritto per interpretare alcuni counter disponibili sui devices Cisco ASA Firewall.

Le informazioni raccolte, possono riportare in un grafico il numero di sessioni VPN attive e la loro durata.

In questo modo è immediato il colpo d’occhio sullo stato degli accessi al sistema. Se il Firewall viene configurato per inviare trap SNMP allo Zenoss, a fronte degli eventi scaturiti dalle autenticazioni, avremo il dettaglio di ogni connessione, con riportati Utente, ip di provenienza ora e durata della connessione.

E’ possibile poi configurare il sistema di gestione degli eventi di Zenoss affinchè invii una mail al verificarsi di determinate condizioni.

fig.1

Quello riportato qui sotto è un estratto della trap che viene inviata dall’Ios ASA al collettore Zenoss.

Il messaggio viene ricevuto ed immagazzinato in relazione all’oggetto monitorato.

Con alcune piccole modifiche ai default delle notifiche dei messaggi è possibile far inviare parte della trap tramite Email per eventuali allarmi.

fig.2

Dalla console eventi bisogna creare un trigger che venga attivato alla ricezione di una trap che contenga nel messaggio clogMessageGenerated.

Successivamente sulla base del trigger definire una notifica, avendo cura di modificare od aggiungere una variabile che comprenda il campo con il rapporto sulla connessione, campo che si desume dal dettaglio della trap in fig.2 ossia clogHistMsgText  che dovrà essere impostato nel seguente modo ${evt/clogHistMsgText} all’interno del “Body Format” della notifica.

Di default nelle notifiche vengono inviati più campi, che in questo caso possono essere eliminati in quanto contengono dati non utili allo scopo.

Nel passo successivo dovrà essere selezionato uno o più Subscriber che altro non è che un utente di Zenoss con la propria informazione relativa alla email.

Da questo momento ogni ricezione da parte di Zenoss di un messaggio di questo tipo produce l’invio alla mail definita per l’utente di parte del messaggio contenente l’informazione sull’evento relativo all’accesso in VPN sull’ASA.

Importante ancora notare che nella parte dedicata alla Notifcation bisogna rimuovere la spunta su “Send only on Initial Occurrence” altrimenti verrà soltanto inviato il primo messaggio alla prima connessione e per i successivi non verrà inviata ulteriore notifica.

Lo Zenpack (plugin) utilizzato per il monitoraggio del Cisco ASA è stato rilasciato e testato sulle versioni 3.x di Zenoss ma gli esempi e le informazioni contenute nel post si riferiscono allo stesso Zenpack installato sulla versione 4.2.1

Riferimenti:

http://www.zenoss.com

http://wiki.zenoss.org/ZenPack:Cisco_Adaptive_Security_Appliance

Squid usato come Reverse Proxy (con riscrittura dell’URL)

In un precedente post ho riportato la configurazione necessaria per la configurazione di un reverse proxy, nel caso preso in considerazione l’utilizzo era per la “protezione” di un Exchange OWA.

L’utilizzo dei RE-WRITERS è utile qualora si voglia controllare ed indirizzare la navigazione degli utenti, ma in questo caso è stato impiegato per “semplificare” un URL particolarmente complicato in accesso, tramite reverse-proxy, ad un servizio aziendale reso disponibile esternamente.

L’URL originale è https://portale.azienda.dominio.it/cart1/cart2/cart3/cart4/pagina.html

Volendo quindi “semplificare” l’URL agli utenti in https://portale.azienda.dominio.it/cart1 è stato necessario l’utilizzo di un re-writer che intercetta le chiamate e le redirige correttamente secondo l’URL completo e quindi corretto.

Esistono diverse modalità e diversi programmi anche molto sofisticati che effettuano questa operazione, tutti esterni a SQUID e vengono “chiamati” direttamente dal software di cache al quale restituiscono poi i valori eventualmente modificati.

In questo caso il sistema più semplice è risultato essere l’utilizzo di uno script PERL richiamato dalla direttiva  redirect_program definita nel file di configurazione dello SQUID.

#esempio di file Squid.con usato come reverse-proxy e re-writer di parte dell’URL

cache_effective_user squiduser
cache_effective_group wheel

https_port 443 accel vhost cert=/usr/local/squid/certificato/portale.crt key=/usr/local/squid/certificato/w3rev2.key
cache_peer 1.2.3.4 parent 9082 0 no-query originserver login=PASS proxy-only

redirect_rewrites_host_header off

acl TUTTI src all
http_access allow TUTTI

#attivazione redirect per modifica URL dall’esterno
redirect_program /usr/local/squid/script/RedirectUrl.pl

#definizione della posizione dei log del formato e della rotazione
logfile_rotate 55
log_mime_hdrs off
access_log /var/log/squid/log/access.log
cache_store_log /var/log/squid/log/store.log
cache_log /var/log/squid/log/cache.log

#definizione della posizione della cache
cache_dir ufs /var/log/squid/cache 100 16 256
cache_mem 50 MB
pid_filename /var/run/squid.pid

script RedirectUrl.pl richiamato da SQUID

#!/usr/bin/perl
use strict;

$| = 1;
# Lettura della variabile da elaborare ( stringa contenente l’URL)
while (<>) {

    my @elems = split;

    my $url = $elems[0];

     if ($url =~ m#^https://portale.azienda.dominio.it/cart1(/.*)?#i) {

        $url = “https://portale.azienda.dominio.it/cart1/cart2/cart3/cart4/pagina.html${1}”;

        print “$urln”;

    }

    else {

        # URL non modificato
print “$urln”;

    }

}

E’ necessario che il file .pl relativo allo script abbia i permessi di esecuzione

riferimenti:

http://wiki.squid-cache.org/Features/Redirectors

http://www.powershelladmin.com/wiki/Linux_squid_proxy_url_rewriting_or_redirection

ZIMBRA (7.2) servizio non avviabile

Ad un anno dall’installazione “improvvisamente” il servizio è risultato essere inaccessibile ed al riavvio con il comando zmcontrol start oppure zmcontrol status vengono riportati in console questi due messaggi

• Unable to determine enabled services from ldap.
• Unable to determine enabled services. Cache is out of date or doesn’t exist.

Il problema è nel fatto che all’atto dell’installazione viene generato un certificato con validità di 365 giorni trascorsi i quali il servizio Zimbra non è più in grado di operare.

con il comando zmlocalconfig -s ssl_allow_untrusted_certs viene visualizzato il comportamento in caso di certificati non validi, nel caso che la verifica riporti un valore false è sufficiente eseguire il comando seguente

• zmlocalconfig -e ssl_allow_untrusted_certs=true

successivamente riavviare i servizi ed il tutto dovrebbe tornare funzionante

se invece si vuole rigenerare nuovamente un certificato i passi da seguire sono descritti nella KB 2021466

Eseguire la scansione del bus scsi su un host Linux

In ambienti virtuali la creazione di un nuovo disco assegnato ad un VM non è recepita dal sistema operativo se non tramite un riavvio del sistema.

Se il riavvio non è immediatamente fattibile è possibile eseguire forzatamente la scansione del bus scsi rendendo così  il nuovo disco disponibile.

il comando da eseguire direttamente da console è il seguente:

echo “- – -” > /sys/class/scsi_host/host0/scan

Questo nel caso la VM abbia un unico controller, nelle configurazioni in cui siano presenti più controller sarà necessario sostituire host0 con un valore che rispecchi la configurazione.

Normalmente ogni controller viene identificato con un progressivo

N.B. la stringa “- – -“ deve contenere uno spazio tra i caratteri  “-“ ed essere racchiusa tra “