SNMP ==== Historia SNMP ------------- Rozwój protokołów do zarządzania sieciami rozpoczął się w 1988 roku, stworzony został wtenczas prosty protokół monitorowania bramek – SGMP (Simple Gateway Management Protocol). Jednak jego funkcjonalność ograniczała się do monitorowania bramek, a potrzeby zaczęły się zwiększać i zaczęto myśleć jak monitorować wszystkie urządzenia sieciowe oraz stacje robocze. Zaczęto więc proponować inne protokoły, które w roku 1988 zostały przejrzane, a następnie Komisja Architektury Internetu (IAB) zatwierdziła niektóre z nich (między innymi prosty protokół zarządzania siecią – SNMP Simple Network Management Protocol) do dalszego rozwoju. SNMP miał być jedynie krótko terminowym rozwiązaniem, które zostanie zastąpione bardziej rozbudowanym protokołem. Stało się inaczej, gdyż prostota tego protokołu spowodowała jego bardzo szybki rozwój, szybko też został zaimplementowany w większości urządzeń sieciowych oferowanych przez różnych producentów. Protokół ten został już kilkakrotnie rozbudowywany. Najnowszą wersją jest SNMPv3. Wykorzystuje on bazę informacji zarządzania (MIB – Management Information Base), którą stanowią schematy baz danych (struktur informacji). Obiekty, które zostały tam zapisane zawierają informacje, które może uzyskać wykorzystując protokół SNMP. Protokół Wykorzystuje tylko dwa atrybuty danych „tylko do odczytu” i „do odczytu i zapisu”. Do definiowania informacji zarządzania w protokole SNMP jest wykorzystywana abstrakcyjna notacja składniowa 1 (ASN.1 Abstract Syntax Notation One). MIB (Management Information Base) --------------------------------- Bazy MIB są tworzone w oparciu o strukturę zdefiniowaną w RFC1155 (Struktura informacji zarządzania – SMI). MIB może przechowywać jedynie proste typy danych (w tym tablice dwuwymiarowe), zostało tak przyjęte, aby uprościć protokół SNMP\@. Protokół ten umożliwia odczytywanie jedynie pojedynczych wartości tablic oraz wartości skalarnych. Struktura baz MIB tworzy strukturę drzewiastą, która grupuje powiązane obiekty. Liście tego drzewa to obiekty, którymi można zarządzać (odczytywać i/lub zapisywać). Struktura tego drzewa jest ustandaryzowana, dlatego, aby stworzyć własne poddrzewo, należy zgłosić się do odpowiedniej organizacji, która przyzna miejsce, w którym można dołączyć swoją część. Do definiowania struktury MIB wykorzystywana jest notacja ASN.1, która została częściowo przedstawiona na poprzednich laboratoriach. Prostota wymagała zmniejszenia liczby typów, które można wykorzystywać. Przykładowy MIB poniżej: .. code-block:: text INDEKS_MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212 mgmt FROM RFC1155-SMI; mib-2 OBJECT IDENTIFIER ::= {mgmt 1} indeks OBJECT IDENTIFIER ::= {mib-2 111} aktywny OBJECT-TYPE SYNTAX INTEGER (0..1) ACCESS read-write STATUS mandatory DESCRIPTION "aktywny indeks" ::= { indeks 1 } nazwisko OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "nazwisko studenta" ::= { indeks 2 } imie OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS optional DESCRIPTION "imie studenta" ::= { indeks 3 } nazwa_uczelni OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "nazwa uczelni" ::= { indeks 4 } przedmiotTable OBJECT-TYPE SYNTAX SEQUENCE OF przedmiot ACCESS not-accessible STATUS mandatory DESCRIPTION "tablica z przedmiotami" ::= { indeks 5 } przedmiot ::= SEQUENCE { nazwa OCTET STRING, prowadzacy OCTET STRING, ocena INTEGER (20..50), semestr INTEGER (1..10) } przedmiotEntry OBJECT-TYPE SYNTAX przedmiot ACCESS not-accessible STATUS mandatory INDEX { nazwa, semestr } DESCRIPTION "opis przedmiotu" ::= { przedmiotTable 1 } nazwa OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "nazwa przedmiotu" ::= { przedmiotEntry 1 } prowadzacy OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "nazwisko prowadzacego przedmiot" ::= { przedmiotEntry 2 } ocena OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "ocena kocowa" ::= { przedmiotEntry 3 } semestr OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "numer semestru na ktorym jest dany przedmiot" ::= { przedmiotEntry 4 } Potrzebne są także informacje jak można odczytać powyższe obiekty, istnieją dwie metody: 1. można stosować nazwy, które rozdziela się kropką, na przykład: indeks.nazwisko.0 – dodanie `.0` zaznacza, że chcemy odczytać obiekt; 2. stosować liczby przyporządkowane nazwą, na przykład 111.2.0. Jak już zaznaczono wcześniej, aby odczytać obiekt należy dodać `.0` na końcu. Natomiast aby odczytać element tablicy należy określić numer wiersza, który chcemy odczytać, robi się to w identyczny sposób jak zwykły obiekt, jednak na końcu zamiast zera dodajemy wartości obiektów zaznaczonych jako :samp:`INDEX`, który chcemy odczytać. Niestety w przypadku wartości typu :samp:`OCTET` :samp:`STRING` należy zakodować ciąg znaków na kody ASCII rozdzielone kropkami, na przykład zamiast `111.5.1.1.”PSII”.` należy podać kody ASCII liter, czyli `111.5.1.1.80.83.73.73.`. Przy dostępie do obiektów ważna jest znajomość porządku leksykograficznego obiektów. W uproszczeniu jest to porządek, który zachowujemy, jeśli poruszamy się po drzewie baz MIB w następujący sposób, zaczynając od lewej strony drzewa schodzimy, aż do osiągnięcia liścia. Następnie możemy wejść z powrotem do tego poziomu, który posiada ścieżkę, którą nie szliśmy i znowu idziemy aż do liścia. W ten sposób z czasem dojdziemy do końca drzewa. Poniżej przedstawiam rysunek drzewa z zaznaczonym porządkiem leksykograficznym obiektów. Przykładowo przejście drzewa przedstawionego na Rys.~\ref{fig:mibexample} wygenerowałoby następującą ścieżkę (ślad):\\ `111, 111.1, 111.2, 111.3, 111.4, 111.5, 111.5.1, 111.5.1.1, 111.5.1.2, 111.5.1.3, 111.5.1.4`. Ćwiczenie: 1. Znajdź definicję baz MIB w systemie i przejrzyj je. 2. Ściagnij program MIBBrowser do przeglądania drzew MIB i zapoznaj się z nim. Protokół SNMP ------------- Możliwe operacje wykonywane na wartościach skalarnych: * :samp:`GET` pobranie wartości obiektu poprzez żądanie stacji zarządzającej; * :samp:`SET` ustawienie wartości obiektu poprzez żądanie stacji zarządzającej; * :samp:`TRAP` wysłanie wartości obiektu do stacji zarządzającej przez agenta. Dostępne obiekty, którymi można zarządzać są wartościami skalarnymi. Uwierzytelnianie w protokole jest bardzo proste i sprowadza się do podania nazwy społeczności (ang. \emph{community name}), nazwa ta nie jest szyfrowana, więc nie zapewnia ona dostatecznego poziomu bezpieczeństwa. Z tego względu wielu producentów urządzeń sieciowych oferuje jedynie usługi monitorowania (operacje Get i Trap), blokując możliwość zmieniania wartości (operacją Set). Polecenia klienta NET-SNMP -------------------------- Pakiet net-snmp instaluje kilka użytecznych komend. * :command:`snmpget` pobranie pojedyńczej wartości z OID * :command:`snmpset` ustawienie wartości * :command:`snmpwalk` przejście całego drzewa * :command:`snmptable` wyświetlenie tablicy Każda komenda posiada wspólną składnię, informacje na ten temat są w poradniku :command:`man snmpcmd`. \\ :command:`snmpwalk -v WERSJA -c COMMUNITY ADRES-AGENTA OID` gdzie wersja to `1 2c 3`, COMMUNITY to nazwa społeczności, ADRES-AGENTA to adres IP lub nazwa domenowana, a OID to dokładny oid lub skrót (np. system). :command:`snmpwalk -v2c -c public localhost system` :command:`snmpwalk -v2c -c public localhost` Komendy `snmp*` udostępniają wspólne opcje formatowania. Ważniejsze z nich to: * :samp:`-On` wyświetl OIDy numerycznie * :samp:`-Oq` pomiń znak = * :samp:`-Of` wyświetl pełne nazwy obiektów MIB Konfiguracja NET-SNMP dla SNMP v1 --------------------------------- Net-SNMP to pakiet oprogramowania umożliwiające wykorzystanie protokołu SNMP (w wersjach v1, v2c oraz v3). W skład pakietu wchodzi biblioteka programistyczna, agent, zestaw aplikacji klienckich oraz moduły implementujące bibliotekę w językach Perl oraz Python. Pakiet jest rozpowszechniany na licencji BSD (źródło Wikipedia). Na większości dystrybucji, pliki konfiguracyjne pakietu net-snmp znajdują się w katalogu :file:`/etc/snmp/`. Plik :file:`snmpd.conf` odpowiada za konfigurację agenta SNMP, z kolei plik :file:`snmp.conf` odpowiada za konfigurację klienta. W pliku :file:`snmptrapds.conf` znajdują się dyrektywy konfiguracyjne demona pułapek SNMP. Dyrektywy ````````` Minimalny plik konfiguracyjny dla SNMP w wersji 1 składa się z dyrektyw `rocommunity` oraz `rwcommunity`. * :samp:`rocommunity` określa nazwę społecznośći, która ma dostęp read-only do drzew MIB agenta, dodatkowo określa żródło, z którego dana społeczność może słać żądania. * :samp:`rwcommunity` to samo co powyżej, jednak dla dostępu read-write. Składnia dyrektywy wygląda następująco: :command:`rocommunity <źródło> -V ` Przykład: .. code-block:: bash rocommunity public 127.0.0.1 rwcommunity private 127.0.0.1 W powyższym przykładzie społeczność `public` może mieć dostęp read-only jedynie z adresu `127.0.0.1`. Podobnie społeczność `private` ma dostęp read-write z localhost. Ćwiczenia: 1. Skonfiguruj snmpd dla rocommunity public z adresów sali laboratoryjnej 2. Wyświetl całe drzewo MIB agenta 3. Wyświetl informacje o systemie 4. Wyświetl tablice interfejsów sieciowych 5. Wyświetl listę aktywnych połaczeń Rozszerzenie UCD ---------------- Rozszerzenie UCD z UCD-SNMP-MIB pozwala na monitorowania dodatkowych parametrów: * `proc NAZWA (MAX=x) (MIN=y)` sprawdzaj czy proces NAZWA działa, MAX --- maksymalna liczba procesów, MIN --- minimalna * `exec NAZWA PROGRAM (ARGUMENTY)` wywołaj PROGRAM z listą argumentów ARGUMENTY * `disk ŚCIEŻKA (MIN=x)` sprawdzaj zajętość duysku ŚCIEŻKA, błąd gdy zajętość > MIN * `load (1MAX) (5MAX) (15MAX)` sprawdzaj load, wartości alertów dla load z 1, 5 i 15 minut Ćwiczenia: 1. Skonfiguruj monitorowanie load, z parametrami 1 5 10 2. Wywołaj alarm dla load 3. Skonfiguruj monitorowanie partycji \home 4. Napisz prosty skrypt, ktory wyswietla cokolwiek 5. Skonfiguruj momitorowanie procesu top dla max=2, wywolaj alarm .. Różnice v1 vs. v2 .. ````````````````` .. .. Zmiany, które wprowadzono w nowszej wersji protokołu można pogrupować na .. modyfikację dokonane w następujących kategoriach: .. \begin{itemize} .. \item struktura informacji zarządzania SMI .. \item współpraca pomiędzy zarządcami .. \item działanie protokołu. .. \end{itemize} .. .. SMI zostało rozszerzone o nowe możliwości oraz niewiele zmienione w stosunku do .. starszej wersji. SMI protokołu SNMPv2 można podzielić na następujące części: .. \begin{itemize} .. \item definicje obiektów, .. \item tabele, .. \item definicje powiadomień, .. \item moduły informacyjne. .. \end{itemize} SNMP w wersji 3 =============== W 1992 roku zaczęto pracować nad poprawą bezpieczeństwa protokołu oraz rozszerzeniem jego możliwości tak, aby mógł kontrolować dowolne zasoby, również te nie związane z sieciami. W 1996 roku ustandaryzowano nową wersję protokółu nazwaną SNMPv2 lub SNMPv2c, drugi skrót pochodzi z określenia sposobu autoryzacji (Community-Based SNMPv2). Niestety wersja ta nie poprawia aspektów bezpieczeństwa. Następujące dokumenty RFC 1901, 1902, 1903, 1904, 1905, 1906, 1907, 1908 opisują standard. Nowością w SNMPv2 jest dodanie możliwość współpracy między zarządcami. W 1998 roku ustandaryzowano SNMPv3, publikując jednocześnie dokumenty RFC numer 2271, 2273, 2273, 2274, 2275. Głównym usprawnieniem wersji trzeciej standardu jest dodanie aspektów związanych z bezpieczeństwem, w tym szyfrowanie i autoryzację Model VACM ---------- Ostatnia wersja protokołu SNMPv3 wprowadza brakujące mechanizmy bezpieczeństwa. W protokole SNMPv2c brakowało ich, gdyż uwierzytelnianie na podstawie nazwy społeczności, przy braku szyfrowania, umożliwiało w bardzo prosty sposób przejmowanie takiej transmisji. Nowa wersja protokołu nie zmienia formatów jednostek PDU, dlatego zachowuje zgodność formatu jednostek PDU z wcześniejszymi wersjami protokołów. W modelu VACM możemy określić dokładne reguły dostępu do drzewa MIB agenta. Służą do tego dyrektywy dostępu (access), widoków (view), grup (group) oraz dyrektywa przywiązujące nazwę społeczności SNMP (com2sec). Definicja widoku: `view NAZWA included OID` Przykład: `view tylko-system included system` `view tylko-ip included .1.3.6.1.2.1.4` Definicja grup: `group NAZWA WERSJA-SNMP SECNAME` .. Przykład: .. .. \command{group admini v1 publiczni}\\ .. \command{group admini v2c publiczni}\\ .. \command{group admini usm publiczni}\\ Definicja reguł dostępu: `access NAZWA-GRUPY "" any noauth exact NAZWA-WIDOKU none none` Definiujemy dowiązanie do COMMUNITYNAME: `com2sec SECNAME SOURCE COMMUNITYNAME` Kompletny przykład, communityname public pozwala na dostęp do drzewa system z adresów z sieci `150.254.32.0/24` dla communityname `public`. .. code-block:: bash com2sec czytacze 150.254.32.0/24 public group users v1 czytacze group users v2c czytacze group users usm czytacze view mysystemview included .1.3.6.1.2.1.1 access users "" any noauth exact mysystemview none none Ćwiczenia: 1. Skonfiguruj snmp tak aby z localhost był dostęp do wszystkiego (community name public), z komputerów sali dostęp public do system, dostęp private do wszystkiego. 2. Dodaj communityname adminsieci z dostępem do drzew ip, tcp i udp z kazdego adresu Model USM --------- Model USM (ang. *User-based Security Model*) jest głównym modelem uwierzytelniania i autoryzacji dodanym do SNMP w wersji 3. Pozwala na definiowanie użytkowników z hasłami oraz szyfrowanie komunikacji SNMP. W przeciwieństwie do prostego modelu opartego na nazwie społeczności znanego z SNMP w wersji 1 i 2c, oferuje o wiele większy poziom bezpieczeństwa i granulacji uprawnień. Wraz z modelem VACM daje to szerokie możliwości konfiguracji. Definiowanie użytkowników -------------------------- Aby zdefiniować użytkownika, należy zatrzymać demona snmpd i dodać następujący wpis do pliku :file:`snmpd.conf`. .. code-block:: bash createUser babcia MD5 "doscdlugiehaslo" DES rwuser babcia Opcja MD5 definiuje ak szyfrowane będzie hasło, natomiast opcja DES mówi jakim skrótem szyfrować komunikację. Drugi wpis `rwuser` definiuje czy użytkownika ma dostęp `rw`, czy `ro`. Po włączeniu demona snmp, ustawienie użytkownika można przetestować np. za pomocą `snmpwalk`. .. code-block:: bash #> snmpwalk -v3 -u babcia -a MD5 -A "doscdlugiehaslo" -x DES -X "doscdlugiehaslo" -l authPriv localhost system Opcja `authPriv` oraz `authNoPriv` definiuje czy żądania mają być uwierzytelniane, a odpowiedzi szyfrowane. Związanie z VACM ---------------- Aby związać model USM z VACM, zmodyfikować użytkownika babcia: .. code-block:: bash rwuser babcia authpriv system