Artykuł ten poświęcony jest funkcjom monitorowania sprzętu sieciowego za pomocą protokołu SNMPv3. Porozmawiamy o SNMPv3, podzielę się swoim doświadczeniem w tworzeniu pełnoprawnych szablonów w Zabbix i pokażę, co można osiągnąć organizując rozproszone powiadamianie w dużej sieci. Protokół SNMP jest głównym protokołem podczas monitorowania sprzętu sieciowego, a Zabbix świetnie nadaje się do monitorowania dużej liczby obiektów i podsumowywania dużych ilości przychodzących metryk.
Kilka słów o SNMPv3
Zacznijmy od celu protokołu SNMPv3 i cech jego zastosowania. Do zadań protokołu SNMP należy 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 restart urządzenia).
Główną różnicą pomiędzy protokołem SNMPv3 a jego poprzednimi wersjami są klasyczne funkcje bezpieczeństwa [1-3], a mianowicie:
- Uwierzytelnianie, które stwierdza, że żądanie zostało otrzymane z zaufanego źródła;
- szyfrowanie (szyfrowanie), aby zapobiec ujawnieniu przesyłanych danych w przypadku ich przechwycenia przez osoby trzecie;
- integralność, czyli gwarancja, że pakiet nie został naruszony podczas transmisji.
SNMPv3 implikuje zastosowanie modelu bezpieczeństwa, w którym strategia uwierzytelniania jest ustalona dla danego użytkownika i grupy, do której on należy (w poprzednich wersjach SNMP żądanie od serwera do obiektu monitorowanego porównywane było jedynie „wspólnotą”, tekstem ciąg znaków z „hasłem” przesyłanym w postaci zwykłego tekstu (zwykły tekst)).
SNMPv3 wprowadza koncepcję poziomów bezpieczeństwa – akceptowalnych poziomów bezpieczeństwa, które określają konfigurację sprzętu i zachowanie agenta SNMP obiektu monitorowanego. Kombinacja modelu bezpieczeństwa i poziomu bezpieczeństwa określa, który mechanizm bezpieczeństwa jest używany podczas przetwarzania pakietu SNMP [4].
Tabela opisuje kombinacje modeli i poziomów bezpieczeństwa SNMPv3 (zdecydowałem się pozostawić trzy pierwsze kolumny jak w oryginale):
W związku z tym będziemy używać SNMPv3 w trybie uwierzytelniania przy użyciu szyfrowania.
Konfigurowanie protokołu SNMPv3
Monitorowanie sprzętu sieciowego wymaga tej samej konfiguracji protokołu SNMPv3 zarówno na serwerze monitorującym, jak i monitorowanym obiekcie.
Zacznijmy od skonfigurowania urządzenia sieciowego Cisco, jego minimalna wymagana konfiguracja wygląda następująco (do konfiguracji używamy CLI, uprościłem nazwy i hasła, 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 includedPierwsza linia snmp-server group – określa grupę użytkowników SNMPv3 (snmpv3group), tryb odczytu (read) oraz uprawnienia grupy snmpv3group do przeglądania niektórych gałęzi drzewa MIB monitorowanego obiektu (następnie nazwa snmpv3 w polu konfiguracja określa, do których gałęzi drzewa MIB grupa może uzyskać dostęp, snmpv3group będzie mogła uzyskać dostęp).
Druga linia snmp-server user – określa użytkownika snmpv3user, jego przynależność do grupy snmpv3group, a także stosowanie uwierzytelniania md5 (hasło dla md5 to md5v3v3v3) i szyfrowania des (hasło dla des to des56v3v3v3). Oczywiście lepiej jest użyć aes zamiast des, podam to tutaj tylko jako przykład. Ponadto definiując użytkownika, możesz dodać listę dostępu (ACL), która reguluje adresy IP serwerów monitorujących, które mają prawo monitorować to urządzenie - to też jest dobra praktyka, ale nie będę komplikować naszego przykładu.
Trzeci wiersz widoku snmp-server definiuje nazwę kodową, która określa gałęzie drzewa MIB snmpv3name, tak aby grupa użytkowników snmpv3group mogła odpytywać je. ISO, zamiast ściśle definiować pojedynczą gałąź, umożliwia grupie użytkowników snmpv3group dostęp do wszystkich obiektów w drzewie MIB obiektu monitorowanego.
Podobna konfiguracja dla 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 monitorującego poprzez protokół SNMPv3, ja skorzystam z snmpwalk:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252
Bardziej wizualnym narzędziem do żądania określonych obiektów OID przy użyciu plików MIB jest snmpget:
Przejdźmy teraz do konfiguracji typowego elementu danych dla SNMPv3 w szablonie Zabbix. Dla uproszczenia i niezależności MIB używam cyfrowych OID:
W kluczowych polach używam niestandardowych makr, ponieważ będą one takie same dla wszystkich elementów danych w szablonie. Możesz je ustawić w ramach szablonu, jeśli wszystkie urządzenia sieciowe w Twojej sieci mają takie same parametry SNMPv3, lub w obrębie węzła sieci, jeśli parametry SNMPv3 dla różnych obiektów monitorowanych są różne:
Należy pamiętać, że system monitorowania posiada jedynie nazwę użytkownika i hasło w celu uwierzytelnienia i szyfrowania. Grupa użytkowników i zakres obiektów MIB, do których dozwolony jest dostęp, są określone w obiekcie monitorowanym.
Przejdźmy teraz do wypełnienia szablonu.
Szablon ankiety Zabbix
Prostą zasadą przy tworzeniu szablonów ankiet jest to, aby były jak najbardziej szczegółowe:
Przywiązuję dużą wagę do zapasów, aby ułatwić pracę z dużą siecią. Więcej na ten temat nieco później, ale na razie – wyzwalacze:
Dla ułatwienia wizualizacji wyzwalaczy, w ich nazwach zawarto makra systemowe {HOST.CONN}, dzięki czemu na dashboardzie w sekcji alertów wyświetlane są nie tylko nazwy urządzeń, ale także adresy IP, choć jest to bardziej kwestia wygody niż konieczności . Aby ustalić, czy urządzenie jest niedostępne, oprócz zwykłego żądania echa, wykorzystuję sprawdzenie niedostępności hosta za pomocą protokołu SNMP, gdy obiekt jest dostępny przez ICMP, ale nie odpowiada na żądania SNMP - taka sytuacja jest możliwa np. , gdy adresy IP są zduplikowane na różnych urządzeniach, z powodu źle skonfigurowanych firewalli lub nieprawidłowych ustawień SNMP na monitorowanych obiektach. Jeśli korzystasz ze sprawdzania dostępności hosta wyłącznie przez ICMP, w momencie badania incydentów w sieci dane z monitorowania mogą nie być dostępne, dlatego należy monitorować ich otrzymanie.
Przejdźmy do wykrywania interfejsów sieciowych – dla sprzętu sieciowego jest to najważniejsza funkcja monitorująca. Ponieważ na urządzeniu sieciowym może znajdować się kilkaset interfejsów, należy odfiltrować te niepotrzebne, aby nie zaśmiecać wizualizacji i nie zaśmiecać bazy danych.
Używam standardowej funkcji wykrywania SNMP z większą liczbą wykrywalnych parametrów, aby zapewnić bardziej elastyczne filtrowanie:
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]
Dzięki temu odkryciu możesz filtrować interfejsy sieciowe według ich typów, niestandardowych opisów i statusów portów administracyjnych. Filtry i wyrażenia regularne do filtrowania w moim przypadku wyglądają tak:
W przypadku wykrycia następujące interfejsy zostaną wykluczone:
- ręcznie wyłączone (adminstatus<>1), dzięki IFADMINSTATUS;
- bez opisu tekstowego, dzięki IFALIAS;
- posiadanie symbolu * w opisie tekstowym, dzięki IFALIAS;
- które mają charakter usługowy lub techniczny, dzięki IFDESCR (w moim przypadku w wyrażeniach regularnych IFALIAS i IFDESCR są sprawdzane przez jeden alias wyrażenia regularnego).
Szablon zbierania danych przy wykorzystaniu protokołu SNMPv3 jest już prawie gotowy. Nie będziemy rozwodzić się bardziej szczegółowo nad prototypami elementów danych dla interfejsów sieciowych, przejdźmy do wyników.
Wyniki monitoringu
Na początek zinwentaryzuj małą sieć:
Jeśli przygotujesz szablony dla każdej serii urządzeń sieciowych, możesz uzyskać łatwy do analizy układ podsumowujących danych na temat aktualnego oprogramowania, numerów seryjnych i powiadomienia o przybyciu sprzątacza na serwer (ze względu na niski czas pracy). Fragment mojej listy szablonów znajduje się poniżej:
A teraz - główny panel monitorujący, z wyzwalaczami rozmieszczonymi według poziomu ważności:
Dzięki zintegrowanemu podejściu do szablonów dla każdego modelu urządzenia w sieci możliwe jest zapewnienie, że w ramach jednego systemu monitorowania zorganizowane zostanie narzędzie do przewidywania usterek i wypadków (o ile dostępne będą odpowiednie czujniki i metryki). Zabbix doskonale nadaje się do monitorowania infrastruktury sieciowej, serwerowej i usługowej, a zadanie utrzymania sprzętu sieciowego wyraźnie pokazuje jego możliwości.
Lista wykorzystanych źródeł:1. Oficjalny przewodnik po certyfikatach Hucaby D. CCNP Routing i przełączanie SWITCH 300-115. Cisco Press, 2014. s. 325-329.
2. RFC 3410.
3. RFC 3415.
4. Przewodnik konfiguracji SNMP, Cisco IOS XE wydanie 3SE. Rozdział: SNMP wersja 3.
Źródło: www.habr.com