Questo articolo è dedicato alle funzionalità di monitoraggio delle apparecchiature di rete utilizzando il protocollo SNMPv3. Parleremo di SNMPv3, condividerò la mia esperienza nella creazione di modelli completi in Zabbix e mostrerò cosa si può ottenere organizzando avvisi distribuiti in una grande rete. Il protocollo SNMP è quello principale quando si monitorano le apparecchiature di rete e Zabbix è ottimo per monitorare un gran numero di oggetti e riassumere grandi volumi di parametri in entrata.
Qualche parola su SNMPv3
Cominciamo con lo scopo del protocollo SNMPv3 e le caratteristiche del suo utilizzo. I compiti di SNMP sono il monitoraggio dei dispositivi di rete e la gestione di base inviando loro semplici comandi (ad esempio, abilitare e disabilitare le interfacce di rete o riavviare il dispositivo).
La principale differenza tra il protocollo SNMPv3 e le sue versioni precedenti sono le classiche funzioni di sicurezza [1-3], ovvero:
- Autenticazione, che determina che la richiesta è stata ricevuta da una fonte attendibile;
- crittografia (Crittografia), per impedire la divulgazione dei dati trasmessi quando intercettati da terzi;
- integrità, cioè la garanzia che il pacchetto non sia stato manomesso durante la trasmissione.
SNMPv3 implica l'utilizzo di un modello di sicurezza in cui viene impostata la strategia di autenticazione per un dato utente e il gruppo a cui appartiene (nelle versioni precedenti di SNMP, la richiesta del server all'oggetto di monitoraggio confrontava solo "community", un testo stringa con una “password” trasmessa in chiaro (plain text)).
SNMPv3 introduce il concetto di livelli di sicurezza: livelli di sicurezza accettabili che determinano la configurazione delle apparecchiature e il comportamento dell'agente SNMP dell'oggetto di monitoraggio. La combinazione del modello di sicurezza e del livello di sicurezza determina quale meccanismo di sicurezza viene utilizzato durante l'elaborazione di un pacchetto SNMP [4].
La tabella descrive combinazioni di modelli e livelli di sicurezza SNMPv3 (ho deciso di lasciare le prime tre colonne come nell'originale):
Di conseguenza, utilizzeremo SNMPv3 in modalità di autenticazione utilizzando la crittografia.
Configurazione di SNMPv3
Il monitoraggio delle apparecchiature di rete richiede la stessa configurazione del protocollo SNMPv3 sia sul server di monitoraggio che sull'oggetto monitorato.
Cominciamo con la configurazione di un dispositivo di rete Cisco, la sua configurazione minima richiesta è la seguente (per la configurazione utilizziamo la CLI, ho semplificato nomi e 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), la modalità di lettura (lettura) e il diritto di accesso del gruppo snmpv3group per visualizzare determinati rami dell'albero MIB dell'oggetto di monitoraggio (snmpv3name quindi nel configurazione specifica a quali rami dell'albero MIB a cui il gruppo può accedere (snmpv3group potrà accedere).
La seconda riga snmp-server user – definisce l'utente snmpv3user, la sua appartenenza al gruppo snmpv3group, nonché l'uso dell'autenticazione md5 (la password per md5 è md5v3v3v3) e della crittografia des (la password per des è des56v3v3v3). Naturalmente è meglio usare aes invece di des; lo riporto qui solo come esempio. Inoltre, quando si definisce un utente, è possibile aggiungere un elenco di accesso (ACL) che regola gli indirizzi IP dei server di monitoraggio che hanno il diritto di monitorare questo dispositivo: anche questa è la migliore pratica, ma non complicherò il nostro esempio.
La terza riga vista snmp-server definisce un nome in codice che specifica i rami dell'albero MIB snmpv3name in modo che possano essere interrogati dal gruppo utenti snmpv3group. L'ISO, invece di definire rigorosamente un singolo ramo, consente al gruppo di utenti snmpv3group di accedere a tutti gli oggetti nell'albero MIB dell'oggetto di monitoraggio.
Una configurazione simile per le apparecchiature Huawei (anche nella CLI) si presenta così:
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 oggetti OID specifici utilizzando file MIB è snmpget:
Passiamo ora alla configurazione di un tipico elemento dati per SNMPv3, all'interno del template Zabbix. Per semplicità e indipendenza dal MIB, utilizzo gli OID digitali:
Utilizzo le macro personalizzate nei campi chiave perché saranno le stesse per tutti gli elementi di dati nel modello. È possibile impostarli all'interno di un modello, se tutti i dispositivi di rete nella rete hanno gli stessi parametri SNMPv3, o all'interno di un nodo di rete, se i parametri SNMPv3 per i diversi oggetti di monitoraggio sono diversi:
Tieni presente che il sistema di monitoraggio ha solo un nome utente e password per l'autenticazione e la crittografia. Il gruppo utenti e l'ambito degli oggetti MIB a cui è consentito l'accesso sono specificati sull'oggetto di monitoraggio.
Passiamo ora alla compilazione del modello.
Modello di sondaggio Zabbix
Una regola semplice quando si creano modelli di indagine è renderli il più dettagliati possibile:
Presto molta attenzione all'inventario per facilitare il lavoro con una rete di grandi dimensioni. Ne parleremo più avanti, ma per ora – trigger:
Per facilitare la visualizzazione dei trigger, nei loro nomi sono incluse le macro di sistema {HOST.CONN} in modo che non solo i nomi dei dispositivi, ma anche gli indirizzi IP vengano visualizzati sulla dashboard nella sezione avvisi, sebbene questa sia più una questione di comodità che di necessità . Per determinare se un dispositivo non è disponibile, oltre alla consueta richiesta di eco, utilizzo un controllo dell'indisponibilità dell'host utilizzando il protocollo SNMP, quando l'oggetto è accessibile tramite ICMP ma non risponde alle richieste SNMP: questa situazione è possibile, ad esempio , quando gli indirizzi IP vengono duplicati su dispositivi diversi, a causa di firewall configurati in modo errato o impostazioni SNMP errate sugli oggetti di monitoraggio. Se si utilizza il controllo della disponibilità dell'host solo tramite ICMP, al momento dell'indagine sugli incidenti sulla rete, i dati di monitoraggio potrebbero non essere disponibili, pertanto la loro ricezione deve essere monitorata.
Passiamo al rilevamento 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 ingombrare la visualizzazione o il database.
Sto utilizzando la funzione di rilevamento SNMP standard, con più parametri rilevabili, per un filtraggio 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 questo rilevamento è possibile filtrare le interfacce di rete in base al tipo, alle descrizioni personalizzate e agli stati amministrativi delle porte. I filtri e le espressioni regolari per il filtraggio nel mio caso assomigliano a questo:
Se rilevate, verranno escluse le seguenti interfacce:
- disabilitato manualmente (adminstatus<>1), grazie a IFADMINSTATUS;
- senza descrizione testuale, grazie a IFALIAS;
- avere il simbolo * nella descrizione del testo, grazie a IFALIAS;
- che siano di servizio o tecnici, grazie a IFDESCR (nel mio caso, nelle espressioni regolari IFALIAS e IFDESCR sono controllati da un alias di espressione regolare).
Il modello per la raccolta dei dati tramite il protocollo SNMPv3 è quasi pronto. Non ci soffermeremo più nel dettaglio sui prototipi di elementi dati per interfacce di rete; passiamo ai risultati.
Risultati del monitoraggio
Per cominciare, fai l'inventario di una piccola rete:
Se prepari modelli per ciascuna serie di dispositivi di rete, puoi ottenere un layout facile da analizzare dei dati di riepilogo sul software corrente, sui numeri di serie e sulla notifica dell'arrivo di un pulitore sul server (a causa del basso tempo di attività). Di seguito è riportato un estratto del mio elenco di modelli:
E ora - il pannello di monitoraggio principale, con trigger distribuiti per livello di gravità:
Grazie ad un approccio integrato ai modelli per ciascun modello di dispositivo nella rete, è possibile garantire che, nell'ambito di un sistema di monitoraggio, sarà organizzato uno strumento per prevedere guasti e incidenti (se sono disponibili sensori e parametri adeguati). Zabbix è adatto per il monitoraggio delle infrastrutture di rete, server e servizi e il compito di mantenere le apparecchiature di rete dimostra chiaramente le sue capacità.
Elenco delle fonti utilizzate:1. Hucaby D. CCNP Routing e Switching Guida alla certificazione ufficiale SWITCH 300-115. Cisco Press, 2014, pagg. 325-329.
2.RFC3410.
3.RFC3415.
4. Guida alla configurazione SNMP, Cisco IOS XE versione 3SE. Capitolo: SNMP versione 3.
Fonte: habr.com