Ten artykuł poświęcony jest szczegółom monitorowania sprzętu sieciowego za pomocą protokołu SNMPv3. Porozmawiamy o SNMPv3, podzielę się moimi doświadczeniami z tworzeniem pełnych szablonów w Zabbix oraz pokażę, co można osiągnąć, organizując rozproszoną alertację w dużej sieci. Protokół SNMP jest podstawowym narzędziem do monitorowania sprzętu sieciowego, a Zabbix doskonale nadaje się do monitorowania dużej liczby obiektów i podsumowywania znacznych ilości przychodzących metryk.
Kilka słów o SNMPv3
Zacznijmy od celu protokołu SNMPv3 i jego cech użytkowych. Zadania SNMP obejmują monitorowanie urządzeń sieciowych oraz podstawowe zarządzanie, poprzez wysyłanie do nich prostych poleceń (na przykład włączanie i wyłączanie interfejsów sieciowych czy restartowanie urządzenia).
Główna różnica protokołu SNMPv3 w porównaniu do jego poprzednich wersji to klasyczne funkcje bezpieczeństwa [1-3], a mianowicie:
- uwierzytelnianie (Authentication), określające, czy żądanie pochodzi z zaufanego źródła;
- szyfrowanie (Encryption), aby zapobiec ujawnieniu przekazywanych danych w przypadku ich przechwycenia przez osoby trzecie;
- integralność (Integrity), czyli gwarancja, że pakiet nie został sfałszowany podczas przesyłania.
SNMPv3 zakłada wykorzystanie modelu bezpieczeństwa, w którym strategia uwierzytelniania jest ustalana dla określonego użytkownika oraz grupy, do której należy (w poprzednich wersjach SNMP w żądaniu od serwera do obiektu monitorowania porównywano tylko "community", tekstową stronę z "hasłem", przesyłaną w postaci otwartego tekstu).
SNMPv3 wprowadza pojęcie poziomów bezpieczeństwa — dopuszczalnych poziomów bezpieczeństwa, które definiują konfigurację sprzętu i zachowanie agenta SNMP obiektu monitorowania. Kombinacja modelu bezpieczeństwa i poziomu bezpieczeństwa decyduje o tym, jaki mechanizm bezpieczeństwa jest stosowany podczas przetwarzania pakietu SNMP [4].
W tabeli opisano kombinacje modeli i poziomów bezpieczeństwa SNMPv3 (pierwsze trzy kolumny postanowiłem zostawić w oryginale):
W związku z tym będziemy korzystać z SNMPv3 w trybie uwierzytelniania z zastosowaniem szyfrowania.
Konfiguracja SNMPv3
Monitorowanie sprzętu sieciowego zakłada identyczną konfigurację protokołu SNMPv3 zarówno na serwerze monitorującym, jak i na obserwowanym obiekcie.
Zacznijmy od konfiguracji urządzenia sieciowego Cisco, minimalna niezbędna konfiguracja wygląda następująco (do konfiguracji używamy CLI, nazwy i hasła uprościłem, aby uniknąć zamieszania):
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 includedPierwszy wiersz snmp-server group definiuje grupę użytkowników SNMPv3 (snmpv3group), tryb odczytu (read) oraz prawo dostępu grupy snmpv3group do przeglądania określonych gałęzi drzewa MIB monitorowanego obiektu (snmpv3name określa, do których gałęzi drzewa MIB grupa snmpv3group będzie miała dostęp).
Drugi wiersz snmp-server user definiuje użytkownika snmpv3user, jego przynależność do grupy snmpv3group, a także zastosowanie autoryzacji md5 (hasło dla md5 — md5v3v3v3) i szyfrowania des (hasło dla des — des56v3v3v3). Oczywiście lepiej używać aes zamiast des, tutaj przytaczam to tylko jako przykład. Przy definiowaniu użytkownika można również dodać listę dostępu (ACL), regulującą adresy IP serwerów monitorowania, które mają prawo monitorować to urządzenie – to również najlepsza praktyka, ale nie będę komplikować naszego przykładu.
Trzeci wiersz snmp-server view definiuje nazwę kodową, która ustawia gałęzie drzewa MIB snmpv3name, aby mogły być one zapytane przez grupę użytkowników snmpv3group. ISO, zamiast ścisłego określenia jednej gałęzi, pozwala grupie użytkowników snmpv3group uzyskać dostęp do wszystkich obiektów drzewa MIB monitorowanego obiektu.
Analogiczna konfiguracja sprzętu Huawei (również w CLI) wygląda następująco:
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 skonfigurowaniu urządzeń sieciowych, należy sprawdzić dostęp z serwera monitorowania protokołem SNMPv3, skorzystam z narzędzia snmpwalk:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252 
Bardziej wizualne narzędzie do zapytania o konkretne obiekty OID, korzystając z plików MIB – snmpget:
Teraz przejdźmy do konfiguracji typowego elementu danych dla SNMPv3 w ramach szablonu Zabbix. Dla uproszczenia i niezależności od MIB, używam cyfrowych OID:
W polach kluczowych używam użytkownikowskich makr, ponieważ będą one identyczne dla wszystkich elementów danych w szablonie. Można je ustawić w ramach szablonu, jeśli w Twojej sieci wszystkie urządzenia sieciowe mają te same parametry SNMPv3, lub w ramach węzła sieci, jeśli parametry SNMPv3 dla różnych obiektów monitorowania się różnią:
Zauważ, że system monitorowania dysponuje jedynie nazwą użytkownika oraz hasłami do autoryzacji i szyfrowania. Grupa użytkowników i zakres obiektów MIB, do których dostęp jest dozwolony, są określane na obiekcie monitorowania.
Teraz przejdźmy do wypełnienia szablonu.
Szablon zapytań w Zabbixie
Prosta zasada przy tworzeniu jakichkolwiek szablonów zapytań – czynić je maksymalnie szczegółowymi:
Zwracam dużą uwagę na inwentaryzację, aby praca z dużą siecią była wygodniejsza. O tym trochę później, a teraz – wyzwolenia:
Aby ułatwić wizualizację wyzwoleń, w ich nazwach osadziłem makra systemowe {HOST.CONN}, aby na pulpicie w sekcji alertów wyświetlane były nie tylko nazwy urządzeń, ale także adresy IP, chociaż jest to bardziej kwestia wygody niż konieczności. Do określenia niedostępności urządzenia, oprócz standardowego żądania echo, używam sprawdzenia dostępności węzła za pośrednictwem protokołu SNMP, gdy obiekt jest dostępny przez ICMP, ale nie odpowiada na zapytania SNMP – taka sytuacja może mieć miejsce na przykład przy dublowaniu adresów IP na różnych urządzeniach, z powodu źle skonfigurowanych zapór sieciowych lub błędnych ustawień SNMP na obiektach monitorowania. Jeśli używać sprawdzenia dostępności węzłów tylko przez ICMP, w momencie badania incydentów w sieci może zabraknąć danych monitorujących, dlatego należy kontrolować ich napływ.
Przejdźmy do wykrywania interfejsów sieciowych – dla sprzętu sieciowego jest to najważniejsza funkcja monitorowania. Ponieważ na urządzeniu sieciowym może być setki interfejsów, konieczne jest filtrowanie niepotrzebnych, aby nie zaśmiecać wizualizacji i nie obciążać bazy danych.
Używam standardowej funkcji wykrywania dla SNMP, z dużą ilością wykrywanych parametrów, dla bardziej elastycznego filtrowania:
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] 
W przypadku takiego wykrycia można filtrować interfejsy sieciowe według ich typów, opisów użytkowników „description” oraz statusów administracyjnych portów. Filtry i wyrażenia regularne do filtrowania w moim przypadku wyglądają następująco:
Podczas wykrywania wykluczone zostaną następujące interfejsy:
- ręcznie wyłączone (adminstatus<>1), dzięki IFADMINSTATUS;
- nieposiadające opisu tekstowego, dzięki IFALIAS;
- posiadające w opisie tekstowym znak *, dzięki IFALIAS;
- będące interfejsami pomocniczymi lub technicznymi, dzięki IFDESCR (w moim przypadku w wyrażeniach regularnych IFALIAS i IFDESCR są sprawdzane jednym wyrażeniem regularnym alias).
Szablon do zbierania danych za pomocą protokołu SNMPv3 prawie gotowy. Nie będziemy się bardziej zagłębiać w prototypy elementów danych dla interfejsów sieciowych, przejdźmy do wyników.
Podsumowanie monitorowania
Na początek – inwentaryzacja małej sieci:
Jeśli przygotujesz szablony dla każdej serii urządzeń sieciowych – możesz osiągnąć korzystny dla analizy układ zbiorczych danych dotyczących aktualnego oprogramowania, numerów seryjnych i powiadomień o przybyciu sprzątaczki do serwerowni (z powodu małego Uptime). Wyciąg mojego listy szablonów poniżej:
A teraz – główny pulpit monitorowania, z rozdzielonymi według poziomów ważności wyzwalaczami:
Dzięki kompleksowemu podejściu do szablonów dla każdego modelu urządzenia w sieci można osiągnąć, że w ramach jednego systemu monitorowania zostanie zorganizowane narzędzie do prognozowania awarii i uszkodzeń (przy dostępnych odpowiednich czujnikach i metrykach). Zabbix doskonale nadaje się do monitorowania infrastruktury sieciowej, serwerowej i usługowej, a zadanie dotyczące konserwacji sprzętu sieciowego wyraźnie pokazuje jego możliwości.
Lista wykorzystanych źródeł:1. Hucaby D. CCNP Routing and Switching SWITCH 300-115 Official Cert Guide. Cisco Press, 2014. s. 325-329.
2. RFC 3410.
3. RFC 3415.
4. Przewodnik konfiguracyjny SNMP, Cisco IOS XE Release 3SE. Rozdział: SNMP Wersja 3.
Źródło: habr.com
