Zapewnianie bezpieczeństwa protokołu SNMP

Określenie „simple” niezbyt trafnie oddaje charakter protokołu SNMP (Simple Network Management Protocol). Jest dość złożony, a w dodatku z biegiem czasu roz­winął wiele nowych funkcjonalności. Termin „simple” odnosi się do faktu, że jego podstawowym zadaniem jest odczytywa­nie lub ustalanie parametrów urządzenia lub jego komponentu (np. licznika bajtów interfejsu sieciowego, nazwy itp.).

Sam protokół nie zajmuje się przetwarzaniem i prezentacją pozyskanych informacji. Do tego celu służy wyspecjalizowa­ne oprogramowanie managera. Standardy RFC, które opisują SNMP, z czasem wprowadziły wiele elementów komplikują­cych możliwe zastosowania SNMP – np. AgentX – czy ele­menty zabezpieczające, które będą głównym tematem tego tekstu. Ale wciąż SNMP ma za podstawowe zadanie to samo: odczyt i zapis pewnych parametrów. W dalszej części artykułu poznasz bezpieczne sposoby korzystania z SNMP na przykła­dzie Cisco IOS (do testów wykorzystamy uniksowy pakiet net­-snmp). Ale zanim to nastąpi, kilka słów na temat zasad dzia­łania tego protokołu.

Systemy zarządzania oparte na SNMP składają się zazwy­czaj z dwóch podstawowych elementów: agenta i managera. Każde z kontrolowanych urządzeń ma uruchomionego agenta, który komunikuje się z managerem. Manager często jest określany mianem Network Management System (NMS).

Jest to często bardzo rozbudowana aplikacja pozwalająca z jed­nego miejsca dokonać prezentacji krytycznych parametrów śro­dowiska informatycznego, konfigurować je zdalnie, śledzić trendy itp.

Agent uruchamiany na zarządzanej stacji ma za zadanie zbiera­nie i przetwarzanie informacji o stanie urządzenia. Mogą to być przykładowo parametry dotyczące wykorzystania CPU, pamięci czy przestrzeni dyskowej. Agent przechowuje informacje o tych parametrach w bazie MIB (Management Information Base). Jest zorganizowana w sposób drzewiasty. Drzewo to jest zgodne z tzw. SMI (Structure of Management Information) opisanym w RFC 1115 i 2578. Każdy parametr, który może być zarządza­ny przez SNMP, to „liść” tego drzewa i zostaje jednoznacznie zidentyfikowany przez ciąg liczb prowadzących do niego.

Rysunek 1. Drzewiasta struktura bazy MIB

Liczbom na każdym poziomie drzewa są przyporządkowa­ne również nazwy łatwiejsze do interpretacji przez człowieka. Taki ciąg liczb opisujący parametr jest nazywany jego OID-em (Object IDentifier).

Dla przykładu ciąg 1.3.6.1.2.1.1.3.0 oznacza OID iso.org.dod.internet.mgmt.system.sysUpTime.0.

Jak się łatwo domyślić, parametr ten określa czas od uruchomienia procesu agenta, czyli w przybliżeniu czas pracy systemu.

OID ma również swój typ – dla przykładu OID odpowiadający nazwie hosta będzie posiadał typ STRING, ale licznik ramek wysłanych przez interfejs będzie typu Counter. Typy te są pod­zbiorem standardu ASN.1 i uniezależniają przesyłane wartości od architektury sprzętowej.

Drugą funkcją agenta jest dostarczanie informacji do NMS. Informacja ta może być przekazywana na żądanie managera lub wysyłana, gdy zajdzie jakieś zdarzenie. NMS może zażądać informacji, wysyłając następujące polecenia:

GET – wysyłane jest żądanie wartości dla listy OID-ów. Stacja zwraca wartości tych parametrów. Przykładem imple­mentacji tego polecenia w net-snmp jest snmpget;

GET-NEXT – powoduje przesłanie do NMS całego poddrze­wa, począwszy od żądanego punktu. Tu odpowiednikiem w net-snmp jest snmpwalk;

GET-BULK – jeśli żądanie GET zawiera tak dużo parametrów, że agent nie może ich wysłać, zostanie zwrócona pusta odpo­wiedź. Jeżeli zostanie użyte GET-BULK, agent zwróci tak dużo informacji, ile pozwala na to jego implementacja. Jest to więc najlepsze narzędzie do odpytywania o większą liczbę parame­trów. Polecenie net-snmp realizujące tę funkcję to snmpbulkget.

NMS może również zażądać ustawienia jakiegoś parametru. Jest to realizowane przez funkcję SET (np. polecenie snmpset z pakietu net-snmp).

Omówione do tej pory działania SNMP były wykonywane przez agenta na żądanie NMS. Agent może także informować managera o zajściu pewnych zdarzeń. Najprostszym sposobem wykonania tego zadania jest wysłanie przez agenta komuni­katu TRAP. NMS musi być skonfigurowany do odbioru tego typu komunikatów. Komunikaty TRAP są wysyłane po zajściu pewnych skonfigurowanych zdarzeń, np. dezaktywacja któ­regoś z interfejsów. Podstawową wadą tego sposobu przeka­zywania informacji jest brak potwierdzenia otrzymania przez NMS.

Inną metodą używaną do tego celu jest tzw. INFORM. Ten komunikat został dodany z myślą o komunikacji NMS-NMS, ale może być wykorzystywany również przez agenta. Podstawową różnicą w stosunku do TRAP jest wysłanie potwierdzenia przez odbiorcę, czyli większa niezawodność komunikacji. Oczywiście stanie się tak, jeśli agent ma zaimplementowane powtórzenie transmisji przy braku potwierdzenia.

Komunikaty są wysyłane za pomocą datagramów UDP. Odpytywanie przez NMS jest skierowane na port 161 agenta, natomiast powiadomienia typu trap lub inform są wysyłane na port 162 NMS. Istnieją rozwiązania pozwalające na transportowanie komunikatów innymi protokołami, ale nie znajdują szerszego zastosowania w praktyce.

Bazy MIB umieszczone na agentach muszą obsługiwać para­metry, które są często właściwe tylko dla danego urządzenia. Oczywiście wiele parametrów (nazwa urządzenia, liczni­ki pakietów na interfejsach itd.) jest wspólnych dla większo­ści urządzeń, ale MIB musi być rozszerzalny. Dlatego agenci dostarczani przez producenta mają często własne gałęzie w SMI. Są rejestrowane jako podgałęzie iso, org, directory, mgmt, experimental (3), private (4). Ważne jest, aby NMS rozumiał te gałęzie. Dlatego należy w takim przypadku pozyskać te fragmenty MIB i zainstalować je na NMS (tzw. kompilacja MIB). W odniesieniu do MIB dla urządzeń Cisco można je pozyskać ze strony www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

Aby dopełnić obrazu SNMP, warto jeszcze wspomnieć o tech­nologii związanej z SNMP, a często używanej w urządzeniach Cisco. Jest to RMON. Zamiast uru­chamiać agenta na poszczególnych urządzeniach sieciowych i monitorować każde z nich osobno, można zastosować dedy­kowane sondy nasłuchujące ruch w segmencie sieci. Sonda taka jest w stanie wysyłać powiadomienia do NMS lub być przez niego odpytywana. Pozwala to na odciążenie właściwych urządzeń. Oczywiście parametry zbierane przez sondę mogą dotyczyć tylko ruchu, który jest w stanie „usłyszeć”. RMON może służyć np. do wykrywania natłoku ruchu, błędów w transmisji itp. Ciekawym zastosowaniem RMON jest skonfigurowanie go na śledzonym urządzeniu, a nie na dedykowanej sondzie.

Taką możliwość mają też rutery i przełączniki Cisco. W takim przypadku można skonfigurować wartości graniczne parametrów, po których przekroczeniu RMON wygeneruje powiadomienie typu trap lub inform (oczywiście można wtedy monitorować również parametry inne niż tylko sieciowe). Przykładowo rozsąd­ne będzie ustalenie progu, np. 80%, wykorzystania procesora, po której RMON powiadomi NMS o tym fakcie. Druga wartość, np. 60%, będzie wyzwalała powiadomienia o spadku wykorzystania procesora poniżej tej wartości – powrotu do stanu akceptowal­nego. W takim zastosowaniu RMON ma jedną zasadniczą przewagę nad zwykłymi powiadomieniami. Tradycyjne komuni­katy trap lub inform są wyzwalane zdefiniowanymi przez producenta zdarzeniami (np. utrata linku na interfejsie).

Korzystając z RMON, możesz monitorować warto­ści parametrów i wyzwalać na ich podstawie powia­domienia w sposób bardziej elastyczny. Niestety, RMON nie jest wyposażony w zabezpieczenia, który­mi zajmujemy się w tym artykule, więc potraktujemy go tylko jako ciekawostkę.