Simple Network Management Protocol (SNMP)

1. Dlaczego Sieci Wymagają Zarządzania

Sieć korporacyjna może zawierać setki lub tysiące routerów, przełączników, serwerów, drukarek i stacji roboczych. Administrator potrzebuje bieżących informacji o dostępności urządzeń, licznikach interfejsów, wykorzystaniu łączy i progach zasobów. Ręczne logowanie do każdego urządzenia nie dostarcza tych danych z wymaganą skalą ani częstotliwością.

Potrzebna jest więc ustandaryzowana i skalowalna metoda monitorowania oraz zarządzania urządzeniami. Zapewnia ją Prosty Protokół Zarządzania Siecią (SNMP). Definiuje on komunikaty i nazwy obiektów, dzięki którym urządzenia oraz aplikacje zarządzające wymieniają informacje w sieci IP. NMS może zbierać te informacje, prezentować je i stosować reguły alarmowania lub konfiguracji.

2. Główne Komponenty Architektury SNMP

Architektura SNMP wykorzystuje menedżera i zarządzane jednostki. Urządzenie zarządzane może zawierać agenta SNMP, a Stacja Zarządzania Siecią (NMS) uruchamia aplikacje menedżera i odbiera powiadomienia. Taki podział pozwala menedżerowi używać tych samych operacji protokołu z urządzeniami różnych producentów, podczas gdy każdy agent odwzorowuje je na lokalny stan sprzętu i oprogramowania.

• Urządzenie Zarządzane (Managed Device)

  Jest to dowolne urządzenie w sieci, które zawiera informacje wymagające monitorowania lub zarządzania. Może to być wszystko, od prostej drukarki po złożony router rdzeniowy. Przykłady obejmują przełączniki, serwery, stacje robocze, zapory sieciowe, a nawet czujniki środowiskowe.

• Agent SNMP (SNMP Agent)

  Agent SNMP to moduł oprogramowania działający na urządzeniu zarządzanym. Udostępnia lokalne informacje zarządcze, takie jak użycie pamięci, obciążenie procesora i statystyki interfejsów, jako obiekty SNMP. Nasłuchuje żądań menedżera, pobiera żądane wartości i odsyła odpowiedzi. Może także generować powiadomienia, gdy wystąpi skonfigurowane zdarzenie.

• Stacja Zarządzania Siecią (NMS)

  NMS to aplikacja zarządzająca używana przez administratorów do monitorowania i kontrolowania sieci. Odpytuje agentów na urządzeniach, zbiera dane o wydajności, wyświetla wykresy lub pulpity nawigacyjne oraz analizuje wyniki pod kątem trendów i usterek. NMS może także odbierać powiadomienia, takie jak trapy i informy wysyłane przez agentów.

3. Definicje MIB i OID

NMS i agenci potrzebują wspólnych definicji informacji zarządczych, które wymieniają. Definicje te dostarczają moduły Bazy Informacji Zarządczej (MIB) oraz Identyfikatory Obiektów (OID).

Baza informacji zarządczej MIB

MIB to formalna specyfikacja określająca zarządzalne obiekty, ich identyfikatory, typy i informacje o dostępie. Moduł MIB jest zwykle reprezentowany jako tekst z użyciem Structure of Management Information (SMI), której zapis opiera się na ASN.1 (Abstract Syntax Notation One). Dla każdego parametru, takiego jak czas działania systemu lub liczba pakietów na interfejsie 2, MIB definiuje kilka właściwości:

• Nazwę tekstową (np. 'sysUpTime').
• Unikalny adres, zwany Identyfikatorem Obiektu (OID).
• Typ danych parametru (np. liczba całkowita, licznik, ciąg znaków).
• Prawa dostępu (np. tylko do odczytu lub do odczytu i zapisu).

MIB jest schematem i nie jest bazą danych przechowywaną na urządzeniu. NMS ładuje odpowiedni moduł MIB, aby interpretować nazwy i wartości obiektów otrzymywanych od agenta. Agent może implementować obiekty bez przechowywania tekstu modułu. Moduł zapisuje także składnię obiektu i reguły dostępu, dzięki czemu narzędzia jednolicie interpretują zwracaną wartość.

Identyfikatory obiektów i drzewo MIB

OID to unikalny adres obiektu zarządzanego lub jego instancji. OID tworzą globalną hierarchię, często nazywaną drzewem MIB. Jej korzenie i gałęzie są przydzielane przez organizacje normalizacyjne, takie jak ISO i ITU, a poddrzewa są delegowane innym organizacjom. Na przykład:

Gdy NMS chce poznać opis systemu urządzenia, żąda wartości OID $1.3.6.1.2.1.1.1.0$. Końcowe $.0$ jest identyfikatorem instancji, wskazującym, że jest to obiekt skalarny (obiekt, który ma tylko jedną instancję). Dla obiektów tabelarycznych, takich jak tabela interfejsów, identyfikator instancji odpowiadałby indeksowi wiersza (np. numerowi interfejsu).

4. Podstawowe Operacje SNMP

NMS i agenci komunikują się za pomocą małego zestawu Jednostek Danych Protokołu (PDU). Każda PDU określa operację i przenosi nazwy obiektów, wartości albo informacje o stanie.

• Żądanie GET: Jest to komunikat wysyłany z NMS do agenta w celu pobrania wartości jednego lub więcej określonych OID. Na przykład: "GET $1.3.6.1.2.1.1.1.0$".
• Żądanie GETNEXT: Służy do "przechodzenia" po drzewie MIB. Prosi agenta o wartość OID, który występuje w drzewie MIB następny po podanym. Jest to przydatne do odkrywania wszystkich obiektów, które obsługuje urządzenie, lub do odczytywania wszystkich wierszy w tabeli bez znajomości ich liczby.
• Żądanie GETBULK:Zdefiniowane dla rodziny protokołów SNMPv2 i używane także w SNMPv3, rozszerza ideę GETNEXT. Pozwala NMS zażądać bloku danych w jednej transakcji (na przykład "daj mi następne 10 obiektów"), ograniczając liczbę podróży tam i z powrotem podczas odpytywania dużych tabel, takich jak tablice routingu.
• Żądanie SET: Wysyłane z NMS do agenta w celu zmiany wartości obiektu zarządzanego, pod warunkiem, że obiekt ten jest zdefiniowany jako do odczytu i zapisu w MIB. W ten sposób SNMP jest używany do zarządzania i konfiguracji (np. zmiana nazwy kontaktowej urządzenia lub wyłączenie interfejsu).
• TRAP: W przeciwieństwie do poprzednich poleceń inicjowanych przez menedżera, TRAP jest niezamówionym, asynchronicznym powiadomieniem wysyłanym od agenta do NMS. Agenta można skonfigurować do wysyłania trapów przy zdarzeniach takich jak awaria łącza, ponowne uruchomienie urządzenia lub błąd uwierzytelniania. TRAP nie wymaga potwierdzenia, więc agent nie otrzymuje informacji, czy menedżer go odebrał.
• INFORM: INFORM jest podobny do TRAP, ale jest to powiadomienie potwierdzane. Gdy agent wysyła INFORM, oczekuje potwierdzenia od NMS. Jeśli potwierdzenie nie zostanie odebrane, agent może ponownie wysłać INFORM. Zapewnia to większą niezawodność dla krytycznych alertów.
• Odpowiedź: Jest to komunikat używany przez agenta do odesłania danych żądanych przez komunikaty GET, GETNEXT lub GETBULK albo do potwierdzenia powodzenia lub niepowodzenia polecenia SET.

5. Ewolucja Wersji i Bezpieczeństwa SNMP

Wersje SNMP różnią się operacjami protokołu i modelami bezpieczeństwa. Zmiany od SNMPv1 do SNMPv3 dotyczą skalowalności, rozmiaru liczników, uwierzytelniania, prywatności i kontroli dostępu.

• SNMPv1: Pierwsza wersja

  Pierwsza wersja SNMP opierała się na bardzo prostym mechanizmie uwierzytelniania zwanym ciągami community. Były to w zasadzie hasła w postaci czystego tekstu, współdzielone między NMS a wszystkimi jego agentami. NMS wysyłał ciąg community wraz ze swoim żądaniem, a jeśli pasował do skonfigurowanego na agencie, dostęp był udzielany. Metoda ta jest niebezpieczna, ponieważ każdy, kto przechwyci ruch sieciowy, może odczytać ciąg community i użyć go do uzyskania nieautoryzowanego dostępu.

• SNMPv2c: Wersja v2 Oparta na Community

  SNMPv2 wprowadził kilka ulepszeń protokołu, w tym wydajną operację 'GETBULK' oraz wsparcie dla 64-bitowych liczników (niezbędnych do monitorowania szybkich interfejsów sieciowych, gdzie 32-bitowe liczniki mogłyby się zbyt szybko zerować). Jednak najszerzej wdrożony wariant, SNMPv2c, nadal używał tego samego niebezpiecznego modelu bezpieczeństwa opartego na ciągach community, co SNMPv1. Litera 'c' w v2c oznacza 'community'.

• SNMPv3: Standardowe modele bezpieczeństwa

  SNMPv3 dodaje podsystem bezpieczeństwa i rozdziela modele bezpieczeństwa od kontroli dostępu. Model Bezpieczeństwa Oparty na Użytkowniku (USM) jest często używany do uwierzytelniania komunikatów i zapewniania prywatności. Zastępuje globalny ciąg community indywidualnymi użytkownikami i poświadczeniami. Uprawnienia dostępu definiuje osobno Model Kontroli Dostępu Oparty na Widokach (VACM). Razem mechanizmy te zapewniają trzy usługi bezpieczeństwa:

  • Uwierzytelnianie: Sprawdza źródło komunikatu i wykrywa jego modyfikację w trakcie przesyłania. USM obejmuje starsze algorytmy HMAC-MD5-96 i HMAC-SHA-96, a późniejsze rozszerzenia definiują także warianty HMAC-SHA-2. Wybór algorytmu zależy od implementacji i polityki wdrożenia.
  • Prywatność (Szyfrowanie): Szyfruje zawartość komunikatu SNMP, aby uniemożliwić jego odczytanie przez osoby postronne. Starszy wariant USM wykorzystuje DES, a rozszerzenie prywatności USM definiuje także AES. Wybór zależy od implementacji i polityki wdrożenia.
  • Kontrola Dostępu: VACM pozwala administratorom precyzyjnie definiować, które obiekty użytkownik lub grupa bezpieczeństwa może odczytywać albo modyfikować, zapewniając szczegółowe uprawnienia zarządzania.

  SNMPv3 definiuje trzy poziomy bezpieczeństwa: 'noAuthNoPriv' (bez uwierzytelniania i prywatności), 'authNoPriv' (uwierzytelnianie bez prywatności) oraz 'authPriv' (uwierzytelnianie z prywatnością). Wybrany poziom powinien wynikać z polityki wdrożenia. 'authPriv' zapewnia oba mechanizmy, gdy dane zarządzania ich wymagają.

6. SNMP i Warstwa Transportowa: UDP

SNMP definiuje odwzorowania transportowe i jest często wdrażany z użyciem User Datagram Protocol (UDP). UDP nie wymaga ustanawiania połączenia i ma mały nagłówek, co pasuje do odpytywania oraz powiadomień, lecz nie gwarantuje dostarczenia ani kolejności i nie zapewnia retransmisji ani korekcji uszkodzonych datagramów. Jego suma kontrolna może wykryć część uszkodzeń, gdy jest używana.

• NMS wysyła żądania na port agenta $161$.
• Agent wysyła TRAPy lub INFORMY na port NMS $162$.

Ponieważ UDP jest bezpołączeniowy, możliwa jest utrata dostarczenia, a transport nie porządkuje komunikatów. Dla powiadomień wymagających potwierdzenia PDU typu "INFORM" wymaga odpowiedzi, a aplikacja może ponowić jego wysłanie, dodając niezawodność ponad UDP.