Questo articolo tratta delle caratteristiche 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ò ciò che 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 è particolarmente adatto per monitorare un gran numero di oggetti e aggregare notevoli volumi di metriche in arrivo.
Qualche parola su SNMPv3
Iniziamo con la funzione del protocollo SNMPv3 e le peculiarità del suo utilizzo. Le funzioni di SNMP comprendono il monitoraggio dei dispositivi di rete e un controllo elementare, inviando semplici comandi (ad esempio, attivare o disattivare interfacce di rete o riavviare i dispositivi).
La principale differenza tra il protocollo SNMPv3 e le sue versioni precedenti è rappresentata dalle classiche funzioni di sicurezza [1-3], ovvero:
- autenticazione (Authentication), che garantisce che la richiesta provenga da una fonte fidata;
- criptografia (Encryption), per prevenire la rivelazione dei dati trasmessi in caso di intercettazione da parte di terzi;
- integrità (Integrity), ossia la garanzia che il pacchetto non sia stato manomesso durante il trasferimento.
SNMPv3 prevede l'uso di un modello di sicurezza in cui viene stabilita una politica di autenticazione per un determinato utente e il gruppo a cui appartiene (nelle versioni precedenti di SNMP, nella richiesta dal server all'oggetto monitorato veniva confrontato solo il 'community', una stringa di testo con 'password', trasmessa in chiaro).
SNMPv3 introduce il concetto di livelli di sicurezza — livelli di sicurezza ammessi che definiscono la configurazione dell'hardware 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 nella gestione del pacchetto SNMP [4].
La tabella descrive le combinazioni di modelli e livelli di sicurezza di SNMPv3 (ho deciso di mantenere le prime tre colonne come nell'originale):
Pertanto, utilizzeremo SNMPv3 in modalità di autenticazione con crittografia.
Configurazione di SNMPv3
Il monitoraggio dell'hardware di rete richiede una configurazione identica 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 è la seguente (utilizzeremo la CLI per la configurazione e ho semplificato i nomi e le password 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 i diritti di accesso del gruppo snmpv3group per visualizzare determinate ramificazioni dell'albero MIB dell'oggetto di monitoraggio (snmpv3name definisce 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, e l'uso dell'autenticazione md5 (la password per md5 è md5v3v3v3) e della crittografia des (la password per des è des56v3v3v3). Naturalmente, invece di des, è meglio utilizzare aes; lo presento qui solo come esempio. Inoltre, nella definizione dell'utente, è possibile aggiungere una lista di controllo degli accessi (ACL) che regola gli indirizzi IP dei server di monitoraggio autorizzati a monitorare questo dispositivo - questo è anche una best practice, ma non complicherò il nostro esempio.
La terza riga della vista snmp-server definisce il nome di codice che stabilisce i rami dell'albero MIB snmpv3name, affinché possano essere interrogati dal gruppo utenti snmpv3group. ISO, invece di definire rigorosamente un singolo ramo, permette al gruppo utenti snmpv3group di accedere a tutti gli oggetti dell'albero MIB dell'oggetto di monitoraggio.
Un'impostazione simile su dispositivi Huawei (anche 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; userò 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 interrogare oggetti OID specifici, utilizzando file MIB – snmpget:
Ora passiamo alla configurazione di un elemento dati tipo per SNMPv3, all'interno del modello Zabbix. Per semplicità e indipendenza da MIB, userò OID numerici:
Utilizzo macro personalizzate nei campi chiave, poiché saranno uguali per tutti gli elementi di dati nel modello. Possono essere definiti all'interno del modello se tutti i dispositivi di rete nella tua rete hanno parametri SNMPv3 uguali, oppure a livello di nodo di rete se i parametri SNMPv3 per diversi oggetti di monitoraggio sono diversi:
Nota 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 definiti sull'oggetto di monitoraggio.
Ora passiamo alla compilazione del modello.
Modello di interrogazione in Zabbix
Una semplice regola nella creazione di qualsiasi modello di interrogazione è di renderli il più dettagliati possibile:
Presto dedico grande attenzione all'inventario, per semplificare la gestione di una grande rete. Ne parleremo un po' più tardi; per 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 di allerta vengano mostrati non solo i nomi dei dispositivi, ma anche gli indirizzi IP, anche se si tratta più di una questione di comodità che di necessità. Per determinare l'inaccessibilità di un dispositivo, oltre alla normale richiesta echo, utilizzo il controllo sull'impossibilità di raggiungere il nodo tramite il protocollo SNMP, quando l'oggetto è accessibile via ICMP, ma non risponde alle richieste SNMP – questa situazione è possibile, ad esempio, in caso di duplicazione degli indirizzi IP su più dispositivi, a causa di firewall configurati in modo errato o di impostazioni SNMP errate sugli oggetti di monitoraggio. Se si utilizza il controllo dell'accessibilità dei nodi solo tramite ICMP, al momento di indagare sugli incidenti nella rete potrebbero mancare i dati di monitoraggio, quindi è necessario monitorarne l'arrivo.
Passiamo alla rilevazione delle interfacce di rete – per le apparecchiature di rete questa è la funzione di monitoraggio più importante. Poiché su un dispositivo di rete possono esserci centinaia di interfacce, è necessario filtrare quelle non necessarie per non sovraccaricare la visualizzazione e non appesantire il database.
Utilizzo la funzione di scoperta standard per SNMP, con numerosi 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 questa scoperta, è possibile filtrare le interfacce di rete in base ai loro tipi, descrizioni personalizzate "description" e stati amministrativi delle porte. I filtri e le espressioni regolari per il filtraggio nel mio caso appaiono come segue:
Durante la scoperta verranno escluse le seguenti interfacce:
- disattivate 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 di dati tramite il protocollo SNMPv3 è quasi pronto. Non soffermiamoci ulteriormente sui prototipi degli elementi dati per le interfacce di rete, passiamo ai risultati.
Riepilogo del monitoraggio
Per iniziare: inventario di una piccola rete:
Se si preparano modelli per ogni serie di dispositivi di rete, si può ottenere una disposizione dei dati riassuntivi relativa al software, ai numeri di serie e alle notifiche di arrivo della donna delle pulizie nel server (a causa di un Uptime ridotto). Ecco un estratto della mia lista di modelli:
E ora - il pannello principale di monitoraggio, con i trigger distribuiti in base ai livelli di importanza:
Grazie a un approccio integrato ai modelli per ogni modello di dispositivo in rete, è possibile creare uno strumento per la previsione di guasti e emergenze all'interno di un unico sistema di monitoraggio (se ci sono sensori e metriche adeguate). Zabbix è molto adatto per il monitoraggio delle infrastrutture di rete, server e servizi, e il compito di manutenzione 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
