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 Trapbą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 Trapbą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 Getbądź Setprzy 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 ROagent zezwala na otrzymywanie jedynie wiadomości Get natomiast w przypadku trybu RWprzepuszcza 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:
FunkcjaMessage 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.
FunkcjaAuthentication – Zapewnia dodatkową autentykację przy użyciu loginu oraz za-haszowanego hasła.
FunkcjaEncryption(Privacy) – Zapewnia dodatkowe szyfrowanie zawartości wiadomości SNMPv3.
Porównanie wiadomości Get, Trap & Set, Inform
Wiadomości Get/ Setodnoszą się do komunikacji menadżer NMS -> Agent SNMP.
Wiadomości Trap/ Informodnoszą 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).
Wykorzystuje uwierzytelnianie za pomocą community strink
Wykorzystuje uwierzytelnianie za pomocą nazwy użytkownika
Nie wspiera szyfrowania
Nie wspiera szyfrowania
Wspiera 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 (MessageEncryption), 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 (SNMPViews), 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.
Ś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).
Dodaj komentarz