SNMP w teorii – prosty i sprawdzony monitoring sieci

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.1.1.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.3.6.1.2.1.1.5.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.3.6.1.4.1.9.2.1.3.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. (podziękowania dla Pawła za wyłapanie, że ten fragment wprowadza w błąd – artykuł został zaktualizowany o treść poniżej)

Warto zwrócić uwagę na to, że SNMPv3 nie sprawdza integralności pakietu by default – aby to zachodziło wymagana jest dodatkowa konfiguracja.

Data integrity do działania wymaga skonfigurowania uwierzytelniania (username+password) oraz właściwego poziomu zabezpieczeń (security level, opisanego poniżej): authNoPriv lub authPriv. Dopiero wtedy zaczyna być wykorzystywany jeden z mechanizmów haszowania (MD5 lub SHA) – generowany jest hash, który jest dołączany do pakietów SNMP i pozwala na weryfikację ich integralności.

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.