Podręcznik funkcji bezpieczeństwa Cisco Srst Snmp Mib 3 4

Podręcznik funkcji bezpieczeństwa Cisco SRST SNMP MIB 3.4 to zestaw zmiennych SNMP, których używa Cisco SRST Security Services, aby zapewnić bezpieczeństwo i kontrolę dostępu. Dostarcza on informacji o używanych protokołach, wykorzystywanych usługach, wersji oprogramowania i wielu innych. Przy użyciu tego podręcznika można monitorować i zarządzać bezpieczeństwem sieci. Ponadto, udostępnia informacje potrzebne do wykrywania i rozwiązywania problemów związanych z bezpieczeństwem. Cisco SRST SNMP MIB 3.4 to skuteczny sposób zapewnienia bezpieczeństwa i ochrony sieci.

Ostatnia aktualizacja: Podręcznik funkcji bezpieczeństwa Cisco Srst Snmp Mib 3 4

Simple Network Management Protocol – rodzina protokołów sieciowych wykorzystywanych do zarządzania urządzeniami takimi jak routery, przełączniki, komputery czy centrale telefoniczne za pośrednictwem sieci IP. Do transmisji wiadomości SNMP wykorzystywany jest głównie protokół UDP: standardowo port 161 wykorzystywany jest do wysyłania i odbierania żądań, natomiast port 162 wykorzystywany jest do przechwytywania sygnałów trap od urządzeń. Możliwe jest także wykorzystanie innych protokołów do przekazywania żądań, na przykład TCP^[1].

Istnieją trzy wersje protokołu:

• SNMPv1 – pierwsza wersja, która została opublikowana w 1988 roku w dokumencie RFC 1067 ↓ (z późniejszymi zmianami w RFC 1098 ↓ oraz RFC 1157 ↓). W tej wersji protokołu bezpieczeństwo oparte jest na tak zwanych communities, które są pewnego rodzaju nieszyfrowanymi hasłami umożliwiającymi zarządzanie urządzeniem,
• SNMPv2 – eksperymentalna wersja protokołu, określana także SNMPv2c, opisana w dokumencie RFC 1901 ↓,
• SNMPv3 – obsługująca uwierzytelnianie oraz szyfrowaną komunikację.

Każdy komunikat dotyczy określonej zmiennej, tzw. OID (ang. Object IDentifier). Dla przykładu zmienna OID o nazwie sysUpTime (czas pracy urządzenia od ostatniego włączenia) ma postać 1. 3. 6. 1. 2. 0, co odpowiada jej adresowi w drzewie MIB.

Funkcjonowanie[edytuj | edytuj kod]

Protokół SNMP zakłada istnienie w zarządzanej sieci dwóch rodzajów urządzeń: zarządzających i zarządzanych. Urządzenie (komputer) jest zarządzającym (tzw. NMS, ang. Network Management Station), gdy jest na nim uruchomiony odpowiedni program, manager SNMP (zarządca SNMP). Urządzenie jest zarządzane, jeśli działa na nim program agent SNMP.

W procesie zarządzania używane są bazy MIB (ang. Management Information Base – baza informacji zarządzania), czyli zbiory zmiennych, które manager SNMP w zależności od uprawnień może odczytać lub zmienić. W tym celu manager SNMP kontaktuje się z agentem na danym zarządzanym urządzeniu wykorzystując jedno z dwóch wcześniej skonfigurowanych haseł:

• hasło odczytu, tzw. public_community,
• hasło zapisu, tzw. private_community.

Odczytanie wybranej zmiennej daje managerowi określoną informację o stanie danego elementu sieci, podczas gdy zapis do danej zmiennej pozwala mu na sterowanie zachowaniem się urządzenia w sieci.

Oprócz operacji odczytu i zapisu zmiennych w agencie przez managera istnieje również możliwość takiego skonfigurowania agenta, aby sam poinformował danego managera o zmianie swojego stanu w przypadku zajścia określonego zdarzenia. Odbywa się to przy pomocy wysyłanego przez agenta komunikatu Trap lub (od wersji drugiej protokołu SNMP) przy pomocy komunikatu Inform.

SNMP domyślnie działa na porcie 161 TCP oraz UDP.

Komunikaty Trap są domyślnie wysyłane do portu 162 TCP lub UDP.

Budowa komunikatów[edytuj | edytuj kod]

Budowa komunikatów protokołu SNMP zdefiniowana jest przy pomocy notacji zwanej Abstract Syntax Notation One (oznaczanej ASN. 1). Sposobem kodowania struktur danych komunikatów SNMP jest uproszczony BER.

Wady i zalety[edytuj | edytuj kod]

SNMP to obecnie najpopularniejszy protokół służący do zarządzania sieciami. Swoją popularność zawdzięcza następującym zaletom:

• Stosunkowo małe dodatkowe obciążenie sieci generowane przez sam protokół,
• Niewielka liczba poleceń własnych obniża koszty urządzeń go obsługujących,
• Niskie koszty wdrożenia do eksploatacji.

Główne wady SNMP:

• Brak zapewnienia bezpieczeństwa przesyłanym danym (SNMP w wersji pierwszej i drugiej).

Rodzaje komunikatów[edytuj | edytuj kod]

W wersji pierwszej protokołu dostępne są następujące komunikaty:

• Get,
• GetNext,
• Set,
• Response,
• Trap.

W wersji drugiej, oprócz komunikatów wersji pierwszej dostępne są:

• GetBulk,
• Inform.

Wersja trzecia nie dodaje do protokołu nowych komunikatów.

Bezpieczeństwo[edytuj | edytuj kod]

Kwestie bezpieczeństwa są największym problemem użytkowników protokołu SNMP w wersji pierwszej i drugiej. Jedyne zabezpieczenie w tym protokole, tzw. community string będący de facto hasłem, jest wysyłany poprzez sieć w postaci niezaszyfrowanej. Pozwala to na jego podsłuchanie przy użyciu programów typu sniffer.

SNMPv3 znacząco poprawia bezpieczeństwo protokołu poprzez wprowadzenie bardziej zaawansowanych metod uwierzytelniania.

Przypisy[edytuj | edytuj kod]

1. ↑ Douglas Mauro, Kevin Schmidt: Essential SNMP. O'Reilly, 2001.

Zobacz też[edytuj | edytuj kod]

• TCP, IP
• porty protokołu

Linki zewnętrzne[edytuj | edytuj kod]

• Wstęp do protokołu SNMP
• SimpleWeb. org. [zarchiwizowane z tego adresu (2021-04-27)].
• SNMP FAQ część 1
• SNMP FAQ część 2
• J. D.  Case i inni, Simple Network Management Protocol, RFC 1067, IETF, sierpień 1988, DOI: 10. 17487/RFC1067, ISSN 2070-1721, OCLC 943595667 (ang. ).
• J. org/html/rfc1098">Simple Network Management Protocol (SNMP), RFC 1098, IETF, kwiecień 1989, 10. 17487/RFC1098,
• J. org/html/rfc1157">Simple Network Management Protocol (SNMP), RFC 1157, IETF, maj 1990, 10. 17487/RFC1157,
• J. Case; K. McCloghrie; M. Rose; S. Waldbusser"> i inni, Introduction to Community-based SNMPv2, RFC 1901, IETF, styczeń 1996, 10. 17487/RFC1901,

• p
• d
• e

Lata mijają, a pewne protokoły pozostają z nami po dziś dzień pomimo swojego sędziwego wieku. Tak też jest w przypadku SNMP, czyli Simple Network Management Protocol. Ciężko o bardziej trafną nazwę – jest to faktycznie prosty protokół do zarządzania siecią. Nie lekceważmy go jednak ponieważ pomimo swojej prostoty jest on nadal bardzo użyteczny. W tym artykule przyjrzymy się bliżej zastosowaniu i zasadom działania SNMP.

Do czego używamy SNMP?

Wyobraź sobie, że zarządzasz na co dzień siecią składającą się z dziesiątek, jeśli nie setek urządzeń. Nawet jeśli znasz tą sieć jak własną kieszeń i poruszasz się po poszczególnych urządzeniach bardzo sprawnie, to nadal pozostaje problem braku monitoringu proaktywnego. Jak się dowiedzieć, że coś się w Twojej sieci zepsuło i to jeszcze zanim ruszą na Ciebie hordy rozwścieczonych użytkowników? Pomaga nam w tym jeden z protokołów warstwy siódmej modelu ISO/OSI – SNMP. Jest to jeden z podstawowych protokołów używanych w fazie Solution Support cyklu życia sieci.

SNMP jest jednym z przykładów implementacji tak zwanego NMS, czyli Network Management System (System Zarządzania Siecią). Jego zadaniem jest monitorowanie stanu urządzeń sieciowych i ich poszczególnych komponentów. W przypadku wykrycia jakiejś awarii czy też anomalii system ten jest odpowiedzialny za informowanie Ciebie jako admina o tych niepożądanych wydarzeniach. Ponadto SNMP może być używany również do konfigurowania urządzeń. Dziś mamy jednak do dyspozycji dużo efektywniejsze narzędzia.

Podczas projektowania SNMP jego autorzy postawili przed sobą niełatwe zadanie. Miało to być uniwersalne rozwiązanie, dzięki któremu moglibyśmy monitorować wszystkie urządzenia komunikujące się za pomocą protokołu IP. Jak jednak poradzono sobie w takiej sytuacji z problemem różnorodności platform? Zdefiniowano swego rodzaju słownik (bazę danych) zawierający zmienne opisujące poszczególne komponenty urządzeń sieciowych.

Zasada działania SNMP

Opisywany w tym artykule protokół składa się z kilku kluczowych części. Omówmy je po kolei.

SNMP Agent & SNMP Manager

SNMP swoje działanie opiera na interakcji dwóch komponentów, którymi są:

• SNMP Agent,
• SNMP Manager.

Agent SNMP to nic innego jak urządzenie, którym będziemy zarządzać. Może to być więc switch, router, firewall czy też nawet urządzenie końcowe takie jak laptop lub drukarka.

Menedżer SNMP to z kolei nasz NMS – czyli endpoint (komputer bądź serwer), na którym mamy zainstalowane dedykowane oprogramowanie wykorzystujące protokół SNMP do zarządzania urządzeniami w sieci.

MIB

Każde urządzenie końcowe (a więc nawet host, na którym jest uruchomiony SNMP Manager) ma w swoim kodzie zaszyty wspomniany wcześniej słownik (bazę danych). Jest to tzw. MIB (Management Information Base).

To nas z kolei prowadzi do kolejnego terminu jakim jest…

OID

OID, czyli Object Identifier to nic innego jak pojedyncza zmienna w bazie MIB. Każde urządzenie, niezależnie od tego jaka firma je wyprodukowała, posiada pewne uniwersalne charakterystyki, które jako administratorzy sieci możemy monitorować. Wśród wielu można by wymienić uptime systemu, stan danego interfejsu (up/down), przepustowość portu itp. Każda z takich charakterystyk to osobny OID.

Przykładowy Object Identifier może wyglądać następująco: 1. 3. 6. 1. 2. 5. 0. W tej chwili może jeszcze tego nie widać, ale mamy tu do czynienia z uporządkowanym zbiorem danych.

MIBy zawierają tak wiele zmiennych, że aby ułatwić nawigowanie po nich zostały one uporządkowane hierarchicznie w strukturę drzewa. Każda kolejna liczba w OID identyfikuje konkretną gałąź wspomnianego drzewa. W przypadku wspomnianego akapit wcześniej OID’u struktura wygląda następująco:

Do przeszukiwania MIB’ów służą nam różne internetowe słowniki takie jak np. http://oid-info. com. Możemy więc sprawdzić, że OID 1. 0 zawiera informację o nazwie urządzenia (zmienna sysName). Dobrym źródłem informacji są też dokumentacje poszczególnych producentów sprzętu sieciowego. Dlaczego?

MIBy mogą zawierać nie tylko uniwersalne OID’y. Większość urządzeń bedzie miała również przygotowane specjalne zmienne, które będą charakterystyczne dla urządzeń danego producenta. W przypadku urządzeń Cisco zmienna sysName będzie dostępna w OID 1. 4. 9. 0. 

Poszczególne OID’y możemy nie tylko odczytywać, ale również modyfikować! Jest to swego rodzaju alternatywna metoda konfiguracji urządzeń – ale o tym za chwilę.

SNMP Views

Na wielu urządzeniach możemy wykorzystywać również tzw. widoki SNMP (SNMP Views). Ustawienia te służą do ograniczenia dostępu NMS do MIB urządzenia i stanowią dodatkową formę zabezpieczenia. Dzięki temu mamy możliwość ograniczenia dostępu do danych OID’ów. Widokom SNMP przyjrzymy się bliżej w osobnym artykule poświęconym konfiguracji SNMP.

Komunikaty SNMP

Teraz gdy znamy już wszystkie podstawowe komponenty wchodzące w skład SNMP, przyjrzyjmy się trzem komunikatom wykorzystywanym przez ten protokół.

SNMP GET

Komunikat SNMP GET jest wysyłany z SNMP Manager’a (NMS) do SNMP Agent’a (hosta) i służy do odczytywania wartości danego OID. Komunikacja zachodzi na porcie UDP 161, a do odczytu OID wystarczą uprawnienia dostępu do hosta na poziomie read-only.

SNMP SET

Komunikat SNMP SET jest wysyłany z SNMP Manager’a (NMS) do SNMP Agent’a (hosta) i służy do modyfikacji wartości danego OID. Komunikacja zachodzi również na porcie UDP 161, a do zapisu OID wymagane są uprawnienia dostępu do hosta na poziomie read-write.

SNMP TRAP

Komunikat SNMP TRAP jest wysyłany z SNMP Agent’a (hosta) do SNMP Manager’a (NMS) i służy do informowania NMS o tym, że nastąpiła zmiana wartości danego OID. Aby TRAP dotyczący danego OID był wysyłany musi być to uprzednio skonfigurowane (włączone) przez administratora. Naszym obowiązkiem jest więc uruchomienie stosownych TRAP’ów na etapie prekonfiguracji urządzenia. Komunikacja zachodzi w starszych wersjach SNMP na porcie UDP 162 co bywa problematyczne z uwagi na naturę działania UDP – istnieje ryzyko, że TRAP nie dotrze do NMS. SNMPv3 naprawia to niedopatrzenie wprowadzając nową wersję komunikatu TRAP, która została nazwana INFORM i używa portu TCP 162.

Z uwagi na naturę działania komunikatów SNMP TRAP/INFORM możemy powiedzieć, że jest to funkcjonalność w pewnym sensie duplikująca działanie Sysloga.

Wersje SNMP

W przypadku protokołu SNMP mamy do czynienia z jego trzema wersjami:

SNMPv1

Najstarsza wersja SNMP, nie polecana ze względów bezpieczeństwa. Mamy tu do czynienia z uwierzytelnianiem za pomocą tzw. community strings. Nie jest to nic innego jak ciąg znakowy. Wykorzystuje się zazwyczaj osobny community string dla dostępu read-only do urządzenia i osobny dla dostępu read-write.

Community strings wysyłane są clear-text’em, brakuje również szyfrowania pakietów i właśnie to powoduje, że SNMPv1 nie jest bezpieczny. Jeśli mamy do czynienia z urządzeniami, które nie wspierają nowszych wersji SNMP (co jednocześnie zmusza nas do używania wersji 1. ) to jest jeden sposób na poprawę sytuacji.

Możemy mianowicie wykorzystać Access Control Lists (ACL) i kontrolować adresy IP, które mogą się komunikować z naszymi urządzeniami sieciowymi. Jest to jednak nadal bardzo proste do złamania zabezpieczenie (wystarczy podszyć się pod adres IP naszego NMS (IP Spoofing)). Dlatego też zaleca się po prostu ograniczyć do używania jedynie read-only community string.

Największym ograniczeniem funkcjonalnym SNMPv1 są 32-bitowe liczniki (counters) używane do pobierania danych z OID’ów. Znacznie ogranicza to zakres możliwych do przesyłania wartości.

SNMPv2c

W przypadku SNMPv2c mamy w zasadzie do czynienia z identycznymi cechami jak w przypadku wersji pierwszej poza jednym czynnikiem – dodano wsparcie dla 64-bitowych counter’ów. Funkcjonalnie można więc wykrzesać nieco więcej z SNMPv2c. Nie zmienia to jednak faktu, że jest to nadal bardzo ryzykowny w użyciu protokół.

SNMPv3

SNMP w wersji trzeciej adresuje wcześniejsze luki bezpieczeństwa. Wprowadzono następujące mechanizmy:

• uwierzytelnianie komunikacji za pomocą pary użytkownik/hasło
• hasło nie jest wysyłane clear-text’em – zamiast tego używany jest hash MD5 lub SHA1
• wspierane jest szyfrowanie pakietu za pomocą DES/3DES/AES

Są to niewątpliwie dobre zmiany. Warto zaznaczyć jednak, że SNMPv3 nie sprawdza integralności pakietu (integrity checking) – nie mamy więc pewności czy dany pakiet nie był modyfikowany podczas transportu między manager’em i agent’em SNMP.

W SNMPv3 mamy do wyboru trzy różne tryby operacyjne, których wsparcie może się różnić w zależności od oprogramowania używanego jako NMS:

noauthnopriv

W tym trybie mamy do czynienia z brakiem szyfrowania i brakiem uwierzytelniania parą użytkownik/hasło. Stosowany jest jedynie username więc w zasadzie jest to forma identyczna z zastosowaniem community strings. Tryb ten używany jest często do wstecznej kompatybilności ze starszymi urządzeniami niewspierającymi SNMPv3.

authnopriv

W tym trybie nadal brakuje szyfrowania, natomiast uwierzytelnianie zachodzi przy użyciu pary użytkownik/hasło. Dane te są przesyłane za pomocą hash’a MD5/SHA1 a wyboru funkcji haszującej możemy dokonać w ustawieniach NMS.

authpriv

Najbezpieczniejszy tryb, w którym cała zawartość pakietu jest szyfrowana za pomocą DES/3DES/AES a uwierzytelnianie zachodzi również przy użyciu pary użytkownik/hasło (w formie hash’a MD5/SHA1).

W tym artykule przyjrzeliśmy się teorii związanej z działaniem SNMP. W drugiej części artykułu zapoznasz się z konfiguracją SNMP oraz opcjami oprogramowania do monitoringu.

Co zrobić, kiedy liczba urządzeń wymagających monitorowania drastycznie wzrasta i po prostu brakuje czasu na indywidualną kontrolę każdej maszyny? Temu wyzwaniu pomaga sprostać protokół SNMP, będący standardem zarządzania siecią.

Simple Network Management Protocol (SNMP) to prosty protokół zarządzania siecią, który działa w warstwie aplikacji modelu ISO/OSI, umożliwiając wymianę informacji kontrolnych pomiędzy urządzeniami sieciowymi. Niestety, z racji tego, że jest on wykorzystywany przez wąską grupę specjalistów, nie słyszy się o nim tyle, co np. o SMTP, POP3 czy DNS.

Ideę SNMP można łatwo zrozumieć, przywołując codzienne, rutynowe sprawdzanie temperatury. To normalne, że mieszkając w Krakowie, po spojrzeniu na termometr za oknem odczytamy temperaturę krakowskiego powietrza. Gdyby jednak ulepszyć termometr w taki sposób, aby jednocześnie pokazywał temperaturę ze wszystkich miast w Polsce, moglibyśmy powiedzieć, że z jednego miejsca w kraju monitorujemy stan temperatury w całej Polsce. Jeśli dodatkowo wyposażyć ten cudowny termometr w możliwość odczytu innych informacji (np. liczby osób w danym mieście, ilości kolizji drogowych, etc. ), a także ich zmiany, powstałby supertermometr.

SNMP jest właśnie takim supertermometrem. Dzięki niemu, w jednym miejscu sieci (na stacji roboczej administratora) można zebrać informacje z kilkunastu miejsc reprezentowanych przez urządzenia sieciowe – routery, switche, komputery, a nawet drukarki. Mierzyć, czy raczej monitorować możemy praktycznie każdą własność danego urządzenia: liczbę aktualnie zalogowanych użytkowników, obciążenie pamięci, ilość wolnego miejsca na dysku twardym, temperaturę podzespołów lub prędkość przesyłania danych. Dodatkowo, z jednej stacji roboczej za pomocą SNMP możemy ustawić parametry urządzeń w całej sieci, wpływając zdalnie na ich konfigurację.

Jak działa SNMP?
Model SNMP oparty został o architekturę klient-serwer, której nazwę zmieniono na zarządca-agent. Jeden zarządca monitoruje od kilku do kilkuset agentów.

Agenci rezydują na każdym urządzeniu sieciowym (routerze, punkcie dostępowym, stacji roboczej czy nawet drukarce obsługującej SNMP) i tworzą bazę danych zwaną MIB (ang. Management Information Base). W bazie przechowywane są obiekty opisujące właściwości danego urządzenia. Na żądanie zarządcy, obiekty te są udostępniane, ujawniając informacje takie, jak np. temperatura procesora, ilość wolnego miejsca na dysku, bieżące obciążenie interfejsu sieciowego czy liczba aktualnie zalogowanych użytkowników.

Rys. 1 Topologia protokołu SNMP

Rolą zarządcy, oprócz odpytywania poszczególnych agentów, jest archiwizowanie informacji i przedstawianie ich w czytelnej formie administratorowi sieci, by ten mógł natychmiastowo podjąć odpowiednie działania.

Im bardziej rozbudowane oprogramowanie zarządcy, tym więcej funkcji może on pełnić. Z ciekawszych opcji warto wymienić wizualizacje topologii sieci, logiczne i fizyczne grupowanie urządzeń, analizę trendów, sporządzanie wykresów czy też szybkie wykrywanie anomalii i powiadamianie administratora za pomocą SMS.

Tryb „pułapka”
SNMP przewiduje także tryb pracy o nazwie pułapka (ang. trap). Pułapkę należy utożsamić z alarmem ustawionym na agencie. Jeśli jedna z monitorowanych wartości przekroczy zdefiniowany uprzednio próg (np. temperaturę krytyczną), agent bezzwłocznie powiadamia o tym fakcie zarządcę, nie czekając aż ten zgłosi się po kolejny odczyt danych.

Drzewo MIB
Nie ulega wątpliwości, że w całym tym procesie monitoringu i zarządzania, to właśnie baza danych agenta (MIB) jest najistotniejsza. Jest ona zarówno źródłem danych, jak i interfejsem umożliwiającym sterowanie urządzeniem.

Baza MIB ma strukturę drzewiastą. Liście drzewa są obiektami. Każdy z obiektów posiada swój unikalny identyfikator Object ID (OID), składający się z ciągu cyfr oddzielonych kropką (np. 1. 3. 6. 2. 1). OID reprezentuje unikalną ścieżkę na drzewie MIB.

Rys. 2 Przykładowe drzewo MIB

Ponieważ tego typu oznaczenie jest raczej ukłonem w stronę maszyny, a nie człowieka, każdy obiekt, można również zidentyfikować za pomocą jednoznacznej nazwy. Wspomniany wcześniej ciąg cyfr 1. 1 identyfikuje nazwę sysDescr.

Świetnym narzędziem tłumaczącym OID na nazwy obiektów (i odwrotnie) jest SNMP Object Navigator, którego interfejs udostępniono na stronie http://tools. cisco. com/Support/SNMP/do/BrowseOID. do? local=en. Za pomocą tego narzędzia możesz również “przechadzać się” po poszczególnych gałęziach drzewa MIB, nie znając ani nazw, ani identyfikatorów obiektów.

Obiekty mają jeden z trzech rodzajów praw dostępu:

• read-only (RO) – tylko do odczytu,
• write-only (WO)- tylko do zapisu,
• read-write (RW) – do odczytu i zapisu.

Dostęp do obiektów wymaga również znajomości community-string, czyli łańcucha znaków, o którym możesz myśleć jak o haśle. Community-string przybiera różne wartości dla dostępu RO i RW. Domyślne ustawienia to odpowiednio public i private. Ze względów bezpieczeństwa zaleca się ich zmianę, ale z drugiej strony trzeba sobie zdawać sprawę, że community-string przesyłany jest przez sieć w postaci jawnego tekstu.

Dopiero wersja trzecia protokołu SNMP implementuje mechanizmy bezpieczeństwa. Niestety, rzadko kiedy spotyka się urządzenia z uruchomionym SNMPv3, nawet jeśli został on zaimplementowany przez producenta. Powodów można doszukiwać się w bardziej skomplikowanej konfiguracji agenta – administrator musi wygenerować i rozesłać klucze służące do szyfrowania i uwierzytelniania. Wiąże się to z ręczną konfiguracją każdego urządzenia z osobna.

Żądania i odpowiedzi SNMP przesyłane są na portach 161 i 162 za pomocą datagramów bezpołączeniowego protokołu UDP i połączeniowego protokołu TCP. Decydując się na implementację SNMP we wszystkich segmentach sieci, pamiętaj aby odpowiednio skonfigurować firmowy firewall.

Komunikaty SNMP
Prostota protokołu SNMP polega m. in. na sposobie komunikacji urządzeń sieciowych. Poniżej przedstawione zostały rodzaje komunikatów i zdarzeń rozsyłanych pomiędzy agentami i zarządcami:

Rys. 3 Komunikaty protokołu SNMP

Wady protokołu SNMP
Warto podkreślić, że praktycznie każdy producent sprzętu sieciowego uznaje SNMP za standard i implementuje jego obsługę w swoich urządzeniach. Dzięki temu została zapewniona kompatybilność urządzeń sieciowych pochodzących od różnych producentów. Zwiększa to użyteczność protokołu, bo zamiast tracić czas na pisanie odpowiednich rozszerzeń konwertujących różne sposoby przesyłania wiadomości kontrolnych, całość po prostu działa. Nie należy także bagatelizować prostoty SNMP. Pozwala ona szybką wymianę danych i sprawia, że SNMP prawie w ogóle nie obciąża urządzenia, na którym pracuje.

Trzeba jednak przyznać, że prostota nigdy nie szła w parze z bezpieczeństwem. Reguła ta potwierdza się w przypadku SNMP. Najpopularniejsza i zarazem najprostsza wersja protokołu niestety jest podatna na szereg ataków. Intruz może stosunkowo łatwo przechwycić community-string, a następnie uwierzytelnić się za jego pomocą i całkowicie zmienić konfigurację monitorowanego urządzenia.

Konfiguracja SNMP

Powyższe akapity objaśniły podstawy protokołu SNMP niezbędne do jego implementacji. Czas zakasać rękawy i rozpocząć przystosowywanie swojej sieci do obsługi protokołu SNMP

Konfiguracja SNMP na urządzeniach sieciowych
Ponieważ wiele przedsiębiorstw, niezależnie od wielkości, buduje swoją sieć w oparciu o rozwiązania firmy Cisco, spróbujmy skonfigurować SNMP na routerze (czy też przełączniku) tej marki. Jeśli w sieci, którą się opiekujesz, działają urządzenia pochodzące od innego producenta, to z dużym prawdopodobieństwem również i one obsługują protokół SNMP. Dodatkowo, możesz liczyć, że popularność systemu operacyjnego Cisco IOS odcisnęła piętno także na sposobie ich konfiguracji.

Poniższy zestaw komend został tak dobrany, by możliwie jak najbardziej schematycznie potraktować zagadnienie i móc posłużyć jako wytyczne dla wszelkiej maści urządzeń sieciowych.

Warto wspomnieć, że większość routerów Cisco może odgrywać rolę zarówno zarządcy SNMP, jak i agenta. My zajmiemy się tylko drugim przypadkiem, głównie z powodu słabej dokumentacji dotyczącej wykorzystywania routera jako zarządcy, ale również ze względu na wyjątkowo niską jakość pracy z zarządcą w środowisku IOS.

Zacznijmy od skonfigurowania dostępu do routera poprzez protokół SNMP. Jak wiemy z wcześniejszej części hasła, jedynym parametrem wymaganym przy zestawianiu połączenia zarządca-agent jest community-string pełniący rolę hasła.

celt(config)#snmp-server community public ro
celt(config)#snmp-server community abrakadabra rw 50

celt(config)#access-list 50 permit 10. 6
celt(config)#access-list 50 permit 10. 7

Pierwsza z komend ustawia wartość community-string na “public” dla dostępu po SNMP w trybie RO (tylko dla odczytu). Druga komenda ogranicza dostęp do SNMP w trybie RW (odczyt-zapis) tylko do osób znających hasło “abrakadabra”, których adresy IP nie zostaną zablokowane przez listę dostępową (ang. Access Control List, ACL) o numerze 50.

Należy zdawać sobie sprawę z tego, że nawet po zastąpieniu domyślnej wartości łańcucha (“private”) skomplikowanym ciągiem znaków i tak będzie on przesyłany przez sieć w jawnej postaci. Stąd, tak ważne jest, abyś odpowiednio strzegł dostępu do trybu RW za pomocą mechanizmu ACL (choć i tu niestety, ewentualny intruz ma pewne pole do popisu – spoofing). Niezabezpieczony dostęp do trybu RW pozwala bowiem na całkowite przejęcie kontroli nad routerem.

Dociekliwy czytelnik zauważy, że do obsługi SNMP w całej sieci wystarczy jeden zarządca. Dlaczego więc pozwalamy na dostęp i drugiej maszynie? Powód jest prosty: w przypadku awarii jednej z maszyn, drugie stanowisko umożliwi nam bezproblemowe i nieprzerwane zarządzanie siecią. Dodatkowo, korzystając z możliwości protokołu SNMPv2, możemy tak ustawić obu zarządców, by jednocześnie sprawowali opiekę nad siecią i wymieniali między sobą pozyskane informacje. Kluczem do takiej konfiguracji jest obsługa wspomnianego wcześniej komunikatu InformRequest (wersje protokołu SNMP począwszy od drugiej).

Nic nie stoi na przeszkodzie, aby za pomocą ACL ograniczyć dostęp także do trybu RO. Dodatkowo, możesz zdefiniować widok (ang. view), który wprowadzi kolejne restrykcje dostępu do poszczególnych obiektów drzewa MIB.

celt(config)#snmp-server community prawiewszystko ro view bezRoutingu

celt(config)#snmp-server view noRouteTable internet included
celt(config)#snmp-server view noRouteTable ip. 21 excluded
celt(config)#snmp-server view noRouteTable ip. 22 excluded
celt(config)#snmp-server view noRouteTable ifMIB excluded

Router w powyższej konfiguracji nie udostępni odpytującemu informacji o tablicach routingu. Przez jednych może to być postrzegane jako restrykcja, inni mogą to odebrać jako ochronę zarządcy przed zalaniem go (zbyt) dużą ilością danych.

Pułapki – ustawianie parametrów do monitorowania

Po skonfigurowaniu bezpiecznego dostępu do urządzenia sieciowego, warto wdać się w głębsze dostrajanie działającego nań agenta. Prawdopodobnie jedyne, o czym teraz myślisz, to odpowiednie skonfigurowanie pułapek, czyli komunikatów trap. Właściwie, to nie możesz myśleć o niczym innym, bo SNMP to tak prosty protokół, że nie pozostało nam już praktycznie nic innego, niż zajęcie się pułapkami.

Przypomnijmy, że pułapka to komunikat wysyłany przez agenta działającego na urządzeniu sieciowym, informujący o zdefiniowanym problemie. Uruchamiamy obsługę pułapek na routerze:

celt(config)#snmp-server enable traps

Za pomocą poniższych komend włączysz tylko specjalnie zdefiniowane rodzaje pułapek:

snmp-server enable traps frame-relay
snmp-server enable traps envmon temperature

Aby komunikat o zdarzeniu został wysłany do zarządcy, router musi znać jego adres:

celt(config)#snmp-server host 10. 6 jawnehaslo

Po wydaniu powyższej komendy, router rozpocznie przesyłanie komunikatów trap do zarządcy o numerze IP 10. 6, uwierzytelniając się łańcuchem “jawnehaslo”. Możemy również rozsyłać pułapki do wielu zarządców, segregując je ze względu na typ:

celt(config)#snmp-server host 10. 6 jawnehaslo snmp envmon
celt(config)#snmp-server host 10. 7 jawnehaslo2 snmp bgp

Zgodnie z powyższym, pierwszy zarządca (10. 6) otrzyma komunikaty dotyczące SNMP i ENVMON, a drugi odbierze komunikaty SNMP i BGP. Takie rozgraniczenie jest korzystne, jeśli siecią opiekuje się kilku administratorów, a każdy z nich specjalizuje się w innych zagadnieniach. Dodatkowo, powyższa metoda może pomóc przy sporządzaniu dziennika zdarzeń, trzymanego na innej maszynie.

Z pewnością najbardziej przydatną administratorowi pułapką jest config. Dzięki niej możesz monitorować kto i kiedy wprowadził zmiany w konfiguracji routera. Kolejnym rarytasem jest pułapka o nazwie syslog. Za jej pomocą możesz wymusić konwersję komunikatów o błędach (pokazujących się zwykle w konsoli) do formatu SNMP i przesyłanie ich do zarządcy. Przydatne zwłaszcza, jeśli nie masz możliwości uruchomienia osobnego serwera syslog w swojej sieci.

Niektóre sieci mają skomplikowaną budowę. Poniższe komendy pozwalają łatwiej odnaleźć się w gąszczu konfigurowanych urządzeń:

snmp-server contact Jan Kowalski, NetCorp, tel. 888123456
snmp-server location pok 303, Palac Kultury i Nauki, Warszawa

Wreszcie, aby zbadać, czy konfiguracja SNMP przynosi spodziewane rezultaty, użyj komendy show snmp, która pokaże wszystkie wiadomości na temat obsługi SNMP na Twoim routerze.

Konfiguracja SNMP na stacjach roboczych

SNMP nie należy utożsamiać wyłącznie z urządzeniami sieciowymi typu routery, switche, czy drukarki. Równie ważne pod względem monitoringu i zarządzania są zwykłe stacje robocze, często wyposażone w krytyczne dla firmy oprogramowanie.

Zacznijmy od skonfigurowania agentów na najpopularniejszym wśród użytkowników końcowych systemie operacyjnym – Windows XP. Konfiguracja usług SNMP na systemach Windows NT, 2000, czy 2003 Server jest analogiczna.

Microsoft Windows
Istnieje sporo niezależnych wersji agentów, które bez problemu dają się zainstalować na Windows XP. Wiele z nich przychodzi od razu w pakiecie z zarządcą. Jeśli jednak oprogramowanie SNMP używane w twojej sieci nie ma własnej wersji agenta, możesz rozważyć instalację domyślnej usługi systemowej Windows XP. Potrafi ona współpracować z zewnętrznymi zarządcami.

Aby zainstalować usługę SNMP, wykonaj następujące kroki:

1. Przejdź do panelu sterowania.
2. Kliknij ikonę Dodaj lub usuń programy.
3. Wybierz Składniki systemu Windows z panelu po lewej stronie.
4. Zaznacz Narzędzia zarządzania i monitorowania i kliknij Dalej.

Instalator poprosi o włożenie płyty instalacyjnej, a następnie skonfiguruje Windows do obsługi SNMP. pl/wp-content/uploads/2016/08/04-300x217. png" alt="Protokół SNMP – gromadzenie danych o sieci" width="629" height="329"/>

Rys. 4 Instalacja usługi agenta SNMP w Windows XP

Wszelkie parametry agenta SNMP można ustawić w konsoli services. msc. Aby się do niej dostać, otwórz Panel sterowania/Narzędzia administracyjne/Usługi. Odszukaj na liści i kliknij dwukrotnie pozycję Usługa SNMP. pl/wp-content/uploads/2016/08/05-261x300. png" sizes="(max-width: 459px) 100vw, 459px" srcset="https://itfocus. pl/wp-content/uploads/2016/08/05-32x32. png 32w, https://itfocus. pl/wp-content/uploads/2016/08/05-50x50. png 50w, https://itfocus. pl/wp-content/uploads/2016/08/05-64x64. png 64w" alt="Protokół SNMP – gromadzenie danych o sieci" width="459" height="451"/>

Rys. 5 Konfiguracja usługi agenta SNMP w Windows XP

Najistotniejsze opcje znajdują się na zakładce Zabezpieczenia – to właśnie tam możesz zdefiniować community-string i listę komputerów, którym agent zezwoli na dostęp do konfiguracji i monitorowania systemu.

Szczegółowe wskazówki i zalecenia dotyczące konfiguracji SNMP w systemie Windows znaleźć można na stronie http://support. microsoft. com/kb/315154/pl

Przetestuj SNMP
Narzędzia z pakietu net-snmp implementują poszczególne komunikaty protokołów SNMPv1, SNMPv2 i SNMPv3. Za ich pomocą możesz przetestować konfigurację SNMP w Windows z linii polecenia. Zamiast zdobywać pojedyncze wartości obiektów przy użyciu snmpget. exe, odczytaj wszystkie obiekty z gałęzi systemowej, używając programu snmpwalk. exe.

Pakiet net-snmp dostępny jest zarówno dla systemów Windows jak i Linux. Możesz go pobrać ze strony http://net-snmp. sourceforge. net/.

Uruchom wiersz polecenia i wpisz poniższe komendy:
cd usr\bin
snmpwalk -Os -c public -v 1 127. 0. 1 system

Zwrócą one następujące wyniki:

sysDescr. 0 = STRING: Hardware: x86 Family 15 Model 4 Stepping 10 AT/AT
COMPATIBLE – Software: Windows 2000 Version 5. 1 (Build 2600
Uniprocessor Free)
sysObjectID. 0 = OID: enterprises. 311. 1
sysUpTimeInstance = Timeticks: (10394776) 1 day, 4:52:27. 76
sysContact. 0 = STRING:
sysName. 0 = STRING: CELT
sysLocation. 0 = STRING:
sysServices. 0 = INTEGER: 76

Aby przejrzeć (zapisując do pliku) całe drzewo MIB udostępniane przez agenta w systemie Windows XP, możesz wydać komendę:

snmpwalk -Os -c public -v 1 127. 1 > drzewo. txt

GNU/Linux
Do obsługi SNMP na komputerach pracujących pod kontrolą systemu Linux potrzebujesz daemona snmpd. Jego instalacja różni się w zależności od dystrybucji Linuksa, z której korzysta twoja firma (przykładowo: apt-get install snmd w Debianie lub emerge snmpd w Gentoo). Warto od razu zainstalować narzędzia wchodzące w skład paczki snmp. Pozwolą one na wykonywanie podstawowych czynności diagnostycznych.

Zwróć uwagę, że daemon snmpd występuje w roli agenta SNMP, a nie serwera! Warto o tym pamiętać, gdyż konwencje nazw i zwyczaje panujące w systemach *niksowych w przypadku SNMP mogą wprowadzać w błąd.

Plik konfiguracyjny agenta SNMP to /etc/snmp/snmpd. conf – to właśnie tam możesz ograniczyć dostęp do agenta z zewnątrz, ustawić community-string, itd. Tak jak w przypadku Windows, po zainstalowaniu i wstępnych ustawieniach SNMP, zaleca się przeprowadzenie testów konfiguracji narzędziami z pakietu net-snmp.

Praktyczne wykorzystanie SNMP
Zainstalowaliśmy już agenty zarówno na urządzeniach sieciowych, jak i stacjach roboczych pracujących pod kontrolą Windows oraz Linuksa. Skonfigurowaliśmy odpowiednie community-string i ograniczyliśmy dostęp jedynie do zaufanej stacji administratora. Pora zacząć korzystać z udostępnianych danych!

MRTG – monitorowanie interfejsów sieciowych
MRTG (Multi Router Traffic Grapher) to darmowe oprogramowanie służące do monitorowania obciążenia łączy sieciowych, przedstawiające wyniki w postaci wykresu. Program został napisany w Perlu i działa zarówno w systemach Microsoftu, jak i plaftormach *niksowych. Pobierzesz go ze strony http://oss. oetiker. ch/mrtg.

MRTG, za pomocą protokołu SNMP, w równych odstępach czasu odpytuje agentów o wartości obiektów w drzewie MIB. Gromadzone dane przedstawia w postaci strony WWW zawierającej odpowiednie wykresy.

Konfiguracja MRTG jest prosta, i wygląda tak samo dla obu systemów operacyjnych. Wystarczy wskazać na agenta, uwierzytelnić się odpowiednim community-string i wyszczególnić, które z OID chcemy monitorować. Reszta odbywa się automatycznie.

1. Utwórz plik konfiguracyjny dla MRTG.

xerror@szynszyl:~# /usr/bin/cfgmaker \
–output=/etc/mrtg/celt_traffic. cfg \
–global “WorkDir: /var/www/localhost/htdocs/mrtg” \
–global “Options[_]: bits, growright” \
public@127. 1

Jak widać, pliki zawierające dane zbierane przez MRTG znajdować będą się w katalogu /var/www/localhost/htdocs, a odpytywany agent pracuje na lokalnym komputerze (127. Uwierzytelnianie następuje za pomocą community-string ustawionego na public.

MRTG obsługuje język polski. Zmienną language w pliku konfiguracyjnym (tu: /etc/mrtg/celt_traffic. cfg) można ustawić na polish.

2. Utwórz strukturę strony WWW przedstawiającej wyniki.

xerror@szynszyl:~# indexmaker \
–output var/www/localhost/htdocs/mrtg/index. html \
/etc/mrtg/celt_traffic. cfg

3. Uruchom MRTG poleceniem
mrtg /etc/mrtg/celt_traffic. cfg

By zapewnić automatyczną aktualizację wykresów, poniższe polecenie warto dodać do crontaba:

xerror@szynszyl:~# crontab -e
*/5 * * * * /usr/bin/mrtg /etc/mrtg/celt_traffic. cfg

Dzięki temu MRTG będzie uaktualniał swoje dane co pięć minut.

Po chwili, MRTG powinien zebrać już dostatecznie dużo danych, by wygenerować czytelny wykres, dostępny pod adresem http://127. 1/mrtg. pl/wp-content/uploads/2016/08/06-300x81. png" alt="Protokół SNMP – gromadzenie danych o sieci" width="656" height="252"/>

Rys. 6 Wykres obciążenia interfejsów wygenerowany przez program MRTG.

Oczywiście wcale nie musisz ograniczać MRTG do zbierania danych wyłącznie na temat obciążenia interfejsów. Równie dobrze możesz badać liczbę aktywnych użytkowników w sieci czy też liczbę użytkowników zalogowanych na router za pomocą SSH lub telnetu. pl/wp-content/uploads/2016/08/07-300x103. png" alt="Protokół SNMP – gromadzenie danych o sieci" width="657" height="201"/>

Rys. 7 Monitorowanie liczby użytkowników w sieci.

MRTG przewidziany został do użytku na maszynach z uruchomionym serwerem WWW (np. IIS w indows lub Apache do Linuksa). Dzięki temu, administrator ma dostęp do najświeższych wykresów z każdego miejsca w sieci, które pozwala na połączenie HTTP z komputerem z uruchomionym MRTG. Serwer HTTP nie jest jednak warunkiem koniecznym do pracy MRTG. Bez aktywnego serwera HTTP wykresy dalej będą generowane, jednakże dostęp do nich będzie można uzyskać tylko lokalnie.

Network Management Systems
MRTG to prosty przykład programu wykorzystującego protokół SNMP do monitorowania i analizy trendów w sieci. Nie ulega wątpliwości, że większe sieci potrzebują poważniejszych rozwiązań. Dlatego właśnie powstały rozbudowane aplikacje zarządzania siecią (Network Management Systems, NMS).

NMS, oprócz standardowych zadań monitoringu agentów, może zapewniać również tak zaawansowane funkcje, jak graficzne przedstawienie topologii sieciowej, automatyczne tworzenie dokumentacji i dziennika zdarzeń, generowanie zaawansowanych raportów, grupowanie logiczne i fizyczne urządzeń sieciowych, możliwość długofalowego planowania strategii rozwoju sieci, analizowanie trendów i ryzyka.

Mówiąc o NMS-ach, grzechem byłoby nie wspomnieć o takim oprogramowaniu, jak Tivoli (IBM), MOM (Microsoft) czy OpenView (Hewlett-Packard). Są to potężne kombajny, opierające swoje funkcje nie tylko na protokole SNMP, ale również na szeregu innych źródłach danych o sieci. Wdrożenia w/w systemów zazwyczaj są jeszcze droższe od wykupienia samej licencji, stąd pozwolić na nie mogą sobie przeważnie firmy z potężnie rozwiniętymi sieciami, międzynarodowe korporacje lub banki, w których monitoring i zarządzanie odgrywa istotną rolę.

Niestety, jedną z wad systemów monitoringu sieci jest ich prawie całkowita niekompatybilność. Większość z NMS-ów to naprawdę rozbudowane i zaawansowane aplikacje, które nierzadko wprowadzają swój własny pseudojęzyk służący do konfiguracji środowiska monitoringu.

Jeśli jednak pracujesz w średniej wielkości firmie, nie załamuj się. Istnieje kilka mocno rozbudowanych aplikacji, za które wcale nie musisz płacić! Poniżej wymieniamy najważniejsze z nich, okraszone tylko krótkim opisem, gdyż systemy te nie polegają wyłącznie na protokole SNMP, a więc wykraczają poza ramy tego artykułu.

OpenNMS
OpenNMS (www. opennms. org/index. php/Main_Page) jest próbą stworzenia otwartego i darmowego systemu zarządzania siecią, który byłby konkurencyjny w stosunku do znanych, komercyjnych rozwiązań, takich jak Tivoli czy OpenView. OpenNMS pozwala między innymi na logowanie zdarzeń z kilkunastu urządzeń, rozproszone monitorowanie sieci i zarządzanie wszelkiego rodzaju operacjami konserwacyjnymi. Informacje o konfiguracji OpenNMS znajdziesz na stronie www. howtoforge. com/opennms_network_management.

BigSister
Rozbudowany system zarządzania siecią, monitorujący pracę węzłów i raportujący awarie. Obsługuje SNMP, potrafi monitorować bazy danych Oracle, serwery DNS, serwery Radius i wiele innych protokołów. BigSister tworzy rozbudowane raporty, stara się być kompatybilny z wieloma innymi programami, co ważniejsze, obsługuje wtyczki i udostępniany jest w wersji zarówno do Windows jak i systemów *niksowych. BigSister to dojrzały NMS, zdecydowanie warty przetestowania. Możesz go pobrać ze strony www. bigsister. ch.

Nagios
Hasłem przewodnim Nagiosa jest “informowanie Cię o problemach w sieci, zanim zostaniesz o nich poinformowany przez użytkowników”. Program pracuje pod kontrolą Linuksa, nieustannie monitorując usługi działające na poszczególnych węzłach sieci. Administrator ma do dyspozycji całkiem elastyczny mechanizm wtyczek oraz świetne możliwości alarmowania o problemach (e-mail, SMS, komunikator internetowy). Dodatkowo, Nagios udostępnia większość zbieranych przez siebie danych w postaci strony internetowej, która może być dostępna z każdego miejsca w sieci. Program dostępny na stronie www. nagios. org.

The Dude
Działający pod kontrolą systemu Windows The Dude to prawdziwa perełka. Oprócz standardowych prac związanych z monitorowaniem i zarządzaniem urządzeniami sieciowymi, potrafi wykryć i rozrysować topologię sieci. Współpracuje z mapami. The Dude jest naprawdę prosty i przyjemny w użyciu, co nie zawsze jest regułą w systemach zarządzania siecią! Program do pobrania ze strony www. mikrotik. com/thedude. php.

Oprócz znanych na świecie zagranicznych systemów zarządzania siecią, warto bliżej przyjrzeć się rodzimej produkcji – systemowi David (www. david. lodz. pl), który od blisko siedmiu lat wspomaga pracę Centrum Komputerowego Politechniki Łódzkiej, zarządzając pracą sieci LODMAN i POL34.

Przyszłość SNMP
Wersja trzecia protokołu SNMP nie odniosła zbyt wielkiego sukcesu, nawet pomimo powszechnego zrozumienia i akceptacji dla wprowadzonych mechanizmów bezpieczeństwa. Wygląda na to, że prostota prawie dwudziestoletniej koncepcji SNMPv1 jest nie do pobicia i skutecznie wrosła już w umysły niezbyt skorych do zmian administratorów sieci.

Nie należy jednak zapominać, że każdy może kształtować przyszłość SNMP – jeśli nie w skali światowej, to chociaż na prywatnym podwórku… SNMP API (ang. Application Program Interface) powstało już prawie dla każdego języka. Z ważniejszych warto wymienić netsnmpj dla Javy (http://netsnmpj. net) i Net::SNMP dla Perla (http://search. cpan. org/dist/Net-SNMP).

Jakby tego było mało, do realizacji własnych pomysłów można posłużyć się gotowymi implementacjami SNMP, chociażby ze wspomnianego już pakietu net-snmp. W końcu jedną z najważniejszych cech dobrego administratora sieci jest zdolność powiększania swojego czasu wolnego poprzez udoskonalanie narzędzi sieciowych!

Alternatywy dla SNMP
Jak wielokrotnie podkreślaliśmy w tym artykule, SNMP jest podstawowym i najprostszym sposobem zbierania informacji o pracy sieci, zwłaszcza tych nieskomplikowanych. Jeśli na co dzień zmagasz się z siecią o dużym natężeniu ruchu, a interesują Cię głównie statystyki ilościowe dotyczące IP, warto byś zapoznał się z protokołem NetFlow (www. com/go/netflow). Jest to alternatywa dla SNMP, stworzona specjalnie na potrzeby rozbudowanych sieci komputerowych zbudowanych na urządzeniach Cisco.