Untitled

Transkrypt

Untitled

Łukasz Witaszek
1
Nowoczesne sposoby zarządzania sieciami – protokół NetFlow
Spis treści
WYKAZ SKRÓTÓW…………………………………………………………………………………………………………………………..4
WYKAZ RYSUNKÓW………………………………………………………………………………………………………………………..6
WYKAZ TABEL……………………………………………………………………………………………………………………………......8
1
WSTĘP ............................................................................................................................... 9
1.1
SYSTEMY INFORMATYCZNE ......................................................................................................... 10
1.2
SIEĆ KOMPUTEROWA ................................................................................................................ 10
1.3
MODEL ZARZĄDZANIA SIECIĄ KOMPUTEROWĄ................................................................................ 11
2
CEL I ZAKRES PRACY ......................................................................................................... 14
3
MONITOROWANIE SIECI KOMPUTEROWYCH – ZAGADNIENIA PODSTAWOWE .................. 15
4
3.1
METRYKI SIECIOWE .................................................................................................................. 15
3.2
TYPY MONITOROWANIA ............................................................................................................ 17
3.3
WYMAGANIA STAWIANE SYSTEMOM MONITOROWANIA .................................................................. 17
3.4
OGRANICZENIA W MONITOROWANIU ........................................................................................... 18
TRADYCYJNE METODY ZARZĄDZANIA............................................................................... 20
4.1
4.1.1
Działanie protokołu SNMP......................................................................................... 21
4.1.2
Monitorowanie z wykorzystaniem SNMP .................................................................. 23
4.1.3
Ograniczenia SNMP ................................................................................................... 24
4.2
PROTOKÓŁ RMON .................................................................................................................. 24
4.2.1
Działanie protokołu RMON ....................................................................................... 25
4.2.2
Grupy zebrane w RMON v.1 MIB ............................................................................... 27
4.2.3
RMON2 ...................................................................................................................... 28
4.2.4
Monitorowanie z wykorzystaniem RMON – przykład ............................................... 29
4.3
5
PROTOKÓŁ SNMP ................................................................................................................... 20
SNMP I RMON – MOŻLIWOŚCI I OGRANICZENIA .......................................................................... 30
NOWOCZESNE METODY MONITOROWANIA – IDEA IPFIX ................................................. 32
5.1
„PRZEPŁYWOWY” SYSTEM MONITOROWANIA SIECI ......................................................................... 32
5.2
IPFIX – NOWY STANDARD MONITOROWANIA PRZEPŁYWÓW ............................................................. 35
5.2.1
Pierwsze implementacje producentów...................................................................... 35
5.2.2
Standard IPFIX – RFC 3917 ........................................................................................ 36
5.3
IPFIX ORAZ NETFLOW – WSPÓLNE PODSTAWY .............................................................................. 37
5.3.1
Pojęcia podstawowe.................................................................................................. 37
Samodzielny Zakład Sieci Komputerowych PŁ,
grudzień 07
Łukasz Witaszek
2
5.3.2
5.4
6
Aplikacje korzystające z IPFIX .................................................................................... 41
5.4.2
Rozróżnianie przepływów .......................................................................................... 42
5.4.3
Wymagania stawiane procesowi monitorowania ..................................................... 43
5.4.4
Model informacji – jakie informacje o przepływach są eksportowane ..................... 45
5.4.5
Model danych – jak skonstruowany jest rekord przepływu....................................... 47
5.4.6
Przesyłanie danych – co należy wziąć pod uwagę ..................................................... 47
5.4.7
Zagadnienia konfigurowania sondy .......................................................................... 48
5.4.8
Zalecenia ogólne........................................................................................................ 49
5.4.9
Lokalizacja punktów obserwacji i procesów IPFIX ..................................................... 50
5.4.10
Zagadnienia bezpieczeZstwa ..................................................................................... 51
NETFLOW V.9 – CISCO IMPLEMENTUJE IPFIX .................................................................... 53
RFC3954 - CISCO SYSTEMS NETFLOW SERVICES EXPORT VERSION 9 ................................................ 53
6.1.1
Pojęcia podstawowe.................................................................................................. 53
6.1.2
Proces tworzenia przepływów ................................................................................... 55
6.1.3
Dostęp do danych przepływów – poprzez interfejs urządzeZ .................................... 58
6.1.4
Dostęp do danych przepływów - proces eksportowania przepływów ....................... 59
6.1.5
Struktura pakietu eksportowego (ang. Packet Layout) ............................................. 60
6.1.6
Formaty zbiorów rekordów (ang. FlowSet Format)................................................... 62
6.1.7
Pakiety opcji .............................................................................................................. 64
6.1.8
Zarządzanie wzorcami ............................................................................................... 67
6.1.9
Definicje typów pól opisujących parametry przepływów .......................................... 69
6.1.10
Proces kolektora ........................................................................................................ 74
6.1.11
Zagadnienia bezpieczeZstwa ..................................................................................... 74
6.2
PRZYKŁAD............................................................................................................................... 75
NETFLOW W PRAKTYCE – WSKAZÓWKI IMPLEMENTACYJNE ............................................. 77
7.1
WŁAŚCIWA ARCHITEKTURA SYSTEMU ........................................................................................... 77
7.1.1
Oprogramowanie stacji zarządzania ......................................................................... 77
7.1.2
Rozmieszczenie sond protokołu NetFlow .................................................................. 81
7.2
8
IPFIX – DALSZE ZAŁOŻENIA PROTOKOŁU ....................................................................................... 41
5.4.1
6.1
7
Architektura............................................................................................................... 40
PRZYKŁAD WYKORZYSTANIA NETFLOW - OCHRONA PRZED ATAKIEM ZŁOŚLIWEGO OPROGRAMOWANIA ..... 83
MONITOROWANIE Z WYKORZYSTANIEM NETFLOW ......................................................... 84
8.1
PROGRAM ANALIZUJĄCY PRZEPŁYWY ............................................................................................ 84
8.2
MONITOROWANIE SIECI DOMOWEJ – TOPOLOGIA PROSTA ............................................................... 87
8.2.1
Opis topologii ............................................................................................................ 87
grudzień 07
Łukasz Witaszek
3
8.2.2
Konfiguracja routera Linksys WRT54GL .................................................................... 87
8.2.3
Prezentacja i analiza przepływów ............................................................................. 90
8.3
8.3.1
Opis topologii ............................................................................................................ 96
8.3.2
Konfiguracja routera Cisco 2651 ............................................................................... 96
8.3.3
Prezentacja i analiza przepływów ............................................................................. 98
8.4
10
MONITOROWANIE SIECI W KORPORACJI ...................................................................................... 102
8.4.1
Opis topologii .......................................................................................................... 102
8.4.2
Konfiguracja routera Cisco 2621XM ........................................................................ 103
8.4.3
Prezentacja i analiza przepływów ........................................................................... 103
8.5
9
MONITOROWANIE SIECI DOMOWEJ – TOPOLOGIA ROZBUDOWANA .................................................... 96
WNIOSKI .............................................................................................................................. 106
DALSZY ROZWÓJ METOD MONITOROWANIA ................................................................. 108
9.1
SFLOW ................................................................................................................................. 108
9.2
FLEXIBLE NETFLOW ................................................................................................................ 110
9.3
CISCO NBAR – ROZPOZNAWANIE APLIKACJI ................................................................................ 113
BIBLIOGRAFIA ................................................................................................................ 115
Dodatek A - zawartość nośnika CD-ROM dołączonego do pracy
Dodatek B - raport z systemu Plagiat.pl
grudzień 07
Łukasz Witaszek
4
Wykaz skrótów
ARP
Address Resolution Protocol
ARPANET
Advanced Research Projects Agency Network
BGP
Border Gateway Protocol
CLI
Command Line Interface
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name System
ESP
Encapsulated Security Payload
ICMP
Internet Control Message Protocol
IETF
Internet Engineering Task Force
IOS
Internetwork Operating System
IP
Internet Protocol
IPFIX
IP Flow Information Eoport
IPSec
IP security
ISO
International Organization for Standardization
LAN
Local area network
MAC
Media Access Control
MIB
Management Information Base
MPLS
Multiprotocol Label Switching
NBAR
Network Based Application Recognition
NFCC
NetFlow Feature Card
NMS
Network management station
NNM
HP Network Node Manager
OSI
Open Systems Interconnection Basic Reference Model
P2P
Peer-to-peer
PDLM
Packet Description Language Module
QoS
Quality of service
RFC
Request for Comments
RMON
The Remote Network MONitoring
SCTP
Stream Control Transmission Protocol
TCP
Transmission Control Protocol
TOS
Type of Service
TTL
Time to live
UDP
User Datagram Protocol
UPS
Uninterruptible power supply
UTC
Coordinated Universal Time
grudzień 07
Łukasz Witaszek
5
VLAN
Virtual LAN
VPN
Virtual private network
WAN
Wide area network
WWW
World Wide Web
grudzień 07
Łukasz Witaszek
6
Wykaz rysunków
RYSUNEK 3.1 WYKORZYSTANIE ŁĄCZA W PROTOKOLE ETHERNET ................................................................................... 16
RYSUNEK 3.2 WYKORZYSTANIE ŁĄCZA - Z DEFINICJI ..................................................................................................... 16
RYSUNEK 4.1 SCHEMAT DZIAŁANIA SNMP (3) .......................................................................................................... 22
RYSUNEK 4.2 MRTG - PRZYKŁAD STATYSTYK (10)...................................................................................................... 23
RYSUNEK 4.3 RMON – PRZYKŁAD STATYSTYK ............................................................................................................ 29
RYSUNEK 5.1 PORÓWNANIE 5. I 9. WERSJI NETFLOW ................................................................................................. 36
RYSUNEK 5.2 ALGORYTM PROCESU KLASYFIKOWANIA (24)........................................................................................... 38
RYSUNEK 5.3 ARCHITEKTURA IPFIX ......................................................................................................................... 40
RYSUNEK 5.4 ROZMIESZCZENIE ELEMENTÓW IPFIX W ARCHITEKTURZE SPRZĘTOWEJ (24) .................................................. 50
RYSUNEK 6.1 PROCES ANALIZOWANIA PAKIETÓW ....................................................................................................... 55
RYSUNEK 6.2 TWORZENIE REKORDU PRZEPŁYWU #1 ................................................................................................... 57
RYSUNEK 6.5 TWORZENIE I EKSPORT REKORDÓW PRZEPŁYWÓW .................................................................................... 60
RYSUNEK 6.6 PAKIET EKSPORTOWY (26) .................................................................................................................. 60
RYSUNEK 6.7 NAGŁÓWEK PAKIETU EKSPORTOWEGO (26) ............................................................................................ 61
RYSUNEK 6.8 FORMAT ZBIORU REKORDÓW WZORCA (26)............................................................................................ 62
RYSUNEK 6.9 FORMAT ZBIORU REKORDÓW DANYCH PRZEPŁYWÓW (26) ......................................................................... 63
RYSUNEK 6.10 FORMAT WZORCA ZBIORU REKORDÓW OPCJI (26) .................................................................................. 64
RYSUNEK 6.11 FORMAT ZBIORU REKORDÓW OPCJI (26) .............................................................................................. 66
RYSUNEK 6.12 PRZYKŁAD ZBIORU REKORDÓW WZORCA (26) ........................................................................................ 75
RYSUNEK 7.1 PODZIAŁ ARCHITEKTURY NETFLOW (30) ................................................................................................ 77
RYSUNEK 7.2 KOMPONENTY STACJI ZARZĄDZANIA NETFLOW ........................................................................................ 78
RYSUNEK 8.1 GŁÓWNE OKNO APLIKACJI NETFLOW ANALYZER....................................................................................... 86
RYSUNEK 8.2 TOPOLOGIA PROSTEJ SIECI DOMOWEJ .................................................................................................... 87
RYSUNEK 8.3 EKRAN POMOCY DLA PROGRAMU RFLOW ................................................................................................ 88
RYSUNEK 8.4 URUCHOMIENIE MONITOROWANIA – RFLOW .......................................................................................... 89
RYSUNEK 8.5 ROUTER LINKSYS - CHARAKTERYSTYKA QUICK VIEW #1: INTERFEJS WAN ..................................................... 91
RYSUNEK 8.6 ROUTER LINKSYS - UDZIAŁ APLIKACJI W WYKORZYSTANIU ŁACZA WAN ......................................................... 93
RYSUNEK 8.7 ROUTER LINKSYS - APLIKACJE WYKORZYSTYWANE W KONWERSACJACH ......................................................... 94
RYSUNEK 8.8 ROUTER LINKSYS - ODBIORCY KONWERSACJI ............................................................................................ 94
RYSUNEK 8.9 ROUTER LINKSYS - ŹRÓDŁA KONWERSACJI ............................................................................................... 94
RYSUNEK 8.10 TOPOLOGIA ROZBUDOWANEJ SIECI DOMOWEJ ....................................................................................... 96
RYSUNEK 8.11 EKRAN INFORMACYJNY - ROUTER CISCO 2651 ...................................................................................... 97
RYSUNEK 8.12 URUCHOMIENIE MONITOROWANIA NA CISCO 2651 #1 .......................................................................... 98
grudzień 07
Łukasz Witaszek
7
RYSUNEK 8.15 ROUTER CISCO 2651 - RAPORT TRAFFIC, PERSPEKTYWA VOLUME ............................................................. 99
RYSUNEK 8.16 ROUTER CISCO 2651 - RAPORT TRAFFIC, PERSPEKTYWA VOLUME [20:00-01:00 NASTĘPNEGO DNIA] ............. 99
RYSUNEK 8.17 ROUTER CISCO 2651 - RAPORT TRAFFIC, PERSPEKTYWA PACKETS [20:00-01:00 NASTĘPNEGO DNIA] ........... 100
RYSUNEK 8.18 ROUTER CISCO 2651 - RAPORT CONVERSATION, PERSPEKTYWA APPLICATION [20:00-01:00 NASTĘPNEGO DNIA]
............................................................................................................................................................. 100
RYSUNEK 8.19 CISCO 2651 - RAPORT CONVERSATION, PERSPEKTYWA SOURCE [20:00-01:00 NASTĘPNEGO DNIA] ............. 101
RYSUNEK 8.20 TOPOLOGIA SIECI DEPARTAMENTU W BRE BANKU ............................................................................... 102
RYSUNEK 8.21 CISCO 2621 XM- RAPORT TRAFFIC, PERSPEKTYWA VOLUME [8:00-14:00] ............................................ 103
RYSUNEK 8.22 CISCO 2621 XM- RAPORT TRAFFIC, PERSPEKTYWA VOLUME [9:15-10:33] ............................................ 104
RYSUNEK 8.23 CISCO 2621 XM- RAPORT CONVERSATION, RUCH WYCHODZĄCY, PERSPEKTYWA APPLICATION [9:15-10:33] 104
RYSUNEK 8.24 CISCO 2621 XM- RAPORT CONVERSATION, RUCH WYCHODZĄCY, PERSPEKTYWA SOURCE [9:15-10:33] ....... 105
RYSUNEK 9.1 FLEXIBLE NETFLOW - WIELE MONITORÓW TEGO SAMEGO PRZEPŁYWU ....................................................... 111
RYSUNEK 9.2 ARCHTEKTURA FLEXIBLE NETFLOW ..................................................................................................... 112
grudzień 07
Łukasz Witaszek
8
Wykaz tabel
TABELA 6.1 ZALEŻNOŚCI POJĘĆ NETFLOW (26).......................................................................................................... 54
TABELA 6.2 TABELA TYPÓW PÓL (26)....................................................................................................................... 73
TABELA 6.3 PRZYKŁADOWE PRZEPŁYWY (26) ............................................................................................................. 75
TABELA 6.4 PRZYKŁADOWY ZBIÓR REKORDÓW DANYCH PRZEPŁYWÓW (26) ..................................................................... 76
TABELA 7.1 KOMERCYJNE OPROGRAMOWANIE STACJI ZARZĄDZANIA (16) ....................................................................... 80
TABELA 7.2 BEZPŁATNE OPROGRAMOWANIE STACJI ZARZĄDZANIA (16) .......................................................................... 81
TABELA 7.3 LOKALIZACJE SOND I ZADANIA MONITOROWANIA - SIEĆ KORPORACJI CISCO...................................................... 82
TABELA 8.1 WYMAGANIA SPRZĘTOWE PROGRAMU NETFLOW ANALYZER ........................................................................ 85
TABELA 8.2 ROUTER LINKSYS - CHARAKTERYSTYKA QUICK VIEW #2: INTERFEJS WAN ....................................................... 91
TABELA 9.1 IANA TABELA PORTÓW ....................................................................................................................... 113
grudzień 07
Łukasz Witaszek
9
1 Wstęp
Społeczeństwo przełomu wieków określane jest wieloma sformułowaniami, wśród
których często przewija się termin „społeczeństwo informacyjne”. Błyskawiczny rozwój
technologii informatycznych obserwowany w ostatnich latach sprzyja popularyzacji komputerów. Dla większości aktywnych społecznie i zawodowo ludzi w krajach rozwiniętych
(lub szybko się rozwijających) wykorzystanie technik komputerowych jest czymś naturalnym. Komputery są nieodłącznym elementem wyposażenia praktycznie każdego biura oraz
większości domów i mieszkań. Upowszechnianie się komputerów w połączeniu z coraz
popularniejszym Internetu pozwalają nam na łatwy dostęp do informacji oraz jej łatwą
wymianę, dlatego też określenie „społeczeństwo informacyjne” nabiera większego sensu
wraz z każdym nowym użytkownikiem Sieci.
W prywatnym życiu wiele osób nie wyobraża sobie funkcjonowanie bez wykorzystywania zdobyczy techniki, jednak brak telefonu komórkowego lub komputera z podłączeniem do Internetu nie oznacza katastrofy i nie wiąże się z żadnymi stratami. Zupełnie
inaczej wygląda sytuacja w odniesieniu do komercyjnych zastosowań informatyki. Nie
wyobrażamy sobie współczesnego biura, banku, zakładu przemysłowego lub instytucji bez
infrastruktury informatycznej. Dla postronnych obserwatorów są to po prostu „komputery”, dla użytkowników (osób korzystających z owych komputerów) jest to „system komputerowy” a dla specjalistów z dziedziny informatyki są to elementy infrastruktury, składające się z wymienionych wcześniej komponentów („komputer” – stacja robocza, „system
komputerowy” – główna aplikacja (lub ich zestaw) wykorzystywana w danej instytucji)
oraz wielu innych elementów – systemów operacyjnych, sprzętu i oprogramowania serwerów oraz sieci komputerowej pozwalającej na komunikację pomiędzy wszystkimi elementami systemu. To właśnie ta połączona ze sobą wieloelementowa struktura jest narzędziem
wykorzystywanym w tak wielu dziedzinach współczesnego życia.
Warto zwrócić uwagę na fakt, iż w przeważającej większości zastosowań o potencjale systemu świadczy możliwość wymiany informacji. Samodzielne stanowiska komputerowe z zainstalowanymi aplikacjami posiadają możliwość przetwarzania informacji
zgromadzonych lokalnie, co w praktyce ma niewielki obszar zastosowań. Dopiero wymiana (dodajmy – bardzo szybka) tych informacji pomiędzy wieloma stanowiskami i użytkownikami danego systemu sprawia, iż istnienie systemu ma sens i ułatwia pracę.
grudzień 07
Łukasz Witaszek
10
1.1 Systemy informatyczne
Wymienione wcześniej we wstępie pojęcie system informatyczny wymaga doprecyzowania, tak aby z właściwej perspektywy spojrzeć na główny temat niniejszej pracy –
sposoby zarządzania sieciami komputerowymi.
„System informatyczny - jest to zbiór powiązanych ze sobą elementów, którego
funkcją jest przetwarzanie danych przy użyciu techniki komputerowej” (1). Użytkownicy
systemu zapytani o główne jego składniki wymienią najczęściej stację roboczą – komputer,
jako fizyczną część systemu, niektórzy wspomną również o zainstalowanym oprogramowaniu i urządzeniach peryferyjnych. Bardzo niewiele osób jest świadomych istnienia infrastruktury sieciowej a tym bardziej jej znaczenia dla poprawnego funkcjonowania systemu jako całości. Sieć komputerowa ma dla właściwego i pełnego działania systemu (a co
za tym idzie dla efektywności działania całej organizacji) znaczenie fundamentalne. Różnego rodzaju badania wykazały, iż awaria sieci w dużej organizacji prowadzi do strat operacyjnych liczonych w milionach dolarów.
1.2 Sieć komputerowa
Sieć komputerowa, łącząc wszystkie elementy struktury systemu pozwala na jego
prawidłowe funkcjonowanie, co przekłada się na generowane za pomocą tegoż systemu
zyski. Wydawałoby się zatem, że ze względu na newralgiczność sieci jako składnika spajającego system, wiedza o funkcjonowaniu sieci jak i regularne działania monitorujące jej
sprawność są priorytetowymi zadaniami zespołów utrzymujących system informatyczny w
stanie pełnej funkcjonalności. Okazuje się jednak, że w wielu przypadkach zagadnieniom
utrzymania sieci poświęca się o wiele mnie zasobów niż pozostałym elementom systemu.
Wynika to z wielu czynników, do których możemy zaliczyć:
• przygotowanie przez producentów sprzętu sieciowego domyślnej konfiguracji (ang.
Out of the box, Plug and Play), co umożliwia włączenie urządzenia do systemu bez
dokonywania czasochłonnych zabiegów optymalizujących ustawienia urządzenia;
• usterki i błędy w działaniu sieci są często ukryte, ujawniają się z biegiem czasu i
zmianą nasilenia eksploatacji (nowa sieć projektowana jest z zachowaniem marginesu na potrzeby rozwoju organizacji – właśnie ten nadmiar zasobów często nie
pozwala dostrzec błędów w ustawieniach, przez co zasoby nie są wykorzystywane
efektywnie.
grudzień 07
Łukasz Witaszek
11
Jak widzimy przygotowanie sprawnej infrastruktury sieciowej nie jest prostą sprawą. Wydaje się jednak, że rzeczą bardziej złożoną, ale równocześnie niezbędną do jej prawidłowego działania jest właściwe zarządzanie obszarem sieci komputerowej.
1.3 Model zarządzania siecią komputerową
Utrzymanie systemu informatycznego w stanie sprawności operacyjnej jest zadaniem administratorów. „Administrator (potocznie admin) - informatyk zajmujący się zarządzaniem całością lub wydzieloną częścią systemu informatycznego, odpowiadający za
jej sprawne działanie.” (2). Wdrażanie wielu nowych aplikacji sieciowych sprawia, że środowisko sieciowe jest coraz dynamiczniejsze i wymaga wytężonej uwagi administratorów.
Aby usystematyzować zagadnienia administrowania sieciami komputerowymi
Międzynarodowa Organizacja Normalizacyjna – ISO (International Organization for
Standardization) wprowadziła standardy dotyczące sieci komputerowych w postaci pięcioelementowego modelu systemu zarządzania siecią komputerową. W oparciu o niego tworzone są narzędzia zarządzania sieciami komputerowymi oraz oprogramowanie sprzętu
sieciowego. W omawianym modelu Organizacja wyróżniła (3):
• zarządzanie w sytuacjach awaryjnych (Fault Management)
Zadaniem zarządzania w sytuacjach awaryjnych jest wykrywanie, raportowanie i
informowanie użytkowników oraz (na ile to jest możliwe) automatyczne naprawianie wykrytych problemów. Ze względu na poważne konsekwencje awarii sieci dla
funkcjonowania całości systemu ten element modelu jest najczęściej implementowanym spośród tu wymienionych (4);
• zarządzanie wykorzystaniem zasobów (Accounting Management)
Ten element modelu odpowiada za analizę wykorzystania dostępnych zasobów
przez użytkownika lub grupę użytkowników, usługę lub grupę usług. W wielu organizacjach system informatyczny jest narzędziem, przy pomocy którego generowane są zyski przez działy spoza obszaru informatyki – informatyka jest działem
pomocniczym, nie tworzy przychodu dla firmy. Managerowie w takich organizacjach często chcą rozliczenia kosztów, które powstają w obszarze informatyki, najczęściej w rozłożeniu na poszczególne obszary działalności biznesowej. Pozwala to
na rozłożenie kosztów utrzymania systemu zgodnie ze stopniem jego wykorzystania przez poszczególne jednostki biznesowe. I w tym miejscu niezbędny okazuje
się bieżący monitoring wykorzystania zasobów sieciowych, dzięki któremu można
grudzień 07
Łukasz Witaszek
12
przedstawić zestawienie wykorzystania sieci przez różne departamenty w organizacji;
• zarządzanie konfiguracją i nazwami (Configuration Management)
Celem zarządzania konfiguracją jest zbieranie informacji o konfiguracji urządzeń,
co jest szczególnie ważne w przypadku wykorzystywania zróżnicowanego sprzętowo i programowo środowiska sieciowego (4)
• zarządzanie wydajnością (Performance Management)
Głównym zadaniem jest zapewnienie właściwej wydajności sieci: w chwili obecnej coraz powszechniejsze stają się usługi IP (ang. IP Services), przykładem może
być telefonia IP , które wysoko podnoszą poprzeczkę dla istniejących sieci komputerowych, dostosowanych do transmisji danych bez konieczności spełnienia wymogu przesyłu w czasie rzeczywistym. Właściwie realizowane zarządzanie wydajnością pozwala na łatwe przygotowanie planów rozwoju sieci: obserwując wykorzystanie dostępnych zasobów można szybko i precyzyjnie odpowiedzieć na pytanie
„Dlaczego system jest mało wydajny? Czy jest to problem serwera aplikacji, czy
może sieć jest niewydolna?”. Analiza raportów pozwoli z wyprzedzeniem wskazać
obciążone elementy i odpowiednio zaplanować zmiany (np. rozbudowę) sieci (5);
• zarządzanie bezpieczeństwem (Security Management)
Zarządzanie bezpieczeństwem to przede wszystkim kontrola dostępu do zasobów
sieciowych zgodnie z zasadami realizowanej polityki bezpieczeństwa. Ważne jest
również wykrywanie ataków złośliwego oprogramowania (kontrola aplikacji sieciowych): bieżący monitoring sieci pozwala w łatwy sposób wychwytywać anomalie i zjawiska, które mogą świadczyć o potencjalnym zagrożeniu złośliwym oprogramowaniem lub też o ataku (np. typu DoS) (5).
Zarządzanie bezpieczeństwem to bardzo szerokie zagadnienie, które należy rozważać na wszystkich płaszczyznach systemu informatycznego (bezpieczeństwo sieci
jest jednym z elementów decydujących o bezpieczeństwie systemu jako całości).
Uwaga: pojęcie nadzorowania/zarządzania siecią komputerową jest ściśle związane z jej
monitorowaniem. Temat niniejszej pracy jest bardzo pojemny, należy jednak zwrócić
uwagę, iż protokół NetFlow jest protokołem monitorowania sieci. Dlatego też to właśnie
monitorowanie (będące jedną ze składowych zarządzania siecią) jest główną osią pracy i
grudzień 07
Łukasz Witaszek
13
przedstawiane przeze mnie technologie i standardy są opisywane głównie z perspektywy
realizacji zadań monitorowania (choć omawiane technologie posiadają również inne funkcjonalności).
grudzień 07
Łukasz Witaszek
14
2 Cel i zakres pracy
Niniejsza praca ma na celu przedstawienie zagadnień zarządzania siecią komputerową, ze szczególnym uwzględnieniem możliwości, jakie w tej dziedzinie daje protokół
NetFlow.
W pierwszej części pracy, obejmującej rozdziały 1., 3. oraz 4. omówione zostają
ogólne zagadnienia związane z pojęciem sieci komputerowych, ich znaczeniem we współczesnym życiu oraz rozwojem na przestrzeni ostatnich lat. Dalej przedstawię konieczność
wprowadzania mechanizmów monitorowania pracy infrastruktury sieciowej oraz omówię
tradycyjne metody realizowania zadania nadzoru sieci komputerowej.
Rozdziały 5. i 6. to przedstawienie i dokładne omówienie podstaw nowoczesnych
metod monitorowania. Przedstawione zostaną metody wykorzystujące w monitorowaniu
pojecie przepływu: zarówno jako standard IPFIX, jak i jego praktyczna implementacja w
postaci protokołu NetFlow v9.
Kolejne dwa rozdziały to opis wykorzystania opisanego od strony teoretycznej protokołu NetFlow w zastosowaniach praktycznych. Przedstawione zostaną zagadnienia poprzedzające implementację: wybór oprogramowania zarządzającego oraz umiejscowienie
elementów architektury tego protokołu. Praktyczne wykorzystanie NetFlow zostanie opisane na przykładzie trzech sieci, w których zostanie wdrożone monitorowanie i przeprowadzone zostaną analizy wyników prowadzonych obserwacji. Zwieńczeniem przeprowadzonych badań są wnioski podsumowujące możliwości jakie daje zastosowanie tej technologii w monitorowaniu.
Ostatni rozdział omawia kierunki, w których ewoluuje NetFlow i inne metody analizowania przepływów. Przedstawione też będzie krótko rozwiązanie rozpoznawania aplikacji sieciowych – Cisco NBAR. Prawidłowa identyfikacja aplikacji sieciowych leży u
podstaw skutecznego monitorowania współczesnych sieci, dlatego w niniejszej pracy zostanie przedstawiona również ta technologia.
grudzień 07
Łukasz Witaszek
15
3 Monitorowanie sieci komputerowych – zagadnienia podstawowe
Zarządzanie siecią jest w znacznej mierze oparte na monitorowaniu jej pracy zgodnie z zaprezentowanym wyżej modelem. Monitorowanie, inaczej mierzenie i analiza wyników tychże pomiarów, wymaga określenia metryk, które pozwolą na dokonywanie porównań i określanie wymagań.
3.1 Metryki sieciowe
W technice sieciowej możemy wyróżnić kilka głównych wskaźników (metryk),
które zostaną poniżej krótko opisane (3) (6):
Wskaźniki parametrów wpływających bezpośrednio na jakość usług sieciowych:
1. Dostępność (ang. Availability) [%] – procent czasu dostępności dla użytkownika
danej usługi lub zasobu. Najczęściej wyrażana wzorem:
gdzie:
MTBF – Mean Time Between Failures – średni czas między awariami
MTTR – Mean Time To Repair – średni czas usunięcia awarii
2. Czas odpowiedzi (ang. Response Time) [s] – czas odpowiedzi systemu na żądanie
wykonania określonego zadania. W złożonym systemie czas odpowiedzi zależy od
wielu czynników, które najczęściej ten czas wydłużają. Główną składową tego parametru w przypadku aplikacji sieciowych jest opóźnienie w przesyłaniu pakietów
przez sieć, które wynika z ograniczeń danego medium transmisyjnego oraz konieczności analizy danych zawartych w pakietach przez kolejne elementy sieciowe
(szczególnie istotne w przypadku sieci przełączanych). Pożądane jest minimalizowanie czasu odpowiedzi systemu, co ma szczególne znaczenie w przypadku aplikacji interaktywnych.
3. Dokładność (ang. Accuracy) [-] – parametr określający jakość komunikacji na podstawie ilości błędów transmisji. O dokładność transmisji dbają (w większości przypadków) protokoły łącza danych oraz protokoły transportowe, uwalniając użytkownika od konieczności wnikliwego analizowania tego obszaru.
grudzień 07
Łukasz Witaszek
16
Wskaźniki parametrów wpływających bezpośrednio na wydajność:
1. Przepustowość (w odróżnieniu jednak od parametru określającego techniczne możliwości medium należałoby wprowadzić pojęcie przepływności, ang. Throughput)[b/s] – wskaźnik charakteryzujący dostępne łącze pod względem jego wykorzystania przez daną aplikację (np. ilość możliwych do przesłania pakietów, zestawionych połączeń terminalowych). Przepustowość jest różna dla różnych aplikacji, co
odróżnia ją od często zamiennie (błędnie) stosowanego pojęcia szerokości pasma
(ang. bandwidth), które niezależnie charakteryzuje medium transmisyjne.
2. Wykorzystanie (ang. Utilization) [%] – określenie procentowe reprezentujące czas
wykorzystania zasobu w stosunku do całego czasu, w którym wykonywany jest
pomiar. Definicja ta opiera się na fakcie całkowitego zawłaszczania łącza przez
transmisję: np. w przypadku połączeń Ethernet, gdzie transmisja jednej stacji wymusza oczekiwanie innych na możliwość przeprowadzenia transmisji (system wykrywania kolizji). Poniższy rysunek przedstawia wykorzystanie przepustowości łącza (bandwidth = 10 MB/s) w czasie wyrażanym w mikrosekundach:
transmisja[kb/s]
20
10
0
1
3
5
7
9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
Rysunek 3.1 Wykorzystanie łącza w protokole Ethernet
Gdy jednak wydłużymy okres obserwacji (czas wyrażony w milisekundach) i będziemy się przyglądać wykorzystaniu łącza definiowanym w powyższy sposób, to
wykres wykorzystania łącza będzie się prezentował następująco:
wykorzystanie [%]
100
50
0
1
3
5
7
9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
Rysunek 3.2 Wykorzystanie łącza - z definicji
grudzień 07
Łukasz Witaszek
17
Wskaźniki parametrów związanych z charakterystyką medium transmisyjnego:
1. Przepustowość (ang. Bandwidth) [b/s] – „maksymalna ilość informacji (mierzonej
w bitach) jaka może być przesyłana przez dany kanał telekomunikacyjny lub łącze
w jednostce czasu (mierzonej w sekundach).” (7)
3.2 Typy monitorowania
Gdy mówimy o monitorowaniu sieci możemy usystematyzować kilka różnych sposobów jego realizacji. I tak możemy wyróżnić pomiary aktywne oraz pomiary pasywne
(6). Aktywne pomiary polegają na obserwowaniu zachowania się pakietów generowanych
tylko na potrzeby dokonywanego monitorowania. Przykładem może tu być ping, lub traceroute – programy wysyłające w sieć spreparowane pakiety danych i przedstawiające ich
zachowanie się w sieci. Pomiary aktywne zwykle wykonywane są jako pomiary punkt
końcowy – punkt końcowy (np. stacja – serwer), bez szczegółowych informacji co dzieje
się pomiędzy tymi punktami.
Pomiary pasywne opierają się na obserwowaniu istniejącej w sieci wymiany danych, bez
wprowadzania do sieci testowych pakietów. Najczęściej pomiar pasywny ogranicza zasięg
monitoringu do zasięgu obserwowanego połączenia (np. router – router).
Innym podziałem metod pomiarowych jest rozróżnienie monitorowania inline oraz
monitorowanie offline. W pierwszym przypadku protokoły wykorzystywane do monitorowania przesyłają dane z wykorzystaniem łącza, które monitorują (np. SNMP). W przypadku metody offline wyniki pomiarów przekazywane są za pomocą innych (często dedykowanych do tego celu) połączeń.
3.3 Wymagania stawiane systemom monitorowania
Krótko przedstawione powyżej elementy modelu monitorowania zdefiniowane
przez ISO są podstawą tworzenia skutecznego systemu nadzorującego pracę sieci. Konieczne jest jednak uzupełnienie modelu teoretycznego wskazówkami praktycznymi, które
pozwalają na dostosowanie systemu do rzeczywistych oczekiwań użytkowników.
Głównym aspektem praktycznym monitorowania jest zbieranie i prezentowanie takich parametrów środowiska sieciowego, które pozwala na jego kontrolę z właściwej perspektywy. Użytkownik końcowy systemu, wykorzystujący sieć do pracy z określonymi
aplikacjami będzie żądał ich sprawnego działania – szybkiego otwierania stron WWW,
dostępności do serwerów pocztowych, komunikatorów, VoIP itp. W tym przypadku kon-
grudzień 07
Łukasz Witaszek
18
trola jedynie stanu sieci komputerowej nie pozwala w pełni diagnozować problemów –
mogą one być spowodowane przerwami w pracy serwerów usług wymaganych przez użytkownika lub ich obciążeniem. Z innej strony na zagadnienia monitorowania będą patrzeć
dostawcy połączeń – dla nich monitorowanie oznacza ciągłą kontrolę pracy urządzeń sieciowych, sprawności łącz, zasilania, stanu łącz zapasowych itd. Widzimy więc, że użytkownicy końcowi oraz dostawcy usług (w tym przypadku usługi dostępu do sieci) mówią
„innym językiem”. Dlatego tak ważne jest, aby przy tworzeniu systemu monitorującego
mieć świadomość potrzeb odbiorcy tego systemu.
Połączenie modelu ISO oraz praktycznych wymagań pozwala na przedstawienie
głównych wymagań funkcjonalnych systemu (6):
• pomiar i prezentacja ilości i częstotliwości wymiany danych pogrupowanych wg
aplikacji (serwisu), stacji komputerowej (klienta, serwera) - obserwacja pozwala
identyfikować szczególnie obciążone zasoby oraz wykrywać anomalie;
• tworzenie logicznych grup węzłów sieci (np. departament, lokalizacja geograficzna,
podsieci adresowe) – możliwość powiązania wykorzystywanych zasobów z jednostką organizacyjną, obserwacja trendów w wykorzystaniu zasobów przez określone obszary organizacji;
• filtry i wyjątki, określone wzorce przepływów – automatyzacja w wykrywaniu zagrożeń i alarmowaniu anomalii;
• raportowanie w oparciu o określone kryteria, wywoływane w określonym czasie
(raporty dobowe, z określonego zakresu pracy sieci) – ułatwione analizowanie zapotrzebowania na usługi w określonych przedziałach czasowych.
3.4 Ograniczenia w monitorowaniu
Wymienione w poprzednim podrozdziale wymagania stawiane przed systemami do
monitoringu sieci muszą zostać spełnione pomimo wielu ograniczeń, które znacząco
utrudniają stworzenie poprawnie działającego systemu. Należy przede wszystkim pamiętać, iż (6):
• urządzenia sieciowe mają ograniczone zasoby – monitoring jest procesem podrzędnym względem poprawnego przesyłania danych. Powoduje do konieczność ograniczania monitoringu do kilku wybranych protokołów, monitorowania zagregowanego (np. na każdy port urządzenia), ogranicza możliwość monitorowania tylko do
grudzień 07
Łukasz Witaszek
19
urządzeń do tego przystosowanych (nowsze generacje sprzętu). Dodatkowo rozwój
sieci gigabitowych podnosi wymagania jeszcze wyżej;
• dedykowane urządzenia pomiarowe pozwalają na pomiar w obciążonych punktach
sieci, lecz nie zawsze można je w tych miejscach fizycznie zamontować (lokalizacje niedostępne, wymagające zezwolenia na dostęp, itp.);
• ciągły rozwój usług sieciowych i pojawiające się wraz z nim nowe protokoły (podczas gdy protokoły monitorowania ewoluują znacznie mniej dynamicznie);
• większość usług (protokołów) nie jest konstruowana w sposób, który ułatwiałby ich
monitorowanie. Niektóre zaś protokoły z premedytacją utrudniają nadzór (np. P2P)
lub bardzo go utrudniają (np. szyfrowanie, dynamiczne przydzielanie portów);
• rosnąca mobilność utrudnia lokalizowanie przepływów i analizę trendów (trudno
jednoznacznie określić, czy zmieniająca się z dnia na dzień lokalizacja źródła określonego ruchu w sieci wynika ze zmiany grupy użytkowników czy też z migracji
użytkowników wykorzystujących określony zasób wcześniej).
Podsumowując – zarządzanie siecią komputerową w nowoczesnym środowisku informatycznym wymaga ciągłego monitorowania charakterystyki przepływających przez tę
sieć danych i właściwą prezentację tejże charakterystyki (zgodnie z różnymi oczekiwaniami). W dalszych rozdziałach niniejszej pracy przedstawione zostaną różne techniki monitorowania ze szczególnym uwzględnieniem rozwiązań opartych o protokół NetFlow i narzędzia z nim związane.
grudzień 07
Łukasz Witaszek
20
4 Tradycyjne metody zarządzania
Od czasu powstania pierwszych sieci komputerowych (koniec lat 60-tych – projekt
Advanced Research Project Agency Network – ARPANET) do dnia dzisiejszego obserwujemy dynamiczny rozwój rozwiązań sieciowych, pozwalających na spełnianie coraz większych wymagań stawianych sieciom komputerowym. Rozwój i powiększanie się sieci wiązało się z rosnącą w szybkim tempie liczbą urządzeń sieciowych co utrudniało ich monitorowanie i właściwe zarządzanie. W końcu lat 80-tych powstały pierwsze standardy, których celem było wprowadzenie jednolitego mechanizmu zarządzania i monitorowania.
4.1 Protokół SNMP
Pierwszym protokołem za pomocą którego można było zarządzać siecią (poprzez
odpowiednie zarządzanie urządzeniami sieciowymi) był opisany w standardzie RFC 1028
(listopad 1987) Simple Gateway Monitoring Protocol. W krótkim czasie pojawiła się nowa
propozycja standardu, rozszerzająca SGMP – protokół Simple Network Management Protocol, opisany w RFC 1067 (sierpień 1988). W kolejnych latach pojawiały się następne
specyfikacje protokołu, które rozwijały jego funkcjonalność i eliminowały odkrywane w
protokole błędy. Prostota implementacji protokołu w wersji 1 (SNMP v1) zaowocowała
szerokim rozpowszechnieniem się właśnie tego rozwiązania jako sposobu zarządzania siecią – praktycznie każdy producent sprzętu sieciowego zawiera w jego oprogramowaniu
tzw. agenta SNMP. Kolejne wersje protokołu nie zmieniały wiele co do ogólnej zasady
działania (o czym więcej w dalszej części rozdziału), koncentrowały się na dodawaniu
nowych funkcjonalności oraz podnoszenia poziomu bezpieczeństwa. I tak, w wersji SNMP
v2 usprawniono odczyt większej niż jeden na raz ilości parametrów (polecenie GetBulk)
oraz sposób propagowania pułapek (ang. Traps). Wersja SNMP v3 wprowadziła właściwy
poziom zabezpieczeń do protokołu, jednak ich złożoność w implementacji jest źródłem
niechęci wielu administratorów do pełnego wykorzystania możliwości mechanizmów bezpieczeństwa.
Gdy mówimy o SNMP należy pamiętać, że mamy na myśli nie tylko protokół wymiany danych zarządzania siecią. SNMP jest zbiorem wielu standardów, których część opisuje
protokół, inne zaś definiują np. struktury danych (bazy MIB), rozszerzają zastosowania
grudzień 07
Łukasz Witaszek
21
SNMP do nadzoru nie tylko sieciowej charakterystyki pracy urządzeń (np. parametry drukarki lub stan procesora stacji roboczej).
Protokół SNMP jest protokołem warstwy aplikacji modelu OSI, typowo wykorzystuje porty 161 (agent) oraz 162 (zarządca) protokołu transportowego UDP. Dodatkowo
możliwe jest użycie innych portów, co wykorzystują w swoich implementacjach protokołu
producenci sprzętu (np. CISCO: snmp-tcp-port 1993/tcp cisco SNMP TCP port; snmptcp-port 1993/udp cisco SNMP TCP port (8) ).
4.1.1 Działanie protokołu SNMP
Podstawą działania mechanizmu zarządzania siecią za pomocą protokołu SNMP
jest współdziałanie w sieci oprogramowania stacji zarządzającej NMS (ang. Network Management Station) z oprogramowaniem agentów rezydujących w systemach operacyjnych
urządzeń sieciowych (9). Stacja zarządzająca komunikuje się z agentami za pośrednictwem
protokołu SNMP i dokonuje analizy parametrów zebranych w Bazie Informacji Zarządzania (ang. Management Information Base). Każde urządzenie posiada taką bazę, w której
przechowywane są aktualne parametry pracy danego urządzenia (np.: ilość odebranych lub
wysłanych przez dany interfejs bajtów/ramek, tablice ARP, wykorzystanie mocy obliczeniowej procesora w danym urządzeniu, stopień naładowania akumulatorów w UPS, itd.)
Stacja zarządzająca może dokonywać wymiany informacji z agentem rezydującym na
urządzeniu w dwojaki sposób:
• może odczytywać parametry z urządzenia (polecenie get i pochodne) – stacja zarządzająca może przeglądać bazę MIB urządzenia i odczytywać aktualne parametry
pracy;
• może zapisywać parametry do urządzenia wpisując je do bazy MIB w urządzeniu
(polecenie set). Pozwala to wpływać na pracę urządzenia poprzez zmianę głównych
parametry jego pracy.
Zwykle stacja zarządzająca odpytuje agentów w określonych interwałach czasowych o stan parametrów i przenosi je do własnej bazy MIB, która przechowuje stan
wszystkich urządzeń objętych kontrolą. Istnieje również możliwość zainicjowania komunikacji przez agenta na urządzeniu w przypadku gdy zadziała mechanizm tzw. pułapki
(ang. trap). Agent monitorujący pracę urządzenia reaguje na wystąpienie określonej (zdefiniowanej w czasie konfiguracji agenta) sytuacji wysłaniem komunikatu do stacji zarzą-
grudzień 07
Łukasz Witaszek
22
dzającej. Uruchomienie stacji zarządzającej na dedykowanym komputerze (z dostępem do
znacznej przestrzeni dyskowej) pozwala na przechowywanie historycznych danych i ich
prezentację w szerokim horyzoncie czasowym.
Uproszczony schemat działania protokołu SNMP przedstawia poniższy rysunek:
Rysunek 4.1 Schemat działania SNMP (3)
W rozbudowanych środowiskach sieciowych, charakteryzujących się dużą liczbą
urządzeń sieciowych (a co za tym idzie rezydujących na nich agentach SNMP) wymiana
informacji oparta o regularne odpytywanie przez stację zarządzania staje się mało wydajna
(angażowane są zasoby obliczeniowe urządzeń) oraz wprowadza dodatkowe obciążenie
sieci przesyłanymi komunikatami SNMP. Dlatego też często w przypadku rozległej infrastruktury stosuje się komunikację sterowaną pułapkami (ang. TDP – Trap-Directed Pooling (3)). W przypadku wykorzystania tej strategii odpytywanie wszystkich agentów
przez stację zarządzającą ma miejsce bardzo rzadko – np. przy uruchomieniu sieci oraz w
długim (np. dobowym) interwale czasowym. Bieżące zmiany stanu sieci są odwzorowywane w stacji zarządzającej po otrzymaniu informacji od agenta, iż doszło do jakiejś zmiany w nadzorowanym obszarze, która to zmiana spowodowała zadziałanie mechanizmu
pułapki. Po otrzymaniu komunikatu stacja zarządzająca inicjuje komunikację z agentem i
grudzień 07
Łukasz Witaszek
23
za pomocą komunikatów get zbiera informacje o nowym stanie sieci nadzorowanej przez
agenta wysyłającego komunikat pułapki.
4.1.2 Monitorowanie z wykorzystaniem SNMP
Monitoring z wykorzystaniem protokołu SNMP realizowany jest poprzez zestaw
aplikacji uzupełniających oprogramowanie stacji zarządzającej, które służą przedstawieniu
informacji o stanie urządzeń zebranych w centralnej bazie MIB. Na rynku dostępnych jest
bardzo wiele programów do monitorowania SNMP, ale należy dokładnie zweryfikować
możliwości każdego z nich (10). Przykładem aplikacji wizualizującej dane zbierane za
pomocą protokołu SNMP jest program autorstwa Tobiego Oetikera – MRTG (The Multi
Router Traffic Grapher) (9). Aplikacja ta dedykowana wyłącznie zadaniom monitoringu
nie wymaga do działania współpracy ze stacją zarządzającą – program tworzy własną bazę
MIB, którą wypełnia danymi pobranymi od wskazanych agentów SNMP.
Przykładem wykorzystania programu może być prezentowana poniżej statystyka
pracy jednego z łączy internetowych serwera RAMOL (10)
Rysunek 4.2 MRTG - Przykład statystyk (10)
Statystyki prezentowane powyżej to tylko bardzo skromny przykład tego, co daje
SNMP, a właściwie co zawdzięczamy ciągłemu rozwojowi baz MIB - producenci sprzętu
rozszerzają ciągle liczbę parametrów, które można odczytać z urządzeń za pomocą agentów SNMP, dzięki czemu możliwe staje się monitorowanie olbrzymiej ilości parametrów
grudzień 07
Łukasz Witaszek
24
pracy urządzeń sieciowych. W przypadku urządzeń, które nie są przystosowane do obsługi
w systemie operacyjnym procesu agenta SNMP, możliwe jest wykorzystanie tzw. pełnomocnika (ang. Proxy), który będzie konwertował komunikację realizowaną przy pomocy
protokołu SNMP na zestaw instrukcji i komunikatów rozpoznawanych przez dane urządzenie.
4.1.3 Ograniczenia SNMP
Prezentowana powyżej statystyka ukazuje pewne ograniczenie protokołu SNMP,
które utrudnia wybrane aspekty monitorowania. Na powyższym rysunku widzimy wykres
przedstawiający stopień wykorzystania łącza wyrażony w KB/s. Uzyskanie jednak informacji o tym, jakie aplikacje (usługi) wykorzystywały łącze w tym czasie wymaga łączenia
ze sobą wielu różnorodnych informacji (np. takich jak lista uruchomionych w danym momencie aplikacji, statystyki danych przesłanych na dany port (warstwa aplikacji)). Mimo
rozbudowanych baz MIB może się okazać, że zebranie tego typu danych nie jest możliwe
za pomocą protokołu SNMP. Lecz gdyby nawet dysponować tego typu informacjami wygenerowanie właściwych statystyk na podstawie właśnie tych informacji byłoby złożone
obliczeniowo i w przypadku dużych sieci trudno byłoby prowadzić monitorowanie w czasie rzeczywistym.
Protokół SNMP, bardzo popularny i dzięki wysiłkowi włożonemu w jego ciągły
rozwój coraz wydajniejszy i łatwiejszy w implementacji, pozwala na kontrolę wielu elementów systemu informatycznego, wykraczając daleko poza obszar infrastruktury sieciowej. W obszarze zastosowań sieciowych pozwala w prosty sposób zarządzać infrastrukturą
i umożliwia wdrażanie zmian wynikających m. in. z monitoringu. Jednakże zbyt bliska
perspektywa (na poziomie bitów/pakietów) nie pozwala na łatwe scharakteryzowanie ruchu sieciowego (poza jego ogólną intensywnością), przez co nie spełnia wymagań stawianych przed systemem monitorującym opisanych powyżej w niniejszej pracy.
4.2 Protokół RMON
Protokół Zdalnego Monitoringu Sieci (ang. The Remote Network MONitoring –
RMON). Protokół, którego zadaniem jest zdalny monitoring sieci komputerowych. W odróżnieniu od SNMP jest to rozwiązanie nastawione na obserwowanie i kontrolę (stąd np.
brak możliwości zmiany konfiguracji urządzeń – do tego służy SNMP). Dwa zdania celnie
charakteryzujące protokół:
grudzień 07
Łukasz Witaszek
25
• „RMON – Remote MONitor. - standard ten został zaprojektowany nie jako konkurencja, ale jako uzupełnienie SNMP” (13);
• W skrócie, RMON jest stworzony do monitorowania opartego o “przepływy”, natomiast SNMP jest często wykorzystywane do “sprzętowego” zarządzania (13).
Powstanie i rozwój protokołu RMON to wynik wielokierunkowej ewolucji protokołu SNMP (3). Wykorzystuje on ten sam protokół komunikacyjny co SNMP oraz opiera
się o istnienie baz MIB, przy czym definiuje on własny format takiej bazy - baza MIB
zdalnego nadzoru (będąca uzupełnieniem bazy MIB-II znanej ze specyfikacji SNMP) (3).
Dzięki temu podejściu wykorzystano sprawdzone wcześniej rozwiązania, zaoszczędzony
dzięki temu czas poświęcając na stworzenie takiej bazy informacji, które pozwolą na łatwy
monitoring zdalny. Podobnie jak to miało miejsce w przypadku SNMP, RMON nie może
być traktowany stricte jako protokół – wykorzystuje przecież protokół zdefiniowany na
potrzeby SNMP. RMON to zbiór standardów umożliwiających zdalne monitorowanie.
Normy związane z RMON to w znaczącej części normy definiujące bazę MIB wykorzystywaną w zdalnym monitoringu. Dokument RFC 1757 (ang. Remote Network Monitoring Management Information Base) definiuje bazę MIB zdalnego monitorowania. Kolejny standard RFC 2021 (ang. Remote Network Monitoring Management Information Base Version 2 using SMIv2) rozszerza zdefiniowaną w poprzednim standardzie bazę informacji zarządzania MIB. Istnieje jeszcze norma RFC 2074 (ang. Remote Network Monitoring MIB Protocol Identifiers) opisująca algorytmy wymagane do identyfikacji protokołów
opisanych w RMNON MIB v2.
4.2.1 Działanie protokołu RMON
Baza MIB-II w oparciu o którą działa SNMP, pozwala na zbieranie informacji z
każdego interfejsu, z którego praca nadzorowana jest przez agenta SNMP. Jednak analiza
ruchu sieciowego z perspektywy pojedynczego interfejsu (ów) nie pozwala na zbieranie
informacji o sieci jako całości. Dlatego też RMON jako rozwinięcie SNMP w kierunku
monitorowania wprowadza pojęcie nadzorcy sieci (ang. Network Monitors). Ze względu na
fakt, iż RMON jest tak naprawdę rozwinięciem SNMP agenci zarządzania (SNMP) oraz
nadzorcy sieci (RMON) wykazują wiele cech wspólnych. To, co rozróżnia te elementy, to
wynikające z różnych zadań umiejscowienie tychże w strukturze sieci. W odróżnieniu od
wcześniej omawianego agenta zarządzania (SNMP) nadzorca sieci (RMON) nie jest
grudzień 07
Łukasz Witaszek
26
umieszczany w każdym węźle sieci – najczęściej implementuje się jedną instancję nadzorcy w każdej podsieci. Nadzorca może zostać zaimplementowany na dedykowanym urządzeniu podłączonym do segmentu sieci lub też na urządzeniu pełniącym inne funkcje – np.
routery, przełączniki lub też serwery usług.
Komunikacja nadzorców sieci ze stacją zarządzającą wykorzystuje protokół SNMP
jako protokół komunikacyjny, przesyłając zebrane informacje. Można wyróżnić kilka charakterystycznych cech opisujących działanie nadzorcy (3):
• działanie w trybie off-line: nadzorca realizuje swoje zadania zbierania określonych
informacji bez utrzymywania ciągłej łączności ze stacją zarządzania. Często jest to
optymalne rozwiązanie, gdy do przesyłanie informacji monitorowania i zarządzania
odbywa się za pośrednictwem połączenia wdzwanianego, zwykle droższego w
utrzymaniu i rozliczanego w oparciu o czas a nie ilość przesłanych informacji.
Wskazane jest również umożliwienie automatycznego przejścia nadzorcy w tryb
offline gdy występują problemy z łącznością ze stacją zarządzania. Nadzorca powinien na bieżąco nadzorować podległy obszar i zachować informacje do czasu uzyskania połączenia ze stacją zarządzania;
• nadzór zapobiegawczy, wykrywanie i raportowanie (ang. Proactive Monitoring,
Problem Detection and Reporting): jeżeli zadania związane z obserwowaniem naturalnego ruchu w sieci nie wykorzystują wszystkich zasobów nadzorcy, możliwe
jest realizowanie dodatkowych zadań diagnostycznych (np. ciągłego sprawdzania
warunków wystąpienia błędów). Taka konfiguracja pozwala na przewidywanie potencjalnych zagrożeń i ich raportowanie do stacji zarządzania;
• nadzór pasywny (bez odpytywania): analiza oparta jest na biernej obserwacji ruchu
sieciowego i w oparciu o informacje zebrane w ten sposób klasyfikowanie zdarzeń
jako prawidłowe lub niepożądane. W tym trybie nadzorca nie generuje dodatkowego obciążenia sieci własnymi pakietami testowymi, dlatego też mowa o braku odpytywania.
Nadzorcy sieci mogą również wykonywać pewne analizy danych przez nich zbieranych, w czym mogą wykonać część zadań stacji zarządzającej. Wyniki tej analizy to tzw.
Value-Added-Data, które dostępne są dla stacji zarządzania. Dodatkową funkcją dostępną
w RMON jest możliwość współpracy nadzorców z wieloma stacjami zarządzającymi,
dzięki czemu można zwiększyć niezawodność oraz wprowadzić podział uprawnień dostęSamodzielny Zakład Sieci Komputerowych PŁ,
grudzień 07
Łukasz Witaszek
27
pu do informacji zarządzania (np. kilka stacji zarządzających może zbierać informacje
eksploatacyjne podczas gdy inne umożliwiają dostęp do danych diagnostycznych).
4.2.2 Grupy zebrane w RMON v.1 MIB
Baza informacji zarządzania (MIB) protokołu RMON wprowadza specyficzne grupy informacji, które pozwalają na sprawne wykonywanie monitoringu. Poniżej ich lista i
krótkie omówienie elementów umożliwiających nadzór (13):
1. Statistics: zbiór statystyk czasu rzeczywistego parametrów sieciowych (wykorzystanie, liczba kolizji, błędy sumy kontrolnej).
2. History: grupa zawierająca archiwalne dane zbierane przez grupę Statistics;
3. Hosts: statystyki zbierane i przypisywane z uwzględnieniem podziału na węzły sieci (w oparciu o adresy MAC).
4. Hosts top N: zbiór N najaktywniejszych (w danym okresie czasu) węzłów sieci;
5. Matrix: grupa reprezentująca macierz połączeń pomiędzy węzłami sieci oraz charakterystyki tychże połączeń.
6. Token Ring: rozszerzenie protokołu SNMP o funkcje monitorujące niskiego poziomu specyficzne dla protokołu Token Ring.
7. Alarm: grupa definiująca wartości progowe parametrów charakteryzujących wydajność sieci. Przekroczenie tych parametrów rozpoczyna realizację procedury
alarmu, czyli wysłanie odpowiedniego komunikatu do stacji nadzorującej.
8. Filter: grupa określająca w jaki sposób należy dokonywać wyboru składowych ruchu w sieci monitorowanych przez nadzorcę. Rekordy w tej grupie definiują zbiór
parametrów (np. adres MAC), które muszą spełniać pakiety przemieszczające się w
sieci, aby były objęte monitoringiem.
9. Capture: grupa przechowująca i umożliwiająca przesłanie do stacji zarządzania pakietów spełniających założenia opisane w grupie Filter.
10. Event: umożliwia definiowanie i przesyłanie do stacji monitorującej pułapek protokołu SNMP odpowiadających zdarzeniom opisanym w grupie Alarm.
Ostatnie cztery grupy zdefiniowane w MIB RMON pozwalają dostosować zakres
obserwowanych pakietów do wymagań administratora sieci i do analizowanych zjawisk
podlegających wnikliwej obserwacji.
grudzień 07
Łukasz Witaszek
28
4.2.3 RMON2
Protokół RMON był znaczącym krokiem w kierunku stworzenia uniwersalnego narzędzia służącego monitorowaniu sieci komputerowych. Wykorzystując dobrze opracowany i szeroko implementowany protokół SNMP oraz wprowadzoną wraz z tym protokołem
architekturę twórcy nowego rozwiązania mogli skoncentrować się na rozwoju funkcjonalności. Okazało się jednak, że monitorowanie ograniczone do warstwy drugiej modelu OSI
jest niewystarczające dla zadań stawianych administratorom przez nowoczesne aplikacje
sieciowe. Ograniczenie to sprawiało, iż dostępny dla nadzorcy obszar sieci był ograniczony do domeny rozgłoszeniowej, ograniczonej urządzeniami działającymi w warstwie 3.
(routerami) lub wyższych modelu OSI. Z tego względu w 1997 roku przedstawiono specyfikację RMON2 (RFC2021), która rozszerzyła bazę MIB protokołu RMON o dodatkowe
10 grup, które pozwalały na analizę w wyższych warstwach modelu OSI. Poniżej krótki
opis grup bazy MIB rozszerzających protokół do wersji RMON2:
1. Protocol Directory: zbiór protokołów, które mogą być rozpoznawane przez nadzorcę.
2. Protocol Distribution: statystyki ruchu sieciowego obserwowanego przez nadzorcę
w rozłożeniu na poszczególne protokoły.
3. Address Map: mapa adresów, tworząca odwzorowanie adresów warstwy łącza danych (MAC) na adresy warstwy sieciowej (IP) – swego rodzaju tablica ARP.
4. Network-Layer Host: statystyki w oparciu o adresy warstwy sieciowej.
5. Network-Layer Matrix: mapa połączeń węzłów sieci w obserwowanym przez nadzorcę obszarze, konstruowana w oparciu o adresy IP.
6. Application-Layer Host: statystyki ruchu w oparciu o warstwę aplikacji.
7. Application-Layer Matrix: mapa połączeń węzłów sieci w obserwowanym przez
nadzorcę obszarze, konstruowana w oparciu o warstwę aplikacji.
8. User History: umożliwia okresowe zapisywanie wartości wskazanych przez administratora parametrów.
9. Probe Configuration: parametry konfiguracyjne nadzorcy.
10. RMON Conformance: informacje dotyczące zgodności z protokołem.
Wymienione powyżej grupy zdefiniowane w ramach rozszerzenia protokołu
RMON dały administratorom sieci nowe, szerokie możliwości nadzorowania sieci. Z wy-
grudzień 07
Łukasz Witaszek
29
korzystaniem nowego oprogramowania zainstalowanego na stacji nadzorczej możliwe stało się wizualizowanie ruchu w analizowanym segmencie sieci z wyróżnieniem wykorzystywanych protokołów, numerów portów warstwy transportowej, adresów IP itp.
4.2.4 Monitorowanie z wykorzystaniem RMON – przykład
Poniżej znajduje się kilka przykładowych wykresów wygenerowanych w oparciu o
pracę nadzorców RMON (16):
Rysunek 4.3 RMON – przykład statystyk
Protokół RMON jest wykorzystywany w wielu komercyjnych narzędziach służących do zarządzania sieciami komputerowymi. Jednym z najbardziej znanych i często wykorzystywanych produktów jest HP OpenView Network Node Manager (NNM), dostarczany przez firmę Hewlett-Packard. Jest to jeden z kilku produktów uławiających zarządzanie
sieciami komputerowymi dostarczanych przez tego producenta. Lista dodatkowego oprogramowania oraz jego szczegółowy opis znajduje się na stronie producenta (17).
grudzień 07
Łukasz Witaszek
30
4.3 SNMP i RMON – możliwości i ograniczenia
Wraz z rozwojem pierwszych sieci rozległych pojawiła się konieczność wdrożenia
narzędzia umożliwiającego administratorom zarządzanie infrastrukturą sieciową. W początkowym okresie realizowano kilka równoległych rozwiązań, lecz za przyczyną względnej prostoty szybko powszechnie uznawanym i implementowanym rozwiązaniem stał się
protokół SNMP. Warto tu zaznaczyć, że SNMP nie oznacza tylko protokołu, za pomocą
którego wymieniane są dane pomiędzy elementami składowymi architektury. SNMP to
ogólne pojęcie określające standard zarządzania, oparty o architekturę składającą się z
agentów (powiązanych z węzłami sieci) oraz centralnej stacji zarządzania, która za pośrednictwem agentów nadzoruje sieć oraz umożliwia konfigurację węzłów.
Rozwiązanie leżące u podstaw protokołu SNMP – bazy informacji zarządzania
(MIB), pozwoliło w łatwy sposób rozszerzać funkcjonalność SNMP przez rozszerzanie
właśnie tychże baz. Elastyczność tego rozwiązania okazała się szczególnie użyteczna, gdy
koniecznym okazało się dostosowanie SNMP do specyficznych zadań związanych z nadzorem sieci komputerowej. Zaproponowane rozwiązanie – protokół RMON, umożliwiający zdalny nadzór sieci komputerowych – jest rozszerzeniem SNMP o nowe funkcje zebrane w bazie MIB protokołu RMON. Podobnie jak w przypadku SNMP nowe rozwiązanie
monitorowania było dostosowywane do potrzeb użytkowników, czego najlepszym przykładem jest powstanie RMON2. Umożliwiło to rozszerzenie zasięgu monitorowania poza
2. warstwę modelu OSI, tak aby administratorzy mieli wgląd również w informacje zawarte w nagłówkach protokołów warstwy Sieci i warstwy Transportowej. Dzięki temu możliwe stało się charakteryzowanie ruchu z uwzględnieniem wykorzystywanych aplikacji sieciowych oraz adresów internetowych (IP).
Wykorzystywanie architektury wdrożonej wraz z powstaniem SNMP okazało się w
pewnych aspektach niewystarczające dla wymagań stawianych przez nowoczesne aplikacje sieciowe oraz generowany przez nie coraz większy ruch sieciowy. Model komunikacji
oparty na okresowym odpytywaniu nadzorców lub agentów przez stację nadzorującą stawia przed tą ostatnią duże wymagania obliczeniowe. Rozszerzenie protokołu projektowanego jako protokół analizujący ruch sieciowy na niskim poziomie o funkcje dające wgląd
w sytuację w wyższych warstwach wiąże się ze zwiększaniem wymagań (co do mocy obliczeniowej oraz dostępnej pamięci) stawianych nadzorcom/agentom. Z tego też względu
najwięksi producenci sprzętu i oprogramowania sieciowego rozpoczęli poszukiwania no-
grudzień 07
Łukasz Witaszek
31
wych rozwiązań, z czego wiele opiera się na pojęciu przepływu (ang. flows). Kolejny rozdział zostanie poświęcony najpopularniejszemu (między innymi ze względu na współtworzenie nowego protokołu przez dominującego producenta rozwiązań sieciowych – firmę
CISCO) rozwiązaniu, którego działanie opiera się na tymże pojęciu.
grudzień 07
Łukasz Witaszek
32
5 Nowoczesne metody monitorowania – idea IPFIX
Tematem niniejszej pracy jest przedstawienie nowoczesnych sposobów zarządzania
sieciami komputerowymi na przykładzie protokołu NetFlow. Przedstawione w poprzednich rozdziałach rozwiązania są ciągle rozwijane, dlatego też trudno je jednoznacznie
określić jako metody nienowoczesne. Właściwszym kryterium podziału wydaje się być
przystosowanie się metod monitorowania do wymagań stawianych przez zmieniającą się
charakterystykę pracy sieci. W ostatnich latach obserwuje się zjawisko wykorzystywania
sieci komputerowej jako wygodnego medium komunikacyjnego, przy czym natura samej
komunikacji uległa zmianie, kładąc coraz większy nacisk na komunikację stricte czasu
rzeczywistego (np. VoIP zamiast poczty elektronicznej i komunikatorów tekstowych)
wzbogacaną przekazem multimedialnym (np. wideokonferencje). Aby zrealizować rozszerzające się wymagania użytkowników w zakresie komunikacji konieczne było stworzenie
nowych aplikacji sieciowych, które z kolei znacząco zmieniły wymagania stawiane środowisku sieciowemu. Stworzenie narzędzi do monitorowania nowoczesnych sieci wymagało
fundamentalnej zmiany w sposobie interpretowania ruchu sieciowego – pojawiło się pojęcie przepływu, a wraz z nim zarządzanie sieciami oparte o przepływy (ang. flow-based
network monitoring). To właśnie zmiana w rozumieniu tego, co się dzieje w sieci, pozwala
na określenie metod monitorowania mianem nowoczesnych.
5.1 „Przepływowy” system monitorowania sieci
Programiści nowoczesnych aplikacji starają się projektować je tak, by były jeszcze
łatwiejsze w obsłudze i jak najwierniej oddawały rzeczywistość, którą w jakiś sposób modelują. Nierozerwalnie wiąże się to ze zwiększeniem ilości danych przesyłanych poprzez
sieć komputerową, coraz częściej w formie strumieni danych. Okazało się, że dotychczasowo wykorzystywane metody analizy ruchu sieciowego nie sprawdzają się przy wykrywaniu usterek, których wynikiem jest nieprawidłowa praca nowych aplikacji. Podstawą
stworzenia systemów, które będą mogły służyć do wydajnego monitorowania stało się,
rozumiane dość intuicyjnie, pojęcie przepływu (ang. flow). Pod tym pojęciem rozumiemy
mniej lub bardziej uporządkowany ruch. W przypadku ruchu sieciowego oznacza to zbiór
pakietów o określonych cechach wspólnych (pełna definicja pojawi się w następnym podrozdziale).
grudzień 07
Łukasz Witaszek
33
Systemy monitorujące zbudowane na tej podstawie ułatwiły znacznie realizację
nowych zadań, jakie stanęły przed administratorami sieci. Oto najważniejsze z nich (18):
• określenie listy aplikacji wykorzystywanych w sieci oraz stopnia w jakim wykorzystują one zasoby sieciowe;
• obserwowanie wpływu jaki wywierają na siebie aplikacje działające w tym samym
obszarze sieci;
• konieczność precyzyjnego podziału kosztów utrzymania coraz wydajniejszych połączeń (wymagane przez nowoczesne aplikacje) pomiędzy wykorzystujące je jednostki organizacyjne;
• inżynieria ruchu – odpowiednie kształtowanie obciążenia i priorytetowania (QoS)
dostępnych zasobów, tak aby spełnione były wymagania umów określających dostępność usług (ang. Service Level Agreements);
• wykrywanie zagrożeń (którym szybki rozwój Internetu dał okazję do spektakularnych ataków) i anomalii – o wiele łatwiej zauważyć nieprawidłowości analizując
wymianę informacji na poziomie logicznej komunikacji (reprezentowanej przez
przepływy) niż obserwując wymianę pakietów w warstwie fizycznej;
• możliwość dokonywania obserwacji w czasie rzeczywistym, niezbędna do poprawnej realizacji powyższych zadań. Na potwierdzenie tej tezy przytoczę wypowiedź
(19) Jeffa Duke, starszego inżyniera sieci w Departamencie Technologii stanu Indiana. Do jego zadań należy nadzór nad siecią gigabitowego Ethernetu, wykorzystywanego przez kilka tysięcy użytkowników. Wg niego wcześniejsze systemy
przesyłały raporty do późniejszej analizy. “Nie widziałem danych, pakietów lub
przepływów w czasie rzeczywistym” – twierdzi. „To nie było nawet zbliżone do
czasu rzeczywistego. Oglądałem rzeczy sprzed tygodnia.” Obserwowanie trendów i
przygotowywanie środowiska do spełnienia nowych wymagań w przyszłości.
Jak się okazało nowa metoda analizy okazała się właściwą dla nowoczesnego ruchu
sieciowego, a aplikacje, które działają w oparciu o nią stają się potężnymi narzędziami w
rękach doświadczonych administratorów. Na potwierdzenie tej tezy przedstawię klika wypowiedzi osób zawodowo zajmujących się administrowaniem rozległych sieci.
grudzień 07
Łukasz Witaszek
34
Zeus Kerravala, członek zarządu ds. infrastruktury firmy Yankee Group, specjalizującej się w dostarczaniu globalnych rozwiązań komunikacyjnych. Twierdzi on (20), iż z
własnej praktyki wie, że prawie 90% czasu poświęconego na usuwanie usterki jest poświęcone na jej wyizolowanie – precyzyjne wskazanie przyczyny błędu. „Bardziej inteligentne
systemy zarządzania mogą znacznie skrócić czas identyfikacji problemu. Wykorzystanie
NetFlow daje tę właśnie inteligencję.”
James Messer, dyrektor ds. Technologii w Network General, obecnie przejętej
przez NetScout Systems, Inc – dostawcę narzędzi do monitorowania sieci. Wg niego (20)
umiejętność interpretacji informacji dostarczanych przez NetFlow daje wgląd w wydajność
aplikacji, pozwalając łatwo izolować i rozwiązywać problemy związane w pojemnością
kanałów sieciowych. Analiza przepływów pozwala również na podstawie obserwacji trendów historycznych i wyszukiwania wzorców przewidywać zachowanie się środowiska w
przyszłości.
Okazuje się, że monitorowanie oparte o przepływy jest również przydatne w przypadku statystyk dostępu do obciążonych usług internetowych, twierdzi Ryan Nelson (19),
dyrektor operacyjny Major League Baseball Advanced Media – agencji prasowej obsługującej amerykańską ligę baseball-a. Liga dysponuje ponad siedemdziesięcioma serwerami
WWW, do których ruch kierowany jest poprzez siedem przełączników równoważenia ruchu (ang. load balancing switches). Jednak analiza problemów obniżonej wydajności wiązała się z olbrzymim nakładem pracy. „Aby znaleźć przyczynę błędu musieliśmy przeszukiwać 10 gigabitowy plik logu każdego dnia. (…) Teraz, gdy widzimy, że dzieje się coś
dziwnego, wykorzystujemy Coradiant1. On ciągle pracuje, zbierając informacje i wskazuje
źródło anomalii.”
Trafnym podsumowaniem nowych wymagań jest opinia Jon Oltsik, analityka Enterprise Strategy Group. Twierdzi on (19), że monitoring przepływów będzie coraz ważniejszy wraz z biznesowym trendem udostępniania aplikacji partnerom i klientom. Utrzymanie wydajności tychże aplikacji na poziomie akceptowalnym przez klientów będzie
przekładało się bezpośrednio na wyniki finansowe. Dlatego też konieczne jest skoncentrowanie się na użytkowniku – odbiorcy usług, przy czym najłatwiej jest to osiągnąć korzystając z analizy przepływów.
1
Zestaw narzędzi do monitorowania wydajności, wykorzystujący informacje o przepływach. Szczegółowe informacje można znaleźć na stronie http://www.coradiant.com/
grudzień 07
Łukasz Witaszek
35
5.2 IPFIX – nowy standard monitorowania przepływów
Opisana powyżej ewolucja metod monitorowania sieci komputerowych, wymuszona zmianą charakteru aplikacji sieciowych, spowodowała rozwój monitorowania opartego
o przepływy. Podobnie jak to miało miejsce w przypadku wielu innych zagadnień informatycznych, najpierw pojawiły się gotowe (często o ograniczonej kompatybilności) rozwiązania, a dopiero później zdefiniowano formalne standardy. W niniejszej pracy porządek
chronologiczny ustąpi miejsca układowi zgodnemu z poprawnością formalną: najpierw
pojawi się opis ogólnego standardu (w tym przypadku IPFIX – IP Flow Information
Export, RFC 3917), potem zaś zostanie szczegółowo opisana jego implementacja - protokół NetFlow wersja 9, RFC 3954. Wart zauważenia jest fakt, że w czasie opracowywania
standardu IPFIX opierano się na protokole NetFlow v9, który został opublikowany w tym
samym czasie. Trudno zatem stwierdzić, czy i tym razem implementacja nie wyprzedziła
standardu, jednak dla ustalenia uwagi w niniejszej pracy zostaną przedstawione zgodnie z
wcześniej przyjętym schematem.
5.2.1 Pierwsze implementacje producentów
Jak wspomniałem, rozwiązania funkcjonalne wyprzedziły formalny standard. Jednym z pierwszych producentów, którzy zaczęli implementować w swoim sprzęcie funkcje
umożliwiające monitorowanie w oparciu o przepływy był potentat na rynku urządzeń sieciowych – firma CISCO Systems, Inc. To właśnie ona wprowadziła pojęcie NetFlow,
określające nieformalny standard zbierania informacji o przepływach i sposobie wymiany
tychże informacji. Istnieje kilka wersji NetFlow, z których każda wnosiła nową funkcjonalność bądź zbliżała całe rozwiązanie do uzyskania miana standardu. Można wyróżnić
(21):
• wersja 1 (V1) to pierwsza wersja protokołu;
• wersja 5 (V5) to rozszerzenie wersji pierwszej o możliwość monitorowania informacji protokołu BGP (informacje o systemie autonomicznym) oraz wprowadzenie
numerów sekwencyjnych przepływów (konieczne ze względu na fakt, iż w typowej
konfiguracji NetFlow wykorzystuje protokół transportowy UDP);
• Wersja 6 (V6) jest zbliżona do wersji 7. Ta wersja nie jest wykorzystywana w nowych wersjach systemu operacyjnego urządzeń CISCO – IOS.
grudzień 07
Łukasz Witaszek
36
• Wersja 7 (V7) wprowadza rozszerzenie wykorzystywane tylko przez przełączniki
serii Cisco Catalyst 5000, wyposażonych w specjalną kartę rozszerzeń dla protokołu NetFlow – ang. NetFlow Feature Card (NFFC). Wersja ta nie jest kompatybilna
z routerami tego producenta.
• Wersja 8 (V8) to rozszerzenie wprowadzające możliwość agregowania przepływów
przez routery.
• Wersja 9 jest ostatnią opublikowaną przez producenta wersją, wzbogaconą o
wsparcie dla takich technologii jak Multicast, Internet Protocol Security (IPSec)
oraz Multi Protocol Label Switching (MPLS).
Różnicę wersji 5. (najpopularniejszej) oraz najnowszej wersji 9. przedstawia poniższa tabela (6):
Rysunek 5.1 Porównanie 5. i 9. wersji NetFlow
Wersje 2, 3 i 4 nie były publikowane.
5.2.2 Standard IPFIX – RFC 3917
Mimo wiodącej roli firmy Cisco jako producenta urządzeń sieciowych konieczne
stało się opracowanie uniwersalnych metod zbierania i wymiany informacji o przepływach
w sieciach wykorzystujących technologie innych producentów. Dlatego też organizacja
IETF (The Internet Engineering Task Force – nieformalne, międzynarodowe stowarzyszenie osób zainteresowanych ustanawianiem standardów technicznych i organizacyjnych w
grudzień 07
Łukasz Witaszek
37
Internecie (22)) powołała grupę roboczą o nazwie IPFIX odpowiedzialną za przygotowanie
Modelu Informacji (opisującego przepływy IP) oraz protokołu IPFIX (definiującego protokół służący do wymiany informacji o przepływach) (23). Wymiernym owocem prac grupy
było opublikowanie standardu RFC 3917 „Wymagania protokołu IP Flow Information
Export (IPFIX)”, (ang. Requirements for IP Flow Information Export (IPFIX)). Postaram
się przedstawić jego główne założenia, które zostaną szczegółowo opisane przy prezentowaniu standardu NetFlow v9.
5.3 IPFIX oraz NetFlow – wspólne podstawy
Poniżej zostaną przedstawione cechy charakterystyczne, wspólne dla IPFIX i NetFlow: zbiór pojęć wykorzystywanych w definiowaniu nowego standardu oraz szkielet architektury.
5.3.1 Pojęcia podstawowe
Grupa pracująca w ramach IETF przygotowując nowy standard wprowadziła specyficzny dla niego zbiór pojęć, za pomocą którego opisuje architekturę nowego systemu
monitorowania. Pojęcia te, ze względu na opisane wcześniej wspólne korzenie ideowe, są
tożsame w odniesieniu do protokołu NetFlow. W protokołach tych wyróżnia się następujące pojęcia (24):
• przepływ IP (ang. IP Traffic Flow): definiowany jako zbiór pakietów protokołu IP
przechodzących przez punkt obserwacji w określonym okresie czasu.
Wszystkie pakiety składające się na dany przepływ wyróżniają się wspólnym zbiorem określonych parametrów. Parametrami, które wyróżniają określony przepływ
mogą być:
o zawartości jednego lub więcej pól nagłówka pakietu IP (np. docelowy adres IP
pakietu), pole nagłówka warstwy transportowej (np. nr portu źródłowego) lub
pole nagłówka warstwy aplikacji
o parametr charakteryzujący pakiet sam w sobie (np. numer etykiety protokołu
MPLS)
o informacja o sposobie przekierowania pakietu (np. adres następnego węzła IP –
next hop IP, interfejs wyjściowy, poprzez który pakiet opuści urządzenie)
Pakiet zostaje przypisany do danego przepływu, jeżeli jego właściwości spełniają
warunki definiujące przepływ (np. jeżeli przepływ jest charakteryzowany przez
grudzień 07
Łukasz Witaszek
38
docelowy adres IP: 10.10.10.100, to pakiety zawierające w nagłówku jako adres
przeznaczenia tenże adres zostaną do tego przepływu przypisane);
• punkt obserwacji (ang. observation point): logiczny punkt w sieci (przełącznik, port
routera, miejsce podłączenia urządzenia dedykowanego do monitorowania przepływów), w którym można obserwować pakiety IP. Możliwe jest istnienie punktów
obserwacji zawartych wewnątrz innych punktów (np. punkty obserwacji na poszczególnych interfejsach routera są zawarte w punkcie obserwacji obejmującym
cały router).
• proces monitorujący/mierzący/klasyfikujący (ang. metering process): proces tworzący logiczne przepływy (grupowane w rekordy) na podstawie fizycznie obserwowanych (w punkcie obserwacji) pakietów, które spełniają kryteria zdefiniowanych przepływów. Proces ten wykorzystuje funkcje przechwytujące nagłówki pakietów, dokonujące znakowania czasowego (ang. timestamping), próbkujące i klasyfikujące. Proces ten uruchamia również funkcje odpowiedzialne za zarządzanie
rekordami przepływów (zawierających statystykę poszczególnych przepływów).
Ich działanie polega na tworzeniu nowych rekordów, uaktualnianiu istniejących,
wykrywaniu przepływów przeterminowanych, przekazywaniu przepływów do procesu eksportującego i usuwaniu rekordów przepływu.
Poniższy rysunek przedstawia kolejność wykonywania poszczególnych funkcji w
procesie monitorującym. Funkcja próbkująca nie została wyróżniona – można ją
wykorzystać w dowolnym miejscu w poniższym schemacie.
przechwytywanie nagłówków pakietów
|
znakowanie czasowe
|
v
+----->+
|
|
| klasyfikacja
|
|
+------+
|
zarządzanie rekordami przepływów
|
V
Rysunek 5.2 Algorytm procesu klasyfikowania (24)
grudzień 07
Łukasz Witaszek
39
• rekord przepływu (ang. flow record): struktura przechowująca informacje o przepływach zaobserwowanych i sklasyfikowanych w danym punkcie obserwacji. Rekord zawiera mierzalne informacje dotyczące przepływu (np. całkowita liczba bajtów w danym przepływie) oraz dane charakteryzujące sam przepływ (np. adres źródłowy IP);
• proces eksportujący (ang. exporting process): proces przesyłający rekordy przepływu (wygenerowane przez proces klasyfikujący) z punktu obserwacji do jednego
lub kilku procesów zbierających (ang. collecting process);
• proces zbierający (ang. collecting process): proces odbierający rekordy przepływów przesyłane przez jeden lub kilka procesów eksportujących. Po odebraniu może magazynować rekordy lub dalej je przetwarzać.
grudzień 07
Łukasz Witaszek
40
5.3.2 Architektura
Wykorzystując zdefiniowane powyżej pojęcia można przedstawić architekturę nowego rozwiązania za pomocą poniższego schematu (25):
proc. klasyfikatora,
proc. eksportujący
IPFIX
proc. zbierający
O----------------------------------------->O
|
| punkt obserwacji
v
---- ruch pakietów IP --->
Rysunek 5.3 Architektura IPFIX
W wybranym przez administratora punkcie sieci, w którym chcemy przeprowadzać
obserwację – stąd nazwa punkt obserwacji, umieszczony zostaje proces klasyfikatora,
współpracujący z procesem eksportera. Przepływające pakiety są analizowane pod względem zgodności ze zdefiniowanymi przepływami i jeżeli wystąpi zgodność z wzorcem
przepływu odpowiednie informacje zostają zapisane we właściwym rekordzie przepływu.
Następnie rekord lub zbiór rekordów zostaje przez proces eksportera przesłany do procesu
kolektora z wykorzystaniem protokołu IPFIX. Proces zbierający magazynuje otrzymane
rekordy i udostępnia je stacji zarządzającej (nie umieszczona na schemacie architektury),
wyposażonej w oprogramowanie, które odpowiednio przetwarza, analizuje i przedstawia
informacje w formie czytelnej dla administratora.
Podobnie jak w architekturze wprowadzonej wraz z powstaniem SNMP, w przypadku IPFIX też możemy mówić o agentach, lub bardziej poprawnie z formalnego punktu
widzenia – o sondach, oraz o stacjach nadzorujących (zbliżonych do tych z protokołu
RMON). Istotna różnica występuje w sposobie zbierania danych przez sondy w odniesieniu do metod wykorzystywanych przez agentów/nadzorców – z których korzysta
SNMP/RMON. Protokół IPFIX opiera się na pojęciu przepływu, które nie występuje w
przypadku SNMP, dzięki czemu jest lepiej dopasowany (w poprzednich podrozdziałach
było to dokładnie omówione) do monitorowania nowoczesnych sieci IP.
Warto też zwrócić uwagę, że w protokole IPFIX proces eksportera dokonuje przesłania danych do procesu zbierającego w wybranym przez siebie momencie, bez interakcji
z kolektorem. Autonomia procesu zbierającego informacje o przepływach jest charakterystyczna dla tego protokołu.
Informacje dotyczące sposobu umieszczania sondy monitorującej i lokalizacji punków obserwacji zostaną przedstawione w dalszej części rozdziału.
grudzień 07
Łukasz Witaszek
41
5.4 IPFIX – dalsze założenia protokołu
Grupa robocza opracowująca nowy standard przygotowała zbiór wymagań i uwag
(24), które muszą wziąć pod uwagę wszyscy ci, którzy chcą zaimplementować w swoich
produktach obsługę nowego protokołu.
5.4.1 Aplikacje korzystające z IPFIX
Twórcy protokołu IPFIX określają w jego specyfikacji zbiór aplikacji, do współpracy z którymi protokół był głównie dopasowywany. W rozdziałach 2. i 3. w których opisywałem zagadnienia zarządzania sieciami ze szczególnym uwzględnieniem monitorowania, starałem się przedstawić obszary, w których mają zastosowanie nowoczesne sposoby
zbierania informacji o ruchu sieciowym. Dlatego też poniżej przedstawię jedynie pobieżnie
zastosowania nowego protokołu wskazane przez jego twórców. (22)
1. Rozliczanie oparte o stopień wykorzystania zasobów (ang. Usage-based Accounting): rozliczanie usług sieciowych w oparciu o płaskie kryterium przepustowości
może wkrótce ustąpić miejsca nowemu modelowi rozliczania wykorzystującemu
ilość przesyłanych danych. Pomiary oparte o dające się szeroko dostosowywać
przepływy pozwalają przygotować rozliczenia z dokładnością per użytkownik/aplikacja/pora dnia.
2. Profilowanie ruchu sieciowego (ang. Traffic Profiling): tworzenie charakterystyki
przepływów w sieci z wykorzystaniem modelu opisanego kluczowymi parametrami
przepływu: czasem trwania, objętością, impulsywnością (ang. burstiness). Stworzenie takiej charakterystyki jest wymogiem prawidłowego planowania sieci oraz
jej późniejszej eksploatacji. Do zbioru parametrów przepływu, które są wykorzystywane do stworzenia profilu ruchu sieciowego należą: wykorzystywane usługi,
protokoły, liczba pakietów danego typu (np. IPv6). To zastosowanie protokołu
wymaga dużej elastyczności od IPFIX ze względu na różnorodny sposób profilowania ruchu.
3. Inżynieria ruchu sieciowego (ang. Traffic Engineering): składa się z metody mierzenia, charakteryzowania i kontroli sieci. Zadaniem inżynierii jest optymalizacja
wykorzystania zasobów oraz utrzymywanie wysokiej wydajności sieci przez realizowanie (z wykorzystaniem SNMP lub innych sposobów konfigurowania urządzeń) zaleceń wynikających z monitorowania. Ponieważ kontrola administratorska
grudzień 07
Łukasz Witaszek
42
wymaga dostępu do podległych węzłów sieci, zwykle mechanizmy monitorowania
i zarządzania dotyczą tej samej domeny administracyjnej.
4. Wykrywanie ataków/wtargnięć (ang. Attaca/Intrusion Detection): przechwytywanie przepływów odgrywa ważną rolę w zapewnieniu bezpieczeństwa: zarówno dla
wykrywania zagrożeń jak i tworzenia polityki bezpieczeństwa. Wykorzystując monitorowanie przepływów można np. skutecznie wykrywać źródła ataków DoS i
szybko odciążać dany zasób. Wykrywanie wtargnięć może być bardziej wymagające, ponieważ opiera się nie tyko na monitorowaniu przepływów lecz również wyszukiwaniu określonych wzorców komunikacyjnych.
5. Monitorowanie QoS (ang. QoS Monitoring): to proces biernego pomiaru parametrów określających jakość usług IP. Przykładem może być kontrola parametrów
QoS ustalonych dla danego typu usługi. Często nadzorowanie QoS wymaga informacji z wielu punktów obserwacyjnych zsynchronizowanych czasowo. To wymaga
korelacji informacji zbieranych w różnych rekordach przepływów. Ważne jest, aby
mieć świadomość, że IPFIX realizuje tylko część wymagań związanych z monitorowaniem QoS i może być traktowany jako element kompletnego systemu nadzoru
QoS. NetFlow – implementacja założeń IPFIX.
5.4.2 Rozróżnianie przepływów
Obserwowane pakiety są przypisywane do przepływów na podstawie ich określonych parametrów. Pakiety o tych samych parametrach określonych jako charakteryzujące
przepływ należą do tego samego przepływu. Pakiet, który różni się choćby jednym parametrem należy do innego przepływu. Poniżej wymienione zostaną te parametry pakietów,
które proces klasyfikujący musi być w stanie określić, aby poprawnie przypisywać pakiety
do przepływów. Nie oznacza to, iż wszystkie parametry muszą być określone w celu wyróżnienia przepływu – proces monitorujący musi dać się skonfigurować tak, aby na podstawie dowolnego podzbioru tych parametrów mógł dokonać klasyfikacji pakietu. Podzbiór tychże parametrów jest określany przez administratora, który definiuje go tak, aby
mógł zaobserwować pożądany w danej sytuacji obszar aktywności sieci. W związku z tą
elastycznością w doborze parametrów ważne jest, aby proces kolektora odbierając rekord
przepływu znał parametry, które były kluczowe dla jego określenia. Konieczne należy też
pamiętać o tym, iż proces monitorujący musi mieć dostęp do pól nagłówka pakietu warstwy sieci i warstwy transportowej, dlatego też wymagania stawiane przed procesem moni-
grudzień 07
Łukasz Witaszek
43
torującym obowiązują w sytuacjach, w których analizowane pola nie są zaszyfrowane (np.
szyfrowanie ESP, gdzie cały pakiet oryginalny zostaje zaszyfrowany i poprzedzony nagłówkiem ESP, na podstawie którego nie można nic orzec o oryginalnym pakiecie).
Sonda IPFIX musi rozróżniać przepływy w oparciu o parametry:
1. Interfejs, przez który pakiet dociera od urządzenia, którym opuszcza urządzenie
oraz kombinacja obu tych wartości.
2. Pola nagłówka IP:
a. źródłowy adres IP (również w postaci adresu prefixowego, obliczanego na podstawie dołączonej maski);
b. docelowy adres IP (również w postaci adresu prefixowego, obliczanego na podstawie dołączonej maski);
c. typ protokołu warstwy wyższej (TCP, UDP, ICMP,…);
d. w przypadku urządzeń wspierających różne wersje protokołu (IPv4 i IPv6) proces eksportujący musi mieć możliwość rozróżniania również w oparciu o ten parametr.
3. Pola nagłówka protokołu warstwy transportowej – numer portu protokołu TCP lub
UDP. Proces monitorujący może (nie jest to wg specyfikacji warunek konieczny)
analizować numer portu protokołu SCTP (ang. Streaming Control Transmission
Protocol, RFC 2960). Wymaganie jest rozróżnianie w oparciu o dowolną kombinację numerów portów, zarówno źródłowych jak i docelowych.
4. Jeżeli proces monitorujący jest uruchomiony na urządzeniu, które wspiera MPLS
(ang. Multiprotocol Label Switching, RFC 3031) musi on umożliwiać rozróżnianie
pakietów na podstawie etykiety MPLS.
5. Jeżeli proces monitorujący jest uruchomiony na urządzeniu, które wspiera DiffServ
(ang. Differentiated Services, RFC 2474) musi on umożliwiać rozróżnianie pakietów na podstawie parametru DiffServ Code Point.
5.4.3 Wymagania stawiane procesowi monitorowania
Poniżej przedstawiona zostanie lista wymagań stawianych przez twórców standardu
procesowi monitorowania, które określają jego zachowanie w różnych warunkach, jakie
występują we współczesnych sieciach komputerowych:
niezawodność: proces monitorujący musi być niezawodny lub też brak niezawodności musi być znany i wskazany. Można powiedzieć o procesie klasyfikującym że
grudzień 07
Łukasz Witaszek
44
jest niezawodny, jeżeli jest w stanie przeanalizować każdy pakiet, który przechodzi
przez punkt obserwacji. Jeżeli np. ze względu na duże obciążenie nie wszystkie pakiety mogą zostać przeanalizowane, proces monitorujący musi mieć zaimplementowaną funkcję, która to wykryje i zgłosi;
próbkowanie: proces klasyfikujący może dokonywać próbkowania przepływów,
jednak w takim przypadku konieczne jest dokładne zdefiniowanie konfiguracji
próbkowania. Jeżeli konfiguracja próbkowania ulegnie zmianie, proces próbkujący
musi powiadomić o tym wszystkie procesy zbierające, do których eksportuje rekordy przepływów. Po zmianie próbkowania, wszystkie rekordy stworzone przed
zmianą próbkowania muszą zostać zakończone i wyeksportowane do kolektora.
Niedozwolone jest wymieszanie rekordów przepływu stworzonych z wykorzystaniem różnych metod próbkowania;
zachowanie w przypadku przeciążenia: gdy z powodu przeciążenia zasoby mocy
obliczeniowej i pamięci operacyjnej są ograniczone, proces monitorujący może dostosować swoje działanie do zaistniałej sytuacji poprzez:
− zmniejszenie liczby monitorowanych przepływów poprzez bardziej gruboziarniste mierzenie przepływów lub ograniczenie ich liczby;
− wprowadzenie próbkowania przepływu nim zostanie poddany klasyfikacji lub,
jeżeli próbkowanie jest już uruchomione, zmniejszenie częstotliwości próbkowania;
− całkowite zatrzymanie monitorowania;
− obniżenie aktywności konkurujących procesów, aby większa ilość zasobów była
dostępna dla procesu monitorowania.
Podobnie jak w przypadku zmiany sposobu próbkowania, w przypadku modyfikacji spowodowanej koniecznością dostosowania do pracy z wykorzystaniem ograniczonych
zasobów proces monitorujący musi odpowiednio odseparować rekordy zainicjowane przed
zmianą od rekordów stworzony już po zmianie trybu pracy. Musi też powiadomić o zmianie procesy kolektorów, do których wysyła rekordy przepływów.
Dodawane znaczników czasu: proces musi generować znaczniki czasu dla pierwszego i ostatniego pakietu w każdym przepływie. Minimalna odległość pomiędzy
znacznikami czasu to jedna setna sekundy (0.01 s).
grudzień 07
Łukasz Witaszek
45
Synchronizowanie czasu: konieczne jest generowanie znaczników czasu z czasem
UTC. Łatwo zauważyć, że z synchronizacji znaczników czasowych z UTC wynika
wzajemna synchronizacja pomiędzy różnymi procesami eksportera.
Przeterminowywanie przepływów: proces monitorujący musi wykrywać przepływy
przeterminowane – takie, do których nie został zakwalifikowany żaden pakiet przez
określony czas przeterminowania. Proces monitorujący może zapobiegać przeterminowaniu przepływów wykrywając wcześniej logiczne zakończenie komunikacji
(np. komunikaty FIN lub RST w protokole TCP).
Monitorowanie przepływów multicastowych: dla pakietów multicastowych, kierowanych na wszystkie porty urządzenia, proces monitorujący powinien stworzyć rekordy przepływu dla każdego portu, rozróżniając je właśnie ze względu na port docelowy.
5.4.4 Model informacji – jakie informacje o przepływach są eksportowane
Poniżej zostaną wymienione parametry, które implementacja sondy musi mieć
możliwość zbierać o przepływach a następnie eksportować z wykorzystaniem rekordów
przepływu. Oczywiście nie wszystkie te parametry muszą być zawarte w każdym z rekordów. Jest to nawet niewskazane ze względu na zalecenie, aby ilość informacji monitorujących sieć była ograniczona tylko do tego, co jest administratorowi w danej chwili potrzebne i nic ponad to. Wskazane jest również ograniczanie redundancji w przekazywanych
parametrach – jeżeli jakaś wartość jest taka sama w każdym rekordzie przepływu (np.
przepływ jest obserwowany na jednym porcie urządzenia), to nie musi ona występować w
każdym z rekordów.
Lista wymaganych do przekazywania parametrów przepływów:
1. wersja protokołu IP;
2. źródłowy adres IP;
3. docelowy adres IP;
4. typ protokołu IP (TCP, UDP, ICMP,…);
5. numer portu źródłowego (dla TCP/UDP);
6. numer portu docelowego (dla TCP/UDP);
7. licznik pakietów (dla podzielonych pakietów);
8. licznik danych – określa liczbę bajtów, która została przesłana w ramach jednego przepływu;
grudzień 07
Łukasz Witaszek
46
9. oktet typ usługi z nagłówka IPv4 lub klasy ruchu (dla IPv6) (zgodnie ze specyfikacją Differentiated Services może w tym bajcie być także tzw. DiffServ Code
Point);
10. etykieta przepływu (dla IPv6);
11. etykieta MPLS (w przypadku wspierania MPLS przez urządzenia w sieci);
12. znacznik czasowy pierwszego pakietu w przepływie;
13. znacznik czasowy ostatniego pakietu w przepływie;
14. konfiguracja próbkowania (jeżeli jest wykorzystywane);
15. unikalny identyfikator punktu obserwacji;
16. unikalny identyfikator procesu eksportującego.
Parametry, które powinny być eksportowane:
17. jeżeli protokół IP to ICMP: typ ICMP;
18. interfejs wejściowy (port, którym pakiet dotarł do urządzenia – nie stosuje się
gdy punkt obserwacji jest umieszczony na urządzeniu dedykowanym do monitorowania NetFlow);
19. interfejs wyjściowy (port, którym pakiet opuścił urządzenie – nie stosuje się gdy
punkt obserwacji jest umieszczony na urządzeniu dedykowanym do monitorowania NetFlow);
20. współczynnik replikacji (Multicast): liczba pakietów wygenerowanych na podstawie jednego przychodzącego pakietu rozgłoszeniowego. Wartość ta nie jest
stała – zmienia się wraz ze zmianami zachodzącymi w sieci (np. mniej komputerów podłączonych do przełącznika).
Parametry, które mogą być eksportowane:
21. TTL (IPv4) lub Hop Limit (IPv6);
22. flagi nagłówka IP;
23. flagi nagłówka TCP;
24. licznik pakietów zagubionych w punkcie obserwacji;
25. ilość pakietów w przepływie, które były podzielone na fragmenty (fragment
bit=1);
26. adres IP następnego węzła w sieci (ang. next hop IP address);
27. numer źródłowego autonomicznego systemu BGP;
grudzień 07
Łukasz Witaszek
47
28. numer docelowy autonomicznego systemu BGP;
29. numer następnego węzła autonomicznego systemu BGP.
5.4.5 Model danych – jak skonstruowany jest rekord przepływu
Model danych, który będzie zaimplementowany w systemie budowanym w oparciu
o standard NetFlow, musi być rozszerzalny, tak aby umożliwiał dodawanie kolejnych parametrów i rozszerzanie definicji rekordów. Mimo iż zestaw atrybutów jest ustalony w
rekordzie przepływu, konieczne jest zapewnienie możliwości jego rozszerzenia na potrzeby specyficznych zastosowań.
Konieczna jest taka implementacja, w której można elastycznie zmieniać format
rekordu i przekazywane w nim parametry przepływu, tak aby unikać redundancji informacji i łatwiej je analizować.
Tworzony model danych powinien być niezależny od protokołu wykorzystywanego
protokołu transportowego.
5.4.6 Przesyłanie danych – co należy wziąć pod uwagę
Po tym, jak zostanie stworzony poprawny proces monitorujący oraz eksportujący (z
zachowaniem wymagań dotyczących elastyczności formy i treści rekordów przepływu),
konieczne jest spełnienie wymagań nałożonych na proces transportu danych. Szczególnej
uwagi wymagają zagadnienia:
•
niezawodności: utrata pakietów w czasie ich przesyłania przez proces eksportujący
do kolektora musi być przez proces zbierający wykryta w sposób, który pozwoli na
określenie liczby zaginionych pakietów. Do utraty pakietów może dojść z następujących powodów: ograniczenia procesu monitorowania lub/i eksportującego (brak
pamięci, mocy obliczeniowej), problemy w warstwie transportowej, ograniczenia
kolektora (proces nie jest w stanie odebrać wszystkich przesyłanych danych) lub
jego czasowego wyłączenia (np. ze względu na zmianę konfiguracji).
Niezawodność w przypadku wykorzystania protokołu transportowego innego niż
TCP (który gwarantuje poprawne przesłanie danych) można przenieść na wyższe
warstwy modelu. W takiej sytuacji ważne jest, aby raportować sam fakt występowania błędów, bez konieczności rozwiązywania trudności.
grudzień 07
Łukasz Witaszek
48
Implementowane rozwiązanie musi umożliwiać rozszerzanie niezawodności poprzez wdrożenie: retransmisji zagubionych rekordów, wykrywanie utraty połączenia oraz potwierdzanie odbioru danych przez kolektor.
• bezpieczeństwa: niezbędne jest zapewnienie poufności, integralności oraz autentyczności transmisji pomiędzy sondą i kolektorem. Szczegółowy opis zagrożeń będzie opisany w dalszej części niniejszego opracowania.
• trybu pracy sondy: sonda może sama decydować o momencie przesyłania rekordów
przepływu (komunikacja aktywna – ang. push mode) lub oczekiwać na żądanie kolektora nakazujące przesłanie rekordów (komunikacja pasywna – ang. pull mode).
Proces eksportujący musi obsługiwać tryb aktywny oraz może obsługiwać tryb
bierny. W przypadku komunikacji aktywnej sonda powinna mieć możliwość przesyłania rekordów w regularnych odstępach czasu.
• informowania o zdarzeniach: proces eksportujący może mieć możliwość przesyłania komunikatów (np. o pojawieniu się w sieci nowego przepływu) do kolektora.
• maskowania informacji: proces eksportujący może ukrywać źródłowy i docelowy
adres IP w przekazywanych rekordach przepływów podobnie jak numery portów i
inne informacje. Konieczność przygotowania rozwiązania do takich zadań jest wymagana przez prawo chroniące prywatność, która może zostać naruszona przez
ujawnienie informacji dotyczących aktywności sieciowej. Ukrywanie informacji
może być realizowane przez proces kolektora, o ile tylko zagwarantowana jest bezpieczna łączność pomiędzy procesem eksportera i kolektora. Algorytmy maskowania informacji są rozwijane, nim jednak powstaną standardy konieczność maskowania nie jest obligatoryjna, nie można jej bezwzględnie wymagać.
Ważne jest, aby w przypadku maskowania przez eksportera proces kolektora wiedział, że dane są zamaskowane – tak aby możliwe było rozdzielenie rekordów maskowanych od pozostałych.
5.4.7 Zagadnienia konfigurowania sondy
W odniesieniu do zagadnień związanych z konfiguracją procesu monitorującego i
eksportującego twórcy standardu wprowadzili następujące kryteria:
• Konfiguracja procesu monitorującego powinna umożliwiać:
o określenie punktu obserwacji (np. interfejs urządzenia);
o zdefiniowanie przepływów, które będą monitorowane;
grudzień 07
Łukasz Witaszek
49
o określenie czasów aktualności przepływów (ang. flow timeouts);
• Konfiguracja procesu monitorującego może umożliwiać:
o określenie metody próbkowania i jej parametrów (jeżeli jest wykorzystywane);
o określenie parametrów procesu w sytuacji przeciążenia (jeżeli taki zestaw funkcji jest dostępny dla sondy).
• Konfiguracja procesu eksportera powinna umożliwiać określenie następujących
elementów:
o format danych wykorzystywanych do eksportowania informacji o przepływach;
o proces (procesy) kolektora, do których eksporter ma przesyłać dane;
o interwał czasowy pomiędzy raportami (tylko jeżeli sonda posiada funkcję realizującą okresowe raportowanie);
o komunikaty przesyłane do kolektora (jeżeli proces eksportera ma zaimplementowaną możliwość wysyłania komunikatów do kolektora);
o maskowanie (anonimizacja) przepływów (tylko jeżeli proces eksportujący
umożliwia maskowanie eksportowanych danych).
Zalecane jest w przypadku zdalnego konfigurowania procesów sondy (monitora i
eksportera), aby wykorzystywać taki sposób połączenia, który zapewni poufność, integralność oraz autentyczność informacji konfiguracyjnych.
5.4.8 Zalecenia ogólne
Twórcy specyfikacji zalecają, aby poza wymienionymi poprzednio wymaganiami
dotyczącymi elementów architektury, twórcy oprogramowania uwzględnili wskazówki
określające cechy rozwiązania jako całości. Zwracają uwagę na:
• otwartość (elastyczność) w wykorzystaniu nowych technologii, co można zrealizować poprzez określone wcześniej wymagania dotyczące szerokiej konfiguracji procesu monitorującego i eksportującego;
• skalowalność umożliwiającą zbieranie informacji z bardzo wielu procesów monitorujących w jednym procesie zbierającym;
• możliwość komunikacji wiele do wielu (wiele procesów eksportera może wysyłać
dane do jednego procesu zbierającego oraz jeden proces eksportera może wysyłać
dane do wielu procesów zbierających). Istotnym wymogiem jest właściwa identyfikacja otrzymywanych informacji pochodzących z wielu źródeł
grudzień 07
Łukasz Witaszek
50
5.4.9 Lokalizacja punktów obserwacji i procesów IPFIX
Grupa tworząca standard nie wprowadza żadnych zaleceń (ograniczeń) jeżeli chodzi o lokalizację punktów obserwacji oraz architekturę procesów. W oparciu o rozwiązania
stosowane w implementacjach SNMP i związaną z nimi praktykę administratorów można
oczekiwać, iż najbardziej optymalne będzie umieszczenie punktu obserwacji, procesu monitorującego i eksportującego na pojedynczym urządzeniu. Jednakże standard umożliwia
również inne konfiguracje, których przykłady zostaną przedstawione poniżej. W każdym
ze schematów wyróżnia się trzy wymienione wcześniej elementy: punkt obserwacji (O) –
rozumiany jako najmniejsze z możliwych na danym urządzeniu (np. jeden interfejs urządzenia, ale już nie grupa interfejsów), proces monitorujący (M) oraz proces eksportujący
(E).
+---+
| E-+->
| | |
| M |
| | |
| O |
+---+
dedykowana
sonda
+---+
| E-+->
| | |
+-+-+
|
+-+-+
| | |
| M |
| | |
| O |
+---+
Konwerter
Protokołów
+-----+
| E--+->
| | |
| M |
| /|\ |
| OOO |
+-----+
router
+---------+
|
E----+->
|
/ \
|
| M
M |
| /|\ /|\ |
| OOO OOO |
+---------+
router
modularny
+---------+
<-+--E
E--+->
| |
| |
| M
M |
| /|\ /|\ |
| OOO OOO |
+---------+
kilka procesów
eksportera
+---+
+---+
| E-+->
| E-+------------->---+
| | |
| | | +---+
+-+-----+
| M |
| M | | E-+------->-+-C-M-E-+->
| | |
| | | | | | +---+
+-+-----+
+-+-+
| O | | M | | E-+->---+
|
+---+ | | | | | |
+-+-+
| O | | M |
| | |
+---+ | | |
+-----+
| O |
| O |
->-+-C-E-+->
+---+
+---+
+-----+
zdalny punkt
koncentrator
proxy
obserwacji
Rysunek 5.4 Rozmieszczenie elementów IPFIX w architekturze sprzętowej (24)
Pierwsze trzy schematy są standardowym, znanym również z architektury SNMP,
rozwiązaniem. Na czwartym rysunku (kilka procesów eksportera) przedstawiona jest możliwość umieszczenia kilku procesów eksportera w jednym urządzeniu, co jest wskazane w
przypadku, gdy monitorowane jest wiele przepływów i przesyłanych rekordów jest wiele.
Kolejny rysunek (konwerter protokołów) przedstawia sytuację, w której proces monitoru-
grudzień 07
Łukasz Witaszek
51
jący jest dostępny tylko z wykorzystaniem protokołu innego niż IPFIX (na przykład SNMP
Meter MIB – RFC2720). W tym przypadku proces monitora i eksportera wykorzystują
protokół dostępny dla monitora, po czym komunikacja pomiędzy eksporterem i kolektorem odbywa się już z wykorzystaniem protokołu IPFIX. Kolejny rysunek (zdalny punkt
obserwacji) ilustruje sytuację, gdzie punkt obserwacji i proces monitorujący są od siebie
logicznie oddalone. Nagłówki pakietów przechwyconych w punkcie obserwacji są przesyłane bez obróbki do urządzenia, na którym uruchomiony jest proces monitorujący. Schemat koncentratora przedstawia przykład agregowania rekordów przepływu: do koncentratora docierają rekordy przepływu (przesyłane za pomocą protokołu IPFIX), gdzie kolejny
proces monitora dokonuje klasyfikacji w oparciu o własny zestaw reguł, po czym dane są
dalej eksportowane przez kolejny proces eksportera. Ostatni z przedstawionych schematów
to urządzenie pośrednika (ang. proxy). Urządzenie zarówno otrzymuje jak i wysyła informacje z wykorzystaniem protokołu IPFIX, jego głównym zastosowaniem jest możliwość
przesyłania danych protokołu przez zapory sieciowe (ang. firewalls) i bramy (ang. gateways).
5.4.10 Zagadnienia bezpieczeństwa
Protokół IPFIX musi umożliwiać przekazywanie danych przez Internet, dlatego też
nie można wykluczyć, iż będzie on narażony na rożnego rodzaju ataki (np. na przechwytywanie lub modyfikację przesyłanych pakietów). Implementujący protokół powinni mieć
świadomość zagrożeń, na jakie mogą być wystawione systemy oparte o IPFIX a także powinni w swoich produktach oferować funkcje zapewniające bezpieczeństwo. W tym rozdziale zostaną przedstawione zagrożenia, które mogą wpływać na poprawne funkcjonowanie protokołu z perspektywy funkcji monitorującej, która jest jego głównym zadaniem.
• Ujawnienie danych o przepływach: informacje zawarte w rekordach przekazywanych w ramach protokołu IPFIX (np. w rekordach przepływu) powinny być poufne
w czasie ich przekazywania pomiędzy elementami architektury protokołu. Możliwość analizowania zawartości rekordów daje osobom niepowołanym (w domyśle –
atakującym naszą sieć) bardzo bogaty zestaw informacji o ruchu w sieci, głównych
węzłach komunikacyjnych i charakterystyce ruchu. Zdobyta wiedza pozwala nie
tylko śledzić (szpiegować) działalność użytkowników, ale też tak zaplanować
ewentualny atak, by ukryć go w ruchu sieciowym.
grudzień 07
Łukasz Witaszek
52
Poufność powinna być również zachowana ze względu na obowiązek ochrony danych użytkowników korzystających z Internetu. W wielu krajach regulacje prawne
precyzują sposób ochrony informacji dotyczących użytkowników (a do takich zaliczane są informacje o aktywności internetowej).
Aby zapewnić poufność można wykorzystać szyfrowanie, dodatkowo uzupełnione
funkcjami anonimizującymi. Dla wielu zadań monitorowania dane zamaskowane są
równie użyteczne co dane w oryginalnej formie. Z tego też względu wcześniej
wspomniane maskowanie powinno być implementowanie również z tego względu.
• Fałszerstwo rekordów przepływu: protokół IPFIX był tworzony z założeniem wykorzystania między innymi dla celów monitorowania bezpieczeństwa i wykrywania
zagrożeń. Z tego też względu ryzyko dokonywania szkodliwych zmian w przesyłanych rekordach (aby ukryć występowanie szkodliwego ruchu) jest znacznie większe niż w przypadku innych protokołów. Atak może być realizowany poprzez
zmianę rekordów przesyłanych do kolektora lub przez wprowadzanie do systemu
nowych, sfałszowanych rekordów. Szczególna uwaga jest wskazana w przypadku
wykorzystywania protokołu IPFIX do sterowania aplikacjami bezpieczeństwa. Fałszywe rekordy przepływu mogą stworzyć nieprawdziwy obraz środowiska sieciowego i obniżyć skuteczność zabezpieczeń.
Zabezpieczeniem protokołu przed tego rodzaju zagrożeniem może być wykorzystanie metod autentykacji i zapewnienia integralności.
• Atak typu Denial of Service (pol. odmówienia usługi): jedna z popularnych form
ataku na usługi wymagające komunikacji, gdzie zwykle jedna ze stron pracuje w
trybie oczekiwania na informacje. W przypadku protokołu IPFIX proces kolektora
może zostać zalany fałszywymi rekordami przepływu, przez co niemożliwe będzie
wiarygodne zbieranie informacji na temat ruchu sieciowego. Również proces monitorujący, jeżeli pracuje w trybie pasywnym (gdzie przesyłanie rekordów jest sterowane przez kolektor) oczekując na polecenia od kolektora jest narażony na przyjmowanie sfałszowanych poleceń.
Inne zagrożenie związane z tego typu atakiem może wynikać również z obserwowania przepływów związanych z usługą, która poddana jest atakowi DoS – więcej
przesyłanych pakietów może zwiększyć ilość generowanych i przesyłanych rekordów.
grudzień 07
Łukasz Witaszek
53
6 NetFlow v.9 – Cisco implementuje IPFIX
Opisany w poprzednim rozdziale protokół IPFIX został opracowany przez grupę
IETF jako standard rozwiązań dla monitorowania przepływów. Protokół NetFlow v9
wdrożony przez firmę Cisco jest implementacją IPFIX, będąc jednocześnie inspiracją dla
tego ostatniego. Grupa robocza IETF wykorzystała wiele z rozwiązań wprowadzonych
przez Cisco do rozwijanego przez siebie protokołu NetFlow. W kolejnych wersjach pojawiały się rozszerzenia przystosowujące protokół do nowych zadań i współpracy z nowymi
wersjami systemów operacyjnych (IOS) urządzeń producenta. Wiele elementów opisujących protokół NetFlow było już opisanych w czasie przedstawiania IPFIX, dlatego też
opisując standard zdefiniowany przez producenta sprzętu skupię się na elementach nie
występujących w poprzedniej specyfikacji.
6.1 RFC3954 - Cisco Systems NetFlow Services Export Version 9
Definiując 9. wersję protokołu Cisco założyło wykorzystanie własnych urządzeń
jako monitorów przepływów, wpisanych jako funkcje w system operacyjny. Wykorzystuje
również mechanizm wzorców/szablonów (ang. templates), zapewniając elastyczność w
sposobie tworzenia i interpretowania rekordów przepływów bez konieczności wprowadzania nowych wersji protokołu. Pozwala to również na zmniejszenie obciążenia sieci ruchem
generowanym przez systemy zarządzania, gdyż można ograniczyć przesyłane w rekordach
dane do niezbędnych dla realizacji określonych zadań monitorowania.
6.1.1 Pojęcia podstawowe
Poniżej zostaną omówione pojęcia, które nie były wyszczególnione w protokole
IPFIX i nie zostały wcześniej omówione (26).
• Domena obserwacji (ang. observation domain): zbiór punktów obserwacji tworzących największy z możliwych do zagregowania zbiór źródeł danych o przepływach
na danym urządzeniu. Przykładem może być karta rozszerzająca router o dodatkowe porty, gdzie każdy interfejs jest punktem obserwacji, natomiast karta tworzy
domenę obserwacji.
• Pakiet eksportowy (ang. export packet): pakiet wysyłany przez proces eksportera,
przenoszący rekordy przepływu do procesu kolektora.
grudzień 07
Łukasz Witaszek
54
• Nagłówek pakietu eksportowego: pierwsza część pakietu eksportowego. Nagłówek
dostarcza podstawowych informacji: określa wersję protokołu NetFlow, liczbę rekordów zawartych w pakiecie oraz numery sekwencyjne.
• Wzorzec rekordu danych (ang. template record): określa strukturę i sposób interpretacji pól zawartych w rekordzie przepływu.
• Wzorzec rekordu opcji (ang. options template record): określa strukturę i sposób
interpretacji pól rekordu opcji wraz z określeniem zakresu opisywanych opcji.
• Rekord opcji (ang. options data record): rekord zawierający parametry procesu
monitorowania, które są interpretowane zgonie z wzorcem rekordu opcji.
• Zbiór rekordów (ang. flow set): ogólny termin określający zbiór rekordów przepływów o zbliżonej strukturze. W pakiecie eksportowym jeden lub więcej zbiorów
przepływów znajduje się za nagłówkiem pakietu. Wyróżnia się trzy typy zbioru rekordów: zbiór rekordów wzorca, zbiór rekordów opcji, zbiór rekordów danych
(przepływów).
• Zbiór rekordów wzorca (ang. template flowset): jeden lub więcej rekordów wzorca
zgrupowanych razem w pakiecie eksportowym.
• Zbiór rekordów wzorca opcji (ang. options template flowset): jeden lub więcej rekordów wzorca opcji zgrupowanych razem w pakiecie eksportowym.
• Zbiór rekordów danych (ang. data flowset): jeden lub więcej rekordów tego samego
typu, zgrupowanych razem w pakiecie eksportowym. Składa się z rekordów przepływu (danych) lub rekordów opcji, zdefiniowanych wcześniej z wykorzystaniem
rekordów wzorca i wzorca rekordu opcji.
Zależności pomiędzy poszczególnymi reprezentuje poniższa tabela:
+------------------+---------------------------------------------+
|
|
Contents
|
|
+--------------------+------------------------+
|
FlowSet
| Template Record
|
Data Record
|
+------------------+--------------------+------------------------+
|
|
| Flow Data Record(s)
|
| Data FlowSet
|
/
|
or
|
|
|
| Options Data Record(s) |
+------------------+--------------------+------------------------+
| Template FlowSet | Template Record(s) |
/
|
+------------------+--------------------+------------------------+
| Options Template | Options Template |
/
|
| FlowSet
| Record(s)
|
|
+------------------+--------------------+------------------------+
Tabela 6.1 Zależności pojęć NetFlow (26)
grudzień 07
Łukasz Witaszek
55
6.1.2 Proces tworzenia przepływów
Parametry pakietów, na podstawie których dokonywana jest ich klasyfikacja i
przypisywanie do określonych przepływów przedstawię z wykorzystaniem ilustracji zamieszczonej przez producenta w dokumentacji protokołu (27):
Rysunek 6.1 Proces analizowania pakietów
Powyższa ilustracja prezentuje proces tworzenia przepływu, który można scharakteryzować następująco:
1. Ruch sieciowy (ang. Traffic) przepływa przez urządzenie na którym uruchomiony
jest proces monitorujący (ang. NetFlow Enabled Device).
2. Proces ten dokonuje analizy pakietu (ang. inspect packet) w oparciu o następujące
parametry:
a. źródłowy adres IP (pozwalają na wykorzystanie masek podsieci do analizowania
zakresów adresów)
b. docelowy adres IP (pozwalają na wykorzystanie masek podsieci do analizowania zakresów adresów)
c. port źródłowy
d. port docelowy
e. protokół warstwy transportowej
f. zawartość bajtu TOS (ang, Type of Service)
g. interfejs wejściowy pakietów
Uwaga: protokół NetFlow jest protokołem jednokierunkowym – pozwala analizować ruch przychodzący do interfejsu.
grudzień 07
Łukasz Witaszek
56
3. Na podstawie przeanalizowanych pakietów informacje o nich są dodawane do właściwych przepływów w pamięci podręcznej procesu monitorującego (ang. NetFlow
Cache). Na podstawie danych w tej pamięci tworzone są rekordy przepływu, przesyłane następnie do procesu kolektora (proces ten nie jest zilustrowany na powyższym rysunku).
Zbiór parametrów wymienionych w pkt. 2. daje wiele cennych informacji o zachowaniu się sieci:
• adresy źródłowe i docelowe pozwalają na określenie głównych ścieżek komunikacji;
• wykorzystywane porty charakteryzują aplikacje wykorzystywane w sieci;
• parametr TOS pozwala określić priorytet ruchu;
• określenie interfejsu pozwala na weryfikację poprawności konfiguracji urządzeń
sieciowych i tras w routerach;
• liczba pakietów pozwala określić rozmiar danych przesyłanych w danym przepływie;
• znaczniki czasowe przepływów pozwalają określić czas życia przepływów;
• informacje dotyczące routowania pakietów (adres następnego węzła, parametry
BGP);
• flagi TCP pozwalające analizować sposób nawiązywania połączenia TCP.
Ważne jest również, aby zrozumieć kiedy tworzony jest nowy przepływ, a w jakiej
sytuacji dokonywane jest jedynie uaktualnienie już istniejącego. Wymienione w punkcie 2
parametry określane są jako tzw. parametry kluczowe przepływów (ang. key fields) –
zbieżność lub rozbieżność całego zestawu tychże parametrów dla analizowanego pakietu
decyduje o tym, czy dany pakiet zostanie dodany do istniejącego przepływu czy też w
oparciu i jego parametry zostanie stworzony nowy przepływ. Zilustruję to wykorzystując
materiały Cisco (28):
1. Do sondy dociera pierwszy pakiet – ponieważ nie ma jeszcze zdefiniowanego pakietu automatycznie powstaje zbiór rekordów opisujących przepływ (rekord tworzą
parametry kluczowe oraz tzw. parametry niekluczowe (ang. non-key fields), np.
ilość pakietów i bajtów w przepływie):
grudzień 07
Łukasz Witaszek
57
Rysunek 6.2 Tworzenie rekordu przepływu #1
2. Do sondy dociera kolejny pakiet, którego parametry kluczowe są takie same jak we
wcześniej utworzonym przepływie – pakiet zostaje przypisany do przepływu przez
uaktualnienie parametrów niekluczowych (ilość pakietów i bajtów w przepływie):
3. Kolejny pakiet rożni się od poprzedniego w obszarze parametrów kluczowych, dlatego też proces monitorujący tworzy nowy przepływ:
Łatwo zauważyć, że zbieżność wymagana w zakresie aż siedmiu parametrów skutkuje generowaniu wielu przepływów, często zbyt wielu, łączonych później w procesie analizy. Aby uniknąć tego nadmiarowego rozwiązania następca NetFlow – Flexible NetFlow
(opisany w końcowych rozdziałach pracy) pozwala na bardziej elastyczne definiowanie
przepływów.
grudzień 07
Łukasz Witaszek
58
6.1.3 Dostęp do danych przepływów – poprzez interfejs urządzeń
Głównym sposobem dostępu do danych jest opisany w następnych podrozdziałach
eksport zebranych danych i ich analiza za pomocą dedykowanego oprogramowania. Jednakże, możliwy jest również dostęp z wykorzystaniem interfejsu CLI (ang. Command Line
Interface), wbudowanego w system operacyjny urządzeń Cisco – IOS (ang. Internetwork
Operating System). Poniżej zostanie przedstawiony przykładowy zrzut zawartości konsoli
(18) po zaaplikowaniu komendy ukazującej bieżącą zawartość pamięci podręcznej przepływów (znaczenie poszczególnych pól zostanie opisane w następnych rozdziałach):
R3#show ip cache flow
IP packet size distribution (469 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .968 .000 .031 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
.000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 278544 bytes
7 active, 4089 inactive, 261 added
1278 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 25736 bytes
1 active, 1023 inactive, 38 added, 38 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-WWW 71 0.0 1 40 0.1 1.3 1.2
TCP-BGP 35 0.0 1 40 0.0 1.3 1.2
TCP-other 108 0.1 1 40 0.1 1.3 1.2
UDP-other 37 0.0 1 52 0.0 0.0 15.4
ICMP 3 0.0 5 100 0.0 0.0 15.3
Total: 254 0.2 1 42 0.4 1.1 3.5
(NetFlow cache below)
SrcIf SrcIPaddress DstIf DstIPaddress Pr
SrcP DstP Pkts
Et1/0 172.16.7.2 Null 224.0.0.9
11
0208 0208 1
Et1/0 172.16.10.2 Et0/0 172.16.1.84
06
0087 0087 1
Et1/0 172.16.10.2 Et0/0 172.16.1.84
06
0050 0050 1
Et1/0 172.16.10.2 Et0/0 172.16.1.85
06
0089 0089 1
Et1/0 172.16.10.2 Et0/0 172.16.1.85
06
0050 0050 1
Et1/0 172.16.10.2 Et0/0 172.16.1.86
06
00B3 00B3 1
Et1/0 172.16.10.2 Et0/0 172.16.1.86
06
0185 0185 2
grudzień 07
Łukasz Witaszek
59
6.1.4 Dostęp do danych przepływów - proces eksportowania przepływów
Proces eksportera przepływów odpowiada za przygotowanie do przesłania i samo
przesłanie do procesu kolektora. Dla poprawności realizacji tego procesu ważne jest, aby
we właściwy sposób wyznaczyć moment zakończenia przepływu (ang. flow expiration) i
możliwość jego eksportu:
1. Wykrywanie zakończenia przepływu spowodowanego przesłaniem bitów FIN lub
RST w połączeniu TCP
2. Brak aktywności przepływu w pewnym okresie czasu (czas ten powinien być konfigurowalny, z możliwością ustawienia go na „0” dla natychmiastowego zakończenia)
3. Dla długich połączeń, gdzie przepływy są długotrwałe, proces eksportera powinien
eksportować rekordy przepływu regularnie w zadanych odstępach czasu (które powinny być konfigurowalne)
4. W przypadku wystąpienia ograniczeń w dostępnych zasobach, proces eksportera
może przedwcześnie zakończyć obserwowanie przepływu i przesłać go do kolektora.
Protokół NetFlow domyślnie wykorzystuje protokół UDP, gwarantujący wysoką
wydajność przy przesyłaniu obszernych pakietów eksportowych. Można jednak wykorzystać inne protokoły warstwy transportowej, które gwarantują poprawność transmisji (np.
protokół SCTP). Możliwe jest, że proces eksportujący do kilku kolektorów może wykorzystywać różne protokoły transportowe.
Ze względu na fakt, iż protokół UDP nie gwarantuje poprawności transmisji w obciążonym środowisku, wskazane jest, aby w przypadku takich właśnie sieci tworzyć połączenie pomiędzy procesem eksportującym i kolektorem z wykorzystaniem dedykowanego
połączenia. W przypadku gdy odległość sieciowa pomiędzy procesem eksportującym i
kolektorem jest większa niż jeden przeskok (jeden router, ang. one-hop distance) lub gdy
nie można wykorzystać dedykowanego łącza, konfiguracja połączenia powinna gwarantować procesowi eksportującemu wystarczające pasmo w każdych warunkach. Jest to ważne,
ponieważ małą przepustowość połączenia może doprowadzić do powstawania zatorów w
eksporterze.
grudzień 07
Łukasz Witaszek
60
Przedstawiony poniżej rysunek obrazuje proces powstawania przepływów i ich eksport.
Rysunek 6.5 Tworzenie i eksport rekordów przepływów
Rysunek nie jest opublikowany w ramach opisu standardu lecz w dokumencie (18)
opublikowanym prze Cisco, który przedstawia główne założenia NetFlow.
6.1.5 Struktura pakietu eksportowego (ang. Packet Layout)
Pakiet eksportowy składa się z nagłówka pakietu, za którym umieszczone są jeden
lub więcej zbiorów rekordów (flowset). Zbiory rekordów mogą być zbiorami rekordów
wzorca, danych lub opcji:
+----------+--------------------------------------------------+
|
| +------------+ +------------+ +------------+
|
| Nagłówek | | zbiór rek. | | zbiór rek. | | zbiór rek. |
|
| pakietu | | wzorca
| | danych
| | opcji
| ... |
|
| |
| |
| |
|
|
|
| +------------+ +------------+ +------------+
|
+----------+--------------------------------------------------+
Rysunek 6.6 Pakiet eksportowy (26)
Rożne typy zbiorów rekordów (flowset) są rozróżniane w oparciu o parametr
FlowSet ID: 0 – zbiór rekordów wzorca, 1 – zbiór rekordów opcji, >255 – zbiór rekordów
danych. Proces eksportujący musi kodować przesyłane dane liczbowe całkowite zgonie z
„sieciowym porządkiem bitów”, zwanym również porządkowaniem bajtów big-endian.
Rozkład zbiorów rekordów w pakiecie eksportowym jest zmienny w czasie. Dla
nowych przepływów pierwszy pakiet będzie zawierał zbiór rekordów wzorca, który poin-
grudzień 07
Łukasz Witaszek
61
formuje proces eksportera jak należy traktować dane przesyłane w zbiorach rekordów danych. Zaraz za zbiorem rekordów wzorca będą przekazywane rekordy danych (zawierające
informacje o przepływie), mogą też wystąpić rekordy opcji, sterujące procesem kolektora.
W kolejnych pakietach przepływów umieszczane będą głównie rekordy danych, ponieważ
wszystkie parametry zostały już ustawione i kolektor wie jak interpretować rekordy danych. Proces eksportera może okresowo przesyłać do kolektora pakiety składające się tylko ze zbiorów rekordów wzorca i opcji, aby zapewnić aktualność informacji procesu zbierającego.
Poniżej zostanie przedstawiona struktura poszczególnych, wymienionych wyżej,
elementów składowych pakietu.
• Format nagłówka pakietu (ang. Header Format)
Specyfikowany w następujący sposób:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Version Number
|
Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
sysUpTime
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
UNIX Secs
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rysunek 6.7 Nagłówek pakietu eksportowego (26)
Version Number – określa numer wersji protokołu NetFlow (w aktualnej wersji 9)
Count – całkowita liczba rekordów zawartych w pakiecie (suma rekordów wzorca,
danych i opcji
sysUpTime – czas (w milisekundach) od czasu uruchomienia urządzenia
UNIX Secs – czas (w sekundach) od 00:00 UTC 1970, w którym pakiet opuścił
proces eksportera
Sequence Number – zwiększany licznik wszystkich pakietów, które opuściły daną
domenę obserwacji za pośrednictwem procesu eksportera. Musi to być wartość
skumulowana i powinna być przez kolektor wykorzystywana do określenia, czy nie
został utracony jakiś pakiet eksportowy.
Source ID – 4 bajtowa wartość identyfikująca domenę obserwacji eksportera. procesy zbierające powinny wykorzystywać kombinację źródłowego adresu IP i war-
grudzień 07
Łukasz Witaszek
62
tość parametru Source ID do rozdzielania różnych strumieni eksportowych pochodzących z tego samego procesu eksportującego.
6.1.6 Formaty zbiorów rekordów (ang. FlowSet Format)
• Format zbioru rekordów wzorca (ang. Template FlowSet Format)
Jednym z głównych elementów formatu NetFlow jest zbiór rekordów wzorca.
Wzorce znacząco rozszerzają elastyczność formatu rekordu przepływu, pozwalając
procesowi zbierającemu przetwarzać dane przesyłane w rekordach bez konieczności interpretacji wszystkich danych zawartych w przepływie. Format zbioru rekordów wzorca wygląda następująco:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
FlowSet ID = 0
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Template ID 256
|
Field Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Field Type 1
|
Field Length 1
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Field Type 2
|
Field Length 2
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Field Type N
|
Field Length N
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Template ID 257
|
Field Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Field Type 1
|
Field Length 1
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Field Type 2
|
Field Length 2
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Field Type M
|
Field Length M
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Template ID K
|
Field Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rysunek 6.8 Format zbioru rekordów wzorca (26)
FlowSet ID – wartość ID zbioru rekordów, dla wzorca ma wartość „0”.
Length – całkowita długość zbioru rekordów. Ponieważ pojedynczy zbiór rekordów
wzorca może zawierać wiele rekordów, wartość length jest wykorzystywana do
wyznaczenia początku kolejnego zbioru rekordów (który może być dowolnego typu).
grudzień 07
Łukasz Witaszek
63
Template ID: każdy z nowo wygenerowanych rekordów wzorca otrzymuje unikalny (w ramach domeny obserwacji) numer identyfikacyjny. Template ID z zakresu
0-255 są zarezerwowane dla zbiorów rekordów wzorca, opcji lub innych specjalnych typów rekordów. Template ID z zakresu 256-65535 określają zbiory rekordów danych przepływów.
Field Count: określa ilość pól w danym wzorcu. Ponieważ zbiór rekordów wzorca
może zawierać więcej niż jeden rekord, pole to pozwala procesowi kolektora wyznaczyć koniec danego rekordu wzorca i początek kolejnego.
Field type: wartość liczbowa reprezentująca typ pola. Wartości te zostaną omówione szczegółowo w dalszej części pracy.
Field length: długość pola danych typu określonego przez poprzedni parametr.
Wartości te zostaną omówione szerzej w następnych rozdziałach.
•
Format pakietu danych (ang. Data FlowSet Format)
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
FlowSet ID = Template ID
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Record 1 - Field Value 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rysunek 6.9 Format zbioru rekordów danych przepływów (26)
FlowSet ID=Template ID: każdy ze zbioru rekordów danych jest jednoznacznie
skojarzony z wygenerowanym wcześniej i opisującym go zbiorem rekordów wzorca. Kolektor musi korzystać z tego parametru do odszukiwania właściwego szablonu, tak aby wykorzystując go prawidłowo odczytać przesyłane dane.
Length: długość zbioru rekordów. Jest to suma długości pola FlowSetID, samego
pola Length oraz rekordów zgromadzonych w tym zbiorze oraz dopełnienia jeżeli
występuje.
Record N – Field Value M: zbiór rekordów przepływów, gdzie każdy zawiera zbiór
wartości.
grudzień 07
Łukasz Witaszek
64
Padding: dopełnienie, które eksporter powinien umieścić aby kolejny zbiór rekordów rozpoczynał się z wyrównaniem do czterech bajtów. Pole Length uwzględnia
występowanie dopełnienia, które powinno być wypełnione „0”.
Poprawność interpretacji rekordów przepływu wymaga dostępności w procesie kolektora wzorca odpowiadającego przesłanym rekordom danych.
6.1.7 Pakiety opcji
Protokół NetFlow w wersji 9. wykorzystuje do przekazywania informacji tzw. rekordy opcji. Podobnie jak w przypadku rekordów danych przepływów, również przy przekazywaniu opcji wykorzystywane są rekordy i szablony, które pozwalają na definiowanie
formatu rekordów danych opcji. Poniżej przedstawione zostaną formaty rekordów opcji i
wzorca rekordu opcji.
• Format zbioru rekordów wzorca opcji (ang. Options Template FlowSet Format)
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
FlowSet ID = 1
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Template ID
|
Option Scope Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Option Length
|
Scope 1 Field Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Scope 1 Field Length
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Scope N Field Length
|
Option 1 Field Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Option 1 Field Length
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Option M Field Length
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rysunek 6.10 Format wzorca zbioru rekordów opcji (26)
FlowSet ID=1: wartość „1” zarezerwowana dla wzorca zbioru rekordów opcji (ang.
Options FlowSet).
Length: łączna długość tego zbioru rekordów wzorca opcji. Ponieważ każdy zbiór
może zawierać różną liczbę rekordów, wartość ta jest wykorzystywana do wyznaczenia pozycji kolejnego zbioru rekordów.
Template ID: ID danego wzorca, większa od 255 (pozwala, podobnie jak w przypadku rekordów danych przepływów, odnaleźć pasujący rekord danych).
grudzień 07
Łukasz Witaszek
65
Option Scope Length: długość w bajtach pól definiujących obszar (Scope – opisany
dalej) zawartych w zbiorze – pozwala wyznaczyć granice definicji poszczególnych
obszarów.
Option Length: długość (w bajtach) wszystkich pól definiujących zakresy opcji w
danym zbiorze – pozwala wyznaczyć pierwszy rekord opisujący opcję.
Scope 1 Field Type: określa zakres działania opcji zawartych w rekordach. W
chwili obecnej zdefiniowane są następujące obszary konfiguracji:
1. System
2. Interface
3. Line Card
4. Cache
5. Template
Dla przykładu proces monitora może być uruchomiony w oparciu o interfejsy, więc
jeżeli za pomocą rekordów opcji dokonywane są zmiany w sposobie monitorowania interfejsu, pole „Scope 1 Field Type” ma wartość 2 („Interface”).
Scope 1 Field Length: długość (w bajtach) pola określającego zakres działania
opcji.
Option 1 Field Type: liczbowa wartość reprezentująca typ pola rekordu. Typy pól
zostaną określone dalej w dokumencie.
Option 1 Field Length: długość (w bajtach) pola opcji.
grudzień 07
Łukasz Witaszek
66
• Format zbioru rekordów danych opcji (ang. Options Data Record Format)
Opisany powyżej zbiór rekordów wzorca opcji opisuje sposób, w jaki należy interpretować zbiory rekordów opcji, których format zostanie zaprezentowany poniżej.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
FlowSet ID = Template ID
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Record 1 - Scope 1 Value
|Record 1 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rysunek 6.11 Format zbioru rekordów opcji (26)
FlowSet ID = Template ID: parametr poprzedzający każdy zbiór rekordów opcji,
tworząc powiązanie z właściwym wzorcem rekordów opcji, dzięki czemu wiadomo
jak interpretować rekordy opcji (w tym typ i długość pól rekordów).
Length: długość zbioru rekordów, będąca sumą długości pół: FlowSet ID, Length,
wszystkich rekordów opcji w zbiorze oraz dopełnienia.
Record N – Option Field M Value: zbiór rekordów, z których każdy składa się z
pola określającego zasięg, którego dotyczą parametry występujące w tym samym
rekordzie oraz pól przekazujących wartości tych zmiennych.
Warto, po raz kolejny, zaznaczyć konieczność przekazywania aktualnych rekordów
wzorca, które pozwalają właściwie interpretować przesyłane opcje, zmieniające parametry
pracy procesów.
grudzień 07
Łukasz Witaszek
67
6.1.8 Zarządzanie wzorcami
Ze względu na kluczową rolę wzorców w całym procesie wymiany informacji konieczne jest usystematyzowanie zarządzania nimi, w szczególności należy pamiętać o:
• zbiory rekordów danych o przepływach mogą być przekazywane w tym samym pakiecie co odpowiadający mu zbiór rekordów wzorca. Ponieważ rekordy wzorca nie
są przekazywane w każdym pakiecie eksportowym proces kolektora musi mieć
możliwość przechowywania i zarządzania rekordami wzorców, tak aby w każdej
chwili dysponować właściwym dla otrzymywanych rekordów przepływów szablonem;
• konieczne jest zaimplementowanie w procesie kolektora, który może odbierać dane
z kilku procesów eksportujących, funkcji która będzie zarządzała wzorcami otrzymanymi od różnych procesów eksportujących;
• identyfikatory wzorców (Templates ID) muszą pozostawać stałe w czasie pracy
procesu eksportera i kolektora. Gdy któryś z procesów zostanie zatrzymany informacje dotyczące wzorców zostaną utracone i konieczne będzie ponowne przesłanie
wzorców z nowo utworzonymi identyfikatorami;
• nowo tworzony rekord wzorca ma przypisywany niewykorzystany do tej pory identyfikator. W przypadku zmiany wzorca jego identyfikator jest porzucany i nie powinien być ponownie wykorzystany aż do czasu restartu procesu eksportera;
• proces kolektora po otrzymaniu nowego wzorca o tym samym ID powinien odrzucić poprzedni i wykorzystywać nowo przesłany;
• w przypadku tworzenia nowego rekordu wzorca w miejsce wcześniej usuniętego o
dokładnie takich samych parametrach, identyfikator może pozostać taki sam.
Proces eksportera wysyła zbiory rekordów wzorca oraz zbiory rekordów wzorca
opcji zachowując następujące warunki:
1. Po zrestartowaniu procesu monitorującego eksporter nie może wysłać żadnego
zbioru rekordów danych przepływów bez uprzedniego przesłania odpowiadającego
zbioru rekordów wzorca oraz (jeżeli jest wymagany) zbioru rekordów wzorca opcji;
2. W przypadku zmian konfiguracji, proces eksportera powinien przesłać nowy zbiór
rekordów wzorca (danych przepływu oraz opcji) w skróconym czasie obsługi. Mo-
grudzień 07
Łukasz Witaszek
68
że na przykład przesłać pakiet eksportowy nie zawierający rekordów danych lecz
tylko wspomniane rekordy wzorców;
3. Eksporter musi przesyłać aktualne rekordy wzorców regularnie, aby utrzymywać
proces kolektora na bieżąco ze zmianami. Identyfikatory wzorców są ograniczone
czasowo i muszą być regularnie odświeżane. Aby to zrealizować wykorzystywane
są dwie metody:
a. co każde N pakietów eksportowych przesyłany jest zbiór rekordów wzorców;
b. co N minut przesyłany jest zbiór rekordów wzorców.
Zarówno jedno jak i drugie podejście muszą być możliwe do skonfigurowania. Gdy
jeden z warunków (a lub b) jest spełniony, musi nastąpić przekazanie rekordów
wzorców.
4. W przypadku zmiany konfiguracji zegara proces eksportera powinien przekazać rekordy wzorców w przyspieszonym trybie.
grudzień 07
Łukasz Witaszek
69
6.1.9 Definicje typów pól opisujących parametry przepływów
W opisach formatu rekordów pojawiały się pojęcia odnoszące się do typów pól,
które mogą występować w rekordach danych i rekordach wzorców. Poniżej zostanie
przedstawiona lista tych typów wraz z krótkim opisem. Pola te odwzorowują wybrane parametry z nagłówka pakietu, informacje routowania (numer systemu autonomicznego, maska podsieci) i właściwości samego pakietu (np. długość). Wymagania co do konieczności
implementacji poszczególnych typów pól zostały przedstawione w rozdziale opisującym
protokół IPFIX (podrozdział 5.4.4 – Model Danych).
Typ pola
IN_BYTES
War-
Długość
tość
(bajty)
1
N
Opis
Licznik
bajtów
należących
do
przychodzących,
przepływu,
dłu-
gość N bajtów, domyślnie N=4
IN_PKTS
2
N
Licznik
pakietów
przychodzą-
cych, należących do przepływu,
długość N bajtów, domyślnie N=4
FLOWS
3
N
Liczba
zagregowanych
przepły-
wów, domyślnie N=4
PROTOCOL
4
1
Bajt określający protokół IP
TOS
5
1
Ustawienie bajtu TOS pakietu na
wejściu interfejsu
TCP_FLAGS
6
1
Skumulowany
zapis
zbioru
flag
TCP dla danego przepływu
L4_SRC_PORT
7
2
Numer źródłowego portu TCP/UDP
IPV4_SRC_ADDR
8
4
Adres źródłowy IPv4
SRC_MASK
9
1
Maska
podsieci
źródła
pakietu
(w notacji „/”, inaczej długość
maski)
INPUT_SNMP
10
N
Numer
portu
wejściowego
urzą-
dzenia. Domyślnie N=2
L4_DST_PORT
11
2
Numer portu docelowego TCP/DST
IPV4_DST_ADDR
12
4
Adres docelowy IPv4
DST_MASK
13
1
Maska podsieci celu pakietu (w
notacji
„/”,
inaczej
długość
maski)
grudzień 07
Łukasz Witaszek
70
Typ pola
OUTPUT_SNMP
War-
Długość
tość
(bajty)
14
N
Opis
Numer
portu
wyjściowego
urzą-
dzenia. Domyślnie N=2
IPV4_NEXT_HOP
15
4
Adres IPv4 kolejnego routera na
trasie pakietu.
SRC_AS
16
N
Numer źródłowego systemu autonomicznego BGP. Domyślnie N=2,
może być też N=4.
DST_AS
17
N
Numer docelowego systemu autonomicznego BGP. Domyślnie N=2,
może być też N=4.
BGP_IPV4_NEXT_HOP
18
4
trasie pakietu w domenie BGP.
MUL_DST_PKTS
19
N
Licznik
wychodzących
pakietów
Multicast. Domyślnie N=4
MUL_DST_BYTES
20
N
Licznik
wychodzących
(oktetów)
Multicast.
bajtów
Domyślnie
N=4
LAST_SWITCHED
21
4
Parametr
sysUptime
(w
milisekundach) w którym ostatni
pakiet
w
ramach
danego
przepływu został przełączony.
FIRST_SWITCHED
22
4
Parametr
sysUptime
milisekundach)
w
(w
którym
pierwszy pakiet w ramach danego
przepływu został przełączony.
OUT_BYTES
23
N
Licznik
bajtów
wychodzących
do
przepływu.
pakietów
wychodzących
należących
Domyślnie N=4.
OUT_PKTS
24
N
Licznik
należących
do
przepływu.
Do-
myślnie N=4.
IPV6_SRC_ADDR
27
16
Adres źródłowy IPv6
IPV6_DST_ADDR
28
16
Adres docelowy IPv6
IPV6_SRC_MASK
29
1
Długość maski podsieci źródłowej.
IPV6_DST_MASK
30
1
Długość maski podsieci docelowej.
grudzień 07
Łukasz Witaszek
71
Typ pola
IPV6_FLOW_LABEL
War-
Długość
tość
(bajty)
31
3
Opis
Etykieta
przepływu
protokołu
IPv6 (RFC2460)
ICMP_TYPE
32
2
Typ pakietu ICMP
MUL_IGMP_TYPE
33
1
Typ pakietu IGMP
SAMPLING_INTERVAL
34
4
Gdy wykorzystywane jest próbkowanie
pole
pakietów
to
określa
realizowana
co
ile
jest
ta
operacja.
SAMPLING_ALGORITHM
35
1
Gdy
wykorzystywane
jest
próbkowanie określa zastosowany
algorytm:0x01
–
deterministyczne,
FLOW_ACTIVE_TIMEOUT
36
2
0x02
-
Czas (w sekundach) traktowania
przepływu jako aktywny.
FLOW_INACTIVE_
37
2
_TIMEOUT
ENGINE_TYPE
Czas (w sekundach) traktowania
przepływu jako nieaktywny.
38
1
Typ
urządzenia
przełączającego
przepływy (np. procesor routera)
ENGINE_ID
39
1
Identyfikator
urządzenia
prze-
łączającego.
TOTAL_BYTES_EXP
40
N
Licznik bajtów wyeksportowanych
przez
daną
domenę
obserwacji.
Domyślnie N=4.
TOTAL_PKTS_EXP
41
N
Licznik
pakietów
wyeksportowanych
domenę
TOTAL_FLOWS_EXP
42
N
obserwacji.
Licznik
domenę
46
1
MPLS_TOP_LABEL_
47
4
_IP_ADDR
daną
Domyślnie
przepływów
wyeksportowanych
MPLS_TOP_LABEL_TYPE
przez
przez
obserwacji.
daną
Domyślnie
0x00 UNKNOWN
0x01 TE-MIDPT
0x02 ATOM
0x03 VPN
0x04 BGP
0x05 LDP
Parameter Forwarding Equivalent
Class MPLS.
grudzień 07
Łukasz Witaszek
72
Typ pola
FLOW_SAMPLER_ID
War-
Długość
tość
(bajty)
48
1
Opis
Identyfikator
zwracany
przez
polecenie “show flow-sampler”
FLOW_SAMPLER_MODE
49
1
Typ
algorytmu
używanego
do
próbkowania danych: 0x02 losowe
FLOW_SAMPLER_
50
4
_RANDOM_INTERVAL
Skojarzony z powyższym: odstęp
(mierzony
ramkami)
pomiędzy
próbkowaniem.
DST_TOS
55
1
Bajt TOS pakietu na wyjściu z
urządzenia.
SRC_MAC
56
6
Źródłowy adres MAC.
DST_MAC
57
6
Docelowy adres MAC.
SRC_VLAN
58
2
Identyfikator
VLAN
związany
z
związany
z
portem wejściowym.
DST_VLAN
59
2
Identyfikator
VLAN
portem wyjściowym.
IP_PROTOCOL_VERSION
60
1
Wersja
protokołu
IP:IPv4-4,
IPv6-6, jeżeli nie występuje we
wzorcu, zakłada się 4.
DIRECTION
61
1
Kierunek przepływu:0-we,1-wy
IPV6_NEXT_HOP
62
16
trasie
BGP_IPV6_NEXT_HOP
63
16
trasie w domenie BGP
IPV6_OPTION_HEADERS
64
4
Bitowa reprezentacja pola opcji
w nagłówku IPv6.
MPLS_LABEL_1
70
3
Etykieta MPLS na pozycji 1. w
stosie.
MPLS_LABEL_2
71
3
stosie.
MPLS_LABEL_3
72
3
stosie.
MPLS_LABEL_4
73
3
stosie.
MPLS_LABEL_5
74
3
stosie.
grudzień 07
Łukasz Witaszek
73
Typ pola
MPLS_LABEL_6
War-
Długość
tość
(bajty)
75
3
Opis
stosie.
MPLS_LABEL_7
76
3
stosie.
MPLS_LABEL_8
77
3
stosie.
MPLS_LABEL_9
78
3
stosie.
MPLS_LABEL_10
79
3
stosie.
Tabela 6.2 Tabela typów pól (26)
Można zauważyć nieciągłość w wartościach typu pola, która wynika z faktu rezerwacji następujących wartości:25, 26, 43 do 45, 51 do 54 oraz 65 do 69. Mogą one zostać
wykorzystane w procesie udoskonalania protokołu.
W przypadkach, gdzie nie dokonano jednoznacznie określenia rozmiaru pola kierowano się dużą zmiennością charakteryzowanych parametrów, co mogłoby prowadzić do
nieoptymalnego wykorzystania pasma i pamięci operacyjnej.
grudzień 07
Łukasz Witaszek
74
6.1.10 Proces kolektora
Proces zbierający otrzymuje wzorce rekordów od eksportera, zwykle przed otrzymaniem zbiorów rekordów danych (opcji). Taka kolejność gwarantuje prawidłowe zdekodowanie informacji przekazanej za pomocą rekordów danych lub opcji. Jeżeli rekordy
wzorca dotrą do procesu kolektora z opóźnieniem, powinien on mieć możliwość przechowania otrzymanych wcześniej rekordów danych, aby w momencie otrzymania szablonów
dokonać ich przetworzenia i zapisać wyniki obserwacji. Implementując proces kolektora
nie można założyć, że zbiory rekordów danych i odpowiadające im zbiory rekordów wzorca są przesyłane w tym samym pakiecie eksportowym, podobnie jak nie można zakładać,
iż w takim pakiecie znajduje się tylko jeden zbiór rekordów wzorca.
Okres ważności wzorca jest ograniczony do ustalonego, odświeżalnego przedziału
czasu, po upływie którego wzorzec uznawany jest za nieaktualny i nie będzie wykorzystywany do interpretacji nadchodzących rekordów danych.
W każdej chwili proces zbierający powinien utrzymywać najświeższe wartości następujących parametrów rekordów wzorca danych i rekordów wzorca opcji: oznaczenie
procesu eksportera, domeny obserwacji, identyfikatora wzorca (unikalnego w ramach procesu eksportera i domeny obserwacji), definicji wzorca oraz wskazanie ostatnio otrzymanego rekordu.
Proces kolektora musi natychmiast po otrzymaniu nowego wzorca o tym samym
identyfikatorze nadpisać poprzedni i wykorzystywać nowo otrzymany szablon. Proces kolektora musi też właściwie interpretować pola dopełnienia występujące w przesyłanych
zbiorach rekordów.
6.1.11 Zagadnienia bezpieczeństwa
Twórcy protokołu NetFlow założyli, że proces monitorująco-eksportujący oraz
proces(y) kolektora znajdują się w obrębie jednej prywatnej (a co za tym idzie bezpiecznej) sieci. Jednakże protokół może być wykorzystywany do komunikacji w środowisku
Internetu, dlatego też należy zwrócić uwagę na mogące się pojawić zagrożenia. Ich szczegółowy opis został przedstawiony przy opisie zaleceń IPFIX dotyczących bezpieczeństwa
(podrozdział 5.4.10 – Zagadnienia bezpieczeństwa). Specyfikacja Cisco nie rozszerza tego
opisu, jak również nie implementuje metod bezpieczeństwa, ze względu na wcześniej
wspomniane założenie wykorzystania technologii w bezpiecznych sieciach.
grudzień 07
Łukasz Witaszek
75
6.2 Przykład
Opis mechanizmu wzorców, wprowadzonego w 9. wersji protokołu, jest skomplikowany, dlatego też w specyfikacji zamieszczony został przykład obrazujący współdziałanie wzorców i zbiorów rekordów (26 str. 29 i następne). Oto jak wyglądają zbiory rekordów i zbiory wzorców tychże rekordów, których zadaniem jest dostarczenie następujących
informacji:
− źródłowy adres IP (IPv4)
− docelowy adres IP (IPv4)
− adres IP (IPv4) następnego węzła (routera)
− liczba bajtów w przepływie
− liczba pakietów w przepływie
Aby przesyłać rekordy danych przepływów niosących wymienione informacje konieczne jest uprzednie przesłanie do procesu eksportera szablonu opisującego strukturę
tych informacji. Szablon wygląda następująco:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
FlowSet ID = 0
|
Length = 28 bytes
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Template ID 256
|
Field Count = 5
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
IP_SRC_ADDR = 8
|
Field Length = 4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
IP_DST_ADDR = 12
|
Field Length = 4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
IP_NEXT_HOP = 15
|
Field Length = 4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
IN_PKTS = 2
|
Field Length = 4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
IN_BYTES = 1
|
Field Length = 4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rysunek 6.12 Przykład zbioru rekordów wzorca (26)
Dane umieszczone w rekordzie są zaczerpnięte m. in. z tabeli określającej typy pól.
Załóżmy, że dla potrzeb przykładu chcemy przesłać informacje o trzech przepływach,
przedstawionych poniżej:
Źródłowy
| Docelowy
| Adres IP na| Liczba
| Liczba
adres IP
| adres IP
| stępnego węzła | pakietów | bajtów
-----------------------------------------------------------------198.168.1.12 | 10.5.12.254 | 192.168.1.1
| 5009
| 5344385
192.168.1.27 | 10.5.12.23
| 192.168.1.1
| 748
| 388934
192.168.1.56 | 10.5.12.65
| 192.168.1.1
| 5
| 6534
Tabela 6.3 Przykładowe przepływy (26)
grudzień 07
Łukasz Witaszek
76
Gdy proces sformatuje rekordy danych przepływów opisujące powyższe dane z
wykorzystaniem przedstawionego wcześniej szablonu, otrzymamy następujący zbiór rekordów danych przepływu:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
FlowSet ID = 256
|
Length = 64
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
198.168.1.12
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
10.5.12.254
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
192.168.1.1
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
5009
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
5344385
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
192.168.1.27
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
10.5.12.23
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
192.168.1.1
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
748
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
388934
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
192.168.1.56
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
10.5.12.65
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
192.168.1.1
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
5
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
6534
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tabela 6.4 Przykładowy zbiór rekordów danych przepływów (26)
grudzień 07
Łukasz Witaszek
77
7 NetFlow
N tFlow w praktyce
pr ktyce – wskazów
ws azówkii imp
implemen
lementacy
cyjne
W poprzednich rozdziałach pracy zostały przedstawione argumenty, które doprodopr
wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji
nowych standardów pozwolił zrozumieć sposoby zbierania i przesyłania infor
informacji
macji o rur
chu sieciowym. Poniżej przedstawionych zostanie kilka kluczowych aspektów związanych
z implementacją NetFlow, przeanalizowanych na podstawie dokumentacji i praktycznych
doświadczeń inżynierów sieci korporacyjnej firmy Cisco.
7.1 Właściwa architektura systemu
Aby monitorować z wykorzystaniem NetFlow konieczne
konieczn jest przygotowanie (jed(je
nej lub kilku) stacji zarządzania, z zainstalowanym właściwym oprogramowaniem. Dla
poprawnej implementacji monitorowania opartego na analizowaniu przepływów ważne
jest również
również właściwe rozmieszczenie elementów architektury – sond, kolektorów i stacji
zarządzania, w monitorowanej sieci. Aspekty te zostaną krótko omówione w poniższych
zarządzania,
podrozdziałach.
7.1.1 Oprogramowanie stacji zarządzania
Opis architektury w poprzednich rozdziałach koncentrował się głównie na końcokońc
wych elementach: sondach, procesach eksportujących oraz kolektorach.
Rysunek 7..1 Podział architektury NetFlow (30)
grudzień 07
Łukasz Witaszek
78
W praktycznych zastosowaniach najważniejszy jest jednak wynik obserwacji prowadzonych przez sondy. Zbieranie danych oraz ich wizualizacja jest zadaniem oprogramowania raportującego. W zależności od wielkości nadzorowanej sieci wykorzystywane
są różne rozwiązania, które integrują w sobie różne elementy architektury.
Najpopularniejsze rozwiązania implementowane w małych i średnich sieciach wykorzystują zgrupowanie w jednym pakiecie procesu (programu) kolektora, obszaru przechowywania danych oraz aplikacji raportującej:
Rysunek 7.2 Komponenty stacji zarządzania NetFlow
W przypadku dużych sieci, w których jest wiele rozproszonych punktów obserwacji generujących duże ilości rekordów przepływu stosuje się zwielokrotnianie procesów
kolektora oraz powiązanych z nim obszarów przechowywania danych o przepływach, z
których dane są pobierane przez stację zarządzania. Oczywistą zaletą takiego rozwiązania
(poza zmniejszeniem obciążenia sieci wynikającej z transportu informacji o przepływach)
jest większa odporność na awarie (np. brak przestrzeni na magazynowanie uniemożliwi
monitorowanie tylko fragmentu sieci). Łatwo też wprowadzić redundancję stacji nadzorujących, co wynika z niezależności od źródła danych.
W dokumencie przedstawiającym technologię NetFlow Cisco sugeruje, aby przy
wyborze właściwego oprogramowania dla stacji zarządzania kierować się następującymi
kryteriami (18):
• jakie będzie główne zastosowanie NetFlow (zagadnienia bezpieczeństwa, planowania sieci i inżynierii ruchu, monitoring i rozliczanie wykorzystania usług)?
• czy ważne jest kontrolowanie w czasie rzeczywistym czy też analiza danych historycznych?
grudzień 07
Łukasz Witaszek
79
• pod kontrolą jakiego systemu operacyjnego będzie pracowała aplikacja zarządzania?
• czy NetFlow będzie wykorzystywany w dużej sieci czy też w niewielkiej, jakie są
perspektywy rozwoju?
• ile można zapłacić za oprogramowanie stacji zarządzania?
• czy są już wdrożone jakieś inne mechanizmy monitorowania? Jeżeli tak to czy
można je rozszerzyć o moduł obsługujący NetFlow?
Analiza powyższych punktów może ułatwić podjęcie trafnej decyzji, która zagwarantuje sprawny system monitorowania, spełniający wymagania eksploatacyjne oraz pozwoli na zachowanie właściwego stosunku oferowanej funkcjonalności i ceny wybranego
oprogramowania. Koszt oprogramowania i jego wdrożenia w przypadku wielu rozwiązań
może odgrywać znaczącą rolę, ponieważ opłaty za program zwykle liczone są one w dziesiątkach, a czasami nawet setkach tysięcy dolarów. Warto też wziąć pod uwagę, iż większość rozwiązań przygotowywanych jest na platformy Unixowe/Linuxowe, choć w ostatnim czasie przybywa rozwiązań uruchamianych pod kontrolą systemów operacyjnych
Windows.
Poniżej znajduje się lista oprogramowania służącego analizowaniu ruchu z wykorzystaniem NetFlow, gdzie Cisco umieściło listę produktów komercyjnych swoich partnerów. Wspomniany wcześniej aspekt finansowy przedstawiony jest w formie przedziałów
cenowych: niski <$7500, średni <$25000 oraz wysoki >$25000.
grudzień 07
Łukasz Witaszek
80
Nazwa produktu
Główne zastosowa-
Główny odbiorca
System
/ producenta
nie
rozwiązania
operacyjny
Cisco NetFlow
Analiza ruchu
przedział
cenowy
Linux, Solaris
Średni
Linux
Średni
Windows
Niski
usług
Collector
Cisco CS-Mars
Korporacje, dostawcy
Początkowy
Monitoring bezpieczeń-
Korporacje, małe i
stwa
średnie przedsiębiorstwa
AdventNet – Net-
Analiza ruchu
średnie przedsiębior-
Flow Analyzer
Netusage - Apo-
Korporacje, małe i
stwa
Analiza ruchu
Korporacje
Linux
Średni
Analiza ruchu/monitoring
BSD
Wysoki
bezpieczeństwa
usług
Analiza ruchu/monitoring
Linux
Średni
bezpieczeństwa
usług
Analiza ruchu
Korporacje, małe i
Windows
Średni
apsis
Arbor Networks
Caligare
Fluke Networks
stwa
HP (OpenView)
IBM Aurora
IdeaData
InfoVista
IsarNet
Lancope
NetQoS
Valencia Systems
Analiza ruchu
Korporacje, ISP
Linux, Solaris
Wysoki
Analiza ruchu / monito-
Linux
Średni
ring bezpieczeństwa
usług
Analiza ruchu
Korporacje
Win / Linux
Średni
Analiza ruchu
Windows
Wysoki
Linux
Średni
Linux
Wysoki
Windows
Wysoki
usług
Analiza ruchu
usług
Analiza ruchu / monito-
ring bezpieczeństwa
usług
Analiza ruchu
usług
Analiza ruchu
Korporacje
Windows
Wysoki
Analiza ruchu
Korporacje, małe i
Windows
Niski
Windows
Wysoki
Solarwinds
stwa
WiredCity
Analiza ruchu
Korporacje
Tabela 7.1 Komercyjne oprogramowanie stacji zarządzania (16)
grudzień 07
Łukasz Witaszek
81
Uzupełnieniem powyższej listy produktów jest zbiór rozwiązań bezpłatnych, tworzonych w większości zgodnie z ideologią Otwartego Oprogramowania (ang. Open Source). Najczęściej nie są to rozwiązania które można stosować w organizacjach o rozległej
infrastrukturze, raczej sprawdzą się w przypadku małych sieci lokalnych do monitorowania niezbyt intensywnego ruchu sieciowego. Cisco proponuje zaznajomienie się z następującymi rozwiązaniami:
Nazwa produktu /
producenta
Główne zastosowanie
System opera-
Komentarz
cyjny
Flow-tools
Program kolektora
Skalowalne
Unix
Flowd
Program kolektora
Obsługuje V9
BSD, Linux
Program raportujący współpracująFlowScan
IPFlow
NetFlow Guide
Unix
cy z pakietem Flow-Tools
Analiza ruchu
Obsługuje
V9,
oraz IPv6, MPLS
Program raportujący
IPv4
Linux, FreeBSD,
Solaris
BSD, Linux
Analiza ruchu
Obsługuje V9
Linux
Program kolektora, sonda progra-
Obsługuje V9
Unix
NetFlow Monitor
NTOP
mowa
Monitoring bezpieczeństwa
Unix
Program raportujący współpracują-
Unix
Panoptis
Stager
cy z pakietem Flow-Tools
Tabela 7.2 Bezpłatne oprogramowanie stacji zarządzania (16)
7.1.2 Rozmieszczenie sond protokołu NetFlow
Bez wątpienia kluczowym zadaniem przy konstruowaniu systemu monitorowania
opartego o analizę przepływów jest właściwe rozmieszczenie procesów monitorujących
(sond) w topologii sieci. Kluczowymi punktami w strukturze sieci IP są routery, które realizują założenia logicznego podziału infrastruktury na podsieci. Dlatego też Cisco wyposaża system operacyjny tychże urządzeń w funkcje sondy z szerokim zakresem konfiguracji. W związku z tym budowanie sieci w oparciu o sprzęt tego producenta gwarantuje
szybkie i łatwe wdrożenie monitorowania NetFlow.
grudzień 07
Łukasz Witaszek
82
W rozległych środowiskach, gdzie ilość routerów jest znacząca, gromadzenie i
przesyłanie informacji poszczególnych przepływach obserwowanych na każdym urządzeniu prowadziłoby do gromadzenia zbyt dużej do przeanalizowania ilości danych. Ponadto
przesyłanie takiej ilości danych zużywałoby zasoby sieci. Stąd warto wybrać punkty znaczące dla obsługi naszej sieci ze względu na następujące kryteria:
• monitorowania dostępności ważnych usług
• wykrywania zagrożeń bezpieczeństwa
• rozliczania wykorzystania usług
Firma Cisco, która wykorzystuje w zarządzaniu własną siecią korporacyjną protokół NetFlow, analizuje za jego pomocą ruch pochodzący z około 1900 interfejsów do sieci
WAN, którymi jest połączona z globalną siecią. Dlatego też wartościowe może być przeanalizowanie wskazówek inżynierów sieciowych odpowiedzialnych za prawidłowe funkcjonowanie infrastruktury. Doświadczenie zdobyte w nadzorowaniu tak rozległej sieci zaowocowało powstaniem poniższej tabeli, przedstawiającej rozlokowanie i funkcjonalność
różnych elementów architektury NetFlow (29):
Lokalizacja w topologii sieci
Oprogramowanie
Cel monitorowania
analizujące
Bramy Internetowe połączone z
Arbor Networks Peak-
Analizowanie ruchu w rozbiciu na wyko-
łączami dostawców usług siecio-
flow Traffic
rzystywane aplikacje.
wych (ang. ISP)
Weryfikacja poprawności konfiguracji
flow DoS
protokołów routingu (np. BGP).
Wykrywanie anomalii.
Routery sieci wewnętrznej obsłu-
gujące publicznie dostępne zasoby
flow DoS
Wykrywanie anomalii.
firmy.
Routery szkieletowe
NetQoS Reporter Analy-
Analizowanie ruchu w rozbiciu na wyko-
zer
rzystywane aplikacje – planowanie rozwoju
sieci
Routery szkieletowe obsługujące
OSU flow-tools from
Zbieranie danych historycznych, wykorzy-
sieci dostępne publicznie
splintered.net
stywanych przy przewidywaniu trendów i
diagnostyce.
Bramy NAT (ang. Network Ad-
OSU flow-tools from
Audytowanie realizowania polityki adresa-
dress Translation Gateway)
splintered.net
cji oraz udostępniania usług.
Tabela 7.3 Lokalizacje sond i zadania monitorowania - sieć korporacji Cisco
grudzień 07
Łukasz Witaszek
83
7.2 Przykład wykorzystania NetFlow - ochrona przed atakiem
złośliwego oprogramowania
Aby potwierdzić praktyczną skuteczność protokołu NetFlow i narzędzi monitorujących firma Cisco opisuje kilka przykładów z obszaru własnej sieci. Jeden z nich dotyczy
wykorzystania monitorowania przepływów do zabezpieczenia się przed atakiem robaka o
nazwie SQL Slammer Worm. Robak pojawił się w Internecie w styczniu 2003 roku i charakteryzował się olbrzymią szybkością propagacji – zainfekował w ciągu 10 minut 90%
komputerów, które były na niego podatne (30). Obciążenie sieci spowodowane propagacją
wywołało swego rodzaju reakcję łańcuchową: robak rozsyłał się generując duże obciążenie
sieci niektóre routery przeciążone dużą ilością pakietów wyłączały się routery sąsiadujące aktualizowały tablice routingu (usuwały trasy prowadzące przez wyłączające się
routery) i przesyłały je do innych routerów generowały dodatkowe obciążenie część
administratorów zdecydowała się zrestartować urządzenia aby przywrócić im normalne
funkcjonowanie zainicjowana została kolejna operacja wymiany tablic routingu dodatkowa porcja obciążenia zwalania sieć. Co ciekawe, robak rozprzestrzeniał się za pomocą pakietu o rozmiarze 376 bajtów, co sprawiało, iż był przekazywany pomimo dużego
obciążenia.
Wiele organizacji przygotowało się na odparcie ataku blokując odpowiednio ruch
na bramach internetowych swoich organizacji, podczas gdy robak dotarł do wnętrza sieci
wykorzystując stacje mobilne przełączane pomiędzy różnymi (w tym niezabezpieczonymi)
sieciami oraz poprzez połączenia VPN – twierdzi Roland Dobbins, inżynier sieciowy w
firmie Cisco (29). Dzięki NetFlow osoby zarządzające siecią w korporacji mogły na bieżąco monitorować i wykrywać pojawiające się przepływy charakterystyczne dla robaka (duży objętościowo ruch wykorzystujący port nr 1434 protokołu UDP) i odpowiednio reagować. Szczególnie ważne w procesie odpierania ataku było wyśledzenie źródeł (szczególnie
stacji mobilnych i połączeń zdalnych), z których rozprzestrzeniał się robak, co z wykorzystaniem NetFlow (zaprojektowanego do śledzenia komunikacji) było szczególnie łatwe.
grudzień 07
Łukasz Witaszek
84
8 Monitorowanie z wykorzystaniem NetFlow
Praktyczne aspekty wykorzystania omawianej w tej pracy metody monitorowania
zostaną przedstawione na przykładzie monitorowania dwóch sieci, z czego jedna będzie
miała w czasie prowadzenia badań zmienioną topologię i zostanie rozbudowana o nowe
urządzenia.
8.1 Program analizujący przepływy
W każdym z badań, które zostaną opisane w kolejnych podrozdziałach wykorzystywany był ten sam program do analizy przepływów. Jest to jeden z produktów wymienionych w tabeli 7.1 (przedstawiające komercyjne aplikacje rekomendowane przez Cisco),
a mianowicie ManageEngine NetFlow Analyzer 6, stworzony przez firmę AdventNet, Inc.
ze Stanów Zjednoczonych. Firma ta zajmuje się od 1996 roku przygotowywaniem oprogramowania wspomagającego administratorów usług sieciowych. Dokładne informacje o
firmie i jej produktach można znaleźć na stronie Internetowej firmy: www.adventnet.com
Wybór tego programu do przeprowadzenia badań zdeterminowały takie czynniki
jak: łatwa i szybka implementacja, dystrybucja pracująca w systemie operacyjnym Windows XP oraz dostępna pełna wersja próbna programu, ograniczona czasowo do 30 dni.
Oto główne cechy charakterystyczne programu (31):
1. Program jest przeznaczony do realizowania ogólnych zasad monitorowania. Z tego
względu program nie jest skomplikowany w konfiguracji i może zostać szybko
uruchomiony w dowolnym środowisku. Program wykorzystuje szeroki zakres technologii monitorowania: NetFlow®, sFlow®, cflowd®, J-Flow®, IPFIX®, NetStream® and Cisco NBAR®.
2. Program jest stworzony do pracy w systemie operacyjnym Windows oraz Linux
RedHat i wymaga do pracy zainstalowanego środowiska Java. Ilość monitorowanych interfejsów wyznacza wersję programu, z której należy korzystać: poniżej 600
– wtedy odpowiednia jest wersja Professional (od $795), natomiast powyżej 600
rekomendowana jest wersja Enterprise (od $9995). W przypadku prezentowanego
eksperymentu została wykorzystana wersja Professional zainstalowana w darmowej, 30-dniowej wersji próbnej (trial), która ma pełną funkcjonalność wersji płatnej.
grudzień 07
Łukasz Witaszek
85
3. Program ma zintegrowany mechanizm kolektora oraz własną bazę danych, w której
przechowuje informacje przesyłane przez sondy. Interfejs realizowany jest poprzez
przeglądarkę internetową, która łączy się z serwerem WWW będącym częścią pakietu instalacyjnego. Wymagania sprzętowe programu przedstawia poniższa tabela:
Pamięć
operacyjna
Przestrzeń
dyskowa
2.6 GHz P-D/ 3.0 GHz P4 HT lub równoważny
512 MB
20 GB
11 – 25
2.8 GHz P-D lub równoważny
1 GB
40 GB
26 – 50
2.6 GHz Core 2 Duo lub równoważny
1 GB
60 GB
51 – 100
3.0 GHz Core 2 Duo / 2.4 GHz dual core
Xeon 3000 lub równoważny
2 GB
75 GB
101 – 300
2.6 GHz dual core 3000 Xeon lub równoważny
4 GB
225 GB
301 – 600
2.6 GHz quad core 3000 Xeon lub równoważny
4 GB
450 GB
Ilość interfejsów
Procesor
Poniżej 10
Tabela 8.1 Wymagania sprzętowe programu NetFlow Analyzer
4. Program ma zaimplementowane mechanizmy regularnego tworzenia i przesyłania
raportów jak również umożliwia definiowanie alarmów w oparciu o wartości wybranych parametrów, dzięki czemu administrator jest informowany na bieżąco o
wszystkich zmianach zachodzących w sieci. Szczegółowy opis funkcji programu
zostanie przedstawiony w kolejnych częściach pracy.
Dla potrzeb przeprowadzenia opisywanych badań program został zainstalowany na
komputerze klasy PC (laptopie) – Dell Inspiron 510m, wyposażonym w procesor Intel®
Celeron® M 1,49 MHz , 512 MB pamięci operacyjnej i 80 GB dysk twardy. Komputer
pracuje pod kontrolą systemu operacyjnego Windows XP Proffesional z Service Pack 2,
zainstalowane jest środowisko uruchomieniowe Java w wersji 1.4. Stacja była także wyposażona w kartę sieci bezprzewodowej zgodnej ze standardem 802.11b. Do obsługi interfejsu programu monitorującego wykorzystywana była przeglądarka Internet Explorer w wersjach 6 i 7 oraz Mozilla Firefox w wersji 2.0 (różnorodność przeglądarek wynika z faktu,
iż interfejs programu jest uruchomiony jako serwis WWW, dlatego też po odpowiednim
skonfigurowaniu można uzyskać do niego dostęp z innych komputerów, a nawet Internetu).
grudzień 07
Łukasz Witaszek
86
Po zalogowaniu do programu wyświetlone zostaje główne okno aplikacji:
4
1
3
2
Rysunek 8.1 Główne okno aplikacji NetFlow Analyzer
W głównym oknie wyróżniłem cztery obszary, które prezentują najważniejsze informacje i pozwalają na zmianę ustawień programu:
1. W tej części prezentowane są urządzenia (Device
Group),
które eksportują lub eks-
portowały przepływy do tego programu. Program daje możliwość grupowania
urządzeń, pozwalając np. odwzorowywać fizyczne rozmieszczenie routerów.
W tym samym miejscu prezentowane są również grupy adresowe (IP
Group),
za
pomocą których można przedstawić logiczną strukturę sieci.
2. Obszar konfiguracji, pozwalający na dokonywanie zmian w działaniu programu.
3. Widok główny – tu prezentowane są dane o stanie monitorowanych interfejsów z
ostatniej godziny. Pozwala to na bieżąco śledzić zmian parametrów pracy nadzorowanych elementów sieci. Dodatkowo korzystając z odnośników można szybko
poznać szczegółową charakterystykę wybranego obszaru.
4. Numer portu, na którym nasłuchuje proces kolektora zbierając informacje z sond –
informacja niezbędna przy konfigurowaniu procesów eksportujących.
Do zarządzania urządzeniami sieciowymi wykorzystywanymi w czasie badań zastosowano protokół telnet i program Putty.
grudzień 07
Łukasz Witaszek
87
8.2 Monitorowanie sieci domowej – topologia prosta
8.2.1 Opis topologii
Badania środowiska małej sieci (trzy stacje robocze i jedno urządzenie sieciowe)
zostało zrealizowane z wykorzystaniem następującej topologii:
Rysunek 8.2 Topologia prostej sieci domowej
Stacja zarządzania została opisana powyżej, pozostałe dwa komputery to stacje
przenośne z zainstalowanym systemem operacyjnym Windows XP Professional, z czego
stacja PC1 była wyposażona w kartę sieci bezprzewodowej zgodnej ze standardem
802.11g. Rolę urządzenia dostępowego pełnił router bezprzewodowy Linksys WRT54GL,
składający się z trzech modułów funkcjonalnych:
− Routera
− Punktu dostępowego sieci 802.11b/g
− Przełącznika sieciowego wyposażonego w cztery porty
Dodatkowo na routerze był uruchomiony serwer DHCP, przydzielający adresy z podsieci
192.168.1.0/29, przy czym router w sieci LAN miał adres 192.168.1.1. Komputery PC1
oraz PC2 miały adresację konfigurowaną dynamicznie przez serwer, natomiast stacja zarządzania miała ręcznie ustawione parametry IP (z adresem 192.168.1.4).
8.2.2 Konfiguracja routera Linksys WRT54GL
Na routerze dla potrzeb przeprowadzenia badania należało uruchomić sondę i proces eksportera NetFlow , co wiązało się z koniecznością zmiany oprogramowania sterującego pracą routera. Było to niezbędne, ponieważ system operacyjny dostarczany przez
producenta nie został wyposażony w funkcjonalność monitorowania z wykorzystaniem
NetFlow. Zdecydowałem się na wykorzystanie pakietu DD WRT (w wersji 23.) przygotoSamodzielny Zakład Sieci Komputerowych PŁ,
grudzień 07
Łukasz Witaszek
88
wywanego w ramach projektu o tej samej nazwie przez firmę NewMedia-NET GmbH.
Dodatkowe informacje dostępne są na stronach internetowych: www.dd-wrt.com oraz
www.dd-wrt.com/wiki (zawierającej dokumentację). Nie jest to jedyne rozwiązanie, ponieważ produkty firmy Linksys serii WRT są przedmiotem zainteresowania wielu programistów tworzących wolne oprogramowanie, przez co dostępny jest szeroki wybór alternatywnych systemów operacyjnych dla tych urządzeń (więcej informacji można odnaleźć na
stronach: http://openwrt.org/ - ang, oraz http://www.openlinksys.info/ - pl).
O wyborze DD WRT zdecydowała zawarta w tym pakiecie oprogramowania zintegrowana z procesem eksportującym sonda NetFlow – program rflow. Informacje o autorze
oraz opis konfiguracji i uruchamiania przedstawia informacja wbudowana w program:
Rysunek 8.3 Ekran pomocy dla programu rflow
Dostępne opcje konfiguracyjne nie umożliwiają stosowania wyrafinowanej konfiguracji (np. nie pozwalają określić szczegółów dotyczących monitorowania). Kolejnym
ograniczeniem programu jest obsługa jedynie NetFlow w wersji 5. Te ograniczenia wydają
się jednak uzasadnione możliwościami obliczeniowymi urządzenia, dla których program
został stworzony. Stosowanie skomplikowanych reguł filtrowania przepływów oraz ich
eksport w formie zdefiniowanej w standardzie NetFlow v9 mogłoby doprowadzić do obciążenia procesora w stopniu uniemożliwiającym routerowi realizowanie jego głównego
zadania, czyli przesyłania pakietów.
Aby poprawnie uruchomić sondę na urządzeniu konieczne jest ustalenie, które interfejsy mają być monitorowane. Bardzo istotna jest przy tym jedna istotna cecha NetFlow:
analizie podlega ruch przychodzący na interfejs, dlatego dla uzyskania pełnej wiedzy o
przepływach w sieci ważne jest aby uruchamiać monitorowanie na właściwych interfejsach. W przypadku, gdy router ma tylko dwa interfejsy (takie przykłady będą występowały
grudzień 07
Łukasz Witaszek
89
w kolejnych topologiach) uruchomiony zostaje monitoring na obu, co pozwala śledzić
przepływy w obu kierunkach. Jednakże w przypadku omawianego routera z wbudowanym
punktem dostępowym wybór właściwych punktów obserwacji nie jest trywialny. Można
oczywiście włączyć monitorowanie wszystkich interfejsów (w tym przypadku na: br0 –
interfejs mostkowy łączący w sobie połączenia bezprzewodowe i interfejsy przełącznika;
eth1 – reprezentującym połączenia bezprzewodowe; vlan1 – reprezentującym połączenie
WAN). Okazało się jednak, że monitorowanie interfejsu mostkowego br0 powodowało
niestabilną pracę urządzenia, odcinając całe środowisko od Internetu. W związku z tym
zdecydowałem się na monitorowanie interfejsu vlan1 (połączenie z Internetem) oraz interfejsu eth1 (połączenia bezprzewodowe). Aby uruchomić monitorowanie i eksport informacji z wykorzystaniem protokołu NetFlow należy wydać następujące polecenie:
~ # rflow -i vlan1 -i eth1 -F 192.168.1.3:9996 -A 600 -I 120
gdzie znaczenie poszczególnych parametrów jest następujące:
rflow -i vlan1 -i eth1 – uruchomienie program monitorującego i wskazanie in-
terfejsów, które mają być monitorowane
-F 192.168.1.3:9996 – wskazanie procesu kolektora (tu wskazanie na stację, na
której jest uruchomiony program NetFlow Analyzer) i portu, na którym nasłuchuje
(ustawienie tego parametru wyświetlane jest w głównym oknie programu i można
je zmienić w ustawieniach konfiguracyjnych:
Product Settings Server Settings Net-
Flow Listener Port).
-A 600 -I 120 – określenie czasów przeterminowania dla rekordów przepływu
przechowywanych w pamięci podręcznej procesu monitorującego: aktywne przepływy będą eksportowane co 10 minut (600s.), natomiast nieaktywne po 2 minutach (120 s.)
Uruchomienie monitorowania na wybranych interfejsach z wykorzystaniem opisanego polecenia przedstawia poniższa ilustracja:
Rysunek 8.4 Uruchomienie monitorowania – rflow
grudzień 07
Łukasz Witaszek
90
Od tego momentu rozpoczyna się eksport informacji o przepływach z wykorzystaniem protokołu NetFlow v5.
8.2.3 Prezentacja i analiza przepływów
W oparciu o materiał zebrany w czasie kilkudniowego monitorowania przepływów
pomiędzy siecią domową a Internetem zaprezentuję zastosowanie NetFlow jako narzędzia,
które pozwala prześledzić wykorzystanie dostępnego pasma przez aplikacje oraz poszczególne komputery. Przedstawienie wszystkich dostępnych w programie statystyk nie jest
możliwe ze względu na ich objętość, dlatego przedstawione zostaną tyko wybrane charakterystyki. Sposób wygenerowania określonej statystyki będzie opisany w formie ścieżki
poleceń prowadzącej od okna głównego programu NetFlow Analyzer (opisanego wcześniej w pracy). Pełna dokumentacja jest dostępna na załączonym nośniku oraz na stornie
internetowej producenta (http://www.adventnet.com/). Dane prezentowane w tym rozdziale zostały zgromadzone w okresie od 27.11.2007 do 01.12.2007. Jak wspomniałem wcześniej uruchomienie monitorowania na wszystkich interfejsach urządzenia nie było możliwe, dlatego też raporty z monitorowania na routerze firmy Linksys dotyczą tylko ruchu
wychodzącego.
Statystyka typu „Szybki podgląd” (ang. Quick View)
W oknie głównym programu prezentowane są statystki z okresu ostatniej godziny.
Aby w szybki sposób przejść do bardziej szczegółowego raportu dla danego interfejsu należy kliknąć ikonę „Quick View”
zlokalizowaną w ostatniej kolumnie wiersza repre-
zentującego port urządzenia. Zostanie uruchomione nowe okno, w którym zobaczymy
główną charakterystykę portu w określonym (w górnej części okna można ustawić zakres
czasowy prezentowanych danych) przedziale czasu. Dostępne są trzy perspektywy: objętości – volume, wykorzystania łącza – utilization oraz domyślna, przedstawiona poniżej
szybkości – speed:
grudzień 07
Łukasz Witaszek
91
Category
Max
Total
IN
1 min
Hourly
1 min
1.97 GB
2.09 Mbps
334.12 Kbps
0.00
0.00
0.00
0.00
0.00
OUT
Min
Hourly
Avg
95th Percentile
2.6 Kbps
45.14 Kbps
220.88 Kbps
0.00
0.00
-
Rysunek 8.5 Router Linksys - charakterystyka
charakterystyka Quick View #1: interfejs WAN
W tym samym oknie przestawione będą informacje o:
- dziesięciu najbardziej aktywnych aplikacjach
ApplicationI [1.97 GB]
ApplicationIN
Application
Traffic
Traffic Percentage
TCP_App
http
edonkey2000
UDP_App
Internet Radio (Winamp)
icmp
netbios-dgm
netbios-ns
dccm
domain
Others
1.05 GB
434.14 MB
138.13 MB
117.41 MB
102.59 MB
27.24 MB
23.69
69 MB
16.69 MB
12.93 MB
9.58 MB
28.45 MB
54%
22%
7%
6%
5%
1%
1%
1%
1%
<1%
1%
Tabela 8.2 Router Linksys - charakterystyka
harakterystyka Quick View #2: interfejs WAN
- dziesięciu
ciu najaktywniejszych źródłach ruchu
SourceIN [1.97 GB]
Source
Traffic
Traffic Percentage
172.16.19.226
331.87 MB
17%
83.204.103.129
67.18 MB
3%
213.251.136.138
61.16 MB
3%
213.113.1.198
57.88 MB
3%
217.195.203.52
54.53 MB
B
3%
140.116.110.5
53.12 MB
3%
172.16.6.1
47.6 MB
2%
213.251.129.27
39.54 MB
2%
213.251.139.82
32.99 MB
2%
200.161.78.31
29.64 MB
2%
Others
1.19 GB
61%
Tabela 8.3 Router Linksys - charakterystyka
harakterystyka Quick View #3:: interfejs WAN
grudzień 07
Łukasz Witaszek
92
- dziesięciu najaktywniejszych odbiorcach ruchu
DestinationIN [1.97 GB]
Destination
172.16.19.226
172.16.6.239
172.16.6.184
172.16.6.182
82.246.76.192
172.16.6.167
172.16.6.154
172.16.6.249
84.120.236.189
201.254.122.66
Others
Traffic
877.8 MB
319.21 MB
65.69 MB
31.2 MB
29.79 MB
24.71 MB
20.06 MB
19.84 MB
19.05 MB
18.98 MB
543.98 MB
Traffic Percentage
45%
16%
3%
2%
2%
1%
1%
1%
1%
1%
28%
Tabela 8.4 Router Linksys - charakterystyka Quick View #4: interfejs WAN
Program raportujący pozwala na wydruk każdego z wygenerowanych raportów oraz jego
konwersję dokumentu w formacie PDF.
grudzień 07
Łukasz Witaszek
93
Charakterystyki szczegółowe dla interfejsu WAN
Aby dokładnie przeanalizować wymianę
wymianę informacji realizowaną z wykorzystaniem
określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą
wybranego portu.
portu. Wtedy udostępnione zostaną szczegółowe raporty, informujące o:
• ruchu – traffic,, który można analizować w czterech perspektywach: objętości (vo(
lume),
), szybkości (speed
(speed),
), wykorzystania łącza (utilization
(utilization)) oraz liczby pakietów
(packets);
);
• aplikacjach – application,
applic
, który prezentuje udział poszczególnych aplikacji w genegen
rowaniu ruchu. Przypisywanie aplikacji jest realizowane z wykorzystaniem mapy
portów, którą można edytować w obszarze konfiguracji programu. Dla wybranego
przedziału czasu prezentuje się to następująco:
następująco:
Rysunek 8.6 Router Linksys - udział aplikacji w wykorzystaniu łacza WAN
• źródłach – source,, przedstawiający główne źródła pakietów;
pakietów
• odbiorcach – destination,
destination, wskazujący odbiorców danych;
danych
• konwersacjach
konwersacj
– conversation,
conversation, który dostarcza informacji o tym które pary hostów
najczęściej się komunikują. Ten raport jest źródłem wielu ciekawych informacji
ważnych dla kształtowania ruchu. Prezentuje informacje wg kryteriów źródła, odo
biorcy oraz wykorzystywanej aplikacji;
aplikacji
grudzień 07
Łukasz Witaszek
94
Rysunek 8.7 Router Linksys - aplikacje wykorzystywane w konwersacjach
Rysunek 8.8 Router Linksys - odbiorcy konwersacji
Rysunek 8.9 Router Linksys - źródła konwersacji
• dostępne są również raporty NBAR (opisanego w końcowym rozdziale pracy), jednakże można je uzyskać tylko wykorzystując urządzenia Cisco.
grudzień 07
Łukasz Witaszek
95
Zaplanowane raporty (Schedule Reports): program ma wbudowaną funkcjonalność,
która pozwala na stworzenie planu automatycznego generowania raportów i przekazywania ich za pomocą poczty elektronicznej do wskazanych odbiorców. Mechanizm ten pozwala na bieżąco śledzić stan sieci bez konieczności samodzielnego generowania raportów
z wykorzystaniem interfejsu programu. W czasie tworzenia raportu określane są kryteria
jego tworzenia: interfejsy, które mają być ujęte w raporcie; typ raportu; schemat generowania raportu (dzienny, tygodniowy, miesięczny, jednorazowy); adres e-mail gdzie ma
zostać przesłany raport. Warto w tym miejscu zwrócić uwagę, iż generowane raporty (format PDF) mają duży rozmiar – ok. 13 MB, co sprawia, iż wykorzystane do ich przesyłania
konta pocztowe muszą zezwalać na przesyłanie wiadomości o takim rozmiarze. Przykład
automatycznie wygenerowanego raportu znajduje się na załączonej do pracy płycie CD.
Alarmy (Alerts): jeszcze innym rodzajem dostępnych raportów są alarmy - przekazywane mailowo krótkie informacje o określonym zdarzeniu. Zdarzenia wyzwalające wygenerowanie raportu można w dowolny sposób definiować, nadając również różny priorytet poszczególnym zdarzeniom i generując odpowiednio ostrzeżenia, alarmy główne oraz
alarmy krytyczne. Przykład wiadomości alarmowej znajduje się na załączonej do pracy
płycie CD.
grudzień 07
Łukasz Witaszek
96
8.3 Monitorowanie sieci domowej – topologia rozbudowana
Topologia wykorzystywana w tym badaniu zostaje rozbudowana w porównaniu do
poprzedniej o nowe urządzenia sieciowe Cisco.
Badania środowiska rozbudowanej sieci (trzy stacje robocze i trzy urządzenia sieciowe) zostało zrealizowane z wykorzystaniem następującej topologii:
Tatrz_Cisco 2651
Catalyst 2960
Rysunek 8.10 Topologia rozbudowanej sieci domowej
Nowa topologia powstała poprzez włączenie do topologii przedstawionej wcześniej
dodatkowych urządzeń: przełącznika Cisco serii Catalyst 2960 oraz routera Cisco 2651.
Wykorzystując router stworzono dodatkową sieć (zaznaczoną na powyższym rysunku) i
dołączono ją do już istniejącej, przenosząc stacje PC1 i PC2 do nowej sieci. W ten sposób
jeden z interfejsów routera (adresie IP:192.168.1.2/29) znajduje się w sieci tworzącej starą
topologię, natomiast drugi (o adresie IP:192.168.2.1/29) jest domyślną bramą dla PC1 i
PC2. Komputery adresowane są dynamicznie przez serwer DHCP uruchomiony na routerze Cisco. Konfiguracja przełącznika to konfiguracja domyślna, a konfiguracja routera
Linksys jest taka sama (z jednym wyjątkiem – ponieważ zmienił się adres IP stacji zarządzania przepływy kierowane są na adres IP: 192.168.1.3) jak wykorzystywana w poprzednim badaniu.
8.3.2 Konfiguracja routera Cisco 2651
Celem zmiany (rozszerzenia) wykorzystywanej topologii było umieszczenie w niej
urządzenia Cisco, w którego system operacyjny (oznaczany w nomenklaturze sieciowej
grudzień 07
Łukasz Witaszek
97
jako IOS) wbudowane są funkcje monitorowania z wykorzystaniem NetFlow. Wykorzystałem urządzenie serii 2651, z zainstalowanym IOS w wersji 12.3(22). Niestety urządzenia z
tej serii odstają parametrami od obecnie wykorzystywanych, dlatego też wersja oprogramowania również nie jest najnowsza, niemniej jednak ma zaimplementowaną obsługę protokołu NetFlow w wersji 9. Szczegółowe informacje o urządzeniu przedstawione są poniżej:
Rysunek 8.11 Ekran informacyjny - router Cisco 2651
W odniesieniu do poprzedniej konfiguracji stacja nadzorująca ma inny adres IP:
192.168.1.3 (wcześniej 192.168.1.4), co musiało zostać uwzględnione przy parametryzacji
procesu eksportująceg. Router jest wyposażony w dwa porty FastEthernet, na których uruchomione zostaje monitorowanie, z analogicznie jak w poprzednim przypadku ustawionymi progami czasowymi: rekordy informujące o przepływach aktywnych będą przesyłane
co 10 minut, natomiast przepływy nieaktywne będą zgłaszane po 120 sekundach. Konfiguracja routera na potrzeby monitorowania została przeprowadzona zgodnie ze wskazówkami przygotowanymi przez firmę Cisco (30) i przebiegała dwuetapowo (wszystkie czynności konfiguracyjne były wykonywane w uprzywilejowanym trybie (ang. privileged EXEC)
pracy użytkownika urządzenia:
grudzień 07
Łukasz Witaszek
98
1. W pierwszym etapie głównym zadaniem było uruchomienie procesu gromadzenia
informacji o przepływach na urządzeniu
Rysunek 8.12 Uruchomienie monitorowania na Cisco 2651 #1
Następnie należało wskazać, które interfejsy mają podlegać monitorowaniu.
2. Kolejnym krokiem było uruchomienie procesu eksportującego z parametrami:
Ważne jest, aby pamiętać, że czasy przeterminowania pakietów aktywnych wyrażane są w minutach, natomiast nieaktywnych w sekundach.
Po wykonaniu powyższych kroków router rozpoczyna gromadzenie i przesyłanie
informacji o przepływach do wskazanej stacji zarządzania (IP: 192.168.1.3), na której uruchomiony jest proces kolektora nasłuchujący na porcie 9996.
W poprzednim badaniu, wykorzystującym topologię bez urządzenia firmy Cisco,
do prezentacji wyników obserwacji wykorzystałem domyślne szablony raportów. Aby szerzej ukazać możliwości, jakie daje wykorzystanie NetFlow w połączeniu z rozbudowaną
aplikacją stacji zarządzania, przedstawię analizę przepływów obserwowanych na routerze
Cisco 2651 w okresie do 01.12.2007 do 04.12.2007. Na urządzeniu uruchomiono monitorowanie na wszystkich (w tym przypadku na dwóch) interfejsach, stąd program NetFlow
Analyzer generuje zarówno statystykę ruchu przychodzącego jak i wychodzącego z danego
potu.
grudzień 07
Łukasz Witaszek
99
Analiza przypadku – specyficzne wykorzystanie łącza w pierwszych godzinach
monitorowania w dniu 01.12.2007
Gdy wybierzemy z okna głównego aplikacji link prowadzący do szczegółowych informacji o interfejsie IfIndex1 urządzenia Tatrz_Cisco 2651 (192.168.1.2) i zmienimy perspektywę raportu na informacje o objętości (volume) zaprezentowany zostanie
wykres:
Rysunek 8.15 Router Cisco 2651 - raport Traffic, perspektywa volume
To co zwraca uwagę na tym wykresie, to duża ilość informacji przesłana przez urządzenie
w ciągu pierwszych sześciu godzin monitorowania. Aby uzyskać dokładniejsze informacje
zmieniłem skalę osi czasu, ograniczając ją do okresu wzmożonego ruchu (godz. 20-01nd):
Rysunek 8.16 Router Cisco 2651 - raport Traffic, perspektywa volume [20:00-01:00 następnego
dnia]
Jak widać ruch w tym okresie czasu miał specyficzną charakterystykę, z wieloma regularnymi impulsami, krótkotrwałymi lecz przenoszącymi duże ilości danych (taki rozkład
przypomina złożenie wielu funkcji impulsowych, tzw. Delty Diraca).
Gdy zmienimy perspektywę na prezentującą liczbę przesyłanych pakietów:
grudzień 07
Łukasz Witaszek
100
Rysunek 8.17 Router Cisco 2651 - raport Traffic, perspektywa packets [20:00-01:00 następnego dnia]
zauważymy, że ilość wysyłanych pakietów jest zbliżona do ilość otrzymywanych, oraz co
ważniejsze – rozkład czasowy jest taki sam. Na tej podstawie można wysunąć tezę, iż obserwujemy ruch, w którym największy udział ma transmisja z wykorzystaniem protokołu
TCP, w którym mechanizm potwierdzania wymaga przesłania pakietu z właściwym numerem sekwencyjnym.
Ostateczną odpowiedź na pytanie jaki ruch był w tym czasie obserwowany uzyskamy z
raportu dotyczącego konwersacji – converstaion:
Rysunek 8.18 Router Cisco 2651 - raport Conversation, perspektywa application [20:00-01:00 następnego dnia]
Widzimy, że większość ruchu to komunikacja z wykorzystaniem protokołu http.
grudzień 07
Łukasz Witaszek
101
Aby sprawdzić, skąd pochodziło tak wiele danych skorzystamy z wykresu perspektywy
Skurce, zaznaczając wcześniej, aby adresy IP zostały zamienione na nazwy DNS:
Rysunek 8.19 Cisco 2651 - raport Conversation, perspektywa source [20:00-01:00 następnego
dnia]
Okazuje się, że głównym źródłem ruchu jest komputer ftp.citylink.co.nz, w którego zasobach znajdują się obrazy płyt instalacyjnych systemu operacyjnego Linux, który był w tym
czasie pobierany z sieci na jeden z komputerów sieci lokalnej.
Wnioski
Przedstawiony wyżej przykład opisuje, jak za pomocą kilku prostych operacji można, wykorzystując dane o przepływach, zweryfikować pozornie nienaturalną transmisję. Jej charakter wynikał z ograniczeń szerokości pasma dostępnego dla komunikacji, która regularnie przekraczała dopuszczalne dla danego łącza wartości, po czym była tłumiona i cykl
rozpoczynał się od nowa.
grudzień 07
Łukasz Witaszek
102
8.4 Monitorowanie sieci w korporacji
Ostatnie badanie zostało przeprowadzone z wykorzystaniem sieci produkcyjnej
jednego z departamentów BRE Banku S.A. w Łodzi. Ze względów na obowiązującą mnie
zasadę zachowania tajemnicy służbowej zmienione zostały adresacje prezentowane w dokumencie względem wykorzystywanych w rzeczywistości. Wykluczone zostały też z monitorowania wszystkie przepływy występujące pomiędzy adresami wewnętrznymi w banku. Badanie zostało wykonane w krótkim okresie czasu na tylko jednej podsieci, dlatego
też mimo umieszczenia w sieci kilkudziesięciu komputerów materiał zebrany do badań nie
jest zbyt obszerny. Konieczność utrzymania ciągłości pracy infrastruktury i możliwość jej
zakłócenia, uruchamianie dodatkowych procesów (np. uruchomienie monitorowania przepływów) sprawiły, że przeprowadzenie badań na szerszą skalę okazało się niemożliwe.
Topologię sieci w departamencie banku można przedstawić następująco:
Rysunek 8.20 Topologia sieci departamentu w BRE Banku
Topologia tej sieci to prosta sieć z routerem Cisco 2621XM, przełącznikiem Cisco
serii 2960 oraz liczbą około 25 komputerów (w sieci znajdowały się także laptopy, których
liczbę ze względu na mobilność pracowników trudno było dokładnie ustalić. Podobnie jak
w poprzednich przykładach na routerze został uruchomiony serwer DHCP przyznający
adresy (klasy C, z puli adresowej 192.168.10.10-255) stacjom roboczym z wykluczeniem
statycznie zaadresowanej stacji zarządzania (192.168.10.5) i samego routera (o adresie
IP:192.168.10.1).
grudzień 07
Łukasz Witaszek
103
8.4.2 Konfiguracja routera Cisco 2621XM
Podobnie jak w przypadku urządzenia Cisco 2651 konfiguracja NetFlow została
wykonana z wykorzystaniem poleceń IOS przy uwzględnieniu specyfiki badanego środowiska. W ustawieniach procesu eksportującego uwzględniono zmieniony adres IP stacji
zarządzania: 192.168.10.5.
Badanie w sieci korporacyjnej zostało przeprowadzone w dniu 02.12.2007, w godzinach od 8:00 do 14:00.
Analiza przypadku – duża ilość ruchu wychodzącego do Internetu
Podobnie jak w poprzednich przypadkach, rozpoczniemy analizowanie ruchu od
ogólnej charakterystyki portu WAN routera.
Rysunek 8.21 Cisco 2621 XM- raport Traffic, perspektywa volume [8:00-14:00]
Analizując ruch w tej sieci warto pamiętać o tym, iż jest to niewielka infrastruktura jednego z departamentów, którego głównym zadaniem jest analizowanie marketingu internetowego.
grudzień 07
Łukasz Witaszek
104
Dlatego też uwagę zwraca duża ilość ruchu wychodzącego (w godzinach od 9:15 do
10:33):
Rysunek 8.22 Cisco 2621 XM- raport Traffic, perspektywa volume [9:15-10:33]
Gdy zaczniemy analizować raport application dla ruchu wychodzącego, łatwo zauważymy
niepokojące (biorąc pod uwagę środowisko korporacyjne) zjawisko:
Rysunek 8.23 Cisco 2621 XM- raport Conversation, ruch wychodzący, perspektywa application
[9:15-10:33]
Widzimy, iż w ruchu wychodzącym do Internetu występują protokoły wykorzystywane
przez programy wykorzystywane do wymiany plików: gnutella oraz eDonkey. Znacząca
ilość nierozpoznanego ruchu – TCP_App, który reprezentuje wykorzystanie portów nie
przypisanych do aplikacji w mapie portów, pozwala przypuszczać, że również część tej
komunikacji służy do wymiany plików. Oczywiście samo wykorzystywanie aplikacji do
współdzielenia plików nie jest nielegalne, ale obowiązująca w środowisku korporacyjnym
polityka bezpieczeństwa zabrania uruchamiania tego typu programów. Dlatego też wskazane jest odszukanie komputera, na którym tego typu oprogramowanie jest uruchomione.
grudzień 07
Łukasz Witaszek
105
Wykorzystując raport Converstation i perspektywę source odpowiedź poznajemy natychmiast:
Rysunek 8.24 Cisco 2621 XM- raport Conversation, ruch wychodzący, perspektywa source
[9:15-10:33]
Wnioski
Podobnie jak w poprzednich przykładach program NetFlow Analyzer dowodzi swojej skuteczności jako narzędzie do szybkiej analizy bieżącej sytuacji w sieci. Korzystając z narzędzia monitorowania udało się wykryć lukę w zabezpieczeniach, która pozwala naruszać
politykę bezpieczeństwa firmy. Częściowym wytłumaczeniem może być fakt, iż departament zajmujący się marketingiem w Internecie często korzysta z różnego rodzaju materiałów promocyjnych, dostarczanych w najróżniejszej formie: prezentacji, filmów, audycji
Internetowych. Mogło to doprowadzić do rezygnacji z polityki „wszystko zablokowane,
odblokowanie na uzasadniony wniosek użytkownika”, gdyż liczba wniosków o odblokowanie była zbyt duża. Okazuje się jednak, że takie odstępstwa od ogólnie przyjętych zasad
mogą szybko doprowadzić do nadużyć i stwarzać zagrożenie dla bezpieczeństwa systemu.
grudzień 07
Łukasz Witaszek
106
8.5 Wnioski
Przedstawione badania, mimo iż przeprowadzone w bardzo małych sieciach komputerowych, pozwoliły zebrać wiele uwag i wskazówek dotyczących zastosowania protokołu NetFlow do realizowania zadań monitorowania sieci komputerowych. Aby w pełni
korzystać z dobrodziejstw tego rozwiązania koniecznie trzeba rozważyć kilka ważnych
aspektów implementacyjnych.
1. Wybór właściwego oprogramowania dla stacji zarządzania.
Jest to ważna kwestia, głównie ze względu na koszty oprogramowania komercyjnego, które liczone jest w dziesiątkach tysięcy dolarów. Właściwe określenie potrzeb oraz środowiska, w jakim oprogramowanie będzie wykorzystywane znacznie
ułatwi podjęcie trafnej decyzji.
Ciekawą propozycją, biorąc pod uwagę kryterium ceny i oferowanych możliwości,
jest wykorzystywany przeze mnie pakiet NetFlow Analyzer.
2. Właściwe rozmieszczenie punktów obserwacji.
Odpowiednie umieszczenie lokalizacji sond NetFlow jest ważne ze względu na to,
że nawet najdoskonalsze programy monitorujące, zasilane danymi o nieistotnych
przepływach, nie spełnią swojego zadania. Warto tu mieć na uwadze fakt, iż NetFlow monitoruje przepływy przychodzące (choć nie jest to już dogmatem – możliwość ustawienia w Cisco IOS raportowania typu egrees). Zadanie poprawnego
rozmieszczenia procesów monitorujących staje się trudniejsze wraz z rozrastaniem
się topologii, lecz czas poświęcony temu zagadnieniu zwróci się wielokrotnie np. w
sytuacji awarii.
3. Dostosowanie procesu eksportującego.
W przypadku niewielkich sieci sposób zbierania i przesyłania informacji o przepływach ustawiony z domyślnymi opcjami konfiguracji nie jest błędem. W przypadku dużej topologii, wykorzystującej szybkie łącza, nieodpowiednio ustawiony
proces eksportowy może doprowadzić do powstawania dodatkowego obciążenia
protokołem NetFlow. Dlatego warto rozważyć stosowanie agregacji i filtrowania w
procesie monitorowania. Pozwala to odciążyć zasoby urządzenia oraz zmniejszyć
zapotrzebowanie protokołu na pasmo. Zmniejsza to również ilość informacji, która
jest zbędna w określonych zadaniach monitorowania.
grudzień 07
Łukasz Witaszek
107
4. Odwzorowanie polityki bezpieczeństwa w ustawieniach programu monitorującego.
Możliwości klasyfikowania ruchu w oparciu o wykorzystywane aplikacje okazuje
się bardzo przydatne w szybkiej ocenie stanu pracy sieci. Równie użyteczna jest
możliwość identyfikacji urządzeń w sieci w oparciu o adresy IP. W celu uzyskania
prawidłowych informacji, konieczne jest wdrożenie w danej sieci polityki w zakresie adresacji oraz dostępnych usług. Na podstawie dokumentacji tego typu można
właściwie skonfigurować serwery DHCP tak, aby adresy mimo dynamicznego
przydzielania pozwalały na jednoznaczną identyfikację na poziomie jednostki organizacyjnej przedsiębiorstwa (np. przynależność komputera do określonego departamentu). Należy pamiętać, iż konieczne jest wprowadzenie tych ustaleń do konfiguracji programu monitorującego oraz uaktualnianie tych danych na bieżąco.
Podsumowując można stwierdzić, że NetFlow i współpracujące z nim narzędzia
programowe ułatwią administratorom sieci zarządzanie infrastrukturą w obliczu wymagań
stawianych przez nowoczesne aplikacje i usługi sieciowe. Jednak, jak każde inne narzędzie, wymaga konserwacji i dostosowywania do wykonywanych działań. Stawia też wymagania osobom, które się nim posługują, ponieważ tylko prawidłowa interpretacja przedstawianych parametrów czyni NetFlow użytecznym.
grudzień 07
Łukasz Witaszek
108
9 Dalszy rozwój metod monitorowania
Czy przedstawiona w poprzednich rozdziałach metoda monitorowania sieci to najnowsze z proponowanych rozwiązań? Czy stanowi pełne źródło informacji o sytuacji w
sieci, czy też wskazane są dodatkowe rozwiązania wspomagające?
9.1 sFlow
Wydaje się, że metoda polegająca na obserwowaniu przepływów była krokiem w
tym samym kierunku, w którym ewoluują sieci i aplikacje, które je wykorzystują. Okazuje
się jednak, że podobnie jak w wielu innych przypadkach rzeczywistość wyprzedza modele
teoretyczne i standardy przemysłowe. Rozwój technologiczny pozwala na zwiększenie
przepustowości (szybkości) sieci – dziś naturalne jest wykorzystywanie sieci gigabitowych
w infrastrukturze średniej wielkości przedsiębiorstwa. Ponadto zmniejszające się koszty
instalacji światłowodowej sprzyjają upowszechnianiu się sieci 10gigabitowych. Być może
w niedalekiej przyszłości media miedziane Cat-7 będzie można wykorzystać do transmisji
o szybkości 100 Gb/s (33). Niezaprzeczalnie będziemy świadkami szybkiego rozwoju sieci
o dużej przepustowości, co staje się kolejnym wyzwaniem dla systemów monitorowania.
Okazuje się, że NetFlow napotyka w przypadku obserwowania sieci w szczególnie obciążonych węzłów sieci na ograniczenia w szybkości wymiany i zapisywania informacji –
procesy eksportera i kolektora nie nadążają z przesyłaniem rekordów przepływów generowanych przez sondy.
Ten problem został dostrzeżony wcześniej niż powstała ostatnia wersja NetFlow,
bo już w 2001r. pojawił się protokół sFlow. Jeżeli chodzi o wyrafinowanie metody zbierania i przesyłania informacji, to jest to rozwiązanie archaiczne – proces sondy nie wykonuje
żadnych skomplikowanych obliczeń, nie są też wykorzystywane żadne metody pozwalające na dostosowanie przesyłanych informacji – przechwycone pakiety są po prostu przesyłane dalej, do procesu zajmującego się ich analizą i przechowywaniem wyników.
Główną zaletą tego rozwiązania jest przeprowadzanie próbkowania – jeden z N pakietów podlega analizie i przesłaniu do procesu kolektora. Względnie łatwo jest zbudować
mechanizm sprzętowy wspierający taką operację. Dzięki temu jest ona o wiele bardziej
wydajna niż analiza NetFlow (nawet przy wykorzystaniu implementowanego programowego próbkowania). Dodatkowymi zaletami są (34): przesyłanie pełnych pakietów – można na nich przeprowadzać dowolne obliczenia pozwalające określić bardzo dokładnie cha-
grudzień 07
Łukasz Witaszek
109
rakter przepływu (jak również monitorować różne protokoły warstwy sieciowej), niskie
koszty implementacji sondy, wysoka wydajność pozwalająca na zbieranie w jednym kolektorze danych z wielu procesów eksportujących.
Dodatkowe informacje znajdują się w opisie standardu RFC3176 oraz na stronie
www.sflow.org
grudzień 07
Łukasz Witaszek
110
9.2 Flexible NetFlow
Doświadczenia zdobyte przy tworzeniu i eksploatacji rozwiązań wykorzystujących
NetFlow pozwoliły dostosowywać produkt do nowych wymagań i warunków pracy. W
wyniku tych prac protokół NetFlow ewoluował by dać podstawy do stworzenia Flexible
NetFlow – określanego przez Cisco jako kolejną generację technologii przepływów (ang.
The Next Generation In Flow Technology) (28). Główne cechy charakterystyczne nowego
rozwiązania wg producenta to:
•
elastyczność, skalowalność i agregowanie przepływów w znacznie większym stopniu niż to było możliwe w zwykłym NetFlow;
•
możliwość monitorowania szerszego zakresu informacji o pakietach, co pozwala na
zbieranie dodatkowych danych o pracy sieci;
•
lepsze wsparcie dla wykrywania anomalii i zagrożeń bezpieczeństwa;
•
rozbudowany mechanizm identyfikowania przepływów i możliwość jeszcze precyzyjniejszego separowania istotnego dla administratora ruchu;
•
łączenie różnych technik rozliczania w jeden mechanizm (ang. accounting mechanism).
Architektura nowego rozwiązania pozwala na równoległe śledzenie wielu przepływów: administrator może konfigurować sondy do monitorowania tych samych przepływów lecz z uwzględnieniem różnych zastosowań, np. jeden dla analizy ruchu a kolejny dla
wykrywania zagrożeń. Dobrze ilustruje to poniższy rysunek, zaczerpnięty z dokumentacji
producenta (35):
grudzień 07
Łukasz Witaszek
111
Rysunek 9.1 Flexible NetFlow - wiele monitorów tego samego przepływu
Przez router przepływa strumień pakietów, które są analizowane i przypisywane do przepływów przez dwie sondy, z czego każda przy klasyfikacji kieruje się innym zbiorem parametrów. Dzięki temu można uniknąć przesyłania nadmiaru danych oraz zmniejszyć zapotrzebowanie na moc obliczeniową przy ich analizie.
Dodatkowe możliwości wykrywania nieprawidłowości oraz zagrożeń wypływają z
znacznie rozszerzonego sposobu określania zbioru informacji o przepływie, który można
zdefiniować w nowym protokole. Możliwe będzie śledzenie informacji na poziomach prawie wszystkich warstw modelu OSI – od warstwy łącza danych aż po warstwę aplikacji.
Poniższy rysunek przedstawia nową architekturę. Warto zwrócić uwagę na wprowadzenie zróżnicowanych typów informacji o przepływach (białe prostokąty na rysunku) –
typy te odpowiadają różnym zagadnieniom monitorowania, które można realizować za
pomocą Flexible NetFlow. Widzimy tu przepływy służące monitorowaniu: aplikacji (Application Flows), ruchu mulitkastowego (Multicast Flows), bezpieczeństwa (Security
Flows), ruchu IP (IP Flows), komunikacji peer to peer (Peering Flows).
grudzień 07
Łukasz Witaszek
112
Rysunek 9.2 Archtektura Flexible NetFlow
Szczegółowy opis nowej technologii wzbogacony przykładami zastosowań można
znaleźć na stronach internetowych producenta: www.cisco.com
grudzień 07
Łukasz Witaszek
113
9.3 Cisco NBAR – rozpoznawanie aplikacji
Zarówno NetFlow, Flexible NetFlow oraz wiele innych aplikacji zarządzania oferuje mechanizmy rozpoznawania aplikacji, które są uruchamiane w sieci. Jest to bardzo ważna informacja, pozwalająca administratorom dostosowywać infrastrukturę i planować jej
przyszły rozwój. Głównym (praktycznie jedynym) źródłem informacji o uruchomionych
aplikacjach jest analiza parametrów warstwy transportowej – numerów portów TCP lub
UDP wykorzystywanych do komunikacji. Wybrany ze zbioru parametrów pakietów numer
portu jest porównywany z listą portów i przypisanych im aplikacji, która jest zarządzana
przez wspomnianą już w niniejszym dokumencie organizację IANA. Lista ta jest podległa
wyłącznemu zarządzaniu organizacji w zakresie portów 0-1023, pozostałe porty mogą być
wykorzystywane przez twórców oprogramowania praktycznie dowolnie, należy jednak
pamiętać o zakresie tzw. portów zarejestrowanych (ang. Registered Ports): 1024-49151.
Fragment listy portów wygląda następująco:
Port Assignments:
Keyword
------[…]
ftp-data
#
ftp-data
#
#
#
ftp
ftp
#
ftp
#
#
#
ssh
ssh
#
ssh
#
#
#
telnet
telnet
Decimal
------0/tcp
0/udp
20/udp
20/sctp
21/tcp
21/udp
21/sctp
22/tcp
22/udp
22/sctp
23/tcp
23/udp
Description
----------Reserved
Reserved
References
----------
File Transfer [Default Data]
Jon Postel <postel&isi.edu>
FTP
IETF TSVWG
Randall Stewart <rrs&cisco.com>
[RFC4960]
File Transfer [Control]
File Transfer [Control]
Jon Postel <postel&isi.edu>
FTP
IETF TSVWG
[RFC4960]
SSH Remote Login Protocol
SSH Remote Login Protocol
Tatu Ylonen <ylo&cs.hut.fi>
SSH
IETF TSVWG
[RFC4960]
Telnet
Telnet
Tabela 9.1 IANA tabela portów
grudzień 07
Łukasz Witaszek
114
Okazuje się jednak, że nowe aplikacje wymykają się klasyfikacji. Do głównych obszarów, w których najczęściej spotykane są odstępstwa zaliczyć można programy wymieniające pliki (w systemie P2P) oraz komunikatory internetowe. Powodów, dla których
twórcy tych programów wyposażają je w funkcje umożliwiające wybór wykorzystywanego portu (w tym przede wszystkim z zakresu objętego wyłączną administracją IANA – 01023) jest kilka. W przypadku komunikatorów najczęściej stosuje się to do ominięcia zapór sieciowych, które skonfigurowane zgodnie z polityką bezpieczeństwa, blokują znane
porty programów komunikacyjnych. Programy wymieniające pliki napotykają więcej przeszkód. Z racji nagminnego ich wykorzystywania do pobierania treści chronionych prawem
autorskim są one blokowane nie tylko w sieciach korporacyjnych ale również przez dostawców Internetu. Dodatkowo niechęć providerów powodowana jest nieuporządkowanym
sposobem wykorzystania łącza – otwieranych jest wiele połączeń między różnymi komputerami, które często zawłaszczają całe dostępne pasmo. Wszystko to sprawia, że na drodze
tego typu ruchu sieciowego pojawia się wiele przeszkód. To z kolei prowadzi do podszywania się aplikacji pod inne usługi, które nie są blokowane (np. http, smtp i inne).
Takie praktyki utrudniają poprawną analizę wykorzystania łącza przez aplikacje –
zawyżają pomiary dla pewnych aplikacji i ukrywają istnienie innych. Aby usprawnić rozpoznawanie wykorzystywanych programów Cisco wprowadziło produkt Network-Based
Application Recognition (NBAR) (36) – Sieciowe Rozpoznawanie Aplikacji. Mechanizm
wykorzystywany w tym rozwiązaniu pozwala na rozpoznawanie wielu typów aplikacji, w
tym grupy aplikacji, które dynamicznie dokonują wyboru wykorzystywanych portów.
NBAR wykorzystuje mechanizmy analizy zawartości przesyłanych pakietów w warstwach
powyżej warstwy transportowej. Wyszukuje określonych wzorców, analizuje typy MIME
(dla aplikacji wykorzystujących protokół http), może też rozszerzać swoją konfigurację
przez dołączane pliki Packet Description Language Module (PDLM) – pliki Języka Opisu
Pakietów. Pliki są dostarczane przez firmę Cisco i są profilowane do wykrywania określonych typów aplikacji.
Dodatkowe informacje na temat tego rozwiązana można znaleźć na stronie producenta: www.cisco.com
grudzień 07
Łukasz Witaszek
115
10 Bibliografia
1. Wikipedia.org. System informatyczny. [Online]
http://pl.wikipedia.org/wiki/System_informatyczny.
2. —. Administrator (informatyka). [Online]
http://pl.wikipedia.org/wiki/Administrator_%28informatyka%29.
3. Stallings, Wiliam. Protokoły SNMP i RMON, vademecum profesjonalisty. Gliwice :
Helion, 2003.
4. Cisco Systems, Inc. Network Management System: Best Practices. [Document ID:
15114]
5. —. NetFlow Case Study. [Online]
http://www.cisco.com/application/pdf/en/us/guest/products/ps6601/c1042/cdccont
_0900aecd80311fc2.pdf.
6. Deri, Luca. Network Monitoring in Practice. [Online] 2007.
http://luca.ntop.org/Teaching/tm2007.pdf.
7. Wikipedia.org. Przepustowość. [Online]
http://pl.wikipedia.org/wiki/Przepustowo%C5%9B%C4%87.
8. IANA.org. PORT NUMBERS. [Online] http://www.iana.org/assignments/port-numbers.
9. IETF. A Simple Network Management Protocol (SNMP) - RFC1157. [Online]
http://www.faqs.org/rfcs/rfc1157.html.
10. DPS Telecom. SNMP Tutorial. [Online]
http://www.dpstele.com/layers/l2/snmp_l2_art_7_key.php.
11. Oetiker, Tobie. [Online] [Zacytowano: 2007 paodziernika 15.] www.mrtg.org.
12. Maciejewski, Grzegorz. [Online] http://r.ehion.com.
13. Wikipedia.org. RMON. [Online] http://pl.wikipedia.org/wiki/RMON.
14. Technical University of Lisbon. [Online]
https://ciist.ist.utl.pt/cacti/graph_view.php?action=tree&tree_id=4&leaf_id=25.
15. Hewlett-Packard Development Company, L.P. HP Network Management Center .
[Online]
https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&c
p=1-11-15-119_4000_100__.
grudzień 07
Łukasz Witaszek
116
16. Cisco Systems, Inc. Introduction to Cisco IOS® NetFlow. [Online]
http://www.cisco.com/en/US/products/ps6601/products_white_paper0900aecd804
06232.shtml.
17. Garvey, Martin J. InformationWeek. Going With The Flow. [Online] 28 listopad 2005.
http://www.informationweek.com/story/showArticle.jhtml?articleID=174401412.
18. Hickey, Andrew R. Tech Target ANZ. NetFlow network monitoring tools go with the
'flow'. [Online] 14 czerwiec 2007.
http://searchnetworking.techtarget.com.au/topics/article.asp?DocID=6100563.
19. Caligare s.r.o. What is Netflow? [Online]
http://netflow.caligare.com/netflow_format.htm.
20. Wikipedia.org. IETF. [Online] http://pl.wikipedia.org/wiki/IETF.
21. The Internet Engineering Task Force. IP Flow Information Export (ipfix). [Online]
czerwiec 2007. http://www.ietf.org/html.charters/ipfio-charter.html.
22. IETF IPFIX Workgroup. Requirements for IP Flow Information Export (IPFIX) - RFC 3917.
[Online] wrzesień 2004. http://www.ietf.org/rfc/rfc3917.tot.
23. Wikipedia.org. IP Flow Information Export. [Online]
http://en.wikipedia.org/wiki/IP_Flow_Information_Eoport.
24. The Internet Engineering Task Force. Cisco Systems NetFlow Services Export Eersion 9
(RFC3954). [Online] paodziernik 2004. http://www.ietf.org/rfc/rfc3954.tot.
25. Cisco Systems, Inc. Introduction to Cisco IOS NetFlow - A Technical Overview. [Online]
06232.shtml.
26. —. Cisco IOS Flexible NetFlow Technology White Paper. [Online]
be1cc.shtml.
27. —. Case Study - NetFlow gives network managers a detailed view of application flows
on the network.
28. Wikipedia.org. SQL Slammer. [Online]
http://en.wikipedia.org/wiki/SQL_slammer_(computer_worm).
29. AdventNet, Inc. ManageEngine ® NetFlow Analyzer. [Online]
http://manageengine.adventnet.com/products/netflow/indeo.html.
grudzień 07
Łukasz Witaszek
117
30. Cisco Systems, Inc. Configuring NetFlow to Capture and Export Network Traffic Data.
[Dokument PDF] 2005.
31. Chustecki, Janusz. NetWorld. Aktualności - Ethernet 100 Gb/s na okablowaniu UTP.
[Online] 16 listopad 2007. http://www.networld.pl/news/131125.html.
32. sFlow.org. Traffic Monitoring using sFlow®. [Online] 2003.
http://www.sflow.org/sFlowOverview.pdf.
33. Cisco Systems, Inc. Cisco IOS Flexible NetFlow Technology White Paper. [Online]
be1cc.shtml.
34. —. Network Based Application Recognition (NBAR). [Online]
http://www.cisco.com/en/US/products/ps6616/products_ios_protocol_group_home
.html.
35. —. Using NetFlow Filtering or Sampling to Select the Network Traffic to Track.
[Dokument PDF] 2005.
36. Wikipedia.org. RMON. [Online] http://en.wikipedia.org/wiki/RMON.
37. —. RMON. [Online] http://en.wikipedia.org/wiki/.
grudzień 07

Untitled

Transkrypt

Podobne dokumenty

R. Tomczak, Metody analizy ruchu sieciowego

cisco.netacad.net