Questo articolo è dedicato alle particolarità del monitoraggio delle apparecchiature di rete tramite il protocollo SNMPv3. Parleremo di SNMPv3, condividerò le mie esperienze nella creazione di modelli completi in Zabbix e mostrerò cosa si può ottenere nell'organizzazione di un sistema di allerta distribuito in una grande rete. Il protocollo SNMP è fondamentale per il monitoraggio delle apparecchiature di rete, e Zabbix è perfetto per monitorare un gran numero di oggetti e sintetizzare volumi significativi di metriche in arrivo.
Qualche parola su SNMPv3
Iniziamo con l'obiettivo del protocollo SNMPv3 e le peculiarità del suo utilizzo. Le funzioni di SNMP sono il monitoraggio dei dispositivi di rete e la gestione elementare tramite l'invio di semplici comandi (ad esempio, attivazione e disattivazione di interfacce di rete o riavvio di un dispositivo).
La principale differenza del protocollo SNMPv3 rispetto alle versioni precedenti è costituita dalle classiche funzioni di sicurezza [1-3], ovvero:
- autenticazione (Authentication), che determina che la richiesta proviene da una fonte affidabile;
- cifratura (Encryption), per prevenire la divulgazione dei dati trasmessi in caso di intercettazione da parte di terzi;
- integrità (Integrity), cioè la garanzia che il pacchetto non sia stato manomesso durante il trasferimento.
SNMPv3 prevede l'uso di un modello di sicurezza, in cui la strategia di autenticazione è stabilita per un determinato utente e il gruppo a cui appartiene (nelle versioni precedenti di SNMP, nella richiesta dal server all'oggetto monitorato veniva confrontata solo la 'community', una stringa di testo con la 'password' inviata in chiaro).
SNMPv3 introduce il concetto di livelli di sicurezza — livelli di sicurezza consentiti che definiscono la configurazione dell'apparecchiatura e il comportamento dell'agente SNMP dell'oggetto monitorato. La combinazione del modello di sicurezza e del livello di sicurezza determina quale meccanismo di sicurezza viene utilizzato per elaborare il pacchetto SNMP [4].
La tabella descrive le combinazioni di modelli e livelli di sicurezza SNMPv3 (i primi tre colonne le lascerò come nell'originale):
Pertanto, utilizzeremo SNMPv3 in modalità di autenticazione con cifratura.
Configurazione di SNMPv3
Il monitoraggio delle apparecchiature di rete presuppone una configurazione uniforme del protocollo SNMPv3 sia sul server di monitoraggio che sull'oggetto monitorato.
Iniziamo con la configurazione del dispositivo di rete Cisco, la sua configurazione minima necessaria appare come segue (per la configurazione utilizziamo la CLI, i nomi e le password sono stati semplificati per evitare confusione):
snmp-server group snmpv3group v3 priv read snmpv3name
snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso includedLa prima riga snmp-server group definisce il gruppo di utenti SNMPv3 (snmpv3group), il modo di lettura (read) e il diritto di accesso del gruppo snmpv3group per visualizzare determinate ramificazioni dell'albero MIB dell'oggetto di monitoraggio (snmpv3name successivamente nella configurazione specifica a quali ramificazioni dell'albero MIB il gruppo snmpv3group potrà accedere).
La seconda riga snmp-server user definisce l'utente snmpv3user, la sua appartenenza al gruppo snmpv3group, così come l'applicazione dell'autenticazione md5 (la password per md5 è md5v3v3v3) e la crittografia des (la password per des è des56v3v3v3). Naturalmente, invece di des, è meglio utilizzare aes, qui lo menziono solo per esempio. Inoltre, nella definizione dell'utente è possibile aggiungere un elenco di accesso (ACL), che regola gli indirizzi IP dei server di monitoraggio autorizzati a monitorare questo dispositivo, il che è anche una best practice, ma non voglio complicare il nostro esempio.
La terza riga snmp-server view definisce il nome codificato, che definisce le ramificazioni dell'albero MIB snmpv3name in modo che possano essere richieste dal gruppo di utenti snmpv3group. ISO, invece di definire rigorosamente una singola ramificazione, consente al gruppo di utenti snmpv3group di accedere a tutti gli oggetti dell'albero MIB dell'oggetto di monitoraggio.
Una configurazione analoga per le apparecchiature Huawei (anch'essa in CLI) appare come segue:
snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5
md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56
des56v3v3v3Dopo aver configurato i dispositivi di rete, è necessario verificare l'accesso dal server di monitoraggio tramite il protocollo SNMPv3, utilizzerò snmpwalk:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252 
Uno strumento più visivo per richiedere specifici oggetti OID, utilizzando file MIB – snmpget:
Ora passiamo alla configurazione di un elemento dati tipico per SNMPv3, all'interno del template di Zabbix. Per semplicità e indipendenza da MIB, utilizzo OID numerici:
Utilizzo macro utente nei campi chiave, poiché saranno uguali per tutti gli elementi di dati del modello. È possibile impostarli nel modello se tutti i dispositivi di rete nella tua rete hanno parametri SNMPv3 identici, oppure all'interno del nodo di rete, se i parametri SNMPv3 per diversi oggetti di monitoraggio differiscono:
Si noti che il sistema di monitoraggio dispone solo del nome utente e delle password per l'autenticazione e la crittografia. Il gruppo di utenti e l'area degli oggetti MIB ai quali è consentito l'accesso sono impostati sull'oggetto di monitoraggio.
Ora passiamo al riempimento del modello.
Template di polling in Zabbix
Una regola semplice durante la creazione di qualsiasi modello di polling è quella di renderli il più dettagliati possibile:
Dedico molta attenzione all'inventario per facilitare la gestione di una rete di grandi dimensioni. Di questo parlerò più avanti, ma ora – i trigger:
Per facilitare la visualizzazione dei trigger, nei loro nomi sono incorporati macro di sistema {HOST.CONN}, in modo che nel cruscotto nella sezione allerta vengano visualizzati non solo i nomi dei dispositivi, ma anche gli indirizzi IP, sebbene questo sia più una questione di comodità che di necessità. Per determinare l'indisponibilità di un dispositivo, oltre alla normale richiesta echo, utilizzo il controllo di indisponibilità del nodo tramite il protocollo SNMP, quando l'oggetto è accessibile tramite ICMP, ma non risponde alle richieste SNMP: questa situazione è possibile, ad esempio, in caso di duplicazione degli indirizzi IP su dispositivi diversi, a causa di firewall non configurati correttamente o impostazioni errate di SNMP sugli oggetti di monitoraggio. Se si utilizza il controllo di accessibilità dei nodi solo tramite ICMP, durante l'indagine degli incidenti di rete, potrebbero non esserci dati di monitoraggio disponibili, quindi è necessario controllare il loro arrivo.
Passiamo all'individuazione delle interfacce di rete: per le apparecchiature di rete questa è la funzione di monitoraggio più importante. Poiché nel dispositivo di rete possono esserci centinaia di interfacce, è necessario filtrare quelle non necessarie per non sovraccaricare la visualizzazione e non affollare il database.
Utilizzo la funzione di scoperta standard per SNMP, con un numero elevato di parametri rilevabili, per una filtrazione più flessibile:
discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7] 
Con tale rilevamento, è possibile filtrare le interfacce di rete in base ai loro tipi, descrizioni utenti «description» e stati amministrativi delle porte. I filtri e le espressioni regolari per il filtraggio nel mio caso sono i seguenti:
Al rilevamento verranno escluse le seguenti interfacce:
- spente manualmente (adminstatus<>1), grazie a IFADMINSTATUS;
- senza descrizione testuale, grazie a IFALIAS;
- che contengono il carattere *, grazie a IFALIAS;
- che sono di servizio o tecniche, grazie a IFDESCR (nel mio caso, nelle espressioni regolari IFALIAS e IFDESCR vengono controllate con un'unica espressione regolare alias).
Il modello per la raccolta dei dati tramite il protocollo SNMPv3 è quasi pronto. Non ci soffermeremo ulteriormente sui prototipi degli elementi dati per le interfacce di rete, ma passiamo ai risultati.
Risultati del monitoraggio
Per iniziare – l'inventario di una piccola rete:
Se si preparano modelli per ogni serie di dispositivi di rete – si può ottenere una composizione dei dati riassuntivi conveniente per l'analisi riguardante il software attuale, i numeri di serie e le notifiche per l'arrivo della donna delle pulizie nella server room (a causa del basso Uptime). Un estratto della mia lista di modelli è di seguito:
E ora – il pannello principale di monitoraggio, con i trigger distribuiti in base ai livelli di importanza:
Grazie a un approccio complessivo ai modelli per ogni modello di dispositivo nella rete, si può ottenere che nell'ambito di un unico sistema di monitoraggio venga organizzato uno strumento per la previsione delle guasti e delle emergenze (in presenza di sensori e metriche appropriati). Zabbix è molto adatto per il monitoraggio delle infrastrutture di rete, server e servizi, e la gestione delle apparecchiature di rete dimostra chiaramente le sue capacità.
Elenco delle fonti utilizzate:1. Hucaby D. CCNP Routing and Switching SWITCH 300-115 Official Cert Guide. Cisco Press, 2014. pp. 325-329.
2. RFC 3410.
3. RFC 3415.
4. Guida alla configurazione SNMP, Cisco IOS XE Release 3SE. Capitolo: SNMP Version 3.
Fonte: habr.com
