Detection and Isolation of Attackers Using Neflow Data

(1)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INFORMA ˇ

CN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

DETEKCE A IZOLACE ´

UTO ˇ

CN´IK ˚

U POMOC´I

Z ´

AZNAM ˚

U NETFLOW

DETECTION AND ISOLATION OF ATTACKERS USING NETFLOW DATA

DIPLOMOV ´

A PR ´

ACE

MASTER’S THESIS

AUTOR PR ´

ACE

MAT ˇ

EJ GR ´

EGR

AUTHOR

VEDOUC´I PR ´

ACE

Ing. PETR MATOU ˇ

SEK, Ph.D.

SUPERVISOR

(2)

Zad´

an´ı pr´

ace

1. Seznamte se s protokolem NetFlow a nástroji pro analýzu dat z´ıskaných ze sondy

NetFlow.

2. Seznamte se s penetraˇcn´ımi nástroji pro zjiˇst’ován´ı informac´ı o s´ıti a s´ıt’ových zaˇr´ızen´ı

(nessus, nmap, apod.).

3. Simulujte útok na s´ıt’ v laboratorn´ıch podm´ınkách. Analyzujte záznamy NetFlow

s c´ılem detekce a izolace ´utoˇcn´ık.

4. Navrhnˇete a implementujte syst´em pro automatickou detekci a izolaci ´utoˇcn´ıka.

5. Demonstrujte pouˇzitelnost systému na reálném s´ıt’ovém provozu (podle doporuˇcen´ı

(3)

Licenˇcn´ı smlouva

Licenˇcn´ı smlouva je uloˇzena v arch´ıvu Fakulty informaˇcn´ıch technologi´ı Vysok´eho uˇcen´ı

technick´eho v Brnˇe.

Abstrakt

Diplomová práce se zabývá pouˇzit´ım záznam˚u NetFlow pro detekci skenován´ı s´ıtˇe. Jako

zdroj dat jsou pouˇzita anonymizovan´a data NetFlow z p´ateˇrn´ı s´ıtˇe VUT. Z tˇechto dat jsou

vytvoˇreny statistiky, na jejichˇz z´akladˇe je navrhnuta sada skript˚u. Pomoc´ı tˇechto skript˚u je

moˇzné detekovat skenován´ı i ve velkých akademických s´ıt´ıch.

Abstract

This thesis deals with using NetFlow records for detection network scanning. Anonymized NetFlow records from backbone VUT network are used as the source. Based on statistics created from these records, several Bash and Python scripts are implemented. With these scripts it is possible to detect network scanning even in large academics networks.

Kl´ıˇcov´

a slova

NetFlow, sonda, skenov´an´ı, zabezpeˇcen´ı

Keywords

NetFlow, probe, scanning, security

Citace

Matˇej Grégr: Detekce a izolace útoˇcn´ık˚u pomoc´ı záznam˚u NetFlow, diplomová práce, Brno,

(4)

Detekce a izolace ´

utoˇcn´ık˚

u pomoc´ı z´

aznam˚

u NetFlow

Prohl´

aˇsen´ı

Prohlaˇsuji, ˇze jsem tuto diplomovou pr´aci vypracoval samostatnˇe pod veden´ım pana Ing. Petra

Matouˇska, Ph.D.

. . . .

Matˇej Gr´egr

26.5.2009

Podˇekov´

an´ı

Dˇekuji Ing. Petrovi Matouˇskovi, Ph.D. za veden´ı diplomové práce a cenné pˇripom´ınky a

Ing. Tomáˇsi Podermańskimu za zpˇr´ıstupnˇen´ı záznam˚u NetFlow a poskytnuté konzultace k

dosaˇzen´ym v´ysledk˚um.

c

Matˇej Gr´egr, 2009.

Tato práce vznikla jako ˇskoln´ı d´ılo na Vysokém uˇcen´ı technickém v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Práce je chránˇena autorským zákonem a jej´ı uˇzit´ı bez udˇelen´ı oprávnˇen´ı autorem je nezákonné, s výjimkou zákonem definovaných pˇr´ıpad˚u.

(5)

Obsah

Obsah 2

1 Uvod´ 3

1.1 C´ıl diplomov´e pr´ace . . . 3

1.2 Clenˇˇ en´ı pr´ace . . . 3

2 Utoky a jejich anal´´ yza 5 3 Skenovac´ı techniky a nástroje 7 3.1 Skenovac´ı techniky . . . 8 3.1.1 TCP . . . 8 3.1.2 UDP . . . 8 3.2 Skenovac´ı nástroje . . . 9 4 NetFlow 10 4.1 Protokol NetFlow . . . 10 4.1.1 Základn´ı popis . . . 10

4.1.2 Princip fungov´an´ı a vznik protokolu . . . 11

4.1.3 Ukl´adan´e informace . . . 12

4.1.4 Architektura NetFlow . . . 13

4.2 Sonda NetFlow . . . 13

4.2.1 Vlastnosti sondy: . . . 13

4.3 N´astroje . . . 14

5 Skenov´an´ı a NetFlow 15 5.1 Skenov´an´ı pomoc´ı nmap . . . 15

5.2 Skenov´an´ı pomoc´ı EtherScopeTMSeries II . . . 16

6 Práce s daty NetFlow v rozsáhlých s´ıt´ıch 18 6.1 Zdroj dat NetFlow . . . 18

6.2 Zpracov´an´ı dat . . . 20

7 Statistika dat NetFlow v rozsáhlých s´ıt´ıch 21 8 Analýza z´ıskaných dat a návrh aplikace 25 8.1 Shrnut´ı z´ıskaných statistik . . . 25

(6)

9 Implementace 31

9.1 Popis implementace . . . 31

9.2 Cas zpracov´ˇ an´ı . . . 33

10 Výsledky analýzy 35 10.1 Výzkum ve svˇetˇe . . . 39

10.2 Moˇzn´a rozˇs´ıˇren´ı . . . 39

11 Závˇer 40 Pouˇzitá literatura 42 Seznam pˇr´ıloh 43 A Nástroj nfdump - formát výstupu pipe 44 B Grafické rozhran´ı vytvoˇrené nástrojem nfsen 45 C Ukázka detekce a záznam komunikace 46 C.1 Skenovaná IP adresa pomoc´ı protkolu ICMP . . . 46

C.2 Detekce ´utoku snaˇz´ıc´ı se zneuˇz´ıt sluˇzbu Windows Messenger . . . 47

C.3 Skenov´an´ı sluˇzby DNS . . . 47

(7)

Kapitola 1

´

Uvod

Poˇc´ıtaˇcov´e s´ıtˇe ˇcel´ı v dneˇsn´ı dobˇe st´ale vˇetˇs´ımu mnoˇzstv´ı bezpeˇcnostn´ıch hrozeb a

za-bezpeˇcit je proti tˇemto hrozbám pˇrináˇs´ı celou ˇradu problém˚u. Samotný firewall jiˇz na

kvalitn´ı zabezpeˇcen´ı pˇrestává staˇcit a proto bývá kombinován s dalˇs´ı technologi´ı. Jednou

z moˇznost´ı jak zvýˇsit bezpeˇcnost poˇc´ıtaˇcové s´ıtˇe, by mohlo být vyuˇzit´ı záznam˚u NetFlow,

které jsou generovány sondami nebo smˇerovaˇci s podporou této technologie. Aby mohl

´

utoˇcn´ık naplánovat útok na poˇc´ıtaˇcovou s´ıt’, potˇrebuje znát o dané s´ıti co nejv´ıce informac´ı.

Pokud se pˇri zajiˇst’ován´ı bezpeˇcnosti poˇc´ıtaˇcové s´ıtˇe zamˇeˇr´ıme také na tuto poˇcátaˇcn´ı fázi ´

utoku, m˚uˇzeme d´ıky vˇcasné detekci útoku minimalizovat vzniklé ˇskody, pˇr´ıpadnˇe útok zcela

odvr´atit.

1.1 C´ıl diplomov´

e pr´

ace

Hlavn´ım c´ılem diplomové práce bude analyzovat, zda lze pomoc´ı záznam˚u NetFlow úspˇeˇsnˇe

detekovat poˇcáteˇcn´ı fázi útoku - skenován´ı s´ıtˇe. Pokud by se tyto typy útok˚u daly

dete-kovat, byl by to pˇr´ınos pro bezpeˇcnost s´ıtˇe. Reakc´ı na detekovaný útok by mohla být

blokace útoˇcn´ıka, omezen´ı útoˇcn´ıka nebo zaslán´ı informace správci s´ıtˇe. Tato diplomová

práce navazuje na semestráln´ı projekt, ve kterém byly popsány principy a fungován´ı

proto-kolu NetFlow, jaká zaˇr´ızen´ı slouˇz´ı ke generován´ı záznam˚u NetFlow a jaké nástroje m˚uˇzeme

pouˇz´ıt k analýze tˇechto záznam˚u. Byly také popsány techniky skenován´ı s´ıtˇe a dostupné

nástroje, které se ke skenován´ı pouˇz´ıvaj´ı. Jednotlivé skenovac´ı nástroje byly otestovány

v laboratorn´ıch podm´ınk´ach.

V diplomové práci se dále budu zabývat daty NetFlow z´ıskanými z reálného provozu

velké s´ıtˇe. Z tˇechto dat bude vytvoˇrena statistika, která pom˚uˇze urˇcit, které údaje jsou z

hle-diska detekce skenován´ı d˚uleˇzité. Dále bude implementována aplikace, která bude schopna

tato skenován´ı detekovat a zaznamenat. Dosaˇzené výsledky by mˇely být konzultovány se

správcem s´ıtˇe, aby se aplikace dala pouˇz´ıt prakticky a z´ıskané výsledky umoˇznily zvˇetˇsit

zabezpeˇcen´ı s´ıtˇe.

1.2 Clenˇ

ˇ

en´ı pr´

ace

Kapitola 2 popisuje souˇcasnˇe pouˇz´ıvané techniky pro detekci s´ıt’ových útok˚u. V kapitole

3 se zabývám technikami skenován´ı zaˇr´ızen´ı na s´ıti a skenovac´ımi nástroji (at’ uˇz

hard-warovými nebo softwarovými). Kapitola 4 popisuje protokol NetFlow, princip fungován´ı

(8)

skeno-vac´ıch nástroj˚u a testován´ı skenovac´ıch technik pˇri skenován´ı v laboratoˇri jsou popsány

v kapitole 5. Kapitola 6 popisuje problematiku analýzy záznam˚u NetFlow ve velkých s´ıt´ıch.

Je zde také popsáno, odkud byla z´ıskána data NetFlow, pouˇzita v této práci a jaká tato

data maj´ı omezen´ı. V kapitole 7 je pops´ano, jak byly vytvoˇreny z dat NetFlow statistiky,

které jsou pouˇzity pro zjiˇstˇen´ı, které informace jsou d˚uleˇzité z hlediska detekce skenován´ı.

V kapitole 8 jsou tato data analyzována a je vytvoˇren návrh aplikace, která bude schopna

detekovat skenov´an´ı. Kapitola 9 popisuje konkr´etn´ı implementaci pro s´ıt’ VUT. V kapitole

10 jsou shrnuty dosaˇzené výsledky a diskutována moˇzná rozˇs´ıˇren´ı. Souˇcást´ı diplomové práce

(9)

Kapitola 2

´

Utoky a jejich anal´

yza

´

Utok na s´ıt’ vˇzdy zaˇc´ıná zkoumán´ım s´ıtˇe (network reconnaissance), kdy se útoˇcn´ık pokouˇs´ı

o neautorizované zmapován´ı s´ıtˇe, sluˇzeb nebo zranitelnost´ı. C´ılem této fáze je z´ıskat dostatek

informac´ı k proveden´ı dalˇs´ıch typ˚u ´utok˚u se zamˇeˇren´ım na z´ısk´an´ı pˇr´ıstupu nebo odm´ıtnut´ı

pˇr´ıstupu legitimn´ım uˇzivatel˚um. Pokud by byla poˇcáteˇcn´ı fáze (tedy zkoumán´ı) neúspˇeˇsná,

dalˇs´ı útok by byl pro útoˇcn´ıka daleko obt´ıˇznˇeji realizovatelný. Pˇri mapován´ı s´ıtˇe se pouˇz´ıvaj´ı pˇreváˇznˇe následuj´ıc´ı techniky:

• Skenován´ı IP adres: Zjiˇst’ován´ı aktivn´ıch IP adres v pods´ıti ˇci organizaci. Realizované

pˇrev´aˇznˇe pomoc´ı protokolu ICMP a zpr´av Echo request, Echo reply (ping).

• Skenován´ı port˚u: U aktivn´ıch IP adres moˇznost zjistit, jaké sluˇzby dané s´ıt’ové zaˇr´ızen´ı

podporuje. V´ıce v kapitole 3

• Naslouchán´ı: Odposloucháván´ı datového provozu na s´ıti. Ztˇeˇzuj´ı to pˇrep´ınané s´ıtˇe, ale

pokud se bude analyzovat provoz na hraniˇcn´ıch bodech, lze z´ıskat mnoˇzstv´ı informac´ı.

• Informaˇcn´ı dotazy na aplikaˇcn´ı vrstvˇe: Vyuˇzit´ı dotaz˚u DNS, datab´aze whois, zjiˇstˇen´ı

rozsahu IP adres organizace

Pro detekci tˇechto a dalˇs´ıch typ˚u ´utok˚u se dnes ve vˇetˇs´ıch s´ıt´ıch pouˇz´ıvaj´ıNetwork

In-trusion Detection System (NIDS) a Network Intrusion Prevention System(NIPS). Syst´em

NIDS útoky detekuje a rozpoznává. Útok˚um se nesnaˇz´ı aktivnˇe bránit - jedná se o pasivn´ı

obranný systém. NIPS se snaˇz´ı útok˚um aktivnˇe zabránit. Systém NIDS/NIPS tvoˇr´ı

sen-zory na vstupn´ıch bodech s´ıtˇe, které analyzuj´ı s´ıt’ový provoz a snaˇz´ı se detekovat útoky.

Z´ıskaná data pos´ılaj´ı centráln´ı stanici, která je zpracovává. ˇReˇsen´ı m˚uˇze být ˇcistˇe

softwa-rov´e, napˇr. program snort, nebo specializovan´e zaˇr´ızen´ı, napˇr. Cisco Guard. Pˇri reakci na

´

utok je spuˇstˇen alarm. To je obecný název pro akci, kterou systém upozorˇnuje na

deteko-vanou aktivitu. Záleˇz´ı na systému, jak je tato akce realizována. M˚uˇze se jednat napˇr´ıklad

o poslán´ı e-mailu správci nebo zaznamenán´ı události do logovac´ıho souboru. ˇZádný systém

NIDS/NIPS ale nen´ı natolik pˇresn´y, aby generoval pouze korektn´ı alarmy. C´ılem je

mini-malizovat faleˇsn´e pozitivn´ı a negativn´ı alarmy.

• Faleˇsn´e alarmy - ˇspatn´e vyhodnocen´ı situace

– faleˇsné pozitivn´ı alarmy - vygenerován alarm pˇri normáln´ı s´ıt’ové aktivitˇe

(10)

• Pravé alarmy - správné vyhodnocen´ı situace

– pravé pozitivn´ı alarmy - vygenerován alarm pˇri útoku

– pravé negativn´ı alarmy - pˇri normln´ı aktivitˇe nen´ı generován ˇzádný alarm

Pro analýzu datového toku a detekci útok˚u se pouˇz´ıvá nˇekolik typ˚u analýz [19].

• Analýza vzor˚u - C´ılem je naj´ıt vzor, který je pro útok specifický. Z tˇechto vzor˚u jsou

pak vytvoˇreny databáze, které se vyuˇz´ıvaj´ı pro detekci (m˚uˇze být dodána napˇr´ıklad

výrobcem spolu se systémem IDS). Posloupnost paket˚u, které maj´ı nastaven pouze

pˇr´ıznak SYN, m˚uˇze být napˇr´ıklad vzor útoku pro skenován´ı. Kaˇzdý nový útok mus´ı

být analyzován a uloˇzen jako nový vzor. Podle poˇctu paket˚u potˇrebných k detekci

´

utoku m˚uˇzeme klasifikovat vzory atomick´e - staˇc´ı jeden paket, nebo sloˇzen´e - je

tˇreba v´ıce paket˚u. Systém IDS vyuˇz´ıvaj´ıc´ı tento typ analýzy m˚uˇze generovat zvýˇsené

mnoˇzstv´ı jak faleˇsných negativn´ıch alarm˚u (napˇr. pˇri malé zmˇenˇe známého útoku)

tak faleˇsn´ych pozitivn´ıch (vzor je pˇr´ıliˇs neurˇcit´y).

• Statistická analýza - Nˇekdy oznaˇcována také jako detekce anomáli´ı. Systém pracuj´ıc´ı

s touto analýzou se nauˇc´ı normáln´ı provoz v dané s´ıti, tzv. profil. Pokud následnˇe

profil s´ıtˇe pˇresáhne zvolenou odchylku, je generován alarm. Výhodou tohoto systému

je i moˇznost detekce nov´ych ´utok˚u a pokud je vytvoˇren kvalitn´ı profil, tak i sn´ıˇzen´ı

faleˇsných pozitivn´ıch alarm˚u. Uˇzivatelé své chován´ı mohou ale mˇenit, coˇz negativnˇe

ovlivˇnuje poˇcet faleˇsnˇe pozitivn´ıch alarm˚u (je nutn´e aktualizovat profily pˇri zmˇenˇe

s´ıtˇe).

• Kontrola obsahu protokol˚u - Aplikaˇcn´ı protokoly jako FTP, HTTP, SMTP a jin´e

mo-hou být analyzovány na základˇe obsahu jednotlivých paket˚u. Tato detekce a analýza

se týká sp´ıˇse systém˚u IPS, které mohou blokovat vybrané pˇr´ıkazy, slouˇzit jako proxy

servery a podobnˇe. Jedn´a se o aktivn´ı obranu.

Pokud je nˇejaký útok detekován, závis´ı na pouˇzitém systému, jaká bude dalˇs´ı reakce.

Pokud se jedná o systém NIDS, útok je zpravidla zaznamenán do souboru se záznamy (logu)

a systém upozorn´ı správce, který provede bezpeˇcnostn´ı opatˇren´ı. Systém NIPS zpravidla

reaguje ihned a útoku se snaˇz´ı aktivnˇe zabránit. Následuje fáze prevence, kdy se snaˇz´ı

upravit odolnost systému, aby zabránil dalˇs´ım podobným útok˚um. Moˇzné reakce a prevence:

• Reset spojen´ı TCP - u spojen´ı TCP je zasl´an paket s pˇr´ıznakem RST obˇema ´uˇcastn´ık˚um.

U spojen´ı UDP se generuje paket ICMP se zpr´avou Port Unreachable.

• Blokace spojen´ı - s´ıt’ové spojen´ı je ihned zruˇseno a zdrojová IP adresa je zablokována.

• Odeb´ırán´ı pˇridˇelených prostˇredk˚u - v pˇr´ıpadˇe vyˇcerpán´ı zdroj˚u se mˇen´ı napˇr. max.

poˇcet ˇc´asteˇcnˇe otevˇren´ych spojen´ı, max. doba neˇcinnosti spojen´ı (idle timeout), max. poˇcet

souˇcasnˇe otevˇrených spojen´ı, délka ˇcekán´ı na ukonˇcovac´ı paket (pˇr´ıznak FIN) a jiné.

• Vyuˇzit´ı proxy - u protokolu HTTP i jin´ych aplikaˇcn´ıch protokol˚u, u spojen´ı TCP se

(11)

Kapitola 3

Skenovac´ı techniky a n´

astroje

Skenován´ı s´ıtˇe bývá rozdˇeleno vˇetˇsinou na tˇri typy, podle zp˚usobu, jakým skenuje porty (viz

obrázek 3.1). Pˇri horizontáln´ım skenován´ı útoˇcn´ık skenuje jeden port na v´ıce poˇc´ıtaˇc´ıch.

U vertikáln´ıho skenován´ı skenuje v´ıce port˚u na jednom poˇc´ıtaˇci a blokové skenován´ı je

kombinac´ı obou. blokové skenování vertikální skenování horizontální skenování IP porty 1.1.1.1 ~ 1.1.1.255 ~ 1.1.2.1 ~ 1 22 23 21 1023 ~ ~ ~

Obr´azek 3.1: Typy skenov´an´ı

Skenován´ı je realizováno u protokolu TCP a UDP skenován´ım port˚u [8]. Porty mohou

b´yt v n´asleduj´ıc´ıch stavech:

• open, accepted: Pokud je port open (otevˇrený), znamená to, ˇze na nˇem bˇeˇz´ı s´ıt’ová

sluˇzba a je moˇzno s n´ım nav´azat spojen´ı.

• closed, denied: closed port znaˇc´ı uzavˇren´y port. Na pokus o pˇripojen´ı k takov´emu

portu je u TCP portu posl´an zpˇet paket s nastaven´ymi pˇr´ıznaky RST a ACK,

v pˇr´ıpadˇe portu UDP je posl´an ICMP paket typu 3, k´od 3 (port unreachable).

• filtered, blocked: Pˇri pokusu o kontaktov´an´ı tohoto portu nebyla zjiˇstˇena odpovˇed’

(kladná ani záporná)

Dalˇs´ı zjiˇst’ován´ı informac´ı o tom, co na daném portu bˇeˇz´ı za sluˇzbu, pˇr´ıpadnˇe jaký OS

(12)

3.1 Skenovac´ı techniky

3.1.1 TCP

U skenován´ı TCP port˚u m˚uˇzeme vyuˇz´ıt v´ıce technik. Vˇetˇsina vyuˇz´ıvá r˚uzných nastavených

pˇr´ıznak˚u v TCP paketu a toho, ˇze u protokolu TCP se navazuje a ustanovuje spojen´ı. Pˇri

navazov´an´ı spojen´ı jde o tzv. tˇr´ıf´azovou synchronizaci (three-way handshake). Pokud port

odpov´ı tak jak m´a (pˇr´ıznaky SYN/ACK), je ve stavu open. Pˇri odpovˇedi RST je ve stavu

closed a pˇri ˇz´adn´e odpovˇedi ve stavu filtered/blocked.

Skenov´an´ı SYN

Skenov´an´ı SYN nikdy nedokonˇc´ı TCP spojen´ı. Pro zjiˇstˇen´ı toho, zda je port otevˇren, mu

staˇc´ı poslat pouze paket s pˇr´ıznakem SYN a ˇcekat na odpovˇed’. Pokud pˇrijde SYN/ACK,

´

utoˇcn´ık v´ı, ˇze port je otevˇrený. Podle tˇr´ıfázové synchronizace by mˇel poslat paket s pˇr´ıznakem

ACK, ale ten nepoˇsle a kompletn´ı spojen´ı tedy nenaváˇze. Tento typ skenován´ı se vyuˇz´ıvá

pro svou rychlost a proto, ˇze je vˇetˇs´ı pravdˇepodobnost, ˇze nekompletn´ı nav´az´an´ı spojen´ı

nebude logov´ano.

Skenov´an´ı connect

Skenován´ı connect je vlastnˇe klasické kompletn´ı navázán´ı spojen´ı. Pokud je port ve stavu

open, probˇehnou vˇsechny tˇri kroky synchronizace TCP. Tato skenovac´ı technika nen´ı pˇr´ıliˇs

vyuˇz´ıv´ana, protoˇze poskytuje stejn´e informace jako SYN scan, ale je pomalejˇs´ı a kompletn´ı

spojen´ı b´yvaj´ı logov´ana.

Skenov´an´ı Null, FIN a Xmas

Tyto zp˚usoby skenov´an´ı vyuˇz´ıvaj´ı znˇen´ı TCP RFC 793 [15], kde je ˇreˇceno, ˇze pokud je

port ve stavu closed, na kaˇzdá pˇr´ıchoz´ı data, která neobsahuj´ı pˇr´ıznak RST, má odpovˇedˇet

paketem s pˇr´ıznakem RST. Pokud je port ve stavu open, m´a na jak´ekoliv pakety, kde nejsou

nastaveny ani jedny z pˇr´ıznak˚u SYN, RST, ACK, zareagovat zahozen´ım paketu.

• Skenován´ı Null pos´ılá pakety bez nastaven´ı jakéhokoliv pˇr´ıznaku.

• Skenov´an´ı FIN nastavuje u paketu pouze pˇr´ıznak FIN.

• Skenov´an´ı Xmas nastavuje pˇr´ıznaky FIN, URG a PSH.

Skenov´an´ı Ack

Tento zp˚usob skenován´ı má za úˇcel zjistit pouze to, zda je port filtrován nebo ne. Pokud

je port nefiltrov´an, tak open i closed port by na paket s pˇr´ıznakem ACK mˇel odpovˇedˇet

paketem s pˇr´ıznakem RST. Pokud je port filtrov´an, tak neodpov´ı.

3.1.2 UDP

U protokolu UDP se vyuˇz´ıvá pouze jediného skenován´ı. Pro oskenován´ı UDP portu se pos´ılá

paket UDP pouze s hlaviˇckou, který neobsahuje ˇzádná data. Pokud se vrát´ı jako odpovˇed’

paket ICMP typu 3, kódu 3, je port oznaˇcen jako closed. Pokud se vrát´ı paket ICMP jiného

k´odu (1,2,9,10,13), m˚uˇzeme port oznaˇcit jako filtered. Pˇri otevˇren´em portu jako odpovˇed’

(13)

3.2 Skenovac´ı n´

astroje

Vˇetˇsinu výˇse zmiˇnovaných technik skenován´ı lze vyzkouˇset pomoc´ı skenovac´ıho nástroje.

Kromˇe skenován´ı connect, které je v podstatˇe stejné, jako pˇripojen´ı se na daný port

telne-tem, vyuˇz´ıvaj´ı ostatn´ı techniky upravené pˇr´ıznaky v hlaviˇckách TCP paket˚u, které vyˇzaduj´ı

extern´ı knihovny a administrátorská oprávnˇen´ı. Nejznámˇejˇs´ı a nejpouˇz´ıvanˇejˇs´ı skener port˚u

a s´ıtˇe obecnˇe je n´astroj Network Mapper, zkr´acenˇe nmap.

Nmap [14]

Nmap (”Network Mapper”) je bezpeˇcnostn´ı a s´ıt’ov´y skener. Dok´aˇze odhalovat poˇc´ıtaˇce

v s´ıti a sluˇzby, kter´e na nich bˇeˇz´ı. Z pokroˇcilejˇs´ıch nastaven´ı lze pouˇz´ıt detekci operaˇcn´ıho

systému, jaké filtry a firewally jsou pouˇzity a jaké verze sluˇzeb bˇeˇz´ı na daném poˇc´ıtaˇci apod.

Je ˇs´ıˇren pod licenc´ı GNU GPL. Pokud ponecháme základn´ı nastaven´ı, tak základn´ı pˇr´ıkaz

#nmap ip.skenovaného.poˇc´ıtaˇce zadaný na pˇr´ıkazové ˇrádce otestuje, zda je poˇc´ıtaˇc

ak-tivn´ı a pokud ano, testuje pˇribliˇzne 1000 nejpouˇz´ıvanˇejˇs´ıch port˚u. Nmap m´a obrovsk´e

mnoˇzstv´ı nastaven´ı a r˚uzn´ych zp˚usob˚u jak zjistit, jak´e sluˇzby poˇc´ıtaˇc poskytuje. V´ıce

in-formac´ı lze z´ıskat v manuálové stránce nebo na stránce projektu.

Nessus [1]

Nessus je program pro kompletn´ı bezpeˇcnostn´ı analýzu. Skládá se z démonanessusd, který

se stará o samotné skenován´ı a klientanessus, který nastavuje r˚uzné parametry skenován´ı,

spouˇst´ı skenován´ı a zobrazuje výsledky uˇzivateli. Pro samotné skenován´ı pouˇz´ıvá zásuvné

moduly, napsan´e ve vlastn´ım skriptovac´ım jazyce NASL1. Tˇechto modul˚u existuje velk´e

mnoˇzstv´ı (pˇres 20 000) a st´ale se aktualizuj´ı, podle aktu´aln´ıch bezpeˇcnostn´ıch zranitelnost´ı.

Pˇri testován´ı zranitelnosti pouˇz´ıvá Nessus na zaˇcátku skenován´ı port˚u daného poˇc´ıtaˇce. Má

vlastn´ı skener, ale dokáˇze pouˇz´ıt také extern´ı, jako napˇr. nmap. U zjiˇstˇených otevˇrených

port˚u zkouˇs´ı vyuˇz´ıt známých bezpeˇcnostn´ıch chyb sluˇzeb, které na daném portu naslouchaj´ı.

Testuje tak´e konfiguraci a chybˇej´ıc´ı bezpeˇcnostn´ı z´aplaty, zda se nepouˇz´ıvaj´ı standardn´ı

a nevyplnˇená hesla a dalˇs´ı. Do roku 2005 to byl projekt s otevˇreným zdrojovým kódem,

pak byl uzavˇren. Pro nekomerˇcn´ı vyuˇzit´ı je st´ale k dispozici zdarma (je nutn´a registrace),

ale aktualizovan´e moduly jsou nab´ızeny se sedmidenn´ım zpoˇzdˇen´ım.

EtherScopeTMSeries II [2]

S´ıt’ m˚uˇzeme skenovat i pomoc´ı hardwarov´ych zaˇr´ızen´ı. Jedn´ım z analyz´ator˚u, je pˇr´ıstroj

EtherScopeTMSeries II od firmy Fluke networks. Tento pˇr´ıstroj dok´aˇze analyzovat s´ıt’, do

které je pˇripojen. Zvládá otestovat kabeláˇz, analyzovat provoz v s´ıti, identifikovat VLAN

s´ıtˇe, odhalit aktivn´ı zaˇr´ızen´ı v s´ıti. Je schopen zobrazit statistiky a grafy protokol˚u, kter´e se

na s´ıti pouˇz´ıvaj´ı, detekovat úzká m´ısta v s´ıti (bottleneck) a mnoho dalˇs´ıho. Zaˇr´ızen´ı pouˇz´ıvá

jako operaˇcn´ı syst´em Linux a pro zobrazen´ı v´ysledk˚u platformu Qtopia od firmy Trolltech.

Podrobnˇejˇs´ı popis je k dispozici v dokumentaci u v´yrobce.

1

(14)

Kapitola 4

NetFlow

Tato kapitola popisuje protokol NetFlow. Je zde popsán princip fungován´ı protokolu, nástroje,

které se pˇri práci s t´ımto protokolem pouˇz´ıvaj´ı, a sonda NetFlow, coˇz je hardwarové zaˇr´ızen´ı

vyuˇz´ıvaj´ıc´ı NetFlow protokol. Pomoc´ı tohoto protokolu lze ukl´adat z´aznam o provozu v s´ıti.

Tato data budou v práci dále analyzována a pokus´ım se zjistit, zda lze z tˇechto dat odhalit

skenov´an´ı s´ıtˇe.

4.1 Protokol NetFlow

4.1.1 Z´akladn´ı popis

Protokol NetFlow je protokol pro pˇrenos z´aznam˚u o toc´ıch, kter´y vyvinula spoleˇcnost Cisco.

NetFlow je také chápán i jako celý proces mˇeˇren´ı tok˚u. Jako dalˇs´ı protokoly této spoleˇcnosti

je uzavˇren´y, ale je k dispozici jeho specifikace v RFC 3954 [5](posledn´ı verze 9). D´ıky

dostupnosti specifikace je protokol implementován a podporován také na jiných platformách

neˇz Cisco IOS napˇr. smˇerovaˇce Juniper nebo distribuce FreeBSD, OpenBSD a GNU/Linux.

Vzniklo nˇekolik verz´ı tohoto protokolu. Nejpouˇz´ıvanˇejˇs´ı je v dneˇsn´ı dobˇe verze 5 a rozˇsiˇruje

se také posledn´ı verze 9. Posledn´ı verze protokolu NetFlow je také základem protokolu

IPFIX1, vytvoˇrený IETF, který pravdˇepodobnˇe bude v bl´ızké dobˇe schválen jako standard.

Protokol definuje nˇekolik pojm˚u, se kterými je nutné se seznámit.

• IP tok (IP Flow): ˇCasto se pouˇz´ıv´a pouze n´azev tok. Tok je posloupnost paket˚u

procházej´ıc´ı monitorovaným rozhran´ım za urˇcitý ˇcasový interval. Tyto pakety se

sho-duj´ı ve zdrojové a c´ılové IP adrese, zdrojovém a c´ılovém portu UDP nebo TCP,

protokolu, rozhran´ı a stejnˇe nastaven´ym bajtem Type of Service [6].

• NetFlow z´aznam(Flow Record, NetFlow data): Podrobnˇejˇs´ı informace k dan´emu

IP toku. Jsou zde informace o d´elce toku, poˇctu pˇrenesen´ych bajt˚u, paket˚u a dalˇs´ıch.

• Exportér (Exporter): Zaˇr´ızen´ı (napˇr. smˇerovaˇc), které monitoruje procházej´ıc´ı

pa-kety a vytv´aˇr´ı z nich IP toky. Informace z tˇechto tok˚u jsou ve formˇe z´aznam˚u NetFlow

odes´ıl´any do kolektoru.

• Exportovaný paket(Export Packet): Paket vytváˇrený exportérem, který obsahuje

záznamy NetFlow. Je odes´ılán exportérem do kolektoru.

(15)

• NetFlow kolektor(NetFlow collector): Kolektor, který pˇrij´ımá a zpracovává pakety

z jednoho nebo v´ıce exportér˚u. Tyto pakety jsou pak ukládány na disk.

Schéma fungován´ı protokolu lze vidˇet na obrázku 4.1. Zde jsou na pozici exportér˚u

smˇerovaˇce Cisco. Ty vytváˇrej´ı toky, které jsou dedikovanou linkou pos´ılány do kolektoru.

Následnˇe mohou být tato data zobrazena napˇr. pomoc´ı nástroj˚u nfdump 4.3 nebo nfsen

4.3.

Obr´azek 4.1: Princip fungov´an´ı protokolu

4.1.2 Princip fungov´an´ı a vznik protokolu

Kv˚uli urychlen´ı pˇrep´ın´an´ı na modern´ıch pˇrep´ınaˇc´ıch, kter´e pracuj´ı na tˇret´ı vrstvˇe

refe-renˇcn´ıho modelu ISO/OSI a vyuˇz´ıvaj´ı pokroˇcilejˇs´ı techniky pˇri pˇrep´ın´an´ı jako napˇr. access

list, byl pˇrepracován systém vyrovnávac´ıch pamˇet´ı na pˇrep´ınaˇc´ıch a smˇerovaˇc´ıch Cisco.

Zaˇcalo se vyuˇz´ıvat informac´ı o s´ıt’ovém toku. Tento tok se shodoval ve zdrojové a c´ılové

IP adrese a zdrojovém a c´ılovém portu, viz obrázek 4.2.

zdrojová IP adresa cílová IP adresa zdrojový port cílový port L3 protokol TOS vstupní rozhraní síťový provoz analýza paketu Vytvoření toků z atributů paketu

Informace o toku Počet paketů Bajtů/paket

adresy, porty . . . 13 456 1 234 . . .

Vyrovnávací paměť NetFlow

Zařízení s podporou NetFlow

Obr´azek 4.2: Princip vytv´aˇren´ı toku [6]

Vedlejˇs´ım efektem byl zisk zaj´ımav´ych statistik o s´ıt’ov´em toku. Tyto statistiky byly

rozˇs´ıˇreny a za cenu m´ırnˇe vyˇsˇs´ı reˇzie pˇri pr˚uchodu paket˚u jsou z´ıskávány informace, které

mohou být pouˇzity k celkové analýze vyt´ıˇzen´ı s´ıtˇe, analýze provozu dat procházej´ıc´ı

(16)

které dokázaly s protokolem NetFlow pracovat a pouˇz´ıvat ho napˇr. k úˇctován´ı zákazn´ık˚u

za mnoˇzstv´ı odeslan´ych dat nebo konektivitu.

Protokol NetFlow vytváˇr´ı pro vˇsechny aktivn´ı toky vyrovnávac´ı pamˇet’, která je

vy-tvoˇrena na základˇe pˇrijet´ı prvn´ıho paketu daného toku. V této vyrovnávac´ı pamˇeti se

po-stupnˇe ukládaj´ı dalˇs´ı informace o toku, které jsou pozdˇeji odeslány do kolektoru. Tyto

exporty jsou provádˇeny jednou za ˇcas podle nastaven´ı zaˇr´ızen´ı, které export dat provád´ı.

Export dat u protokolu NetFlow by mˇel b´yt dostateˇcnˇe efektivn´ı a podle statistik by mˇel

tvoˇrit pouze 1,5 % [20] pˇrenesených dat na smˇerovaˇci. Ukonˇcován´ı toku a následný export

se obvykle ˇr´ıd´ı podle n´asleduj´ıc´ıch pravidel:

• Spojen´ı TCP bylo uzavˇreno, at’ uˇz pomoc´ı ukonˇcen´ı spojen´ı (pˇr´ıznak FIN) nebo

zruˇsen´ı (pˇr´ıznak RST).

• Tok je po urˇcitou dobu neaktivn´ı.

• Tok trv´a pˇr´ıliˇs dlouho (z´akladn´ı hodnota v nastaven´ı je 20 minut).

• Zaplnˇen´ı vyrovn´avac´ı pamˇeti, hrozba pˇreteˇcen´ı ˇc´ıtaˇc˚u.

Ukonˇcené datové toky se záznamy NetFlow jsou spojeny do paketu viz. 4.1.1 -

Exporto-vaný paket a odeslány do kolektoru. Tento paket m˚uˇze obsahovat aˇz 30 záznam˚u NetFlow.

Data se pos´ılaj´ı jako datagramy UDP a po odesl´an´ı jsou export´erem zahozeny. Protoˇze je

protokol UDP bezestavov´y, m˚uˇze doj´ıt ke ztr´atˇe datagramu.

4.1.3 Ukl´adan´e informace

V následuj´ıc´ı tabulce lze vidˇet, co vˇse protokol NetFlow ukládá a jaké informace tedy

m˚uˇzeme pouˇz´ıt k následné analýze. Tato data lze z´ıskat pomoc´ı nástroje nfdump 4.3

Date flow start Cas, kdy byl tok poprv´ˇ e zaznamenán. Ukládán ve formátu

ISO 8601 vˇcetnˇe milisekund.

Date flow end Konec toku. ˇCas, kdy byl tok naposledy detekován. Ukládán

ve form´atu ISO 8601 vˇcetnˇe milisekund.

Duration Délka toku v milisekundách. Pokud jsou toky agregované,

d´elka toku je souˇctem d´elek vˇsech tˇechto tok˚u.

Proto Protokol, kter´y byl pouˇzit v dan´em toku

Src IP Addr:port Zdrojov´a adresa a port

Dst IP Addr:port C´ılov´a adresa a port

TCP flags Pˇr´ıznaky u paketu TCP (SYN,ACK aj.)

ToS Typ sluˇzby (Type of service)

inif, outif Zdrojové a c´ılové s´ıt’ové rozhran´ı

src AS, dst AS Zdrojový a c´ılový autonomn´ı systém

Packets Poˇcet paket˚u v toku. Pokud jsou toky agregovan´e tak jejich

souˇcet

pps Poˇcet paket˚u za sekundu: poˇcet paket˚u / d´elka toku

bps Poˇcet bit˚u za sekundu: 8 * poˇcet bajt˚u / d´elka toku

Bpp Poˇcet bajt˚u za paket: poˇcet bajt˚u / poˇcet paket˚u

Flows Poˇcet tok˚u. Pokud jsou toky jenom vyps´any - vˇzdy 1. Pokud

(17)

4.1.4 Architektura NetFlow

Klasicky se pˇredpokládá na pozici exportéra Cisco smˇerovaˇc se zapnutou sluˇzbou NetFlow.

Smˇerovaˇce pak potom kromˇe pˇrepos´ılán´ı paket˚u mus´ı sv˚uj výpoˇcetn´ı výkon vˇenovat také

tvorbˇe statistik. Pokud smˇerovaˇcem procház´ı vyˇsˇs´ı datový tok, nem˚uˇze výpoˇcetnˇe zvládat

zpracováván´ı kaˇzdého paketu a zároveˇn generovat statistiky pro daný tok. Proto se provád´ı

vzorkován´ı, tedy pro výpoˇcet statistiky se vyuˇz´ıvá pouze kaˇzdý n-tý paket. Pokud záznamy

NetFlow z tˇechto smˇerovaˇc˚u slouˇz´ı pouze pro sbˇer statistik, pak vzorkov´an´ı nem´a vˇetˇs´ı

ne-gativn´ı vliv. Pouze sniˇzuje pˇresnost. Pokud ale chceme zabr´anit bezpeˇcnostn´ım incident˚um,

je výbˇer pouze kaˇzdého n-tého paketu problém.

Problém se vzorkován´ım paket˚u ˇreˇs´ı hardwarovˇe akcelerované sondy NetFlow. Podrobnˇejˇs´ı

popis sondy je v sekci 4.2.

4.2 Sonda NetFlow

Sonda NetFlow je pasivn´ım (data jsou pouze monitorov´ana, nezasahuje se do nich)

monito-rovac´ım zaˇr´ızen´ım [22]. Je schopn´a monitorovat IP toky a pos´ılat je do extern´ıch kolektor˚u.

Pokud sondu zapoj´ıme na linku, kterou chceme monitorovat, pˇr´ıchoz´ı provoz je posl´an

pˇr´ımo ke svému c´ıli a zároveˇn je kopie pˇredána sondˇe ke zpracován´ı. Pokud data odes´ıláme

dedikovanou linkou pˇr´ımo do kolektoru, je sonda neviditeln´a na linkov´e a vyˇsˇs´ı vrstvˇe. D´ıky

tomu je témˇeˇr vylouˇcen pˇr´ıpadný útok proti sondˇe. Pouˇzit´ı této sondy m´ısto smˇerovaˇc˚u

odstraˇnuje problém se vzorkován´ım paket˚u a pˇrináˇs´ı dalˇs´ı výhody. Smˇerovaˇce pak mohou

sv˚uj procesorový ˇcas vyuˇz´ıt pouze k tomu, k ˇcemu jsou urˇceny - smˇerován´ı. Analýzou bylo

zjiˇstˇeno, ˇze sonda zvládá na lince datovou propustnost 1Gbps bez ztráty paket˚u a bez

ohledu na velikost paket˚u [10].

4.2.1 Vlastnosti sondy:

• monitorov´an´ı dvou 1Gbps port˚u

• pˇresn´y ˇcas pˇri anal´yze paket˚u

• aktivn´ı ˇcasový limit - za jak dlouho se tok, který je povaˇzován za aktivn´ı, mus´ı odeslat

do kolektoru

• neaktivn´ı ˇcasový limit - umoˇzˇnuje nastavit ˇcasový interval, za který bude tok

klasifi-kován jako ukonˇcený a odeslán do kolektoru

• export dat ve verzi NetFlow 5, verzi 9 nebo IPFX

• export dat na v´ıce kolektor˚u z´aroveˇn

• moˇznost nastavit vzorkovan´ı

• sbˇer statistik - z´ısk´av´an´ı statistik o IP adrese, ˇc´ıslech port˚u, protokolech, poˇctech

(18)

4.3 N´

astroje

Pro práci se záznamy NetFlow existuje celá ˇrada nástroj˚u:

• nfdump(netflow dump) [4]: Nástroj pro ˇcten´ı a zpracováván´ı dat NetFlow uloˇzených

pomoc´ınfcapd. Dokáˇze z tˇechto dat vytváˇret statistiky. Napsán v C pro vˇetˇs´ı rychlost.

D´ıky tomu dok´aˇze filtrovat v´ıce neˇz 4 mili´ony tok˚u za vteˇrinu na 3GHz procesoru Intel

[9], nebo vypoˇc´ıtat statistiku top N za 2.5s pˇri 1,5 mili´on˚u tok˚u. Pracuje v pˇr´ıkazov´e

ˇrádce, podobný programu tcpdump. Podporuje záznamy NetFlow verze 5, 7 a 9. Lze

pouˇz´ıt filtrován´ı podobné jako u libpcap nebo WinPcap, které pouˇz´ıvá napˇr. tcpdump

a wireshark.

• nfcapd(netflow capture deamon): Zaznamenává data NetFlow ze s´ıtˇe a ukládá je do

soubor˚u. Dok´aˇze pracovat se z´aznamy NetFlow verze 5, 7, 9.

• nfprofile(netflow profiler): Dokáˇze procházet soubory uloˇzené pomoc´ınfcapd. Tyto

soubory filtruje podle zadaných filtr˚u a ukládá pro pozdˇejˇs´ı analýzu.

• nfreplay (netflow replay): ˇCte soubory s daty NetFlow uloˇzen´e pomoc´ı nfcapd

a pos´ıl´a je po s´ıti na jin´y poˇc´ıtaˇc.

• nfclean(netflow cleanup): Skript pro maz´an´ı star´ych dat.

• nfsen(netflow sensor): Jedná se o grafické rozhran´ı pro nástrojnfdump. D´ıky tomuto

nástroji lze pomoc´ı webových stránek jednoduˇse procházet uloˇzená data z kolektoru.

Dokáˇze z tˇechto dat zobrazit grafy pro jednotlivá rozhran´ı, protokoly, zvolit si ˇcasový

´

usek, za kter´y budou grafy vykresleny, a dalˇs´ı. Uk´azka rozhran´ı je v pˇr´ıloze B

(19)

Kapitola 5

Skenov´

an´ı a NetFlow

Skenovac´ı nástroje jsou bˇeˇznˇe pouˇz´ıvány pro analýzu s´ıtˇe. M˚uˇze je také ale pouˇz´ıt útoˇcn´ık

a informace z´ıskané z tˇechto skenován´ı pouˇz´ıt pro dalˇs´ı útok. Pokud chceme toto

ske-nov´an´ı detekovat, je tˇreba analyzovat, co za pakety tyto n´astroje pouˇz´ıvaj´ı. V laboratorn´ıch

podm´ınkách jsem vyzkouˇsel skenován´ı pomoc´ı nástroj˚u nmap a EtherScope.

5.1 Skenov´

an´ı pomoc´ı nmap

Následuje pˇr´ıklad, jak se uloˇz´ı data NetFlow pˇri skenován´ı pomoc´ı nástroje nmap. Schéma

5.1 ukazuje zapojen´ı sondy NetFlow v laboratoˇri. M˚uˇzeme si povˇsimnout, ˇze sonda nen´ı

zapojena pˇr´ımo do pˇrep´ınaˇce. Je to z toho d˚uvodu, ˇze dan´e skenov´an´ı bychom potom v˚ubec

neodhalili. Na s´ıti tvoˇren´e pˇrep´ınaˇci a smˇerovaˇci se data pos´ılaj´ı pouze od zdroje k c´ıli

(pokud pomineme r˚uzné útoky jako arp cache poisoning, zaplnˇen´ı CAM tabulky a jiné)

a data by pro sondu nebyla v˚ubec viditeln´a.

Obr´azek 5.1: Sch´ema zapojen´ı

Pokud nyn´ı provedeme skenován´ı pomoc´ı nástroje nmap, základn´ım pˇr´ıkazem#nmap 10.10.10.1,

a prohlédneme si, pomoc´ı nástroje nfdump, co sonda zaznamenala, z´ıskáme údaje, které

(20)

Date flow start Src IP Addr:Port Dst IP Addr:Port Flags Packets Flows 2008-11-18 16:03:56.423 10.10.10.106:43578 10.10.10.1:80 ....S. 1 1 2008-11-18 16:03:56.420 10.10.10.106:43578 10.10.10.1:22 ....S. 1 1 2008-11-18 16:03:56.422 10.10.10.106:43578 10.10.10.1:23 ....S. 1 1 2008-11-18 16:03:56.420 10.10.10.106:43578 10.10.10.1:143 ....S. 1 1 2008-11-18 16:03:56.422 10.10.10.106:43578 10.10.10.1:443 ....S. 1 1 2008-11-18 16:03:56.425 10.10.10.106:43578 10.10.10.1:21 ....S. 1 1 2008-11-18 16:03:56.425 10.10.10.106:43578 10.10.10.1:1024 ....S. 1 1 2008-11-18 16:03:57.645 10.10.10.106:43579 10.10.10.1:1301 ....S. 1 1

Pro pˇrehlednost byly z tabulky vypuˇstˇeny nˇekteré údaje. Jsou to informace o délce toku,

typ protokolu, ToS1 a poˇcet bajt˚u. Jak lze vidˇet, je skenov´ano asi 1000 nejpouˇz´ıvanˇejˇs´ıch

port˚u. Tok se vˇzdy zobrazuje jako jednosmˇern´y provoz. Tedy tyto stejn´e toky dostaneme

i v opaˇcném smˇeru, ale budou m´ıt nastavené jiné pˇr´ıznaky u paketu TCP (pˇr´ıznak RST,

odm´ıtnut´ı spojen´ı). Na prvn´ı pohled lze vidˇet, ˇze bylo pouˇzito skenov´an´ı SYN. Toho m˚uˇzeme

pˇri pozdˇejˇs´ım návrhu vyuˇz´ıt. Dalˇs´ı vˇec urˇcuj´ıc´ı skenován´ı je krátká délka toku a malý poˇcet

paket˚u v toku. Tyto informace bude tˇreba zpracovat a na z´akladˇe nich se rozhodovat.

Nástroj nfdump umoˇzˇnuje i tvorbu filtr˚u. Jednoduchým filtrem, který m˚uˇzeme pouˇz´ıt na

snadnˇejˇs´ı odhalen´ı skenov´an´ı SYN, by mohl b´yt napˇr´ıklad filtr

proto tcp and flags S and not flags ARFPU

Tento filtr vyp´ıˇse vˇsechny TCP toky, kter´e maj´ı u paketu TCP nastaven´y pouze pˇr´ıznak

SYN.

Vyzkouˇsel jsem vˇsechny typy skenov´an´ı, kter´e nmap poskytuje. Podrobnˇeji jsou tyto

techniky a principy, které pouˇz´ıvaj´ı k detekci port˚u, popsány v kapitole 3. Pokud se jedná

o skenován´ı SYN, tak je funkˇcn´ı, rychlé a spolehlivé. Skenován´ı connect je pomalejˇs´ı, ale

pokud na daném zaˇr´ızen´ı nemá uˇzivatel administrátorská oprávnˇen´ı, je taktéˇz pouˇzitelné.

U ménˇe obvyklých technik jako skenován´ı FIN a XMASS záleˇz´ı na zaˇr´ızen´ı. Vˇetˇsinou ale

zobraz´ı poˇcet otevˇrených ˇci filtrovaných port˚u. U skenován´ı NULL jsem se sp´ıˇse setkal s t´ım,

ˇ

ze na nˇe s´ıt’ov´e zaˇr´ızen´ı v˚ubec neodpovˇedˇelo, pˇrestoˇze by u zavˇren´ych port˚u mˇelo generovat

paket s pˇr´ıznakem RST.

5.2 Skenov´

an´ı pomoc´ı EtherScope

TM

Series II

Dalˇs´ı skenovac´ı zaˇr´ızen´ı, kter´e jsem vyzkouˇsel v laboratoˇri je pˇr´ıstroj EtherScope [2]. Tento

s´ıt’ov´y analyz´ator skenuje celou s´ıt’. Sondu jsem zapojil pˇr´ımo za toto zaˇr´ızen´ı, jak je vidˇet

na obrázku 5.2, abych z´ıskal veˇskeré údaje o paketech, které toto zaˇr´ızen´ı pos´ılá. Pˇribliˇzná

data lze vidˇet v n´asleduj´ıc´ı tabulce 5.2

1

(21)

Obr´azek 5.2: Sch´ema zapojen´ı II

Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Packets Bytes Flows

0.219 ICMP 10.10.10.150:0 10.10.10.106:8.0 ... 2 84 1 0.000 UDP 10.10.10.150:35072 255.255.255.255:7 ... 1 52 1 0.219 ICMP 10.10.10.150:0 10.10.10.51:8.0 ... 2 84 1 2.878 UDP 10.10.10.150:137 10.10.10.255:137 ... 3 234 1 13.650 ICMP 10.10.10.150:0 255.255.255.255:8.0 ... 2 80 1 0.220 ICMP 10.10.10.150:0 10.10.10.63:8.0 ... 2 84 1 0.218 ICMP 10.10.10.150:0 10.10.10.119:8.0 ... 2 84 1

Z této tabulky byly odstraˇneny údaje o ˇcasu skenován´ı a ToS. Tady vid´ıme, ˇze zaˇr´ızen´ı

EtherScope pos´ılá pˇreváˇznˇe pakety ICMP a UDP. U tˇechto paket˚u nem˚uˇzeme provést

fil-trován´ı jako u skenován´ı SYN. Jsou to ale toky vesmˇes velmi krátké, s malým poˇctem

pa-ket˚u a kr´atkou dobou trv´an´ı. Tyto toky by se v s´ıti nemˇely vyskytovat pˇr´ıliˇs ˇcasto. Vˇetˇsina

uˇzivatel˚u pouˇz´ıvá pˇripojen´ı pro prohl´ıˇzen´ı webových stránek, komunikaci nebo mail a tam

je trván´ı tok˚u delˇs´ı, s vˇetˇs´ım poˇctem paket˚u. Statistické výsledky, které zjiˇst’uj´ı, zda toto

(22)

Kapitola 6

Pr´

ace s daty NetFlow v rozs´

ahl´

ych

s´ıt´ıch

Objem dat NetFlow ukládáných smˇerovaˇci nebo sondami NetFlow záleˇz´ı na velikosti

pro-vozu s´ıtˇe. Velikost exportovan´ych soubor˚u se m˚uˇze pohybovat od nˇekolika MB v mal´ych

s´ıt´ıch do stovek MB ve velmi rozs´ahl´ych s´ıt´ıch.

V malých s´ıt´ıch mohou být pouˇzity pro vytváˇren´ı záznam˚u NetFlow smˇerovaˇce, které

tento protokol podporuj´ı. Ve vˇetˇs´ıch s´ıt´ıch s velkým datovým provozem to jiˇz ale nen´ı moˇzné

a je nutno zaznamen´avat data pomoc´ı hardwarovˇe akcelerovan´ych zaˇr´ızen´ı, jako jsou napˇr.

sondy NetFlow 4.2. Ty bývaj´ı nasazované do s´ıt´ı od velikosti padesáti zaˇr´ızen´ı. ˇCasto jsou

nasazovány v s´ıt´ıch o 100-500 zaˇr´ızen´ı. Následuj´ı banky, poskytovatelé pˇripojen´ı, státn´ı

instituce aj., kde se velikost s´ıtˇe pohybuje v nˇekolika tis´ıc´ıch zaˇr´ızen´ı.

6.1 Zdroj dat NetFlow

Pˇri zkuˇsebn´ım provozu sondy NetFlow zapojené v rámci vnitˇrn´ı s´ıtˇe FIT, byl ukládaný

provoz minimáln´ı a nehodil se k ˇzádné analýze. Pro podrobnˇejˇs´ı analýzu byla poskytnuta

data z páteˇrn´ı s´ıtˇe VUT, která je pˇripojena do akademické s´ıtˇe CESNET. Tato data jsou

z´ıskávána ze dvou extern´ıch 10Gb/s linek, které pˇripojuj´ı s´ıt’ VUT do CESNETu. Sbˇer

dat je prov´adˇen 10Gb/s kartami na provozu odboˇcen´em prostˇrednictv´ım TAPu. TAP je

hardwarov´e zaˇr´ızen´ı, kter´e umoˇzˇnuje monitorovat komunikaci mezi dvˇema body. Zaˇr´ızen´ı

má minimálnˇe tˇri porty. Port pro monitorován´ı a port pro kaˇzdé monitorované zaˇr´ızen´ı.

Veˇsker´a prob´ıhaj´ıc´ı komunikace mezi tˇemito body je pak zkop´ırov´ana na monitorovac´ı port.

Data jsou ukládána jako hodinový záznam (dump) provozu. Toto je celkem nestandardn´ı

ˇreˇsen´ı, protoˇze NetFlow exportér je standardnˇe nastaven na pˇetiminutové exportován´ı a toto

dodrˇzuje dle zkuˇsenost´ı z praxe vˇetˇsina firem.

Dodan´a data, s kter´ymi jsem pracoval, nejsou kompletn´ı data NetFlow. Chyb´ı jim

nˇekolik poloˇzek, napˇr. pˇr´ıznaky u paket˚u TCP. Toto do znaˇcné m´ıry ztˇeˇzuje vyhledáván´ı

skenován´ı, protoˇze nejv´ıce skenovac´ıch útok˚u je skenován´ı SYN [13]. Pokud bychom mˇeli

uloˇzeny i pˇr´ıznaky, mohli bychom pouˇz´ıt filtry, kter´e by z tok˚u vypsaly pouze ty s

na-staveným pˇr´ıznakem SYN a t´ımto do jisté m´ıry odhalit skenován´ı. U ustanoven´ı nového

spojen´ı TCP se sice také pos´ılá paket SYN, ale tento paket má nastaven i pˇr´ıznak ACK

a tedy by nezkreslil filtrované výsledky. Dalˇs´ı podstatná chybˇej´ıc´ı poloˇzka je u protokolu

ICMP. NetFlow dokáˇze u tohoto protokolu ukládat typ a kód paketu. Tyto poloˇzky ukládá

(23)

Request-100 150 200 250 300 350 400 00:00 05:00 10:00 15:00 20:00 čas / hod ve lik os t s ou bo ru / M B

Obr´azek 6.1: Pr˚umˇern´a velikost soubor˚u s NetFlow daty

Echo Reply, pouˇz´ıvána pˇr´ıkazem ping, bude ve zdrojovém portu uloˇzena 0 a v c´ılovém 8.0.

Odpovˇed’ Echo Reply (typ 0) na dotaz Echo Request (typ 8, k´od 0). Tento nedostatek,

stejnˇe jako chybˇej´ıc´ı pˇr´ıznaky u protokolu TCP, ztˇeˇzuje následné odhalen´ı útok˚u, které

tˇechto paket˚u ICMP vyuˇz´ıvaj´ı k zjiˇstˇen´ı ˇzivosti s´ıt’ov´ych zaˇr´ızen´ı. ˇCasem se vˇsak pl´anuje

zakoupen´ı sondy, kter´a bude schopna exportovat plnohodnotn´e data NetFlow.

Data jsou postupnˇe ukl´ad´ana na server od 15.11.2008 a zat´ım je moˇzno analyzovat

pˇribliˇznˇe 740 GB dat. Pˇribliˇzn´a velikost jednotliv´ych soubor˚u a poˇcet tok˚u za hodinu lze

vidˇet v grafu 6.1 a 6.2. U grafu 6.1 je vypoˇc´ıtaná pr˚umˇerná velikost soubor˚u za jednotlivé

hodiny. Pr˚umˇer je vypoˇc´ıtán z uloˇzených záznam˚u za tˇri mˇes´ıce. V grafu 6.2 je poˇcet tok˚u

vypoˇc´ıtán obdobnˇe, jako pr˚umˇerný poˇcet tok˚u za danou hodinu v daný den. Pr˚umˇer je

vypoˇc´ıtán také za tˇri mˇes´ıce záznam˚u. Zákazn´ıci pouˇz´ıvaj´ıc´ı sondy NetFlow v ˇCR dosáhnou

maxim´aln´ı propustnosti okolo 400 tok˚u za sekundu. Jak lze vidˇet, poˇcet tok˚u dosahovan´ych

v rámci páteˇrn´ı s´ıtˇe VUT je nejménˇe 1600 tok˚u/s, bˇeˇznˇe ale dosáhne 3500 tok˚u/s.

Zpracovávat takové mnoˇzstv´ı dat je ˇcasovˇe velmi nároˇcné. Pr˚umˇernou dobu generován´ı

statistik na poˇc´ıtaˇc´ıch, kter´e jsem pouˇz´ıval, lze vidˇet v tabulce 6.1.

Procesor/RAM Pr˚umˇern´a doba vytvoˇren´ı statistiky

Pentium-M 1.86 GHz / 1GB 22s

Intel Xeon 2.4 GHz / 3GB 12s

Tabulka 6.1: Pr˚umˇern´a doba zpracov´an´ı

Pr˚umˇern´a doba vytvoˇren´ı statistiky je doba, za kterou se vytvoˇr´ı statistika top 20 IP

adres seˇrazených podle poˇctu tok˚u z jednoho souboru, který obsahuje hodinový záznam

provozu. N´astroj nfdump umoˇzˇnuje proch´azet i v´ıce soubor˚u najednou a generovat z nich

globáln´ı statistiky. To je ale extrémnˇe nároˇcné na výpoˇcetn´ı zdroje a operaˇcn´ı pamˇet’. Doba

(24)

5e+06 6e+06 7e+06 8e+06 9e+06 1e+07 1.1e+07 1.2e+07 1.3e+07 1.4e+07 1.5e+07 00:00 5:00 10:00 15:00 20:00 po če t t ok ů čas / h

Obrázek 6.2: Pr˚umˇerný poˇcet tok˚u za jednotlivé hodiny

6.2 Zpracov´

an´ı dat

Z výˇse uvedených dob zpracován´ı a velikost´ı dat lze stanovit urˇcité postupy, jak budou data

dále zpracována. Nab´ızej´ı se dvˇe moˇznosti. Ukládat data do relaˇcn´ı databáze a pokusit se je

zpracovat dotazovac´ım jazykem ˇci nˇejak´ym rozˇs´ıˇren´ım pro data mining u datab´aze Oracle,

nebo se je pokusit zpracovat pˇr´ımo pomoc´ı skriptovac´ıch jazyk˚u. U relaˇcn´ı datab´aze by

se nejprve musel vygenerovat skript pro uloˇzen´ı dat, následnˇe data nahrát do databáze

a zpracovat, pravdˇepodobnˇe jazykem PHP nebo podobn´ym. U skriptovac´ıch jazyk˚u se data

mohou zpracovat rovnou a pravdˇepodobnˇe jsou ke zpracov´an´ı vhodnˇejˇs´ı.

U obou ˇreˇsen´ı se potýkáme s velkými objemy dat pro zpracován´ı. Tento objem dat by

mohl být sn´ıˇzen filtrován´ım. Abychom vˇedˇeli, jaká data je moˇzné odfiltrovat, jsou v kapitole

7 vytvoˇreny statistiky ze z´ıskaných dat, které by mohly pomoci s rozhodován´ım, která data

(25)

Kapitola 7

Statistika dat NetFlow v

rozs´

ahl´

ych s´ıt´ıch

V rozsáhlých s´ıt´ıch s velkým poˇctem aktivn´ıch uzl˚u a nˇekolika tis´ıci spojen´ımi za sekundu

je obt´ıˇzn´e v˚ubec z´ıskat plnohodnotn´a data NetFlow v pomˇeru 1:11. Data jsou bˇeˇznˇe

vzor-kována a hod´ı se hlavnˇe pro statistické úˇcely. Pokud jsou z´ıskávána kompletn´ı data, lze

v kapitole 6 vidˇet, ˇze tˇechto dat je velk´e mnoˇzstv´ı a zpracov´an´ı nen´ı nejrychlejˇs´ı. M˚uˇzeme

se tedy pokusit pod´ıvat na data jako celek, zjistit jak´e sluˇzby jsou v toc´ıch dominantn´ı,

jak´e jsou pˇrenosy dat, atp.

Na následuj´ıc´ım grafu 7.1 je vidˇet pr˚umˇerné mnoˇzstv´ı unikátn´ıch IP adres v pr˚ubˇehu

dne. Tento graf bude posléze d˚uleˇzitý pˇri návrhu zpracován´ı dat pro odhalen´ı skenován´ı.

Pokud bychom chtˇeli porovnávat jednotlivé záznamy mezi sebou, ˇcasová sloˇzitost takové

operace by byla kvadratická O(n2). U záznamu, který má 2 mil. unikátn´ıch IP adres za

hodinu, by poˇcet operac´ı potom dos´ahl 412_{, coˇ}_{z je ne´}_umˇ_ernˇ_{e n´}_aroˇ_cn´_{e a mus´ı b´}_{yt pouˇ}_{zit jin´}_y

pˇr´ıstup. 1e+06 1.2e+06 1.4e+06 1.6e+06 1.8e+06 2e+06 2.2e+06 2.4e+06 2.6e+06 00:00 05:00 10:00 15:00 20:00 po če t u nik át ní ch IP čas/hod

Obr´azek 7.1: Poˇcet unik´atn´ıch IP adres v toku

Graf 7.2 ukazuje, kolik je pr˚umˇernˇe vymˇenˇeno paket˚u v toku. V datech, ze kter´ych je

1

(26)

1 10 100 1000 10000 100000 1e+06 1e+07 1e+08 1 10 100 1000 10000 100000 1e+06 Če tn os t

Počet paketů v toku

Obr´azek 7.2: Frekvence poˇctu paket˚u v toku

tento graf vygenerován, se vyskytovalo témˇeˇr 35 mil. jednopaketových tok˚u, coˇz pˇredstavuje

pˇribliˇznˇe 55 %. Toky do 3 paket˚u pak tvoˇrily pˇribliˇznˇe 80 % vˇsech tok˚u. D´ıky t´eto statistice

se výraznˇe zmˇenilo tvrzen´ı, které jsme uvaˇzovali v kapitole 5, tedy ˇze krátkých tok˚u bude

mal´e mnoˇzstv´ı.

Pokud se na toky pod´ıváme z hlediska sluˇzeb, nenalezneme pˇr´ıliˇs pˇrekvapivé výsledky.

Dominantn´ı sluˇzbou je protokol HTTP, HTTPS. U UDP je to protokol DNS. Co se t´yˇce

pˇrenesen´ych dat, zde je dominantn´ı tunelovac´ı protokol GRE2 _{od firmy Cisco.}

Počet toků u služeb

HTTPS 1.7% HTTP 9.2% ICMP 4.0% DNS 2.7%

rest of 82.3%

Počet bytů u služeb

GRE 2.9% HTTP 1.7% HTTPS 0.4% dynamic ports 1.6% SSH 0.3% rest of 93.1%

Obr´azek 7.3: Statistika jednotliv´ych sluˇzeb

Z následuj´ıc´ıch graf˚u 7.3 se m˚uˇze zdát, ˇze tyto sluˇzby jsou zastoupeny v mizivém

mnoˇzstv´ı. Je tˇreba si ale uvˇedomit, ˇze celkov´e mnoˇzstv´ı port˚u je 65535. Tedy souˇcet

vˇsech ostatn´ıch tok˚u a bajt˚u proud´ıc´ı na ostatn´ı porty je samozˇrejmˇe vˇetˇs´ı. Poloˇzka

dy-2

(27)

namické porty znamená porty od 49152 výˇse. Tyto porty se ve statistice mˇen´ı kaˇzdý den

a pravdˇepodobnˇe to budou vytvoˇren´e tunelovac´ı spoje. To usuzuji za pˇredpokladu, ˇze tyto

dynamické porty maj´ı velice podobný pomˇer poˇctu tok˚u ku pˇreneseným bajt˚um. Jako dalˇs´ı

významná poloˇzka z hlediska poˇctu tok˚u je protokol ICMP. Pˇredpokládám, ˇze vˇetˇsina tˇechto

tok˚u jsou pakety ICMP Echo-Request a Echo-Replay, ale z d˚uvod˚u uveden´ych v kapitole

6 to nelze pˇresnˇe urˇcit. Pokud jsem zkoumal data, kter´a byla k dispozici od firmy Invea,

lze v toc´ıch ICMP pozorovat tak´e hodnˇe paket˚u k´odu 3 - Destination unreachable. Pˇresto

Echo pakety pˇrevaˇzuj´ı.

V tabulce 7.1 lze vidˇet pˇribliˇzn´y pomˇer tok˚u a bajt˚u u nejfrekventovanˇejˇs´ıch sluˇzeb.

Tato statistika je generov´ana za ˇctyˇr hodinov´y provoz v nejfrekventovanˇejˇs´ı denn´ı dobu. Za

tyto ˇctyˇri hodiny bylo v pˇribliˇznˇe 77 mil. toc´ıch pˇreneseno 1,2 TB dat. Lze vidˇet, ˇze pomoc´ı

tunelovac´ıho protokolu se pˇrenáˇs´ı velké mnoˇzstv´ı dat, ale poˇcet tok˚u je velice malý, d´ıky

velice dlouhému trván´ı spojen´ı. U protokolu HTTP je naopak pˇreneseno velké mnoˇzstv´ı

bajt˚u pˇri nˇekolikanásobném mnoˇzstv´ı tok˚u. Proto jsem výˇse usoudil, ˇze dynamické porty,

kter´e se objevuj´ı ve statistik´ach budou pravdˇepodobnˇe dalˇs´ı tunelovac´ı protokoly, jako napˇr.

VPN.

Protokol Poˇcet pˇrenesen´ych bajt˚u Poˇcet tok˚u

GRE 31.6 GB 7694

HTTP 18.4 GB 7.1 mil.

dynamic ports 15 GB 7318

SSH 3.6 GB 20 494

Tabulka 7.1: Pomˇer pˇrenesen´ych byt˚u k poˇctu tok˚u

U skenován´ı se pˇripojuje útoˇcn´ık na jednotlivé porty zaˇr´ızen´ı, které skenuje. Pokud

skenuje napˇr. pomoc´ı z´akladn´ıho nastaven´ı skeneru nmap, testuje u jednoho poˇc´ıtaˇce tis´ıc

port˚u. Bylo by tedy zaj´ımavé zjistit, na kolik port˚u se v reálném provozu pr˚umˇernˇe uˇzivatel

pˇripojuje. Toto lze vidˇet na grafu 7.4. Lze vidˇet, ˇze pr˚umˇernˇe se uˇzivatel pˇripojuje na velice

mal´e mnoˇzstv´ı port˚u. V 80 % pˇr´ıpad˚u je to dokonce pouze jeden port.

1 10 100 1000 10000 100000 1e+06 1e+07 0 200 400 600 800 1000 1200 1400 Če tn os t

Počet navštívených portů

Obr´azek 7.4: Frekvence poˇctu navˇst´ıven´ych port˚u

(28)

vy-tvoˇren z 26,3 mil. tok˚u, ve kterém bylo 2,6 mil. unikátn´ıch IP adres. Poˇcet IP adres, které

vytv´aˇr´ı pouze jeden tok je sice nejvˇetˇs´ı, ale z celkov´eho mnoˇzstv´ı je to pouze okolo 6 %. Je

totiˇz daleko v´ıce IP adres, kter´e maj´ı vˇetˇs´ı mnoˇzstv´ı tok˚u.

1 10 100 1000 10000 100000 1e+06 1e+07 1 10 100 1000 10000 100000 1e+06 Če tn os t Počet toků na IP

(29)

Kapitola 8

Anal´

yza z´ıskan´

ych dat a n´

avrh

aplikace

V pˇredcházej´ıc´ıch kapitolách jsem vytvoˇril ˇradu statistik, které popisuj´ı provoz v s´ıti. Ze

z´ıskaných údaj˚u je nyn´ı nutné vybrat základn´ı prvky, d´ıky kterým bude moˇzno odhalit

skenován´ı i v takto rozsáhlé s´ıti. Dále je nutno zodpovˇedˇet otázky týkaj´ıc´ı se samotné

aplikace. N´asleduje shrnut´ı nejpodstatnˇejˇs´ıch ´udaj˚u.

8.1 Shrnut´ı z´ıskan´

ych statistik

• Unikátn´ı IP adresy: V provozu jsem zjistil velký poˇcet unikátn´ıch IP adres. Bˇeˇznˇe je

to kolem 2 mil. adres za hodinu. Kaˇzd´a adresa se samozˇrejmˇe pˇripojuje v libovoln´y

ˇcas a v z´aznamu se tedy vyskytuje tis´ıce tok˚u se stejnou IP adresou. Pokud bych chtˇel

na z´akladˇe IP adresy toky analyzovat, musel bych pro kaˇzdou IP adresu proj´ıt cel´y

z´aznam.

• Navˇst´ıvené porty: Pokud jsem sledoval pr˚umˇerný poˇcet navˇst´ıvených port˚u u IP

ad-resy, v 80 % pˇr´ıpad˚u je to pouze jeden port. Jak jiˇz bylo zm´ınˇeno, u skenov´an´ı se

´

utoˇcn´ık pˇripojuje k velk´emu mnoˇzstv´ı port˚u nebo k jednomu, ale na velk´em mnoˇzstv´ı

poˇc´ıtaˇc˚u.

• Poˇcet paket˚u v toku: U skenován´ı je vyuˇz´ıváno pˇredevˇs´ım skenován´ı SYN, které

pouˇz´ıv´a pouze jeden paket. Tok˚u, kter´e obsahuj´ı pouze jeden paket, je ale v´ıce neˇz

polovina. Tato situace je tedy podobn´a jako u unik´atn´ıch IP adres.

• Mnoˇzstv´ı dat: Záznamy v hodinových dumpech provozu obsahuj´ı velké mnoˇzstv´ı dat.

Zpracovávat tato data je pak ˇcasovˇe nároˇcné.

Je nutné si uvˇedomit, ˇze i kdyby byla k dispozici velká výpoˇcetn´ı s´ıla a nebyl bych

ome-zen pamˇet´ı apod., analyzovat data delˇs´ı ˇcasový úsek je bezpˇredmˇetné. Skenovac´ı útok ˇcasto

pˇredcház´ı útok jiný a je tedy výhodné na nˇej rychle reagovat a dalˇs´ım útok˚um tak zabránit.

Také je ale d˚uleˇzité si uvˇedomit, ˇze výsledky, zda doˇslo v reálném provozu ke skenován´ı,

nemohu odhalit ihned. Z´aznam NetFlow nem˚uˇze export´er odes´ılat kaˇzdou sekundu, protoˇze

by zahltil s´ıt’. Standardnˇe je pos´ıl´an po pˇeti minut´ach.

Co z výˇse uvedených bod˚u vyplývá? U dat by bylo vhodné se pokusit odfiltrovat ta

data, o kter´ych jsme pˇresvˇedˇceni, ˇze neobsahuj´ı podezˇrelou aktivitu a zmenˇsit tak objem

(30)

skenován´ı nejd˚uleˇzitˇejˇs´ı, je nejv´ıc. Ve vˇetˇsinˇe pˇr´ıpad˚u jsou to totiˇz krátké, nˇekolikapaketové

toky, tedy stejná data, jaká pos´ılaj´ı nástroje pro skenován´ı port˚u. Odfiltrován´ım delˇs´ıch

tok˚u sice zmenˇs´ım ˇcásteˇcnˇe objem, ale 80 % dat mi stejnˇe z˚ustane a ˇreˇs´ım stejný problém.

ˇ

Cas na zpracován´ı dat aplikac´ı mus´ı být pˇrinejhorˇs´ım stejný, jako ˇcas, za který se vytváˇr´ı

záznamy. Pokud jsou záznamy pos´ılány do kolektoru v desetiminutových intervalech, nelze

data zpracovávat déle neˇz 10 minut. Zpracován´ı by ale mˇelo trvat podstatnˇe kratˇs´ı dobu.

Odhalit vˇsechna skenován´ı v s´ıti, která má milióny spojen´ı za hodinu, je nemoˇzné. Pokud

bude ´utoˇcn´ık skenovat pouze nˇekolik poˇc´ıtaˇc˚u a port˚u, je to v takto objemn´ych datech

neodhalitelné. Toto ale ani nen´ı poˇzadavkem. U takto velkých s´ıt´ı je c´ılem odhalit útoˇcn´ıky,

kteˇr´ı provád´ı horizontáln´ı skenován´ı celých pods´ıt´ı, pˇr´ıpadnˇe velké blokové skenován´ı.

Zamˇeˇrme se tedy na horizontáln´ı skenován´ı. Pro toto skenován´ı plat´ı:

• Pouˇz´ıv´a jedno aˇz dvou paketov´e toky

• Skenuje velk´e mnoˇzstv´ı IP adres

• Toky trvaj´ı krátce. Délka skenován´ı závis´ı na poˇctu IP adres.

• Poˇcet bajt˚u je st´ale stejn´y

Protoˇze v hodinovém záznamu o provozu jsem nedokázal efektivnˇe odhalit ˇzádné útoky,

zamˇeˇril jsem se na omezen´ı velikosti zpracovávaných dat. Jak jsem ukázal v kapitole 7,

velký poˇcet tok˚u na IP adresu je relativnˇe malý. Skenován´ı trvá také relativnˇe krátkou

dobu. Za tuto krátkou dobu ale vytvoˇr´ı útoˇcn´ık velké mnoˇzstv´ı tok˚u. Omezil jsem si tedy

hodinový záznam na nejkratˇs´ı rozumný ”pˇetiminutový”záznam. Pokud se v tomto krátkém

ˇ

casovém úseku objev´ı útoˇcn´ık, mˇela by nastat následuj´ıc´ı situace:

1. ´Utoˇcn´ık vytvoˇr´ı velk´e mnoˇzstv´ı spojen´ı. Toto by se mˇelo projevit ve statice tok˚u na

z´akladˇe zdrojov´e IP adresy.

2. Toky útoˇcn´ıka by mˇely vykazovat stejný poˇcet paket˚u, stejný poˇcet byt˚u a krátkou

dobu trv´an´ı.

3. Legitimn´ı uˇzivatelé by nemˇeli podle z´ıskaných statistik vytváˇret velké mnoˇzstv´ı tok˚u.

4. Servery, které obsluhuj´ı hodnˇe klient˚u, vytváˇr´ı také hodnˇe tok˚u. V tˇechto toc´ıch by

ale poˇcet paket˚u mˇel kol´ısat, stejnˇe tak poˇcet pˇrenesen´ych bajt˚u.

Z výˇse uvedených úvah jsem postupoval následuj´ıc´ım zp˚usobem.

1. Z pˇetiminutov´eho toku je vytvoˇrena statistika o nejfrekventovanˇejˇs´ıch IP adres´ach na

z´akladˇe poˇctu tok˚u.

2. U kaˇzdé IP adresy je vyfiltrován záznam o vˇsech jej´ıch toc´ıch v daném ˇcasovém

intervalu.

3. Tento z´aznam je zpracov´an pomoc´ı rozhodovac´ıho algoritmu.

(31)

8.2 Rozhodovac´ı algoritmus

Pro rozhodován´ı, zda daný tok je, nebo nen´ı souˇcást skenován´ı, je vhodné pouˇz´ıt techniky

pro strojové uˇcen´ı a dolovan´ı z dat. Pˇri dolován´ı z dat se zde uplatn´ı hlavnˇe analytická

metodologie, pˇri které se pouˇz´ıvaj´ı rozhodovac´ı stromy, neuronové s´ıtˇe nebo genetické

pro-gramov´an´ı. Pro tuto pr´aci jsem usoudil, ˇze bude nejvhodnˇejˇs´ı pouˇz´ıt rozhodovac´ı strom

generovan´y algoritmem ID31 [16].

Rozhodovac´ı stromy jsou induktivn´ı algoritmy vytvoˇren´e ke klasifikaci instanc´ı. M˚uˇzeme

je pouˇz´ıt, kdyˇz jsou instance pops´any atributy a hodnotami (napˇr. VLHKOST: norm´aln´ı,

vysoká) a c´ılová funkce nabývá diskrétn´ıch hodnost (napˇr. ANO / NE). Trénovac´ı data

mohou obsahovat i chyby a tak´e nemus´ı obsahovat hodnoty vˇsech atribut˚u.

C´ılov´a funkce je reprezentov´ana rozhodovac´ım stromem (sekvenc´ı rozhodnut´ıif-then-else).

Klasifikace se prov´ad´ı pr˚uchodem stromem od koˇrene k list˚um, kdy se testuje hodnota

jed-noho atributu instance pro kaˇzdý uzel. Kaˇzdá hrana odpov´ıdá jedné hodnotˇe. Kaˇzdý list

pak urˇcuje klasifikaci instance.

U ID3 algoritmu vytváˇr´ıme na základˇe trénovac´ıch dat rozhodovac´ı strom. Strom se

vytváˇr´ı od koˇrene. V kaˇzdém uzlu se zjiˇst’uje, který atribut je pro právˇe tento uzel

nej-vhodnˇejˇs´ı. Poˇcet potomk˚u odpov´ıdá poˇctu hodnot vybraného atributu. Trénovac´ı data se

rozdˇel´ı podle pˇr´ısluˇsn´e hodnoty atributu na pˇr´ısluˇsn´e podmoˇziny. Algoritmus pracuje

re-kurzivnˇe v n´asleduj´ıc´ıch kroc´ıch.

Pˇr´ıklad vytvoˇren´eho rozhodovac´ıho stromu m˚uˇzeme vidˇet na obr´azku 8.1. U tohoto

pˇr´ıkladu je strom pouˇzit k rozhodnut´ı, zda mám nebo nemám j´ıt hrát golf.

Předpověď Slunečno Zataženo Déšť Vlhkost Vysoká Normální NE ANO ANO Vítr Silný Slabý NE ANO

Obr´azek 8.1: Pˇr´ıklad rozhodovac´ıho stromu

1

(32)

ID3(Tr´enovac´ı data, C´ılov´y atribut, Atributy)

1. Zaloˇz Koˇrenstromu

2. Pokud jsou vˇsechnaTr´enovac´ı datapozitivn´ı, vytvoˇr jednouzlov´y strom s koˇrenem

oznaˇcen´ym +

3. Jsou-li vˇsechnaTrénovac´ı datanegativn´ı, vytvoˇr jednouzlový strom s koˇrenem oznaˇceným

-4. Je-li mnoˇzina atribut˚uAtributyprázdná, vrat’ jednouzlový strom s koˇrenem oznaˇceným

nejˇcastˇejˇs´ı hodnotou c´ılov´eho atributu v tr´enovac´ıch datech

5. Jinak:

Vyber atribut A, který nejlépe klasifikuje trénovac´ı data,Koˇren = A

5.1 Pro kaˇzdou jeho moˇznou hodnotu vytvoˇr novou vˇetev

5.2 Vytvoˇr Podmnoˇzinavi z tr´enovac´ıch dat, pokud A=vi

5.3 Je-li Podmoˇzinavi prázdná, pod danou vˇetv´ı zaloˇz list stromu oznaˇcený

nejˇcastˇejˇs´ı hodnotou c´ılov´eho atributu v tr´enovac´ıch datech

5.4 Jinak pˇridej pod vˇetev podstromID3(Podmnoˇzinavi, C´ılov´y atribut,Atributy - A)

6. Vrat’ v´ysledn´y podstrom

Výbˇer nejlepˇs´ıho atributu prob´ıhá na základˇe entropie (zisku informace) [7]. Necht’ X je

náhodný jev, jenˇz m˚uˇze nabývat hodnotx1, x2, . . . , xns pravdˇepodobnostmip(x1), p(x2), . . . , p(xn)

a necht’ je

n

X

i=1

p(xi) = 1. Pak entropie jevuX je

H(X) =− n

X

i=1

p(xi) log2p(xi)

Kritérium oˇcekávaného zisku m˚uˇzeme definovat jako m´ıru oˇcekávaného sn´ıˇzen´ı entropie po

rozdˇelen´ı tr´enovac´ıch dat podle hodnoty vybran´eho atributu [23]. Tedy informace, kterou

nám pˇrináˇs´ı znalost hodnoty atributu. Formáln´ı zápis potom ukazuje rovnice 8.1:

Gain(D, A)≡H(D)− X v∈V alues(A)

|Dv|

|D|H(Dv) (8.1)

• A - atribut; A(d) - hodnota atributuA v instancid

• V alues(A) - mnoˇzina vˇsech moˇzn´ych hodnot atributu A

• D- tr´enovac´ı data

(33)

Tr´enovac´ı data

Pro klasifikaci, zda tok je nebo nen´ı souˇcást´ı skenován´ı, jsem vytvoˇril následuj´ıc´ı sadu

pravidel. Popis atribut˚u:

• C´ılov´a IP:

– mal´y rozd´ıl v rozsahu: Tato hodnota znamen´a, ˇze IP adresy jdou postupnˇe

za sebou v jedn´e pods´ıti. Napˇr 10.10.10.1, 10.10.10.2atd.

– stejná: Stejná IP adresa ve dvou po sobˇe následuj´ıc´ıch toc´ıch – rozd´ılná: IP adresa je z rozd´ılných pods´ıt´ı

• C´ılov´y port:

– rozd´ıl <5: Podobnˇe jako u IP adresy tato hodnota atributu urˇcuje, zda porty

jdou postupnˇe za sebou.

– stejný: Porty po dvou po sobˇe jdouc´ıch toc´ıch jsou shodné. – rozd´ılné:Dva po sobˇe jdouc´ı toky maj´ı rozd´ılné porty.

• Poˇcet paket˚u:

– < 5:Tok obsahuje m´enˇe neˇz pˇet paket˚u.

– > 5:Tok obsahuje v´ıce neˇz pˇet paket˚u.

• Poˇcet byt˚u:

– stejný, nebo dvojnásobný nebo poloviˇcn´ı:Tok má stejný, nebo dvojnásobný

nebo poloviˇcn´ı poˇcet bajt˚u jako tok pˇredch´azej´ıc´ı.

– rozd´ıln´y:Rozd´ıln´y poˇcet bajt˚u ve 2 toc´ıch.

C´ılová IP C´ılový port Poˇcet paket˚u Poˇcet bajt˚u Skenován´ı

malý rozd´ıl v rozsahu stejný <5 stejný, nebo 2x nebo 1₂ ANO

stejn´a rozd´ıl <5 <5 stejn´y, nebo 2x nebo 1₂ ANO

rozd´ılná rozd´ılný <5 rozd´ılný NE

stejná rozd´ılný <5 rozd´ılný NE

stejn´a rozd´ıl <5 >5 rozd´ıln´y NE

mal´y rozd´ıl v rozsahu rozd´ıl <5 <5 stejn´y, nebo 2x nebo 1₂ ANO

rozd´ıln´a rozd´ıl <5 >5 rozd´ıln´y NE

rozd´ılná rozd´ılný >5 stejný, nebo 2x nebo 1₂ NE

stejná stejný >5 rozd´ılný NE

malý rozd´ıl v rozsahu rozd´ılný >5 rozd´ılný NE

mal´y rozd´ıl v rozsahu rozd´ıl <5 <5 rozd´ıln´y ANO

stejn´a rozd´ıl <5 <5 rozd´ıln´y ANO

(34)

Z tabulky 8.1 jsem vytvoˇril mnoˇzinu tr´enovac´ıch dat. Algoritmus pro vytvoˇren´ı

rozho-dovac´ıho stromu jsem vytvoˇril v jazyce python. ˇC´asti algoritmu jsou pˇrevzat´e z [18]. Po

vytvoˇren´ı rozhodovac´ıho stromu jsem zjistil, ˇze z hlediska oˇcekávaného zisku jsou d˚uleˇzité

pouze atributyPoˇcet paket˚uaC´ılov´y port. T´ım by ale nebylo moc moˇznost´ı, jak

ovliv-nit ”citlivost”detekce. Doplnil jsem tedy i dalˇs´ı atributy. ˇCást vˇetve výsledného stromu je

na obr´azku 8.2 Pakety IP Porty > 5 NE IP IP Počet bajtů ._. . > 5 rozdíl < 5 = _rozdílný = < 5 rozdílná = _!= . . . . . . . .

. Počet bajtů Počet bajtů

ANO Podezřelé

(35)

Kapitola 9

Implementace

9.1 Popis implementace

Uloˇzená data NetFlow zpracovávám pomoc´ı nˇekolika skript˚u implementovaných pomoc´ı

skriptovac´ıch jazyk˚u Bash a Python. Vytváˇret univerzáln´ı aplikaci je nároˇcné z nˇekolika

hledisek. Data mohou být um´ıstˇena na r˚uzných systémech rozd´ılnˇe. Toto lze ˇcásteˇcnˇe ˇreˇsit

konfiguraˇcn´ım souborem, kde nastav´ıme v´ychoz´ı adres´aˇre. Ty ale mohou m´ıt rozd´ılnou

adresáˇrovou strukturu, rozd´ılný zp˚usob pojmenován´ı, atd. Vytvoˇril jsem nˇekolik skript˚u,

které spojuji do vˇetˇs´ıho celku. D˚uvodem, proˇc jsem vytváˇrel malé, jednoúˇcelové skripty, je

vˇetˇs´ı univerzálnost. Data z páteˇrn´ı s´ıtˇe VUT tvoˇr´ı záznamy hodinového provozu. Tyto

záznamy potˇrebuji rozdˇelit na pˇetiminutové, ale jiné systémy mohou ukládat data jiˇz

v poˇzadovaném ˇcasovém rozsahu. Proto m˚uˇze být vˇetˇsina skript˚u vynechána a správce

pouˇzije pouze ty, kter´e potˇrebuje pro analyzov´an´ı dat. Sadu skript˚u jsem tedy vytvoˇril

s ohledem na univerzálnost, ale primárnˇe pro zpracován´ı dat ze s´ıtˇe VUT. Pro zpracován´ı

na jin´ych syst´emech bude pravdˇepodobnˇe potˇreba je pˇrekonfigurovat, pˇr´ıpadnˇe pˇrizp˚usobit.

Data na serveru VUT jsou uloˇzena v této adresáˇrové struktuˇre:

/data/netflow/CESNET.anonymized/yyyy-mm-dd/nfcapd.yyyymmddhhmm

kde yyyy = rok, mm = mˇes´ıc, dd = den, hh = hodina(24h/den), mm = minuta. Tyto

soubory jsou hodinové záznamy provozu. Nejdˇr´ıve je nutné je rozdˇelit na pˇetiminutové

z´aznamy.

Pˇr´ıklad rozdˇelen´ı hodinov´eho souboru na pˇetiminutov´y.

nfdump -r /cesta/netflow -t 2009/01/01.00:00:00-2009/01/01.00:04:59 \

-w /kam/ulozit/2009-01-01.00-05

• -r: urˇcuje zdroj NetFlow dat

• -t: filtruje data pouze podle ˇcasov´eho okna zadan´eho jako parametr

• -w: soubor ukládá jako NetFlow záznam do poˇzadovaného adresáˇre (v základn´ım

nastaven´ı jsou záznamy vypsány na standardn´ı výstup a nemohou být zpracována

znovu pomoc´ı n´astrojenfdump)

Schéma volán´ı skript˚u je na obrázku 9.1.

Pro rozdˇelen´ı hodinových záznam˚u NetFlow slouˇz´ı skript split.sh. Pomoc´ı nástroje