POLITECHNIKA ŁÓDZKA Wydział Elektrotechniki i Elektroniki

Wielkość: px
Rozpocząć pokaz od strony:

Download "POLITECHNIKA ŁÓDZKA Wydział Elektrotechniki i Elektroniki"

Transkrypt

1 POLITECHNIKA ŁÓDZKA Wydział Elektrotechniki i Elektroniki Praca dyplomowa magisterska Bartłomiej Jóźwiak Nr albumu: Promotor: prof. dr hab. inż. Dominik Sankowski Konsultant: mgr inż. Łukasz Sturgulewski

2 Moim rodzicom...

3 Pragnę gorąco podziękować Panu promotorowi prof. dr hab. inż. Dominikowi Sankowskiemu za życzliwość i serdeczność. Pragnę również w szczególny sposób podziękować Panu mgr inż. Łukaszowi Sturgulewskiemu za poświęcony mi czas i wszystkie wskazówki metodyczne i rzeczowe.

4 Spis treści Cel i zakres pracy Wstęp Podstawowe informacje na temat rodziny protokołów TCP/IP Krótki rys historyczny Warstwowy model architektury TCP/IP Protokół UDP Podstawy monitorowania i zarządzania sieciami komputerowymi Protokół SNMP Podstawowe informacje na temat protokołu SNMP SNMP v Struktura Informacji Zarządzania SNMP v SNMP v Struktura Informacji Zarządzania SNMP v SNMP v MIB Abstrakcyjna Notacja Składniowa 1 (ASN.1) Podstawowe zasady kodowania (BER) Routery Routery CISCO Konfiguracja SNMP na routerach Cisco Projekt - Implementacja protokołu SNMPv Założenia projektowe Opis projektu Testy akceptacyjne Podsumowanie Projekt - Wizualne przedstawienie danych odczytywanych z routera Cisco Założenia projektowe Opis projektu Testy akceptacyjne Rozwiązania praktyczne Topologia sieci wykorzystanej w badaniach Wstępne testy

5 9.3 Pomiar obciążenia routera Podsumowanie Wykaz skrótów stosowanych w pracy Spis ilustracji Spis tabel Spis listing ów Bibliografia

6 Cel i zakres pracy Głównym przedmiotem rozważań niniejszej pracy magisterskiej jest budowa narzędzia umożliwiającego monitorowanie urządzeń sieciowych z wykorzystaniem protokołu SNMP, implementującego moduły notacji składniowej ASN.1 oraz kodowania BER. Dzięki tej aplikacji możliwym jest graficzne przedstawienie dowolnych informacji dostarczonych przez protokół SNMP (Simple Network Management Protocol). Do zbudowania takiego narzędzia niezbędna była implementacja samego protokołu SNMPv1. Dodatkowo powstała pomocnicza aplikacja pozwalająca na dokładną analizę wiadomości SNMP. Aplikacje te zostały wykorzystane do badań, których celem było pokazanie uniwersalności samego protokołu, jak również wykazanie małego stopnia zużycia zasobów router a. Praca składa się z dziewięciu rozdziałów. Rozdział 2 krótko opisuje historię Internetu oraz omawia sam model architektury TCP/IP, ze szczególnym uwzględnieniem protokołu UDP, który SNMP używa jako protokółu transportowego. Rozdział 3 zawiera wprowadzenie do tematyki monitorowania oraz zarządzania sieciami komputerowymi, omawiając teoretyczne zagadnienia związane z nimi, zwracając szczególną uwagę na na trudności, mogące wystąpić podczas obserwacji oraz podając praktyczne rozwiązania tych problemów. Dodatkowo rozdział ten dostarcza cennych wskazówek pozwalających lepiej zrozumieć intencje twórców protokołu SNMP, jak i same jego założenia. Rozdział 4 opisuje istniejące trzy wersje protokołu SNMP. Znaleźć można nim ogólny opis samego protokołu i jego założeń, jak również szczegóły budowy samej wiadomości. Dodatkowo jedna z części rozdziału opisuje Bazę Informacji Zarządzania, tzw. MIB (Management Information Base). Notację składniową ASN.1 (Abstract Syntax Notation One) opisano w rozdziale 5. Notacja ta jest wykorzystywana do opisu wiadomości (struktur danych), wymienianych pomiędzy różnego rodzaju aplikacjami, na wysokim poziomie abstrakcji, uniezależniając tak zdefiniowaną wiadomość od jakiejkolwiek platformy sprzętowej oraz języka programowania. Ponieważ aplikacjami wykorzystującymi ASN.1 mogą być zarówno dowolne programy, jak również Internet, sieci inteligentne, sieci komórkowe, interaktywna telewizja, etc., notacja ta jest krytyczną częścią naszego życia, jest wszechobecna, a jednocześnie działa tak dobrze, że jest niezauważalna. SNMP również wykorzystuje ASN.1 do opisu własnych struktur danych. Dodatkowo rozdział ten zawiera opis podstawowych zasad kodowania BER (Basic Encoding Rules) używanych do - 6 -

7 przesyłania danych zdefiniowanych za pomocą ASN.1 pomiędzy dwiema jednostkami. Rozdział 6 to zwięzły opis samych routerów Cisco oraz sposobów konfiguracji SNMP na nich. Rozdział 7 stanowi wyczerpujący opis samej implementacji SNMPv1 oraz aplikacji pomocniczej wykorzystywanej w dokładnym analizowaniu wiadomości SNMP. Program służący do graficznego wyświetlania danych otrzymanych za pomocą SNMP został omówiony w rozdziale 8, który opisuje również konfigurację aplikacji. Oba programy zostały wykorzystane do przeprowadzenia badań opisanych w rozdziale

8 1 Wstęp Żyjemy w czasach bardzo szybkiego rozwoju nowoczesnych technologii, w tym także technologii sieciowych. Pozwalają one na wymianę danych liczonych w gigabajtach (GB) i terabajtach (TB), pomiędzy niezliczoną ilością komputerów na całym świecie. Dzięki wykładniczej ekspansji Internetu przez ostatnie 30 lat, czasy w których dostęp do niego był ograniczony do instytucji rządowych, wojska i uczelni, minęły. Powstały i powstają nowoczesne technologie takie jak Web Services, DCOM, CORBA, itp., oparte na sieciach komputerowych. Oprócz zaawansowych technologii również każdy z nas może codziennie korzystać z dobrodziejstw, jakie oferuje nam Internet, np. elektroniczne zakupy (ang. e- shopping), elektroniczna bankowość (ang. e-banking), elektroniczne zdalne nauczanie (ang. e-learning), telewizja przez Internet (ang. Internet Protocol Television, IPTV) czy coraz popularniejsza telefonia przez Internet (ang. Voice over Internet Protocol, VoIP). Co więcej, rozwój, a nawet funkcjonowanie współczesnej organizacji wydaje się nie możliwy bez własnej korporacyjnej sieci komputerowej z dostępem do Internetu. Jednakże wszystkie te systemy oraz sieci komputerowe wymagają stałego monitoringu, nadzorującego poprawność działania poszczególnych komponentów. Oczywiste jest stwierdzenie, że człowiek (administrator) nie jest w stanie sprawnie zarządzać elementami sieciowymi, ze względu na złożoność struktur sieciowych. A zatem, konieczne i celowe jest zastosowanie zautomatyzowanych narzędzi administracyjno-monitorujących. Główne wymagania stawiane przed tymi narzędziami to unifikacja (normalizacja) protokołów i formatów przez nie obsługiwanych oraz efektywne wykorzystywanie zasobów (minimalne obciążenie sieci przy maksymalnej liczbie monitorowanych urządzeń). Rozwiązanie powyższych problemów oferuje protokół SNMP (ang. Simple Network Managment Protocol), łączący w sobie prostotę (łatwość implementacji) z dużą elastycznością (zunifikowany sposób kodowania typów danych, tworzenie struktur informacji, skalowalność) oraz wydajnością

9 2 Podstawowe informacje na temat rodziny protokołów TCP/IP 2.1 Krótki rys historyczny Początki Internetu sięgają lat 60-tych. W Departamencie Obrony Stanów Zjednoczonych (DoD - Department of Defense) prowadzone były wówczas badania zakrojone na szeroką skalę, mające na celu opracowanie systemu komunikacji, dzięki któremu możliwa byłaby wymiana informacji oraz danych na potrzeby wojska, jak również uniwersytetów stanowych. Kamieniem milowym w tych pracach stała się praca Leonard a Kleinrock a opisująca podstawy technologii komutacji pakietów. Efektem prac stała się sieć nazwana ARPANET (Advanced Research Projects Agency Network). Pierwsza wiadomość została przesłana z Uniwersytetu Kalifornijskiego w Los Angeles (UCLA, komputer Honeywell DDP 516) do Instytutu Badawczego Stanforda (SRI, komputer SDS-940 computer). Wkrótce kolejne dwa uniwersytety dołączyły do ARPANET u : Uniwersytet w Santa Barbara (komputer IBM 360/75) oraz Uniwersytet Stanu Utah (komputer DEC PDP-10) [14] [16]. Rysunek 1. Szkic pierwszego połączenia dwóch hostów w sieci ARPANET [15] - 9 -

10 Rysunek 2. Szkic powstającej sieci ARPANET [15] W roku 1971 w skład sieci wchodziło już około 30 uniwersytetów [14]. Rysunek 3. Szkic możliwej topologii ARPANET, zrobiony pod koniec lat 60-tych przez L. Roberts a [15] Pierwotna sieć ARPANET wykorzystywała protokół sterowania siecią NCP (Network Control Protocol), który umożliwiał między innymi przesyłanie plików, logowanie się na zdalnej maszynie oraz drukowanie. W roku 1983 militarna część ARPANET została wydzielona jako MILNET (Military Network), a sam ARPANET zaczął ustępować miejsca Internetowi, aby w roku 1990 oficjalnie zakończyć swą działalność. 2.2 Warstwowy model architektury TCP/IP W teorii sieci bardzo ważne miejsce zajmuje tzw. warstwowy model sieci. Najczęściej opisuje się go korzystając z mającej raczej teoretyczne znaczenie architektury ISO OSI, która wyróżnia 7 warstw. Każda warstwa stanowi zbiór oprogramowania, realizującego pewną funkcjonalność przypisaną do danej warstwy, dostarcza usług warstwie wyższej oraz może korzystać z usług warstwy niższej. Takie podejście jest bardziej elastyczne i łatwiejsze do rozbudowy [19]

11 Również w samym protokole TCP/IP można wyróżnić cztery warstwy przedstawione na Rysunku 4. Warstwa prezentacji Warstwa transportowa Warstwa Internet Warstwa dostępu do sieci Sprzętu 7 Warstwa 6 Warstwa 5 Warstwa 4 Warstwa 3 Warstwa 2 Warstwa 1 Warstwa aplikacji prezentacji sesji transportowa sieci łącza danych fizyczna Rysunek 4. Model warstwowy TCP/IP Na rysunku umieszczony również został referencyjny model OSI w celu odniesienia architektury TCP/IP do niego. Warstwa dostępu do sieci (Network Interface Layer) odpowiada za dostarczanie danych do innych urządzeń bezpośrednio dołączonych do sieci. Nazywana jest także warstwą host-do-sieci. Współpracuje ona bezpośrednio ze sprzętem oraz sterownikami odpowiedzialnymi za współpracę z siecią (PPP, SLIP, Token-Ring, Ethernet). Warstwa ta współpracując z interfejsem sieciowym (kartą sieciową, modemem lub innym urządzeniem) separuje wyższe warstwy od zastowanych rozwiązań fizycznych, zajmując się wszystkimi aspektami potrzebnymi, by pakiet protokołu IP mógł przejść łączem fizycznym z jednego urządzenia do drugiego [7][20]

12 Warstwa Internet (Internet Layer) odpowiedzialna jest za wysyłanie pakietów źródłowych z dowolnej sieci w sieci rozległej i dostarczanie ich do miejsca przeznaczenia, niezależnie od ścieżek oraz napotkanych po drodze sieci. Protokołem zarządzającym tą warstwą jest protokół IP (Internet Protocol). Wybór najlepszej ścieżki oraz komutacja pakietów następuje właściwie w tej warstwie. Korzysta ona z usług warstwy dostępu do sieci, zaś sama świadczy usługi dostarczania pakietu do dowolnego hosta w Internecie. Protokół IP jest zawodny, gdyż nie zapewnia dostarczenia pakietu do adresata. Nie ma żadnych potwierdzeń ani retransmisji, nie ma również gwarancji dostarczenia pakietów w odpowiedniej kolejności. Dzięki temu implementacja protokołu jest prosta, a niezawodnością dostarczania danych zajmuje się warstwa transportowa. Z warstwą tą związane są również adresy IP. Każdy host podłączony do sieci TCP/IP musi posiadać taki adres, który jest unikalny w całej sieci. Adres IP składa się z 32 bitów (w wersji IP v.4) i najczęściej zapisywany jest w postaci tekstowej w formacie zapisu dziesiętnego kropkami, jak pokazano ponizej: Adres ten oprócz identyfikacji samego hosta, niesie również informacje na temat sieci, do której dane urządzenie jest podłączone. Szczegóły na temat adresowania IP można znaleźć w wielu publikacjach poświęconych tej tematyce. [7][20]. Warstwa transportowa (Transport Layer) odpowiedzialna jest za niezawodną wymianę danych w Inter-sieci oraz kontrolę przepływu. Organizuje też i utrzymuje tzw. sesje, czyli wirtualne połączenia pomiędzy urządzeniami sieciowymi. Warstwa ta czasem nazywana jest warstwą host-to-host. W skład tej warstwy wchodzą dwa protokoły: TCP (Transport Control Protocol) oraz UDP (User Datagram Protocol). Protokół TCP pracuje w trybie połączeniowym oraz zapewnia niezawodność. Protokół UDP jest dużo prostszy od TCP, nie zapewnia on niezawodności oraz pracuje w trybie bezpołączeniowym. Ponieważ wykorzystywany jest przez SNMP, zostanie omówiony bardziej szczegółowo w rozdziale 3.3, który jest poświecony temu protokołowi.. Warstwa aplikacji obsługuje protokoły wyższego poziomu, aspekty prezentacji oraz kodowanie

13 Schemat przedstawiony na Rysunku 5 nazywany graficznym schematem protokołu TCP/IP ilustruje w sposób bardziej praktyczny opisane wyżej warstwy. HTTP FTP SMTP DNS SNMP TCP UDP IP LAN WAN INNE Rysunek 5. Graficzny schemat TCP/IP Oczywiście nie zawiera on wszystkich możliwych aplikacji opartych o TCP/IP, lecz tylko te najważniejsze. 2.3 Protokół UDP Jak wspomniano już wyżej, protokół UDP należy do rodziny TCP/IP. Zdefiniowany został w RFC 768 i wykorzystuje bezpołączeniowy tryb pracy, nie gwarantując przy tym dostarczenia, zachowania kolejności oraz zabezpieczenia przed powielaniem pakietów. Umożliwia proste wysyłanie komunikatu i jest preferowanym protokołem transportowym dla SNMP [1][2][RFC 768]. Nagłówek UDP jest prosty, zawiera jedynie kilka pól (Rysunek 6) przedtawionych poniżej:

14 Źródłowy port Długość Docelowy port Suma kontrolna Dane (oktety) Rysunek 6. Nagłowek UDP Port źródłowy (source port) jest polem opcjonalnym, wskazującym na port procesu wysyłającego. Port ten może być użyty np. do odpowiedzi. Jeśli nie jest używane, powinno być wypełnione zerami, Port docelowy (destination port) zawiera numer portu docelowego, Długość (length) jest długością datagramu wyrażoną w oktetach, zawierająca zarówno nagłówek jak i dane użytkownika, Pole sumy kontrolnej (checksum), 2 oktety, jest używane w celu wykrycia przekłamań występujących w trakcie transmisji. W przypadku stwierdzenia niepoprawnej wartości sumy kontrolnej, pakiet jest odrzucany i nie następuje retransmisja. Dzięki swojej prostocie protokół ten jest bardzo wydajny i szybki. UDP nie traci czasu na nawiązanie i utrzymywanie połączenia oraz na retransmisję pakietów. Dlatego też jest wykorzystywany przez aplikacje, którym: zależy na czasie, mogą zgubić kilka pakietów, stosują mechanizm pytanie odpowiedź. Sam protokół SNMP (jak wspomniano wyżej) używa UDP do wysyłania oraz odbierania komunikatów. Domyślnymi portami są: 161 wykorzystywany przez agenty SNMP, 162 używany przez menadżera (trap)

15 3 Podstawy monitorowania i zarządzania sieciami komputerowymi Przed przystąpieniem do omawiania samego protokołu SNMP należy najpierw zapoznać się z ogólnymi pojęciami dotyczącymi zarządzania sieciami. W codziennym życiu (niesieciowych środowiskach) mamy do czynienia z bardzo złożonymi systemami, które składają się z dużej ilości komponentów wzajemnie ze sobą powiązanych i oddziałujących na siebie. Wszystkie te komponenty (oraz systemy) muszą być w większym, bądź mniejszym stopniu monitorowane, zarządzane i kontrolowane przez administratora (w generalnym tego słowa pojęciu). Dla przykładu rozważmy samochód. Administratorem tego systemu jest kierowca, który na desce rozdzielczej widzi mnóstwo wskaźników, kontrolek, przełączników (obrotomierz, prędkościomierz, wskaźnik ciśnienia oleju, wskaźnik ilości paliwa, kontrolki zapalonych świateł) etc. Te wszystkie urządzenia pozwalają kierowcy kontrolować kierowany pojazd i informować o ewentualnych zagrożeniach lub problemach (np. brak paliwa). Podsumowując, kierowca monitorując stan odległych urządzeń (silnik, zbiornik paliwa) i analizując ich stan może stwierdzić, że działają one oraz że zakres ich pracy mieści się w ustalonych granicach. Może natychmiastowo kontrolować i regulować ich wartość po otrzymaniu notyfikacji o zmianach w kierowanym pojeździe (zmiana biegu, kiedy obroty silnika wykraczają poza górną/dolną granicę) oraz aktywnie zarządzać całym pojazdem, wykrywając trendy oraz anormalne zachowania, zapobiegając wystąpieniu poważnych awarii lub usterek (brak paliwa, małe ciśnienie powietrza w oponach). Podobnie dzieje się w przypadku sieci komputerowych. Administrator w sposób aktywny monitoruje, kontroluje oraz zarządza administrowaną siecią. Rozważmy prostą sieć przedstawioną na Rysunku 7 poniżej

16 Rysunek 7. Przykładowy schemat sieci Rysunek 7 przedstawia prostą sieć zawierającą 3 routery, kilkanaście hostów oraz serwerów. Pomimo tak prostej struktury przedstawionej sieci, można rozpatrzyć wiele scenariuszy, w których narzędzia do zarządzania siecią znacznie ułatwią oraz zoptymalizują pracę administratora: wykrywanie intruzów; administrator może być notyfikowany o nadmiernym ruchu określonych typów pakietów (np. duża liczba SYN pakietów), który oznaczać może próbę ataku; wykrywanie częstych zmian tablic routingu; zachowanie takie może oznaczać niepoprawne skonfigurowanie tras routingu, bądź samego routera; wykrywanie uszkodzeń, któregoś z urządzeń sieciowych (np. karty sieciowej hosta, interfejsu routera); monitorowanie ruchu w sieci; administrator może monitorować np. określony typ pakietów, sprawdzać czy któreś z łączy nie jest przeciążone etc. Zarządzanie sieciami komputerowymi obejmuje zatem wiele aspektów. Dlatego też Międzynarodowa Organizacja Standaryzacyjna ISO zdefiniowała pięć kluczowych

17 obszarów zarządzania siecią, które zostały powszechnie zaakceptowane przez producentów systemów zarządzania siecią: Zarządzanie wydajnością (Performance management); Zarządzanie w sytuacjach awaryjnych (Fault management); Zarządzenie konfiguracją i nazwami (Configuration and name management); Zarządzanie wykorzystaniem zasobów (Accounting management); Zarządzanie bezpieczeństwem (Security management); Pojęcia te zostaną bliżej omówione w dalszej części niniejszego opracowania. W roku 1996 Saydam i Magedanz zaproponowali następującą definicję zarządzania siecią: Network management includes the deployment, integration and coordination of the hardware, software, and human elements to monitor, test, poll, configure, analyze, evaluate and control the network and element resources to meet the realtime, operational performance, and Quality of Service requirements at a reasonable cost. [18] Zarządzanie siecią nie jest więc zadaniem łatwym. Integruje ono ze sobą wiele zasobów w celu uzyskania określonych wyników, analiz, testów, przy ograniczonych zasobach czasowych, finansowych oraz obliczeniowych. Systemy zarządzania są złożoną strukturą (najczęściej zbiorem narzędzi), wykorzystywaną w monitoringu oraz sterowaniu zasobami sieciowymi, zbudowaną w taki sposób, aby potrzebny był minimalny narzut dodatkowego sprzętu i oprogramowania (w większości wykorzystywane są już zasoby wbudowane w istniejący sprzęt) oraz udostępniała spójny interfejs dla operatora, który umożliwi wykonanie większości lub wszystkich zadań związanych z zarządzaniem siecią. Dodatkowo system taki powinien udostępniać możliwość podglądu sieci jako ujednoliconej architektury z przypisanymi nazwami lub adresami dla każdego monitorowanego obiektu [1]. Ogólna architektura systemu zarządzania siecią przedstawiona jest na Rysunku

18 Rysunek 8. Struktura systemu zarządzania siecią Każdy węzeł sieci oprócz odpowiednich elementów sprzętowych zawiera także następujące oprogramowanie: System operacyjny (OS) Oprogramowanie komunikacyjne (ComSoft) zawierające np. implementację stosu TCP/IP Dodatkowe aplikacje (App) Jednostkę zarządzania siecią (NME) network management entity Aplikacje zarządzania siecią (NMA) network management aplication Dwie ostatnie pozycje (tj. NME i NMA) uczestniczą w zarządzaniu siecią. Do zadań MNE należą: gromadzenie danych statystycznych o aktywności komunikacyjnej i innej związanej z działaniem sieci, przechowywanie lokalnie zgromadzonych danych statystycznych, odpowiadanie na polecenia z centrum zarządzania siecią (przesyłanie danych, zmiana parametrów, etc.),

19 wysyłanie do centrum sterowania siecią informacji na temat lokalnych zmian warunków w sieci. Każdy monitorowany obiekt jest wyposażony w jednostkę NME, nazywaną również modułem agenta lub krótko agentem. Oprócz obiektów monitorowanych w sieci, musi być wyodrębniona chociaż jedna jednostka, pełniąca rolę nadzorczą w sieci, tzw. zarządca. Każdy taki host zawiera dodatkowo oprogramowanie zwane aplikacją zarządzania siecią, oznaczoną na rysunku jako NMA. Głównymi zadaniami NMA są: udostępnianie interfejsu dla upoważnionych użytkowników, pozwalającego na zarządzanie siecią, wysyłanie oraz odbieranie komunikatów przychodzących od agentów, wyświetlanie różnego rodzaju informacji związanych z zarządzaniem siecią, wysyłanie rozkazów do agentów. Zarządca ma możliwość komunikacji oraz kontroli agentów, również w innych systemach. Rzadko stosuje się tylko jednego hosta, który pełni rolę zarządcy. W rzeczywistych rozwiązaniach przeważnie są dwie lub więcej takich jednostek. Dzięki temu, zapewniony jest stały dostęp do funkcji zarządczych. Redundantni zarządcy, w sytuacji normalnej pracy najczęściej zbierają tylko informacje (Rysunek 9). Rysunek 9. Schemat rozproszonego systemu zarządzania

20 Oprogramowanie do zarządzania siecią działa zawsze w określonym systemie operacyjnym i przy określonej architekturze komunikacyjnej [1]. Jednak w rzeczywistych rozwiązaniach rzadko spotykana jest taka konfiguracja. Może się okazać na przykład, że cześć hostów w sieci posiada starsze lub niekompletne oprogramowanie MNE lub w ogóle go nie posiada (modemy, multipleksery). W takich sytuacjach wykorzystuje się pełnomocników (Proxy). Pełnomocnikiem jest agent wybrany w celu reprezentowania jednego lub kilku węzłów. Za każdym razem kiedy zarządca próbuje uzyskać informacje od węzła sieci, który nie spełnia w/w założenia, komunikacja następuje poprzez agenta Proxy związanego z danym węzłem. Agent dokonuje potrzebnych przekształceń informacji uzyskanej od zarządcy, a następnie tak przygotowane żądanie wysyła do docelowego odbiorcy. Oczywiście odpowiedzi pochodzące od systemu docelowego, a skierowane do zarządcy, są również wysyłane za pośrednictwem agenta z uprzednim tłumaczeniem z jednego systemu na drugi (Rysunek 10). Rysunek 10. Architektura zarządcy-pełnomocnika Monitorowanie sieci zajmuje się obserwowaniem i analizowaniem zarządzanej sieci. Główne obszary monitorowania przedstawia Rysunek 11 [1]. Obszary monitorowania Dostęp do monitorowanych informacji Projektowanie mechanizmów Zastosowania zebranych informacji Rysunek 11. Obszary monitorowania sieci

21 Aby móc monitorować sieć trzeba najpierw wiedzieć, jaki konkretnie parametr będzie monitorowany (trzeba go zdefiniować), a później pobrać tę informacje i przesłać do zarządcy. Tym właśnie zajmuje się pierwszy z obszarów monitorowania dostęp do informacji. Monitorowane informacje można podzielić na: statyczne zmieniające się sporadycznie charakteryzują aktualną konfigurację (np. nazwa routera, liczba jego portów), dynamiczne zmieniające się podczas pracy sieci (np. liczba wysłanych pakietów), statystyczne wyliczone na podstawie zebranych informacji (np. średnie ilości pakietów). Podział ten pociąga za sobą sposób zbierania i przechowywania danych, które będą wykorzystane w celach nadzorczych. Statyczną informację generuje zazwyczaj element z nią powiązany i jest ona bezpośrednio dostępna dla nadzorcy (chyba, że dany element nie posiada oprogramowania agenta, wtedy udostępniana jest poprzez pełnomocnika). Podobnie dynamiczna informacja jest przechowywana i zbierana przez element sieci, który ją wygenerował. Dodatkowo, jeżeli dany system jest podłączony bezpośrednio do sieci LAN, wówczas większość jego działalności może być obserwowana przez inny system w tej sieci, zwany dalej zdalnym nadzorcą. Termin ten oznacza urządzenie w sieci LAN, obserwujące cały ruch w tej sieci oraz gromadzące informacje o tym ruchu. Należy jednak zaznaczyć, że nie każda informacja może być zebrana przez zdalnego nadzorcę (np. liczba połączeń warstwy sieci). Ostatnia grupa informacje statystyczne może być generowana przez każdy system posiadający stosowny dostęp do odpowiednich informacji dynamicznych. Ważnym czynnikiem w monitorowaniu sieci jest sposób, w jaki uzyskuje się niezbędne informacje (obszar projektowania mechanizmów). Obecnie wykorzystywane są dwie metody: odpytywanie (polling), raportowanie zdarzeń (event raporting). W metodzie odpytywania wykorzystywany jest prosty mechanizm typu pytanie odpowiedź. Zarządca wysyła zapytanie do agenta, a agent odpowiada informacją pobraną z własnej bazy przechowującej zarządzane informacje. Prośba (request) zarządcy może zawierać pytanie odnośnie wartości jednej lub kilku zmiennych. Może to być również pytanie o charakterze wyszukiwawczym, proszące agenta o informacje spełniające określone kryteria. Zarządca może użyć odpytywania w celu:

22 rozpoznania konfiguracji sieci, generowania raportów na żądanie użytkownika, udzielenia odpowiedzi użytkownikowi, dokładnego zbadania warunków panujących w sieci po otrzymaniu notyfikacji. W przypadku drugiej metody raportowania zdarzeń to agent wysyła komunikat do nasłuchującego zarządcy. Generowane raporty mogą mieć charakter regularnie wysyłanych notyfikacji lub powstawać w sytuacjach ważnych, bądź niezwyczajnych zdarzeń (zmiana stanu, awaria etc.). Należy podkreślić, że w przypadku obiektów których stan zmienia się bardzo rzadko, metoda raportowania jest wydajniejsza od tworzenia zapytań. Wybór konkretnej metody zależy od wielu czynników, między innymi od: rodzaju stosowanych aplikacji kontrolujących sieć, obciążenia sieci spowodowanego dodatkowym ruchem wywołanym przez każdą z metod, opóźnień czasowych podczas powiadamiania, odporności w sytuacjach krytycznych, działań w stanach uszkodzeń. Pięć kluczowych obszarów zarządzania siecią, wymienionych w początkowej części tego rozdziału, można podzielić na dwie grupy, związane z monitorowaniem sieci: Zarządzanie wydajnością, Zarządzanie w sytuacjach awaryjnych, Zarządzanie wykorzystaniem zasobów oraz sterowaniem siecią: Zarządzanie bezpieczeństwem, Zarządzenie konfiguracją i nazwami. W niniejszym opracowaniu zostaną one omówione ogólnie. Szczegółowy opis można znaleźć w publikacjach: [1][2][dokumenty RFC]. Jednym z ważniejszych parametrów opisujących sieć jest jej wydajność. Monitorowanie wydajności jest absolutnie podstawowym warunkiem w zarządzaniu siecią, bez niego nie sposób jest zarządzać oraz nadzorować żadnego systemu. Do pomiaru wydajności używa się wielu wskaźników. Poniżej przedstawiono najważniejsze z nich

23 Wskaźniki wydajności Zorientowane na usługi Dostępność Czas odpowiedzi Zorientowane na wydajność Przepustowość Wykorzystanie Dokładność Rysunek 12. Wskaźniki wydajności Należy wyraźnie zaznaczyć, że do efektywnego monitorowania należy użyć właściwych oraz najbardziej miarodajnych wskaźników dla danej konfiguracji. Wybór ich jest sprawą bardzo trudną i wymaga sporego doświadczenia. Wskaźniki zorientowane na usługi mają zawsze najwyższy priorytet i służą do oceniania czy dane usługi są na poziomie satysfakcjonującym użytkowników. Natomiast pomiary zorientowane na wydajność służą do oceny kosztów. Dostępność (Availability) określa ilość czasu, przez jaki dany system, komponent lub aplikacja była udostępniona użytkownikowi i przeważnie wyrażona jest w procentach. Dostępność oparta jest na niezawodności poszczególnych komponentów sieci. Niezawodność to prawdopodobieństwo, że dany komponent będzie wykonywał swoją funkcję w danym czasie, w określonych warunkach [1]. Najczęściej jako miary awaryjności używa się średniego czasu między uszkodzeniami MTBF (Mean Time Between Failures). Dlatego też, dostępność może być wyrażona wzorem: MTBF A = MTBF + MTTR gdzie A oznacza dostępność, a MTTR to średni czas naprawy (Mean Time to Repair). Dodatkowo w celu podwyższenia niezawodności danego systemu (a co za tym idzie dostępności) stosuje się nadmiarowe elementy. Czas odpowiedzi (Response Time) to czas, po jakim system odpowiada na żądanie wykonania określonego zadania. Dąży się do tego, aby wartość tego parametru była możliwie najmniejsza. Niestety krótszy czas odpowiedzi pociąga za sobą większe koszty. Szczegółowy opis znajduje się w [1]

24 Dokładność (Accurancy) określa ilość czasu, w którym dane przesłane pomiędzy dowolnymi punktami w sieci były poprawne i nie zawierały błędów. Ponieważ współczesne protokoły transportowe mają wbudowane mechanizmy korekcji błędów, wskaźnik ten nie jest tak istotny dla użytkownika. Nie mniej jednak warto jest monitorować ilość błędów, gdyż mogą one świadczyć o niepoprawnym działaniu sieci, uszkodzeniach linii, istnieniu źródeł szumów lub interferencji, które należy wyeliminować. Przepustowość (Throughput) jest to częstość występowania zdarzeń powiązanych z aplikacją[1]. Wykorzystanie (Utilization) to procent czasu, w jakim dany zasób jest wykorzystywany w przeciągu określonego przedziału [1]. Monitorowanie wydajności to nie tylko gromadzenie statystyk o ruchu. To także analiza wydajności, która wykorzystywana jest do przetwarzania i reprezentowania zebranych wyników pomiarów oraz sztuczne wytwarzanie ruchu, które pozwala obserwować sieć przy kontrolowanym obciążeniu. Najczęściej pomiary wydajności przeprowadzane są przez agentów, gdyż mają najlepsze warunki do zbierania szczegółowych informacji. Niestety, narzucają one konieczność wykorzystania części zasobów obliczeniowych danego węzła. Dlatego też niekiedy wykorzystuje się zdalnego nadzorcę, który obserwuje ruch w danej sieci (segmencie), zbierając większość potrzebnych informacji. Rozwiązanie takie przenosi większość obliczeń na dedykowany system, odciążając jednocześnie pozostałe węzły w sieci. Monitorowanie uszkodzeń ma na celu jak najszybsze wykrywanie oraz identyfikowanie przyczyn błędów, w celu określenia i podjęcia odpowiednich działań naprawczych [1]. Zagadnienia związane z tym obszarem zarządzania siecią nie są proste, wymagają sporej wiedzy oraz doświadczenia administratora tego systemu do izolowania, rozpoznania i naprawiania błędów. Nie wszystkie powstałe uszkodzenia mogą być obserwowane (deadlock), gdyż mogą być jedynie częściowo obserwowalne. Dodatkowe trudności wprowadza również niepewność samej obserwacji (np. trudno jest powiedzieć czy dany host w sieci uległ uszkodzeniu fizycznemu, czy po prostu zostało przerwane łącze komunikacyjne) oraz trudności w identyfikacji samego źródła błędów, szczególnie w bardzo złożonych systemach

25 Ważnym aspektem monitorowania uszkodzeń jest samo ich raportowanie. Jak wspomniano już wyżej istnieją dwie metody: przez odpytywanie; agent monitorujący trzyma lokalnie dziennik zdarzeń, który jest udostępniany uprawnionym nadzorcom na prośbę - jest to metoda niezalecana; przez samodzielne raportowanie; agent samodzielnie raportuje nadzorcę (ewentualnie grupę nadzorców) o powstałym błędzie; należy jednocześnie dobrać odpowiednie kryteria, aby nie spowodować nadmiernego obciążenia sieci. Dobry system monitoringu uszkodzeń powinien móc samodzielnie przewidzieć ewentualne problemy w sieci na podstawie wcześniejszych obserwacji i odpowiednio wcześniej podjąć stosowne działania. Monitorowanie wykorzystania zasobów (Accounting Monitoring) dotyczy głównie śledzenia sposobu wykorzystywania zasobów sieci przez użytkowników [1]. Kolejne dwa obszary dotyczą sterowania siecią. Samo sterowanie siecią dotyczy zmiany parametrów oraz wywołania działań w systemach końcowych, pośrednich oraz w podsieciach, które składają się na zarządzaną konfigurację [1]. Zarządzanie konfiguracją wiąże się z inicjowaniem, utrzymywaniem oraz zatrzymywaniem pojedynczych komponentów i podsystemów logicznych wewnątrz całkowitej konfiguracji zasobów komputerowych i komunikacyjnych danej instalacji [1]. Kontrola konfiguracji daje możliwość ustawienia początkowych (domyślnych) wartości parametrów urządzenia, dzięki czemu może ono zacząć pracę w pożądanym stanie oraz relacji między innymi komponentami danego systemu. Oczywiście zarządzanie konfiguracją powinno ściśle współpracować z innymi obszarami zarządzania siecią w celu dostosowywania ustawień do zmieniających się warunków, np. jeśli zostanie wykryte uszkodzenie (zarządzanie sytuacjami awaryjnymi), konfiguracja powinna zostać zmieniona tak, aby można było je wyeliminować. Poniżej przedstawiony został zestaw funkcji, które powinny wchodzić w skład zarządzania konfiguracją [1]: definiowanie informacji o konfiguracji, ustawianie i modyfikacja wartości atrybutów, definiowanie i modyfikacja powiązań, inicjalizacja i wstrzymywanie operacji sieciowych, rozpoznawanie oprogramowania, weryfikacja wartości i powiązań

26 tworzenie raportu o stanie konfiguracji. Ostatnim obszarem zdefiniowanym przez ISO jest zarządzanie bezpieczeństwem, które obecnie jest niezwykle ważnym elementem nie tylko w przypadku samego zarządzania, ale generalnie w wymianie informacji. Jest to niezwykle obszerna tematyka, mogąca stanowić podstawy do zupełnie odrębnego opracowania. Z punktu widzenia zarządzania bezpieczeństwem, wszystkie funkcje wchodzące w jego skład mogą zostać zgrupowane w trzech kategoriach [1]: utrzymywanie informacji dotyczących bezpieczeństwa, kontrolowanie usługi dostępu do zasobów, sterowanie procesem szyfrowania

27 4 Protokół SNMP 4.1 Podstawowe informacje na temat protokołu SNMP Kiedy projektowano protokół TCP/IP nie zwracano uwagi na zagadnienia związane z monitorowaniem i zarządzaniem siecią. Jedynym dostępnym narzędziem był protokół ICMP (Internet Control Message Protocol), umożliwiający wysyłanie prostych komunikatów kontrolnych. Najbardziej rozpowszechnionym programem, korzystającym z ICMP jest PING (Packet Internet Groper) służący m.in. do: sprawdzenia czy dane urządzenie sieciowe jest adresowalne, czy dany host działa, obserwowania opóźnień czasowych, zliczania ilości utraconych pakietów. Jednak w miarę rozbudowywania protokołu TCP/IP oraz rozrastania się samego Internetu, ten prosty mechanizm okazał się niewystarczający. Dlatego też zaczęto opracowywać nowe protokoły i narzędzia służące do zarządzania siecią, takie jak: SGMP (Simple Gateway Monitoring Protocol), zapewniający prosty sposób monitorowania bramek, HEMS (High-Level Entity Management Protocol), CMOT. Początkowo SNMP powstało jako krótkoterminowe rozwiązanie, pozwalające na dokończenie prac nad protokołem CMOT. Dzięki swojej prostocie, protokół ten nie powodował niepotrzebnego obciążenia systemów końcowych. Dodatkowo, początkowe założenia zakładały, że zarówno SNMP jak i CMOT będą wykorzystywały wspólną bazę danych zarządzanych obiektów, co miało umożliwić późniejsze, łatwiejsze przejście z jednego systemu na drugi. Rzeczywistość jednak zweryfikowała te początkowe ustalenia, powodując odstąpienie od wspólnej hierarchii zarządzanych obiektów oraz pozwalając jednocześnie na równoległy i niezależny rozwój nad tymi dwoma systemami. Dzięki tej decyzji nastąpił gwałtowny rozwój SNMP. Obecnie protokół SNMP jest powszechnie dostępny i jest zaimplementowany niemal w każdym urządzeniu sieciowym. Dodatkowo powstały rozwinięcia samego protokołu, z których najważniejszym jest RMON (Remote Network Monitoring), służący do zdalnego monitorowania podsieci jako całości, a nie tylko pojedynczych hostów

28 Powstały również kolejne wersje samego protokołu: SNMPv2 oraz SNMPv3, które poprawiły niedoskonałości pierwotnej wersji SNMP. Sam termin SNMP określa cały zbiór specyfikacji, które dotyczą zagadnień związanych z zarządzaniem siecią, a nie tylko samego protokołu. Najbardziej podstawowymi specyfikacjami są: Struktura oraz identyfikacja informacji zarządzania w sieciach działających w oparciu o TCP/IP (Struture and Identification of Managment Information for TCP/IP-based Internets), zdefiniowana w dokumencie RFC 1155; dostarcza definicji dla struktur wykorzystywanych w zarządzaniu siecią; Baza informacji zarządzania, w zarządzaniu międzysieci działających w oparciu o TCP/IP: MIB II (Managment Information Base fot Network Managment for TCP/IP-based Internets), opisana w dokumencie RFC 1213; opisuje zarządzane obiekty zawarte w MIB; Prosty Protokół Zarządzania siecią Simple Network Managment Protocol, zdefiniowany w dokumencie RFC 1157; definiuje protokół, który używany jest do zarządzania obiektami opisanymi wyżej. 4.2 SNMP v1 Terminem SNMP v1 określa się pierwszą wersję tego protokołu. Jest to najbardziej popularna i jednocześnie najprostsza postać SNMP. Menedżer Komendy Agent MIB Odpowiedzi MIB Rysunek 13. Ogólny schemat wymiany komunikatów w SNMP SNMP bazuje na wymianie odpowiednich komunikatów pomiędzy menadżerem, a agentem, które umożliwiają odczytanie lub zmianę wartości zmiennych zapisanych

29 w bazie MIB (Rysunek 13). W dokumencie RFC 1157 (rodz. 4. Protocol Specification) zdefiniowano (przy pomocy ASN.1) strukturę komunikatu oraz pięć jednostek danych protokołu PDU (Protocol Data Units), które może zawierać komunikat SNMP. Dostępne jednostki PDU to: GetRequest ; jest wysyłana przez menadżera do agenta, w celu uzyskania wartości danej zmiennej (obiektu), bądź listy zmiennych; GetNextRequest; jest bardzo podobna do GetRequest z tą różnicą, że wynikiem tego zapytania jest wartość instancji obiektu następującej bezpośrednio za tą podaną w zapytaniu (zgodnie z porządkiem leksykograficznym); GetResponse; stanowi odpowiedź agenta na otrzymane zapytanie typu Get; SetRequest; jest używana do ustawiania wartości danego obiektu instancji w MIB; Trap (pułapka); jest wysyłana od agenta do menadżera, w celu powiadomienia o powstałym zdarzeniu, które uznawane jest jako ważne. Rysunek 14 przedstawia w sposób graficzny budowę komunikatu SNMP, natomiast poszczególne pola zostały omówione w Tabeli 1. version community GetRequest(0), GetNextRequest(1), SetRequest(3) PDU type (0,1,3) requestid 0 0 variablebindings PDU GetResponse PDU requestid type (2) errorstatus errorindex variablebindings Trap PDU type (4) enterprise agentaddr generictrap specifictrap timestamp variablebindings variablebindings name1 value1 name2 value2 namen valuen Rysunek 14. Budowa komunikatu SNMP

30 Nazwa pola Opis Version Wersja SNMP, dla SNMP v1 pole to przyjmuje wartość 0 Community Nazwa społeczności, używana do autoryzacji komunikatów SNMP PDU type Typ PDU, możliwe wartości: 0 GetRequest 1 GetNextRequest 2 GetResponse 3 SetRequest 4 Trap Request-id Identyfikator, który musi być unikalny, służy do identyfikacji wysyłanych zapytań; specyfikacja nie podaje sposobu wybierania wartości tego pola, można wybierać tę wartość w sposób np.: inkrementacyjny lub losowy. error-status Sygnalizuje rodzaj błędu, który wystąpił podczas przetwarzania zapytania; możliwe wartości: noerror (0) toobig (1) nosuchname (2) badvalue (3) readonly (4) generr (5) error-index Sygnalizuje, która zmienna z listy (variablebindings) spowodowała błąd Enterprise Typ obiektu generującego pułapkę agent-addr Adres IP obiektu, który wygenerował pułapkę Generic-trap Typ standardowej pułapki; możliwe wartości: coldstart (0) warmstart (1) linkdown (2) linkup (3) authenticationfailure (4) egpneighborloss (5) enterprisespecific (6) specific-trap Niestandardowy typ pułapki time-stamp Czas, który upłynął między ostatnią inicjalizację/reinicjalizacją danej jednostki, a wysłaniem pułapki. Variablebindings Lista zmiennych typu: nazwa zmiennej wartość. W przypadku wysyłania zapytania typu Get zaleca się ustawienie wartości na NULL namex Nazwa zmiennej valuex Wartość zmiennej Tabela 1. Opis pól komunikatu SNMP

31 Dzięki pięciu różnym rodzajom komunikatów, które oferuje SNMP protokół ten spełnia zarówno rolę monitorowania sieci jak i zarządzania nią. Standardowa sekwencja wymiany jednostek PDU pomiędzy zarządcą a agentem ilustruje Rysunek 15. Zarządca Agent Zarządca Agent GetRequest GetNextRequest GetResponse GetResponse Zarządca Agent Zarządca Agent SettRequest Trap GetResponse Rysunek 15. Schemat sekwencji PDU W rzeczywistości może się okazać, że któryś z komunikatów może zaginąć. Dzieje się tak, ponieważ SNMP używa bezpołączeniowego protokołu transmisji jakim jest UDP (porty 161 oraz 162). Protokół ten nie gwarantuje dostarczenia pakietów. Również w samym SNMP nie zdefiniowano żadnych procedur, które miałyby być podjęte na wypadek zagubienia komunikatu. Dlatego takie mechanizmy powinny zostać zaimplementowane w samej aplikacji np. poprzez wprowadzenie czasu oczekiwania na odpowiedź oraz retransmisji zapytania (Rysunek 16). Niestety rozwiązanie to nie może zostać zastosowane do komunikatów typu Trap, wysyłanych przez agenta. Jedynym rozsądnym rozwiązaniem jest zapewnienie periodycznych zapytań o najważniejsze parametry generowanych przez menadżera do podległych mu agentów

32 Zarządca Agent GetRequest X GetRequest GetResponse Rysunek 16. Zagubienie komunikatu SNMP SNMPv.1 zapewnia również bardzo proste mechanizmy bezpieczeństwa. Opierają się one na pojęciu społeczności SNMP (SNMP Community). Społeczność odzwierciedla relację pomiędzy agentem a grupą zarządców, która określa: metodę uwierzytelniania kontrolę dostępu pełnomocnictwo. Każda kombinacja pełnomocnictwa, metody uwierzytelniania oraz kontroli dostępu, która została zdefiniowana w agencie, muszą posiadać własną, unikalną nazwę społeczności, przekazywaną do zarządcy. Zarządca wykorzystuje tę nazwę podczas wysyłania komunikatów do agenta (Get oraz Set). Społeczności pełnią w SNMP rolę usługi uwierzytelniania (rolę hasła). Ponieważ jednak informacje przesyłane są jawnym tekstem, który nie stanowi dostatecznego zabezpieczenia, większość producentów sprzętu udostępnia jedynie funkcje monitoringu (Get, Trap) bez możliwości zarządzania (Set) danym urządzeniem. 4.3 Struktura Informacji Zarządzania SNMP v1 Struktura Informacji Zarządzania (SMI Structure of Managment Information) dla SNMPv1 została zdefiniowana w dokumencie RFC Opisuje ona ogólną strukturę definiowania i konstruowania baz MIB. Do formalnego zapisu struktur oraz innych definicji stosowana jest notacja ASN.1. SMI określa jakiego typu dane mogą być dostępne w bazie MIB oraz w jaki sposób są one reprezentowane i nazywane. Głównym zadaniem SMI jest utrzymanie jak największej prostoty oraz rozszerzalności MIB. W związku z tym jedynymi typami danych, które

33 przechowuje baza, są typy proste (wartości skalarne) oraz dwuwymiarowe tablice, z których można czytać jedynie pojedyncze wpisy (wielkości skalarne). Jak wspomniano wyżej, do definicji obiektów używa się formalnego języka ASN.1. Każdy typ posiada swoją nazwę, składnię oraz zasady kodowania tego obiektu. Nazwa służy do identyfikacji obiektu oraz określa związek z innymi obiektami w MIB. Kodowanie oznacza po prostu sposób reprezentacji danego typu obiektu podczas transmisji w sieci. Do tego celu wykorzystuje się BER. Składnia definiuje abstrakcyjną strukturę danych odpowiadającą danemu obiektowi. Generalnie dowolna konstrukcja ASN.1 może być użyta do określenia składni obiektu, jednak w przypadku SMI dla SNMP postawiono na prostotę, nakładając jednocześnie pewne restrykcje i definiując dostępne typy. W SNMPv1 można korzystać z typów: uniwersalnego, aplikacyjnego. Typ uniwersalny jest podzbiorem typów klasy UNIVERSAL dopuszczającym tylko: integer (UNIVERSAL 2); octetstring (UNIVERSAL 4); null (UNIVERSAL 5); object identifier (UNIVERSAL 6); notacji ASN.1, sequence, sequence-of (UNIVERSAL 16); Typ aplikacyjny (klasa APPLICATION notacji ASN.1) to taki, który definiuje aplikacja na własny użytek. W SNMPv1 zostały zdefiniowane następujące typy aplikacyjne: networkaddress typ umożliwiający wybór odpowiedniego formatu adresu sieciowego w zależności od użytego protokołu; obecnie możliwy jest tylko wybór adresu typu ipadddress; ipaddress 32-bitowy adres zgodny z formatem IP counter licznik, działa w zakresie <0,2 32-1>, wartość może być tylko zwiększana; w przypadku przepełnienia, następuje wyzerowanie licznika; gauge miernik, działa w zakresie <0,2 32-1>; wartość może być zwiększana oraz zmniejszana; w przypadku osiągnięcia wartości maksymalnej następuje zatrzymanie (zatrzaśnięcie) się miernika na tej wartości do momentu ponownego zresetowania;

34 timeticks jest to nieujemna liczba zliczająca czas (w setnych częściach sekundy) od początku pewnej epoki; opaque typ używany do przechowywania dowolnych danych. 4.4 SNMP v2 SNMPv1 stało się popularnym narzędziem do zarządzania siecią, niestety posiadało sporo braków (początkowo zakładano je jako tymczasowe rozwiązanie). Dlatego też opracowano jego rozszerzenie, znane jako SNMPv2, które w sposób znaczący poszerza oraz poprawia dotychczasową funkcjonalność. W SNMPv2 wprowadzono nowy typ dostępu do informacji zarządzania, w którym zarządca wysyła zapytanie do innego zarządcy (Manager-Manager Request-Response). Typ ten zapewnia możliwość współpracy między zarządcami. Oczywiście, dwa pozostałe typy (zarządca agent oraz pułapka wysyłana przez agenta) są również dostępne. SNMPv2 wykorzystuje komunikaty do przesyłania informacji, których struktura jest identyczna do struktury komunikatów z wersji pierwszej. Oczywiście pole version zawiera numer wersji wskazujący na nową wersję protokołu i wynosi 1. Różnica występuje natomiast w budowie jednostek PDU. Wersja druga protokołu zawiera aż siedem jednostek PDU: GetRequest GetNextRequest SetRequest InformRequest Response GetBulkRequest SNMPv2-Trap Strukturę budowy jednostek PDU przedstawia Rysunek 17. Tabela 2 opisuje nowe pola, które pojawiły się w jednostkach PDU z SNMPv2. Warto zauważyć, że praktycznie występują tylko dwa różne formaty PDU, co znacznie upraszcza implementacje samego protokołu. Sekwencja wymiany poszczególnych jednostek PDU przedstawiona została na Rysunku

35 version community GetRequest(0), GetNextRequest(1), SetRequest(3), SNMPv2-Trap(7) InformRequest(6) PDU type requestid 0 0 variablebindings PDU GetBulkResponse(5) PDU type GetResponse(2) PDU requestid type errorstatus errorindex requestid nonrepeaters maxrepeaters variablebindings variablebindings variablebindings name1 value1 name2 value2 namen valuen Rysunek 17. Budowa komunikatu SNMPv2 Nazwa pola PDU type error-status Opis Typ PDU, możliwe wartości: 0 GetRequest 1 GetNextRequest 2 Response 3 SetRequest 5 GetBulkRequest 6 InformRequest 7 SNMPv2-Trap 8 Report Sygnalizuje rodzaj błędu, który wystąpił podczas przetwarzania zapytania; możliwe wartości: noerror (0) toobig (1) nosuchbame (2) badvalue (3) readonly (4) generr (5) noacces (6) wrongtype(7) wronglength(8) wrongencoding(9) wrongvalue(10) nocreation(11) inconsistentvalue(12) resourceunavailable(13) commitfailed(14) undofailed(15) authorizationerror(16)

36 notwritable(17) inconsistentname(18) error-index Sygnalizuje, która zmienna z listy (variablebindings) spowodowała błąd non-repeaters Pole wykorzystywane w zapytaniu GetBulkRequest, określa liczbę zmiennych z listy dla których ma być zwrócony tylko jeden następnik max-repeaters Pole wykorzystywane w zapytaniu GetBulkRequest, określa liczbę następników leksykograficznych, które zostaną zwrócone dla pozostałych zmiennych z listy, nie objętych w non-repeaters. variablebindings Lista zmiennych typu: nazwa zmiennej wartość. W przypadku wysyłania zapytania typu Get zaleca się ustawienie wartości na NULL namex Nazwa zmiennej valuex Wartość zmiennej, która może przyjmować: value wartość obiektu MIB unspecified kiedy wystąpił błąd podczas przetwarzania jednej ze zmiennych, możliwe wartości to: NULL, nosuchobject, nosuchinstance, endofmibview. Tabela 2. Opis pól komunikatu SNMPv2 Zarządca Agent Zarządca Agent GetRequest GetNextRequest GetResponse GetResponse Zarządca Agent Zarządca Zarządca GetBulkRequest InformRequest GetResponse GetResponse

37 Zarządca Agent Zarządca Agent SetRequest SNMPv2 Trap GetResponse Rysunek 18. Sekwencja wymiany komunikatów w SNMPv2 Nowa definicja pola variable-bindings (Listing 1, z RFC 1905), które wykorzystywane jest do przeprowadzania tej samej operacji na grupie instancji obiektów, nie zawiera już tylko pary: nazwa obiektu wartość, lecz może przyjmować jedną z wylistowanych wartości: value wartości instancji obiektu unspecified wartość nieokreślona (NULL) nosuchobcject obiekt nie jest zaimplementowany w agencie endofmibview wskazany obiekt wykracze poza widok MIB w agencie. Listing 1 VarBind ::= SEQUENCE { name ObjectName, CHOICE { value ObjectSyntax, unspecified NULL, nosuchobject[0] IMPLICIT NULL, nosuchinstance[1] IMPLICIT NULL, -- in retrieval requests -- exceptions in responses } } endofmibview[2] IMPLICIT NULL Zastosowanie takiej definicji variable-bindings umożliwiło pozbycie się atomowości (SNMPv1) z zapytań typu: GetRequest i GetNextRequest. W przeciwieństwie do

38 poprzedniej wersji, w wersji drugiej protokołu odpowiedź zawiera wartości wszystkich obiektów, które mogły być zwrócone, a te co do których zaistniała wyjątkowa sytuacja, zawierają oznaczenie tego wyjątku. Takie podejście w znaczącym stopniu usprawniło proces monitorowania sieci. W przypadku PDU typu SetRequest schemat postępowania wygląda inaczej. Najpierw sprawdzana jest poprawność każdej pary powiązania zmiennej z variable-bindings (według dwunastu zasad opisanych w RFC), a następnie przeprowadzane są wszystkie operacje SET. Jeśli wystąpi jakikolwiek wyjątek na dowolnej zmiennej, całe zapytanie zwraca błąd. W SNMPv2 operacja SET jest atomowa, podobnie jak w SNMPv1. Jednym z dwóch nowych typów zapytania jest GetBulkRequest. Ten typ PDU umożliwia odczytanie dużych ilości danych przy minimalnym nakładzie transakcji. Schemat działania jest zbliżony do żądania typu GetNextRequest. Lista zmiennych zawiera N+R nazw obiektów, dla których N-pierwszych nazw odczytuje się tak jak przy użyciu GetNextRequest, a dla R-ostatnich nazw zwracanych jest kilka następników leksykograficznych (max-repetitions). Jeśli odpowiedź miałaby przekroczyć dopuszczalny rozmiar komunikatu, agent zwróci tyle danych ile zdoła, informując jednocześnie zarządcę o zaistniałym wyjątku. Drugim nowym typem PDU jest InformRequest. Dzięki niemu zapewniona została komunikacja pomiędzy zarządcami. SNMPv2 jest bardzo podobny do SNMPv1, jednakże posiada też parę istotnych różnic (nowe jednostki PDU, nowa semantyka operacji GET variable bindings), które uniemożliwiają bezpośrednie współdziałanie systemów opartych na SNMPv1 i SNMPv2. Istnieją jednak dwie strategie, które umożliwiają współpracę takim systemom: z wykorzystaniem agentów proxy poprzez zarządców wspierających obie wersje protokołu. Środowisko SNMPv2 Środowisko SNMPv1 Zarządca SNMPv2 Agent SNMPv2 I Proxy Agent SNMPv1 Rysunek 19. Agent proxy wspierający komunikację pomiędzy SNMPv1 i SNMPv2-38 -

39 Wykorzystanie agenta proxy w celu zapewnienia współpracy pomiędzy dwoma wersjami protokołu SNMP jest najprostszym sposobem, pozwalającym na odpytanie jednostek SNMPv1 poprzez zarządców SNMPv2. Agent SNMPv2, odpowiednio skonfigurowany, będzie pełnił rolę agenta proxy na rzecz agentów SNMPv1. Dzięki temu zapewniona zostaje dwukierunkowa komunikacja, z konwersją komunikatów SNMPv1 i SNMPv2. Jednostka PDU Opis GetRequest Przekazywana bez żadnych zmian GetNextRequest Przekazywana bez żadnych zmian SetRequest Przekazywana bez żadnych zmian GetBulkRequest Następuje konwersja na jednostkę GetNextRequest z niezmienioną listą variable-bindings. Efektem będzie odczytanie tylko pierwszego wiersza z części max-repetitions z listy. Tabela 3. Zasady konwersji PDU SNMPv2 na SNMPv1 Jednostka PDU GetResponse Trap Opis Przekazywana bez żadnych zmian. Konwertowana jest na jednostkę SNMPv2-Trap. Dołączane są do listy zmiennych dwie nowe zmienne: sysuptime.0 oraz SNMPv2-TrapOID.0. Tabela 4. Zasady konwersji PDU SNMPv2 na SNMPv1 Drugim sposobem zapewniania współpracy pomiędzy urządzeniami wykorzystującymi różne wersje SNMP jest wykorzystanie zarządcy wspierającego obie wersje protokołu. Zarządca SNMPv2 Zarządca wspierający SNMPv1 oraz SNMPv2 Agent SNMPv1 Agent SNMPv2 Rysunek 20. Zarządca wspierający dwie wersje protokołu

40 4.5 Struktura Informacji Zarządzania SNMP v2 Ponieważ SNMPv2 jest rozwinięciem pierwszej wersji protokołu, dlatego też struktura informacji zarządzania opiera się na SMI z SNMPv1. SNMPv2 SMI definiuje bardziej szczegółowo zarządzane obiekty oraz bazę MIB. Zmieniło się nieznacznie makro OBJECT-TYPE, wykorzystywane w definicji obiektów. Główne zmiany objęły: wprowadzenie nowych typów, zmiana praw dostępu (klauzula MAX-ACCESS) dodanie klauzuli UNITS, która umożliwia podanie jednostek związanych z obiektem, zmiany w klauzuli STATUS usunięto kategorie Optional oraz Mandatowy. Dostępne typy proste to (wywodzące się z ASN.1): INTEGER liczby całkowite z zakresu <-2 31,2 31-1> OCTET STRING OBCJECT IDENTIFIER SMI SNMPv2 definiuje natomiast następujące typy aplikacyjne: IpAddress 32-bitowy adres w formacie IP-adresu Counter32 reprezentuje wartość całkowitą z przedziału <0, >, która może być tylko zwiększana; w przypadku osiągnięcia wartości maksymalnej, licznik zeruje się i zaczyna zliczanie od nowa; Counter64 typ podobny jest do Counter32 z tą różnicą, że wartością maksymalną jest ; Unsigned32 reprezentuje wartości całkowite z przedziału <0, >; używany również jako Gauge32; TimeTicks reprezentuje nieujemną wartość, która odlicza czas w setnych częściach sekundy od pewnej epoki; Opaque typ pozostawiony dla kompatybilności BITS typ wyliczeniowy, umożliwia nadanie nazw poszczególnym bitom. Typ danych SNMPv1 SNMPv2 INTEGER X X OCTET STRING X X OBCJECT IDENTIFIER X X IpAddress X X

41 Unsigned32 X Counter32 X X Counter64 X TimeTicks X X Opaque X X BITS X Gauge32 X X Tabela 5. Typy danych dostępne w SNMPv1 i SNMPv2 Największe zmiany w porównaniu z SNMPv1 dotyczą zarządzania tabelami. Poza niewielkimi zmianami w zakresie indeksowania, dostępu oraz statusu tabeli największe różnice znajdują się w sposobie tworzenia i kasowania wierszy. Mechanizm został zaczerpnięty z tzw. polki RMON (opisanej w protokole RMON [1], [2], [RFC 1757, 2021, 2074] ). Nie wprowadza on konieczności definiowania nowych typów zapytań, bazuje na zapytaniach typu get i set. Tabela, na której będą wykonywane operacje dodawania lub usuwania wierszy, musi posiadać tzw. kolumnę statusową (obiekt kolumnowy, w którym klauzula SYNTAX przyjmuje wartość RowStatus). Dodatkowo kolumna ta musi posiadać dostęp typu readcreate. Sama definicja konwencji RowStatus jest obszerna, ale dość jasno opisana w dokumencie [RFC 1443]. Dodawanie wiersza może być przeprowadzone poprzez dwie metody: createandgo, createandwait. Metoda createandwait (twórz-i-czekaj) posiada dwie fazy. Początkowa faza zaczyna się od wydania agentowi polecenia utworzenia nowego wiersza. Agent tworzy wiersz uzupełniając go wartościami domyślnymi. Następnie zarządca odpytuje agenta (get) o status każdego z nowoutworzonych obiektów. Po ewentualnej weryfikacji wartości obiektów, zarządca wysyła polecenie aktywujące dany wiersz (set) zmieniając wartość kolumny statusowej na active. Natomiast metoda createandgo (twórz-i-idź) jest dużo prostsza. Zarządca wydaje polecenie (set) utworzenia nowego wiersza agentowi. Jeśli operacja powiedzie się, agent tworzy nowy wiersz i od razu ustawia go w stan aktywności. 4.6 SNMP v3 Podstawowym założeniem SNMP jest prostota, osiągnięta poprzez dostarczenie tylko kilku funkcji, łatwość implementacji, instalacji oraz użytkowania. Dodatkowo SNMP

42 miało nie powodować nadmiernego obciążenia sieci. Dodatkowo poprzez swoją prostotę możliwe jest zapewnienie współdziałania modułów pochodzących od różnych dostawców przy minimalnym nakładzie pracy oraz kosztów. SNMP bazuje na trzech pojęciach: menadżerach, agentach i bazie informacji zarządzania (MIB). W dowolnej konfiguracji przynamniej jeden host musi posiadać status zarządcy. Każde urządzenie sieciowe (komputer, router, most, serwer) wyposażone jest w moduł agenta, który odpowiedzialny jest za dostęp do lokalnej bazy MIB, odzwierciedlającej zasoby oraz inne parametry opisujące aktywność danej jednostki. Obiekty w bazie MIB mogą być odczytywane (np. odczyt licznika aktualnie wysłanych pakietów) jak i ustawiane (wyłączenie danego linka). Opisane zdolności są w zupełności wystarczające w bardzo prostych i podstawowych aspektach zarządzania. Rozszerzeniem tej funkcjonalności było wprowadzenie nowej wersji protokołu SNMPv2. SNMPv2 dodatkowo dostarcza możliwość odczytu dużej ilości informacji (bulk request), usprawnia mechanizm zarządzania tabelami, umożliwia komunikację pomiędzy zarządcami, etc. Jednakże żaden z nich nie wspiera należycie zagadnień związanych z bezpieczeństwem. Ani SNMPv1, ani SNMPv2, nie potrafi uwierzytelnić źródła, z którego została wysłana wiadomość, ani dostarczyć metod szyfrowania wiadomości. Bez tych podstawowych zagadnień bezpieczeństwa, nieautoryzowany użytkownik może używać funkcji SNMP oraz podsłuchiwać przesyłane wiadomości. Z tych właśnie powodów wiele implementacji SNMPv1/v2 zostało ograniczonych jedynie do możliwości odczytu danych, ograniczając jednocześnie możliwości zarządzania i kontroli. Odpowiedzią na problemy związane z aspektami bezpieczeństwa jest SNMPv3. SNMPv3 zostało opublikowane w styczniu 1998 roku jako zbiór proponowanych standardów (RFC 2271, 2272, 2273, 2274, 2275). Ten zbiór dokumentów nie dostarcza definicji nowego protokołu, ale raczej definiuje ogólną architekturę SNMP oraz dostarcza mechanizmów bezpieczeństwa. W jednym z dokumentów opisujących SNMPv3 jest napisane: SNMPv3 is SNMPv2 plus administration and security. Sformułowanie to oznacza, że SNMPv3 jest zaprojektowane tak, by używać go w połączeniu z SNMPv2. SNMPv3 zawiera trzy ważne usługi: uwierzytelnianie (authentification),

43 prywatność (privacy), kontrolę dostępu (access control). SNMPv3 wykorzystuje modułowy schemat budowy (Rysunek 21). Każda jednostka SNMP (SNMP entity) zawiera jeden moduł, zwany SNMP engine, który implementuje funkcje do: wysyłania oraz odbierania wiadomości, uwierzytelniania, szyfrowania/deszyfrowania, kontroli dostępu do zarządzanych obiektów. Ta funkcjonalność dostarczana jest w formie usług jednej lub kilku aplikacji, które odpowiednio skonfigurowane razem z SNMP engine, stanowią jednostkę SNMP. Architektura modułowa przynosi wiele korzyści. Pierwszą z nich jest rola, jaką może pełnić jednostka SNMP, która uzależniona jest od modułów, jakie zawiera. Dla przykładu agent ma pewny określony zbiór modułów, które musi zawierać, natomiast menadżer ma zupełnie inny (choć może częściowo się pokrywać). Drugą korzyścią stosowania modułowości jest możliwość korzystania z różnych wersji poszczególnych modułów, bez konieczności definiowania nowego standardu. Aplikacje Generator poleceń Odbiorca powiadomień Przekaźnik proxy Wykonawca poleceń Nadawca powiadomień Inne SNMP engine Blok nadawczy Podsytem przetwarzania wiadomości Podsystem bezpieczeństwa Podsystem kontroli dostępu Rysunek 21. Jednostka SNMP (na podstawie RFC 2271)

44 Nazwa modułu Blok nadawczy (dispatcher) Podsystem przetwarzania wiadomości (message processing subsytem) Podsystem bezpieczeństwa (security subsytem) Podsystem kontroli bezpieczeństwa (access control subsystem) Generator poleceń (command generator) Wykonawca poleceń (command responder) Odbiorca powiadomień (notification receiver) Nadawca powiadomień (notification originator) Przekaźnik proxy (proxy forwarder) Opis Pozwala na równoczesną obsługę wiadomości pochodzących z różnych wersji protokołu SNMP. Odpowiedzialny jest za przygotowanie wiadomości do wysłania oraz za wydobywanie danych z nadesłanych wiadomości. Dostarcza usług bezpieczeństwa takich jak autoryzacja oraz prywatność wiadomości. Podsystem ten może zawierać wiele modeli bezpieczeństwa. Dostarcza zbioru usług autoryzacyjnych, które pozwalają aplikacji na sprawdzenie praw dostępu. Podsystem ten może być wykorzystywany w operacjach odczytu lub modyfikacji wartości obiektów oraz przy generowaniu powiadomień. Inicjuje żądania typu: Get, GetNext, GetBulk oraz Set. Przetwarza i generuje odpowiedź na nadesłane wcześniej żadanie. Odbiera jednostki PDU przeznaczone dla danego systemu (contextengineid). Aplikacja wykonawcy poleceń podejmie wykonanie polecenia po weryfikacji odebranej wiadomości powiadomień w podsystemie kontroli dostępu i wygeneruje odpowiedź, która zostanie wysłana do jednostki wysyłającej żądanie. Monitoruje system pod kątem wystąpienia określonego zdarzenia lub warunku, po czym generuje powiadomienie (Trap lub Inform PDU) bazując na występujących zdarzeniach. Oczekuje na komunikaty powiadomień i generuje odpowiedzi w przypadku, kiedy nadesłana wiadomość jest typu Inform PDU. Przekierowywuje wiadomości do jednostki, w imieniu której działa. Moduł ten jest opcjonalny. Tabela 6. Opis komponetów jednostki SNMP Podobnie jak wcześniejsze wersje, tak i SNMPv3 wykorzystuje protokół UDP (wyjątkowo możliwy jest inny) do przekazywania wiadomości. Powyżej warstwy UDP, funkcjonalność SNMP jest zorganizowana w dwóch blokach: blok przetwarzania jednostek PDU, blok przetwarzania wiadomości. Najwyższą warstwą jest blok przetwarzania jednostek PDU. W tej warstwie komendy zarządzania (takie jak Get, Set, Trap, Inform) są przekształcane do PDU, które zawiera typ komendy oraz listę zmiennych. Następnie tak utworzone PDU jest przekazywane warstwie niższej blokowi przetwarzania wiadomości, który dodaje nagłówek wiadomości. Nagłówek wiadomości zawiera informacje związane z bezpieczeństwem, które mogą zostać użyte w celu autoryzacji, bądź w operacjach szyfrujących. Rysunek 22 przedstawia strukturę wiadomości. Pierwsze pięć pól generuje (wiadomości wychodzące) oraz przetwarza (wiadomości przychodzące) podsystem przetwarzania wiadomości. Kolejnych sześć pól zawiera informacje na temat parametrów bezpieczeństwa wykorzystywanych przez podsystem bezpieczeństwa. Ostatnie trzy pola stanowią zakres

45 PDU, wykorzystywane są w przetwarzaniu PDU. Dokładny opis pól można znaleźć w [RFC 2272][1][2]. msgversion msgid msgmaxsize msgflags msgsecuritymodel msgauthoritativeengineid Zakres uwierzytelniania msgauthoritativeengineboots msgauthoritativeenginetime msgusername msgauthenticationparameters msgprivacyparameters contextengineid Zakres szyfrowania contextname PDU Rysunek 22. Schemat budowy wiadomości SNMPv3 Opis pięciu pierwszych pól znajduje się w Tabeli 7 poniżej. Nazwa pola Opis msgversion Wersja (3 dla SNMPv3) msgid Unikalny identyfikator używany pomiędzy dwoma jednostkami SNMP do koordynacji żądań i odpowiedzi. Identyfikator ten jest również wykorzystywany przez podsystem przetwarzania wiadomości do identyfikowania przetwarzanych danych przez różne podsystemy wchodzące w skład architektury. Zakres wynosi od 0 do msgmaxsize Zawiera informację o maksymalnej wielkości wiadomości (w oktetach) jaka jest wspierana przez wysyłającego, zakres wynosi 484 do msgflags Pole typu octet string zawierające informacje na temat trzech flag (poczynając od najmniej znaczącego bitu): reportable Flag privflag authflag msgsecuritymodel Identyfikator przyjmujący wartości z zakresu 0 (2 31-1) mówiący o tym jaki model zabezpieczeń został wykorzystany przez nadawcę w celu przygotowania wiadomości. Taki sam

46 model musi zostać użyty przez odbierającego do przetworzenia nadesłanej wiadomości. Wartości: 1, 2, 3 są zarezerwowane dla SNMPv1-3. Tabela 7. Opis pierwszych pięciu pól nagłówka wiadomości SNMPv3 SNMPv3 wykorzystuje model bezpieczeństwa oparty na użytkownikach (USM User- Based Security Model). Został on zdefiniowany w dokumencie [RFC 2274]. Model ten bazuje na pojęciu autorytatywnej jednostki (authoritative engine). W jakiejkolwiek wymianie wiadomości, jedna z dwóch jednostek (nadawca bądź odbiorca) jest desygnowana na autorytatywną jednostkę według następujących zasad: kiedy wiadomość SNMP zawiera dane świadczące o tym, iż spodziewana jest odpowiedź (Get, GetNext, GetBulk, Set lub Inform PDU) wtedy odbiorca takiej wiadomości jest autorytatywny, w przeciwnym wypadku, kiedy wiadomość nie zawiera danych wskazujących na żądanie odpowiedzi (Trap, Response lub Report PDU), wówczas nadawca jest autorytatywny. Oznaczenie jednej ze stron jako wiarygodnej (autorytatywnej) służy dwóm celom: kontroli czasu, procesowi lokalizacji klucza (pojedynczy zwierzchnik może posiadać klucze przechowywane w wielu jednostkach). Każda wiadomość wysyłana i odbierana przez jednostkę SNMP przechodzi przez USM, który wykorzystuje pola opisane w Tabeli 8. Nazwa pola Opis msgauthoritativeengineid Pole zawiera wartość snmpengineid autorytatywnej jednostki. msgauthoritativeengineboots Przechowuje wartość snmpengineboots autorytatywnej jednostki, która mówi o ilość inicjalizacji/reinicjalizacji danej jednostki od początkowej konfiguracji. Zakres wartości od 0 do (integer). msgauthoritativeenginetime Przechowuje wartość snmpenginetime autorytatywnej jednostki. Zmienna ta opisuje ilość sekund, jakie upłynęły od czasu ostaniej inkrementacji snmpengineboots. Zakres wartości od 0 do (integer). msgusername Użytkownik (zwierzchnik principal) na rzecz, którego następuje wymiana wiadomości. msgauthenticationparameters Jeśli nie jest używana autoryzacja wiadomości pole to przyjmuje wartość NULL, w przeciwnym wypadku przechowuje parametry potrzebne przy autoryzacji (w obecnej formie są to parametry potrzebne metodzie HMAC zobacz w [1], [2], [RFC 2104]). msgprivacyparameters Przyjmuje wartość NULL jeśli nie jest stosowany

47 mechanizm szyfrowania wiadomości, w przeciwnym wypadku zawiera parametry szyfrowania (algorytm DES [1], [2], [RFC 2104]). Tabela 8. Opis pól nagłówka wiadomośći SNMPv3 W celu upewnienia się, że wysłana wiadomość pochodzi od zwierzchnika zamieszczonego w nagłówku, SNMPv3 wykorzystuje mechanizm autoryzacji. Dodatkowo mechanizm ten zabezpiecza przed nieautoryzowaną zmianą wiadomości, sztucznym opóźnianiem, bądź duplikowaniem komunikatów. Autoryzacja osiągnięta jest poprzez sekretny klucz autoryzacji, który jest wspólny dla obu jednostek (zwierzchnika i zwykłej jednostki) próbujących nawiązać komunikację. Klucz ten w połączeniu z algorytmem uwierzytelniania HMAC (HMAC-MD5-96 lub HMAC-SHA1-96) generuje pewną wartość wyjściową umieszczaną w nagłówku wiadomości, wykorzystywaną później w procesie uwierzytelniania danej wiadomości. Dodatkowym mechanizmem stosowanym w celu uwierzytelnienia wiadomości jest weryfikacja czasu, której szczegółowy opis można znaleźć w pozycji [1][2]. Dodatkowo prywatność może być chroniona w SNMPv3 przy wykorzystaniu konwencjonalnych metod szyfrowania danych. Model USM wykorzystuje w tym celu schemat szyfrowania DES (Data Encryption Standard). Więcej informacji można znaleźć w opisie standardu [RFC 2274] oraz publikacjach [1] oraz [2]. Kontrola dostępu w SNMPv3 opiera się na modelu VACM (View-Based Access Control Model) zdefiniowanych w dokumencie [RFC 2275]. Model ten pozwala na zdefiniowanie kilku poziomów dostępu do bazy MIB, którą zarządza agent. 4.7 MIB Każde urządzenie wspierające standard SNMP musi zarządzać zbiorem obiektów opisujących jego aktualny stan, konfiguracje etc. Zbiór ten nazywany jest bazą informacji zarządzania MIB (Management Information Base). Zarządzane obiekty (wartości), które są zgrupowane w MIB, mogą być odczytywane lub zmieniane w celu dostarczania informacji o zarządzanym urządzeniu sieciowym. MIB ma strukturę drzewiastą, w której liście reprezentują obiekty. Każdy obiekt posiada elementy opisane poniżej: typ obiektu (object type) identyfikuje typ obiektu MIB, zazwyczaj prosta nazwa; składnię (syntax) typ wartości obiektu; pole dostępu (access) określa maksymalny poziom dostępu do zmiennej i może przyjmować jedną z wartości: o odczyt-tworzenie (read-create),

48 o odczyt-zapis (read-write), o tylko odczyt (read only), o dostępny tylko dla notyfikacji (accessible-for-notify), o niedostępny (not-accessible); status (status) informuje o statusie obiektu, który może przyjmować wartości: o mandatory obowiązkowy; o current obecny; o deprecated niezalecany, wkrótce nie będzie implementowany ; o obsolete przestarzały, nie powinien być implementowany; opis (description) krótki opis (tekstowy) zarządzanego obiektu Definicja poszczególnych obiektów, jak również samej struktury MIB, jest sformalizowana i wyspecyfikowana przy pomocy składni ASN.1. Warto na samym początku również wspomnieć, że MIB nie jest bazą danych. Jest raczej pojęciem abstrakcyjnym, logicznym uporządkowaniem danych tak, aby były one łatwo dostępne i zrozumiałe dla wszystkich. Obecnie w użyciu są dwie wersje baz MIB, nazywane odpowiednio MIB-1 oraz MIB-2. MIB-2 jest rozszerzeniem pierwszej wersji i jest używane przez SNMP. Powstało również wiele eksperymentalnych oraz korporacyjnych baz MIB. Z każdym typem obiektu w MIB związany jest pewien identyfikator typu ASN.1 OBJECT IDENTIFIER. Identyfikator ten służy jako nazwa obiektu. Oznaczany jest czasem symbolem OID. OID jest unikalnym identyfikatorem dla poszczególnych typów obiektów. Jego wartość składa się z sekwencji liczb całkowitych. Jak już wspomniano wcześniej, zbiór tak zdefiniowanych obiektów przyjmuje strukturę drzewa. Każda wartość składnika identyfikatora obiektu identyfikuje pewien wycinek drzewa, poczynając od jego pnia. Na poziomie pnia, a więc na jego pierwszym poziomie, są trzy węzły iso, ccitt, joint-iso-ccitt [1]. Rysunek 23 ilustruje kolejne poziomy bazy MIB. Warto zaznaczyć, że obiekty w bazie MIB są ułożone w porządku leksykograficznym. Właściwość ta wykorzystywana jest przy zapytaniach typu GetNext/GetBulk

49 Rysunek 23. Grupy obiektów MIB-II

50 5 Abstrakcyjna Notacja Składniowa 1 (ASN.1) Abstrakcyjna Notacja Składniowa (Abstract Syntax Notation One) jest notacją używaną do opisu wiadomości wymienianych pomiędzy komunikującymi się systemami lub aplikacjami. Dostarcza wysokopoziomowego opisu danych wolnych od jakiegokolwiek narzutu protokołów, architektury oraz ułożenia bitów i bajtów w wiadomości. ASN.1 oraz jego zasady kodowania zostały ustandaryzowane przez CCITT (X.208) oraz przez ISO (ISO 8824). Najważniejszymi cechami ASN.1, dzięki którym notacja jest tak ważna i unikalna są: definiowanie struktur danych na bardzo wysokim poziomie abstrakcji, które jest międzynarodowo ustandaryzowane, niezależne od producentów, niezależne platformowo oraz językowo (języki programowania), wsparcie w wielu aplikacjach użytkowych, działających na prawie wszystkich platformach, implementacja w wielu językach programowania, która pozwala na automatyczne przekładanie struktur zdefiniowanych w ASN.1 na struktury zależne od danego języka, dokładnie opisane reguły reprezentacji oraz przesyłania danych uwzględniające reprezentację bitową i ich kolejność. ASN.1 dostarcza wielu predefiniowanych typów podstawowych takich jak: liczby całkowite (INTEGER), wartości logiczne (BOOLEAN), ciągi znakowe (IA5String, UniversalString, etc), ciągi bitowe (BIT STRING), inne. Można również definiować typy złożone (własne) przy pomocy konstrukcji takich jak: SEQUENCE struktury, SEQUENCE OF listy, CHOINCE wybieranie pomiędzy typami, inne. Dzięki tym typom i konstrukcjom możliwe jest zdefiniowanie dowolnych innych struktur danych (audio, video, etc.). Opisanie dokładne wszystkich typów i konstrukcji używanych

51 wykracza poza niniejsze opracowanie, dlatego też więcej szczegółów zostało opisanych w publikacjach [5], [27]. 5.1 Podstawowe zasady kodowania (BER) Podstawowe zasady kodowania (BER Basic Encoding Rules) określają sposób kodowania wartości każdego typu ASN.1 w postaci ciągu oktetów. BER jest historycznie oryginalnym zestawem zasad kodowania ASN.1. Wchodzą one w skład standardu opublikowanego przez CCITT (X.209) oraz ISO (ISO 8825). Składnia kodowania BER ma zawsze format w postaci tzw. trójki TLV (Type, Length, Value Typ, Długość, Wartość) Rysunek 24. T L V Rysunek 24. Trójka TLV (Triplet TLV) Każde z pól T, L lub V może być zbudowane z serii oktetów. Dodatkowo pole V może zawierać kolejną trójkę TLV (zasada rekursji, Rysunek 25). Porządek bitów w oktecie jest typu big Endians, tzn. najbardziej znaczący bit znajduje się po lewej stronie oktetu (Rysunek 26). Rysunek 25. Rekursja TLV oktet Rysunek 26. Porządek bitów w oktecie Oktety typu T kodują typ oraz klasę ASN.1. Dodatkowo wskazują na rodzaj zastosowanego kodowania: proste (primitive) lub złożone (constructed). Rysunek 27 przedstawia strukturę budowy oktetów typu T

52 Klasa Kodowanie Etykieta (tag) oktet typu T (tag octet) Rysunek 27. Struktura budowy oktetu typu T Jeżeli numer typu ASN.1 jest mniejszy bądź równy 30, wtedy kodowany jest on w postaci pojedynczego oktetu (Rysunek 28) na pięciu najmniej znaczących bitach. W przeciwnym wypadku pięć najmniej znaczących bitów z pierwszego oktetu ustawianych jest na 1, żądana wartość kodowana jest przy pomocy tylu oktetów, ile jest potrzebnych do zakodowania jej, używając tylko siedmiu najmniej znaczących bitów z każdego oktetu. Najbardziej znaczący bit ustawiany jest na 1 dla wszystkich oktetów składających się na kodowany typ z wyjątkiem ostatniego, który ma wartość 0. Klasa ASN.1 Bit 7 Bit 6 Universal (uniwersalna) 0 0 Application (aplikacyjna) 0 1 Context-specific (kontekstowa) 1 0 Private (prywatna) 1 1 Tabela 9. Wartości dla klas ASN.1 Bit określający rodzaj kodowania (piąty najmniej znaczący bit) ustawiany jest na 1 w przypadku, kiedy część V zawiera kolejną trójkę TLV (SET, SET-OF), w przeciwnym wypadku ustawiany jest na 0 (INTEGER). Bit ten również wskazuje na rodzaj kodowania długości, jaki został użyty. BER oferuje trzy rodzaje kodowania długości (oktetów typu L). Pierwszą jest krótka forma (short definite length) Rysunek 29. Używana jest wtedy, kiedy liczba oktetów w cześć V jest mniejsza od 128 i może być używana niezależnie od tego czy zastosowano kodowanie proste, czy złożone. Forma ta jest identyfikowana, kiedy najbardziej znaczący bit oktetu L ustawiony jest na 0, pozostałe 7 bitów wskazuje na liczbę V oktetów

53 0 tag t t t t t tag > Numer etyukiety Rysunek 28. Kodowanie numeru etykiety L L L L L L L Rysunek 29. Kodowanie długości krótka forma W przypadku, kiedy najbardziej znaczący bit L-oktetu przyjmuje wartość 1, wtedy do kodowania długości używana jest tak zwana długa forma (long definite length) Rysunek 30. Siedem najmniej znaczących bitów pierwszego oktetu określa liczbę oktetów użytych do zapisu długości. Wartość ta musi być mniejsza od 127 ( b), która została zarezerwowana dla przyszłych rozszerzeń. Praktycznie oznacza to, że długość, którą można zapisać w ten sposób wynosi oktetów. Liczba ta jest większa od ilości gwiazd w naszej galaktyce l l l l l l l L L L L L L L L L L L L L L L L L L L L L L L L lllllll oktetów Rysunek 30. Kodowanie długości - forma długa Ostatnią formą kodowania długości jest kodowanie o nieokreślonej długości (indefinite length) Rysunek 31. Forma ta może być tylko wtedy użyta, kiedy zostało użyte złożone kodowanie części V (zawiera serię trójek TLV). Kodowanie długości każdej z trójek, wchodzących w skład części V, może korzystać z dowolnej formy kodowania długości, również nieokreślonej. Zgodnie z definicją, najstarszy bit pierwszego oktetu przyjmuje

54 wartość 1, pozostałe zaś ustawione są na 0. Następne oktety należą już do trójek TLV i tworzą cześć V, której długość wyznaczona jest przez specjalny ogranicznik parę zerowych oktetów Zawartość (V) Rysunek 31. Kodowanie długości - forma nieokreślona Ponieważ niniejsze opracowanie skupia się na zagadnieniach związanych z SNMP, nie będzie zawierało opisu zasad kodowania dla wszystkich typów zdefiniowanych w ASN.1, tylko dla tych, które wykorzystuje SNMP (Tabela 10). Nazwa zmiennej Typy proste ASN.1 (primitive, basic) INTEGER BIT STRING OCTET STRING NULL OBJECT IDENTIFIER Typy konstrukcyjne ASN.1 (constructed) SEQUENCE Typy aplikacyjne SNMP (application) IpAddress Counter (Counter32 SNMPv2) Gauge (Gauge 32 SNMPv2) TimeTicks Opaque Counter64 (SNMPv2) Uinteger32 (SNMPv2) Rodzaje wiadomości SNMP (message types) GetRequest-PDU GetNextRequestPDU GetResponse/Response-PDU SetRequest-PDU Trap-PDU GetBulkRequest-PDU InformRequest-PDU SNMPv2-Trap-PDU ASN.1 indetifikator (hex) 0x02 0x03 0x04 0x05 0x06 0x30 0x40 0x41 0x42 0x43 0x44 0x46 0x47 0xA0 0xA1 0xA2 0xA3 0xA4 0xA5 0xA6 0xA7-54 -

55 Tabela 10. Typy ASN.1 wykorzystywane w SNMP Dodatkowo, należy zaznaczyć, że SNMP nie używa kodowania o nieokreślonej długości, dlatego też nie zostało ono omówione w niniejszym opracowaniu. Zostało jedynie zaznaczone, że można użyć takiego kodowania przy konkretnym typie. Obszerne omówienie kodowania BER można znaleźć w opracowaniach: [25], [24], [5]. Kodowanie typów prostych zostało przedstawione w Tabeli 11. Wszystkie liczby przedstawione w tabeli zapisane są w formacie hexadecymalnym. T L V Uwagi Przykład INTEGER 02 LL VV Kodowanie: proste; LL oznacza ilość oktetów potrzebnych na zakodowanie liczby, VV zakodowana liczba. Reprezentacja liczby opiera się na uzupełnianiu do dwóch z najmniejszą liczbą wykorzystanych oktetów. BIT STRING 03 LL VV Kodowanie: proste lub złożone; W kodowaniu prostym oktety VV, które składają się na wartość można przedstawić w postaci: Lead_octet + (LL -1)*data_octet gdzie: Lead_octet oznacza oktet inicjujący oznaczający liczbę nieużywanych bitów z lewej strony ciągu, którego wartość może być pomiędzy 0 a 7. Nieużywane bity mogą być ustawione na 1 lub 0. data_octet oznacza oktety z danymi. Tak więc długość oznacza liczbę oktetów potrzebnych do zapisania żadanej wartości plus jeden oktet inicjujący. Oczywiście jeśli nie ma w ogóle oktetów z danymi wówczas długość (LL) wynosi 1, a wartość Lead_octet to 0. OCTET STRING 04 LL VV Kodowanie: proste lub złożone; Przy kodowaniu prostym oktety zawartości odpowiadają po kolejnym 48: F: F -80: : B: B7 88 gdzie: B7 88 można przedstawić w postaci binarnej jako: xxx W tym przykładzie x = :

56 wartością łańcucha. LL oznacza liczbę oktetów VV składających się na zawartość. NULL Kodowanie: proste; Brak wartości V. OBJECT IDENTIFIER 06 LL VV Kodowanie: proste W generalnym ujęciu wartość składa się z sekwencji integer ów. Każdy integer (podidentyfikator) kodowany jest przy użyciu 7 najmniej znaczących bitów oktetu. Najbardziej znaczący bit oktetu ustawiany jest na 0 jeśli jest to ostatni oktet kodowanej wartości, w przeciwnym wypadku przyjmuje 1. Dodatkowo dwa pierwsze () identyfikatory tworzone są przy pomocy wyrażenia: 1_ident * _ident SEQUENCE 30 LL VV Kodowanie: złożone Każdy element znajdujący się na liście jest kodowany i dołączany do pola VV zgodnie z kolejnością wystąpień. LL zawiera ilość wszystkich oktetów stanowiących VV. CHOICE Kod wartości CHOICE jest kodem wybranej wartości Tabela 11.Kodowanie BER typów prostych AABBCC0011: AA BB CC OID: B Triplet SEQUENCE of INTEGER ::= {2, 6, 5} VV Definicja typów aplikacyjnych ustawione bity 7 i 6 na 01b używanych w SNMP została przedstawiona na Listingu 2. Wynika z niej, że wszystkie typy aplikacyjne używane w SNMP zostały zdefiniowane jako IMPLICIT i bazują na typach prostych. Dlatego też kodowanie ich polega na zastąpieniu kodu pola etykiety typu prostego przez kod etykiety (tag) typu aplikacyjnego, a pozostałe pola (długość i wartość) pozostają bez zmian

57 Listing 2 (RFC 1155) IpAddress ::= [APPLICATION 0] -- in network-byte order IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER ( ) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER ( ) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER ( ) Opaque ::= [APPLICATION 4] -- arbitrary ASN.1 value, IMPLICIT OCTET STRING -- "double-wrapped" Przykładowo, chcąc zakodować wartość 48 typu COUNTER (tag: 0x41), stosując się do opisanej wyżej zasady, musimy wykonać następujące kroki: 1. typ COUNTER zdefiniowany jest jako IMPLICIT INTEGER, zatem należy poszukać sposobu kodowania INTEGER a; 2. wartość 48 zakodowana jako INTEGER wygląda: , gdzie kolorem czerwonym zaznaczono pole etykiety; 3. podmieniając pole etykiety dostaniemy szukaną wartość:

58 6 Routery Router jest inteligentnym urządzeniem sieciowym, pracującym w trzeciej warstwie modelu OSI, służącym do przekazywania pakietów pomiędzy różnymi sieciami komputerowymi. Bazując na wewnętrznej tablicy, zwanej tablicą routingu oraz na innych parametrach stanowiących koszt, router podejmuje decyzje, na który interfejs ma przesłać odebrany pakiet. Routery są uważane za urządzenia sieci WAN, aczkolwiek mogą również działać w sieciach lokalnych (LAN) [7]. Mogą być używane do łączenia zarówno podobnych, jak i niejednorodnych segmentów sieci (Rysunek 32, 33). Rysunek 32. Przykład wykorzystania routerów Rysunek 33. Wykorzytanie routerów Routery stosowane są zazwyczaj do obsługi wielu protokołów, z których każdy ma własny protokół routingu. Routery umożliwiają ich równoległe współdziałanie [7]. Ponieważ routery funkcjonują na poziomie warstwy sieci (trzeciej) modelu OSI, są używane do tworzenia segmentów będących unikalnymi domenami kolizji i rozgłoszeń. Segmenty te nazywane są sieciami. Każda sieć jest nie tylko własną domeną kolizji i rozgłoszeń, ale również ma własny logiczny adres sieci. Ponadto, każda jednostka w sieci ma własny, unikatowy adres, który wskazuje na sieć do której należy oraz identyfikuje tę

59 jednostkę [7]. Dodatkowo, ponieważ routery operują w trzeciej warstwie OSI, mogą ograniczać, bądź zabezpieczać ruch sieciowy w zależności od atrybutów każdego z pakietów (na dowolnym interfejsie). Funkcjonalność ta nosi nazwę list dostępu (ACL access list control) i wykracza poza niniejsze opracowanie. 6.1 Routery CISCO Routery CISCO, jak sama nazwa wskazuje, produkowane są przez firmę CISCO Systems. Obecnie firma w swojej ofercie ma kilka serii routerów różniących się mocą oraz stopniem zaawansowania (od najstarszych i najprostszych 800, 1700, 1800 po te najnowsze i najbardziej nowoczesne 7600, 10000, 10700, 12000). Dokładny opis można znaleźć na stornie producenta : Series 3600 Series 7600 Series Series Rysunek 34. Routery Cisco Pomimo różnorodnej budowy oraz zaawansowania, w routerach CISCO można wyszczególnić kilka cech wspólnych. Pierwszą z nich jest międzysieciowy system operacyjny IOS (Internetworking Operating System). Jest on tym samym dla routera

60 czym system operacyjny dla komputera. Projektantom IOS przyświecała myśl o zbudowaniu elastycznego produktu, który mógłby rozwijać się wraz z ewolucją danej sieci. Jest on dobrze przystosowany do obsługi zmian i migracji, a to dzięki zdolności do integracji różnych rozwijalnych platform sieciowych. System IOS obejmuje sieci rdzeniowe, grupy robocze, sieci ze zdalnym dostępem i rozwiązania międzysieciowe firmy IBM. Obsługuje formalne i nieformalne standardy interfejsów sieciowych, a w tym głównie protokoły sieciowe takie jak IP, IX, NetBIOS, SNA oraz AppleTalk. Zapewnia najważniejsze usługi sieciowe, m.in. routing, optymalizację sieci rozległych, zarządzanie, systemy ochrony i skalowalność [6]. Najnowsza wersja to 12.4 [28]. Listing 3. Router1#config terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#hostname MyRouter MyRouter(config)#^Z MyRouter# Listing 4.! Enable service password-encryption if it isn't already. service password-encryption! Here is our enable password, which is ok! but not too secure. enable password 7 141B171F ! Here is our enable secret, much better. enable secret 5 $1$99Jc$dxVXUkwMM3Edvj7f0SUrL/ Kolejną cechą jest posiadanie wspólnych komponentów fizycznych takich jak: procesor, pamięć RAM, pamięć NVRAM, pamięć Flash, ROM, Interfejs. 6.2 Konfiguracja SNMP na routerach Cisco Implementacja SNMP na routerach Cisco wspiera wszystkie obiekty MIB II opisane w dokumencie RFC 1213 oraz definiuje pułapki, korzystając z wytycznych zawartych w RFC Dodatkowo Cisco wprowadza własne prywatne rozszerzenia MIB. IOS, system operacyjny routerów Cisco, do wersji 11.2(6)F wspierał SNMPv2, następnie został

61 on zastąpiony SNMPv2c (SNMP opartym na społecznościach). SNMPv1 wspierane jest już przez najstarsze wersje systemu. Ponieważ poprzednie wersje protokołu nie posiadają dostatecznych mechanizmów bezpieczeństwa, dlatego też począwszy od wersji 12.0(3)T, IOS udostępnia SNMPv3. Identyfikator obiektu: (lub iso.org.dod.internet.private.enterprise.cisco) reprezentuje Cisco MIB, z którego odchodzą dwie główne gałęzie: Workgroup Products (5) oraz Cisco Management (9). Szczegółowy opis można znaleźć w [29]. W celu skonfigurowania usługi SNMP na routerze, użytkownik musi znajdować się w trybie uprzywilejowanym. Następnie należy wydać komendę: configure terminal która ustawia tryb konfiguracji terminala. W trybie tym dostępnych jest szereg funkcji służących konfiguracji SNMP. W niniejszym opracowaniu zostaną one jedynie pokrótce omówione, dokładny opis można znaleźć w dokumentacji Cisco. Komenda Znaczenie Tworzenie oraz modyfikowanie widoków snmp-server view view-name oid-tree Tworzy lub modyfikuje widok SNMP {included excluded} no snmp-server view view-name Usuwa dany widok SNMP Tworzenie oraz modyfikowanie reguł dostępu dla określonej społeczności SNMP snmp-server community string [view Definiuje dostęp dla danej społeczności view-name] [ro rw] [number] no snmp-server community string Usuwa dostęp Definiowanie nazwy serwera Engine SNMP snmp-server engineid [local engineidstring] [remote ip-address udp-port zarówno lokalnej jak i zdalnej. Konfigurowanie nazwy SNMP Engine port-number engineid-string] Definiowanie grup snmp-server group [groupname {v1 v2c v3 [auth noauth priv]}][read readview] [write writeview] [notify notifyview] [access access-list] Konfigurowanie odbiorców pułapek snmp-server host host [traps informs][version {1 2c 3 [auth noauth priv]} ] community-string [udp-port port] [notification-type] Konfigurowanie użytkowników SNMP snmp-server user username [groupname remote ip-address [udp-port port] {v1 v2c v3 [encrypted] [auth {md5 sha} auth-password [priv des56 priv password]] [access access-list] Konfiguruje nową grupę SNMP, która mapuje użytkowników SNMP na odpowiednie widoki. Konfiguruje odbiorcę (adres, port, etc) powiadomień Dodanie nowego użytkownika SNMP Uaktywnienie mechanizmu zamykania (Shutdown Mechanism) snmp-server system-shutdown Uaktywnienie usługi przeładowania systemu

62 Konfiguracja ustawień informacyjnych agenta snmp-server contact text Ustawienie informacji kontaktowych snmp-server location text Ustawienie informacji o lokalizacji snmp-server chassis-id number Ustawienie numeru seryjnego Informacje statusowe show snmp Wyświetla ogólne informacje statusowe o SNMP show snmp engineid [local remote] Wyświetla informacje na temat lokalnego oraz zdalnego SNMP Engine show snmp groups Wyświetla informacje o grupach show snmp user Wyświetla informacje o użytkownikach Wyłączanie agenta SNMP no snmp-server Wyłącza agenta Konfigurowanie wysyłania pułapek (traps) snmp-server engineid remote remote-ipaddr Określa engine ID dla zdalnego hosta remote-engineid snmp-server user username groupname Przypisuje użytkownika SNMP do hosta remote remote-ip-addr v3 snmp-server group [groupname {v1 v2c Konfiguruje grupy na zdalnym hostcie v3 {auth noauth priv}}] [read readview] [write writeview] [notify notifyview ] [access access-list] snmp-server host host-addr traps [ Definiuje odbiorcę powiadomień version {1 2c 3 [auth noauth priv] }] groupname [notification-type] snmp-server enable traps [notificationtype] Uaktywnia wysyłanie powiadomień lub [notification-option] notyfikacji, specyfikuje też typ tego powiadomienia snmp-server trap-source interface Specyfikuje źródło pułapek, jak również jest ono źródłowym adres ip dla powiadomień (wiadomości typu informs) snmp-server queue-length length Ustawia długość kolejki powiadomień snmp-server trap-timeout seconds Konfigurowanie wysyłania powiadomień (informs) snmp-server engineid remote remote-ipaddr remote-engineid snmp-server user user-name group-name remote remote-ip-addr v3 snmp group group-name v3 noauth snmp-server host remote-ip-addr informs v3 noauth group-name config snmp-server enable traps [notificationtype] snmp-server informs [retries retries] [timeout seconds] [pending pending] snmp-server trap-source interface Zarządzanie sesjami snmp-server manager snmp-server manager session-timeout seconds show snmp show snmp sessions [brief] show snmp pending Definiuje częstotliwość z jaką mają być retransmitowane wiadomości Określa engine ID dla zdalnego hosta Przypisuje użytkownika SNMP do hosta Konfiguruje grupy na zdalnym hostcie Określna odbiorcę wiadomości typu inform Uaktywnia wysyłanie powiadomień lub notyfikacji, specyfikuje też typ tego powiadomienia Konfiguruje opcje związane z retransmisją niepotwierdzonych powiadomień Specyfikuje źródło pułapek, jak również jest ono źródłowym adres ip dla powiadomień (wiadomości typu informs) Uaktywnia manadżera SNMP Określa czas, po jakim sesja zostanie zamknięta Wyświetla ogólne informacje na temat SNMP Wyświetla szczegółowy opis obecnej sesji Wyświetla informacje na temat oczekujących zapytań

63 7 Projekt - Implementacja protokołu SNMPv1 7.1 Założenia projektowe Celem projektu było zaimplementowanie protokołu SNMP w wersji pierwszej (SNMPv1), opierając się na specyfikacji zawartej w dokumentach RFC oraz opisie ASN.1 i kodowaniu BER. Lista przedstawiona poniżej zawiera najważniejsze problemy oraz zagadnienia projektu: implementacja struktur, zmiennych oraz stałych opisanych w [RFC 1155] oraz [RFC 1157], implementacja funkcjonalności związanej z kodowaniem i dekodowaniem BER, utworzenie prawidłowej wiadomości SNMP, utworzenie MIB browser a pozwalającego w prosty sposób wybierać odpowiednie OID, utworzenie prostego oraz przejrzystego interfejsu użytkownika, implementacja mechanizmów sieciowych pozwalających na wysyłanie zapytań, odbieranie odpowiedzi oraz pułapek (TRAP). 7.2 Opis projektu Pierwsza część opisu projektu będzie zawierała szczegóły dotyczące implementacji. Następnie omówiony zostanie interfejs graficzny oraz posługiwanie się samym programem. Podstawowym problemem podczas implementacji SNMP jest prawidłowe przeniesienie definicji typów, struktur oraz stałych zdefiniowanych w dokumencie RFC 1155 oraz 1157 przy pomocy notacji ANS.1 do języka C/C++. Listing 5 zawiera definicję typów zdefiniowaną w RFC 1155 w rozdziale 6. Listing 5. ObjectSyntax ::= CHOICE { simple SimpleSyntax, application-wide ApplicationSyntax } SimpleSyntax ::= CHOICE { number INTEGER, string OCTET STRING, object OBJECT IDENTIFIER, empty NULL } ApplicationSyntax ::= CHOICE {

64 } address counter gauge ticks arbitrary NetworkAddress, Counter, Gauge, TimeTicks, Opaque NetworkAddress ::= CHOICE { internet IpAddress } IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER ( ) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER ( ) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER ( ) Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING Odwzorowanie w/w definicji w języku C/C++ przedstawione zostało na Listingu 6 (plik: smi.h). Oczywiście istnieją inne możliwości takiego odwzorowania, niemniej niniejsza implementacja bazuje tylko na tych zawartych w Listingu 6. Listing 6. //<!--SimpleSyntax from SMI typedef unsigned char smibyte; typedef smibyte sminull; typedef long smiint; typedef unsigned long smiuint; //--> //<!-- OBJECT IDENTIFIER typedef struct { smiuint len; smiuint *ptr; } smioid; //--> //<!--OCTET STRING typedef struct { smiuint smibyte } smioctet; //--> len; *ptr; //<!--ApplicationSyntax from smi typedef smiuint smicounter; typedef smiuint smigauge; typedef smiuint smitimeticks; typedef smioctet smiopaque; typedef smioctet smiipaddress; typedef smiipaddress sminetworkaddress; //--> //<!--ObjectSyntax typedef struct { smiint syntax; //type of value union { //value, depend on type smiint number; //this is a SimpleSyntax

65 smiuint smioctet sminull smioid } value; } ObjectSyntax; unumber; string; empty; object; W pliku smi.h znaleźć można również implementację struktur zdefiniowanych w dokumencie RFC Dokument ten definiuje strukturę budowy PDU oraz samej wiadomości SNMP. Listingi 8 oraz 9 przedstawiają definicję tych struktur w ASN.1 oraz C/C++. Listing 7. Message ::= SEQUENCE { version INTEGER {version-1(0)}, community OCTET STRING, data ANY } PDUs ::= CHOICE { get-request GetRequest-PDU, get-next-request GetNextRequest-PDU, get-response GetResponse-PDU, set-request SetRequest-PDU, trap Trap-PDU } PDU ::= SEQUENCE { request-id INTEGER, error-status INTEGER {noerror(0),toobig(1),nosuchname(2), badvalue(3),readonly(4),generr(5)}, error-index INTEGER, variable-bindings VarBindList } Trap-PDU ::= [4] IMPLICIT SEQUENCE { enterprise OBJECT IDENTIFIER, agent-addr NetworkAddress, generic-trap INTEGER {coldstart(0),warmstart(1),linkdown(2), linkup(3),authenticationfailure(4), egpneighborloss(5), enterprisespecific(6)}, specific-trap INTEGER, time-stamp TimeTicks, variable-bindings VarBindList } VarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } VarBindList ::= SEQUENCE OF VarBind Listing 8. //<!--varbind typedef struct { smioid ObjectSyntax } VarBind; name; value;

66 //--> //<!--VarBindList typedef struct VarList { VarBind curr; //currect position VarList *next; //next position, if there is no more NULL } VarList; //--> typedef enum { noerror = 0, toobig = 1, nosuchname = 2, badvalue = 3, readonly = 4, generr = 5 } ErrorStatus; typedef enum { coldstart = 0, warmstart = 1, linkdown = 2, linkup = 3, authfailegpneighloss = 4, egpneiloss = 5, enterspec = 6 } GenericTrap; //<!--SNMP PDU typedef struct { smiint command; //type of command trap, get, getnext, set, resp smiuint request_id; //random number ErrorStatus error_status; smiuint error_index; smioid enterprise; sminetworkaddress address; GenericTrap trap_type; smiint specific_trap; smiuint time_stamp; VarList *var; //variable-binding } pdu; //--> //<!--SNMP Message typedef struct { smiint version; //version of protocol, in our case is version 1 smioctet community; //name of community pdu *PDU; //SNMP PDU (protocol data unit) } SnmpMessage; //--> Tabela 12 zawiera krótki opis pozostałych plików nagłówkowych składających się na projekt. Plik Opis Ber.h Zawiera funkcje wykorzystywane podczas kodowania/dekodowania BER. common.h Zawiera zbiór pomocniczych funkcji służących do konwersji oraz do produkcji specjalnych napisów (stringów) wyświetlanych później w oknie

67 dialogowym. detailsdlg.h Okno dialogowe, służące do wyświetlania informacji na temat wiadomości. mibdlg.h Okno MIB browser a. mysnmp.h Zbiór funkcji używanych do tworzenia wiadomości SNMP. sendingdlg.h Okno dialogowe wysyłające zapytanie do agenta, odbierające wiadomość od niego oraz pokazujące szczegółowe informacje na temat odebranych danych. smi.h Implementacja typów, struktur oraz stałych zdefiniowanych w RFC 1155, smifun.h Funkcje inicjalizacyjne. snmpdec.h Funkcje używane do dekodowania wiadomości SNMP. snmpenc.h Funkcje używane do kodowania wiadomości SNMP. snmplen.h Funkcje obliczające długość zmiennej, wykorzystywaną w kodowaniu BER. snmp_object.h Deklaracja klasy CSNMP_Object. threadsend.h Deklaracja klasy CthreadSend, służącej do wysyłania wiadomości i odbierania odpowiedzi SNMP. threadtrap.h Deklaracja klasy CThreadTrap, odpowiadającej za obsługę powiadomień. Tabela 12. Opis najważniejszych plików nagłówkowych Oczywiście sama implementacja typów to za mało, aby zbudować poprawną wiadomość SNMP. Potrzebujemy jeszcze funkcji, które odpowiednio zakodują/rozkodują typy ASN.1 oraz zbudują z nich pełną wiadomość, którą będzie można umieścić w pakiecie UDP i wysłać przez sieć. Rysunek 35 przedstawia w sposób poglądowy dowolny typ ASN.1 (w tym przypadku posiadający długość jednego oktetu) oraz grupuje funkcje, które wykorzystywane są podczas kodowania/dekodowania BER w funkcjonalne bloki odpowiedzialne za poszczególne części składowe danego typu. BER_SetNull(), BER_GetNull(), BER_SetOID(), BER_GetOID(), BER_SetOctetStr(), BER_GetOctetStr(),etc. BER_GetHeader(), BER_SetHeader() BER_GetClass() BER_SetClass() BER_GetEncod() BER_SetEncod() BER_GetTag() BER_SetTag() BER_GetLen() BER_GetLen() Klasa Kodowanie Etykieta (tag) oktet typu T (tag octet) Długość Wartość Rysunek 35. Kodowanie BER

68 Pierwszym blokiem (bazowym) jest blok odnoszący się do konkretnego typu ASN.1. Blok jest niczym innym jak funkcją odpowiedzialną za proces kodowania BER danego typu ASN.1. W nim zawierają się pozostałe. Blok bazowy odpowiedzialny jest za poprawne zakodowanie wartości oraz za wywołanie bloku odpowiedzialnego za utworzenie nagłówka, w którym wyróżnić można dwie części odpowiedzialne za: poprawne zakodowanie długości, utworzenie nagłówka typu, w którego skład wchodzą bloki: klasy, kodowania oraz etykiety. Takie podejście pozwala łatwo dodać nowe typy, jak również zoptymalizować kod lub poprawić ewentualne błędy implementacyjne poprzez modyfikację niewielkiego kawałka kodu. Dla przykładu zostanie rozpatrzona funkcja służąca do kodowania OID. Jej deklarację przedstawia Listing 9. Listing 9. int BER_SetOID(BER *data, smioid, *oid, int &ptr_val); Parametrami funkcji są: wskaźnik na bufor, w którym mają być zapisane zakodowane dane (*data), wskaźnik do struktury zawierającej OID, który ma zostać zakodowany (*oid) oraz referencje, która będzie wskazywała ostatnią pozycję w buforze. Listing 10. bits = 0; orig = val; while(val > 0){ bits = (bits << 7) (val & 0x07F); val >>= 7; } val = 0; while(val!= orig){ tmp = (smibyte) bits & 0x07F; bits >>= 7; val = (val << 7) tmp; if(val!= orig) tmp = (tmp & 0x7F) 0x80; *ptr_buf++ = tmp; } Algorytm działania funkcji został przedstawiony na Rysunku 37. Ciekawym zagadnieniem jest zapisanie wartości podidentyfikatora większej od 126 (8 bitów). Zgodnie ze standardem ASN.1 kodowanie wartości odbywa się tylko na siedmiu LSB

69 MSB wykorzystywany jest do stwierdzenia czy dana wartość podidentyfikatora mieści się w tym jednym oktecie (MSB wynosi 0) czy też nie (MSB wynosi 1). Rysunek 36. Odwracanie bitów Listing 10 przedstawia rozwiązanie tego problemu. Pierwsza pętla tworzy formę przejściową wartości (Rysunek 36), która polega na odwróceniu każdych 7 bitów. Następnie z formy przejściowej budowana jest już postać ostateczna (druga pętla), zapisana w buforze uwzględnieniem bitów kontrolnych. Rysunek 37. Algorytm

70 Dalsze szczegóły implementacyjne kodowania BER typów atomowych ASN.1 można znaleźć w dołączonych do opracowania kodach źródłowych. Warto zaznaczyć, że funkcje odpowiedzialne za kodowanie atomowych typów ASN.1 wywoływane są z funkcji SNMP_EncodSyntax(), która dokonuje wyboru odpowiedniej procedury kodowania w zależności od wartości pola syntax danego typu. Zgodnie ze specyfikacją protokołu SNMP zmienne zawarte w wiadomości mogą tworzyć listę (variable-bindings). Każda pozycja takiej struktury składa się z OID obiektu oraz z jego wartości. Najprostszą i jednocześnie najbardziej oczywistą implementacją tej struktury jest lista jednokierunkowa, zilustrowana na Rysunku 38. Każda pozycja przechowuje wartości typu: smioid typ przechowujący informację na temat OID, ObjectSyntax typ przechowujący informacje na temat typu danego obiektu oraz jego wartości. Rysunek 38. Lista VarBind Proces kodowania (dekodowania) pełnej wiadomości SNMP (PDU) jest dość skomplikowany i obszerny, dlatego też został on zilustrowany na schematycznych rysunkach (Rysunek 39 oraz Rysunek 40), które w połączeniu z kodem źródłowym powinny pomóc w zrozumieniu wykorzystanych mechanizmów. Warto zaznaczyć, że funkcja: SNMP_EncodeSyntax() korzysta bezpośrednio z atomowych funkcji kodowania BER

71 Rysunek 39. Kodowanie wiadomości SNMP

72 Rysunek 40. Dekodowanie wiadomości Druga część rozdziału opisuje interfejs użytkownika oraz funkcjonalność, dostępną z poziomu aplikacji. Sam interfejs użytkownika został tak zaprojektowany, aby możliwie najdokładniej i jednocześnie najprościej pokazać całą logikę opisaną w specyfikacji SNMP. Rysunek 41 przedstawia główne okno programu, w którym można wyróżnić następujące bloki funkcjonalne: Agent parameters (parametry agenta): zawiera adres IP agenta oraz port, na którym nasłuchuje on przychodzących wiadomości, dodatkowo znajduje się jeszcze pole (Timeout) mówiące o czasie oczekiwania na odpowiedź (SNMP nie specyfikuje

73 dokładnie tej wartości); Czas oczekiwania na odpowiedź podawany jest w milisekundach; Trap parameters (parametry odbioru pułapek): włącza obsługę odbierania powiadomień od agenta oraz ustawia port; Rysunek 41. GUI Send message (wysyłanie wiadomości): blok funkcyjny odpowiedzialny za skomponowanie i wysłanie wiadomości SNMP, zostanie omówiony w dalszej części opracowania; Received message (odebrane wiadomości): zawiera listę wiadomości (par zapytanie odpowiedź), które zostały wysłane i odebrane podczas pracy. Najbardziej złożoną częścią GUI jest fragment odpowiedzialny za wysyłanie wiadomości. Można wyróżnić w nim część odpowiadającą definicji VarBind z RFC 1157 (instancji obiektu), posiadającą pola: OID: identyfikator obiektu, Value: wartość, wykorzystywaną w czasie zapytań typu Set, w innych przypadkach pole może zawierać dowolną wartość, zgodną z typem obiektu (pole jest wymagane), bądź pozostać niewypełnione w przypadku wybrania typu zmiennej jako NULL,

74 Type of value: typ obiektu, który powinien odpowiadać typowi obiektu wskazanego przez OID; Warto podkreślić, że wyłącznie w przypadku wiadomości typu Set, typ obiektu wybranego musi być zgodny z rzeczywistym typem, inaczej zostanie zwrócony błąd. W przypadku odczytu danych (Get, GetNext) typ każdego obiektu można ustawić na NULL, w odpowiedzi dostaniemy prawidłowy typ oraz jego wartość. Jest to zgodne z specyfikacją SNMP. Do programu został dodany tzw. MIB Browser (Rysunek 42), ułatwiający przeglądanie drzewa MIB. Chcąc wybrać odpowiedni identyfikator obiektu oraz przypisany mu typ, wystarczy zaznaczyć go w oknie MIB Browser a, po czym kliknąc na przycisk OK. Pole OID oraz Type of value w głównym oknie programu zostanie automatycznie wypełnione. Rysunek 42. MIB browser MIB Browser nie ma na stałe zdefiniowanego drzewa, lecz przy każdym uruchomieniu programu parsuje on definicyjne pliki MIB, umieszczone w katalogu mibs. Nazwa każdego pliku definicyjnego, który ma zostać poddany przetwarzaniu, powinna zostać umieszczona w pliku: mibs/.index. Warto zaznaczyć w tym punkcie, iż duża liczba plików wydłuża znacznie czas uruchomienia samej aplikacji. Mechanizm parsowania plików definicyjnych pochodzi z dynamicznie dołączanej biblioteki libsnmp.dll, pochodzącej z projektu Net-Snmp. Listing 11 pokazuje definicje zaimportowanych funkcji. Dodatkowo zdefiniowano kilka nowych typów, które używane są przez zaimportowane funkcje (Listing 12)

75 Listing 11 extern "C" declspec(dllimport) void init_mib (); extern "C" declspec(dllimport) void init_mib_internals(void); extern "C" declspec(dllimport) struct tree *read_mib (const char *); extern "C" declspec(dllimport) int add_mibdir(char *dirname); extern "C" declspec(dllimport) int add_module_replacement( char *old_module, char *new_module, char *tag, int len); extern "C" declspec(dllimport) struct tree *read_module(char *name); extern "C" declspec(dllimport) struct tree *read_all_mibs(void); extern "C" declspec(dllimport) void shutdown_mib(void); Listing 12 #define TYPE_OTHER 0 #define TYPE_OBJID 1 #define TYPE_OCTETSTR 2 #define TYPE_INTEGER 3 #define TYPE_NETADDR 4 #define TYPE_IPADDR 5 #define TYPE_COUNTER 6 #define TYPE_GAUGE 7 #define TYPE_TIMETICKS 8 #define TYPE_OPAQUE 9 #define TYPE_NULL 10 #define TYPE_COUNTER64 11 #define TYPE_BITSTRING 12 #define TYPE_NSAPADDRESS 13 #define TYPE_UINTEGER 14 #define TYPE_UNSIGNED32 15 #define TYPE_INTEGER32 16 #define TYPE_SIMPLE_LAST 16 #define TYPE_TRAPTYPE 20 #define TYPE_NOTIFTYPE 21 #define TYPE_OBJGROUP 22 #define TYPE_NOTIFGROUP 23 #define TYPE_MODID 24 #define TYPE_AGENTCAP 25 #define TYPE_MODCOMP 26 /* * A tree in the format of the tree structure of the MIB. */ struct tree { struct tree *child_list; /* list of children of this node */ struct tree *next_peer; /* Next node in list of peers */ struct tree *next; /* Next node in hashed list of names */ struct tree *parent;

76 char *label; /* This node's textual name */ u_long subid; /* This node's integer subidentifier */ int modid; /* The module containing this node */ int number_modules; int *module_list; /* To handle multiple modules */ int tc_index; /* index into tclist (-1 if NA) */ int type; /* This node's object type */ int access; /* This nodes access */ int status; /* This nodes status */ struct enum_list *enums; /* (optional) list of enumerated */ /*integers */ struct range_list *ranges; struct index_list *indexes; char *augments; struct varbind_list *varbinds; char *hint; char *units; int (*printomat)(u_char **, size_t *, size_t *, int, struct variable_list *, struct enum_list *, const char *, const char *); void (*printer) (char *, struct variable_list *, struct enum_list *, const char *, const char *); /* Value printing function */ }; char *description; /* description (a quoted string) */ int reported; /* 1=report started in print_subtree */ char *defaultvalue; W bloku Send message znajduje się również pozycja List variables, która odpowiada strukturze VarList z dokumentów RFC. Dodawanie nowych elementów do tej listy odbywa się po naciśnięciu klawisza Add to list->. Mając zdefiniowaną listę zmiennych, wybrany typ wiadomości oraz ustawioną poprawną nazwę społeczności można wysłać zapytanie SNMP naciskając na klawisz Send SNMP Message. Po wykonaniu tej operacji pojawia się okno dialogowe ilustrujące cały proces wysyłania oraz odbierania wiadomości SNMP (Rysunek 43). Okno to można podzielić na dwie części: opisującą wysyłaną wiadomość (górna) zawiera informacje na temat adresu agenta, pokazuje typ wiadomości, nazwę społeczności, wysyłane obiekty oraz zakodowaną wiadomość SNMP,

77 pokazującą proces odbioru wiadomości oraz (jeśli nie wystąpił błąd) zdekodowaną odpowiedź. Rysunek 43. Okno dialogowe wysyłania wiadomości Najczęstszymi błędami, które mogą wystąpić podczas wysyłania wiadomości skutkującymi nieodebraniem odpowiedzi, są: zły adres agenta, agent nie został uruchomiony na odległym urządzeniu, domyślny port 161 został zmieniony na jakiś inny, docelowe urządzanie znajduje się za firewall em. Błędy te zgłaszane są dwoma komunikatami: Waiting for respond... Timeout!!!! oraz Waiting for respond... Error during receiving data!!! Pierwszy z nich oznacza, że odpowiedź nie przyszła w oczekiwanym czasie. Natomiast drugi oznacza, że podczas wywoływania funkcji bibliotecznej Receive() (Listing 13) został zwrócony błąd typu SOCKET_ERROR. Szczegóły można znaleźć w dokumentacji samej funkcji

78 Listing 13 virtual int CSocket::Receive( void* lpbuf, int nbuflen, int nflags = 0 ); Dodatkową funkcjonalnością programu jest możliwość zapamiętywania wysłanych/odebranych wiadomości oraz otrzymanych pułapek. Rysunek 44 przedstawia listę przechowywanych wiadomości. Rysunek 44. Przetworzone wiadomości Każda wyświetlana informacja przyjmuje postać: [czas i data] <info> Adres IP [Typ wiadomości] [Typ wiadomości] może przyjmować jedną z poniższych wartości: GET_REQ_MSG wiadomość typu Get, GETNEXT_REQ_MSG wiadomość typu GetNext, SET_REQ_MSG wiadomość typu Set, TRP_MSG pułapka (Trap), RSP_MSG odpowiedź (Response). Pole <info> jest specjalnym polem informacyjnym, zbudowanym wg. schematu pokazanego poniżej: <parametr 1> <parametr 2 - opcja> Pierwszy parametr jest wykorzystywany do identyfikacji wiadomości stosując kryterium: wiadomość wychodząca : <out>, wiadomość przychodząca: <in>, pułapka: <trap>

79 Jeśli pierwszy parametr jest różny od <trap>, wówczas drugi parametr określa nam czy wysłane zapytanie SNMP otrzymało odpowiedź <resp> czy też nie <no re> oraz czy przychodząca wiadomość jest odpowiedzią na wysłane zapytanie <answ>. Podejście takie jest podyktowane faktem przetrzymywania przez aplikację par typu zapytanie odpowiedź. Po podwójnym kliknięciu na dowolną pozycję z listy pojawi się okno (Rysunek 45) przedstawiające powiązane wiadomości. Rozwiązanie takie znacznie ułatwia późniejszą analizę danych. Rysunek 45. Okno powiązanych wiadomości Ostatnim elementem funkcjonalnym aplikacji jest możliwość odbierania pułapek. Po zaznaczeniu pola Enable traps (Rysunek 46), aplikacja będzie nasłuchiwała notyfikacji od agentów na wskazanym porcie. Rysunek 46. Uruchomienie usługi odbierającej pułapki Oczywistym jest, że dodatkowo trzeba skonfigurować samego agenta tak, aby przesyłał powiadomienia pod adres naszej aplikacji. Odebrane notyfikacje są dekodowane i umieszczane na liście wiadomości opisanej wyżej

80 7.3 Testy akceptacyjne Wstępne testy akceptacyjne zostały przeprowadzone na komputerze, na którym lokalnie został zainstalowany agent pochodzący z projektu Net-SNMP oraz standardowy agent dostępny w systemie operacyjnym Windows XP. Miały one na celu weryfikację poprawności działania kodowania BER oraz sprawdzenie pozostałej funkcjonalności aplikacji. Następnie cała procedura została powtórzona w oparciu o dwa komputery pracujące w sieci, z których jeden miał zainstalowanego i uruchomionego agenta. Ostatnim etapem było przetestowanie aplikacji wykorzystując do tego celu router Cisco (szczegółowy opis w rozdziale 9). Poniżej znajduje się wykaz wszystkich testów, które zostały przeprowadzone. Lp. Test Status 1 Uruchomienie programu Pozytywny 2 Zamknięcie programu Pozytywny 3 Ręczne wpisanie poprawnych danych w obszarze Variable binding Pozytywny oraz próba dodania ich do listy zmiennych 4 Ręczne wpisanie danych w obszarze Variable binding z błędnym OID Pozytywny oraz próba dodania ich do listy zmiennych 5 Ręczne wpisanie danych w obszarze Variable binding z błednie Pozytywny wybranym typem zmiennej i wpisana wartością oraz próba dodania ich do listy zmiennych 6 Uruchomienie MIB Browser a Pozytywny 7 Próba wybrania dowolnych obiektów przy pomocy MIB Browser a Pozytywny 8 Próba dodania kilku zmiennych do listy zmiennych Pozytywny 9 Usunięcie dowolnej pozycji z listy zmiennych Pozytywny 10 Próba wysłania zapytania typu Get do agenta (prawidłowy adres, Pozytywny prawidłowe dane - dowolne) sprawdzenie funkcjonalności aplikacji 11 Próba wysłania zapytania typu GetNext do agenta (prawidłowy adres, Pozytywny prawidłowe dane - dowolne) sprawdzenie funkcjonalności aplikacji 12 Próba wysłania zapytania typu Set do agenta (prawidłowy adres, Pozytywny prawidłowe dane - dowolne) sprawdzenie funkcjonalności aplikacji 13 Sprawdzenie poprawności implementacji protokołu SNMP. Wysłanie Pozytywny zapytania typu Get o jeden obiekt. Próba powtarzana jest dla każdego typu SMI. 14 Sprawdzenie poprawności implementacji protokołu SNMP. Wysłanie Pozytywny zapytania typu GetNext o jeden obiekt. Próba powtarzana jest dla każdego typu SMI. 15 Sprawdzenie poprawności implementacji protokołu SNMP. Wysłanie Pozytywny zapytania typu Set ustawiającego wartość tylko jednego obiektu. Próba powtarzana jest dla każdego typu SMI. 16 Sprawdzenie poprawności implementacji protokołu SNMP. Wysłanie Pozytywny wiadomości z listą zmiennych. Próba powtarzana dla każdego typu wiadomości. 17 Wysłanie zapytania o nieistniejący obiekt. Próba powtórzona dla Pozytywny

81 wszystkich typów wiadomości. 18 Sprawdzenie poprawności odbierania pułapek. Pozytywny 19 Próba wysłania dowolnej wiadomości do nieistniejącego hosta (lub Pozytywny nie posiadającego aktywnego agenta SNMP). 7.4 Podsumowanie Implementacja protokołu SNMPv1 pozwoliła w sposób praktyczny poznać i zrozumieć sam protokół, jak również zagadnienia z nim związane: ASN.1 oraz kodowanie BER. Aplikacja udostępnia prosty interfejs użytkownikowi, który zawiera jednak wszystkie szczegóły opisywane w protokole SNMPv1. Dodatkowym atutem jest wyświetlanie zakodowanej wiadomości przy użyciu BER a. Program ten może zostać użyty na zajęciach laboratoryjnych, wprowadzając studentów w tajniki samego SNMP, jak i notacji ASN.1. W przyszłości można rozszerzyć ten projekt o kolejne wersje SNMP

82 8 Projekt - Wizualne przedstawienie danych odczytywanych z routera Cisco 8.1 Założenia projektowe Głównym celem projektu, bazującym na implementacji protokołu SNMP omówionej w rozdziale 7, było przedstawienie użytkownikowi w formie graficznej danych odczytanych z routera Cisco (w ogólności dowolnego urządzenia wspierającego SNMPv1). Głównymi założenia projektu były: próba implementacji graficznych liczników, pozwalających w przejrzysty sposób wyświetlić dane użytkownikowi, prosty mechanizm pozwalający definiować obiekty, które będą podlegały monitorowaniu, napisanie prostej aplikacji, umożliwiającej zastosowanie w/w graficznych liczników pozwalających na monitorowanie dowolnych obiektów z bazy MIB. 8.2 Opis projektu Jak wspomniano we wstępie, projekt ten bazuje na implementacji SNMPv1, która została omówiona wcześniej, jak również na dwóch dodatkowych projektach: Davide a Calabro: CClockST v1.3 [33], Nic a Wilson a : Digital Display CStatic control [34]. Oryginalne źródła tych projektów zostały umieszczone na załączonej płycie. Należy zaznaczyć, że zostały one znacznie zmodyfikowane oraz poprawiono w nich kilka błędów. Klasa CStatic z MFC doskonale nadaje się jako klasa bazowa do budowy kolejnych kontrolek, pozwalając dodawać nową funkcjonalność. Dlatego też w niniejszym projekcie została ona również wykorzystana do tego celu. Pozostałe klasy dziedziczą po niej jak na Rysunku 47. Klasa CDummyConuter jest bardzo prostą klasą wywodzącą się bezpośrednio z CStatic. Listing 14 class CDummyCounter : public CStatic { public: int type; CDummyCounter(void); }; virtual ~CDummyCounter(void); virtual void ChangeFont(CFont* pfont, int size);

83 Listing 14 przedstawia deklarację tej klasy. Jedyną jej rolą jest udostępnienie interfejsu do pozostałych klas. Dzięki niej łatwe staje się również zarządzanie kolejnymi obiektami, które wywodząc się ze wspólnej klasy, mogą być przechowywane na wspólnej liście (Listing 15). Rysunek 47. Dziedziczenie Listing 15 typedef struct _CounterBind_T_ { smioid *oid; int type; CDummyCounter *counter; } CounterBind_T; list< CounterBind_T * > m_listcounters; Klasy CClockST oraz CClockCounter są klasami pomocniczymi. Klasa CClockCounterTitle udostępnia użytkownikowi kontrolkę, która wyświetla aktualną godzinę oraz datę (Rysunek 48). Rysunek 48. Kontrolka CClockCounterTitle

84 Klasy CDigitalCounter oraz CDigitalUCounter mogą zostać użyte do wyświetlenia na ekranie dowolnej liczby. CDigitalUCounter, może być użyty jedynie do wartości dodatnich (unsigned). Rysunek 49 ilustruje trzy rodzaje kontrolek, które udostępniają nam te klasy. Rysunek 49. Trzy rodzaje kotrolek typu CDigitalCounter/ CDigitalUCounter (style 0,1,2) Ostatnią nieopisaną klasą jest klasa CMatrixStatic. Klasa to może zostać użyta do wyświetlenia znaków alfanumerycznych (np. pochodzący z typu Octet String). Kontrolki uzyskane z tej klasy, mogą posiadać trzy predefiniowane rozmiary: tiny, small oraz large (Rysunek 50). Natomiast kolory (tła, zgaszonych punktów oraz zapalonych) mogą być definiowane dowolnie w postaci liczby szesnastkowej gdzie: 0xRRGGBB RR oznacza składową czerwoną, GG składową zieloną oraz BB stanowi składową niebieską danego koloru. Rysunek 50. Trzy dostępne rozmiary kontrolek klasy CMatrixStatic Główne okno aplikacji jest bardzo proste (Rysunek 51). Z menu dostępne są jedynie trzy opcje: zamknięcie aplikacji (Exit), otwarcie nowego pliku z definicjami kontrolek (Open), zmiana rozmiaru czcionek użytych do wyświetlenia tytułów powyżej każdej z kontrolek (Font properties). Pliki z definicjami kontrolek bazują na standardowych plikach inicjalizacyjnych Windowa (tzw. plikach *.ini). Pliki *.ini zawierają sekcje, a każda sekcja kilka par typu klucz wartość (Listing 16)

85 Rysunek 51. Główne okno aplikacji Więcej informacji na temat plików konfiguracyjnych można znaleźć na stronach Microsoft u. Listing 16 [sekcja] klucz=wartość Przetwarzaniem wczytanych plików zajmuje się klasa CSNMPFile. Każdy definicyjny plik musi zawierać sekcję [GENERAL]. Sekcja ta odpowiada za ogólne parametry oraz definiuje agenta, który będzie odpytywany. Tabela 13 zawiera opis kluczy występujących w tej sekcji. Klucz Opis address Adres IP agenta community Nazwa społeczności port Port time_req Czas pomiędzy kolejnymi zapytaniami (w milisekundach) repeat_no Liczba powtórzeń wysłania wiadomości przypadku nie uzyskania odpowiedzi od agenta. timeout Czas po jakim aplikacja uzna, że nie nadeszła odpowiedź (w milisekundach) snmp_ver Wersja SNMP (dla SNMPv1 pole poprzyjmuje wartość 0) controls_no Liczba kontrolek request_type Typ zapytania, możliwe tylko: get oraz getnext Tabela 13. Klucze w sekcji [GENERAL]

Simple Network Management Protocol

Simple Network Management Protocol Simple Network Management Protocol Simple Network Management Protocol Rozwój W miarę wzrostu rozmiarów, złożoności i niejednorodności sieci, wzrastają koszty zarządzania nimi. Aby kontrolować te koszty,

Bardziej szczegółowo

MODEL WARSTWOWY PROTOKOŁY TCP/IP

MODEL WARSTWOWY PROTOKOŁY TCP/IP MODEL WARSTWOWY PROTOKOŁY TCP/IP TCP/IP (ang. Transmission Control Protocol/Internet Protocol) protokół kontroli transmisji. Pakiet najbardziej rozpowszechnionych protokołów komunikacyjnych współczesnych

Bardziej szczegółowo

Protokoły sieciowe - TCP/IP

Protokoły sieciowe - TCP/IP Protokoły sieciowe Protokoły sieciowe - TCP/IP TCP/IP TCP/IP (Transmission Control Protocol / Internet Protocol) działa na sprzęcie rożnych producentów może współpracować z rożnymi protokołami warstwy

Bardziej szczegółowo

Stos protokołów TCP/IP (ang. Transmission Control Protocol/Internet Protocol)

Stos protokołów TCP/IP (ang. Transmission Control Protocol/Internet Protocol) Stos protokołów TCP/IP (ang. Transmission Control Protocol/Internet Protocol) W latach 1973-78 Agencja DARPA i Stanford University opracowały dwa wzajemnie uzupełniające się protokoły: połączeniowy TCP

Bardziej szczegółowo

Wprowadzenie Management Information Base (MIB) Simple Network Management Protocol (SNMP) Polecenia SNMP Narzędzia na przykładzie MIB Browser (GUI)

Wprowadzenie Management Information Base (MIB) Simple Network Management Protocol (SNMP) Polecenia SNMP Narzędzia na przykładzie MIB Browser (GUI) Wprowadzenie Management Information Base (MIB) Simple Network Management Protocol (SNMP) Polecenia SNMP Narzędzia na przykładzie MIB Browser (GUI) () SNMP - Protokół zarządzania sieciami TCP/IP. - UDP

Bardziej szczegółowo

Zarządzanie sieciami komputerowymi - wprowadzenie

Zarządzanie sieciami komputerowymi - wprowadzenie Zarządzanie sieciami komputerowymi - wprowadzenie Model zarządzania SNMP SNMP standardowy protokół zarządzania w sieci Internet stosowany w dużych sieciach IP (alternatywa logowanie i praca zdalna w każdej

Bardziej szczegółowo

Przesyłania danych przez protokół TCP/IP

Przesyłania danych przez protokół TCP/IP Przesyłania danych przez protokół TCP/IP PAKIETY Protokół TCP/IP transmituje dane przez sieć, dzieląc je na mniejsze porcje, zwane pakietami. Pakiety są często określane różnymi terminami, w zależności

Bardziej szczegółowo

Zarządzanie infrastrukturą sieciową Modele funkcjonowania sieci

Zarządzanie infrastrukturą sieciową Modele funkcjonowania sieci W miarę rozwoju sieci komputerowych pojawiały się różne rozwiązania organizujące elementy w sieć komputerową. W celu zapewnienia kompatybilności rozwiązań różnych producentów oraz opartych na różnych platformach

Bardziej szczegółowo

Protokół zarządzania siecią SNMP

Protokół zarządzania siecią SNMP Protokół zarządzania siecią SNMP Simple Network Management Protocol 3. (RFC 3411-3418). Starsze Wersje: SNMP 1, SNMP 2 SNMP jest protokołem wykorzystywanym do zarządzania różnymi elementami sieci (np.

Bardziej szczegółowo

Laboratorium 1. Wprowadzenie do protokołu SNMP i kodowanie BER (ASN.1)

Laboratorium 1. Wprowadzenie do protokołu SNMP i kodowanie BER (ASN.1) Laboratorium 1. Wprowadzenie do protokołu SNMP i kodowanie BER (ASN.1) Celem laboratorium jest poznanie przez studenta podstawowego sposobu kodowania (BER), który jest wykorzystywany przez protokół SNMP.

Bardziej szczegółowo

Model OSI. mgr inż. Krzysztof Szałajko

Model OSI. mgr inż. Krzysztof Szałajko Model OSI mgr inż. Krzysztof Szałajko Protokół 2 / 26 Protokół Def.: Zestaw reguł umożliwiający porozumienie 3 / 26 Komunikacja w sieci 101010010101101010101 4 / 26 Model OSI Open Systems Interconnection

Bardziej szczegółowo

Podstawy Transmisji Danych. Wykład IV. Protokół IPV4. Sieci WAN to połączenia pomiędzy sieciami LAN

Podstawy Transmisji Danych. Wykład IV. Protokół IPV4. Sieci WAN to połączenia pomiędzy sieciami LAN Podstawy Transmisji Danych Wykład IV Protokół IPV4 Sieci WAN to połączenia pomiędzy sieciami LAN 1 IPv4/IPv6 TCP (Transmission Control Protocol) IP (Internet Protocol) ICMP (Internet Control Message Protocol)

Bardziej szczegółowo

Warstwy i funkcje modelu ISO/OSI

Warstwy i funkcje modelu ISO/OSI Warstwy i funkcje modelu ISO/OSI Organizacja ISO opracowała Model Referencyjny Połączonych Systemów Otwartych (model OSI RM - Open System Interconection Reference Model) w celu ułatwienia realizacji otwartych

Bardziej szczegółowo

ARP Address Resolution Protocol (RFC 826)

ARP Address Resolution Protocol (RFC 826) 1 ARP Address Resolution Protocol (RFC 826) aby wysyłać dane tak po sieci lokalnej, jak i pomiędzy różnymi sieciami lokalnymi konieczny jest komplet czterech adresów: adres IP nadawcy i odbiorcy oraz adres

Bardziej szczegółowo

Zestaw ten opiera się na pakietach co oznacza, że dane podczas wysyłania są dzielone na niewielkie porcje. Wojciech Śleziak

Zestaw ten opiera się na pakietach co oznacza, że dane podczas wysyłania są dzielone na niewielkie porcje. Wojciech Śleziak Protokół TCP/IP Protokół TCP/IP (Transmission Control Protokol/Internet Protokol) to zestaw trzech protokołów: IP (Internet Protokol), TCP (Transmission Control Protokol), UDP (Universal Datagram Protokol).

Bardziej szczegółowo

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0> Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą

Bardziej szczegółowo

ZiMSK NAT, PAT, ACL 1

ZiMSK NAT, PAT, ACL 1 ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ dr inż. Artur Sierszeń, asiersz@kis.p.lodz.pl dr inż. Andrzej Frączyk, a.fraczyk@kis.p.lodz.pl NAT, PAT, ACL 1 Wykład Translacja

Bardziej szczegółowo

Marek Parfieniuk, Tomasz Łukaszuk, Tomasz Grześ. Symulator zawodnej sieci IP do badania aplikacji multimedialnych i peer-to-peer

Marek Parfieniuk, Tomasz Łukaszuk, Tomasz Grześ. Symulator zawodnej sieci IP do badania aplikacji multimedialnych i peer-to-peer Marek Parfieniuk, Tomasz Łukaszuk, Tomasz Grześ Symulator zawodnej sieci IP do badania aplikacji multimedialnych i peer-to-peer Plan prezentacji 1. Cel projektu 2. Cechy systemu 3. Budowa systemu: Agent

Bardziej szczegółowo

Sieci Komputerowe Modele warstwowe sieci

Sieci Komputerowe Modele warstwowe sieci Sieci Komputerowe Modele warstwowe sieci mgr inż. Rafał Watza Katedra Telekomunikacji AGH Al. Mickiewicza 30, 30-059 Kraków, Polska tel. +48 12 6174034, fax +48 12 6342372 e-mail: watza@kt.agh.edu.pl Wprowadzenie

Bardziej szczegółowo

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych Wykład 2: Budowanie sieci lokalnych 1 Budowanie sieci lokalnych Technologie istotne z punktu widzenia konfiguracji i testowania poprawnego działania sieci lokalnej: Protokół ICMP i narzędzia go wykorzystujące

Bardziej szczegółowo

Sieci Komputerowe. Wykład 1: TCP/IP i adresowanie w sieci Internet

Sieci Komputerowe. Wykład 1: TCP/IP i adresowanie w sieci Internet Sieci Komputerowe Wykład 1: TCP/IP i adresowanie w sieci Internet prof. nzw dr hab. inż. Adam Kisiel kisiel@if.pw.edu.pl Pokój 114 lub 117d 1 Kilka ważnych dat 1966: Projekt ARPANET finansowany przez DOD

Bardziej szczegółowo

Protokoły sieciowe model ISO-OSI Opracował: Andrzej Nowak

Protokoły sieciowe model ISO-OSI Opracował: Andrzej Nowak Protokoły sieciowe model ISO-OSI Opracował: Andrzej Nowak OSI (ang. Open System Interconnection) lub Model OSI to standard zdefiniowany przez ISO oraz ITU-T, opisujący strukturę komunikacji sieciowej.

Bardziej szczegółowo

Model sieci OSI, protokoły sieciowe, adresy IP

Model sieci OSI, protokoły sieciowe, adresy IP Model sieci OSI, protokoły sieciowe, adresy IP Podstawę działania internetu stanowi zestaw protokołów komunikacyjnych TCP/IP. Wiele z używanych obecnie protokołów zostało opartych na czterowarstwowym modelu

Bardziej szczegółowo

Dr Michał Tanaś(http://www.amu.edu.pl/~mtanas)

Dr Michał Tanaś(http://www.amu.edu.pl/~mtanas) Dr Michał Tanaś(http://www.amu.edu.pl/~mtanas) Protokół komunikacyjny zapewniający niezawodność przesyłania danych w sieci IP Gwarantuje: Przyporządkowanie danych do konkretnego połączenia Dotarcie danych

Bardziej szczegółowo

Plan wykładu. 1. Sieć komputerowa 2. Rodzaje sieci 3. Topologie sieci 4. Karta sieciowa 5. Protokoły używane w sieciach LAN 6.

Plan wykładu. 1. Sieć komputerowa 2. Rodzaje sieci 3. Topologie sieci 4. Karta sieciowa 5. Protokoły używane w sieciach LAN 6. Plan wykładu 1. Sieć komputerowa 2. Rodzaje sieci 3. Topologie sieci 4. Karta sieciowa 5. Protokoły używane w sieciach LAN 6. Modem analogowy Sieć komputerowa Siecią komputerową nazywa się grupę komputerów

Bardziej szczegółowo

Sieci komputerowe. Zajęcia 3 c.d. Warstwa transportu, protokoły UDP, ICMP

Sieci komputerowe. Zajęcia 3 c.d. Warstwa transportu, protokoły UDP, ICMP Sieci komputerowe Zajęcia 3 c.d. Warstwa transportu, protokoły UDP, ICMP Zadania warstwy transportu Zapewnienie niezawodności Dostarczanie danych do odpowiedniej aplikacji w warstwie aplikacji (multipleksacja)

Bardziej szczegółowo

Sieci komputerowe - administracja

Sieci komputerowe - administracja Sieci komputerowe - administracja warstwa sieciowa Andrzej Stroiński andrzej.stroinski@cs.put.edu.pl http://www.cs.put.poznan.pl/astroinski/ warstwa sieciowa 2 zapewnia adresowanie w sieci ustala trasę

Bardziej szczegółowo

SIECI KOMPUTEROWE Adresowanie IP

SIECI KOMPUTEROWE  Adresowanie IP Adresowanie IP Podstawowa funkcja protokołu IP (Internet Protocol) polega na dodawaniu informacji o adresie do pakietu danych i przesyłaniu ich poprzez sieć do właściwych miejsc docelowych. Aby umożliwić

Bardziej szczegółowo

Dr Michał Tanaś(http://www.amu.edu.pl/~mtanas)

Dr Michał Tanaś(http://www.amu.edu.pl/~mtanas) Dr Michał Tanaś(http://www.amu.edu.pl/~mtanas) Jest to zbiór komputerów połączonych między sobą łączami telekomunikacyjnymi, w taki sposób że Możliwa jest wymiana informacji (danych) pomiędzy komputerami

Bardziej szczegółowo

Rywalizacja w sieci cd. Protokoły komunikacyjne. Model ISO. Protokoły komunikacyjne (cd.) Struktura komunikatu. Przesyłanie między warstwami

Rywalizacja w sieci cd. Protokoły komunikacyjne. Model ISO. Protokoły komunikacyjne (cd.) Struktura komunikatu. Przesyłanie między warstwami Struktury sieciowe Struktury sieciowe Podstawy Topologia Typy sieci Komunikacja Protokoły komunikacyjne Podstawy Topologia Typy sieci Komunikacja Protokoły komunikacyjne 15.1 15.2 System rozproszony Motywacja

Bardziej szczegółowo

ZiMSK. VLAN, trunk, intervlan-routing 1

ZiMSK. VLAN, trunk, intervlan-routing 1 ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ dr inż. Artur Sierszeń, asiersz@kis.p.lodz.pl dr inż. Andrzej Frączyk, a.fraczyk@kis.p.lodz.pl VLAN, trunk, intervlan-routing

Bardziej szczegółowo

Zarządzanie ruchem w sieci IP. Komunikat ICMP. Internet Control Message Protocol DSRG DSRG. DSRG Warstwa sieciowa DSRG. Protokół sterujący

Zarządzanie ruchem w sieci IP. Komunikat ICMP. Internet Control Message Protocol DSRG DSRG. DSRG Warstwa sieciowa DSRG. Protokół sterujący Zarządzanie w sieci Protokół Internet Control Message Protocol Protokół sterujący informacje o błędach np. przeznaczenie nieosiągalne, informacje sterujące np. przekierunkowanie, informacje pomocnicze

Bardziej szczegółowo

Uniwersalny Konwerter Protokołów

Uniwersalny Konwerter Protokołów Uniwersalny Konwerter Protokołów Autor Robert Szolc Promotor dr inż. Tomasz Szczygieł Uniwersalny Konwerter Protokołów Szybki rozwój technologii jaki obserwujemy w ostatnich latach, spowodował że systemy

Bardziej szczegółowo

Laboratorium - Przechwytywanie i badanie datagramów DNS w programie Wireshark

Laboratorium - Przechwytywanie i badanie datagramów DNS w programie Wireshark Laboratorium - Przechwytywanie i badanie datagramów DNS w programie Wireshark Topologia Cele Część 1: Zapisanie informacji dotyczących konfiguracji IP komputerów Część 2: Użycie programu Wireshark do przechwycenia

Bardziej szczegółowo

Pytanie 1 Z jakich protokołów korzysta usługa WWW? (Wybierz prawidłowe odpowiedzi)

Pytanie 1 Z jakich protokołów korzysta usługa WWW? (Wybierz prawidłowe odpowiedzi) Pytanie 1 Z jakich protokołów korzysta usługa WWW? (Wybierz prawidłowe odpowiedzi) Pytanie 2 a) HTTPs, b) HTTP, c) POP3, d) SMTP. Co oznacza skrót WWW? a) Wielka Wyszukiwarka Wiadomości, b) WAN Word Works,

Bardziej szczegółowo

Sieci komputerowe - Wstęp do intersieci, protokół IPv4

Sieci komputerowe - Wstęp do intersieci, protokół IPv4 Piotr Kowalski KAiTI Internet a internet - Wstęp do intersieci, protokół IPv Plan wykładu Informacje ogólne 1. Ogólne informacje na temat sieci Internet i protokołu IP (ang. Internet Protocol) w wersji.

Bardziej szczegółowo

Wybrane Zagadnienia Administrowania Sieciami. Dr inż. Robert Banasiak

Wybrane Zagadnienia Administrowania Sieciami. Dr inż. Robert Banasiak Wybrane Zagadnienia Administrowania Sieciami Dr inż. Robert Banasiak 1 Gryplan Protokół SNMP Protokół RMON i IPFIX Wybrane protokoły warstwy aplikacji Obserwacja stosu protokołów modelu ISO OSI 2 SNMP

Bardziej szczegółowo

Institute of Telecommunications. koniec wykładu V. mariusz@tele.pw.edu.pl

Institute of Telecommunications. koniec wykładu V. mariusz@tele.pw.edu.pl koniec wykładu V operacje na wierszu tablicy wymagania MAX-ACCESS= read-create obecność kolumny typu RowStatus operacje tworzenie (creation) zawieszanie (suspension) SetRequest( RowStatus= notinservice)

Bardziej szczegółowo

Tworzenie i obsługa wirtualnego laboratorium komputerowego

Tworzenie i obsługa wirtualnego laboratorium komputerowego Uniwersytet Mikołaja Kopernika Wydział Fizyki, Astronomii i Informatyki Stosowanej Michał Ochociński nr albumu: 236401 Praca magisterska na kierunku informatyka stosowana Tworzenie i obsługa wirtualnego

Bardziej szczegółowo

PBS. Wykład Zabezpieczenie przełączników i dostępu do sieci LAN

PBS. Wykład Zabezpieczenie przełączników i dostępu do sieci LAN PBS Wykład 7 1. Zabezpieczenie przełączników i dostępu do sieci LAN mgr inż. Roman Krzeszewski roman@kis.p.lodz.pl mgr inż. Artur Sierszeń asiersz@kis.p.lodz.pl mgr inż. Łukasz Sturgulewski luk@kis.p.lodz.pl

Bardziej szczegółowo

Podstawy Informatyki. Inżynieria Ciepła, I rok. Wykład 13 Topologie sieci i urządzenia

Podstawy Informatyki. Inżynieria Ciepła, I rok. Wykład 13 Topologie sieci i urządzenia Podstawy Informatyki Inżynieria Ciepła, I rok Wykład 13 Topologie sieci i urządzenia Topologie sieci magistrali pierścienia gwiazdy siatki Zalety: małe użycie kabla Magistrala brak dodatkowych urządzeń

Bardziej szczegółowo

1 Moduł Diagnostyki Sieci

1 Moduł Diagnostyki Sieci 1 Moduł Diagnostyki Sieci Moduł Diagnostyki Sieci daje użytkownikowi Systemu Vision możliwość badania dostępności w sieci Ethernet komputera lub innych urządzeń wykorzystujących do połączenia protokoły

Bardziej szczegółowo

Referencyjny model OSI. 3 listopada 2014 Mirosław Juszczak 37

Referencyjny model OSI. 3 listopada 2014 Mirosław Juszczak 37 Referencyjny model OSI 3 listopada 2014 Mirosław Juszczak 37 Referencyjny model OSI Międzynarodowa Organizacja Normalizacyjna ISO (International Organization for Standarization) opracowała model referencyjny

Bardziej szczegółowo

Rys. 1. Wynik działania programu ping: n = 5, adres cyfrowy. Rys. 1a. Wynik działania programu ping: l = 64 Bajty, adres mnemoniczny

Rys. 1. Wynik działania programu ping: n = 5, adres cyfrowy. Rys. 1a. Wynik działania programu ping: l = 64 Bajty, adres mnemoniczny 41 Rodzaje testów i pomiarów aktywnych ZAGADNIENIA - Jak przeprowadzać pomiary aktywne w sieci? - Jak zmierzyć jakość usług sieciowych? - Kto ustanawia standardy dotyczące jakości usług sieciowych? - Jakie

Bardziej szczegółowo

Konspekt: Bezpieczeństwo w zarządzaniu systemami i sieciami. Autorzy: Grzegorz Dębiec, Edyta Gąsior, Łukasz Krzanik, Maciej Tokarczyk DUMF

Konspekt: Bezpieczeństwo w zarządzaniu systemami i sieciami. Autorzy: Grzegorz Dębiec, Edyta Gąsior, Łukasz Krzanik, Maciej Tokarczyk DUMF Konspekt: Bezpieczeństwo w zarządzaniu systemami i sieciami Autorzy: Grzegorz Dębiec, Edyta Gąsior, Łukasz Krzanik, Maciej Tokarczyk DUMF 1 STRESZCZENIE Konspekt powstał na podstawie wykładu (28 maja 2002)

Bardziej szczegółowo

DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ

DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ PROTOKOŁY TCP I UDP WSTĘP DO SIECI INTERNET Kraków, dn. 12 grudnia 2016 r. PLAN TCP: cechy protokołu schemat nagłówka znane numery portów UDP: cechy protokołu

Bardziej szczegółowo

Adresy w sieciach komputerowych

Adresy w sieciach komputerowych Adresy w sieciach komputerowych 1. Siedmio warstwowy model ISO-OSI (ang. Open System Interconnection Reference Model) 7. Warstwa aplikacji 6. Warstwa prezentacji 5. Warstwa sesji 4. Warstwa transportowa

Bardziej szczegółowo

SIECI KOMPUTEROWE mgr inż. Adam Mencwal Katedra Informatyki Stosowanej

SIECI KOMPUTEROWE mgr inż. Adam Mencwal Katedra Informatyki Stosowanej SIECI KOMPUTEROWE mgr inż. Adam Mencwal Katedra Informatyki Stosowanej amencwal@kis.p.lodz.pl http://www.kis.p.lodz.pl/~amencwal/ Sieć komputerowa co to takiego? Sieć komputerowa - to grupa komputerów

Bardziej szczegółowo

Celem ćwiczenia jest zapoznanie się z zarządzaniem urządzeniami sieciowymi za pomocą protokołu SNMP.

Celem ćwiczenia jest zapoznanie się z zarządzaniem urządzeniami sieciowymi za pomocą protokołu SNMP. 1 Laboratorium SNMP 1.1 Cel ćwiczenia Celem ćwiczenia jest zapoznanie się z zarządzaniem urządzeniami sieciowymi za pomocą protokołu SNMP. 1.2 Informacje wstępne SNMP to protokół zarządzania siecią działającą

Bardziej szczegółowo

Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA. Dlaczego DNS jest tak ważny?

Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA. Dlaczego DNS jest tak ważny? Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA Dlaczego DNS jest tak ważny? DNS - System Nazw Domenowych to globalnie rozmieszczona usługa Internetowa. Zapewnia tłumaczenie nazw domen

Bardziej szczegółowo

Wykład Nr 4. 1. Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia

Wykład Nr 4. 1. Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia Sieci komputerowe Wykład Nr 4 1. Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia Sieci bezprzewodowe Sieci z bezprzewodowymi punktami dostępu bazują na falach radiowych. Punkt dostępu musi mieć

Bardziej szczegółowo

Politechnika Łódzka. Instytut Systemów Inżynierii Elektrycznej

Politechnika Łódzka. Instytut Systemów Inżynierii Elektrycznej Politechnika Łódzka Instytut Systemów Inżynierii Elektrycznej Laboratorium komputerowych systemów pomiarowych Ćwiczenie 7 Wykorzystanie protokołu TCP do komunikacji w komputerowym systemie pomiarowym 1.

Bardziej szczegółowo

Laboratorium 6.7.2: Śledzenie pakietów ICMP

Laboratorium 6.7.2: Śledzenie pakietów ICMP Topologia sieci Tabela adresacji Urządzenie Interfejs Adres IP Maska podsieci Domyślna brama R1-ISP R2-Central Serwer Eagle S0/0/0 10.10.10.6 255.255.255.252 Nie dotyczy Fa0/0 192.168.254.253 255.255.255.0

Bardziej szczegółowo

MODEL OSI A INTERNET

MODEL OSI A INTERNET MODEL OSI A INTERNET W Internecie przyjęto bardziej uproszczony model sieci. W modelu tym nacisk kładzie się na warstwy sieciową i transportową. Pozostałe warstwy łączone są w dwie warstwy - warstwę dostępu

Bardziej szczegółowo

Kierunek: technik informatyk 312[01] Semestr: II Przedmiot: Urządzenia techniki komputerowej Nauczyciel: Mirosław Ruciński

Kierunek: technik informatyk 312[01] Semestr: II Przedmiot: Urządzenia techniki komputerowej Nauczyciel: Mirosław Ruciński Kierunek: technik informatyk 312[01] Semestr: II Przedmiot: Urządzenia techniki komputerowej Nauczyciel: Mirosław Ruciński Temat 8.9. Wykrywanie i usuwanie awarii w sieciach komputerowych. 1. Narzędzia

Bardziej szczegółowo

ZiMSK. Routing statyczny, ICMP 1

ZiMSK. Routing statyczny, ICMP 1 ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ dr inż. Artur Sierszeń, asiersz@kis.p.lodz.pl dr inż. Andrzej Frączyk, a.fraczyk@kis.p.lodz.pl Routing statyczny, ICMP 1

Bardziej szczegółowo

System zarządzania i monitoringu

System zarządzania i monitoringu Załącznik nr 12 do Opisu przedmiotu zamówienia System zarządzania i monitoringu System zarządzania i monitoringu powinien być zbudowany z odrębnych, dedykowanych modułów oprogramowania, monitorujących:

Bardziej szczegółowo

Routing i protokoły routingu

Routing i protokoły routingu Routing i protokoły routingu Po co jest routing Proces przesyłania informacji z sieci źródłowej do docelowej poprzez urządzenie posiadające co najmniej dwa interfejsy sieciowe i stos IP. Routing przykład

Bardziej szczegółowo

SNMP, wersje 1, 2c i 3

SNMP, wersje 1, 2c i 3 SNMP, wersje 1, 2c i 3 SNMP v1 operacje zarządcy: get(oid1, OID2,..., OIDN) odczytanie wartości obiektu o zadanym identyfikatorze dla każdego argumentu getnext (OID1, OID2,..., OIDN) odczytanie identyfikatora

Bardziej szczegółowo

MASKI SIECIOWE W IPv4

MASKI SIECIOWE W IPv4 MASKI SIECIOWE W IPv4 Maska podsieci wykorzystuje ten sam format i sposób reprezentacji jak adresy IP. Różnica polega na tym, że maska podsieci posiada bity ustawione na 1 dla części określającej adres

Bardziej szczegółowo

Warstwa sieciowa. Model OSI Model TCP/IP. Aplikacji. Aplikacji. Prezentacji. Sesji. Transportowa. Transportowa

Warstwa sieciowa. Model OSI Model TCP/IP. Aplikacji. Aplikacji. Prezentacji. Sesji. Transportowa. Transportowa Warstwa sieciowa Model OSI Model TCP/IP Aplikacji Prezentacji Aplikacji podjęcie decyzji o trasowaniu (rutingu) na podstawie znanej, lokalnej topologii sieci ; - podział danych na pakiety Sesji Transportowa

Bardziej szczegółowo

SNMP PODSTAWOWE KOMPONENTY. Relacje między trzema głównymi komponentami

SNMP PODSTAWOWE KOMPONENTY. Relacje między trzema głównymi komponentami SNMP - WPROWADZENIE Simple Network Management Protocol (SNMP) jest protokołem warstwy aplikacji, który ułatwia wymianę informacji zarządzania miedzy urządzeniami sieciowymi. Został stworzony dla sieci

Bardziej szczegółowo

TCP/IP formaty ramek, datagramów, pakietów...

TCP/IP formaty ramek, datagramów, pakietów... SIECI KOMPUTEROWE DATAGRAM IP Protokół IP jest przeznaczony do sieci z komutacją pakietów. Pakiet jest nazywany przez IP datagramem. Każdy datagram jest podstawową, samodzielną jednostką przesyłaną w sieci

Bardziej szczegółowo

DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ

DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ INTERNET PROTOCOL (IP) INTERNET CONTROL MESSAGE PROTOCOL (ICMP) WSTĘP DO SIECI INTERNET Kraków, dn. 7 listopada 2016 r. PLAN IPv4: schemat nagłówka ICMP: informacje

Bardziej szczegółowo

Uproszczony opis obsługi ruchu w węźle IP. Trasa routingu. Warunek:

Uproszczony opis obsługi ruchu w węźle IP. Trasa routingu. Warunek: Uproszczony opis obsługi ruchu w węźle IP Poniższa procedura jest dokonywana dla każdego pakietu IP pojawiającego się w węźle z osobna. W routingu IP nie wyróżniamy połączeń. Te pojawiają się warstwę wyżej

Bardziej szczegółowo

Sieci komputerowe w sterowaniu informacje ogólne, model TCP/IP, protokoły warstwy internetowej i sieciowej

Sieci komputerowe w sterowaniu informacje ogólne, model TCP/IP, protokoły warstwy internetowej i sieciowej ieci komputerowe w sterowaniu informacje ogólne, model TCP/IP, protokoły warstwy internetowej i sieciowej 1969 ARPANET sieć eksperymentalna oparta na wymianie pakietów danych: - stabilna, - niezawodna,

Bardziej szczegółowo

Rok szkolny 2014/15 Sylwester Gieszczyk. Wymagania edukacyjne w technikum. SIECI KOMPUTEROWE kl. 2c

Rok szkolny 2014/15 Sylwester Gieszczyk. Wymagania edukacyjne w technikum. SIECI KOMPUTEROWE kl. 2c Wymagania edukacyjne w technikum SIECI KOMPUTEROWE kl. 2c Wiadomości Umiejętności Lp. Temat konieczne podstawowe rozszerzające dopełniające Zapamiętanie Rozumienie W sytuacjach typowych W sytuacjach problemowych

Bardziej szczegółowo

Wykład I. Wprowadzenie do baz danych

Wykład I. Wprowadzenie do baz danych Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles

Bardziej szczegółowo

OBSŁUGA I KONFIGURACJA SIECI W WINDOWS

OBSŁUGA I KONFIGURACJA SIECI W WINDOWS OBSŁUGA I KONFIGURACJA SIECI W WINDOWS Jak skonfigurować komputer pracujący pod kontrolą systemu operacyjnego Windows 7, tak aby uzyskać dostęp do internetu? Zakładamy, że komputer pracuje w małej domowej

Bardziej szczegółowo

Wykład 4: Protokoły TCP/UDP i usługi sieciowe. A. Kisiel,Protokoły TCP/UDP i usługi sieciowe

Wykład 4: Protokoły TCP/UDP i usługi sieciowe. A. Kisiel,Protokoły TCP/UDP i usługi sieciowe N, Wykład 4: Protokoły TCP/UDP i usługi sieciowe 1 Adres aplikacji: numer portu Protokoły w. łącza danych (np. Ethernet) oraz w. sieciowej (IP) pozwalają tylko na zaadresowanie komputera (interfejsu sieciowego),

Bardziej szczegółowo

PROGRAM PRAKTYKI ZAWODOWEJ. Technikum Zawód: technik informatyk

PROGRAM PRAKTYKI ZAWODOWEJ. Technikum Zawód: technik informatyk PROGRAM PRAKTYKI ZAWODOWEJ Technikum Zawód: technik informatyk 351203 Lp. Temat 1 Zajęcia wprowadzające. Zapoznanie z zakładem, regulaminem pracy, przepisami BHP oraz instruktaż bhp. 2 Montaż i eksploatacja

Bardziej szczegółowo

Akademickie Centrum Informatyki PS. Wydział Informatyki PS

Akademickie Centrum Informatyki PS. Wydział Informatyki PS kademickie Centrum Informatyki PS Wydział Informatyki PS Wydział Informatyki Sieci komputerowe i Telekomunikacyjne Transmisja w protokole IP Krzysztof ogusławski tel. 4 333 950 kbogu@man.szczecin.pl 1.

Bardziej szczegółowo

ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ DHCP

ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ DHCP ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ dr inż. Artur Sierszeń, asiersz@kis.p.lodz.pl dr inż. Andrzej Frączyk, a.fraczyk@kis.p.lodz.pl DHCP 1 Wykład Dynamiczna konfiguracja

Bardziej szczegółowo

Akademickie Centrum Informatyki PS. Wydział Informatyki PS

Akademickie Centrum Informatyki PS. Wydział Informatyki PS Akademickie Centrum Informatyki PS Wydział Informatyki PS Akademickie Centrum Informatyki Wydział Informatyki P.S. Warstwy transmisyjne Protokoły sieciowe Krzysztof Bogusławski tel. 449 41 82 kbogu@man.szczecin.pl

Bardziej szczegółowo

DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ ADRESACJA W SIECIACH IP. WSTĘP DO SIECI INTERNET Kraków, dn. 24 października 2016r.

DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ ADRESACJA W SIECIACH IP. WSTĘP DO SIECI INTERNET Kraków, dn. 24 października 2016r. DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ ADRESACJA W SIECIACH IP WSTĘP DO SIECI INTERNET Kraków, dn. 24 października 2016r. PLAN Reprezentacja liczb w systemach cyfrowych Protokół IPv4 Adresacja w sieciach

Bardziej szczegółowo

Zadania z sieci Rozwiązanie

Zadania z sieci Rozwiązanie Zadania z sieci Rozwiązanie Zadanie 1. Komputery połączone są w sieci, z wykorzystaniem routera zgodnie ze schematem przedstawionym poniżej a) Jak się nazywa ten typ połączenia komputerów? (topologia sieciowa)

Bardziej szczegółowo

POŁĄCZENIE STEROWNIKÓW ASTRAADA ONE MIĘDZY SOBĄ Z WYKORZYSTANIEM PROTOKOŁU UDP. Sterowniki Astraada One wymieniają między sobą dane po UDP

POŁĄCZENIE STEROWNIKÓW ASTRAADA ONE MIĘDZY SOBĄ Z WYKORZYSTANIEM PROTOKOŁU UDP. Sterowniki Astraada One wymieniają między sobą dane po UDP POŁĄCZENIE STEROWNIKÓW ASTRAADA ONE MIĘDZY SOBĄ Z WYKORZYSTANIEM PROTOKOŁU UDP Sterowniki Astraada One wymieniają między sobą dane po UDP Wstęp Celem informatora jest konfiguracja i przygotowanie sterowników

Bardziej szczegółowo

Enkapsulacja RARP DANE TYP PREAMBUŁA SFD ADRES DOCELOWY ADRES ŹRÓDŁOWY TYP SUMA KONTROLNA 2 B 2 B 1 B 1 B 2 B N B N B N B N B Typ: 0x0835 Ramka RARP T

Enkapsulacja RARP DANE TYP PREAMBUŁA SFD ADRES DOCELOWY ADRES ŹRÓDŁOWY TYP SUMA KONTROLNA 2 B 2 B 1 B 1 B 2 B N B N B N B N B Typ: 0x0835 Ramka RARP T Skąd dostać adres? Metody uzyskiwania adresów IP Część sieciowa Jeśli nie jesteśmy dołączeni do Internetu wyssany z palca. W przeciwnym przypadku numer sieci dostajemy od NIC organizacji międzynarodowej

Bardziej szczegółowo

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Infomatyki Stosowanej Piotr Benetkiewicz Nr albumu: 168455 Praca magisterska na kierunku Informatyka

Bardziej szczegółowo

Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Instytut Fizyki

Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Instytut Fizyki Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Instytut Fizyki Tomasz Pawłowski Nr albumu: 146956 Praca magisterska na kierunku

Bardziej szczegółowo

Wykaz zmian w programie SysLoger

Wykaz zmian w programie SysLoger Wykaz zmian w programie SysLoger Pierwsza wersja programu 1.0.0.1 powstała we wrześniu 2011. Funkcjonalność pierwszej wersji programu: 1. Zapis logów do pliku tekstowego, 2. Powiadamianie e-mail tylko

Bardziej szczegółowo

Skąd dostać adres? Metody uzyskiwania adresów IP. Statycznie RARP. Część sieciowa. Część hosta

Skąd dostać adres? Metody uzyskiwania adresów IP. Statycznie RARP. Część sieciowa. Część hosta Sieci komputerowe 1 Sieci komputerowe 2 Skąd dostać adres? Metody uzyskiwania adresów IP Część sieciowa Jeśli nie jesteśmy dołączeni do Internetu wyssany z palca. W przeciwnym przypadku numer sieci dostajemy

Bardziej szczegółowo

Laboratorium 6.7.1: Ping i Traceroute

Laboratorium 6.7.1: Ping i Traceroute Laboratorium 6.7.1: Ping i Traceroute Topologia sieci Tabela adresacji Urządzenie Interfejs Adres IP Maska podsieci Domyślna brama R1-ISP R2-Central Serwer Eagle S0/0/0 10.10.10.6 255.255.255.252 Nie dotyczy

Bardziej szczegółowo

Systemy operacyjne i sieci komputerowe Szymon Wilk Adresowanie w sieciach Klasy adresów IP a) klasa A

Systemy operacyjne i sieci komputerowe Szymon Wilk Adresowanie w sieciach Klasy adresów IP a) klasa A i sieci komputerowe Szymon Wilk Adresowanie w sieciach 1 1. Klasy adresów IP a) klasa A sieć host 0 mało sieci (1 oktet), dużo hostów (3 oktety) pierwszy bit równy 0 zakres adresów dla komputerów 1.0.0.0-127.255.255.255

Bardziej szczegółowo

ZiMSK. Charakterystyka urządzeń sieciowych: Switch, Router, Firewall (v.2012) 1

ZiMSK. Charakterystyka urządzeń sieciowych: Switch, Router, Firewall (v.2012) 1 ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ dr inż. Artur Sierszeń, asiersz@kis.p.lodz.pl dr inż. Andrzej Frączyk, a.fraczyk@kis.p.lodz.pl Charakterystyka urządzeń sieciowych:

Bardziej szczegółowo

Plan wykładu. Warstwa sieci. Po co adresacja w warstwie sieci? Warstwa sieci

Plan wykładu. Warstwa sieci. Po co adresacja w warstwie sieci? Warstwa sieci Sieci komputerowe 1 Sieci komputerowe 2 Plan wykładu Warstwa sieci Miejsce w modelu OSI/ISO unkcje warstwy sieciowej Adresacja w warstwie sieciowej Protokół IP Protokół ARP Protokoły RARP, BOOTP, DHCP

Bardziej szczegółowo

Wykaz zmian w programie SysLoger

Wykaz zmian w programie SysLoger Wykaz zmian w programie SysLoger Pierwsza wersja programu 1.0.0.1 powstała we wrześniu 2011. Funkcjonalność pierwszej wersji programu: 1. Zapis logów do pliku tekstowego, 2. Powiadamianie e-mail tylko

Bardziej szczegółowo

Kurs OPC S7. Spis treści. Dzień 1. I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501)

Kurs OPC S7. Spis treści. Dzień 1. I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501) Spis treści Dzień 1 I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501) I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami

Bardziej szczegółowo

Urządzenia sieciowe. Tutorial 1 Topologie sieci. Definicja sieci i rodzaje topologii

Urządzenia sieciowe. Tutorial 1 Topologie sieci. Definicja sieci i rodzaje topologii Tutorial 1 Topologie sieci Definicja sieci i rodzaje topologii Definicja 1 Sieć komputerowa jest zbiorem mechanizmów umożliwiających komunikowanie się komputerów bądź urządzeń komputerowych znajdujących

Bardziej szczegółowo

Wprowadzenie do zagadnień związanych z firewallingiem

Wprowadzenie do zagadnień związanych z firewallingiem NASK Wprowadzenie do zagadnień związanych z firewallingiem Seminarium Zaawansowane systemy firewall Dla przypomnienia Firewall Bariera mająca na celu powstrzymanie wszelkich działań skierowanych przeciwko

Bardziej szczegółowo

Spis treści. 1 Moduł RFID (APA) 3

Spis treści. 1 Moduł RFID (APA) 3 Spis treści 1 Moduł RFID (APA) 3 1.1 Konfigurowanie Modułu RFID..................... 3 1.1.1 Lista elementów Modułu RFID................. 3 1.1.2 Konfiguracja Modułu RFID (APA)............... 4 1.1.2.1

Bardziej szczegółowo

Laboratorium Sieci Komputerowych - 2

Laboratorium Sieci Komputerowych - 2 Laboratorium Sieci Komputerowych - 2 Analiza prostych protokołów sieciowych Górniak Jakub Kosiński Maciej 4 maja 2010 1 Wstęp Zadanie polegało na przechwyceniu i analizie komunikacji zachodzącej przy użyciu

Bardziej szczegółowo

Katedra Inżynierii Komputerowej Politechnika Częstochowska. Zastosowania protokołu ICMP Laboratorium podstaw sieci komputerowych

Katedra Inżynierii Komputerowej Politechnika Częstochowska. Zastosowania protokołu ICMP Laboratorium podstaw sieci komputerowych Katedra Inżynierii Komputerowej Politechnika Częstochowska Zastosowania protokołu ICMP Laboratorium podstaw sieci komputerowych Cel ćwiczenia Zastosowania protokołu ICMP Celem dwiczenia jest zapoznanie

Bardziej szczegółowo

ZADANIE.09 Syslog, SNMP (Syslog, SNMP) 1,5h

ZADANIE.09 Syslog, SNMP (Syslog, SNMP) 1,5h Imię Nazwisko ZADANIE.09 Syslog, SNMP (Syslog, SNMP) 1,5h 1. Zbudować sieć laboratoryjną 2. Czynności wstępne 3. Syslog 4. SNMP 5. Czynności końcowe - 1 - 1. Zbudować sieć laboratoryjną Zadanie Zbudować

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Wykaz zmian w programie SysLoger

Wykaz zmian w programie SysLoger Wykaz zmian w programie SysLoger Pierwsza wersja programu 1.0.0.1 powstała we wrześniu 2011. Funkcjonalność pierwszej wersji programu: 1. Zapis logów do pliku tekstowego, 2. Powiadamianie e-mail tylko

Bardziej szczegółowo

Rok szkolny 2015/16 Sylwester Gieszczyk. Wymagania edukacyjne w technikum

Rok szkolny 2015/16 Sylwester Gieszczyk. Wymagania edukacyjne w technikum Lp. 1 Temat 1. Konfigurowanie urządzeń. Uzyskiwanie dostępu do sieci Internet 2 3 4 5 Symulatory programów konfiguracyjnych urządzeń Konfigurowanie urządzeń Konfigurowanie urządzeń sieci Funkcje zarządzalnych

Bardziej szczegółowo

Komunikacja i wymiana danych

Komunikacja i wymiana danych Budowa i oprogramowanie komputerowych systemów sterowania Wykład 10 Komunikacja i wymiana danych Metody wymiany danych Lokalne Pliki txt, csv, xls, xml Biblioteki LIB / DLL DDE, FastDDE OLE, COM, ActiveX

Bardziej szczegółowo

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak Wykład 3 / Wykład 4 Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak 1 Wprowadzenie do Modułu 3 CCNA-E Funkcje trzech wyższych warstw modelu OSI W jaki sposób ludzie wykorzystują

Bardziej szczegółowo

Monitorowanie sieci (w oparciu o Protokoły SNMP i RMON W. Stallings) Architektura monitorowania sieci

Monitorowanie sieci (w oparciu o Protokoły SNMP i RMON W. Stallings) Architektura monitorowania sieci Monitorowanie sieci (w oparciu o Protokoły SNMP i RMON W. Stallings) Architektura monitorowania sieci Obszary monitorowania sieci Dostępu do monitorowanych informacji - w jaki sposób zdefiniować monitorowane

Bardziej szczegółowo