Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

1

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Spis treści

WYKAZ SKRÓTÓW…………………………………………………………………………………………………………………………..4

WYKAZ RYSUNKÓW………………………………………………………………………………………………………………………..6

WYKAZ TABEL……………………………………………………………………………………………………………………………......8

1

WSTĘP ............................................................................................................................... 9

1.1

S

YSTEMY INFORMATYCZNE

......................................................................................................... 10

1.2

S

IEĆ KOMPUTEROWA

................................................................................................................ 10

1.3

M

ODEL ZARZĄDZANIA SIECIĄ KOMPUTEROWĄ

................................................................................ 11

2

CEL I ZAKRES PRACY ......................................................................................................... 14

3

MONITOROWANIE SIECI KOMPUTEROWYCH – ZAGADNIENIA PODSTAWOWE .................. 15

3.1

M

ETRYKI SIECIOWE

.................................................................................................................. 15

3.2

T

YPY MONITOROWANIA

............................................................................................................ 17

3.3

W

YMAGANIA STAWIANE SYSTEMOM MONITOROWANIA

.................................................................. 17

3.4

O

GRANICZENIA W MONITOROWANIU

........................................................................................... 18

4

TRADYCYJNE METODY ZARZĄDZANIA ............................................................................... 20

4.1

P

ROTOKÓŁ

SNMP ................................................................................................................... 20

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

P

ROTOKÓŁ

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

SNMP

I

RMON

–

MOŻLIWOŚCI I OGRANICZENIA

.......................................................................... 30

5

NOWOCZESNE METODY MONITOROWANIA – IDEA IPFIX ................................................. 32

5.1

„P

RZEPŁ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

N

ET

F

LOW

–

WSPÓLNE PODSTAWY

.............................................................................. 37

5.3.1

Pojęcia podstawowe .................................................................................................. 37

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

2

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

5.3.2

Architektura ............................................................................................................... 40

5.4

IPFIX

–

DALSZE ZAŁOŻENIA PROTOKOŁU

....................................................................................... 41

5.4.1

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

6

NETFLOW V.9 – CISCO IMPLEMENTUJE IPFIX .................................................................... 53

6.1

RFC3954

-

C

ISCO

S

YSTEMS

N

ET

F

LOW

S

ERVICES

E

XPORT

V

ERSION

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

P

RZYKŁAD

............................................................................................................................... 75

7

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

P

RZYKŁAD WYKORZYSTANIA

N

ET

F

LOW

-

OCHRONA PRZED ATAKIEM ZŁOŚLIWEGO OPROGRAMOWANIA

..... 83

8

MONITOROWANIE Z WYKORZYSTANIEM NETFLOW ......................................................... 84

8.1

P

ROGRAM ANALIZUJĄCY PRZEPŁYWY

............................................................................................ 84

8.2

M

ONITOROWANIE SIECI DOMOWEJ

–

TOPOLOGIA PROSTA

............................................................... 87

8.2.1

Opis topologii ............................................................................................................ 87

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

3

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

8.2.2

Konfiguracja routera Linksys WRT54GL .................................................................... 87

8.2.3

Prezentacja i analiza przepływów ............................................................................. 90

8.3

M

ONITOROWANIE SIECI DOMOWEJ

–

TOPOLOGIA ROZBUDOWANA

.................................................... 96

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

M

ONITOROWANIE 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

W

NIOSKI

.............................................................................................................................. 106

9

DALSZY ROZWÓJ METOD MONITOROWANIA ................................................................. 108

9.1

S

F

LOW

................................................................................................................................. 108

9.2

F

LEXIBLE

N

ET

F

LOW

................................................................................................................ 110

9.3

C

ISCO

NBAR

–

ROZPOZNAWANIE APLIKACJI

................................................................................ 113

10

BIBLIOGRAFIA ................................................................................................................ 115

Dodatek A - zawartość nośnika CD-ROM dołączonego do pracy

Dodatek B - raport z systemu Plagiat.pl

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

4

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

5

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

VLAN

Virtual LAN

VPN

Virtual private network

WAN

Wide area network

WWW

World Wide Web

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

6

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Wykaz rysunków

R

YSUNEK

3.1

W

YKORZYSTANIE ŁĄCZA W PROTOKOLE

E

THERNET

................................................................................... 16

R

YSUNEK

3.2

W

YKORZYSTANIE ŁĄCZA

-

Z DEFINICJI

..................................................................................................... 16

R

YSUNEK

4.1

S

CHEMAT DZIAŁANIA

SNMP

(3) .......................................................................................................... 22

R

YSUNEK

4.2

MRTG

-

P

RZYKŁAD STATYSTYK

(10) ...................................................................................................... 23

R

YSUNEK

4.3

RMON

–

PRZYKŁAD STATYSTYK

............................................................................................................ 29

R

YSUNEK

5.1

P

ORÓWNANIE

5.

I

9.

WERSJI

N

ET

F

LOW

................................................................................................. 36

R

YSUNEK

5.2

A

LGORYTM PROCESU KLASYFIKOWANIA

(24) ........................................................................................... 38

R

YSUNEK

5.3

A

RCHITEKTURA

IPFIX ......................................................................................................................... 40

R

YSUNEK

5.4

R

OZMIESZCZENIE ELEMENTÓW

IPFIX

W ARCHITEKTURZE SPRZĘTOWEJ

(24) .................................................. 50

R

YSUNEK

6.1

P

ROCES ANALIZOWANIA PAKIETÓW

....................................................................................................... 55

R

YSUNEK

6.2

T

WORZENIE REKORDU PRZEPŁYWU

#1 ................................................................................................... 57

R

YSUNEK

6.3

T

WORZENIE REKORDU PRZEPŁYWU

#2 ................................................................................................... 57

R

YSUNEK

6.4

T

WORZENIE REKORDU PRZEPŁYWU

#3 ................................................................................................... 57

R

YSUNEK

6.5

T

WORZENIE I EKSPORT REKORDÓW PRZEPŁYWÓW

.................................................................................... 60

R

YSUNEK

6.6

P

AKIET EKSPORTOWY

(26) .................................................................................................................. 60

R

YSUNEK

6.7

N

AGŁÓWEK PAKIETU EKSPORTOWEGO

(26) ............................................................................................ 61

R

YSUNEK

6.8

F

ORMAT ZBIORU REKORDÓW WZORCA

(26) ............................................................................................ 62

R

YSUNEK

6.9

F

ORMAT ZBIORU REKORDÓW DANYCH PRZEPŁYWÓW

(26) ......................................................................... 63

R

YSUNEK

6.10

F

ORMAT WZORCA ZBIORU REKORDÓW OPCJI

(26) .................................................................................. 64

R

YSUNEK

6.11

F

ORMAT ZBIORU REKORDÓW OPCJI

(26) .............................................................................................. 66

R

YSUNEK

6.12

P

RZYKŁAD ZBIORU REKORDÓW WZORCA

(26) ........................................................................................ 75

R

YSUNEK

7.1

P

ODZIAŁ ARCHITEKTURY

N

ET

F

LOW

(30) ................................................................................................ 77

R

YSUNEK

7.2

K

OMPONENTY STACJI ZARZĄDZANIA

N

ET

F

LOW

........................................................................................ 78

R

YSUNEK

8.1

G

ŁÓWNE OKNO APLIKACJI

N

ET

F

LOW

A

NALYZER

....................................................................................... 86

R

YSUNEK

8.2

T

OPOLOGIA PROSTEJ SIECI DOMOWEJ

.................................................................................................... 87

R

YSUNEK

8.3

E

KRAN POMOCY DLA PROGRAMU RFLOW

................................................................................................ 88

R

YSUNEK

8.4

U

RUCHOMIENIE MONITOROWANIA

–

RFLOW

.......................................................................................... 89

R

YSUNEK

8.5

R

OUTER

L

INKSYS

-

CHARAKTERYSTYKA

Q

UICK

V

IEW

#1:

INTERFEJS

WAN ..................................................... 91

R

YSUNEK

8.6

R

OUTER

L

INKSYS

-

UDZIAŁ APLIKACJI W WYKORZYSTANIU ŁACZA

WAN ......................................................... 93

R

YSUNEK

8.7

R

OUTER

L

INKSYS

-

APLIKACJE WYKORZYSTYWANE W KONWERSACJACH

......................................................... 94

R

YSUNEK

8.8

R

OUTER

L

INKSYS

-

ODBIORCY KONWERSACJI

............................................................................................ 94

R

YSUNEK

8.9

R

OUTER

L

INKSYS

-

ŹRÓDŁA KONWERSACJI

............................................................................................... 94

R

YSUNEK

8.10

T

OPOLOGIA ROZBUDOWANEJ SIECI DOMOWEJ

....................................................................................... 96

R

YSUNEK

8.11

E

KRAN INFORMACYJNY

-

ROUTER

C

ISCO

2651 ...................................................................................... 97

R

YSUNEK

8.12

U

RUCHOMIENIE MONITOROWANIA NA

C

ISCO

2651

#1 .......................................................................... 98

R

YSUNEK

8.13

U

RUCHOMIENIE MONITOROWANIA NA

C

ISCO

2651

#2 .......................................................................... 98

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

7

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

R

YSUNEK

8.14

U

RUCHOMIENIE MONITOROWANIA NA

C

ISCO

2651

#3 .......................................................................... 98

R

YSUNEK

8.15

R

OUTER

C

ISCO

2651

-

RAPORT

T

RAFFIC

,

PERSPEKTYWA VOLUME

............................................................. 99

R

YSUNEK

8.16

R

OUTER

C

ISCO

2651

-

RAPORT

T

RAFFIC

,

PERSPEKTYWA VOLUME

[20:00-01:00

NASTĘPNEGO DNIA

] ............. 99

R

YSUNEK

8.17

R

OUTER

C

ISCO

2651

-

RAPORT

T

RAFFIC

,

PERSPEKTYWA PACKETS

[20:00-01:00

NASTĘPNEGO DNIA

] ........... 100

R

YSUNEK

8.18

R

OUTER

C

ISCO

2651

-

RAPORT

C

ONVERSATION

,

PERSPEKTYWA APPLICATION

[20:00-01:00

NASTĘPNEGO DNIA

]

............................................................................................................................................................. 100

R

YSUNEK

8.19

C

ISCO

2651

-

RAPORT

C

ONVERSATION

,

PERSPEKTYWA SOURCE

[20:00-01:00

NASTĘPNEGO DNIA

] ............. 101

R

YSUNEK

8.20

T

OPOLOGIA SIECI DEPARTAMENTU W

BRE

B

ANKU

............................................................................... 102

R

YSUNEK

8.21

C

ISCO

2621

XM-

RAPORT

T

RAFFIC

,

PERSPEKTYWA VOLUME

[8:00-14:00] ............................................ 103

R

YSUNEK

8.22

C

ISCO

2621

XM-

RAPORT

T

RAFFIC

,

PERSPEKTYWA VOLUME

[9:15-10:33] ............................................ 104

R

YSUNEK

8.23

C

ISCO

2621

XM-

RAPORT

C

ONVERSATION

,

RUCH WYCHODZĄCY

,

PERSPEKTYWA APPLICATION

[9:15-10:33] 104

R

YSUNEK

8.24

C

ISCO

2621

XM-

RAPORT

C

ONVERSATION

,

RUCH WYCHODZĄCY

,

PERSPEKTYWA SOURCE

[9:15-10:33] ....... 105

R

YSUNEK

9.1

F

LEXIBLE

N

ET

F

LOW

-

WIELE MONITORÓW TEGO SAMEGO PRZEPŁYWU

....................................................... 111

R

YSUNEK

9.2

A

RCHTEKTURA

F

LEXIBLE

N

ET

F

LOW

..................................................................................................... 112

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

8

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Wykaz tabel

T

ABELA

6.1

Z

ALEŻNOŚCI POJĘĆ

N

ET

F

LOW

(26) .......................................................................................................... 54

T

ABELA

6.2

T

ABELA TYPÓW PÓL

(26) ....................................................................................................................... 73

T

ABELA

6.3

P

RZYKŁADOWE PRZEPŁYWY

(26) ............................................................................................................. 75

T

ABELA

6.4

P

RZYKŁADOWY ZBIÓR REKORDÓW DANYCH PRZEPŁYWÓW

(26) ..................................................................... 76

T

ABELA

7.1

K

OMERCYJNE OPROGRAMOWANIE STACJI ZARZĄDZANIA

(16) ....................................................................... 80

T

ABELA

7.2

B

EZPŁATNE OPROGRAMOWANIE STACJI ZARZĄDZANIA

(16) .......................................................................... 81

T

ABELA

7.3

L

OKALIZACJE SOND I ZADANIA MONITOROWANIA

-

SIEĆ KORPORACJI

C

ISCO

...................................................... 82

T

ABELA

8.1

W

YMAGANIA SPRZĘTOWE PROGRAMU

N

ET

F

LOW

A

NALYZER

........................................................................ 85

T

ABELA

8.2

R

OUTER

L

INKSYS

-

CHARAKTERYSTYKA

Q

UICK

V

IEW

#2:

INTERFEJS

WAN ....................................................... 91

T

ABELA

8.3

R

OUTER

L

INKSYS

-

CHARAKTERYSTYKA

Q

UICK

V

IEW

#3:

INTERFEJS

WAN ....................................................... 91

T

ABELA

8.4

R

OUTER

L

INKSYS

-

CHARAKTERYSTYKA

Q

UICK

V

IEW

#4:

INTERFEJS

WAN ....................................................... 92

T

ABELA

9.1

IANA

TABELA PORTÓW

....................................................................................................................... 113

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

9

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 kom-

puteró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ś natural-

nym. 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 wykorzy-

stywania 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 „kompute-

ry”, dla użytkowników (osób korzystających z owych komputerów) jest to „system kom-

puterowy” a dla specjalistów z dziedziny informatyki są to elementy infrastruktury, składa-

ją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 serwe-

rów oraz sieci komputerowej pozwalającej na komunikację pomiędzy wszystkimi elemen-

tami 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 poten-

cjale systemu świadczy możliwość wymiany informacji. Samodzielne stanowiska kompu-

terowe z zainstalowanymi aplikacjami posiadają możliwość przetwarzania informacji

zgromadzonych lokalnie, co w praktyce ma niewielki obszar zastosowań. Dopiero wymia-

na (dodajmy – bardzo szybka) tych informacji pomiędzy wieloma stanowiskami i użyt-

kownikami danego systemu sprawia, iż istnienie systemu ma sens i ułatwia pracę.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

10

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

1.1 Systemy informatyczne

Wymienione wcześniej we wstępie pojęcie system informatyczny wymaga doprecy-

zowania, 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 oprogramo-

waniu i urządzeniach peryferyjnych. Bardzo niewiele osób jest świadomych istnienia in-

frastruktury sieciowej a tym bardziej jej znaczenia dla poprawnego funkcjonowania syste-

mu 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 ope-

racyjnych 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 spaja-

ją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 margi-

nesu 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

11

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Jak widzimy przygotowanie sprawnej infrastruktury sieciowej nie jest prostą spra-

wą. Wydaje się jednak, że rzeczą bardziej złożoną, ale równocześnie niezbędną do jej pra-

widł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 zada-

niem administratorów. „Administrator (potocznie admin) - informatyk zajmujący się za-

rzą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 śro-

dowisko 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ęcio-

elementowego modelu systemu zarządzania siecią komputerową. W oparciu o niego two-

rzone 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 naprawia-

nie wykrytych problemów. Ze względu na poważne konsekwencje awarii sieci dla

funkcjonowania całości systemu ten element modelu jest najczęściej implemento-

wanym 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 or-

ganizacjach system informatyczny jest narzędziem, przy pomocy którego genero-

wane są zyski przez działy spoza obszaru informatyki – informatyka jest działem

pomocniczym, nie tworzy przychodu dla firmy. Managerowie w takich organiza-

cjach często chcą rozliczenia kosztów, które powstają w obszarze informatyki, naj-

częś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 wykorzysta-

nia 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

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

12

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

przedstawić zestawienie wykorzystania sieci przez różne departamenty w organiza-

cji;

• 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 obec-

nej 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 kompu-

terowych, dostosowanych do transmisji danych bez konieczności spełnienia wymo-

gu przesyłu w czasie rzeczywistym. Właściwie realizowane zarządzanie wydajno-

ścią pozwala na łatwe przygotowanie planów rozwoju sieci: obserwując wykorzy-

stanie 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 sie-

ciowych): bieżący monitoring sieci pozwala w łatwy sposób wychwytywać anoma-

lie i zjawiska, które mogą świadczyć o potencjalnym zagrożeniu złośliwym opro-

gramowaniem 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

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

13

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

przedstawiane przeze mnie technologie i standardy są opisywane głównie z perspektywy

realizacji zadań monitorowania (choć omawiane technologie posiadają również inne funk-

cjonalności).

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

14

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

2 Cel i zakres pracy

Niniejsza praca ma na celu przedstawienie zagadnień zarządzania siecią kompute-

rową, 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 pro-

tokołu NetFlow w zastosowaniach praktycznych. Przedstawione zostaną zagadnienia po-

przedzające implementację: wybór oprogramowania zarządzającego oraz umiejscowienie

elementów architektury tego protokołu. Praktyczne wykorzystanie NetFlow zostanie opi-

sane na przykładzie trzech sieci, w których zostanie wdrożone monitorowanie i przepro-

wadzone zostaną analizy wyników prowadzonych obserwacji. Zwieńczeniem przeprowa-

dzonych badań są wnioski podsumowujące możliwości jakie daje zastosowanie tej techno-

logii w monitorowaniu.

Ostatni rozdział omawia kierunki, w których ewoluuje NetFlow i inne metody ana-

lizowania przepływów. Przedstawione też będzie krótko rozwiązanie rozpoznawania apli-

kacji sieciowych – Cisco NBAR. Prawidłowa identyfikacja aplikacji sieciowych leży u

podstaw skutecznego monitorowania współczesnych sieci, dlatego w niniejszej pracy zo-

stanie przedstawiona również ta technologia.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

15

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

3 Monitorowanie sieci komputerowych – zagad-

nienia podstawowe

Zarządzanie siecią jest w znacznej mierze oparte na monitorowaniu jej pracy zgod-

nie z zaprezentowanym wyżej modelem. Monitorowanie, inaczej mierzenie i analiza wyni-

ków tychże pomiarów, wymaga określenia metryk, które pozwolą na dokonywanie porów-

nań 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 pa-

rametru w przypadku aplikacji sieciowych jest opóźnienie w przesyłaniu pakietów

przez sieć, które wynika z ograniczeń danego medium transmisyjnego oraz ko-

nieczności analizy danych zawartych w pakietach przez kolejne elementy sieciowe

(szczególnie istotne w przypadku sieci przełączanych). Pożądane jest minimalizo-

wanie czasu odpowiedzi systemu, co ma szczególne znaczenie w przypadku aplika-

cji interaktywnych.

3. Dokładność (ang. Accuracy) [-] – parametr określający jakość komunikacji na pod-

stawie ilości błędów transmisji. O dokładność transmisji dbają (w większości przy-

padków) protokoły łącza danych oraz protokoły transportowe, uwalniając użyt-

kownika od konieczności wnikliwego analizowania tego obszaru.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

16

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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. Through-

put)[b/s] – wskaźnik charakteryzujący dostępne łącze pod względem jego wykorzy-

stania przez daną aplikację (np. ilość możliwych do przesłania pakietów, zestawio-

nych 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 wy-

musza oczekiwanie innych na możliwość przeprowadzenia transmisji (system wy-

krywania kolizji). Poniższy rysunek przedstawia wykorzystanie przepustowości łą-

cza (bandwidth = 10 MB/s) w czasie wyrażanym w mikrosekundach:

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:

Rysunek 3.2 Wykorzystanie łącza - z definicji

0

10

20

1

3

5

7

9

11 13 15 17 19 21 23 25 27 29 31 33 35 37 39

transmisja[kb/s]

0

50

100

1

3

5

7

9

11 13 15 17 19 21 23 25 27 29 31 33 35 37 39

wykorzystanie [%]

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

17

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 spo-

sobó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 trace-

route – 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 monitoro-

wania przesyłają dane z wykorzystaniem łącza, które monitorują (np. SNMP). W przypad-

ku metody offline wyniki pomiarów przekazywane są za pomocą innych (często dedyko-

wanych 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. Ko-

nieczne 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 ta-

kich parametrów środowiska sieciowego, które pozwala na jego kontrolę z właściwej per-

spektywy. 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-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

18

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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żyt-

kownika 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ń sie-

ciowych, sprawności łącz, zasilania, stanu łącz zapasowych itd. Widzimy więc, że użyt-

kownicy 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 jed-

nostką 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 za-

groż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 za-

potrzebowania 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ęd-

nym względem poprawnego przesyłania danych. Powoduje do konieczność ograni-

czania monitoringu do kilku wybranych protokołów, monitorowania zagregowane-

go (np. na każdy port urządzenia), ogranicza możliwość monitorowania tylko do

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

19

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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ć (lokaliza-

cje 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 (pod-

czas 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 in-

formatycznym 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 oczekiwania-

mi). W dalszych rozdziałach niniejszej pracy przedstawione zostaną różne techniki moni-

torowania ze szczególnym uwzględnieniem rozwiązań opartych o protokół NetFlow i na-

rzędzia z nim związane.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

20

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 obserwu-

jemy dynamiczny rozwój rozwiązań sieciowych, pozwalających na spełnianie coraz więk-

szych 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 monito-

rowanie 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 Pro-

tocol, 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 sie-

cią – 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 bez-

pieczeństwa.

Gdy mówimy o SNMP należy pamiętać, że mamy na myśli nie tylko protokół wymia-

ny 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

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

21

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

SNMP do nadzoru nie tylko sieciowej charakterystyki pracy urządzeń (np. parametry dru-

karki lub stan procesora stacji roboczej).

Protokół SNMP jest protokołem warstwy aplikacji modelu OSI, typowo wykorzy-

stuje 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; snmp-

tcp-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 Ma-

nagement 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ądza-

nia (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 oblicze-

niowej 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 za-

rzą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 czaso-

wych 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 komu-

nikacji 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 (zde-

finiowanej w czasie konfiguracji agenta) sytuacji wysłaniem komunikatu do stacji zarzą-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

22

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 infra-

struktury stosuje się komunikację sterowaną pułapkami (ang. TDP – Trap-Directed Po-

oling (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ą odwzorowy-

wane w stacji zarządzającej po otrzymaniu informacji od agenta, iż doszło do jakiejś zmia-

ny 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

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

23

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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ą agen-

tów SNMP, dzięki czemu możliwe staje się monitorowanie olbrzymiej ilości parametrów

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

24

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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łno-

mocnika (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 infor-

macji 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 mo-

mencie 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 wy-

generowanie 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 cza-

sie 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 ele-

mentów systemu informatycznego, wykraczając daleko poza obszar infrastruktury siecio-

wej. 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 ru-

chu sieciowego (poza jego ogólną intensywnością), przez co nie spełnia wymagań stawia-

nych 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 od-

róż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ół:

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

25

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

• „RMON – Remote MONitor. - standard ten został zaprojektowany nie jako konku-

rencja, ale jako uzupełnienie SNMP”

(13)

;

• W skrócie, RMON jest stworzony do monitorowania opartego o “przepływy”, na-

tomiast SNMP jest często wykorzystywane do “sprzętowego” zarządzania (13).

Powstanie i rozwój protokołu RMON to wynik wielokierunkowej ewolucji proto-

koł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 wy-

korzystywaną w zdalnym monitoringu. Dokument RFC 1757 (ang. Remote Network Moni-

toring Management Information Base) definiuje bazę MIB zdalnego monitorowania. Ko-

lejny standard RFC 2021 (ang. Remote Network Monitoring Management Information Ba-

se Version 2 using SMIv2) rozszerza zdefiniowaną w poprzednim standardzie bazę infor-

macji zarządzania MIB. Istnieje jeszcze norma RFC 2074 (ang. Remote Network Monito-

ring 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

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

26

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

umieszczany w każdym węźle sieci – najczęściej implementuje się jedną instancję nadzor-

cy 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 cha-

rakterystycznych 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 powi-

nien na bieżąco nadzorować podległy obszar i zachować informacje do czasu uzy-

skania 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 na-

turalnego 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 po-

tencjalnych 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 dodatkowe-

go obciążenia sieci własnymi pakietami testowymi, dlatego też mowa o braku od-

pytywania.

Nadzorcy sieci mogą również wykonywać pewne analizy danych przez nich zbie-

ranych, 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ę-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

27

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 gru-

py 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 (wykorzy-

stanie, 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 sie-

ci (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 cha-

rakterystyki tychże połączeń.

6. Token Ring: rozszerzenie protokołu SNMP o funkcje monitorujące niskiego po-

ziomu specyficzne dla protokołu Token Ring.

7. Alarm: grupa definiująca wartości progowe parametrów charakteryzujących wy-

dajność 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 ru-

chu 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 pa-

kietó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 pro-

tokoł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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

28

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

4.2.3 RMON2

Protokół RMON był znaczącym krokiem w kierunku stworzenia uniwersalnego na-

rzędzia służącego monitorowaniu sieci komputerowych. Wykorzystując dobrze opracowa-

ny i szeroko implementowany protokół SNMP oraz wprowadzoną wraz z tym protokołem

architekturę twórcy nowego rozwiązania mogli skoncentrować się na rozwoju funkcjonal-

noś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ł ograniczo-

ny 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 specy-

fikację 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 nadzor-

cę.

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 da-

nych (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 nad-

zorcę 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 admi-

nistratora 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-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

29

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

korzystaniem nowego oprogramowania zainstalowanego na stacji nadzorczej możliwe sta-

ło się wizualizowanie ruchu w analizowanym segmencie sieci z wyróżnieniem wykorzy-

stywanych 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 wy-

korzystywanych produktów jest HP OpenView Network Node Manager (NNM), dostarcza-

ny przez firmę Hewlett-Packard. Jest to jeden z kilku produktów uławiających zarządzanie

sieciami komputerowymi dostarczanych przez tego producenta. Lista dodatkowego opro-

gramowania oraz jego szczegółowy opis znajduje się na stronie producenta (17).

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

30

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 po-

czątkowym okresie realizowano kilka równoległych rozwiązań, lecz za przyczyną względ-

nej 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śred-

nictwem 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 nad-

zorem sieci komputerowej. Zaproponowane rozwiązanie – protokół RMON, umożliwiają-

cy zdalny nadzór sieci komputerowych – jest rozszerzeniem SNMP o nowe funkcje zebra-

ne 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 przy-

kł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 zawar-

te w nagłówkach protokołów warstwy Sieci i warstwy Transportowej. Dzięki temu możli-

we stało się charakteryzowanie ruchu z uwzględnieniem wykorzystywanych aplikacji sie-

ciowych 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 aplika-

cje 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ą sta-

wia przed tą ostatnią duże wymagania obliczeniowe. Rozszerzenie protokołu projektowa-

nego 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 ob-

liczeniowej 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-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

31

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

wych rozwiązań, z czego wiele opiera się na pojęciu przepływu (ang. flows). Kolejny roz-

dział zostanie poświęcony najpopularniejszemu (między innymi ze względu na współtwo-

rzenie 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

32

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 poprzed-

nich 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ć rozsze-

rzają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 środo-

wisku 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 mo-

delują. 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 dotychcza-

sowo wykorzystywane metody analizy ruchu sieciowego nie sprawdzają się przy wykry-

waniu 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 pod-

rozdziale).

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

33

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 wykorzy-

stują 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 jed-

nostki 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 do-

stępność usług (ang. Service Level Agreements);

• wykrywanie zagrożeń (którym szybki rozwój Internetu dał okazję do spektakular-

nych 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 popraw-

nej realizacji powyższych zadań. Na potwierdzenie tej tezy przytoczę wypowiedź

(19) Jeffa Duke, starszego inżyniera sieci w Departamencie Technologii stanu In-

diana. Do jego zadań należy nadzór nad siecią gigabitowego Ethernetu, wykorzy-

stywanego 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 wy-

powiedzi osób zawodowo zajmujących się administrowaniem rozległych sieci.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

34

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Zeus Kerravala, członek zarządu ds. infrastruktury firmy Yankee Group, specjalizu-

ją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 tren-

dó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 przy-

padku statystyk dostępu do obciążonych usług internetowych, twierdzi Ryan Nelson (19),

dyrektor operacyjny Major League Baseball Advanced Media – agencji prasowej obsługu-

ją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 ru-

chu (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 przeszu-

kiwać 10 gigabitowy plik logu każdego dnia. (…) Teraz, gdy widzimy, że dzieje się coś

dziwnego, wykorzystujemy Coradiant

1

. On ciągle pracuje, zbierając informacje i wskazuje

źródło anomalii.”

Trafnym podsumowaniem nowych wymagań jest opinia Jon Oltsik, analityka En-

terprise 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. Utrzy-

manie 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 skoncentro-

wanie się na użytkowniku – odbiorcy usług, przy czym najłatwiej jest to osiągnąć korzy-

stając z analizy przepływów.

1

Zestaw narzędzi do monitorowania wydajności, wykorzystujący informacje o przepływach. Szcze-

gółowe informacje można znaleźć na stronie http://www.coradiant.com/

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

35

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

5.2 IPFIX – nowy standard monitorowania przepływów

Opisana powyżej ewolucja metod monitorowania sieci komputerowych, wymuszo-

na zmianą charakteru aplikacji sieciowych, spowodowała rozwój monitorowania opartego

o przepływy. Podobnie jak to miało miejsce w przypadku wielu innych zagadnień informa-

tycznych, 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 - proto-

kół 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. Jed-

nym 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ń sie-

ciowych – 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ą funkcjo-

nalność 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 infor-

macji 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 no-

wych wersjach systemu operacyjnego urządzeń CISCO – IOS.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

36

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

• 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 stowarzysze-

nie osób zainteresowanych ustanawianiem standardów technicznych i organizacyjnych w

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

37

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 proto-

kół 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 prezento-

waniu standardu NetFlow v9.

5.3 IPFIX oraz NetFlow – wspólne podstawy

Poniżej zostaną przedstawione cechy charakterystyczne, wspólne dla IPFIX i Net-

Flow: zbiór pojęć wykorzystywanych w definiowaniu nowego standardu oraz szkielet ar-

chitektury.

5.3.1 Pojęcia podstawowe

Grupa pracująca w ramach IETF przygotowując nowy standard wprowadziła spe-

cyficzny 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 zbio-

rem 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

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

38

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 prze-

pł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 po-

szczególnych interfejsach routera są zawarte w punkcie obserwacji obejmującym

cały router).

• proces monitorujący/mierzący/klasyfikujący (ang. metering process): proces two-

rzący logiczne przepływy (grupowane w rekordy) na podstawie fizycznie obser-

wowanych (w punkcie obserwacji) pakietów, które spełniają kryteria zdefiniowa-

nych przepływów. Proces ten wykorzystuje funkcje przechwytujące nagłówki pa-

kietów, dokonujące znakowania czasowego (ang. timestamping), próbkujące i kla-

syfikują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 pro-

cesu 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)

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

39

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

• rekord przepływu (ang. flow record): struktura przechowująca informacje o prze-

pływach zaobserwowanych i sklasyfikowanych w danym punkcie obserwacji. Re-

kord zawiera mierzalne informacje dotyczące przepływu (np. całkowita liczba baj-

tó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 prze-

pł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ły-

wów przesyłane przez jeden lub kilka procesów eksportujących. Po odebraniu mo-

że magazynować rekordy lub dalej je przetwarzać.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

40

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

5.3.2 Architektura

Wykorzystując zdefiniowane powyżej pojęcia można przedstawić architekturę no-

wego 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 przy-

padku 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 odniesie-

niu 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 prze-

słania danych do procesu zbierającego w wybranym przez siebie momencie, bez interakcji

z kolektorem. Autonomia procesu zbierającego informacje o przepływach jest charaktery-

styczna dla tego protokołu.

Informacje dotyczące sposobu umieszczania sondy monitorującej i lokalizacji pun-

ków obserwacji zostaną przedstawione w dalszej części rozdziału.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

41

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 opi-

sywałem zagadnienia zarządzania sieciami ze szczególnym uwzględnieniem monitorowa-

nia, 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 Accoun-

ting): 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żytkow-

nik/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). Stwo-

rzenie takiej charakterystyki jest wymogiem prawidłowego planowania sieci oraz

jej późniejszej eksploatacji. Do zbioru parametrów przepływu, które są wykorzy-

stywane 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 profilo-

wania ruchu.

3. Inżynieria ruchu sieciowego (ang. Traffic Engineering): składa się z metody mie-

rzenia, charakteryzowania i kontroli sieci. Zadaniem inżynierii jest optymalizacja

wykorzystania zasobów oraz utrzymywanie wysokiej wydajności sieci przez reali-

zowanie (z wykorzystaniem SNMP lub innych sposobów konfigurowania urzą-

dzeń) zaleceń wynikających z monitorowania. Ponieważ kontrola administratorska

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

42

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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): przechwytywa-

nie 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 mo-

nitorowanie 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ż wy-

szukiwaniu określonych wzorców komunikacyjnych.

5. Monitorowanie QoS (ang. QoS Monitoring): to proces biernego pomiaru parame-

tró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 infor-

macji 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 monito-

rowaniem 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ślo-

nych 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 para-

metrem 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 wy-

różnienia przepływu – proces monitorujący musi dać się skonfigurować tak, aby na pod-

stawie dowolnego podzbioru tych parametrów mógł dokonać klasyfikacji pakietu. Pod-

zbió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 war-

stwy sieci i warstwy transportowej, dlatego też wymagania stawiane przed procesem moni-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

43

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 na-

głó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 pod-

stawie dołączonej maski);

b. docelowy adres IP (również w postaci adresu prefixowego, obliczanego na pod-

stawie 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) pro-

ces eksportujący musi mieć możliwość rozróżniania również w oparciu o ten pa-

rametr.

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ą kombina-

cję 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 pakie-

tó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 niezawod-

ności musi być znany i wskazany. Można powiedzieć o procesie klasyfikującym że

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

44

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 pa-

kiety mogą zostać przeanalizowane, proces monitorujący musi mieć zaimplemen-

towaną 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 rekor-

dy 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 wykorzysta-

niem 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 do-

stosować swoje działanie do zaistniałej sytuacji poprzez:

− zmniejszenie liczby monitorowanych przepływów poprzez bardziej gruboziarni-

ste 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óbko-

wania;

−

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 modyfika-

cji 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 zmia-

nie procesy kolektorów, do których wysyła rekordy przepływów.

Dodawane znaczników czasu: proces musi generować znaczniki czasu dla pierw-

szego i ostatniego pakietu w każdym przepływie. Minimalna odległość pomiędzy

znacznikami czasu to jedna setna sekundy (0.01 s).

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

45

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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ć przeter-

minowaniu 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, kiero-

wanych na wszystkie porty urządzenia, proces monitorujący powinien stworzyć re-

kordy przepływu dla każdego portu, rozróżniając je właśnie ze względu na port do-

celowy.

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 rekor-

dó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 potrzeb-

ne 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 jedne-

go przepływu;

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

46

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

9. oktet typ usługi z nagłówka IPv4 lub klasy ruchu (dla IPv6) (zgodnie ze specyfi-

kacją 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 monito-

rowania 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 monitoro-

wania NetFlow);

20. współczynnik replikacji (Multicast): liczba pakietów wygenerowanych na pod-

stawie jednego przychodzącego pakietu rozgłoszeniowego. Wartość ta nie jest

stała – zmienia się wraz ze zmianami zachodzącymi w sieci (np. mniej kompute-

ró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;

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

47

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 pa-

rametró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 potrze-

by 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 informa-

cji 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ępu-

ją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ępo-

wania błędów, bez konieczności rozwiązywania trudności.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

48

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Implementowane rozwiązanie musi umożliwiać rozszerzanie niezawodności po-

przez wdrożenie: retransmisji zagubionych rekordów, wykrywanie utraty połącze-

nia oraz potwierdzanie odbioru danych przez kolektor.

• bezpieczeństwa: niezbędne jest zapewnienie poufności, integralności oraz auten-

tycznoś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 ko-

lektora 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ść prze-

syłania rekordów w regularnych odstępach czasu.

• informowania o zdarzeniach: proces eksportujący może mieć możliwość przesyła-

nia 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 wy-

magana 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 bez-

pieczna łączność pomiędzy procesem eksportera i kolektora. Algorytmy maskowa-

nia informacji są rozwijane, nim jednak powstaną standardy konieczność masko-

wania nie jest obligatoryjna, nie można jej bezwzględnie wymagać.

Ważne jest, aby w przypadku maskowania przez eksportera proces kolektora wie-

dział, że dane są zamaskowane – tak aby możliwe było rozdzielenie rekordów ma-

skowanych 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;

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

49

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 funk-

cji 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ę reali-

zującą okresowe raportowanie);

o komunikaty przesyłane do kolektora (jeżeli proces eksportera ma zaimplemen-

towaną 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ść, integral-

ność 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 zrealizo-

wać poprzez określone wcześniej wymagania dotyczące szerokiej konfiguracji pro-

cesu monitorującego i eksportującego;

• skalowalność umożliwiającą zbieranie informacji z bardzo wielu procesów monito-

rują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 identyfi-

kacja otrzymywanych informacji pochodzących z wielu źródeł

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

50

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

5.4.9 Lokalizacja punktów obserwacji i procesów IPFIX

Grupa tworząca standard nie wprowadza żadnych zaleceń (ograniczeń) jeżeli cho-

dzi 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 mo-

nitorują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-+-> | E--+-> | E----+-> <-+--E E--+->
| | | | | | | / \ | | | | |
| M | | M | | M M | | M M |
| | | | /|\ | | /|\ /|\ | | /|\ /|\ |
| O | | OOO | | OOO OOO | | OOO OOO |
+---+ +-----+ +---------+ +---------+

dedykowana router

router

kilka procesów

sonda

modularny

eksportera

+---+ +---+ +---+
| E-+-> | E-+-> | E-+------------->---+
| | | | | | | | | +---+ +-+-----+
+-+-+ | M | | M | | E-+------->-+-C-M-E-+->
| | | | | | | | | | +---+ +-+-----+
+-+-+ +-+-+ | O | | M | | E-+->---+
| | | | +---+ | | | | | |
| M | +-+-+ | O | | M |
| | | | | | +---+ | | | +-----+
| O | | O | | O | ->-+-C-E-+->
+---+ +---+ +---+ +-----+
Konwerter zdalny punkt koncentrator

proxy

Protokołów 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-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

51

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 kolekto-

rem 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. Sche-

mat koncentratora przedstawia przykład agregowania rekordów przepływu: do koncentra-

tora 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 infor-

macje 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. gate-

ways).

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 przechwy-

tywanie 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 po-

winni w swoich produktach oferować funkcje zapewniające bezpieczeństwo. W tym roz-

dziale zostaną przedstawione zagrożenia, które mogą wpływać na poprawne funkcjonowa-

nie protokołu z perspektywy funkcji monitorującej, która jest jego głównym zadaniem.

• Ujawnienie danych o przepływach: informacje zawarte w rekordach przekazywa-

nych w ramach protokołu IPFIX (np. w rekordach przepływu) powinny być poufne

w czasie ich przekazywania pomiędzy elementami architektury protokołu. Możli-

wość 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

52

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Poufność powinna być również zachowana ze względu na obowiązek ochrony da-

nych 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 zali-

czane 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 wy-

korzystania między innymi dla celów monitorowania bezpieczeństwa i wykrywania

zagrożeń. Z tego też względu ryzyko dokonywania szkodliwych zmian w przesyła-

nych rekordach (aby ukryć występowanie szkodliwego ruchu) jest znacznie więk-

sze 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 siecio-

wego i obniżyć skuteczność zabezpieczeń.

Zabezpieczeniem protokołu przed tego rodzaju zagrożeniem może być wykorzysta-

nie 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 moni-

torujący, jeżeli pracuje w trybie pasywnym (gdzie przesyłanie rekordów jest stero-

wane przez kolektor) oczekując na polecenia od kolektora jest narażony na przyj-

mowanie sfałszowanych poleceń.

Inne zagrożenie związane z tego typu atakiem może wynikać również z obserwo-

wania 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 rekor-

dów.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

53

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 poja-

wiał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 wprowadza-

nia 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 dodatko-

we 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

54

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

• Nagłówek pakietu eksportowego: pierwsza część pakietu eksportowego. Nagłówek

dostarcza podstawowych informacji: określa wersję protokołu NetFlow, liczbę re-

kordów zawartych w pakiecie oraz numery sekwencyjne.

• Wzorzec rekordu danych (ang. template record): określa strukturę i sposób inter-

pretacji 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ły-

wó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 re-

kordó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 re-

kordó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 prze-

pł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)

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

55

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 za-

mieszczonej 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 scharak-

teryzować 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 analizowa-

nia 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 analizo-

wać ruch przychodzący do interfejsu.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

56

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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, prze-

sył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 zacho-

waniu się sieci:

• adresy źródłowe i docelowe pozwalają na określenie głównych ścieżek komunika-

cji;

• 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ły-

wie;

• 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 pa-

kietu 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):

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

57

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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):

Rysunek 6.3 Tworzenie rekordu przepływu #2

3. Kolejny pakiet rożni się od poprzedniego w obszarze parametrów kluczowych, dla-

tego też proces monitorujący tworzy nowy przepływ:

Rysunek 6.4 Tworzenie rekordu przepływu #3

Łatwo zauważyć, że zbieżność wymagana w zakresie aż siedmiu parametrów skut-

kuje generowaniu wielu przepływów, często zbyt wielu, łączonych później w procesie ana-

lizy. 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

58

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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. Jed-

nakż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 prze-

pł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

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

59

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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ć kon-

figurowalny, z możliwością ustawienia go na „0” dla natychmiastowego zakończe-

nia)

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 po-

winny 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 kolekto-

ra.

Protokół NetFlow domyślnie wykorzystuje protokół UDP, gwarantujący wysoką

wydajność przy przesyłaniu obszernych pakietów eksportowych. Można jednak wykorzy-

stać 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 wykorzy-

stywać różne protokoły transportowe.

Ze względu na fakt, iż protokół UDP nie gwarantuje poprawności transmisji w ob-

ciąż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 gwaranto-

wać 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

60

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

61

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

formuje proces eksportera jak należy traktować dane przesyłane w zbiorach rekordów da-

nych. 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 da-

nych. Proces eksportera może okresowo przesyłać do kolektora pakiety składające się tyl-

ko ze zbiorów rekordów wzorca i opcji, aby zapewnić aktualność informacji procesu zbie-

rają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. pro-

cesy zbierające powinny wykorzystywać kombinację źródłowego adresu IP i war-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

62

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

tość parametru Source ID do rozdzielania różnych strumieni eksportowych pocho-

dzą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 rekor-

dó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 ty-

pu).

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

63

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Template ID: każdy z nowo wygenerowanych rekordów wzorca otrzymuje unikal-

ny (w ramach domeny obserwacji) numer identyfikacyjny. Template ID z zakresu

0-255 są zarezerwowane dla zbiorów rekordów wzorca, opcji lub innych specjal-

nych typów rekordów. Template ID z zakresu 256-65535 określają zbiory rekor-

dó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 wy-

znaczyć koniec danego rekordu wzorca i początek kolejnego.

Field type: wartość liczbowa reprezentująca typ pola. Wartości te zostaną omówio-

ne 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 | Record 1 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - 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 wzor-

ca. Kolektor musi korzystać z tego parametru do odszukiwania właściwego szablo-

nu, 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

64

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Padding: dopełnienie, które eksporter powinien umieścić aby kolejny zbiór rekor-

dó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 ko-

lektora wzorca odpowiadającego przesłanym rekordom danych.

6.1.7 Pakiety opcji

Protokół NetFlow w wersji 9. wykorzystuje do przekazywania informacji tzw. re-

kordy opcji. Podobnie jak w przypadku rekordów danych przepływów, również przy prze-

kazywaniu 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 wyzna-

czenia pozycji kolejnego zbioru rekordów.

Template ID: ID danego wzorca, większa od 255 (pozwala, podobnie jak w przy-

padku rekordów danych przepływów, odnaleźć pasujący rekord danych).

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

65

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 monitorowa-

nia 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.

Padding: dopełnienie, które eksporter powinien umieścić aby kolejny zbiór rekor-

dó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”.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

66

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

• 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 inter-

pretować 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 1 - Option Field 2 Value| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Scope 1 Value |Record 2 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 2 - Option Field 2 Value| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Scope 1 Value |Record 3 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 3 - Option Field 2 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.

Padding: dopełnienie, które eksporter powinien umieścić aby kolejny zbiór rekor-

dó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”.

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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

67

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

6.1.8 Zarządzanie wzorcami

Ze względu na kluczową rolę wzorców w całym procesie wymiany informacji ko-

nieczne 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 pa-

kiecie 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 szablo-

nem;

• 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 otrzy-

manymi 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 infor-

macje 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 iden-

tyfikator. W przypadku zmiany wzorca jego identyfikator jest porzucany i nie po-

winien być ponownie wykorzystany aż do czasu restartu procesu eksportera;

• proces kolektora po otrzymaniu nowego wzorca o tym samym ID powinien odrzu-

cić 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-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

68

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

ż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ć re-

kordy wzorców w przyspieszonym trybie.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

69

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 pa-

rametry z nagłówka pakietu, informacje routowania (numer systemu autonomicznego, ma-

ska 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

War-

tość

Długość

(bajty)

Opis

IN_BYTES

1

N

Licznik bajtów przychodzących,

należących do 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)

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

70

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Typ pola

War-

tość

Długość

(bajty)

Opis

OUTPUT_SNMP

14

N

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 auto-

nomicznego BGP. Domyślnie N=2,

może być też N=4.

DST_AS

17

N

Numer docelowego systemu auto-

nomicznego BGP. Domyślnie N=2,

może być też N=4.

BGP_IPV4_NEXT_HOP

18

4

Adres IPv4 kolejnego routera na

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

bajtów

(oktetów) Multicast. 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

(w

milisekundach)

w

którym

pierwszy pakiet w ramach danego

przepływu został przełączony.

OUT_BYTES

23

N

Licznik

bajtów

wychodzących

należących

do

przepływu.

Domyślnie N=4.

OUT_PKTS

24

N

Licznik pakietów wychodzących

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ło-

wej.

IPV6_DST_MASK

30

1

Długość maski podsieci docelo-

wej.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

71

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Typ pola

War-

tość

Długość

(bajty)

Opis

IPV6_FLOW_LABEL

31

3

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óbko-

wanie pole to określa co ile

pakietów realizowana jest ta

operacja.

SAMPLING_ALGORITHM

35

1

Gdy

wykorzystywane

jest

próbkowanie określa zastosowany

algorytm:0x01

–

deterministyczne,

0x02

-

FLOW_ACTIVE_TIMEOUT 36

2

Czas (w sekundach) traktowania

przepływu jako aktywny.

FLOW_INACTIVE_

_TIMEOUT

37

2

Czas (w sekundach) traktowania

przepływu jako nieaktywny.

ENGINE_TYPE

38

1

Typ urządzenia przełączającego

przepływy (np. procesor route-

ra)

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

przez

daną

domenę

obserwacji.

Domyślnie

TOTAL_FLOWS_EXP

42

N

Licznik

przepływów

wyeksportowanych

przez

daną

domenę

obserwacji.

Domyślnie

MPLS_TOP_LABEL_TYPE 46

1

0x00 UNKNOWN
0x01 TE-MIDPT
0x02 ATOM
0x03 VPN
0x04 BGP
0x05 LDP

MPLS_TOP_LABEL_

_IP_ADDR

47

4

Parameter Forwarding Equivalent

Class

MPLS.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

72

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Typ pola

War-

tość

Długość

(bajty)

Opis

FLOW_SAMPLER_ID

48

1

Identyfikator

zwracany

przez

polecenie “show flow-sampler”

FLOW_SAMPLER_MODE

49

1

Typ

algorytmu

używanego

do

próbkowania danych: 0x02 losowe

FLOW_SAMPLER_

_RANDOM_INTERVAL

50

4

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

portem wejściowym.

DST_VLAN

59

2

Identyfikator VLAN związany z

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

Adres IPv6 kolejnego routera na

trasie

BGP_IPV6_NEXT_HOP

63

16

Adres IPv6 kolejnego routera na

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

Etykieta MPLS na pozycji 2. w

stosie.

MPLS_LABEL_3

72

3

Etykieta MPLS na pozycji 3. w

stosie.

MPLS_LABEL_4

73

3

Etykieta MPLS na pozycji 4. w

stosie.

MPLS_LABEL_5

74

3

Etykieta MPLS na pozycji 5. w

stosie.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

73

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Typ pola

War-

tość

Długość

(bajty)

Opis

MPLS_LABEL_6

75

3

Etykieta MPLS na pozycji 6. w

stosie.

MPLS_LABEL_7

76

3

Etykieta MPLS na pozycji 7. w

stosie.

MPLS_LABEL_8

77

3

Etykieta MPLS na pozycji 8. w

stosie.

MPLS_LABEL_9

78

3

Etykieta MPLS na pozycji 9. w

stosie.

MPLS_LABEL_10

79

3

Etykieta MPLS na pozycji 10. w

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 rezer-

wacji 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 kie-

rowano się dużą zmiennością charakteryzowanych parametrów, co mogłoby prowadzić do

nieoptymalnego wykorzystania pasma i pamięci operacyjnej.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

74

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

6.1.10 Proces kolektora

Proces zbierający otrzymuje wzorce rekordów od eksportera, zwykle przed otrzy-

maniem zbiorów rekordów danych (opcji). Taka kolejność gwarantuje prawidłowe zdeko-

dowanie 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ść przecho-

wania 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 wzor-

ca 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 wykorzysty-

wany do interpretacji nadchodzących rekordów danych.

W każdej chwili proces zbierający powinien utrzymywać najświeższe wartości na-

stępujących parametrów rekordów wzorca danych i rekordów wzorca opcji: oznaczenie

procesu eksportera, domeny obserwacji, identyfikatora wzorca (unikalnego w ramach pro-

cesu eksportera i domeny obserwacji), definicji wzorca oraz wskazanie ostatnio otrzyma-

nego rekordu.

Proces kolektora musi natychmiast po otrzymaniu nowego wzorca o tym samym

identyfikatorze nadpisać poprzedni i wykorzystywać nowo otrzymany szablon. Proces ko-

lektora 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 bezpiecz-

nej) 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 szcze-

gół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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

75

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

6.2 Przykład

Opis mechanizmu wzorców, wprowadzonego w 9. wersji protokołu, jest skompli-

kowany, dlatego też w specyfikacji zamieszczony został przykład obrazujący współdziała-

nie wzorców i zbiorów rekordów (26 str. 29 i następne). Oto jak wyglądają zbiory rekor-

dó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 ko-

nieczne 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)

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

76

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 re-

kordó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)

7 N

cy

wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji

nowych standardów pozwolił zrozumieć sposoby zbierania i przesyłania infor

chu sieciowym.

z implementacją NetFlow, przeanalizowanych na podstawie dokumentacji i praktycznych

doświadczeń inżynierów sieci korporacyjnej firmy Cisco.

7.1

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ówni

zarządza

podrozdziałach.

7.1.1

wych elementach: sondach, procesach eksportujących oraz kolektorach.

Łukasz Witaszek

Nowoczesne sposoby

Samodzielny Zakład Sieci Komputerowych

NetFlow

cyjne

W poprzednich rozdziałach pracy zostały przedstawione argumenty, które dopr

wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji

nowych standardów pozwolił zrozumieć sposoby zbierania i przesyłania infor

chu sieciowym.

z implementacją NetFlow, przeanalizowanych na podstawie dokumentacji i praktycznych

doświadczeń inżynierów sieci korporacyjnej firmy Cisco.

Właściwa architektura

Aby monitorować z wykorzystaniem NetFlow konieczn

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ż właściwe rozmieszczenie elementów architektury

zarządzania, w monitorowanej sieci. Aspekty te zostaną krótko omówione w poniższych

podrozdziałach.

7.1.1 Oprogramowanie stacji zarządzania

Opis architektury w poprzednich rozdziałach

wych elementach: sondach, procesach eksportujących oraz kolektorach.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami

Samodzielny Zakład Sieci Komputerowych

tFlow w pr

W poprzednich rozdziałach pracy zostały przedstawione argumenty, które dopr

wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji

nowych standardów pozwolił zrozumieć sposoby zbierania i przesyłania infor

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.

Właściwa architektura

Aby monitorować z wykorzystaniem NetFlow konieczn

nej lub kilku) stacji zarządzania, z zainstalowanym właściwym oprogramowaniem. Dla

poprawnej implementacji monitorowania opartego na analizowaniu przepływów ważne

eż właściwe rozmieszczenie elementów architektury

nia, w monitorowanej sieci. Aspekty te zostaną krótko omówione w poniższych

podrozdziałach.

Oprogramowanie stacji zarządzania

Opis architektury w poprzednich rozdziałach

wych elementach: sondach, procesach eksportujących oraz kolektorach.

zarządzania sieciami

Samodzielny Zakład Sieci Komputerowych

praktyce

W poprzednich rozdziałach pracy zostały przedstawione argumenty, które dopr

wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji

nowych standardów pozwolił zrozumieć sposoby zbierania i przesyłania infor

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.

Właściwa architektura systemu

Aby monitorować z wykorzystaniem NetFlow konieczn

nej lub kilku) stacji zarządzania, z zainstalowanym właściwym oprogramowaniem. Dla

poprawnej implementacji monitorowania opartego na analizowaniu przepływów ważne

eż właściwe rozmieszczenie elementów architektury

nia, w monitorowanej sieci. Aspekty te zostaną krótko omówione w poniższych

Oprogramowanie stacji zarządzania

Opis architektury w poprzednich rozdziałach

wych elementach: sondach, procesach eksportujących oraz kolektorach.

Rysunek 7.

zarządzania sieciami – protokół NetFlow

Samodzielny Zakład Sieci Komputerowych PŁ,

ktyce – ws

W poprzednich rozdziałach pracy zostały przedstawione argumenty, które dopr

wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji

nowych standardów pozwolił zrozumieć sposoby zbierania i przesyłania infor

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.

systemu

Aby monitorować z wykorzystaniem NetFlow konieczn

nej lub kilku) stacji zarządzania, z zainstalowanym właściwym oprogramowaniem. Dla

poprawnej implementacji monitorowania opartego na analizowaniu przepływów ważne

eż właściwe rozmieszczenie elementów architektury

nia, w monitorowanej sieci. Aspekty te zostaną krótko omówione w poniższych

Oprogramowanie stacji zarządzania

Opis architektury w poprzednich rozdziałach

wych elementach: sondach, procesach eksportujących oraz kolektorach.

.1 Podział architektury NetFlow (30)

protokół NetFlow

wskazów

W poprzednich rozdziałach pracy zostały przedstawione argumenty, które dopr

wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji

nowych standardów pozwolił zrozumieć sposoby zbierania i przesyłania infor

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.

Aby monitorować z wykorzystaniem NetFlow konieczn

nej lub kilku) stacji zarządzania, z zainstalowanym właściwym oprogramowaniem. Dla

poprawnej implementacji monitorowania opartego na analizowaniu przepływów ważne

eż właściwe rozmieszczenie elementów architektury

nia, w monitorowanej sieci. Aspekty te zostaną krótko omówione w poniższych

Oprogramowanie stacji zarządzania

Opis architektury w poprzednich rozdziałach koncentrował się głównie na końc

wych elementach: sondach, procesach eksportujących oraz kolektorach.

Podział architektury NetFlow (30)

azówki imp

W poprzednich rozdziałach pracy zostały przedstawione argumenty, które dopr

wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji

nowych standardów pozwolił zrozumieć sposoby zbierania i przesyłania infor

Poniżej przedstawionych zostanie kilka kluczowych aspektów związanych

z implementacją NetFlow, przeanalizowanych na podstawie dokumentacji i praktycznych

Aby monitorować z wykorzystaniem NetFlow konieczne jest przygotowanie (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

eż właściwe rozmieszczenie elementów architektury – sond, kolektorów i stacji

nia, w monitorowanej sieci. Aspekty te zostaną krótko omówione w poniższych

koncentrował się głównie na końc

wych elementach: sondach, procesach eksportujących oraz kolektorach.

Podział architektury NetFlow (30)

i implemen

W poprzednich rozdziałach pracy zostały przedstawione argumenty, które dopr

wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji

nowych standardów pozwolił zrozumieć sposoby zbierania i przesyłania informacji o r

Poniżej przedstawionych zostanie kilka kluczowych aspektów związanych

z implementacją NetFlow, przeanalizowanych na podstawie dokumentacji i praktycznych

jest przygotowanie (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

sond, kolektorów i stacji

nia, w monitorowanej sieci. Aspekty te zostaną krótko omówione w poniższych

koncentrował się głównie na końc

wych elementach: sondach, procesach eksportujących oraz kolektorach.

grudzień 07

lementa-

W poprzednich rozdziałach pracy zostały przedstawione argumenty, które dopro-

wadziły do powstania nowych metod zarządzania i monitorowania. Opis implementacji

macji o ru-

Poniżej przedstawionych zostanie kilka kluczowych aspektów związanych

z implementacją NetFlow, przeanalizowanych na podstawie dokumentacji i praktycznych

jest przygotowanie (jed-

nej lub kilku) stacji zarządzania, z zainstalowanym właściwym oprogramowaniem. Dla

poprawnej implementacji monitorowania opartego na analizowaniu przepływów ważne

sond, kolektorów i stacji

nia, w monitorowanej sieci. Aspekty te zostaną krótko omówione w poniższych

koncentrował się głównie na końco-

77

grudzień 07

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

78

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

W praktycznych zastosowaniach najważniejszy jest jednak wynik obserwacji pro-

wadzonych przez sondy. Zbieranie danych oraz ich wizualizacja jest zadaniem oprogra-

mowania 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 wy-

korzystują zgrupowanie w jednym pakiecie procesu (programu) kolektora, obszaru prze-

chowywania 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 obserwa-

cji 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 nadzoru-

ją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, planowa-

nia sieci i inżynierii ruchu, monitoring i rozliczanie wykorzystania usług)?

• czy ważne jest kontrolowanie w czasie rzeczywistym czy też analiza danych histo-

rycznych?

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

79

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

• pod kontrolą jakiego systemu operacyjnego będzie pracowała aplikacja zarządza-

nia?

• 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 zagwa-

rantuje sprawny system monitorowania, spełniający wymagania eksploatacyjne oraz po-

zwoli 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 dzie-

siątkach, a czasami nawet setkach tysięcy dolarów. Warto też wziąć pod uwagę, iż więk-

szość rozwiązań przygotowywanych jest na platformy Unixowe/Linuxowe, choć w ostat-

nim czasie przybywa rozwiązań uruchamianych pod kontrolą systemów operacyjnych

Windows.

Poniżej znajduje się lista oprogramowania służącego analizowaniu ruchu z wyko-

rzystaniem NetFlow, gdzie Cisco umieściło listę produktów komercyjnych swoich partne-

rów. Wspomniany wcześniej aspekt finansowy przedstawiony jest w formie przedziałów

cenowych: niski <$7500, średni <$25000 oraz wysoki >$25000.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

80

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Nazwa produktu

/ producenta

Główne zastosowa-

nie

Główny odbiorca

rozwiązania

System

operacyjny

Początkowy

przedział

cenowy

Cisco NetFlow

Collector

Analiza ruchu

Korporacje, dostawcy

usług

Linux, Solaris Średni

Cisco CS-Mars

Monitoring bezpieczeń-

stwa

Korporacje, małe i

średnie przedsiębior-

stwa

Linux

Średni

AdventNet – Net-

Flow Analyzer

Analiza ruchu

Korporacje, małe i

średnie przedsiębior-

stwa

Windows

Niski

Netusage - Apo-

apsis

Analiza ruchu

Korporacje

Linux

Średni

Arbor Networks

Analiza ruchu/monitoring

bezpieczeństwa

Korporacje, dostawcy

usług

BSD

Wysoki

Caligare

Analiza ruchu/monitoring

bezpieczeństwa

Korporacje, dostawcy

usług

Linux

Średni

Fluke Networks

Analiza ruchu

Korporacje, małe i

średnie przedsiębior-

stwa

Windows

Średni

HP (OpenView)

Analiza ruchu

Korporacje, ISP

Linux, Solaris Wysoki

IBM Aurora

Analiza ruchu / monito-

ring bezpieczeństwa

Korporacje, dostawcy

usług

Linux

Średni

IdeaData

Analiza ruchu

Korporacje

Win / Linux

Średni

InfoVista

Analiza ruchu

Korporacje, dostawcy

usług

Windows

Wysoki

IsarNet

Analiza ruchu

Korporacje, dostawcy

usług

Linux

Średni

Lancope

Analiza ruchu / monito-

ring bezpieczeństwa

Korporacje, dostawcy

usług

Linux

Wysoki

NetQoS

Analiza ruchu

Korporacje, dostawcy

usług

Windows

Wysoki

Valencia Systems

Analiza ruchu

Korporacje

Windows

Wysoki

Solarwinds

Analiza ruchu

Korporacje, małe i

średnie przedsiębior-

stwa

Windows

Niski

WiredCity

Analiza ruchu

Korporacje

Windows

Wysoki

Tabela 7.1 Komercyjne oprogramowanie stacji zarządzania (16)

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

81

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Uzupełnieniem powyższej listy produktów jest zbiór rozwiązań bezpłatnych, two-

rzonych w większości zgodnie z ideologią Otwartego Oprogramowania (ang. Open Sour-

ce). 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 monitorowa-

nia niezbyt intensywnego ruchu sieciowego. Cisco proponuje zaznajomienie się z następu-

jącymi rozwiązaniami:

Nazwa produktu /

producenta

Główne zastosowanie

Komentarz

System opera-

cyjny

Flow-tools

Program kolektora

Skalowalne

Unix

Flowd

Program kolektora

Obsługuje V9

BSD, Linux

FlowScan

Program raportujący współpracują-

cy z pakietem Flow-Tools

Unix

IPFlow

Analiza ruchu

Obsługuje V9, IPv4

oraz IPv6, MPLS

Linux, FreeBSD,

Solaris

NetFlow Guide

Program raportujący

BSD, Linux

NetFlow Monitor

Analiza ruchu

Obsługuje V9

Linux

NTOP

Program kolektora, sonda progra-

mowa

Obsługuje V9

Unix

Panoptis

Monitoring bezpieczeństwa

Unix

Stager

Program raportujący współpracują-

cy z pakietem Flow-Tools

Unix

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 re-

alizują założenia logicznego podziału infrastruktury na podsieci. Dlatego też Cisco wypo-

saża system operacyjny tychże urządzeń w funkcje sondy z szerokim zakresem konfigura-

cji. W związku z tym budowanie sieci w oparciu o sprzęt tego producenta gwarantuje

szybkie i łatwe wdrożenie monitorowania NetFlow.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

82

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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ądze-

niu 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 zna-

czą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ą proto-

kół 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ć prze-

analizowanie wskazówek inżynierów sieciowych odpowiedzialnych za prawidłowe funk-

cjonowanie infrastruktury. Doświadczenie zdobyte w nadzorowaniu tak rozległej sieci za-

owocowało powstaniem poniższej tabeli, przedstawiającej rozlokowanie i funkcjonalność

różnych elementów architektury NetFlow (29):

Lokalizacja w topologii sieci

Oprogramowanie

analizujące

Cel monitorowania

Bramy Internetowe połączone z

łączami dostawców usług siecio-

wych (ang. ISP)

Arbor Networks Peak-

flow Traffic

Arbor Networks Peak-

flow DoS

Analizowanie ruchu w rozbiciu na wyko-

rzystywane aplikacje.

Weryfikacja poprawności konfiguracji

protokołów routingu (np. BGP).

Wykrywanie anomalii.

Routery sieci wewnętrznej obsłu-

gujące publicznie dostępne zasoby

firmy.

Arbor Networks Peak-

flow DoS

Wykrywanie anomalii.

Routery szkieletowe

NetQoS Reporter Analy-

zer

Analizowanie ruchu w rozbiciu na wyko-

rzystywane aplikacje – planowanie rozwoju

sieci

Routery szkieletowe obsługujące

sieci dostępne publicznie

OSU flow-tools from

splintered.net

Zbieranie danych historycznych, wykorzy-

stywanych przy przewidywaniu trendów i

diagnostyce.

Bramy NAT (ang. Network Ad-

dress Translation Gateway)

OSU flow-tools from

splintered.net

Audytowanie realizowania polityki adresa-

cji oraz udostępniania usług.

Tabela 7.3 Lokalizacje sond i zadania monitorowania - sieć korporacji Cisco

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

83

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 cha-

rakteryzował 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ąsia-

dują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 do-

datkowa porcja obciążenia zwalania sieć. Co ciekawe, robak rozprzestrzeniał się za pomo-

cą 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 reago-

wać. 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 wykorzy-

staniem NetFlow (zaprojektowanego do śledzenia komunikacji) było szczególnie łatwe.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

84

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 wykorzy-

stywany był ten sam program do analizy przepływów. Jest to jeden z produktów wymie-

nionych 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 opro-

gramowania 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 Win-

dows 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 tech-

nologii monitorowania: NetFlow®, sFlow®, cflowd®, J-Flow®, IPFIX®, NetStre-

am® and Cisco NBAR®.

2. Program jest stworzony do pracy w systemie operacyjnym Windows oraz Linux

RedHat i wymaga do pracy zainstalowanego środowiska Java. Ilość monitorowa-

nych 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 darmo-

wej, 30-dniowej wersji próbnej (trial), która ma pełną funkcjonalność wersji płat-

nej.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

85

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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ą pa-

kietu instalacyjnego. Wymagania sprzętowe programu przedstawia poniższa tabela:

Ilość interfejsów

Procesor

Pamięć

operacyjna

Przestrzeń

dyskowa

Poniżej 10

2.6 GHz P-D/ 3.0 GHz P4 HT lub równo-

waż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ówno-

ważny

4 GB

225 GB

301 – 600

2.6 GHz quad core 3000 Xeon lub rów-

noważny

4 GB

450 GB

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 wy-

branych 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 wypo-

sażona w kartę sieci bezprzewodowej zgodnej ze standardem 802.11b. Do obsługi interfej-

su programu monitorującego wykorzystywana była przeglądarka Internet Explorer w wer-

sjach 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 Interne-

tu).

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

86

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Po zalogowaniu do programu wyświetlone zostaje główne okno aplikacji:

Rysunek 8.1 Główne okno aplikacji NetFlow Analyzer

W głównym oknie wyróżniłem cztery obszary, które prezentują najważniejsze in-

formacje 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 nadzo-

rowanych 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ń za-

stosowano protokół telnet i program Putty.

1

2

3

4

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

87

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 za-

rzą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 pro-

ces 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.) przygoto-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

88

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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, po-

nieważ produkty firmy Linksys serii WRT są przedmiotem zainteresowania wielu progra-

mistów tworzących wolne oprogramowanie, przez co dostępny jest szeroki wybór alterna-

tywnych 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 zinte-

growana 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 konfi-

guracji (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 ob-

ciąż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 in-

terfejsy 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 interfej-

sach. W przypadku, gdy router ma tylko dwa interfejsy (takie przykłady będą występowały

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

89

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 inter-

fejsu eth1 (połączenia bezprzewodowe). Aby uruchomić monitorowanie i eksport informa-

cji 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 prze-

pływy będą eksportowane co 10 minut (600s.), natomiast nieaktywne po 2 minu-

tach (120 s.)

Uruchomienie monitorowania na wybranych interfejsach z wykorzystaniem opisa-

nego polecenia przedstawia poniższa ilustracja:

Rysunek 8.4 Uruchomienie monitorowania – rflow

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

90

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Od tego momentu rozpoczyna się eksport informacji o przepływach z wykorzysta-

niem 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 poszcze-

gó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 charak-

terystyki. 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 rozdzia-

le 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żli-

we, 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 na-

leż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:

Category

IN

OUT

W tym samym oknie przestawione będą informacje o:

-

-

Łukasz Witaszek

Nowoczesne sposoby

Samodzielny Zakład Sieci Komputerowych

Category

Total

IN

1.97 GB

OUT

0.00

Rysunek

W tym samym oknie przestawione będą informacje o:

- dziesięciu najbardziej aktywnych aplikacjach

ApplicationI

Application

TCP_App
http
edonkey2000
UDP_App
Internet Radio (Winamp)
icmp
netbios-dgm
netbios-ns
dccm
domain
Others

- dziesięciu najaktywniejszych źródłach ruchu

SourceIN [1.97 GB]

Source

172.16.19.226

83.204.103.129

213.251.136.138

213.113.1.198

217.195.203.52

140.116.110.5

172.16.6.1

213.251.129.27

213.251.139.82

200.161.78.31

Others

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami

Samodzielny Zakład Sieci Komputerowych

Total

1 min

1.97 GB

2.09 Mbps

0.00

0.00

Rysunek 8.5 Router Linksys

W tym samym oknie przestawione będą informacje o:

dziesięciu najbardziej aktywnych aplikacjach

ApplicationIN [1.97 GB]

edonkey2000

Internet Radio (Winamp)

Tabela 8.2 Router Linksys

ciu najaktywniejszych źródłach ruchu

[1.97 GB]

172.16.19.226

83.204.103.129

213.251.136.138

213.113.1.198

217.195.203.52

140.116.110.5

213.251.129.27

213.251.139.82

200.161.78.31

Tabela 8.3 Router Linksys

zarządzania sieciami

Samodzielny Zakład Sieci Komputerowych

Max

1 min

Hourly

2.09 Mbps

334.12 Kbps

0.00

0.00

Router Linksys - c

W tym samym oknie przestawione będą informacje o:

dziesięciu najbardziej aktywnych aplikacjach

Traffic

1.05 GB
434.14 MB
138.13 MB
117.41 MB
102.59 MB
27.24 MB
23.69 MB
16.69 MB
12.93 MB
9.58 MB
28.45 MB

Router Linksys

ciu najaktywniejszych źródłach ruchu

Traffic

331.87 MB

67.18 MB

61.16 MB

57.88 MB

54.53 MB

53.12 MB

47.6 MB

39.54 MB

32.99 MB

29.64 MB

1.19 GB

Router Linksys

zarządzania sieciami – protokół NetFlow

Samodzielny Zakład Sieci Komputerowych PŁ,

Hourly

1 min

334.12 Kbps

0.00

0.00

0.00

charakterystyka

W tym samym oknie przestawione będą informacje o:

dziesięciu najbardziej aktywnych aplikacjach

434.14 MB
138.13 MB
117.41 MB
102.59 MB
27.24 MB

69 MB

16.69 MB
12.93 MB

28.45 MB

Router Linksys - charakterystyka

ciu najaktywniejszych źródłach ruchu

331.87 MB

67.18 MB

61.16 MB

57.88 MB

B

53.12 MB

39.54 MB

32.99 MB

29.64 MB

Router Linksys - charakterystyka

protokół NetFlow

Min

1 min

Hourly

0.00

2.6 Kbps

0.00

0.00

harakterystyka Quick View

W tym samym oknie przestawione będą informacje o:

dziesięciu najbardziej aktywnych aplikacjach

Traffic Percentage

54%
22%
7%
6%
5%
1%
1%
1%
1%
<1%
1%

harakterystyka Quick View

ciu najaktywniejszych źródłach ruchu

Traffic Percentage

17%

3%

3%

3%

3%

3%

2%

2%

2%

2%

61%

harakterystyka Quick View

Avg

45.14 Kbps

0.00

Quick View #1: interfejs

Traffic Percentage

Quick View #2: interfejs WAN

Traffic Percentage

Quick View #3: interfejs WAN

95th Percentile

220.88 Kbps

-

#1: interfejs WAN

#2: interfejs WAN

Traffic Percentage

: interfejs WAN

grudzień 07

95th Percentile

220.88 Kbps

91

grudzień 07

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

92

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

- dziesięciu najaktywniejszych odbiorcach ruchu

DestinationIN [1.97 GB]

Destination

Traffic

Traffic Percentage

172.16.19.226

877.8 MB

45%

172.16.6.239

319.21 MB

16%

172.16.6.184

65.69 MB

3%

172.16.6.182

31.2 MB

2%

82.246.76.192

29.79 MB

2%

172.16.6.167

24.71 MB

1%

172.16.6.154

20.06 MB

1%

172.16.6.249

19.84 MB

1%

84.120.236.189

19.05 MB

1%

201.254.122.66

18.98 MB

1%

Others

543.98 MB

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.

określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą

wybranego portu

•

•

•
•
•

Łukasz Witaszek

Nowoczesne sposoby

Samodzielny Zakład Sieci Komputerowych

Charakterystyki szczegółowe

Aby dokładnie przeanalizować w

określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą

wybranego portu

• ruchu –

lume), szybkości (

(packets);

• aplikacjach

rowaniu ruchu.

portów, którą można edytować w obszarze konfiguracji programu. Dla wybranego

przedziału czasu prezentuje się to nast

• źródłach
• odbiorcach
• konwersacj

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, o

biorcy oraz wykorzystywanej

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami

Samodzielny Zakład Sieci Komputerowych

Charakterystyki szczegółowe

Aby dokładnie przeanalizować w

określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą

wybranego portu. Wtedy udostępnione zostaną szczegółowe raporty, informujące

traffic, który można analizować w czterech perspektywach: objętości (

), szybkości (speed

);

aplikacjach – applic

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

Rysunek 8.6

źródłach – source, przedstawiający główne źródła pakietów

odbiorcach – destination

konwersacjach – conversation

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, o

biorcy oraz wykorzystywanej

zarządzania sieciami

Samodzielny Zakład Sieci Komputerowych

Charakterystyki szczegółowe dla interfejsu WAN

Aby dokładnie przeanalizować w

określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą

. Wtedy udostępnione zostaną szczegółowe raporty, informujące

, który można analizować w czterech perspektywach: objętości (

speed), wykorzystania łącza (

application, który prezentuje udział poszczególnych aplikacji w gen

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

Router Linksys

, przedstawiający główne źródła pakietów

destination, wskazujący odbiorców danych

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, o

biorcy oraz wykorzystywanej aplikacji

zarządzania sieciami – protokół NetFlow

Samodzielny Zakład Sieci Komputerowych PŁ,

dla interfejsu WAN

Aby dokładnie przeanalizować wymianę informacji realizowaną z wykorzystaniem

określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą

. Wtedy udostępnione zostaną szczegółowe raporty, informujące

, który można analizować w czterech perspektywach: objętości (

), wykorzystania łącza (

, który prezentuje udział poszczególnych aplikacji w gen

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:

Router Linksys - udział aplikacji w wykorzystaniu łacza WAN

, przedstawiający główne źródła pakietów

, wskazujący odbiorców danych

, 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, o

aplikacji;

protokół NetFlow

dla interfejsu WAN

ymianę informacji realizowaną z wykorzystaniem

określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą

. Wtedy udostępnione zostaną szczegółowe raporty, informujące

, który można analizować w czterech perspektywach: objętości (

), wykorzystania łącza (utilization

, który prezentuje udział poszczególnych aplikacji w gen

Przypisywanie aplikacji jest realizowane z wykorzystaniem mapy

portów, którą można edytować w obszarze konfiguracji programu. Dla wybranego

ępująco:

udział aplikacji w wykorzystaniu łacza WAN

, przedstawiający główne źródła pakietów

, wskazujący odbiorców danych

, 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, o

ymianę informacji realizowaną z wykorzystaniem

określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą

. Wtedy udostępnione zostaną szczegółowe raporty, informujące

, który można analizować w czterech perspektywach: objętości (

utilization) oraz liczby pakietów

, który prezentuje udział poszczególnych aplikacji w gen

Przypisywanie aplikacji jest realizowane z wykorzystaniem mapy

portów, którą można edytować w obszarze konfiguracji programu. Dla wybranego

udział aplikacji w wykorzystaniu łacza WAN

, przedstawiający główne źródła pakietów;

, wskazujący odbiorców danych;

, 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, o

ymianę informacji realizowaną z wykorzystaniem

określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą

. Wtedy udostępnione zostaną szczegółowe raporty, informujące o:

, który można analizować w czterech perspektywach: objętości (

) oraz liczby pakietów

, który prezentuje udział poszczególnych aplikacji w gen

Przypisywanie aplikacji jest realizowane z wykorzystaniem mapy

portów, którą można edytować w obszarze konfiguracji programu. Dla wybranego

udział aplikacji w wykorzystaniu łacza WAN

, 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, o

grudzień 07

ymianę informacji realizowaną z wykorzystaniem

określonego interfejsu należy w oknie głównym aplikacji uruchomić łącze (link) z nazwą

o:

, który można analizować w czterech perspektywach: objętości (vo-

) oraz liczby pakietów

, który prezentuje udział poszczególnych aplikacji w gene-

Przypisywanie aplikacji jest realizowane z wykorzystaniem mapy

portów, którą można edytować w obszarze konfiguracji programu. Dla wybranego

, 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, od-

93

grudzień 07

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

94

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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), jed-

nakże można je uzyskać tylko wykorzystując urządzenia Cisco.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

95

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Zaplanowane raporty (Schedule Reports): program ma wbudowaną funkcjonalność,

która pozwala na stworzenie planu automatycznego generowania raportów i przekazywa-

nia ich za pomocą poczty elektronicznej do wskazanych odbiorców. Mechanizm ten po-

zwala 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 genero-

wania 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 (for-

mat 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 - przeka-

zywane mailowo krótkie informacje o określonym zdarzeniu. Zdarzenia wyzwalające wy-

generowanie raportu można w dowolny sposób definiować, nadając również różny priory-

tet 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

96

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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.

8.3.1 Opis topologii

Badania środowiska rozbudowanej sieci (trzy stacje robocze i trzy urządzenia sie-

ciowe) zostało zrealizowane z wykorzystaniem następującej topologii:

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 route-

rze 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 poprzed-

nim 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

Catalyst 2960

Tatrz_Cisco 2651

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

97

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 oprogra-

mowania również nie jest najnowsza, niemniej jednak ma zaimplementowaną obsługę pro-

tokoł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 uru-

chomione zostaje monitorowanie, z analogicznie jak w poprzednim przypadku ustawiony-

mi 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. Konfigu-

racja routera na potrzeby monitorowania została przeprowadzona zgodnie ze wskazówka-

mi 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:

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

98

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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.

Rysunek 8.13 Uruchomienie monitorowania na Cisco 2651 #2

2. Kolejnym krokiem było uruchomienie procesu eksportującego z parametrami:

Rysunek 8.14 Uruchomienie monitorowania na Cisco 2651 #3

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 uru-

chomiony jest proces kolektora nasłuchujący na porcie 9996.

8.3.3 Prezentacja i analiza przepływów

W poprzednim badaniu, wykorzystującym topologię bez urządzenia firmy Cisco,

do prezentacji wyników obserwacji wykorzystałem domyślne szablony raportów. Aby sze-

rzej 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 monito-

rowanie 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

99

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 in-

formacji o interfejsie

IfIndex1

urządzenia

Tatrz_Cisco 2651 (192.168.1.2)

i zmie-

nimy 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 regular-

nymi 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:

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

100

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Rysunek 8.17 Router Cisco 2651 - raport Traffic, perspektywa packets [20:00-01:00 następne-

go 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ż ob-

serwujemy 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 nume-

rem 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ęp-

nego dnia]

Widzimy, że większość ruchu to komunikacja z wykorzystaniem protokołu http.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

101

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 zaso-

bach 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, wy-

korzystując dane o przepływach, zweryfikować pozornie nienaturalną transmisję. Jej cha-

rakter wynikał z ograniczeń szerokości pasma dostępnego dla komunikacji, która regular-

nie przekraczała dopuszczalne dla danego łącza wartości, po czym była tłumiona i cykl

rozpoczynał się od nowa.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

102

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 do-

kumencie względem wykorzystywanych w rzeczywistości. Wykluczone zostały też z mo-

nitorowania wszystkie przepływy występujące pomiędzy adresami wewnętrznymi w ban-

ku. 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 prze-

pływów) sprawiły, że przeprowadzenie badań na szerszą skalę okazało się niemożliwe.

8.4.1 Opis topologii

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).

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

103

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 środo-

wiska. W ustawieniach procesu eksportującego uwzględniono zmieniony adres IP stacji

zarządzania: 192.168.10.5.

8.4.3 Prezentacja i analiza przepływów

Badanie w sieci korporacyjnej zostało przeprowadzone w dniu 02.12.2007, w go-

dzinach 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 jedne-

go z departamentów, którego głównym zadaniem jest analizowanie marketingu interneto-

wego.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

104

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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ż wska-

zane jest odszukanie komputera, na którym tego typu oprogramowanie jest uruchomione.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

105

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Wykorzystując raport Converstation i perspektywę source odpowiedź poznajemy natych-

miast:

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 sku-

tecznoś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ż departa-

ment 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 odbloko-

wanie 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

106

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

8.5 Wnioski

Przedstawione badania, mimo iż przeprowadzone w bardzo małych sieciach kom-

puterowych, pozwoliły zebrać wiele uwag i wskazówek dotyczących zastosowania proto-

koł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 komercyj-

nego, które liczone jest w dziesiątkach tysięcy dolarów. Właściwe określenie po-

trzeb 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ż Net-

Flow monitoruje przepływy przychodzące (choć nie jest to już dogmatem – możli-

wość 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 prze-

pływach ustawiony z domyślnymi opcjami konfiguracji nie jest błędem. W przy-

padku 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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

107

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 zakre-

sie 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 or-

ganizacyjnej przedsiębiorstwa (np. przynależność komputera do określonego depar-

tamentu). Należy pamiętać, iż konieczne jest wprowadzenie tych ustaleń do konfi-

guracji 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ż wy-

magania osobom, które się nim posługują, ponieważ tylko prawidłowa interpretacja przed-

stawianych parametrów czyni NetFlow użytecznym.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

108

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

9 Dalszy rozwój metod monitorowania

Czy przedstawiona w poprzednich rozdziałach metoda monitorowania sieci to naj-

nowsze 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 genero-

wanych 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 zbiera-

nia 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 pa-

kietó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 programo-

wego 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-

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

109

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 ko-

lektorze danych z wielu procesów eksportujących.

Dodatkowe informacje znajdują się w opisie standardu RFC3176 oraz na stronie

www.sflow.org

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

110

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 stop-

niu 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 precy-

zyjniejszego separowania istotnego dla administratora ruchu;

• łączenie różnych technik rozliczania w jeden mechanizm (ang. accounting mecha-

nism).

Architektura nowego rozwiązania pozwala na równoległe śledzenie wielu przepły-

wów: administrator może konfigurować sondy do monitorowania tych samych przepły-

wó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):

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

111

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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 prze-

pływów przez dwie sondy, z czego każda przy klasyfikacji kieruje się innym zbiorem pa-

rametrów. Dzięki temu można uniknąć przesyłania nadmiaru danych oraz zmniejszyć za-

potrzebowanie 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 pra-

wie wszystkich warstw modelu OSI – od warstwy łącza danych aż po warstwę aplikacji.

Poniższy rysunek przedstawia nową architekturę. Warto zwrócić uwagę na wpro-

wadzenie 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 (Ap-

plication Flows), ruchu mulitkastowego (Multicast Flows), bezpieczeństwa (Security

Flows), ruchu IP (IP Flows), komunikacji peer to peer (Peering Flows).

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

112

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

113

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

9.3 Cisco NBAR – rozpoznawanie aplikacji

Zarówno NetFlow, Flexible NetFlow oraz wiele innych aplikacji zarządzania oferu-

je 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 Decimal Description References
------- ------- ----------- ----------
0/tcp Reserved
0/udp Reserved
[…]
ftp-data 20/udp File Transfer [Default Data]
# Jon Postel <postel&isi.edu>
ftp-data 20/sctp FTP
# IETF TSVWG
# Randall Stewart <rrs&cisco.com>
# [RFC4960]
ftp 21/tcp File Transfer [Control]
ftp 21/udp File Transfer [Control]
# Jon Postel <postel&isi.edu>
ftp 21/sctp FTP
# IETF TSVWG
# Randall Stewart <rrs&cisco.com>
# [RFC4960]
ssh 22/tcp SSH Remote Login Protocol
ssh 22/udp SSH Remote Login Protocol
# Tatu Ylonen <ylo&cs.hut.fi>
ssh 22/sctp SSH
# IETF TSVWG
# Randall Stewart <rrs&cisco.com>
# [RFC4960]
telnet 23/tcp Telnet
telnet 23/udp Telnet

Tabela 9.1 IANA tabela portów

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

114

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

Okazuje się jednak, że nowe aplikacje wymykają się klasyfikacji. Do głównych ob-

szarów, w których najczęściej spotykane są odstępstwa zaliczyć można programy wymie-

niają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 wykorzystywane-

go portu (w tym przede wszystkim z zakresu objętego wyłączną administracją IANA – 0-

1023) jest kilka. W przypadku komunikatorów najczęściej stosuje się to do ominięcia za-

pór sieciowych, które skonfigurowane zgodnie z polityką bezpieczeństwa, blokują znane

porty programów komunikacyjnych. Programy wymieniające pliki napotykają więcej prze-

szkó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 do-

stawców Internetu. Dodatkowo niechęć providerów powodowana jest nieuporządkowanym

sposobem wykorzystania łącza – otwieranych jest wiele połączeń między różnymi kompu-

terami, 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 podszy-

wania 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ć roz-

poznawanie 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ślo-

nych typów aplikacji.

Dodatkowe informacje na temat tego rozwiązana można znaleźć na stronie produ-

centa: www.cisco.com

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

115

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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__.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

116

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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]

http://www.cisco.com/en/US/products/ps6601/products_white_paper0900aecd804

06232.shtml.

26. —. Cisco IOS Flexible NetFlow Technology White Paper. [Online]

http://www.cisco.com/en/US/products/ps6601/products_white_paper0900aecd804

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.

Łukasz Witaszek

Nowoczesne sposoby zarządzania sieciami – protokół NetFlow

117

Samodzielny Zakład Sieci Komputerowych PŁ,

grudzień 07

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]

http://www.cisco.com/en/US/products/ps6601/products_white_paper0900aecd804

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/.