Tento článek se zaměřuje na charakteristiky monitorování síťového vybavení pomocí protokolu SNMPv3. Budeme hovořit o SNMPv3, podělím se o své poznatky související s vytvářením plnohodnotných šablon v Zabbixu a ukážu, co lze dosáhnout při organizaci distribuovaného alertingu ve velké síti. Protokol SNMP je klíčový pro monitorování síťového vybavení, zatímco Zabbix je skvěle uzpůsoben pro monitorování velkého počtu objektů a shrnování významných objemů přijatých metrik.
Několik slov o SNMPv3
Začněme s určením protokolu SNMPv3 a jeho využitím. Úkoly SNMP zahrnují monitorování síťových zařízení a základní správu pomocí jednoduchých příkazů (například zapnutí a vypnutí síťových rozhraní nebo restartování zařízení).
Hlavním rozdílem mezi protokolem SNMPv3 a jeho předchozími verzemi jsou klasické bezpečnostní funkce [1-3], a sice:
- autentizace (Authentication), která určuje, že požadavek byl přijat od důvěryhodného zdroje;
- šifrování (Encryption), aby se zabránilo odhalení přenášených dat při jejich zachycení třetími stranami;
- integrita (Integrity), což znamená záruku, že paket nebyl poškozen během přenosu.
SNMPv3 předpokládá použití bezpečnostního modelu, ve kterém se bezpečnostní strategie nastavuje pro daného uživatele a skupinu, které patří (v předchozích verzích SNMP se při požadavku ze serveru na monitorovaný objekt porovnávala pouze „community“, textový řetězec s „heslem“, předávaný v nešifrované podobě).
SNMPv3 zavádí pojem bezpečnostních úrovní — povolených úrovní bezpečnosti, které určují nastavení zařízení a chování SNMP agenta monitorovaného objektu. Kombinace bezpečnostního modelu a úrovně bezpečnosti určuje, jaký bezpečnostní mechanismus se používá při zpracování SNMP paketu [4].
V tabulce jsou popsány kombinace modelů a úrovní bezpečnosti SNMPv3 (první tři sloupce jsem se rozhodl ponechat v originále):
Proto budeme používat SNMPv3 v režimu autentizace s použitím šifrování.
Nastavení SNMPv3
Monitorování síťového vybavení vyžaduje stejnou konfiguraci protokolu SNMPv3 na monitorovacím serveru a na pozorovaném objektu.
Začněme s nastavením síťového zařízení Cisco. Jeho minimální požadovaná konfigurace vypadá takto (pro konfiguraci používáme CLI, názvy a hesla jsem zjednodušil, abych předešel zmatku):
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 includedPrvní řádek snmp-server group – definuje skupinu uživatelů SNMPv3 (snmpv3group), režim čtení (read) a právo přístupu skupiny snmpv3group k určitému podstromu MIB stromu objektu monitorování (snmpv3name stanovuje, ke kterým podstromům MIB skupina snmpv3group získá přístup).
Druhý řádek snmp-server user – definuje uživatele snmpv3user, jeho příslušnost ke skupině snmpv3group a také použití autentizace md5 (heslo pro md5 je md5v3v3v3) a šifrování des (heslo pro des je des56v3v3v3). Samozřejmě, místo des je lepší použít aes, zde ho uvádím jen jako příklad. Také při definici uživatele lze přidat seznam přístupu (ACL), který určuje IP adresy monitorovacích serverů oprávněných monitorovat toto zařízení – což je také nejlepší praxe, ale nebudu to v našem příkladu komplikovat.
Třetí řádek snmp-server view definuje kódové jméno, které stanovuje podstromy MIB stromu snmpv3name, aby je mohla žádát skupina uživatelů snmpv3group. ISO, místo přísného určení nějakého konkrétního podstromu, umožňuje skupině uživatelů snmpv3group získat přístup ke všem objektům MIB stromu objektu monitorování.
Podobné nastavení zařízení Huawei (také v CLI) vypadá takto:
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
des56v3v3v3Po nastavení síťových zařízení je nutné zkontrolovat přístup ze serveru monitorování pomocí protokolu SNMPv3. Použiji snmpwalk:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252 
Přehlednější nástroj pro dotazování na konkrétní OID objekty, s použitím MIB souborů – snmpget:
Nyní přejdeme k nastavení typového datového prvku pro SNMPv3 v rámci Zabbix šablony. Pro zjednodušení a nezávislost na MIB používám číselné OID:
Ve svých klíčových polích používám uživatelské makra, protože budou stejná pro všechny datové prvky v šabloně. Je možné je nastavit v rámci šablony, pokud mají všechna síťová zařízení ve vaší síti stejné parametry SNMPv3, nebo v rámci uzlu sítě, pokud se parametry SNMPv3 pro různé objekty monitorování liší:
Všimněte si, že monitorovací systém disponuje pouze uživatelským jménem a hesly pro autentifikaci a šifrování. Skupina uživatelů a oblast MIB-objektů, ke kterým je povolen přístup, se nastavuje na monitorovacím objektu.
Nyní přejdeme k naplnění šablony.
Šablona dotazování v Zabbixu
Jednoduché pravidlo při vytváření jakýchkoli šablon dotazování – dělat je co nejpodrobněji:
Věnuji velkou pozornost inventarizaci, aby se s velkou sítí snáze pracovalo. O tom trochu později, ale teď – spouštěče:
Pro usnadnění vizualizace spouštěčů jsou do jejich názvů zakódovány systémová makra {HOST.CONN}, aby se na řídicím panelu v sekci upozorňování zobrazovaly nejen názvy zařízení, ale i IP adresy, i když to je spíše otázka pohodlí než nutnosti. Pro určení nedostupnosti zařízení kromě běžného echo dotazu používám kontrolu dostupnosti uzlu pomocí protokolu SNMP, kdy je objekt dostupný přes ICMP, ale neodpovídá na SNMP dotazy – taková situace může nastat například při duplicitě IP adres na různých zařízeních, kvůli nesprávně nastaveným firewallům nebo chybným nastavením SNMP na monitorovacích objektech. Pokud bychom používali kontrolu dostupnosti uzlů pouze přes ICMP, během vyšetřování incidentů v síti nemusí být k dispozici monitoring, proto je potřeba sledovat jejich příjem.
Přejdeme k objevování síťových rozhraní – pro síťová zařízení je to nejdůležitější funkce monitorování. Protože na síťovém zařízení může být stovky rozhraní, je nutné filtrovat nepotřebná, aby nedocházelo k přeplnění vizualizace a nezasypávali jsme databázi.
Používám standardní funkci objevování pro SNMP s velkým počtem objevovaných parametrů pro flexibilnější filtrování:
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] 
Při takovém zjištění je možné filtrovat síťové rozhraní podle jejich typů, uživatelských popisů „description“ a administrativních stavů portů. Filtry a regulární výrazy pro filtrování v mém případě vypadají následovně:
Při zjištění budou vyloučena následující rozhraní:
- ručně vypnutá (adminstatus1), díky IFADMINSTATUS;
- bez textového popisu, díky IFALIAS;
- mající ve textovém popisu znak *, díky IFALIAS;
- které jsou služební nebo technické, díky IFDESCR (v mém případě jsou ve regulárních výrazech IFALIAS a IFDESCR kontrolována jedním regulárním výrazem alias).
Šablona pro sběr dat pomocí protokolu SNMPv3 je téměř hotová. Nebudeme se podrobněji zabývat prototypy datových prvků pro síťová rozhraní, přejdeme k výsledkům.
Výsledky monitorování
Nejprve – inventarizace malé sítě:
Pokud připravíte šablony pro každou sérii síťových zařízení – můžete dosáhnout přehledného uspořádání souhrnných údajů o aktuálním softwaru, sériových číslech a upozornění na příchod uklízečky do serverovny (kvůli nízkému Uptime). Výtažek mého seznamu šablon níže:
A nyní – hlavní monitorovací panel, s trigery rozdělenými podle úrovní důležitosti:
Díky komplexnímu přístupu k šablonám pro každý model zařízení v síti je možné dosáhnout toho, že v rámci jednoho monitorovacího systému bude organizován nástroj pro predikci poruch a havárií (při dostupných odpovídajících senzorech a metrikách). Zabbix je skvělý pro monitorování síťových, serverových a servisních infrastruktur, a úkol údržby síťového vybavení jasně ukazuje jeho možnosti.
Seznam použitých zdrojů:1. Hucaby D. CCNP Routing and Switching SWITCH 300-115 Official Cert Guide. Cisco Press, 2014. str. 325-329.
2. RFC 3410.
3. RFC 3415.
4. SNMP Configuration Guide, Cisco IOS XE Release 3SE. Kapitola: SNMP Verze 3.
Zdroj: habr.com
