SNMP (Simple Network Management Protocol)

SNMP jest jednym z najważ?niejszych zbiorów norm definiują?cych protokoł?y, usł?ugi i bazy danych potrzebne do zarzą?dzania sieciami TCP/IP. Na tę? zł?oż?oną? strukturę? zarzą?dzania skł?adają? się? cztery zasadnicze czę?ś?ci:

• ?Stacja zarzą?dzania - SMN (Station Management Network), którą? jest najczę?ś?ciej samodzielne urzą?dzenie z oprogramowaniem menedż?era systemu zarzą?dzania siecią?. SMN dysponuje bazą? informacji pochodzą?cych z róż?nych zarzą?dzanych jednostek oraz aplikacjami analizują?cymi ruch, tworzą?cymi statystyki, korygują?cymi bł?ę?dy itp.
• ?Agent zarzą?dzania, w postaci programu instalowanego na jednostce zarzą?dzanej - ruterze, przeł?ą?czniku, zasilaczu UPS czy serwerze. Każ?dy agent musi uż?ywać? protokoł?u SNMP UDP oraz IP. W systemach, gdzie czę?ś?ć? urzą?dzeń? nie uż?ywa SNMP funkcjonuje agent zastę?pczy - proxy, który przeprowadza konwersję? komunikatów. Agent zastę?pczy moż?e obsł?ugiwać? jedno lub wiele takich urzą?dzeń?, gdyż? jest instalowany na jednostce wybranej przez administratora. Przez agenta zastę?pczego musi się? również? komunikować? stacja zarzą?dzania SNMPv2 lub v3 z urzą?dzeniem uż?ywają?cym SNMPv1.
• ?Baza informacji MIB (Management Intormation Base), opisują?ca obiekty zaimplementowane w okreś?lonym wę?ź?le sieci (ruterze, przeł?ą?czniku itp.), niezależ?na od protokoł?u SNMP. Zasoby sieci są? reprezentowane przez obiekty. Każ?dy obiekt jest zmienną? charakteryzują?cą? jedną? cechę? zarzą?dzania agenta. Zbiór tych zmiennych stanowi bazę? MIB. Obiekt moż?e na przykł?ad reprezentować? tablicę? adresów gromadzonych w okreś?lonym wę?ź?le, a nie jej wiersz. Wszystkie definicje zmiennych muszą? być? zgodne z reguł?ami ję?zyka formalnego ASN.1. Obiekt jest rozpoznawany po identyfikatorze 010 (Object IDentifier).
• ?Protokół? zarzą?dzania siecią? - SNMP uż?ywany do przenoszenia informacji zarzą?dzają?cych mię?dzy jednostkami SNMP. Wymiana informacji mię?dzy menedż?erem i agentem oraz mię?dzy menedż?erami ma formę? komunikatu SNMP - cią?gu pól zgodnego z ASN. 1. Protokół? SNMP nie ma ustalonego pakietu. Na ruch SNMP skł?adają? się? pakiety przenoszą?ce ś?ciś?le zdefiniowane sekwencje SNMP umieszczane w polu Dane protokoł?u UDP który z kolei bę?dzie przenoszony przez IP.

Zarzą?dzanie oparte na standardach internetowych charakteryzuje się? modularnoś?cią? architektury. Cał?a struktura jest wię?cej niż? tylko protokoł?em przenoszenia danych. W jej skł?ad wchodzą?: ję?zyk definiowania danych, formaty informacji, definicje zarzą?dzania informacją?, zbiory operacji zwią?zane z zarzą?dzaniem oraz mechanizmy bezpieczeń?stwa i zarzą?dzania. Z czasem struktura ewoluował?a z SNMPv1 (pierwotna nazwa - SNMP), przez SNMPv2 do SNMPv3. Każ?da kolejna wersja był?a bogatsza, ale fundamenty pozostawał?y spójne. SNMPv2 z róż?nych przyczyn nie został? zaakceptowany jako standard zarzą?dzania. Wprawdzie mógł? być? implementowany, ale wymagał? bardzo skomplikowanych operacji konfiguracyjnych, a ponadto nie był? zgodny z projektem wstę?pnym. Jego specyfikacje zawarte w siedmiu RFC miał?y status propozycji standardu SNMPv3. Zdecydowano się? na tę? nową? nazwę? z potrzeby peł?nego rozproszenia wszystkich niejasnoś?ci powstał?ych wokół? róż?nych wersji SNMPv2: SNMPv2p, SNMPv2c ("c" od community z SNMPv1), SNMPv2u (propozycja IBM) i SNMPv2* (propozycja Hewlett-Packarda).

Koncepcja wspólnoty SNMP - community - opisana w RFC 1257 to w istocie relacje mię?dzy agentem i zbiorem menedż?erów. Wspólnotę? definiuje agent, umoż?liwiają?c w ten sposób dostę?p do swojej MIB tylko wybranej grupie menedż?erów. Wspólnot moż?e być? tyle, ile jest kombinacji cech uwierzytelnienia, kontroli dostę?pu i zastę?pstw proxy. Każ?da wspólnota ma swoją? lokalnie niepowtarzalną? nazwę?, którą? przyporzą?dkowani jej menedż?erowie muszą? każ?dorazowo podać? przy operacjach Get i Set. W sumie jest to dosyć? skromny aparat bezpieczeń?stwa.

Widok (view) MIB jest podzbiorem udostę?pnianym okreś?lonej róż?nym wspólnotom. Ale definiuje się? dla społ?ecznoś?ci również? tryb dostę?pu do podzbioru, read-only lub write-only. Widok MIB i tryb dostę?pu tworzą? profil wspólnoty SNMP. Wspólnota SNMP i profile społ?ecznoś?ci to polityka kontroli dostę?pu.

Gł?ównym powodem zauważ?alnej modularnoś?ci SNMP był?o umoż?liwienie cią?gł?ej ewolucji, jak to ujmuje RFC 1052. Począ?tkowo przewidywano,ż?e ta wł?aś?nie cecha miał?a uł?atwić? przejś?cia z sieci, w których zarzą?dzanie oparto na SNMP do zarzą?dzania opartego na protokoł?ach OSI (wtedy jeszcze prawie nikt nie przypuszczał?, ż?e model TCP/IP wyprze OSI). Historia pokazał?a, ze wybór tej architektury był? dobrą? decyzją? powzię?ta ze zł?ych przesł?anek - okazał?o się?, ż?e architektura raczej uł?atwił?a przejś?cie z SNMPv1 na SNMPv2 i z SNMPv2 ra SNMPv3 niż? uł?atwił?a przejś?cie od jakiegoś? zarzą?dzania do opartego na SNMP.

W architekturze SNMPv3 moż?na się? dopatrzyć? wielu koncepcji znanych z architektur SNMPv1 i v2. Jednak w niektórych przypadkach funkcje i terminologia róż?nią? się? w wię?kszym czy mniejszym stopniu. Oryginalny syslem SNMPv1 skł?ada się? trzech dokumentów:

• ?RFC 1155, definiują?cym SMI (Structure ot Management Information)  mechanizmy uż?yte do opisu i nazewnictwa obiektów na potrzeby zarzą?dzania;
• ?RFC 1212, zawierają?cy bardziej zwię?zł?y opis mechanizmu, ale cał?kowicie zgodny z SMI;
• ?RFC 1157, definiują?cym SNMP (Simple Network Management Protocol) - protokół? dostę?pu sieciowego do zarzą?dzanych obiektów.

SNMPv1 wprowadza takż?e koncepcję? usł?ugi uwierzytelnienia wspierają?cej jeden lub kilka schematów. W SNMPv3 koncepcja usł?ug uwierzytelniania został?a wzbogacona o inne usł?ugi, np. prywatnoś?ć?. Jeś?li jednak struktura SNMPv1 antycypuje definicje wielu schematów uwierzytelniania, to nie definiuje ż?adnego innego schematu niż? oparty na cią?gach znaków. Był?a to najwię?ksza sł?aboś?ć? SNMPv1. Wreszcie SNMPv1 wprowadza kontrolę? dostę?pu opartą? na koncepcji widoku bazy - SNMP MIB view. SNMPv3 specyfikuje fundamentalnie podobną? koncepcję? o nazwie view-based access control. Jej model zostanie nazwany VACM.

Z kolei SNMPv2 jest w peł?ni opisany w dokumentach RFC od 1902 do 1907. Kwestie koegzystencji i przejś?cia odnoszą?ce się? do SNMPv1 i SNMPv2 został?y przedstawione w RFC 1908. W porównaniu z pierwszą? wersja, SNMPv2 wnosi kilka ulepszeń?:

• ?rozszerzony typy danych: 54-bitowy licznik;
• ?wię?kszą? wydajnoś?ć? i sprawnoś?ć?: polecenie get bulk (menedzer do
• ?agenta; po jednym poleceniu moż?e uzyskać? duż?y blok danych);
• ?informowanie o zdarzeniach u nadawcy: polecenie inform (menedż?er do menedż?era) umoż?liwia też? współ?dzielenie odpowiedzialnoś?ci za administrowanie wię?kszymi sieciami;
• ?rozbudowane reagowanie na bł?ę?dy i wyją?tki;
• ?zaawansowane ustawienia;
• ?dobrze dobrany ję?zyk definiowania danych.
• Jednakż?e struktura SNMPv2, jaka został?a opisana w RFC1902 -1907, jest niekompletna w takim znaczeniu, ż?e nie speł?nia oryginalnych celów projektu SNMPv2. Chodzi przede wszystkim o warunki zarzą?dzania oraz bezpieczeń?stwa tzw. jakoś?ci komercyjnej, obejmują?ce:
• ?identyfikację?: identyfikacja pochodzenia, integralnoś?ć? przesył?ki i niektóre aspekty ochrony typu replay protection (wymuszanie powtórzenia wiadomoś?ci);
• ? prywatnoś?ć?, poufnoś?ć?;
• ?autoryzację? i kontrolę? dostę?pu;
• ? odpowiednie dla tych wł?asnoś?ci zdalne konfigurowanie i administrowanie.

• ?Bezpieczeń?stwo - identyfikacja i prywatnoś?ć?, autoryzacja i kontrola
• ?Strukturę? zarzą?dzania - nazewnictwo jednostek, społ?ecznoś?ci i polityki uż?ytkowników i zarzą?dzanie kluczem, strony przeznaczenia, relacja proxy: zdalnie konfigurowanie przez operacje SNMP

Specyfikacja zarzą?dzania w strukturze SNMPv3 jest rozparcelowana modularnie na kilka dokumentów. Intencja SMNPv3 Working Group jest czytelna: wszystkie dokumenty powinny być? przeglą?dane, aktualizowane i modyfikowane indywidualnie, Dokumenty, które specyfikują? zarzą?dzanie SNMPv3, mogą? być? pogrupowane w 4 gł?ównych kategoriach: ję?zyk definiowania danych, moduł?y MIB, operacje protokoł?u i bezpieczeń?stwo wraz z administrowaniem. Pierwsze trzy są? wł?ą?czone z SNMPv2. Czwarta jest nowa, ale oparta na wcześ?niejszych pracach.

Specyfikacja ję?zyka definicji danych jest zawarta w RFC 2578 The Structure of Management Intormation Version 2 (SMIv2). SMI (Strueture of Management Intormation) precyzuje fundamentalne typy danych, model obiektu i reguł?y zapisywania i korekty moduł?ów MIB. Informacje uzupeł?niają?ce są? zaw3rtewRFC 2579, definiują?cym zbiór skrótów w moduł?ach MIB, i RFC 2580 - okreś?lają?cym format dla instrukcji zgodnoś?ci.

Moduł?y MIB, zawierają?ce zazwyczaj definicje obiektów, mogą? zawierać? definicje zgł?oszeń?, a czasem instrukcje zgodnoś?ci (compliance statements), specyfikowane w zakresie odpowiednich grup obiektów. Moduł?y są? zdefiniowane zgodnie z reguł?ami okreś?lonymi w dokumentach specyfikują?cych ję?zyk definicji danych, gł?ównie SMI. Liczba tych moduł?ów jest duż?a i stale roś?nie. Do potowy lutego 2002 r. powstał?o ponad 100 standardowych moduł?ów MIB, a sumaryczna liczba zdefiniowanych obiektów przekracza 10 tys. Ponadto równie wielka, i też? rosną?ca, jest liczba moduł?ów MIB specyficznych, zdefiniowanych przez róż?nych producentów, grupy badawcze, konsorcja. Najogólniej - informacje zarzą?dzają?ce zdefiniowane w jakimś? module MIB, bez wzglę?du na wersję? uż?ytego ję?zyka definicji danych, mogą? być? uż?yte z dowolną? wersją? protokoł?u. Na przykł?ad moduł?y MIB zdefiniowane w kategoriach SMI SNMPv1 są? kompatybilne ze strukturą? _NMPv3 i mogą? być? przenoszone przez protokoł?y, Również? odwrotnie: zdefiniowane moduł?y MIB uż?ywają?ce SMI SNMPv2 są? kompatybilne z operacjami Specyfikacja zarzą?dzania w strukturze SNMPv3 jest rozparcelowana modularnie na kilka dokumentów. Intencja SMNPv3 Working Group jest czytelna: wszystkie dokumenty powinny być? przeglą?dane, aktualizowane i modyfikowane indywidualnie, Dokumenty, które specyfikują? zarzą?dzanie SNMPv3, mogą? być? pogrupowane w 4 gł?ównych kategoriach: ję?zyk definiowania danych, moduł?y MIB, operacje protokoł?u i bezpieczeń?stwo wraz z administrowaniem. Pierwsze trzy są? wł?ą?czone z SNMPv2. Czwarta jest nowa, ale oparta na wcześ?niejszych pracach.

Specyfikacja ję?zyka definicji danych jest zawarta w RFC 2578 The Structure of Management Intormation Version 2 (SMIv2). SMI (Strueture of Management Intormation) precyzuje fundamentalne typy danych, model obiektu i reguł?y zapisywania i korekty moduł?ów MIB. Informacje uzupeł?niają?ce są? zaw3rtewRFC 2579, definiują?cym zbiór skrótów w moduł?ach MIB, i RFC 2580 - okreś?lają?cym format dla instrukcji zgodnoś?ci.

 Moduł?y MIB, zawierają?ce zazwyczaj definicje obiektów, mogą? zawierać? definicje zgł?oszeń?, a czasem instrukcje zgodnoś?ci (compliance statements), specyfikowane w zakresie odpowiednich grup obiektów. Moduł?y są? zdefiniowane zgodnie z reguł?ami okreś?lonymi w dokumentach specyfikują?cych ję?zyk definicji danych, gł?ównie SMI. Liczba tych moduł?ów jest duż?a i stale roś?nie. Do potowy lutego 2002 r. powstał?o ponad 100 standardowych moduł?ów MIB, a sumaryczna liczba zdefiniowanych obiektów przekracza 10 tys. Ponadto równie wielka, i też? rosną?ca, jest liczba moduł?ów MIB specyficznych, zdefiniowanych przez róż?nych producentów, grupy badawcze, konsorcja. Najogólniej - informacje zarzą?dzają?ce zdefiniowane w jakimś? module MIB, bez wzglę?du na wersję? uż?ytego ję?zyka definicji danych, mogą? być? uż?yte z dowolną? wersją? protokoł?u. Na przykł?ad moduł?y MIB zdefiniowane w kategoriach SMI SNMPvsą? kompatybilne ze strukturą? SNMPv3 i mogą? być? przenoszone przez protokoł?y. Również? odwrotnie: zdefiniowane moduł?y MIB uż?ywają?ce SMI SNMPv2 są? kompatybilne z operacjami protokoł?u SNMPv1. Ale z jednym waż?nym wyją?tkiem. Jest nim typ danych Counter64, wprowadzony w SMI SNMPv2: motor protokoł?u SNMPv1 nie jest zdolny przenosić? tego typu danych.

Specyfikacje dla operacji protokoł?u i odwzorowania transportu struktury SNMPv3 są? wł?ą?czone przez odniesienie do dwóch dokumentów struktury SNMPv2, odpowiednio 1905 i 1906. Z kolei bezpieczeń?stwo i zarzą?dzanie SNMPv3, zdefiniowane przez SNMPv3 Working Group, charakteryzuje seria sześ?ciu dokumentów:

• ? RFC 2570 Introduetion to version 3 ot the Internet-standard NetworkManagement Framework - streszczenia SNMPv3;
• ? RFC 2571 An Arehiteeture tor Describing SNMP Management Framelorks- opis architektury ogólnej ze specjalnym uwzglę?dnieniem architektu_bezpieczeń?stwa i zarzą?dzania;
• ? RFC 2572 Message Processing and Dispatehing tor the Stropie NettworkManagement Protocol (SNMP) - opisuje moż?liwe modele przetwarzania komunikatu i zadania programu szeregują?cego, które mogą? być? czę?ś?cią? motoru protokoł?u SNMP;
• ?RFC 2573 - charakteryzuje 5 typów aplikacji, które mogą? być? kojarzone z motorem SNMPv3 i elementy procedur;
• ? RFC 2574 - opisuje zagroż?enia, mechanizmy, protokoł?y i wspierane dane uż?yte do bezpieczeń?stwa na poziomie wiadomoś?ci (message level seeurty) SNMP
• ?. RFC 2575 - przedstawia VACM (View-based Aeeess Control Moden, czyli model kontroli dostę?pu do bazy danych zastosowany w architekturze SNMP

• ?motorów i aplikacji;
• ?jednostek (dostawców usł?ug, jak jednostki w agentach i menedż?erach);
• ?toż?samoś?ci (uż?ytkownicy usł?ug);
• ?informacji zarzą?dzają?cych, obejmują?cych wsparcie dla wielu logicznych kontekstów.

RFC 2572 opisuje MPO (Message Processing and Dispatch) dla wiadomoś?ci SNMP w architekturze SNMP Definiuje procedury dla kojarzenia (szeregowanie i dystrybucja) potencjalnie wielu wersji wiadomoś?ci SNMP z wł?aś?ciwym modelem przetwarzania wiadomoś?ci SNMP MPM (Message Processing Models). Precyzuje takż?e procedury dla koordynowania PDU z aplikacjami SNMP Ten dokument opisuje jeden model MPM - SNMPv3 MPM, Motor protokoł?u SNMPv3 musi wspierać? przynajmniej jeden MPM. Na przykł?ad wieloję?zyczny system moż?e jednocześ?nie wspierać? SNMPv3 i SNMPv1 czy SNMPv2c.

Celem RFC 2573 jest opisanie pię?ciu typów aplikacji, które mogą? być? kojarzone z motorem SNMP Aplikacjami tymi są?: Command Generators, Command Responders, Notitieation Originators, Notitieation Reeeivers i Proxy Forwarders,

• ?Aplikacje, które inicjują? ż?ą?dania SNMP Read-Class (klasy Odczyt) i/lub Write-Class (klasy lapis), są? nazywane Command Generators - generatory poleceń?.
• ?Aplikacja odpowiadają?ca na zapytania SNMP Read-Class i WriteClass to Command Responder. Aplikacja otrzymuje ż?ą?dania kierowane do systemu lokalnego. W odpowiedzi bę?dzie wykonywał?a m. in. operacja wł?aś?ciwe dla protokoł?u, przeprowadzają?c kontrolę? dostę?pu.
• ?Aplikacje, które generują? jednostki danych protokoł?u SNMP typu Notitieation-Class został?y nazywane Notitieation Originators; monitorują? one system w kontekś?cie szczególnych zdarzeń? i warunków oraz generują? wiadomoś?ci Notitieation Class (Contirmed-Class, jak i Uneontirmed-Class) na podstawie tych zdarzeń? i warunków. Aplikacja Nonitieation Originator musi rozpoznawać?, gdzie wysył?ać? wiadomoś?ci oraz jakiej wersji SNMP i jakich parametrów bezpieczeń?stwa uż?yć? do wysył?ania wiadomoś?ci.
• ? Aplikacje, które otrzymują? jednostki danych protokoł?u SNMP NotitieationClass noszą? nazwę? Notitieation Reeeivers. Aplikacje te nasł?uchują? powiadomień?Notitieation Messages i generują? Response Messages (odpowiedzi), kiedy otrzymana wiadomoś?ć? zawiera jednostkę? danych protokolu Contirmed-Class,
• ?Aplikacje, które wysył?ają? wiadomoś?ci SNMR nazwano Proxy Forwarder. Implementacja tych aplikacji jest opcjonalna.

W USM stosuje się? algorytm skrótu wiadomoś?ci MD5 (Massage Digest 5) i oparty na nim SHA (Seeure Hash Algorithm). Dzię?ki nim zapewnia się? integralnoś?ć? danych, czyli bezpoś?rednią? ochronę? przed atakami mają?cymi na celu modyfikację? zawartoś?ci. Ale mają? on również? na celu uwierzytelnienie danych i ochronę? przed atakami w rodzaju wspomnianego podszywanie się? pod uż?ytkownika. Algorytm SHA jest wolniejszy od MD5 o 25 proc, ale generuje skrót o dł?ugoś?ci 160 bitów, a wię?c o 32 bity dł?uż?szy niż? MD5.

USM uż?ywa luź?no zsynchronizowanych monotonicznie rosną?cych wskaź?ników czasowych, zabezpieczają?cych poś?rednio przed atakami ukierunkowanymi na zmodyfikowanie strumienia wiadomoś?ci. Mechanizmy automatycznej synchronizacji zegara oparte na protokole są? specyfikowane niezależ?nie od jakiegoś? trzeciego ź?ródł?a czasowego i okolicznoś?ci towarzyszą?cych bezpieczeń?stwu. USM stosuje DES, zapobiegają?cy ujawnieniu wiadomoś?ci. Dokument obejmuje takż?e problematykę? odpowiedniej MIB dla zdalnego monitorowania i zarzą?dzania konfiguracja parametrów dla USM, wliczają?c w to zarzą?dzanie i dystrybucję? klucza.

RFC 2575 charakteryzuje VACM dla architektury SNMP. Definiuje elementy procedury dla kontroli dostę?pu do zarzą?dzania informacjami. Dokument obejmuje takż?e opis MIB do zdalnego zarzą?dzania parametrami konfiguracyjnymi dla VACM. Kontrola dostę?pu VACM moż?e być? jednocześ?nie skojarzona w jednej implementacji z wieloma MPM i wieloma modelami bezpieczeń?stwa. Architektura umoż?liwia dysponowanie róż?nymi modelami kontroli dostę?pu i prezentowanie ich w jednym motorze, ale moż?na przypuszczać?, ż?e bę?dzie to rzadkie w praktyce i daleko mniej powszechne niż? równoczesne wsparcie MPM i/lub wielu modeli bezpieczeń?stwa (Security Models).