(T) Teoria protokołu SNMP*

Wprowadzenie do protokołu SNMP

Podstawowe zagadnienia dotyczące protokołu SNMP

  • Agent SNMP – Oprogramowanie działające na przełączniku bądź innym urządzeniu sieciowym. Zbierające oraz przechowujące informacje zebrane na temat konfiguracji oraz statusu lokalnego urządzenia.
  • Manager SNMP – Urządzenie zbierające informacje, od wszystkich skonfigurowanych agentów SNMP.
  • NMS (Network Management Station) – Oprogramowanie pobierające informacje od agentów SNMP.
  • MIB (Management Information Base) – Lokalna baza agenta SNMP, zawierającą zmienne określające poszczególne parametry lokalnego urządzenia. Pośród różnych wartości MIB istnieją zmienne uniwersalne dostępne na większości urządzeń jak i te unikalne dla danego producenta czy konkretnej wersji oprogramowania.

Proces wymiany danych pomiędzy agentem a menadżerem SNMP

  • Menadżer NMS systematycznie wysyła zapytania Get Request, w celu pobrania wartości zmiennych zapisanych w bazie MIB, agentów SNMP. Po zweryfikowaniu poziomu dostępu, agent odsyła odpowiedź w formie wiadomości Get Response, zawierającą wartość zmiennej bądź wielu zmiennych pobranych z bazy MIB.
  • Menadżer NMS systematycznie wysyła wiadomości Get w celu pobrania najnowszych informacji na temat śledzonego agenta. Metoda ta nie zapewnia jednak monitoringu w czasie rzeczywistym, aby go osiągnąć agent SNMP musi mieć włączoną opcję wysyłania wiadomości Trap bądź Inform. Dzięki której zyskuje możliwość informowania menadżera NMS o ważnych wydarzeniach w czasie rzeczywistym.
  • Komunikacja pomiędzy agentem a menadżerem NMS może być również inicjowana z poziomu agenta SNMP, w takim przypadku wysyła on notyfikację (Notification) za pomocą wiadomości Trap bądź wiadomości Inform. Komunikacja ta może być zainicjowana przekroczeniem określonego progu wartości zmiennej bazy MIB bądź zajściem nagłego zdarzenia związanego np. z bezpieczeństwem monitorowanego urządzenia. Przykładową sytuacją obligującą agenta SNMP do wysłania wiadomości Trap może być zmiana statusu interfejsu sieciowego z Up na Down.
Wiadomości Trap oraz Inform są wysyłana za pomocą protokołu UDP na porcie 162.
Wiadomości Get oraz Set są wysyłana za pomocą protokołu UDP na porcie 161.

Wiadomości wykorzystywane przez protokół SNMP

  • Wiadomość Trap – Tak samo jak wiadomość Inform, ma za zadanie informować menadżera NMS o ważnych zmiana zachodzących w bazie MIB agenta protokołu SNMP. Chodź obydwie wiadomości mają podobny cel, różnią się w metodzie działania. Wiadomość Trap kieruje się zasadą Fire-and-Forget co oznacza, że po wysłaniu wiadomości agent SNMP nie oczekuje otrzymania potwierdzenia o dotarciu danych od menadżera NMS.
  • Wiadomość Inform – Tak samo jak wiadomość Trap wykorzystuje protokołu UDP w warstwie transportowej, jednak w tym przypadku komunikacja pomiędzy agentem menadżerem a SNMP wzbogacona jest o aplikacyjnie zaimplementowaną osiągalność. Tym samym każda wysłana wiadomość Inform musi być potwierdzona.
  • Wiadomość Get Request – Stanowi żądanie o wartość konkretnej zmiennej MIB.
  • Wiadomość Get Next Request – Stanowi żądanie kolejnej wartości, następującej po tej która została otrzymana.
  • Wiadomość Get Bulk Request – Stanowi żądanie o całą tablicę bądź wartość szeregu zmiennych MIB.
  • Wiadomość Get Response – Stanowi odpowiedź na wiadomości Get Request oraz Get Bulk jak i Get Next.
  • Wiadomość Set Response – Stanowi żądanie o zmianę wartości, konkretnej zmiennej MIB.
  • Wiadomości Get a wersje protokołu SNMP:
    • Get Request, Get Next oraz Get Response wspierają wszystkie wersje protokołu SNMP.
    • Get Bulk wspiera jedynie wersja druga oraz trzecia protokołu SNMP (SNMPv2, SNMPv3).

Zabezpieczanie protokołu SNMP

  • Według zasady „Best Practices” dostęp do agenta SNMP, powinien być zabezpieczony za pomocą listy dostępu ACL, tak aby tylko zaufane stacje NMS mogły pobierać dane z bazy MIB bądź modyfikować jej zawartość.
  • Protokół SNMP w wersji pierwszej (SNMPv1) wykorzystuje mechanizm autentykacji urządzeń za pomocą hasła (Communities) zapisywanego w postaci czystego tekstu (Community String). Hasła wysyłane są za pomocą wiadomości Get bądź Set przy każdej operacji wykonywanej przez menadżera na agencie SNMP.
  • Protokół SNMP w wersji pierwszej określa poziom dostępu menadżera NMS do agenta za pomocą trybu RO (Read-only community) bądź trybu RW (Read-Write community). W przypadku opcji RO agent zezwala na otrzymywanie jedynie wiadomości Get natomiast w przypadku trybu RW przepuszcza zarówno wiadomości pobierające wartości zmiennych z bazy MIB (Get Request) jak i te mające możliwość wprowadzania zmian w bazie (Set Response).
  • Protokół w wersji drugiej (SNMPv2) w swojej pierwotnej wersji nie posiadał podziału na (communities RO oraz RW) jednak jego poprawiona wersja (SNMPv2c) przywróciła usuniętą funkcjonalność protokołu SNMPv1.
  • Protokół SNMP w wersji trzeciej (SNMPv3) ponownie wykluczył podział na (communities RO oraz RW), dodając w zamian szereg funkcjonalności mających zadbać o bezpieczeństwo wymienianych danych. Funkcje te są następujące:
    • Funkcja Message Integrity – Zaimplementowana we wszystkich rodzajach wiadomości SNMPv3, bada czy wysłana wiadomość uległa zmianie, podczas transmisji pomiędzy menadżerem a agentem SNMP.
    • Funkcja Authentication – Zapewnia dodatkową autentykację przy użyciu loginu oraz za-haszowanego hasła.
    • Funkcja Encryption (Privacy) – Zapewnia dodatkowe szyfrowanie zawartości wiadomości SNMPv3.

Porównanie wiadomości Get, Trap & Set, Inform

  • Wiadomości Get / Set odnoszą się do komunikacji menadżer NMS -> Agent SNMP.
  • Wiadomości Trap / Inform odnoszą się do komunikacji Agent SNMP -> menadżer NMS.

MIB – Management Information Base

Struktura bazy MIB

  • Każdy agent protokołu SNMP posiada swoją własną lokalną bazę MIB, zawierającą informację dotyczące lokalnego urządzenia w postaci zmiennych. Każda zmienna nazywana jest przez protokół SNMP obiektem, posiadającym unikalną wartość ID zwaną OID (Object ID).
  • W przypadku przełączników Cisco Catalyst, baza MIB jest na bieżąco aktualizowana danymi zbieranymi w czasie rzeczywistym, następnie dane te są zapisywane w pamięci urządzenia.
  • Baza MIB posiada zorganizowaną strukturę, w której wartości OID są poukładane w formie drzewa, a zapisywane w postaci ciągu liczb oddzielonych od siebie kropkami, przykładowa wartość wygląda następującą 1.3.6.1.4.1.9.2.1.58.0.
  • Każda baza MIB jest napisana w języku ASN.1 (Abstract Syntax Notation 1).

Znaczenie przykładowej wartości OID

  • Wartość OID: 1.3.6.1.4.1.9.9.10
    • 1Iso, 3Org, 6 Dod, 1Internet, 4Private, 1 enterprises, 9Cisco, 9Cisco mgmt, 10 Cisco flash group.

Wersje protokołu SNMP

  • SNMPv1 (RFC 1157).
  • SNMPv2c (RFC 1901).
  • SNMPv3 (RFC 34103415).

SNMPv1 SNMPv2 SNMPv3
Wspiera GET, nie wspiera GET-BULK Wspiera GET jak i GET-BULK Wspiera GET jak i GET-BULK
Wykorzystuje uwierzytelnianie za pomocą strink Wykorzystuje uwierzytelnianie za pomocą community strink Wykorzystuje uwierzytelnianie za pomocą nazwy użytkownika
Nie wspiera szyfrowaniaNie wspiera szyfrowaniaWspiera szyfrowanie

Protokół SNMP w wersji trzeciej

Protokół SNMPv3

  • Protokół SNMP w wersji trzeciej nie wykorzystuje znanego ze wcześniejszych wersji protokołu SNMP, podziału na (communities), w zamian za to oferując podział na grupy oraz użytkowników. Inną dodatkową funkcjonalnością protokołu SNMPv3 jest opcjonalna Enkrypcja wysyłanych wiadomości (Message Encryption), Jak i ogólna poprawa bezpieczeństwa uzyskana przy pomocy każdorazowej weryfikacji integralności (Message Integrity) lub opcjonalnej autentykacji (Message Authentication).
  • Jedną z podstawowych zmian wprowadzonych w protokole SNMPv3, jest nowe podejście do zarządzania bazą MIB. Nowy protokół wykorzystuje system widoków (SNMP Views), określających jakie dane na temat lokalnego urządzenia można monitorować a jakie są nie dostępne. Dodatkowo istnieje możliwość tworzenia własnych widoków.
  • Domyślnym widokiem protokołu SNMPv3 jest widok v1default, ustawiony w konfiguracji tylko do odczytu. Oczywiście istnieje opcjonalna możliwość ustawienia funkcji zarówno odczytu jak i zapisu danych MIB, za pomocą komendy [snmp-server group name v3 noauth write v1default].
  • Protokół SNMP w wersji trzeciej wprowadził nowe funkcje bezpieczeństwa, umożliwiające wybór jednego z trzech scenariuszy zabezpieczeń, wprowadzonych w komunikacji pomiędzy agentem a menadżerem NMS.
    • Podstawowy scenariusz (noauth) – Zapewnia jedynie podstawowe zabezpieczenie integralności wiadomości SNMP.
    • Środkowy scenariusz (auth) – Zapewnia autentykację za pomocą nazwy użytkownika jak i hasła haszowanego za pomocą algorytmu MD5 bądź algorytmu SHA.
    • Zaawansowany scenariusz (priv) – Zapewnia autentykację za pomocą nazwy użytkownika jak i hasła haszowanego za pomocą algorytmu MD5 bądź SHA oraz enkrypcji całej zawartości wiadomości SNMP za pomocą algorytmu DES, 3DES bądź AES.
Komenda Wiadomość Sprawdzanie integralności Autentykacja wiadomości SNMP Enkrypcja wiadomości SNMP
noauth noAuthNoPriv Tak Nie Nie
auth authNoPriv Tak Tak Nie
priv priv Tak Tak Tak

Porównanie metod zabezpieczających komunikację protokołu SNMPv3

Struktura komend wykorzystywana w konfiguracji protokołu SNMPv3

  • Komenda SNMP Group – Tworzy grupę definiującą wersję protokołu SNMP, scenariusz zabezpieczeń, tryb dostępu (Read, Write), widok bazy MIB oraz dodatkowe zabezpieczenia w postaci listy dostępu ACL.
  • Komenda SNMP User – Tworzy użytkownika przypisanego do danej grupy protokołu SNMPv3, określającego konkretne właściwości scenariusza zabezpieczeń, takie jak nazwę użytkownika, opcjonalne hasło z metodą haszowania oraz opcjonalny algorytm enkrypcji wiadomości SNMP (Dane te muszą byś zgodne z wybranym scenariuszem grupy SNMP, inaczej dany użytkownik nie zostanie połączony z określoną grupą, a tym samym połączenie pomiędzy agentem a menadżerem NMS nie zostanie nawiązane). 
  • Komenda SNMP Host – Definiuje dane dotyczące menadżera NMS, określając jego adres IP, wersję protokołu SNMP, scenariusz zabezpieczeń, nazwę użytkownika oraz wersję wysyłanych wiadomości SNMP (Trap, Inform). Dane dotyczące scenariusza zabezpieczeń muszą byś zgodne z wybranym scenariuszem grupy SNMP, inaczej dany menadżer NMS nie zostanie powiązany z określoną grupą SNMP, a tym samym koniunkcja pomiędzy agentem a menadżerem zawiedzie. 

Różnice pomiędzy poszczególnymi wersjami protokołu SNMP

  • Cechy charakterystyczne protokołu SNMPv1:
    • Protokół SNMPv1 wprowadził podstawowe wiadomości Get, Set oraz Trap, wraz z zasadą podziału na (communities).
    • Teoretycznie w przypadku protokołu SNMPv1 tylko menadżer NMS należący do odpowiedniej communities (RW), mógł dokonywać zmian w zawartości bazy MIB danego agenta. Jednak w praktyce pozbawiony zabezpieczeń protokół zezwalał na to każdemu, kto wysłał odpowiednio spreparowane żądanie „Set Request”.
  • Cechy charakterystyczne protokołu SNMPv2c:
    • Protokół SNMPv2c zwiększył wielkość zmiennych z 32 bitów do 64 bitów, wprowadzając również nowe wiadomości Get Bulk oraz Get inform.
  • Cechy charakterystyczne protokołu SNMPv3:
    • Protokół SNMPv3 pozbył się podziału na (communities), zastępując go grupami SNMP. Dodatkowo zwiększył poziom zabezpieczeń wspierany przez system użytkowników, autentykacji, badania integralności oraz enkrypcji wysyłanych wiadomości. Nowy protokół SNMP zmienił również sposób zarządzania bazą MIB wprowadzając widoki (View).
  • Różniące pomiędzy protokołem SNMPv2 & SNMPv2c:
    • Protokół SNMP w wersji drugiej (SNMPv2) nie posiada podziału na (communities) RO oraz RW.
    • Poprawiony protokół SNMP w wersji drugiej (SNMPv2c) ponownie wprowadza podział na (communities).

Pozostałe tematy związane z protokołem SNMP

PDFPRINT

Robert T Kucharski

Cisco Network Engineer in GPW.

Dodaj komentarz