LABORATORIUM DYPLOMOWE

„Analiza standardów zarządzania sieciami i zasobami sieciowymi”

Opracował:

Janusz Trzeszewski

STI, sem.IX

spiS treśCi :

1. Wstęp

1. Wstęp

Oprócz protokołów, które zapewniają usługi na poziomie sieci i programów użytkowych umożliwiających wykorzystywanie tych protokołów, oprogramowanie intersieci potrzebuje narzędzia pozwalającego administratorom na znajdowanie przyczyn problemów, sterowania wyznaczaniem tras oraz na wykrywanie komputerów, które naruszają standardy protokołów. Zadania tego typu określa się mianem zarządzania siecią.

Protokoły zarządzania siecią określają sposób komunikacji między programem-klientem do zarządzania siecią, który jest używany przez administratora a serwerem działającym na komputerze lub routerze. Poza określeniem postaci i znaczenia komunikatów oraz reprezentacji nazw i wartości w tych komunikatach, protokoły zarządzania siecią definiują również zależności administracyjne między kontrolowanymi routerami. Oznacza to, że udostępniają one możliwość uwierzytelniania administratorów. Można by oczekiwać, że protokół zarządzania siecią będzie miał dużo różnych poleceń. Niektóre wczesne protokoły zapewniały np. polecenia umożliwiające przeładowanie systemu, dodanie lub usunięcie tras, włączenie lub wyłączenie określonego interfejsu sieciowego lub usunięcie adresów z pamięci podręcznej. Główną wadą wbudowywania poleceń w protokół zarządzania siecią jest jego rosnąca złożoność. Protokół taki wymaga osobnego zestawu poleceń dla każdej operacji. Na przykład skasowanie pozycji z tablicy tras wymaga innego polecenia niż wyłączenie interfejsu. Oznacza to, że dodawanie nowych danych, które można zmieniać, wymaga modyfikacji protokołów.

Trzeba jednak pamiętać o tym, że ramki protokołu zarządzania korzystają z tego samego medium, co ramki protokołu użytkowego i protokołu routingu. Wobec tego dąży się do tego, aby ramki protokołu zarządzania były możliwie krótkie i nie wymagały potwierdzeń, aby nie generować zbytniego obciążenia w sieci.

Na poniższym rysunku przedstawiłem powiązania pomiędzy protokołem zarządzania, protokołem użytkowym i protokołem routingu.

Protokoły zarządzania sieciami TCP/IP dzielą problem na dwie części, do których odnoszą się osobne standardy. Pierwszy z nich dotyczy sposobu przekazywania informacji. Protokół określa sposób, w jaki klient działający na komputerze administratora porozumiewa się z agentem. Definiuje formaty i znaczenia komunikatów przesyłanych między klientem a serwerem oraz postać nazw i adresów. Druga część dotyczy informacji, którymi zarządzają te protokoły. Protokół określa, jakie informacje musi przechowywać jednostka sieciowa spełniająca ten standard, nazwy poszczególnych danych i składnię tych nazw.

1.1 Model zarządzania siecią

W modelu zarządzania siecią zarządzane zasoby noszą nazwę elementów sieci (ang. network elements) lub inaczej zarządzanych węzłów (ang. managed nodes). Każdy z elementów sieci składa się z zarządzanych jednostek (ang. managed entities) i agenta, który nimi steruje. Agenci komunikują się ze stacją zarządzania siecią NMS (ang. Network Management Station), która wydaje agentom polecenia dotyczące zarządzania siecią i jej elementami. W przypadku, gdy mamy do czynienia z elementami sieci, które nie mogą być zarządzane bezpośrednio przez stację zarządzania przy pomocy protokołu SNMP (np. w przypadku, gdy element sieci jest wyposażony we własny system zarządzania, który nie jest oparty na protokole SNMP) korzystamy z tzw. Agenta-pośrednika (ang. proxy agent), który dokonuje konwersji protokołów.

Poniższy rysunek przedstawia struktury systemu zarządzania:

Operacje Odpowiedzi

zarządzania NMS lub zdarzenia

System zarządzający

Agent Agent ...................... Agent

Baza Baza ...................... Baza

Urządzenie Urządzenie Urządzenie

sieciowe sieciowe sieciowe

Przy opracowywaniu standardów zarządzania kierowano się zasadą, że zarządzanie siecią i uruchomienie funkcji zarządzania w węzłach ma mieć minimalny wpływ na złożoność tychże węzłów. Wynikało z tego dążenie do maksymalnego uproszczenia funkcjonalności agentów kosztem złożoności stacji zarządzania siecią. Osiągnięto ten cel miedzy innymi dzięki zastosowaniu zarządzania opartego na przepytywaniu (ang. polling based management), w którym stacja zarządzająca jest odpowiedzialna za monitorowanie agenta (a pośrednio podległych mu zarządzanych obiektów) oraz wykrywanie zdarzeń.

2. Protokół SNMP

Obecnie standardowym protokołem zarządzania sieciami TCP/IP jest Simple Network Management Protocol (SNMP).

2.1 Cechy protokołu

Router kontrolowany za pomocą SNMP musi przechowywać i udostępniać administratorowi informacje sterujące i informacje o stanie. Router taki gromadzi informacje statystyczne dotyczące stanu jego interfejsów sieciowych, przychodzących i wysyłanych pakietów, porzuconych datagramów oraz wysyłanych komunikatów o błędach. Protokół SNMP umożliwia administratorowi dostęp do tych informacji, ale nie określa w jaki sposób ten dostęp ma być zrealizowany. Temu zagadnieniu jest poświęcony osobny standard - Management Information Base (MIB), który określa jakie informacje musi przechowywać router i jakie operacje muszą być na nich określone. Standard MIB np. wymaga, aby oprogramowanie IP przechowywało informacje o liczbie oktetów przychodzących do każdego z interfejsów sieciowych, określa też, że oprogramowanie zarządzające może jedynie odczytywać tę informację.

Zasadniczym elementem architektury jest zbiór stacji zarządzania sieciowego, elementów sieciowych. Stacje zarządzające wykonują aplikacje zarządzające, które monitorują i kontrolują elementy sieciowe. Elementami sieciowymi są hosty, bramy, terminale, serwery i inne posiadające agentów zarządzających. SNMP jest używany do przesyłania informacji zarządzającej pomiędzy stacjami i agentami w elementach sieciowych.

Celem tej architektury są: redukcja kosztów software'u zarządzającego do niezbędnych, zwiększenie zdalnych funkcji zarządzających dla pełnego wykorzystania zasobów internetu i minimalnych ograniczeń co do narzędzi, uproszczony zestaw funkcji ułatwia zrozumienie. Punkty te wynikają z dążenia do uproszczenia protokołu. Inne cele :zapewnić rozszerzalność protokołu, niezależność od hosta.

W SNMP wszystkie operacje są wykonywane przy użyciu modelu odczytaj-zapisz wartość elementu MIB. SNMP dostarcza tylko dwu poleceń: do odczytania wartości zmiennej i do jej zapisania. Wszystkie inne operacje są ich efektami ubocznymi.

Główne zalety modelu odczytaj-zapisz to stabilność, prostota i elastyczność. SNMP jest stabilny, gdyż jego definicja nie wymaga zmian przy dodawaniu nowych zmiennych MIB i określaniu operacji na nich. Umożliwia on łatwe wykrywanie błędów, gdyż nie wymaga osobnych przypadków szczególnych dla poszczególnych poleceń. Jest on bardzo elastyczny, gdyż umożliwia łatwe dodawanie nowych poleceń.

Protokół SNMP pozostaje oczywiście niewidoczny dla administratora. Interfejs użytkownika zapewniany przez oprogramowanie zarządzania siecią dostarcza tradycyjnych operacji, takich jak np. przeładowanie systemu (reboot). Nie ma zatem większej różnicy między sposobem używania przez administratora SNMP oraz innych protokołów zarządzania siecią. Od pewnego czasu producenci zaczęli sprzedawać oprogramowanie zarządzania siecią wyposażone w graficzny interfejs użytkownika. Oprogramowanie takie jest bardzo proste w użyciu i przyjazne użytkownikowi, gdyż umożliwia wyświetlanie diagramów połączeń w sieci i wykonywanie poleceń za pomocą myszki .

2.2 Rodzaje wiadomości

Protokół SNMP v.1 umożliwia wymianę pięciu typów wiadomości :

• Get Request, która pozwala uzyskać od agenta wartości zmiennych (obiektów)

• Get Next Request, która umożliwia otzrymanie od agenta wartości kolejnej zmiennej w drzewie MIB

• Set Request, która pozwala stacji zarządzania zmienić wartości zmiennych

• Get Response, która jest przesyłana przez agenta w odpowiedzi na otrzymane wiadomości Get Request, Get Next Request i Set Request

• Trap, która umożliwia agentowi zgłoszenie zdarzenia związanego z elementem sieci (otrzymanie tej wiadomości nie jest potwierdzane przez stację zarządzania)

Protokół SNMP jest protokołem o synchronizacji niepodzielnej co oznacza, że jeśli np. wiadomość Get Request dotyczy kilku zmiennych, wtedy niepowodzenie odczytu wartości jednej ze zmiennych powoduje przerwanie realizowania tego żądania.

SNMP management station SNMP agent

Managed

Application resources

Management application manages SNMP

objects managed objects

SNMP

SNMP manager messages SNMP agent

UDP UDP

IP IP

Network-dependent protocols Network-dependent protocols

Network or internet

Komunikaty SNMP nie mają ustalonych pól, lecz używają standardowego kodowania ASN.1 co powoduje, że jest on mało czytelny dla ludzi. Komunikacja pomiędzy jednostkami odbywa się za pomocą przesyłania komunikatów, z których każdy jest reprezentowany przez pojedynczy datagram UDP używający kodowania ASN.1. Komunikaty UDP odbierane są na porcie 161, zaś pułapki (komunikaty o zdarzeniach) odbierane są na porcie 162.

2.3 Struktura ramek protokołu SNMP

Ramka SNMP wygląda następująco:

Nagłówek

Variable Binding

Variable Binding

.............

Variable Binding

Nagłówek:

1-2b 1b 1-16b 1b 4b 1b 1b

total length

Protocol Version

Community name

Frame Type

req-id

err status

err index

Variable Binding:

object identifier (oid)

Value

Każde pole może mieć dowolną długość. W rzeczywistości są one implementowane jako:

variable type

variable length

Variable value

Np. pole „protocol version” składa się z trzech bajtów: typ=ASN.1 INTEGER, length=1, value. W powyższym opisie podana jest tylko długość części informacyjnej dla pól o ustalonej długości. To w jaki sposób realizowane jest kodowanie nie jest istotne. Można znaleźć to w normie CCITT.

Znaczenie poszczególnych pól ramki SNMP:

- total length - długość ramki w bajtach (nagłówek + wszystkie pola Variable

Binding)

- protocol version - wersja protokołu SNMP (aktualnie 0)

- community name - hasło sprawdzane przez oprogramowanie zarządzające

(management system )

- frame type - typ ramki (GET, GET-NEXT, SET, GET RESPONSE, TRAP)

- req-id - identyfikator ramki umożliwiający zgranie odpowiedzi z zapytaniem

- err-status - kod błędu zawierający jedną z następujących wartości

# noError (0) - bez błędów

# tooBig (1) - wynik nie mieści się w jednostce danych protokołu

# noSuchName (2) - zmienna o takiej nazwie nie może zostać

odnaleziona

# badValue (3) - zmienna o tej wartości nie może zostać

odnaleziona

# readOnly (4) - zmienną można tylko odczytać

# GenError (5) - inne błędy

- err-index - numer (liczony od 1) pola Variable Binding zawierającego błąd

Pola ErrorStatus i ErrorIndex są równe zero w przypadku żądania.

Format wiadomości Trap jest inny i zawiera następujące pola

• Enterprise, które pozwala określić system, w którym znajduje się proces

agenta wysyłający tę wiadomość (zmienna sysObjectID)

• Agent Addr, które podaje adres sieciowy agenta obiektu wysyłającego

wiadomość (zmienna typu NetworkAddress)

• Generic Trap, który określa zdarzenie, które wywołało wysłanie

wiadomości. Wśród predefiniowanych zdarzeń są:

# coldStart (wznowienie pracy obiektu-konfiguracja może ulec

zmianie)

# warmStart (wznowienie pracy obiektu-konfiguracja nie może ulec

zmianie)

# linkDown (awaria łącza)

# linkUp (usunięcie awarii łącza)

# authenticationFailure (nieudana autentyfikacja)

# egpNeighborLoss (awaria partnerskiego serwera EGP)

# enterpriseSpecific (inny powód, podany w polu Specific Trap)

• Specific Trap, które precyzuje inny powód zasygnalizowania w polu

Generic Trap

- Time Stamp, które określa czas wystąpienia zdarzenia

• Variable Bindings, które zawiera dodatkowe informacje dotyczące

zmiennych i ich wartości

W SNMPv1 wszyscy agenci oraz stacje zarządzające muszą obsługiwać UDP i IP. Nakłada to ograniczenie na bezpośrednie zarządzanie niektórymi urządzeniami oraz wyklucza niektóre, np. niektóre mosty i modemy, które nie obsługują protokołu TCP/IP. Ponadto może być wiele małych systemów takich jak komputery osobiste, stacje robocze, sterowniki programowalne, które stosują TCP/IP do obsługi własnych aplikacji, lecz dla których dodatkowe obciążenie w postaci SNMP, programów agentów i utrzymywania MIB nie byłoby pożądane.

2.4. Społeczności w SNMPv1

Zarządzanie siecią za pomocą SNMP odbywa się za pomocą relacji „jeden na wielu” między agentem a zbiorem menedżerów. Menedżer może używać Get (uzyskiwać) i używać Set (ustawiać) obiekty u agentów oraz może otrzymywać od nich przerwania. A więc pod względem operacyjnym i kontrolnym menedżer „rządzi” wieloma agentami. Menedżerów może być wielu, a każdy z nich może zarządzać wszystkimi lub podzbiorem agentów. Podzbiory te mogą się częściowo pokrywać.

Każdy agent kontroluje własną lokalną MIB i musi mieć możliwość kontroli korzystania z tej MIB przez wielu menedżerów. Kontrola ta ma trzy aspekty:

• usługa uwierzytelniania: agent może zastrzec prawo dostępu do MIB tylko dla pewnych menedżerów

• ograniczenia dostępu: agent może udzielać różnych przywilejów dostępu różnym menedżerom

• usługa pełnomocnictwa: agent może działać jako pełnomocnik innych agentów. Wiąże się to z implementacją usługi uwierzytelniania, ograniczeń dostępu lub obydwu usług dla innych agentów w systemie pełnomocnika

Wszystkie te aspekty wiążą się z bezpieczeństwem. W środowisku w którym odpowiedzialność za składniki sieci jest podzielona, tak jak pomiędzy wieloma jednostkami administracyjnymi, agenci muszą chronić siebie i swoje MIB przed niedozwolonym dostępem. SNMP jak opisano w RFC 1157, oferuje jedynie proste i ograniczone możliwości ochrony w tej dziedzinie, a mianowicie koncepcję społeczności.

Społeczność SNMP to stosunki łączące agenta i zbiór menedżerów SNMP, w ramach których procedury uwierzytelniania, kontroli dostępu i pełnomocnictwa maja określone cechy. Społeczność ma charakter lokalny, zdefiniowany u agenta. Agent tworzy jedną społeczność dla każdej żądanej kombinacji cech uwierzytelniania, kontroli dostępu i pełnomocnictwa. Każdej społeczności nadaje się niepowtarzalną (w ramach agenta) nazwę, a należący do niej menedżerzy dysponują nią i musza ją podawać przy wszystkich operacjach Get i Set. Agent może ustanowić wiele społeczności, przy czym jeden menedżer może należeć do wielu.

Ponieważ społeczności są definiowane lokalnie u agenta, różni agenci mogą używać tych samych nazw. Nazwa jest nieistotna i nie wskazuje na żadne podobieństwa między określonymi nią społecznościami. Menedżer musi więc znać nazwę lub nazwy społeczności związane z agentami, do których chce dotrzeć.

2.4.1. Usługa uwierzytelniania

Celem usługi uwierzytelniania w SNMPv1 jest zagwarantowanie odbiorcy, że komunikat SNMPv1 pochodzi z oznaczonego w nim źródła. SNMPv1 dysponuje tylko prostym systemem uwierzytelniania. Każdy komunikat (Get lub SetRequest) od menedżera do agenta zawiera nazwę społeczności. Nazwa ta funkcjonuje jako hasło i jeżeli nadawca zna hasło, komunikat uznaje za autentyczny.

Przy tak ograniczonej formie uwierzytelniania wielu administratorów sieci nie jest skłonnych zezwolić na więcej niż monitorowanie sieci, tj. operacje typu Get i Trap. Zarządzanie siecią za pomocą operacji Set to oczywiście bardziej „wrażliwy” teren. Nazwa społeczności mogłaby służyć do uruchamiania procedury uwierzytelniania, funkcjonując tylko w charakterze urządzenia sprawdzającego hasło wstępne. Procedura uwierzytelniania mogłaby wiązać się z operacjami szyfrowania/deszyfrowania, co wpływałoby na zwiększenie bezpieczeństwa funkcji uwierzytelniania. RFC 1157 nie obejmuje takich możliwości.

2.4.2. Polityka ograniczeń dostępu

Definiując społeczność, agent ogranicza dostęp do swojej MIB do wybranego zbioru menedżerów. Agent może przydzielać różne kategorie dostępu do MIB różnym menedżerom, definiując więcej niż jedna społeczność. Kontrola dostępu ma dwa aspekty:

• widok MIB: podzbiór obiektów w obrębie MIB. Dla każdej społeczności można zdefiniować różne widoki MIB. Zbiór obiektów w widoku nie musi należeć do jednego poddrzewa MIB

• tryb dostępu: element zbioru {READ-ONLY, READ-WRITE}. Tryb dostępu definiuje się dla każdej społeczności

Kombinację widoku MIB i trybu dostępu określa się nazwą profilu społeczności SNMP. Profil społeczności składa się więc z określonego podzbioru MIB agenta oraz trybu dostępu do tych obiektów. Tryb dostępu SNMP stosuje się tak samo do wszystkich obiektów należących do widoku MIB. Jeśli więc wybrano tryb dostępu READ-ONLY (tylko odczyt), stosuje się on do wszystkich obiektów w widoku i ogranicza dostęp menedżera do tego widoku, umożliwiając mu jedynie operacje związane tylko z odczytem.

Rys. Pojęcia administracji

Profil społeczności jest związany z każdą społecznością zdefiniowaną przez agenta. Kombinację społeczności SNMP i profilu społeczności SNMP określamy nazwą polityka kontroli dostępu SNMP.

2.4.3. Usługa pełnomocnictwa

Koncepcja społeczności jest przydatna także przy pełnomocnictwach. Przypomnieć należy tutaj, że pełnomocnik jest agentem SNMP, działającym w imieniu innych urządzeń. Zazwyczaj inne urządzenia są „obce”, tj. nie używają ani TCP/IP ani SNMP. W niektórych przypadkach system może używać SNMP, lecz w celu zminimalizowania interakcji między nim a systemami zarządzania siecią stosuje się pełnomocnictwo.

Dal każdego reprezentowanego urządzenia pełnomocnik prowadzi politykę ograniczeń dostępu. To znaczy, że pełnomocnik wie, których obiektów można używać do zarządzania reprezentowanym systemem (widok MIB) i zna tryb dostępu do nich.

2.5. Zalety i wady protokolu SNMP

SNMP ma swoje zalety i wady, ale popularność tego protokołu świadczy o tym, że tych pierwszych jest dużo więcej. Niewątpliwymi zaletami protokołu są prostota w pracy i niski koszt implementacji aplikacji opartych na tym standardzie. Poza tym użytkownik ma pewnośc, że standard został zaakceptowany przez cały przemysł informatyczny i znakomita większość produktów sieciowych pracuje zgodnie z SNMP. Najważniejszą z wad SNMP wydaje się być brak mechanizmów zapewniających danym przesyłanym przez ten protokół odpowiedniego poziomu bezpieczeństwa.

Do głównych zalet SNMP zaliczyć należy:

• Stosunkowo małe obciążenie sieci pakietami. SNMP używa do komunikowania się ze stacjami prostego bezpołączeniowego protokołu UDP (wymieniającego informacje w trybie żądanie / odpowiedź), przez co ruch pakietów w sieci jest ograniczony do niezbędnego minimum.

• Instalowane w węzłach sieci programy typu agent zajmują mało miejsca w pamięci

• Protokół pozwala kontrolować liczbę generowanych przez stację zarządzania powtórzeń żądań obsługi oraz czas oczekiwania (time out) na odpowiedzi urządzeń

• Cenną zaletą protokołu SNMP jest możliwość zbierania od zarządzanych węzłów informacji typu trap (wychwytywanie konkretnych zdarzeń). Pozwala to węzłom sieci przesyłać do zarządcy te informacje, które są szczególnie cenne dla stacji zarządzania (rodzaj zdarzenia jest wcześniej definiowany przez administratora systemu).

Jeśli chodzi o wady, to można wymienić trzy podstawowe zastrzeżenia zgłaszane pod adresem protokołu SNMP:

• Skomplikowana praca samego agenta

• Ograniczanie przepustowości sieci

• Brak mechanizmów bezpieczeństwa

3. Protokół SNMPv2

Siłą SNMP jest jego prostota. Dysponuje on podstawowym zestawem narzędzi zarządzania siecią, łatwym do zaimplementowania i skonfigurowania. Lecz w miarę jak użytkownicy zaczęli w coraz większym stopniu opierać się na SNMP w zarządzaniu wiecznie rosnącymi sieciami z wzrastającym obciążeniem, coraz bardziej zauważalne stały się jego niedostatki. Wady te można podzielić na trzy kategorie:

• Braki w dziedzinie zarządzania sieciami rozproszonymi

• Niedostatki funkcjonalne

• Niedostatki bezpieczeństwa

W 1992 roku ukończono prace nad następcą protokołu SNMP, czyli protokołem SNMPv2 (SNMP version 2). W porównaniu z pierwotną wersją, wersja 2 zapewnia większe bezpieczeństwo przesyłania wiadomości (szyfrowanie i autentyfikacja), oraz rozszerzoną do 7 liczbę wiadomości o ujednoliconym formacie.

Autentyfikacja opiera się na algorytmie MD5 (ang. Message Digest Algorithm 5), opisanym w dokumencie RFC 1321, a szyfrowanie realizuje się opierając się na standardzie DES (Data Encryption Standard).

SNMPv2 pozwala na stosowanie nie tylko protokołu TCP/IP, ale również innych protokołów. W szczególności SNMPv2 może działać nad protokołami OSI. SNMPv2 można więc stosować do zarządzania różnymi strukturami sieciowymi.

3.1. Zarządzanie sieciami rozproszonymi

SNMPv2 umożliwia stosowanie zarówno strategii zarządzania typu wysoce scentralizowanego, jak i typu rozproszonego. W tym drugim przypadku mamy do czynienia z wieloma menedżerami. Strategię hierarchiczną przedstawiono na poniższym rysunku:

Rys Architektura zarządzania sieciami rozproszonymi

Za logiczne lub geograficzne podzbiory całej konfiguracji odpowiadają menedżerowie elementów. Zajmują się oni szczegółowym zarządzaniem podległym im obszarem. Powyżej tego poziomu znajduje się jeden lub więcej „serwerów zarządzających”, które zajmują się zarządzaniem na poziomie strategii. Zazwyczaj serwer zarządzający otrzymuje (w formie streszczonej) informacje od menedżerów elementów. Dzięki temu podporządkowani menedżerowie mogą zająć się szczegółami zarządzania siecią, a główni - stosować podejście generalne, zbiorowe.

Dwie nowe cechy SNMPv2 umożliwiają zastosowanie metody zdecentralizowanej. Po pierwsze SNMPv2 umożliwia jednemu menedżerowi wysłanie potwierdzonego zawiadomienia do innego. Po drugie SNMPv2 umożliwia zastosowanie MIB typu menedżer - menedżer (M2M MIB), opisanej poniżej:

Jak sama nazwa wskazuje, M2M MIB jest przeznaczona do komunikacji miedzy dwoma menedżerami, zazwyczaj między głównym i podporządkowanym. Na MIB składają się dwie grupy obiektów:

• grupa alarmowa: zbiór obiektów, które umożliwiają opis i konfigurację alarmów opartych na progach.

• grupa zdarzeń: zbiór obiektów służących do opisu i konfiguracji zdarzeń

Grupy te tworzą proste, lecz sprawne narzędzie pracy ze zdarzeniami. Przy pomocy grupy alarmowej można skonfigurować menedżera lub agenta tak, by monitorował dowolny obiekt w dowolnej MIB i generował zawiadomienia dla menedżera, gdy wartość tego obiektu przekroczy jakiś próg. Grupa zdarzeń określa format i czas zawiadomień, wysyłanych do menedżera. Przyczyną wysłania zawiadomienia może być przekroczenie progu w grupie alarmowej lub inne określone zdarzenie, np. awaria linii.

Kombinacja grupy zdarzeń i alarmowej stanowi przydatne narzędzie zarządzania siecią. Na przykład, gdy liczba pakietów zawierających błędy na danej linii przekroczy pewien próg, może to oznaczać awarię na tej linii. Jeśli natężenie ruchu w LAN przekroczy pewien próg, powoduje to ostrzeżenie stacji zarządzającej, że czas reakcji może się pogorszyć, jeśli obciążenie nie zostanie ustabilizowane.

3.2. Elementy zwiększające funkcjonalność

W poniższej tabeli wymieniłem dodatkowe elementy zwiększające funkcjonalność wprowadzone do SNMPv2. Oba protokoły zdefiniowano jako zbiory poleceń. W przypadku SNMPv1 mamy pięć poleceń, w SNMPv2 dochodzą jeszcze dwa nowe.

Polecenie	Opis	Kierunek	SNMPv1	SNMPv2
Get	Dla każdego obiektu wymienionego w poleceniu zwróć wartość tego obiektu	Menedżer do agenta	√	√
GetNext	Dla każdego obiektu wymienionego w poleceniu zwróć wartość następnego obiektu MIB	Menedżer do agenta	√	√
GetBulk	Dla każdego obiektu wymienionego w poleceniu zwróć wartość następnych N obiektów MIB	Menedżer do agenta		√
Set	Dla każdego obiektu wymienionego w poleceniu przypisz odpowiednią wartość wymienioną w poleceniu	Menedżer do agenta	√	√
Trap	Prześlij „nie żądaną” informację	Agent do menedżera	√	√
Inform	Prześlij „nie żądaną” informację	Menedżer do menedżera		√
Response	Odpowiedz na żądanie menedżera	Agent do menedżera	√	√

Tabela. Polecenia SNM

Nowymi wiadomościami wprowadzonymi w protokole SNMPv2 są Get Bulk Request, która umożliwia uzyskiwanie jednocześnie wartości wielu zmiennych, oraz Inform Request, która pozwala przesyłać komunikaty między stacjami zarządzania siecią (zarządcami). Również wiadomość SNMPv2 Trap można uznać za nową, gdyż chociaż jest ona równoważna wiadomości Trap protokołu SNMP, to uzyskała nowy format, jednolity z formatem pozostałych wiadomości.

Przesyłanie wiadomości Get Bulk Request jest w istocie równoważne przesyłaniu wielu wiadomości Get Next Request. Zmienne, których dotyczy wiadomość Get Bulk Request są przesyłane w polu Variable Bondings.

Wiadomości typu Inform Request umożliwiają komunikację pomiędzy zarządcami i ich wzajemne informowanie się o zaistniałych zdarzeniach. Pole Variable Bindings w wiadomości Inform Request jest wykorzystywane w następujący sposób:

• pierwsze przyporządkowanie (zmienna sysUpTime.0) określa czas i datę

wygenerowania wiadomości

• drugie przyporządkowanie (zmienna snmpEventID.i) wskazuje na zmienną

typu meldunek (zdefiniowaną za pomocą makrodefinicji

NOTIFICATION-TYPE)

• dalsze przyporządkowania dotyczą zmiennych (obiektów związanych z

meldunkiem (zmienne te określa się w definicji meldunku po słowie OBJECTS)

Dla potrzeb wiadomości Inform Request zdefiniowano trzy meldunki:

• snmpRisingAlarm - przekroczenie przez zmienną górnej wartości

progowej

• snmpFallingAlarm - przekroczenie przez zmienną dolnej wartości

progowej

• snmpObjectUnavailableAlarm - niedostępność zmiennej

Z innych ulepszeń protokołu SNMP należy wspomnieć o tym, że w protokole SNMPv2 rozszerzono listę wartości pola Error Status, między innymi o wartości umożliwiające, co nie było możliwe w poprzedniej wersji protokołu, sygnalizowanie błędów powstałych po otrzymaniu wiadomości Set Request. Możliwe jest np. poinformowanie zarządcy, że zmienna (obiekt), której dotyczy wiadomość Set Request nie istnieje (noCreation), że istnieje, ale nie można jej zapisywać (notWritable), lub że nowa wartość zmiennej nie jest dopuszczalna (wrongValue).

Wszystkie dopuszczalne wartości pola Error Status dla protokołu SNMPv2 przedstawiłem poniżej:

• noError (0)

• tooBig (1)

• noSuchName (2)

• badValue (3)

• readOnly (4)

• genErr (5)

• noAccess (6)

• wrongType (7)

• wrongLength (8)

• wrongEncoding (9)

• wrongValue (10)

• noCreation (11)

• inconsistentValue (12)

• resourceUnavailable (13)

• commitFailed (14)

• undoFailed (15)

• authorizationError (16)

• notWritable (17)

• inconsistentName (18)

3.3. Elementy podwyższające poziom bezpieczeństwa

3.3.1. Środki zapewniania bezpieczeństwa w SNMPv2

Najbardziej chyba rzucającym się w oczy niedostatkiem SNMPv1 jest brak możliwości w dziedzinie ochrony. W SNMPv1 nie ma sposobu na uniemożliwienie stronie trzeciej śledzenia ruchu między menedżerem a agentem. Co gorsza, nie ma także sposobu na uniemożliwienie stronie trzeciej grania roli menedżera i wykorzystywania operacji Get i Set w obrębie agenta. W rezultacie wielu użytkowników SNMPv1 po prostu wyłącza możliwość stosowania polecenia Set. SNMP zostaje w ten sposób zredukowany do poziomu narzędzia monitorowania sieci, pozbawionego możliwości „dostrajania” systemu, ustawiania parametrów, zmieniania konfiguracji.

W celu obrony przed wymienionymi zagrożeniami SNMPv2 wzbogacono o możliwości w dziedzinie ochrony. Są one oparte na koncepcji „strony”. Każdy menedżer i każdy agent ma co najmniej jedna stronę i może mieć ich wiele oraz wchodzić z nimi w bezpieczne relacje. Między dowolną parą stron w celu zagwarantowania odbiorcy pewności co do tożsamości nadawcy można używać kodu uwierzytelniania.

Aby ochronić przesyłane informacje przed podsłuchem, w dowolnej parze stron można stosować szyfrowanie.

Wreszcie, tak jak w SNMPv1, SNMPv2 zawiera mechanizmy kontroli dostępu, które umożliwiają ograniczenie dostępu strony zarządzającej do pewnych części MIB i do pewnych poleceń.

Możliwość	Opis	SNMPv1	SNMPv2
Uwierzytelnianie	Procedura umożliwiająca stronie odbiorczej weryfikowanie, że komunikat pochodzi z danego źródła i że ma właściwy czas. Uwierzytelnianie realizuje się przez dodanie do komunikatu tajnego kodu		√
Prywatność	Ochrona przesyłanych danych przed podsłuchaniem. Realizuje się ją przez szyfrowanie komunikatów SNMP		√
Kontrola dostępu	Ograniczanie dostępu menedżera do konkretnego fragmentu MIB oraz określonego podzbioru poleceń	√	√

Środki zapewniania bezpieczeństwa w SNMPv2 opisane są w następujących dokumentach:

• RFC 1445: „Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)” - Jest to opis modelu zarządzania SNMP. Model ten stanowi jednolitą podstawę koncepcyjna do administrowania obiektami protokołu SNMP z zapewnieniem uwierzytelniania i nienaruszalności danych, prywatności, kontroli dostępu oraz współpracy wielu obiektów;

• RFC 1446: „Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)” - opisuje protokoły realizujące trzy usługi w dziedzinie bezpieczeństwa danych: (1) nienaruszalność danych, (2) uwierzytelnianie pochodzenia danych, (3) poufność danych.

• RFC 1447: „Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)” - opisuje część bazy informacji administracyjnych (MIB) przeznaczoną do stosowania w protokołach zarządzania w intersieciach opartych na TCP/IP. Opisuje reprezentację stron SNMP jako obiektów, zgodną z protokołami bezpieczeństwa SNMP.

3.3.2. Zagrożenia przed którymi zabezpiecza SNMPv2

Środki zapewniania bezpieczeństwa, jakimi dysponuje SNMP, służą do ochrony przed następującymi zagrożeniami:

• Ujawnienie: Przeciwnik może śledzić informacje wymieniane przez menedżera i agen­ta i w ten sposób poznać wartości zarządzanych obiektów oraz dowiedzieć się o wyda­rzeniach. Na przykład zaobserwowanie zestawu poleceń zmieniających hasła umoż­liwiłoby przeciwnikowi poznanie naszych haseł.

• Maskarada: Dana jednostka może wykonywać niedozwolone dla siebie operacje za­rządzania, podszywając się pod jednostkę, dla której operacje te są dozwolone.

• Modyfikacja treści komunikatu: Przeciwnik może modyfikować wygenerowany przez uprawnioną jednostkę komunikat w czasie przesyłania w taki sposób, by doprowadzić do wykonania niedozwolonych operacji zarządzania, w tym ustawiania wartości obiek­tów. Istotą tego zagrożenia jest możliwość zmiany przez nieuprawnioną jednostkę dowolnego parametru zarządzania, w tym parametrów związanych z konfiguracją, działaniem i zliczaniem (accounting).

• Modyfikacja kolejności i czasu komunikatów: W celu doprowadzenia do wykonania niedozwolonych operacji zarządzania przeciwnik może zmieniać kolejność, opóźniać lub powtarzać (powielać) komunikaty SNMP. Na przykład komunikat wysłany w celu przeładowania (reboot) urządzenia może zostać skopiowany i wysłany później.

SNMPv2 nie chroni przed następującymi zagrożeniami:

• Uniemożliwienie działania: Przeciwnik może zablokować wymianę informacji między menedżerem a agentem.

• Analiza przesyłu: Przeciwnik może śledzić schemat ruchu między menedżerami a agentami.

Brak środków ochrony przed zagrożeniem typu uniemożliwienie działania można uzasadnić na dwa sposoby. Po pierwsze ataki tego rodzaju są w wielu przypadkach nieodróżnialne od pewnego rodzaju awarii sieci, z którymi musi sobie radzić każdy samodzielny program sieciowy; po drugie ataki takie najczęściej uniemożliwiają wszelką wymianę informacji i przeciwdziałanie im jest sprawą ogólnych środków bezpieczeństwa, nie zaś tych, które wchodzą w skład protokołu zarządzania siecią. Wreszcie uznano, że nie warto tworzyć zabezpieczeń przed atakami wiążącymi się z analizą przesyłu.

3.3.3. Usługi SNMPv2

Pamiętając o powyższych zagrożeniach zajmijmy się przeglądem usług oferowanych przez SNMPv2. SNMPv2 ma z założenia wykonywać trzy usługi związane z ochroną: zapewnianie prywatności, uwierzytelnianie i kontrolę dostępu.

Zapewnianie prywatności polega na ochronie przesyłanych danych przed różnymi formami podsłuchu. Prywatność wymaga, by każdy komunikat był tak zamaskowany, by tylko odpowiedni odbiorca był w stanie uzyskać go w postaci pierwotnej.

Mówimy, że komunikat, plik, dokument lub inny zbiór danych jest autentyczny, jeśli jest oryginalny i pochodzi z podanego w nim źródła. Uwierzytelnianie komunikatów jest procedurą umożliwiającą komunikującym się stronom weryfikację autentyczności otrzymy­wanych komunikatów. Podstawowe znaczenie ma weryfikacja, czy treść komunikatu nie została zmieniona oraz czy źródło jest autentyczne. Należy także zweryfikować popraw­ność czasu komunikatu (czy nie został on sztucznie opóźniony lub też powtórzony) oraz kolejność w stosunku do innych komunikatów przepływających między dwiema stronami.

Celem kontroli dostępu w kontekście zarządzania siecią jest zagwarantowanie, by tylko uprawnieni użytkownicy mieli dostęp do danej bazy informacji administracyjnych oraz by dostęp i modyfikacja danej części danych była zastrzeżona dla uprawnionych osób i programów.

Zanim opiszę powyższe trzy usługi, wprowadzę jeszcze pojęcie strony i pokażę strukturę komunikatu SNMPv2.

3.3.4. Strony w SNMPv2

Aby mogła się odbywać bezpieczna komunikacja, przy każdej wymianie informacji jest konieczne identyfikowanie źródła i miejsca przeznaczenia. Uwierzytelnianie zależy od źródła. Jego zadaniem jest po pierwsze włączenie do każdego komunikatu informacji gwarantującej, że jego pochodzenie jest autentyczne, a po drugie wykonanie odpowied­nich funkcji zapewniających nienaruszalność komunikatu. Zapewnianie prywatności ko­munikatu przez szyfrowanie zależy natomiast od miejsca przeznaczenia. Szyfrowanie musi zostać przeprowadzone tak, aby tylko w odpowiednim miejscu przeznaczenia moż­na było dokonać odszyfrowania. Kontrola dostępu zależy zarówno od źródła, jak i od miejsca przeznaczenia. Każde miejsce przeznaczenia może stosować inne zasady kontroli dostępu dla poszczególnych źródeł.

Każdy komunikat musi więc zawierać informacje o tożsamości źródła i miejsca przeznaczenia. Nie wystarczy jednak utożsamiać źródła z wysyłającą jednostką SNMPv2, a miejsca przeznaczenia z odbiorcą. Każda jednostka SNMPv2 może zachowywać się inaczej pod względem bezpieczeństwa w zależności nie tylko od tożsamości innej jednostki biorącej udział w wymianie, ale także od programu właśnie obsługiwanego. Innymi słowy, rola jednostki SNMPv2 zależy od kontekstu jej działania. Ideę roli wyraża w SNMPv2 pojęcie strony. Każda jednostka może obejmować wiele stron.

Sposób postępowania ze stronami jest następujący. Każda jednostka SNMPv2 dys­ponuje bazą danych zawierającą informacje o wszystkich znanych jej stronach; są to:

• Strony lokalne: Zbiór stron, których działania wykonuje lokalna jednostka SNMPv2, tj. zbiór "ról" tej jednostki.

• Strony reprezentowane: Zbiór stron jednostek reprezentowanych przez daną jednostkę SNMPv2.

• Strony odległe: Zbiór stron, których działania realizują inne jednostki SNMPv2, z któ­rymi dana jednostka może wchodzić w interakcje.

Zastosowanie koncepcji stron w usługach bezpieczeństwa wyjaśni się w dalszym toku tego wywodu.

3.4. Format komunikatu

W SNMPv2 dochodzi do wymiany informacji między menedżerem i agentem oraz mię­dzy menedżerami w formie komunikatu. Każdy komunikat zawiera nagłówek, obejmują­cy informacje związane z bezpieczeństwem, oraz jeden z wielu typów bloku danych. Strukturę komunikatu przedstawiono na poniższym rysunku:

privDst

AuthInfo

dstParty

srcParty

context

PDU

1. Format ogólny

privDst

ŁAŃCUCH OKTETÓW długości zero

dstParty

srcParty

context

PDU

2. Komunikat nie zabezpieczony

privDst

wyciąg

dstTimestamp

SrcTimestamp

dstParty

srcParty

context

PDU

3. Uwierzytelnianie bez prywatności

ZASZYFROWANE

privDst

ŁAŃCUCH OKTETÓW długości zero

DstParty

srcParty

context

PDU

4. Prywatność bez uwierzytelniania

ZASZYFROWANE

privDst

wyciąg

dstTimestamp

SrcTimestamp

dstParty

srcParty

context

PDU

5. Prywatność i uwierzytelnianie

Rys. Formaty komunikatu SNMPv2

Nagłówek składa się z pięciu pól. Pole srcParty (strona-źródło) służy identyfikacji strony wysyłającej komunikat, należącej do menedżera lub agenta. Pole dstParty (strona przeznaczenia) określa stronę należącą do menedżera lub agenta, do której komunikat jest wysyłany. Pole Context może wskazywać, że dana wymiana informacji wiąże się z dostępem do MIB lokalnej w stosunku do agenta. W takim przypadku wartość w tym polu określa"podzbiór MIB agenta, tzw. widok MIB. W innym przypadku może ona oznaczać, że dana wymiana wiąże się z uzyskaniem dostępu do systemu trzeciego za pośrednict­wem relacji pełnomocnictwa, w tym przypadku wartość kontekstu służy identyfikacji reprezentowanego urządzenia i określenia przywilejów związanych z dostępem do niego. W obu przypadkach kombinacja informacji o stronie źródłowej, stronie przeznaczenia i wartość kontekstu służą do określenia przywilejów dostępu w danej wymianie infor­macji. Pole authInfo zawiera informacje istotne dla protokołu uwierzytelniania. W polu privDst znajduje się powtórzony identyfikator strony przeznaczenia.

Pole PDU zawiera jedno z poleceń wymienionych w tabeli 10.1 wraz z odpowied­nimi parametrami.

Jeśli komunikat nie jest zabezpieczony (nie jest uwierzytelniony ani prywatny), pole authInfo zawiera łańcuch oktetów zerowej długości, w postaci zakodowanej ASN.1 (abs­tract syntax notation one). Jeśli komunikat jest uwierzytelniany, lecz nie jest prywatny, pole authInfo zawiera informacje potrzebne do uwierzytelniania.

Komunikat prywatny jest w całości (wraz z nagłówkiem i PDU, lecz z wyjątkiem pola privDst) zaszyfrowany. Pole privDst musi pozostać niezaszyfrowane, by jednostka SNMPv2 w miejscu przeznaczenia mogła określić stronę przeznaczenia i dzięki temu określić charakterystykę prywatności komunikatu.

(a) Typowy diagram przesyłania

Na rysunku (a) przedstawiono ogólną procedurę przesyłania komunikatu: w pier­wszej kolejności przeprowadza się uwierzytelnianie (w razie potrzeby), a następnie szyf­rowanie (w razie potrzeby).

(b) Typowy diagram odbioru

Rys Przesyłanie i odbiór komunikatów w SNMPv2

Na rysunku (b) przedstawiono ogólną procedurę odbioru komunikatu. Jeśli komunikat jest zaszyfrowany, najpierw przeprowadza się deszyfrowa­nie. Następnie, jeżeli podlega on uwierzytelnianiu, odbiorca wykonuje odpowiedni al­gorytm uwierzytelniania. Wreszcie przeprowadza się kontrolę dostępu, by zbadać, czy strona źródłowa jest uprawniona do przeprowadzenia żądanej operacji zarządzania w da­nym kontekście i dla danej strony przeznaczenia.

Prywatność

Dla każdej strony znanej jednostki SNMPv2 baza danych stron zawiera trzy zmienne, których znaczenie zależy od stosowanego protokołu prywatności:

• partyPrivProtocol: Określa protokół prywatności i mechanizm ochrony komunikatów otrzymywanych przez daną stronę. Wartość noPriv oznacza, że komunikaty otrzymy­wane przez daną stronę nie są chronione przed ujawnieniem.

• partyPrivPrivate: Tajna wartość, której wymaga protokół prywatności. Może to być klucz szyfrowania konwencjonalnego lub klucz prywatny w przypadku systemu szyfro­wania z kluczem jawnym.

• parryPrivPublic: dowolna wartość jawna potrzebna w ramach protokołu prywatności. Może to być klucz jawny w systemie szyfrowania z kluczem jawnym.

Mechanizm zapewniania prywatności w aktualnej wersji SNMPv2 polega na szyfrowa­niu konwencjonalnym z zastosowaniem algorytmu DES i wymaga on, by strona źródłowa i strona przeznaczenia miały wspólny klucz szyfrujący. Służy on do ochrony otrzymanego komunikatu przed ujawnieniem (tj. tylko odpowiedni odbiorca oraz nadawca mogą prze­czytać komunikat). Struktura bazy danych umożliwia jednak zastosowanie innych syste­mów szyfrowania konwencjonalnego bądź systemów szyfrowania z kluczem jawnym.

Uwierzytelnianie

Dla każdej strony znanej danej jednostce SNMPv2 baza danych stron zawiera pięć zmien­nych, których znaczenie jest uzależnione od protokołu uwierzytelniania:

• partyAuthProtocol: Określa protokół uwierzytelniania - mechanizm stosowany przez daną stronę do potwierdzania pochodzenia i nienaruszalności wysyłanych komunika­tów. Wartość noAuth wskazuje, że komunikaty generowane przez stronę nie podlegają uwierzytelnianiu.

• parryAuthClock: Określa aktualny czas lokalny danej strony.

• parryAurhPrivare: Tajna wartość wymagana przez protokół uwierzytelniania. Może to być tajna wartość zastosowana w wyciągu z komunikatu, klucz szyfrowania konwen­cjonalnego lub klucz prywatny w systemie szyfrowania z kluczem jawnym.

• parryAuthPublic: Dowolna wartość jawna wymagana przez protokół uwierzytelniania. Może to być klucz jawny w systemie szyfrowania z kluczem jawnym.

• partyAuthLifetime: Narzucona administracyjnie górna granica akceptowanego opóźnienia dostarczenia komunikatów generowanych przez daną stronę.

Mechanizm uwierzytelniania zastosowany w aktualnej wersji SNMPv2 to protokół uwierzytelniania wyciągiem MD5. Umożliwia on weryfikację nienaruszalności otrzymanego komunikatu (tj. czy otrzymany komunikat jest tym, który został wysłany), uwierzytelnianie pochodzenia komunikatu oraz zapewnia prawidłowy czas dostarczenia komunikatu.

Zasadniczo procedura uwierzytelniania jest następująca. Na podstawie wysyłanego komunikatu oblicza się jego wyciąg i dodaje doń na początku tajną wartość, korzystając z algorytmu MD5. Komunikat wraz z wyciągiem (lecz bez tajnej wartości) przesyła się. Przy odbiorze ponownie oblicza się wyciąg na podstawie otrzymanego komunikatu i lokalnej kopii tajnej wartości. Jeśli otrzymany wyciąg zgadza się z obliczo­nym, otrzymany komunikat uważa się za autentyczny. Zastosowanie wyciągu gwarantuje nienaruszalność, a zastosowanie tajnej wartości gwarantuje uwierzytelnienie pochodzenia.

3.5. Komunikacja

3.5.1. Przesyłanie komunikatu

Przejdę teraz do szczegółów protokołu uwierzytelniania, rozpoczynając od prze­syłania. Nagłówek przesyłanego komunikatu SNMPv2 zawiera pole z informacjami istot­nymi dla uwierzytelniania, składające się z 3 elementów:

• authDigest: Wyciąg obliczany na podstawie odpowiedniego fragmentu komunikatu oraz tajna wartość (partyAuthPrivate).

• authSrcTimestamp: Czas generowania komunikatu zgodnie z wartością zmiennej Par­tyAuthClock strony źródłowej. Rozdzielczość zegara i co za tym idzie, datownika, to jedna sekunda.

• authDstTimestamp: Czas generowania komunikatu zgodnie z wartością zmiennej Par­tyAuthClock strony przeznaczenia. Należy zwrócić uwagę, że jest to wartość zegara strony przeznaczenia przechowywana w jednostce źródłowej SNMPv2.

Załóżmy, że strona „a” znajdująca się w jednym systemie wysyła komunikat stronie „b” w drugim systemie, w konkretnym kontekście. Komunikat zawiera daną (Protocol Data Unit, PDU), reprezentującą jedno z poleceń SNMPv2. Załóżmy, że zażądano zarówno uwierzytelniania, jak i zapewnienia prywatności. Komunikat przygotowuje się do prze­słania w następujący sposób (rys. 10.8):

1. Polom dstParty, srcParty, context i PDU przypisuje się odpowiednie wartości.

2. Trzem podpolom pola authInfo przypisuje się wartości w następujący sposób: polu srcTimestamp przypisuje się aktualną wartość zegara strony „a” (przechowywaną lokal­nie); potu dstTimestamp przypisuje się aktualną wartość zegara strony „b” (przechowy­waną lokalnie), a polu digest tymczasowo przypisuje się tajną wartość uwierzy­telniającą strony „a”.

3. Na podstawie pól authInfo, dstParty, srcParty, context i PDU oblicza się wyciąg i umieszcza w polu authDigest. Ponieważ oblicza się go na podstawie bloku zawierają­cego tajną wartość, a wartość ta nie jest przesyłana, komunikat jest zabezpieczony przed modyfikacją.

4. Cały blok (authInfo, dstParty, srcParty, context, PDU) szyfruje się za pomocą DES i tajnego klucza wspólnego ze stroną „b”.

5. Polu privDst przypisuje się tę samą wartość co niezaszyfrowanemu dstParty i umiesz­cza na początku zaszyfrowanego bloku, co daje cały komunikat. Pole privDst musi zostać wysłane w formie jawnej, by umożliwić odbierającemu komunikat menedżero­wi lub agentowi określenie strony przeznaczenia i odszyfrowanie pozostałej części komunikatu.

Rys. Przesyłanie komunikatu SNMP (od strony „a” do strony „b”)

3.5.2. Odbiór komunikatu

Procedura postępowania przy odbiorze komunikatu jest bardziej złożona, gdyż nie­zbędne jest wykonanie różnych kontroli poprawności. Na poniższym rysunku przedstawiono kolejne czynności wykonywane po otrzymaniu komunikatu od strony „a”, przeznaczonego dla strony „b”. W tym przypadku również zakładamy, że wymagane jest zarówno uwierzy­telnianie, jak i zapewnienie prywatności.

Rys. Odbiór komunikatu SNMPv2 (po stronie „b”)

1. Odbiorca sprawdza wartość pola privDst otrzymanego komunikatu, by określić, czy pochodzi on od znanej mu strony lokalnej. Jeśli nie, komunikat odrzuca się.

2. Pozostałą część komunikatu deszyfruje się za pomocą klucza tajnego należącego do strony przeznaczenia.

3. Następnie przeprowadza się podstawowe kontrole poprawności. Komunikat musi być w prawidłowym formacie syntaktycznym. Odszyfrowana wartość dstParty musi się zgadzać z privDst. Strona srcParty musi być znaną stroną nielokalną. Jeśli komunikat nie przejdzie któregokolwiek z tych testów, zostanie odrzucony.

4. Jeśli wartość authSrcTimestamp nie spełnia kryterium prawidłowego czasu, komuni­kat odrzuca się. Kryterium to mówi, że komunikat musi zostać odebrany w rozsądnym czasie, tj. czas ten nie może przekroczyć administracyjnie narzuconej wartości. Kryterium to można sprowadzić do stwierdzenia, że "wiek" komunikatu w momencie otrzymania musi być mniejszy niż maksymalny dozwolony "czas życia".

5. Wartość authDigest wydziela się i tymczasowo zapisuje. Pole authDigest tymczasowo ustawia się na tajną wartość. Na podstawie całego komunikatu (oprócz privDst) oblicza się wyciąg i porównuje z wartością przechowywaną (tą, którą otrzymano wraz z komu­nikatem). Jeśli wartości te są takie same, akceptuje się komunikat jako autentyczny.

6. Jeśli kontekst podany w nagłówku komunikatu jest nieznany, komunikat odrzuca się.

7. Sprawdza się w lokalnej bazie danych, czy przywileje dostępu zezwalają na żądaną operację. Jeżeli nie, komunikat zostaje odrzucony i generuje się komunikat o błędzie, który wysyła się do strony „a”. Jeśli dostęp jest dozwolony, przeprowadza się syn­chronizację zegara, i wykonuje polecenie podane w PDU.

3.6. Kontrola dostępu

Na politykę kontroli dostępu składają się cztery elementy:

• Strona przeznaczenia: Strona SNMP wykonująca operacje zarządzania na żądanie stro­ny źródłowej.

• Strona źródlowa: Strona SNMP żądająca wykonania operacji zarządzania na żądanie strony przeznaczenia.

• Zasoby: Informacje zarządzania, na których można przeprowadzać żądane operacje zarządzania w postaci lokalnego widoku MIB lub relacji pełnomocnictwa; ten element nazywamy kontekstem.

• Przywileje: Operacje dozwolone, zdefiniowane jako dozwolone PDU, przynależące do danego kontekstu, i do których wykonywania w imieniu podmiotu jest uprawniony odbiorca.

A zatem, politykę kontroli dostępu określają trzy parametry. Strona źródłowa żąda przeprowadzenia operacji zarządzania od strony przeznaczenia i podaje kontekst żądania Kontekst może określać widok MIB lokalny dla strony przeznaczenia lub odległą jedno­stkę reprezentowaną. Dla danej pary stron źródłowa/przeznaczenia może być wiele polityk kontroli dostępu, po jednej na każdy kontekst. Kontekst jest przekazywany przez źródło miejscu przeznaczenia w nagłówku komunikatu SNMPv2. Metoda ta eliminuje konieczność określania niepowtarzalnej pary stron źródłowa/przeznaczenia na każdą po­litykę kontroli dostępu i umożliwia pojedynczej stronie przeznaczenia działanie w wielu kontekstach dla danej strony źródłowej.

Wartość parametru przywilejów opisuje listę PDU SNMPv2, które mogą być przesy­łane z danego źródła do danego miejsca przeznaczenia. Parametr ten koduje się przez przypisanie każdemu PDU wartości całkowitej będącej potęgą liczby 2:

Get	1
GetNext	2
Response	4
Set	8
- niewykorzystana	16
Get-Bulk	32
Inform	64
SNMPv2-Trap	l28

Kontrolę dostępu określają informacje zawarte w MIB stron. Baza ta składa się z czterech tablic: tablicy stron, tablicy kontekstów, tablicy kontroli dostępu i tablicy widoków WIB (tabela 10.3). Najlepszym sposobem opisu funkcji tych tablic pod względem kontroli dostępu będzie rozważenie ich zastosowania podczas przesyłania komunikatów.

Tabela. MIB stron SNMPv2

1. Tablica stron

Obiekt	Opis
PartyIdentity	Niepowtarzalny identyfikator strony.
Partylndex	Niepowtarzalna wartość całkowita związana ze stroną.
PartyTDomain	Usługa transportowa użyta do SNMPv2.
PartyTAddr	Adres tej strony.
PartyMaxMessageeSize	Maksymalna długość komunikatu, który strona może zaakceptować (w oktetach).
PartyLocal	Wartość boolowska wskazująca, czy strona jest lokalna dla agenta lub menedżera.
PartyAuthProtocol	Opisuje mechanizm stosowany przez stronę do uwierzytelniania pochodzenia i zapewniania nienaruszalności wysyłanych komunikatów. Wartość noAuth oznacza, że komunikaty generowane przez tę stronę nie podlegają uwierzytelnianiu.
PartyAuthCłock	Lokalna wersja aktualnego czasu strony.
PartyAuthPrivate	Tajna wartość potrzebna do protokołu uwierzytelniania.
PartyAuthPublic	Jawna wartość ew. potrzebna do protokołu uwierzytelniania.
PartyAuthLifetime	Górna granica akceptowalnego opóźnienia dostarczenia komunikatów generowanych przez stronę.
PartyPrivProtocol	Wskazuje mechanizm stosowany do ochrony przed ujawnieniem komunikatów otrzymywanych przez stronę. Wartość noPriv oznacza, że komunikaty otrzymywane przez stronę nie są chronione przed ujawnieniem.
PartyPrivPrivate	Tajna wartość potrzebna w protokole prywatności.
PartyPrivPublic	Jawna wartość ew. potrzebna w protokole prywatności.
PartyCloneFrom	Identyfikator strony, z której należy skopiować parametry dotyczące uwierzytelniania i prywatności, aby stworzyć tę pozycję.

(b) Tablica kontekstów

Obiekt	Opis
ContextIdentity	Niepowtarzalny identyfikator kontekstu.
ContextIndex	Niepowtarzalna wartość całkowita związana z kontekstem.
ContextLocal	Wartość boolowska określająca, czy kontekst ten jest realizowany przez danego menedżera lub agenta.
ContextViewIndex	Jeżeli jest on równy 0, wiersz ten odnosi się do kontekstu określającego relację pełnomocnictwa; w innym przypadku wiersz ten dotyczy kontekstu określającego widok MIB jednostki lokalnie dostępnej, a wartość tego obiektu stanowi indeks do ViewTable.
ContextLocalEntity	Jeśli ContextViewIndex jest większy od 0, wartość ta określa lokalną jednostkę, dla której dane o zarządzaniu znajdują się w widoku MIB kontekstu. Pusty napis oznacza. że ten widok MIB zawiera własne, lokalne dane o zarządzaniu jednostki.
ContextProxyDstParty	Jeśli ContextViewIndex jest równy 0, wartość ta określa stronę, która jest stroną przeznaczenia w relacji pełnomocnictwa.
ContextProxySrcParty	Jeśli ContextViewIndex jest równy 0, wartość ta określa stronę, która jest stroną źródłową w relacji pełnomocnictwa.
ContextProxyContext	Jeśli ContextViewIndex jest równy 0, wartość ta określa kontekst relacji pełnomocnictwa.

(c) Tablica kontroli dostępu

Obiekt	Opis
AclTarget	Docelowa strona SNMP, wykonująca operacje zarządzania ograniczane przez dany zbiór przywilejów.
AclSubject	Strona SNMP, wydająca żądania przeprowadzenia operacji zarządzania ograniczonych przez dany zbiór przywilejów.
AclResources	Kontekst w polityce kontroli dostępu.
AclPrivileges	Liczba całkowita z przedziału od 0 do 255, kodująca przywileje dostępu dla danej trójki (cel, podmiot, kontekst).

(d) Tablica widoku MIB

Obiekt	Opis
ViewIndex	Niepowtarzalna wartość każdego widoku MIB
ViewSubtree	Poddrzewo MIB
ViewMask	Maska bitowa, która wraz z odpowiadającym jej ViewSubtree (poddrzewem) określa rodzinę poddrzew MIB.
ViewType	Przyjmuje wartości: włączone (1), wyłączone (2). Wskazuje, czy odpowiadająca mu rodzina poddrzew zdefiniowana przez viewSubtree i viewMask jest włączona, czy wyłączona z danego widoku MIB.

Załóżmy. że menedżer wysyła komunikat do agenta. Nagłówek komunikatu zawiera pola srcParty, dstParty i context. Tablica stron u agenta zawiera informacje o każdej lokalnej i odległej stronie znanej agentowi.

Informacje o stronach obejmują parametry uwierzytelniania, które mają być stosowa­ne dla srcParty (strony źródłowej) i parametry prywatności, które mają być stosowane dla dstParty (strony przeznaczenia). Tablica kontekstów zawiera jeden element na każdy kontekst znany agentowi. Każdy z nich określa, czy kontekst jest lokalny (musi wówczas zostać zastosowany odpowiedni widok MIB), czy odległy (w takim przypadku określone jest urządzenie reprezentowane). Tablica kontekstów zawiera odniesienia do tablicy wi­doków MIB. Odpowiednia pozycja określa podzbiór lokalnej MIB, do którego dostęp można uzyskać w danym kontekście. Wreszcie, każda pozycja tablicy kontroli dostępu zawiera niepowtarzalną kombinację wartości srcParty, dstParty i kontekstu oraz określa, które operacje zarządzania (PDU) są dozwolone dla danej kombinacji.

3.7. MIB stron

Poprzednie omówienie zagadnień kontroli dostępu daje pewne pojęcie u funkcjach każdej z czterech tablic w MIB stron. W tym podrozdziale przyjrzę się bliżej poszczególnym tablicom.

Tablica stron

Tablica stron zawiera po jednej pozycji na każdą stronę znaną lokalnemu menedżero­wi lub agentowi. Każda pozycja zawiera parametry uwierzytelniania (authProtocol, auth­Clock, authPrivate, authPublic, authLifetime) i parametry prywatności (privProtocol, privPrivate. privPublic), opisane wcześniej w tym podrozdziale. Należy zwrócić uwagę, że w tablicy tej przechowuje się wartość zegara strony. Raz na sekundę lokalny menedżer lub agent musi zwiększyć wartość zegara dla każdej pozycji tablicy.

Tablice kontekstów

Tablica kontekstów może zawierać dwa rodzaje pozycji: związane tyko z informa­cjami lokalnymi oraz związane z relacjami pełnomocnictwa. Rodzaj pozycji określa pole viewIndex:

• Jeżeli w polu viewIndex znajduje się wartość niezerowa, wiersz ten dotyczy informacji lokalnych, a wartość viewIndex stanowi indeks do tablicy widoków, określając w ten sposób odpowiedni widok MIB. W tym przypadku pole LocalEntity określa lokalna jednostkę, dla której informacja o zarządzaniu znajduje się w danym widoku MIB; jednostką tą może być jednostka SNMPv2 (pusty napis) bądź inna jednostka kontrolowa­na lokalnie (np. ”Repeater l"). Wartość w polu LocalTime określa kontekst czasowy.

• Jeżeli w polu viewIndex jest wartość zero, wiersz ten odnosi się do relacji pełnomocnictwa. W takim przypadku wartości pól srcPartyIndex i dstPartyIndex są indeksami do tablicy stron i odsyłają do stron źródłowej i przeznaczenia danej relacji pełnomocnictwa, a wartość proxyContext jest identyfikatorem kontekstu.

4. Protokół SNMPv3

Od czasu pierwszej publikacji w 1988 roku Simple Network Management Protocol (SNMP) stał się najszerzej używanym narzędziem do zarządzania sieciami opartymi na TCP/IP.

Błyskawiczny wzrost popularności SNMP datujący się od wczesnych lat 90-tych, który następował mimo świadomości jego usterek, zaczął spadać ze względu na szereg zastrzeżeń w stosunku do wielu funkcjonalnych usterek, takich jak niezdolność do łatwego sprecyzowania transferu dużych ilości danych, usterki w bezpieczeństwie, takie jak brak autentyfikacji i mechanizmów prywatności(privacy mechanism).

Wiele z tych funkcjonalnych usterek zostało rozwiązanych w serii nowych dokumentów RFC, które ukazały się w 1993 roku. Dokumenty te zawierały drugą wersje naszego protokołu znana jako SNMPv2. Wersja ta zawierała pewne mechanizmy bezpieczeństwa, lecz nie były one szeroko zaakceptowane z powodu braku konsensusu i zauważonych pewnych usterek w definicji. Zatem w 1996 roku powstała skorygowana edycja SNMPv2

W styczniu 1998 roku ukazała się kolejna propozycja standardu zawarta w dokumentach RFC 2271-2275.

SNMPv3 składa się jakby z trzech modułów:

• Message Processing and Control, który obsługuje tworzenie wiadomości SNMP

• Local Processing, który steruje dostępem do danych w polach Variable Binding i

przetwarza te dane

• User Security Model, który dostarcza funkcje autentyfikacji i utajniania, oraz kontroluje momenty przychodzenia w czasie pewnych wiadomości SNMP (timeliness of certain SNMP messages)

Większość istotnych ulepszeń SNMPv3 w stosunku do SNMPv1 i SNMPv2 polega na dodaniu dodatkowych elementów bezpieczeństwa. Większość dużych producentów, którzy stosowali SNMP mówiło, że brak jest w nim efektywnych zabezpieczeń. Na przykład chodzi o to, aby tylko autoryzowany personel mógł dokonywać funkcji związanych z zarządzaniem siecią (na przykład wyłączenie/uaktywnienie linii) i aby tylko autoryzowany personel miał dostęp do informacji związanych z zarządzaną siecią (np. zawartość pliku konfiguracyjnego).

A więc SNMPv3 dostarcza trzy nowe cechy związane z bezpieczeństwem: autentyfikację, utajnianie i kontrolę dostępu. Autentyfikacja umożliwia agentowi weryfikację, że przybywające polecenie pochodzi od osoby uprawnionej do zarządzania siecią i że jego zawartość nie była po drodze zmieniana. Dla osiągnięcia tego każdy manager i agent, którzy pragną się komunikować musi udostępnić tajny klucz. Manager używa tego klucza do obliczania kodu autentyfikacji wiadomości, który jest do niej dołączany i transmitowany. Kiedy agent otrzyma wiadomość, używa on tego samego klucza i oblicza kod autentyfikacji wiadomości jeszcze raz. Jeśli wersja tego kodu obliczona przez agenta jest taka jak dołączona do przybywającej wiadomości, wtedy agent wie, że wiadomość może pochodzić od autoryzowanego managera i że nie była ona zmieniana w czasie transmisji.

Zdolność zachowania tajemnicy umożliwia managerom i agentom utajnianie wiadomości co zapobiega podsłuchiwaniu przez osoby trzecie. W tym przypadku, jeśli obydwaj są skonfigurowani do korzystania z zachowania tajemnicy, cała komunikacja pomiędzy nimi jest utajniona.

Zdolność kontroli dostępu polega na odpowiednim konfigurowaniu agentów, w celu dostarczania różnych poziomów dostępu dla różnych managerów. Dostęp może być limitowany poprzez ilość komend, które agent może zaakceptować od danego managera i również w jednostkach porcji MIB-a, do których dany manager może uzyskać dostęp. Postępowanie przy kontroli dostępu używane przez agentów w stosunku do każdego managera musi być wcześniej ustalone i istotnie składa się z tabeli, która zawiera szczegóły uprzywilejowujące dostęp dla pewnych autoryzowanych managerów, a uniemożliwiające dla innych.

Z tymi nowymi cechami wzmacniającymi bezpieczeństwo, osoba zarządzająca siecią powinna mieć dużo większy komfort, szczególnie w dużych instalacjach z dużą liczbą użytkowników.

Zarówno w SNMPv1 jak i SNMPv2 brakuje cech bezpieczeństwa, takich jak dobra autentyfikacja i zapewnienie tajności, które to cechy byłyby wymagane dla pełnej użyteczności tego protokołu. Niedawna seria dokumentów RFC traktujących o SNMPv3 zapełnia tę lukę.

Number	Title	Date
RFC 2271	An Architecture for Describing SNMP Management Frameworks	January 1998
RFC 2272	Message Processing and Dispatching for SNMP	January 1998
RFC 2273	SNMPv3 Applications	January 1998
RFC 2274	User-Based Security Model for SNMPv3	January 1998
RFC 2275	View-Based Access Control Model (VACM) for SNMP	January 1998
Internet Draft	Introduction to Version 3 of the Internet Network Management Framework	August 1998

Tabela 1. Dokumenty opisujące SNMPv3

Ta seria dokumentów, oprócz zdefiniowania struktury protokołu znanej już z SNMPv1 i SNMPv2 definiuje wyraźnie elementy związana z bezpieczeństwem sieci i kontrolowanym dostępem. Ważne jest to, że realizacja SNMPv3 nie jest równoważna zastąpieniu SNMPv1 i/lub SNMPv2. SNMPv3 definiuje elementy bezpieczeństwa, które mogą być używane w połączeniu z SNMPv2 (co jest preferowane), lub z SNMPv1. W dodatku, RFC 2271, który jest jednym z dokumentów „wypuszczonych” przez grupę pracującą nad SNMPv3 opisuje architekturę, której wnętrze jest dopasowane do wszystkich bieżących i przyszłych wersji SNMP. RFC 2275 opisuje elementy kontroli dostępu. W ten sposób tylko trzy z tych pięciu dokumentów opublikowanych przez tę grupę traktuje o bezpieczeństwie w SNMPv3.

Poniższy rysunek opisuje relacje pomiędzy różnymi wersjami SNMP.

Informacja, w postaci wiadomości SNMP jest przesyłana pomiędzy stacja zarządzającą, a agentem. Proces związany z zapewnieniem bezpieczeństwa pochodzi od niższej warstwy, aniżeli standardowe wiadomości SNMP. SNMPv3 specyfikuje User Security Model (USM), który to dodaje swój nagłówek do tradycyjnej ramki SNMP.

Pole Protocol Data Unit (PDU) wskazuje na typ raki (np. set lub get) oraz listę nazw zmiennych związanych z typem.

W wymienionych powyżej dokumentach RFC opisywana jest cała architektura oraz struktura przesyłanych wiadomości, lecz nie został zdefiniowany nowy format PDU. A więc format istniejący w poprzednich wersjach protokołu musi być używany także z nową architekturą.

Terminologia

W poniższej tabeli zawarłem kilka terminów, które zostały wprowadzone w RFC 2271.

snmpEngineID	Unikalny i niedwuznaczny identyfikator od SNMP
ContextEngineID	Unikalnie identyfikuje an SNMP mogący realizować przykład z kontekstu za pomocą indywidualnego contextName.
contextName	Identifies a particular context within an SNMP engine. It is passed as a parameter to the Dispatcher and Access Control Subsystem.
scopedPDU	A block of data consisting of a contextEngineID, a contextName, and an SNMP PDU. It is passed as a parameter to/from the Security Subsystem.
SnmpMessageProcessingModel	Unique identifier of a message processing model of the Message Processing Subsystem. Possible values include SNMPv1, SNMPv2c, and SNMPv3.
SnmpSecurityModel	Unique identifier of a security model of the Security Subsystem. Possible values include SNMPv1, SNMPv2c, and USM.
SnmpSecurityLevel	A level of security at which SNMP messages can be sent or with which operations are being processed, expressed in terms of whether or not authentication and/or privacy are provided. The alternative values are noAuthnoPriv, authNoPriv, and authPriv.
principal	The entity on whose behalf services are provided or processing takes place. A principal can be an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or set of applications; and combinations thereof.
securityName	A human-readable string representing a principal. It is passed as a parameter in all of the SNMP primitives (Dispatcher, Message Processing, Security, Access Control)

Tabela 2. Terminologia stosowana w SNMPv3

Bottom of Form 1

Message Processing i User Security Model

Proces wysyłania wiadomości zawiera w sobie elementy znane z poprzednich wersji SNMP jak i elementy nowe związane z zapewnieniem bezpieczeństwa. Związek ten jest pokazany na poniższym rysunku:

Message Processing Model

Dokument RFC 2272 definiuje uniwersalny model przetwarzania wiadomości. Model ten jest odpowiedzialny za akceptację PDU od dyspozytora, enkapsulację go w wiadomości, oraz za wzywanie USM do wstawiania parametrów związanych z bezpieczeństwem w nagłówek wiadomości. Model ten obejmuje także przybywające wiadomości, wzywa USM do przetwarzania parametrów zawartych w nagłówku, oraz dostarcza „wyłuskane” PDU do dyspozytora.

Kolejny rysunek ilustruje strukturę wiadomości:

Pierwsze pięć pól jest generowanych przez Message Processing Model dla wychodzących wiadomości i poddawane przetwarzaniu przez ten model dla wiadomości przychodzących. Następne sześć pól pokazuje parametry związane z bezpieczeństwem, a używane przez USM. Na końcu znajduje się PDU wraz z contextEngineID i contextName.

Te pierwsze pięć pól to:

• MsgVersion: ustawiane jako SNMPv3 (3)

• MsgID: unikalny identyfikator używany pomiędzy dwoma podmiotami SNMP do koordynowania żądań i odpowiedzi (request and response messages). Zakres tego identyfikatora zawiera się w granicach od zera do 2³¹-1

• MsgMaxSize: przenosi maksymalny rozmiar wiadomości (w oktetach) wspieranej przez nadawcę. Zakres tego parametru waha się od 484 do 2³¹-1. Parametr ten wyznacza maksymalny rozmiar segmentu, jaki nadawca może zaakceptować od innego podmiotu SNMP (może to być odpowiedź na poprzedzajace ją żądanie lub też inny typ wiadomości)

• MsgFlags: jeden oktet zawierający trzy flagi zapisane na najmniej znaczących trzech bitach. Są to reportableFlag, privFlag, oraz authFlag. Jeśli reportableFlag=1, wówczas ?????

• MsgSecurityModel: jest to identyfikator w zakresie od 0 do 2³¹-1, który określa który model bezpieczeństwa został użyty przez nadawcę przy tworzeniu tej wiadomości, a zatem także jaki model musi być użyty przez odbiorcę do przetworzenia tej wiadomości. Zarezerwowane wartości to: 1 dla SNMPv1, 2 dla SNMPv2c oraz 3 dla SNMPv3

5. Management Information Base MIB

Management Information Base określa jakie informacje musi przechowywać router i jakie operacje mogą być na nich określone. Standard ten wymaga także, aby oprogramowanie IP przechowywało o liczbie oktetów przychodzących do każdego z interfejsów sieciowych, określa też, że oprogramowanie zarządzające może jedynie odczytywać tę informację. Standard MIB dla TCP/IP dzieli informacje sterujące na dziesięć kategorii:

Kategoria MIB	Związane informacje
system	System operacyjny komputera lub rutera
interfaces	Poszczególne interfejsy sieciowe
address translation	Tłumaczenie adresów (np. odwzorowanie ARP)
ip	Oprogramowanie IP
icmp	Oprogramowanie ICMP
tcp	Oprogramowanie TCP
udp	Oprogramowanie UDP
egp	Oprogramowanie EGP
transsmision	Media transmisyjne
SNMP	Statystyki systemu

Poza standardem MIB dla TCP/IP, znanym jako MIB-II, wiele dokumentów RFC definiuje zmienne MIB dotyczące określonych urządzeń. Dokonajmy analizy kilku przykładowych pozycji w standardzie MIB:

Zmienna MIB	Kategoria	Znaczenie
sysUpTime	system	Czas od uruchomienia systemu
ifNumber	interfaces	Liczba interfejsów sieciowych
ifMtu	interfaces	MTU wskazanego interfejsu
ipDefaultTTL	ip	Wartość wstawiana przez IP w polu czasu życia
iplnReceives	ip	Liczba otrzymanych datagramów
IpForwDatagrams	ip	Liczba przekazanych datagramów
IpOutNoRoutes	ip	Liczba błędów trasowania
ipReasmOks	ip	Liczba złożonych datagramów
ipFragOKs	ip	Liczba fragmentowanych datagramów
IpRoutingTable	ip	Tablica tras IP
icmplEchos	icmp	Liczba otrzymanych próśb o echo ICMP
tcpRtoMin	tcp	Minimalny dowolny czas retransmisji TCP
tcpMaxConn	tcp	Maksymalna dowolna liczba połączeń TCP
tcplnSegs	tcp	Liczba otrzymanych segmentów TCP
UdplnDatagrams	udp	Liczba otrzymanych datagramów UDP
egplnMsgs	egp	Liczba otrzymanych komunikatów EGP

Do przechowywania wartości większości pozycji wystarczy liczba całkowita. Inne zmienne MIB to: octet string, object indentifier i null. Zmienne MIB mogą jednak definiować bardziej złożone struktury. Na przykład mogą to być tablice, tak jak to jest w przypadku np.: ipRoutingTable - tablica tras rutera. Zawartości pozycji tablicy tras odpowiadają dodatkowe zmienne MIB, co pozwala protokołowi zarządzania siecią odwoływać się do informacji składowych poszczególnych pozycji tablicy tras.

Oczywiście zmienne MIB określają tylko logiczną strukturę poszczególnych pozycji - wewnętrzne struktury danych rutera mogą być reprezentowane zupełnie inaczej. Po otrzymaniu zapytania oprogramowanie agenta rutera dokonuje odwzorowania informacji przechowywanych w wewnętrznych strukturach danych rutera na reprezentację zmiennych MIB.

Oprócz standardu MIB, który definiuje zmienne używane przy zarządzaniu siecią oraz znaczenie tych zmiennych, istnieje osobny standard, który określa reguły definiowana i identyfikacji zmiennych MIB. Reguły te są znane jako Structure and Identification of Management Information (SMI) - RFC 1155. W celu uproszczenia protokołów zarządzania siecią SMI wprowadza ograniczenia na typ zmiennych MIB, określa reguły nazywania tych zmiennych oraz reguły definiowania typów zmiennych. Co więcej reguły SMI precyzują, w jaki sposób można się odwoływać do tabel MIB.

Definicje i odwołania do zmiennych MIB muszą używać notacji dla składni abstrakcyjnej ASN.1 (Abstract Syntax Notation 1) opracowanej przez ISO. Precyzyjna i formalna notacja umożliwia uniknięcia jakichkolwiek niejednoznaczności zarówno dotyczących reprezentacji, jak i znaczenia. Poza zapewnieniem jednoznaczności dokumentów standaryzacyjnych, ASN.1 umożliwia uproszczenie implementacji protokołów zarządzania siecią i zapewnia współpracę produktów różnych firm. Dostarcza ona ścisłej definicji kodowania nazw i wartości danych w komunikacie. Wobec tego, jeżeli dokumentacja MIB będzie wyrażona w notacji ASN.1, to można bezpośrednio i jednoznacznie przekształcić wersję czytelną dla człowieka na zakodowaną postać używaną w komunikatach. Określając krótko protokoły zarządzania sieciami TCP/IP używają formalnej notacji ASN.1 do definiowania nazw i typów zmiennych w bazie informacji. Ścisła notacja zapewnia jednoznaczność reprezentacji nazw i wartości zmiennych.

Zrozumienie nazw zmiennych MIB wymaga zapoznania się z przestrzenią nazw:

root

join ISO ITU ISO-ITU

1 2 3

org

3

dod

6

internet

1

expe

directory mgmt rimental private

1 2 3 4

Nazwy zmiennych MIB pochodzą z przestrzeni nazw identyfikatorów obiektów zarządzanej przez ISO i ITU. Przestrzeń nazw identyfikatorów obiektów dostarcza nazw dla wszystkich możliwych obiektów.

Przestrzeń nazw identyfikatorów obiektów jest absolutna (globalna), co oznacza, że struktura nazw zapewnia ich globalną unikatowość. Podobnie jak większość dużych, absolutnych przestrzeni nazw, przestrzeń identyfikatorów obiektów jest hierarchiczna. Odpowiedzialność za poszczególne jej części jest dzielona na każdym poziomie, co umożliwia indywidualnym grupom samodzielne przydzielanie niektórych nazw bez konieczności konsultowania każdego wyboru z władzą centralną.

Korzeń hierarchii identyfikatorów obiektów nie ma nazwy, ale ma trzech bezpośrednich potomków zarządzanych przez ISO, ITU oraz wspólnie przez ISO i ITU. Potomkowie są identyfikowani zarówno przez krótkie nazwy, jak i numery (nazwy są używane przy komunikacji z ludźmi, oprogramowanie używa numerów, które zapewniają zwięzłą reprezentację nazw). ISO zarezerwowało jedno z poddrzew dla innych krajowych lub międzynarodowych organizacji standaryzacyjnych, a jedno z poddrzew zostało przydzielone Departamentowi Obrony USA.

Nazwa obiektu w hierarchii jest ciągiem numerów wierzchołków wzdłuż ścieżki od korzenia do danego obiektu. Ciąg taki jest zapisywany w postaci liczb oddzielonych kropkami. Na przykład 1.3.6.1.1 wskazuje wierzchołek o etykiecie directory. Dla MIB przydzielono wierzchołek w poddrzewie internet mgmt o etykiecie mib i numerze 1. Poszczególne kategorie na jakie dzieli zmienne MIB to poddrzewa wierzchołka mib.

Nazwy zmiennych MIB używanych przez protokoły w komunikatach są zawsze zakończone stosownym sufiksem. Dla zwykłych zmiennych jest używany sufiks 0, który oznacza zmienną o takiej właśnie nazwie.

Nie ma żadnego sposobu na odgadnięcie wartości numerycznej lub sufiksu odpowiadającego danej zmiennej. Wartości numeryczne przydzielane danym typom obiektów są określane przez dokumenty standaryzacyjne i tylko tam je można znaleźć. Zatem programy, które dokonują konwersji między numerami i nazwami muszą do tego celu używać tabel przyporządkowań - nie ma żadnych algorytmów, które pozwalałaby wyliczenie tych informacji.

Jeśli chodzi o tablicę adresów IP jest ona z punktu widzenia języków programowania jednowymiarową tablicą, której elementami są rekordy składające się z pól: adresu IP, numeru portu, maski podsieci IP, adresu rozgłaszania IP oraz maksymalnego rozmiaru datagramu, który ruter może złożyć. Nie każdy ruter przechowuje w pamięci taką tablicę. Informacje takie mogą być przechowywane w wielu zmiennych lub w strukturze powiązanej wskaźnikami, pomimo to MIB określa nazwę tej tablicy tak jakby istniała w pamięci rutera i umożliwia oprogramowaniu zarządzania siecią poszczególnych ruterów odwzorowywanie nazw elementów tablicy na zewnętrzną reprezentację. Poszczególne elementy tablicy MIB są dostępne za pomocą odpowiedniego sufiksu nazwy. W przypadku naszej przykładowej tabeli adresów IP jako sufiks służy adres IP, który dokleja się na końcu nazwy obiektu.

6. Remote MONitoring (RMON)

6.1. Standard RMON 1

W przeszłości sieci komputerowe miały stosunkowo prostą budowę i topologię. Obecnie są to bardzo rozbudowane struktury, którymi zarządzać jest nieporównywalnie trudniej. Minęły już czasy, gdy sieć oplatała jedno biuro lub w najlepszym przypadku kilka zlokalizowanych blisko siebie budynków. Obecnie są to często tak duże zarówno w sensie fizycznym jak i geograficznym struktury, że administrator systemu musi dysponować niezbędnym zestawem narzędzi, pozwalającym mu zdalnie monitorować pracę całego systemu i w porę definiować oraz w miarę możliwości szybko usuwać ewentualne awarie.

Pracę sieci komputerowych można monitorować na dwa sposoby: przy uzyciu analizatorów protokołów sieciowych lub stosując aplikacje klasy RMON (Remote MONitoring - zdalny monitoring).

Pakiety SNMP nie pozwalają śledzić na bieżąco pracy sieci komputerowej oraz poddawać analizie krążące po niej pakiety, a następnie budować w postaci graficznej odpowiednie raporty. Tym platformom zarządzania brakuje właśnie monitoringu. Tutaj do akcji wkraczają narzędzia RMON, które umożliwiają zdalne monitorowanie sieci. Pakiety RMON zbierają i gromadzą dane, które są udostępniane im przez sondy instalowane w poszczególnych węzłach sieci, a następnie poddają je analizie , a w razie potrzeby generują raporty , przybierające postać wykresów czy grafów.

Prace nad standardem RMON1 zaczęto w 1990r. Pierwsza propozycja standardu (RFC 1271) ujrzała światło dzienne pod koniec 1991r. i opisywała sposób instalowania sond RMON w sieciach Ethernet. Standard w wersji draft został opublikowany trzy lata później (RFC 1757).

Sondy RMON definiują szereg dodatkowych (w porównaniu z SNMP) grup baz danych MIB. Dane gromadzone w tych bazach służą do dokładnego analizowania pracy danego urządzenia lub całego segmentu sieci LAN. Nowe bazy danych MIB zakładane przez sondy RMON, instalowane w sieciach Ethernet to:

• Statistics: dane statystyczne, np. liczba pakietów multicast i kolizji

• History: dane zbierane przez określony czas; możliwość ich analizowania

• Alarm: definiowanie warunków (progów), po przekroczeniu których system

generuje alarm

• Host: zbieranie danych statystycznych o pracy konkretnego urządzenia LAN,

zakładanie tablic zawierających adresy MAC urządzeń komunikujących

się z danym węzłem sieci.

• HostTopN: zbieranie informacji o urządzeniach pracujących w sieci

• Matrix: analizowanie ruchu pakietów

• Filter: możliwość definiowania, jakiego rodzaju pakiety (generowane przez

wskazaną podsieć) będą przez RMON zbierane

• Capture: możliwość przechwytywania i kopiowania określonych pakietów do

specjalnej pamięci

• Event: możliwość definiowania jak ma się zachować aplikacja po wystąpieniu

określonego zdarzenia

Wszystkie grupy są opcjonalne i producent aplikacji może wspierać wybrane przez siebie grupy lub jedną grupę.

RMON 1 pozwala administratorowi systemu zbierać informacje z odległych węzłów sieci, w tym gromadzić poprzednie i bieżące dane statystyczne opisujące pracę konkretnego segmentu (węzła sieci). Administrator może definiować graniczne progi (w odniesieniu do różnych parametrów monitorowanych przez sondę), po przekroczeniu których system wysyła do stacji zarządzania alarm. Aplikacje RMON dysponują mechanizmami do analizowania (filtry) ruchu pakietów, które pełnią rolę - pracujących niejednokrotnie w bardzo wyrafinowany sposób - analizatorów protokołów.

Aplikacje RMON składają się z dwóch części i mają architekturę podobną do rozwiązań typu klient / serwer. Klient jest uruchamiany na stacji zarządzającej siecią i prezentuje administratorowi dane RMON. Serwerami są elementy instalowane w różnych miejscach sieci - zbierają one informacje RMON i analizują pakiety przesyłane przez dany segment sieci. Urządzenia monitorujące noszą nazwę sond. Sonda współpracuje z oprogramowaniem instalowanym w pamięci węzła sieci, będącym niczym innym jak agentem systemu RMON. Agenci są instalowani w hubach, routerach, przełącznikach itd. Agent komunikuje się ze stacją zarządzania korzystając z usług protokołu SNMP.

Z biegiem czasu wymagania administratorów nadzorujących pracę sieciowych systemów informatycznych zaczęły wzrastać. Nie wystarczały im już informacje udostępniane przez sondy RMON1, które operowały w dwóch dolnych warstwach modelu OSI. Tak właśnie narodził się pomysł opracowania sond, które zbierałyby też informacje obecne w wyższych warstwach modelu OSI. W 1994r. narodził się standard RMON2 (RFC 2021).

6.2. Standard RMON 2

RMON2 to standard (zaakceptowany 16 stycznia 1997r.) wspierający te warstwy modelu OSI, do których sondy RMON1 nie mają dostępu. RMON2 definiuje szereg nowych baz danych MIB, w których można gromadzić dane generowane przez sześć warstw OSI (a w modelu OSI jest ich w sumie siedem). Ważne jest to, że użytkownik może tu analizować dane wymieniane między poszczególnymi segmentami sieci LAN, czego nie przewiduje standard RMON1. Sondy RMON2 analizują dane formowane przez warstwy sieci, transportu, sesji i prezentacji. W ten sposób administrator dysponujący narzędziem klasy RMON2, ma możliwość śledzenia pakietów generowanych np. przez protokoły IP, HTTP (sieć WEB) czy FTP. Tym samym przed administratorem rysują się zupełnie nowe możliwości, które pozwalają dużo efektywniej monitorować pracę sieci.

Czołowymi producentami narzędzi RMON są takie firmy jak Hewlett-Packard, 3Com, Bay Networks i Network.

W których warstwach modelu OSI (i protokołach używanych przez sieci różnych standardów) operują narzędzia RMON 1 i RMON 2

7. Element usługowy CMISE i protokół CMIP

Element usługowy ogólnej (wspólnej) informacji zarządzania CMISE (ang. Common Management Information Service Element) zapewnia usługi komunikacyjne związane z zarządzaniem zasobami. Usługi te nazywane usługami CMIS, umożliwiają przesyłanie między zarządcą i agentem (między systemem zarządzania a systemem zarządzanym) informacji zarządzania. Usługi CMIS umożliwiają procesowi zarządzającemu MP wykonanie operacji zarządzania, a procesowi agenta AP - przesłanie meldunku. Element usługowy CMISE korzysta z protokołu ogólnej (wspólnej) informacji zarządzania CMIP (ang. Common Management Information Protocol) oraz elementów usługowych ACSE (ustanowienie skojarzenia) i ROSE (operacje zdalne).

Procesy SMAP, które wymieniają informacje zarządzania przy pomocy elementu usługowego CMISE, można podzielić na dwie grupy:

• procesy wywołujące usługę elementu CMISE - proces MP żądający wykonania operacji lub proces AP, który wysyła meldunek

• procesy wykonujące usługę elementu CMISE - proces AP wykonujący operację lub proces MP, który otrzymuje meldunek

Podział ten nie opiera się na tym, który proces jest usługobiorcą, a który usługodawcą usług zarządzania, (model zarządca-agent), ale na tym, który z nich wywołuje, a który wykonuje usługi elementu usługowego CMISE.

7.1. Element usługowy ROSE

Funkcjonowanie rozproszonych i interakcyjnych programów aplikacyjnych, takich jak programy aplikacyjne zarządzania, może wymagać, by pewien system otwarty (proces aplikacyjny) wykonywał operacje w innym systemie otwartym (zlecał wykonanie operacji procesowi aplikacyjnemu tego systemu). Pierwszy proces jest nazywany procesem wywołującym (ang. invoker), a drugi procesem wykonującym (ang. performer). Operacje tego typu nazywane operacjami zdalnymi (ang. remote operation), są możliwe dzięki użyciu elementu usługowego ROSE (ang. Remote Operations Service Element). Element ROSE umożliwia systemowi wywołującemu zażądanie od systemu wywoływanego wykonania pewnej operacji zdalnej. System wywoływany próbuje zrealizować to żądanie (które może zakończyć się sukcesem lub porażką) i zdaje sprawozdanie dotyczące jego wykonania. Operacje zdalne i warunki ich wykonania opisuje się przy pomocy notacji RO-Notation, która opiera się, dzięki wykorzystaniu mechanizmu makrodefinicji na notacji ASN.1.

7.1.1. Tryby działania i klasy

Element usługowy ROSE dopuszcza dwa tryby działania:

synchroniczny, w którym proces wywołujący musi otrzymać odpowiedź wywoływanego procesu wykonującego, zanim będzie mógł wywołać inną operację zdalną;

• asynchroniczny, w którym operacja poprzednia nie musi być potwierdzana odpowiedzią przed wykonaniem innej operacji (tryb ten umożliwia wykonanie kilku operacji równocześnie)

Z pojęciem trybów wiąże się pięć klas operacji:

• klasa 1: tryb synchroniczny - raport zarówno gdy operacja zdalna zostaje zakończona sukcesem, jak i porażką

• klasa 2: tryb asynchroniczny - raport zarówno gdy sukces jak i porażka

• klasa 3: tryb asynchroniczny - raport tylko gdy porażka

• klasa 4: tryb asynchroniczny - raport tylko gdy sukces

• klasa 5: tryb asynchroniczny - bez raportów

7.1.2. Usługi, prymitywy i parametry

Element usługowy ROSE zapewnia pięć niepotwierdzanych usług:

• RO-INVOKE - proces wywołujący żąda wykonania operacji od procesu

wykonującego

• RO-RESULT - odpowiedź na RO-INVOKE, jeśli wykonanie żądanej operacji

zakończyło się sukcesem

• RO-ERROR - odpowiedź na RO-INVOKE, jeśli wykonanie żądanej operacji

zakończyło się porażką

• RO-REJECT-U - usługobiorca usług ROSE odrzuca żądanie RO-INVOKE lub

odpowiedź w postaci RO-RESULT lub RO-ERROR (np. jeśli

zawierają one parametry o niedozwolonych wartościach)

• RO-REJECT-P - to samo znaczenie co RO-REJECT-U, ale używana jest przez

usługodawcę usług ROSE (przez warstwę prezentacji)

7.2. Element usługowy CMISE

7.2.1. Przegląd usług

Zdefiniowano siedem usług elementu usługowego CMISE. Mogą one być wykonywane w dwóch trybach: potwierdzanym albo niepotwierdzanym. Przedstawiłem je poniżej :

• M-EVENT-REPORT

Usługa M-EVENT-REPORT służy do złożenia usługobiorcy meldunku o zdarzeniu (do zgłoszenia zdarzenia), które miało miejsce w sieci. Rodzaje meldunków nie są definiowane w standardzie opisującym element usługowy CMISE (ich definicje znajdują się w definicjach klas zarządzanych obiektów). Usługa M-EVENT-REPORT określa, który obiekt zarządzany meldował o zdarzeniu, a także podaje czas wystąpienia zdarzenia. Jest ona dostępna zarówno w wersji potwierdzanej jak i niepotwierdzanej.

• M-GET

Usługa M-GET pozwala usługobiorcy uzyskać dane o wartościach atrybutów określonego obiektu albo zbioru zarządzanych obiektów, wybranego dla określonego zakresu i filtru. Jednym z zastosowań tej usługi jest wybieranie podzbioru zarządzanych obiektów. Stosuje się ją tylko w trybie potwierdzanym.

• M-CANCEL-GET

Usługa M-CANCEL-GET umożliwia usługobiorcy odwołanie wcześniej wywołanego żądania usługi M-GET. Może być ona stosowana tylko w trybie potwierdzanym.

• M-SET

Usługa M-SET pozwala dokonać zmian wartości atrybutów obiektów i jest dostępna zarówno w wersji potwierdzanej jak i niepotwierdzanej. Wyboru obiektów dokonuje się poprzez określenie zakresu i filtru.

• M-ACTION

Przy pomocy usługi M-ACTION usługobiorca zleca zarządzanemu obiektowi (lub też podzbiorowi obiektów) wykonanie akcji określonej w jego definicji. Usługa ta jest dostępna w wersji potwierdzanej i niepotwierdzanej.

• M-CREATE

Usługa M-CREATE służy do utworzenia zarządzanego obiektu, przy czym przy pomocy jednego wywołania tej usługi można utworzyć tylko jeden obiekt. Usługa ta jest usługą potwierdzaną.

• M-DELETE

Usługa M-DELETE pozwala usunąć obiekt zarządzany, a także określony podzbiór obiektów (na podstawie zakresu i filtrowania). Usługa M-DELETE może być wykonywana tylko w trybie potwierdzanym.

Wybór trybu usługi - tzn. czy usługa potwierdzana czy też niepotwierdzana - dokonywany jest przy jej wywołaniu. W przypadku usługi potwierdzanej w potwierdzeniu może zostać przesłany czas wygenerowania potwierdzenia.

7.3. Protokół CMIP

Rolą protokołu CMIP jest przenoszenie informacji zarządzania dla usług CMISE. Protokół CMIP jest zależny od elementu usługowego ROSE i jego protokołu - definicja protokołu CMIP nie zawiera tablic stanów i tablic przejść. Protokół CMIP wykorzystuje wszystkie (oprócz RO-REJECT-P) usługi elementu usługowego ROSE, czyli RO-INVOKE, RO-RESULT, RO-ERROR i RO-REJECT-U. Stosowana jest klasa skojarzenia 3, co oznacza, że oba procesy, zarówno wywołujący jak i wywoływany, mogą wykonywać operacje zdalne korzystając z RO-INVOKE. Usługi potwierdzane korzystają z usług RO-RESULT i RO-ERROR w trybie synchronicznym (klasa 1) lub asynchronicznym (klasa 2). Z kolei usługi niepotwierdzane korzystają z trybu asynchronicznego (klasa 5).

7.3.1. Automat CMIPM

Automat CMIPM (ang.CMIP machine) określa zależność między usługami (prymitywami) elementu CMISE a reakcjami na nie protokołu CMIP, nazywanymi operacjami protokołu CMIP (ang. CMIP operations). Operacja polega na przekazaniu usługobiorcy usług CMISE odpowiedniego prymitywu lub na sformowaniu odpowiedniej jednostki APDU i przesłaniu jej elementowi ROSE.

Prymityw CMISE	Czy tryb potwierdzany ?	Czy jest obecny parametr Linked ID	Operacja CMIP
M-EVENT-REPORT req/ind	NIE		m-EventReport
M-EVENT-REPORT req/ind	TAK		m-EventReport-Confirmed
M-EVENT-REPORT res/con			m-EventReport-Confirmed
M-GET req/ind	TAK		m-Get
M-GET res/con		NIE	m-Get
M-GET res/con		TAK	m-Linked-Reply
M-CANCEL-GET req/ind	TAK		m-Cancel-Get-Confirmed
M-CANCEL-GET res/con			m-Cancel-Get-Confirmed
M-SET req/ind	NIE		m-Set
M-SET req/ind	TAK		m-Set-Confirmed
M-SET res/con		NIE	m-Set-Confirmed
M-SET res/con		TAK	m-Linked-Reply
M-ACTION req/ind	NIE		m-Action
M-ACTION req/ind	TAK		m-Action-Confirmed
M-ACTION res/con		NIE	m-Action-Confirmed
M-ACTION res/con		TAK	m-Linked-Reply
M-CREATE req/ind	TAK		m-Create
M-CREATE res/con			m-Create
M-DELETE req/ind	TAK		m-Delete
M-DELETE res/con		NIE	m-Delete
M-DELETE req/ind		TAK	m-Linked-Reply

Funkcjonowanie automatu opiera się na następujących zasadach:

• po odebraniu prymitywu żądania od elementu CMISE automat CMIPM formuje jednostkę danych APDU, którą zawiera żądanie wykonania przez system odległy operacji odpowiadającej żądanej usłudze elementu CMISE (np. żądanie usługi M- GET: operacja m-Get). Następnie automat CMIPM przesyła jednostkę APDU elementowi ROSE przy pomocy usługi RO-INVOKE, a ten przesyła ją dalej, korzystając z usług warstwy prezentacji (prymityw P-DATA);

• po odebraniu bezbłędnej jednostki APDU z żądaniem wykonania danej operacji automat CMIPM wykonuje ją, to znaczy albo przesyła usługobiorcy usług CMISE odpowiedni prymityw zawiadomienia, albo jeśli format jednostki APDU jest niepoprawny - odsyła wiadomość o błędzie przy pomocy usługi RO-REJECT;

• po otrzymaniu prymitywu odpowiedzi pośredniej (obecny parametr linked identifier) automat generuje jednostkę danych APDU z żądaniem wykonania operacji m-Linked-Reply w systemie odległym. Jednostka danych przesyłana jest przy pomocy usługi RO-INVOKE;

• po odebraniu prymitywu odpowiedzi końcowej (parametr linked identifier nie jest obecny) automat CMIPM generuje jednostkę APDU, która potwierdza wykonanie odpowiedniej operacji. Jeśli jednostka ta przenosi informacje o wyniku poprawnie wykonanej operacji, to stosowany jest prymityw RO-RESULT. Jeśli przenoszone informacje dotyczą wyniku operacji wykonanej tylko częściowo lub informacje o błędzie, wtedy wykorzystywany jest prymityw RO-ERROR;

• po odebraniu jednostki APDU potwierdzającej wykonanie operacji automat CMIPM albo przekazuje elementowi CMISE odpowiedni prymityw potwierdzenia, albo jeśli format jednostki APDU jest niepoprawny, odsyła wiadomość o błędzie przy pomocy prymitywu RO-REJECT.

7.3.2. Przykład zastosowania protokołu CMIP

Załóżmy, że proces w systemie A korzystający z elementu usługowego CMISE i protokołu CMIP, chce złożyć meldunek o zdarzeniu w sieci procesowi w systemie B i otrzymać potwierdzenie otrzymania meldunku. Przesyła on automatowi CMIPM (system A) prymityw M-EVENT-REPORT req w trybie potwierdzanym.

Dalsze etapy komunikacji po stronie systemu A zostały opisane poniżej:

1. Po otrzymaniu prymitywu przez element usługowy CMISE automat CMIPM rozpoczyna operację m-EventReport-Confirmed

2. Operacja m-EventReport-Confirmed polega na sformowaniu jednostki danych APDU, zawierającej parametry przekazane w prymitywie i przesłaniu jej elementowi usługowemu ROSE przy pomocy prymitywu RO-INVOKE req

3. Element ROSE, korzystając ze swojego protokołu przesyła jednostkę APDU warstwie prezentacji przy pomocy prymitywu P-DATA

Po stronie systemu B automat CMIPM odbiera jednostkę APDU za pośrednictwem prymitywu RO-INVOKE ind, a dalsze etapy przebiegają następująco:

4. Jeśli jednostka APDU została odebrana bezbłędnie, automat CMIPM przesyła usługobiorcy usług CMISE prymityw M-EVENT-REPORT ind (w przeciwnym razie elementowi ROSE jest sygnalizowany błąd przy pomocy prymitywu RO-REJECT)

5. Usługobiorca usług CMISE odpowiada prymitywem M-EVENT-REPORT res

6. Po otrzymaniu prymitywu przez element usługowy CMISE automat CMIPM rozpoczyna operację m-EventReport-Confirmed

7. W tym przypadku operacja m-EventReport-Confirmed polega na sformowaniu jednostki danych APDU, zawierającej parametry przekazane w prymitywie i przesłaniu jej elementowi usługowemu ROSE przy pomocy prymitywu RO-RESULT req

Po stronie systemu A automat CMIPM odbiera jednostkę APDU za pośrednictwem prymitywu RO-RESULT ind i jeśli dane zostały odebrane prawidłowo przesyła prymityw M-EVENT-REPORT conf procesowi, który rozpoczął opisaną wyżej wymianę.

Przykład wykorzystania protokołu CMIP (przesłanie meldunku w trybie potwierdzanym)

8. Zarządzanie w technologii webowej

8.1. Technologia WWW i zarządzanie

Efektywne wykorzystanie narzędzi platformy WWW do zarządzania systemami informatycznymi powinno przebiegać według zasady: do wykonania określonego zadania należy użyć odpowiedniego narzędzia.

Mówiąc najogólniej, proces zarządzania systemami i sieciami można podzielić na cztery podstawowe zadania. Można je w skrócie zdefiniować jako:

• Wiedzę (założenia i zdefiniowanie całego instrumentarium)

• Przesyłanie

• Przetwarzanie

• Prezentacja danych

Pierwsze zadanie polega na tym, że dane używane w procesie zarządzania muszą być prawidłowo zidentyfikowane i zdefiniowane. Wiąże się to z przygotowaniem całego instrumentarium, a więc: zainstalowaniem agentów w poszczególnych węzłach sieci i określeniem sposobu odczytywania danych generowanych przez te węzły i pozostałe stanowiska pracy (którymi będziemy zarządzać). Instrumentarium takie jest dokładnie określone w środowisku sieci Internet przez dwie specyfikacje, które przedstawiłem już wcześniej. Są to mianowicie: SMI (SNMP Structure of Management Information) opisana w RFC 1902, oraz MIB (Management Information Base) - bazy danych budowane przez aplikacje zarządzające systemami sieciowymi.

Zadanie drugie sprowadza się do dwóch spraw: w jaki sposób uzyskujemy dostęp do informacji gromadzonych w pamięciach zarządzanych urządzeń oraz jak te dane są przesyłane przez sieć. I znowu odpowiednie rozwiązania są opisane w środowisku sieci Internet przez specyfikację SNMP. Ponieważ aplikacje zarządzania nie są w tym przypadku zbyt wymagające (i informacje takie mogą być przesyłane przez sieć przy użyciu protokołu bezpołączeniowego), to do transportu danych SNMP używa się najczęściej protokołu UDP (User Datagram Protocol)

Zadanie trzecie to przetwarzanie i obróbka danych. Aplikacja zarządzania przetwarza zgromadzone dane na postać odpowiednią odpowiednia do ich zinterpretowania i poddania analizie. W tej warstwie zarządzania rezydują wiec programy wyposażone w inteligentnie pracujące mechanizmy. Potrafią one agregować, interpretować i zapisywać dane dostarczane przez poszczególne węzły sieci w takiej formie, aby można je było np. wyświetlić na ekranie konsoli zarządzania.

Zadanie czwarte. Ta część aplikacji odpowiada za udostępnienie (prezentację) informacji przetworzonej przez poprzednią warstwę końcowemu użytkownikowi, czyli administratorowi sieci komputerowej.

Wielu producentów oprogramowania zarządzającego sieciami znalazło się pod tak dużym wpływem technologii WWW, że nie oglądając się na nic starają się ją zastosować we wszystkich omówionych wcześniej zadaniach. Nie jest to właściwe podejście, ponieważ technologia WWW bynajmniej nie nadaje się do wszystkiego. Niewłaściwe jej zastosowanie może doprowadzić do tego, że aplikacja zarządzająca siecią pracuje mało wydajnie, a użytkownicy borykają się z problemami braku kompatybilności i mała podatnością na skalowanie takich aplikacji.

Przyjrzyjmy się uważniej, jak spisuje się technologia WWW w odniesieniu do każdego z czterech omówionych wcześniej zadań.

Przygotowanie instrumentarium wydaje się być łatwym i nieskomplikowanym zadaniem. Należy tu jednak przyjąć dwa założenia: po pierwsze - w przypadku problemów z urządzeniem użytkownik musi mieć możliwość odczytania strony webowej, a po drugie - aplikacja powinna tak pracować, aby administrator mógł w danym czasie monitorować pracę tylko tego jednego urządzenia.

WIEDZA - NIE

Poważne kłopoty występują na polu współfunkcjonowania (kompatybilność). Właściwie nie ma żadnych szans, aby oferowane przez poszczególnych producentów pakiety i urządzenia mogły się ze sobą komunikować bez przeszkód. Chyba że do definiowania danych używanych w procesie zarządzania sieciami i systemami użyto by jednego, akceptowanego przez wszystkich standardu (tak jak w przypadku SNMP i SMI). Jeśli każdy producent będzie umieszczać na stronach webowych dane w formacie rozumianym tylko przez jego aplikację, to będziemy zdani tylko na tę jedną, konkretną aplikację zarządzania. Bo chociaż dane generowane przez taką aplikację może odczytać każda przeglądarka WWW, to są one bezużyteczne - nie mogą być we właściwy sposób zinterpretowane. Każda z takich aplikacji będzie wtedy swego rodzaju wyspą, a pomiędzy wyspami nie będzie żadnej komunikacji.

Przez ostatnie osiem lat producenci sprzętu i oprogramowania uczynili gigantyczny wysiłek opracowując oparte na standardach (SNMP, MIB, SMI) sposoby definiowania instrumentarium i danych. Ponieważ standardy te zyskały ogólną akceptację, więc przemysł informatyczny oferuje obecnie produkty (dotyczy to zarówno warstwy sprzętowej, jak i oprogramowania), które mogą ze sobą bez przeszkód współpracować. Problem kompatybilności zostaje wreszcie rozwiązany i nagle pojawia się technologia WWW. Co robić? Budować wszystko od podstaw i zaprzepaścić dotychczasowe osiągnięcia czy też raczej wdrażać technologię WWW tak, aby nie burzyć starego porządku?

PRZESYŁANIE - NIE

Eksploatowane obecnie aplikacje zarządzania są oparte na architekturze składającej się z dwóch ściśle współpracujących ze sobą elementów: agenta (czy raczej wielu agentów) i menedżera. System zarządzania (czy też warstwa pośrednia, w której działa tzw. inteligentny agent) przegląda okresowo zarządzane urządzenia i zbiera gromadzone tam dane. Dane te są następnie analizowane i poddawane interpretacji. Zarządzane urządzenia mogą też same generować różnego rodzaju alarmy i pułapki (praca w trybie asynchronicznym) i w momencie wystąpienia awarii, czy też określonego zdarzenia przesyłać je do menedżera zarządzania.

Okazuje się, że język HTML i protokół HTTP nie najlepiej nadają się do wykonywania tego rodzaju zadań. Mamy tu bowiem do czynienia z „czynnikiem ludzkim”. Użytkownik musi po prostu sam uruchomić (klikając myszą na odpowiednim przycisku) procedurę odczytywania danych z odległego węzła sieci. Widać z tego, że pracując w ten sposób standardy HTTP/HTML nie nadają się do obsługiwania alarmów i pułapek generowanych w trybie asynchronicznym. Co prawda można zastosować aplety pisane w języku Java, które same emulują proces klikania myszą na wcześniej zdefiniowanym wskaźniku URL, ale prawdę powiedziawszy standardów HTML i HTTP nie pisano z myślą z myślą o wykonywaniu tego rodzaju zadań. Dlatego wydajność pracy aplikacji opartych na takim rozwiązaniu może pozostawiać wiele do życzenia.

Jakie jest zatem wyjście? Wydaje się, że technologie SNMP i WWW należy potraktować komplementarnie. Standard SNMP powinno się stosować w dwóch pierwszych fazach pracy aplikacji zarządzania (instrumentalizacja oraz dostęp do danych i ich transport przez sieć), a technologię WWW stosować do wykonywania dwóch ostatnich zadań (przetwarzanie i prezentacja danych).

Przeprowadzone ostatnio badania laboratoryjne i testy wykazały, że do transportu danych używanych przez aplikacje zarządzania (np. te oparte na standardzie SNMP) systemami i sieciami nadają się najlepiej protokoły bezpołączeniowe (UDP). Jednocześnie stwierdzono, że w przypadku uruchomienia aplikacji opartej na technologii WWW i zastosowaniu protokołu połączeniowego (HTTP/HTML przez protokół TCP) należy się liczyć z tym, że aplikacja taka będzie stwarzać kłopoty i pracować mało wydajnie.

PRZETWARZANIE - TAK

Standard SNMP pozwolił rozwiązać wiele problemów występujących w dwóch pierwszych fazach pracy aplikacji zarządzania (instrumentarium oraz dostęp do danych i transfer danych przez sieć), ale w pozostałych dwóch pozostaje jeszcze wiele do zrobienia. W dalszym ciągu należałoby poprawić takie elementy, jak interfejs dostępu do repozytorium z danymi czy efektywność programów do modelowania danych. Nie są to zagadnienia łatwe, ponieważ poszczególni producenci stosują różne technologie. Jeśli dodamy, że na rynku są dostępne aplikacje pracujące pod różnymi systemami operacyjnymi i obsługujące tylko określony rodzaj węzłów sieci i systemów, to sprawa komplikuje się jeszcze bardziej.

Właśnie tu technologia WWW (a szczególnie język Java) może przyjść z pomocą. Aplikacje oparte na tej technologii można przecież uruchamiać na komputerach różnych platform i może to być sposób na opracowanie uniwersalnego interfejsu dostępu do repozytorium z danymi.

WWW jest też taką technologią, która nadaje się wręcz idealnie do budowania programów prezentujących zebrane wcześniej dane i informacje. Dzięki niej można przecież łatwo prezentować dane na stronach webowych i udostępniać je wszystkim zainteresowanym. Jak już wspomniano wcześniej, podstawowa zaleta technologii HTTP/HTML i Java polega na tym, że aplikacje webowe można uruchamiać na komputerach różnych platform. Dlatego w określonych środowiskach pracy mogą one zastąpić z powodzeniem aplikacje X Windows.

PREZENTACJA - TAK

Alternatywne architektury prezentacji

Rynek aplikacji zarządzania oparty na technologii WWW dopiero raczkuje, a już wielu producentów i organizacji proponuje odmienne sposoby funkcjonowania takich aplikacji i różne architektury systemów zarządzania. Można wymienić cztery takie podstawowe architektury:

1. System zarządzania (oparty na technologii WWW) komunikuje się bezpośrednio z urządzeniami przy użyciu protokołu HTTP (po zainstalowaniu w pamięci tych urządzeń odpowiednich agentów).

2. Dostęp do systemu zarządzania jest realizowany przy użyciu protokołu HTTP i przeglądarki WWW, podczas gdy sam system zarządzania zbiera dane z węzłów sieci opierając się na technologii SNMP

3. System zarządzania wykorzystuje złącza programistyczne JaMAPI (Java Management API) i język Java

4. Architektura WBEM (Web-Based Enterprise Management)

Architektura pierwsza zakłada, że w pamięci każdego z zarządzanych urządzeń rezyduje serwer webowy, który udostępnia dane generowane przez to urządzenie (protokół HTTP). W wielu przypadkach urządzenie takie dysponuje tez interfejsem udostępniającym dane w standardzie SNMP. Można wtedy zarządzać nim również przez ogólnozakładowy system zarządzania oparty na tym standardzie (rys 1).

SYSTEM ZARZĄDZANIA SIECIĄ

W tej architekturze, aplikacja (oparta na technologii webowej) pracuje w ten sposób, że konsola zarządzania komunikuje się przy użyciu protokołu HTTP bezpośrednio z urządzeniami (po zainstalowaniu w pamięci tych urządzeń odpowiednich agentów i serwera webowego). W pamięci każdego z zarządzanych urządzeń rezyduje zawsze serwer webowy, udostępniający otoczeniu dane generowane w obszarze tego urządzenia (protokół HTTP). W wielu przypadkach urządzenie takie dysponuje też interfejsem udostępniającym dane w standardzie SNMP. Jest to bardzo dobre rozwiązanie (można wtedy elastycznie konfigurować poszczególne węzły sieci i stanowiska pracy), nie pozbawiona jednak wad: aplikacja taka nie daje się skalować, ponieważ sieć oparta na WWW wykorzystuje protokół połączeniowy.

Jak pracują tego rodzaju urządzenia? Stosuje się tutaj dwa rozwiązania:

• Węzeł sieci dysponuje dwoma oddzielnymi stosami komunikacyjnymi, z których jeden obsługuje protokół SNMP, a drugi HTTP.

• Nieraz stosuje się jeden, ale za to zintegrowany stos komunikacyjny, który jest w stanie obsłużyć każdy z tych protokołów (SNMP i HTTP). Mapowanie protokołów ma wtedy miejsce w wyższej warstwie stosu komunikacyjnego.

Technologię dwóch stosów komunikacyjnych zaimplementowało już w swoich produktach wielu producentów. Integracja dwóch protokołów w ramach jednego stosu ma jednak wiele zalet:

• Stos taki pracuje bezpieczniej, ponieważ dostęp do danych jest realizowany dużo prościej (przez pojedynczą ścieżkę dostępu)

• Nie występują problemy związane z synchronizacja dostępu do danych generowanych przez dwa różne protokoły

• Jest rzeczą oczywistą, że jeden stos zajmuje dużo mniej miejsca w pamięci komputera czy węzła sieci, niż dwa stosy

• Mechanizm zarządzania pracuje dużo przejrzyściej i spójniej (oba systemy zarządzania - SNMP i WWW - mają dostęp do wszystkich danych przez jedną ścieżkę odczytu)

• System taki daje się tez dużo łatwiej testować - mamy tu przecież do czynienia z jednym tylko stosem komunikacyjnym, a nie z dwoma

Ale system zarządzania oparty na technologii WWW ma też wiele wad i ograniczeń. Zarządzanie węzłem sieci nie sprowadza się przecież tylko do odczytania informacji z bazy danych MIB przy użyciu przeglądarki WWW. Trzeba pamiętać, że przeglądarki komunikują się z serwerem przesyłając dane za pomocą protokołu połączeniowego, który nie zdaje egzaminu w tego typu sytuacjach. W związku z tym aplikacja oparta na technologii WWW nie nadaje się do zarządzania dużymi systemami informatycznymi o rozbudowanej architekturze.

Właśnie dlatego systemy zarządzania oparte na technologii WWW poddają się bardzo trudno operacji skalowania i sprawują się kiepsko w zarządzaniu urządzeniami. Trzeba jednak przyznać, że pewne zadania związane z konfigurowaniem węzłów sieci i systemów można śmiało realizować przy użyciu tej technologii.

Technologia WWW zapewnia dostęp do systemu zarządzania

Architektura numer dwa zakłada, że przeglądarki WWW komunikują się z systemem zarządzania wykorzystując protokół HTTP, podczas gdy system zarządzania wymienia dane z zarządzanymi urządzeniami korzystając z usług SNMP i zainstalowanych w tych urządzeniach agentów (rys2).

Konsole systemu zarządzania

W architekturze tej przeglądarki webowe komunikują się z systemem zarządzania przy użyciu protokołu HTTP, podczas gdy system zarządzania wymienia dane z zarządzanymi urządzeniami korzystając z usług standardu SNMP i zainstalowanych w tych urządzeniach agentów. Po jednej stronie tego systemu mamy więc do czynienia z protokołami HTTP i UDP, a po drugiej z protokołami SNMP i TCP. Zaletą tej architektury jest to , że wiele przeglądarek może się komunikować jednocześnie z systemem zarządzania siecią. To samo można powiedzieć o systemie zarządzania, który może też obsługiwać równolegle wiele urządzeń.

Po jednej stronie tego systemu mamy więc do czynienia z protokołami HTTP i UDP, a po drugiej z SNMP i TCP. Zaletą tej architektury jest to, że wiele przeglądarek może jednocześnie uzyskiwać dostęp do systemu zarządzania siecią. To samo można powiedzieć o systemie zarządzania - może on zarządzać równolegle wieloma urządzeniami.

Jak z tego widać architektura taka rozwiązuje skutecznie problem zbierania danych i prezentowania ich użytkownikowi. Niestety, kwestie dostępu do repozytorium z danymi i modelowania danych nie są w należyty sposób przez nią obsługiwane.

Java i JMAPI

Architektura numer trzy (której twórcą jest SunSoft - inicjatywa Solstice Workshop) opiera się na języku Java i złączach programistycznych JMAPI. Solstice Workshop reprezentuje w tej architekturze środowisko służące do budowania aplikacji zarządzania opartych na technologii WWW, które wykorzystują wyspecjalizowane złącza programistyczne JMAPI. Oprócz złącz JMAPI środowisko Solstice Workshop pozwala budować niewielkie bazy danych i stwarza możliwość programowania w języku Java. Niewątpliwą zaletą tej architektury jest to, że złącza JMAPI i język Java pozwalają budować aplikacje zarządzania, którym można przypisać bardzo ważną cechę - „napisz raz i uruchamiaj wszędzie” (czyli na komputerach różnych platform). A przenośność aplikacji jest bardzo ważną rzeczą.

Architekturą tą jest już zainteresowanych wielu producentów oprogramowania i można oczekiwać, że wkrótce na rynku pojawią się pierwsze aplikacje w języku Java (oraz narzędzia do ich pisania) korzystające z usług złączy JMAPI. Będą one dysponować bardzo podobnymi (jeśli nie identycznymi) elementami do budowania i kontrolowania graficznych interfejsów użytkownika, dzięki czemu można już mówić o pewnym standardzie sposobu komunikowania się z aplikacją i wyświetlania danych.

Problem w tym, że jak dotąd nie zdefiniowano szczegółowo klas obiektów oferowanych przez złącza JMAPI. Może to opóźnić rozwój aplikacji opartych na tej technologii. Wydaje się, że mogą to zrobić (a nawet powinni) sami producenci tego rodzaju oprogramowania.

W każdym razie architektura ta jest bardzo atrakcyjna, ponieważ pozwala integrować (przynajmniej teoretycznie) w jeden organizm aplikacje uruchamiane na komputerach różnych platform. Aby jednak było to rzeczywiście możliwe, trzeba koniecznie opracować kilka standardów, które zdefiniują szczegółowo sposób integrowania takich aplikacji. Dopiero wtedy będzie można powiedzieć, że aplikacje zarządzania oparte na standardach Java/JMAPI są produktami w pełni przenośnymi.

Architektura WBEM

Wreszcie ostatnia architektura, która nosi nazwę WBEM. Jej założenia zostały przedstawione w połowie 1996r. Przez firmy Microsoft, Compaq, Cisco, BMC Software i Intel. Obecnie architektura ta jest już popierana i promowana przez 50 kolejnych firm. System zarządzania oparty na architekturze WBEM składa się z takich elementów jak:

• HyperMedia Management Schema to standard definiujący szczegółowo budowę danych używanych przez środowisko zarządzania WBEM. Intencją twórców tego standardu było, aby został on dopracowany i zaakceptowany przez DMTF (Desktop Management Task Force). Jednak DMTF zrezygnował z tego pomysłu i opracował własny standard, któremu nadał nazwę Common Information Model (CIM). CIM opisuje procedury mapowania danych generowanych przez dwie różne aplikacje: aplikacje oparte na standardzie HMMS i aplikacje pracujące zgodnie ze specyfikacjami CORBA, SNMP i DMTF.

• HyperMedia Object Manager to standard definiujący model danych, dzięki któremu system zarządzania może konsolidować dane pochodzące z różnych źródeł.

• HyperMedia Management Protocol to protokół komunikacyjny oparty na architekturze HMMS i standardzie HTTP. W przyszłości HyperMedia Management Protocol ma być wyposażony w interfejsy umożliwiające wymianę informacji z systemami opartymi na standardach SNMP i DMI.

Architektura WBEM/CIM idzie najdalej i wybiega tak daleko w przyszłość, że minie zapewne jeszcze sporo czasu, zanim pojawią się tu dopracowane rozwiązania (nie mówiąc tu już o gotowych do użycia aplikacjach).

Wizja systemu zarządzania

Język Java wydaje się być tym produktem, który pozwoli w przyszłości rozwiązać szereg problemów związanych z takimi cechami systemów zarządzania, jak wieloplatformowość czy kompatybilność. Język ten daje jednocześnie wiele nowych możliwości co do sposobu prezentowania danych. Niemała część producentów oprogramowania jest jednak tak zafascynowana tym językiem, że zdaje się powielać wiele błędów, których przemysł informatyczny nie ustrzegł się w przeszłości. Forsują oni rozwiązania nie przystające do eksploatowanych już systemów zarządzania sieciami komputerowymi (brak kompatybilności).

I tak np. takie architektury zarządzania (oparte na technologii WWW) jak JMAPI i WBEM, rywalizują obecnie z rozwiązaniami proponowanymi przez rozproszone środowisko zarządzania Distributed Management Environment (zaproponowane swego czasu przez Open Software Foundation). Może to powodować określone kłopoty z wdrażaniem systemów zarządzania klasy WWW.

Trzeba zauważyć, że twórcy systemów zarządzania opartych na języku Java i architekturze WBEM próbują na nowo definiować całe instrumentarium produktów tej klasy. Może to doprowadzić do określonych problemów kompatybilności czy wydajności takich systemów. Dane generowane przez nowe i tradycyjne systemy zarządzania trzeba będzie przecież wtedy poddawać w jakiś sposób mapowaniu. Zresztą użytkownicy mają już w tej dziedzinie przykre doświadczenia, gdy technologie zaproponowane przez DMTF starano się wdrożyć w środowiskach opartych na standardzie SNMP.

Obecnie na rynek trafia wiele urządzeń obsługiwanych przez systemy zarządzania oparte na technologii WWW. Większość z nich jest również w stanie pracować w standardzie SNMP. Technologia zarządzania sieciami komputerowymi związana z WWW będzie się ciągle, chociaż powoli rozwijać. Proces ten można przyśpieszyć, jeśli tylko producenci tego rodzaju aplikacji skoncentrują się na wdrażaniu technologii WWW do interpretowania i prezentowania danych, a nie będą próbować przebudowywać całego instrumentarium systemu zarządzania czy zmieniać zasad pracy modułów odpowiedzialnych za transfer danych na linii system zarządzania - agent.

Trzeba sobie uświadomić, że w przypadku aplikacji zarządzających systemami i sieciami komputerowymi nie ma żadnego cudownego rozwiązania. Dlatego nie należy pochopnie rezygnować z eksploatowanych już systemów zarządzania, ale powoli wdrażać rzeczywiście sprawdzone produkty, mogące funkcjonować równolegle z używanym już systemem. Kluczem do sukcesu może być połączenie starej i nowej technologii, tak aby określone zadania realizowane przez system zarządzania były wykonywane przez właściwe narzędzie.

9. Podsumowanie

Protokoły zarządzania siecią umożliwiają administratorowi nadzór i sterowanie pracą routerów i komputerów. Program-klient do zarządzania siecią, który pracuje na komputerze administratora, kontaktuje się z jednym lub wieloma serwerami (nazywanymi agentami) działającymi na zarządzanych komputerach. Intersieć składa się z komputerów i sieci różnych typów, oprogramowanie zarządzania intersieciami TCP/IP jest więc programem użytkowym, który używa protokołów transportowych intersieci np. UDP w celu zapewnienia komunikacji pomiędzy klientem i serwerami.

Standardowym protokołem zarządzania sieciami TCP/IP jest SNMP. Jest to protokół niskiego poziomu, który zapewnia dwie podstawowe operacje: odczytanie wartości zmiennej i ustawienie wartości zmiennej. Wszystkie operacje są następstwem zmiany wartości zmiennych. SNMP określa format komunikatów, które są przesyłane pomiędzy komputerem administratora i zarządzanym przezeń urządzeniem.

Ze standardem SNMP jest związany standard określający zbiór zmiennych, które muszą być dostępne na zarządzanym urządzeniu. Standard ten jest znany jako MIB. Zmienne MIB są zdefiniowane przy użyciu ASN.1, formalnej notacji zapewniającej możliwość zwięzłego kodowania nazw, czytelnej dla człowieka, będącej jednocześnie ścisłą notacją dla nazw i obiektów. ASN.1 używa hierarchicznej przestrzeni nazw, aby zapewnić globalną jednoznaczność nazw MIB, umożliwiając jednocześnie grupom niezależne od innych przydzielanie nazw z różnych części przestrzeni nazw.

Ciąg dalszy w przygotowaniu

Analiza standardów zarządzania sieciami i zasobami sieciowymi

2

internet

1

mgmt

2

directory

1

experi-

mental

3

6

private

4

mib

1

ip

4

addr.

trans.

3

inter-

face

2

icmp

5

tcp

6

system

1

udp

7

egp

8

---