Network Protection Using NetFlow Data

Full text

(1)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV PO ˇ

C´ITA ˇ

COV ´

YCH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

OCHRANA DATOV ´

E S´IT ˇ

E S VYU ˇ

ZIT´IM NETFLOW DAT

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

JAKUB ˇ

CEGAN

(2)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV PO ˇ

C´ITA ˇ

COV ´

YCH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

OCHRANA DATOV ´

E S´IT ˇ

E S VYU ˇ

ZIT´IM NETFLOW DAT

NETWORK PROTECTION USING NETFLOW DATA

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

JAKUB ˇ

CEGAN

AUTHOR

VEDOUC´I PR ´

ACE

Ing. JI ˇ

R´I TOBOLA

SUPERVISOR

(3)

Abstrakt

Tato pr´ace popisuje zabezpeˇcen´ı datov´e s´ıtˇe pomoc´ı technologie NetFlow. V ´uvodu jsou pops´any nˇekter´e moˇzn´e hrozby, kter´e mohou datovou s´ıt’ postihnout a kter´e jsou rozpoz-nateln´e pomoc´ı NetFlow dat. V dalˇs´ı ˇc´asti pr´ace jsou navrˇzena urˇcit´a detekˇcn´ı pravidla a dvoukrokov´y zp˚usob detekce pomoc´ı jejich pouˇzit´ı. Tato pravidla byla formulov´ana na z´akladˇe pozorov´an´ı a experiment˚u v datov´e s´ıti.

Abstract

This thesis deals with the using of NetFlow data for computer network protection. First are described some types of network security threats. After study of these threats and many experiments were designed detection rules for them. New detection form were designed too. It is working with two step detection of threats.

Kl´ıˇ

cov´

a slova

NetFlow, detekce, ochrana datov´e s´ıtˇe, BitTorrent, skenov´an´ı, DDoS ´utok

Keywords

NetFlow, detection, Network Protection, BitTorrent, Scans, DDoS attack

(4)

Ochrana datov´

e s´ıtˇ

e s vyuˇ

zit´ım NetFlow dat

Prohl´

sen´ı

Prohlaˇsuji, ˇze jsem tuto bakal´aˇrskou pr´aci vypracoval samostatnˇe pod veden´ım pana Ing. Jiˇr´ıho Toboly. Dalˇs´ı informace mi poskytl RNDr. Pavel Minaˇr´ık.

. . . . Jakub ˇCegan 18. kvˇetna 2009

Podˇ

ekov´

an´ı

R´ad bych podˇekoval vedouc´ımu sv´e pr´ace Ing. Jiˇr´ımu Tobolovi za ˇcas vˇenovan´y konzultac´ım t´eto pr´ace a za to, ˇze mi umoˇznil pˇr´ıstup k poˇc´ıtaˇcov´e s´ıti, kde prov´adˇel sv´e testy. Tak´e bych r´ad podˇekoval RNDr. Pavlu Minaˇr´ıkovi za jeho ˇcas str´aven´y se mnou pˇri pro mne d˚uleˇzit´ych konzultac´ıch s podnˇetnou diskuz´ı. V neposledn´ı ˇradˇe m´e podˇekov´an´ı patˇr´ı Ing. Janu Pazderovi za pomoc pˇri spr´avˇe testovac´ıho stroje.

c

Jakub ˇCegan, 2009.

Tato pr´ace vznikla jako ˇskoln´ı d´ılo na Vysok´em uˇcen´ı technick´em v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Pr´ace je chr´anˇena autorsk´ym z´akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´ a-vnˇen´ı autorem je nez´akonn´e, s v´yjimkou z´akonem definovan´ych pˇr´ıpad˚u.

(5)

Obsah

1 Uvod´ 3

2 Bezpeˇcnost datov´ych s´ıt´ı 4

2.1 Firewall . . . 4

2.1.1 Paketov´e filtry . . . 4

2.1.2 Stavov´e filtry . . . 4

2.1.3 Firewally aplikaˇcn´ı vrstvy . . . 4

2.2 Intrusion detection system (IDS) . . . 5

2.3 Intrusion prevention system (IPS) . . . 5

2.4 Honeypot . . . 6

2.5 SNMP protokol . . . 6

2.6 Antispamov´a ochrana . . . 6

2.6.1 Filtrace dle odesilatele . . . 6

2.6.2 Filtrace dle obsahu zpr´avy . . . 7

3 Monitorov´an´ı provozu na z´akladˇe s´ıt’ov´ych tok˚u 8 3.1 Uvod do NetFlow´ . . . 8

3.2 Software pro zpracov´an´ı NetFlow dat. . . 9

3.2.1 NfDump a NfSen . . . 10

3.3 Statistick´e metody detekce anom´ali´ı . . . 11

3.4 Detekce pomoc´ı pravidel . . . 11

4 Hrozby pro datovou s´ıt’ 13 4.1 Skenov´an´ı port˚u . . . 13

4.1.1 TCP SYN sken . . . 13

4.1.2 FIN sken, Xmas sken a Null sken . . . 13

4.2 Detekce malware . . . 14

4.3 Utok na SSH´ . . . 15

4.4 Utok odepˇ´ ren´ım sluˇzby. . . 15

4.4.1 HTTP flood. . . 16

4.5 Instant Messengery . . . 17

4.5.1 Protokol OSCAR . . . 18

4.5.2 Protokol XMPP . . . 18

4.6 Detekce Instant Messengeru . . . 18

4.6.1 Obecn´a detekce Instant Messengeru . . . 18

(6)

5 Z´avˇer 23

(7)

Kapitola 1

´

Uvod

V dneˇsn´ı dobˇe doch´az´ı k neust´al´emu rozvoji datov´ych s´ıt´ı. Dramaticky se zvyˇsuje jejich poˇcet a velikost. Doch´az´ı tak´e k masivn´ımu n´ar˚ustu rychlosti s´ıt´ı. S rozˇs´ıˇrov´an´ım datov´ych s´ıt´ı roste potˇreba jejich ochrany pˇred snahami o naruˇsen´ı jak z vnˇejˇs´ıho svˇeta, tak od uˇzivatel˚u uvnitˇr sledovan´e s´ıtˇe. Je tˇreba ´uˇcinnou formou prosazovat z´akony vztahuj´ıc´ı se na chov´an´ı v datov´e s´ıti a tak´e na data, kter´a se v n´ı nach´azej´ı. Je tedy nezbytn´e neust´ale kontrolovat dˇen´ı v s´ıti, a sledovat jestli nedoch´az´ı k protipr´avn´ımu jedn´an´ı. Na druhou stranu je ovˇsem nutn´e dodrˇzovat pr´avo na soukrom´ı uˇzivatel˚u.

Vzhledem ke zrychlov´an´ı s´ıt´ı a zvˇetˇsov´an´ı objemu dat jimi prot´ekaj´ıc´ıch je zpracov´av´an´ı kaˇzd´eho paketu velmi n´aroˇcn´e a v koneˇcn´em d˚usledku mohou bˇeˇzn´a monitorovac´ı zaˇr´ızen´ı s´ıt’ zbyteˇcnˇe zatˇeˇzovat a st´at se tak jej´ım ´uzk´ym hrdlem. Zabezpeˇcen´ı takov´e datov´e s´ıtˇe pomoc´ı NetFlow umoˇzˇnuje v pˇr´ıpadˇe pouˇzit´ı pasivn´ıch sond sledovat provoz v s´ıti bez toho, aniˇz by byla s´ıt’ zbyteˇcnˇe zatˇeˇzov´ana.

Tato technologie m˚uˇze b´yt vyuˇzita poskytovateli internetu pro zajiˇstˇen´ı ´uˇctovatelnosti poskytovan´ych dat a dohledu nad dodrˇzov´an´ım podm´ınek stanovan´ych smlouvou. Stejnˇe tak mohou b´yt NetFlow data pouˇzita v IT oddˇelen´ıch velk´ych firem k monitorov´an´ı ko-munikace v jejich vnitˇrn´ı s´ıti. Pomoc´ı statistick´e anal´yzy je moˇzn´e vytvoˇrit profily jed-notliv´ych uˇzivatel˚u a sledovat tak jejich chov´an´ı bez naruˇsen´ı jejich soukrom´ı. D´ale je moˇzn´e zabezpeˇcit s´ıt’ pˇred ´uniky dat, napaden´ım DoS a DDoS ´utoky a pˇred ˇs´ıˇren´ım ileg´aln´ıch dat. Pˇredmˇetem t´eto pr´ace je vypracov´an´ı n´ahledu na bezpeˇcnost datov´e s´ıtˇe skrze pouˇzit´ı technologie NetFlow. V prvn´ı ˇc´asti je struˇcnˇe nast´ınˇen pohled na dnes bˇeˇznˇe pouˇz´ıvan´a zabezpeˇcen´ı datov´e s´ıtˇe. V n´asleduj´ıc´ı kapitole je rozebr´ano monitorov´an´ı poˇc´ıtaˇcov´e s´ıtˇe pomoc´ı technologie NetFlow. Je zde nast´ınˇen struˇcn´y ´uvod do NetFlow protokolu a tak´e je zde uveden pˇrehled program˚u a jejich funkc´ı pro pr´aci s daty se zamˇeˇren´ım na program pouˇzit´y v t´eto pr´aci. Pot´e n´asleduje rozbor nˇekolika hrozeb pro datovou s´ıt’ s ohledem na jejich projevy v NetFlow datech s uveden´ymi moˇznostmi jejich detekce. Posledn´ı ˇc´ast´ı pr´ace je rozbor dosaˇzen´ych v´ysledk˚u a nast´ınˇen´ı moˇznost pokraˇcov´an´ı v pr´aci.

(8)

Kapitola 2

Bezpeˇ

cnost datov´

ych s´ıt´ı

2.1

Firewall

Firewall je aplikace, ˇci s´ıt’ov´e zaˇr´ızen´ı umoˇzˇnuj´ıc´ı zabezpeˇcen´ı pˇred hrozbami pˇrich´azej´ıc´ımi do d˚uvˇeryhodn´e vnitˇrn´ı s´ıtˇe z ned˚uvˇeryhodn´e s´ıtˇe vnˇejˇs´ı. Jedn´a se o bod na pˇr´ıstupov´e lince nebo link´ach, pˇres kter´y proch´az´ı veˇsker´a komunikace mezi s´ıtˇemi. V tomto m´ıstˇe doch´az´ı ke kontrole dle zadan´e bezpeˇcnostn´ı politiky a k propouˇstˇen´ı, pˇr´ıpadnˇe zam´ıt´an´ı spojen´ı. Pouˇzit´e technologie firewallu je moˇzn´e rozdˇelit podle doby vzniku a pˇr´ıstupu k probl´emu do tˇr´ı n´ıˇze popsan´ych kategori´ı [17].

2.1.1 Paketov´e filtry

Paketov´e filtry jsou prvn´ım a nejstarˇs´ım druhem firewallu. Funguj´ı na principu aplikace pravidel pro povolen´ı nebo zak´az´an´ı kaˇzd´eho spojen´ı proch´azej´ıc´ıho firewallem. Tato s´ıt’ov´a spojen´ı jsou identifikov´ana dle zdrojov´e a c´ılov´e ip adresy, ˇc´ısel port˚u a protokolu. V´yhodou tohoto typu firewallu je rychlost pr´ace s daty.

Z´asadn´ı nev´yhodou pak je bezstavovost, tedy nemoˇznost rozhodnout, zda paket patˇr´ı k nˇejak´emu jiˇz existuj´ıc´ımu spojen´ı [1].

2.1.2 Stavov´e filtry

Stavov´e filtry funguj´ı obdobnˇe jako paketov´e filtry, ovˇsem s pˇridanou funkcionalitou ukl´ad´an´ı povolen´ych spojen´ıch. Tato schopnost umoˇzˇnuje firewallu rozhodnout, zda je pˇr´ıchoz´ı paket souˇc´ast´ı jiˇz existuj´ıc´ıho spojen´ı, nebo se jedn´a o nov´e spojen´ı a je tedy tˇreba o nˇem teprve rozhodnout.

V´yhodou stavov´ych filtr˚u je vyˇsˇs´ı rychlost a bezpeˇcnost neˇz u pˇredchoz´ıch paketov´ych firewall˚u.

2.1.3 Firewally aplikaˇcn´ı vrstvy

Tyto firewally tak´e naz´yvan´e proxy firewally vznikly jako posledn´ı. Jak jiˇz n´azev napov´ıd´a, pracuj´ı na sedm´e vrstvˇe ISO/OSI modelu [1]. Doch´az´ı zde k ´upln´emu oddˇelen´ı spojen´ı, protoˇze se zde oba poˇc´ıtaˇce pˇr´ımo nepropojuj´ı. Nejdˇr´ıve je nav´az´ano spojen´ı z poˇc´ıtaˇce ini-cializuj´ıc´ıho komunikaci s proxy firewallem. Pot´e, pokud je spojen´ı povoleno, dojde k propo-jen´ı z firewallu na c´ılov´y poˇc´ıtaˇc a data jsou pˇred´ana v p˚uvodn´ı podobˇe. Vzhledem k principu spojen´ı tyto firewally tak´e funguj´ı jako pˇrekladaˇce s´ıt’ov´ych adres (NAT).

(9)

V´yhodou tohoto pˇr´ıstupu je vysok´y stupeˇn ochrany s´ıtˇe. Nev´yhodou jsou vysok´e n´aroky na hardware firewallu a relativn´ı pomalost oproti v´yˇse uveden´ym pˇr´ıstup˚um.

2.2

Intrusion detection system (IDS)

Jedn´a se o softwarov´y ˇci hardwarov´y syst´em pro detekci neˇz´adouc´ıho chov´an´ı v datov´e s´ıti. Syst´em dok´aˇze sledovat obsah paket˚u a tak odhalit pokus o naruˇsen´ı bezpeˇcnosti pˇrich´azej´ıc´ı jak z vnˇejˇs´ıho prostˇred´ı, typicky internetu, tak i zevnitˇr s´ıtˇe. Jeho hlavn´ımi ´ukoly jsou pˇredevˇs´ım detekce ´utok˚u proti zraniteln´ym sluˇzb´am a aplikac´ım, detekce pokusu o z´ısk´an´ı pˇr´ıstupov´ych pr´av k syst´em˚um a v neposledn´ı ˇradˇe detekce malwaru, tj. trojsk´ych kon´ı, vir˚u a ˇcerv˚u. Syst´emy pro detekci vniknut´ı je moˇzn´e rozdˇelit do n´asleduj´ıc´ıch dvou z´akladn´ıch kategori´ı [14]:

Network intrusion detection system (NIDS) Senzory NIDS b´yvaj´ı um´ıstˇeny u vstup-n´ıch bod˚u do poˇc´ıtaˇcov´e s´ıtˇe, pˇr´ıpadnˇe u vstupu do demilitarizovan´e z´ony t´eto s´ıtˇe. Doch´az´ı zde k zachycov´an´ı veˇsker´eho s´ıt’ov´eho provozu a vyhled´av´an´ı neˇz´adouc´ıch projev˚u. Detekce je zaloˇzena na hled´an´ı vzork˚u v paketech uveden´ych v datab´azi syst´emu jako pˇr´ıznaˇcn´e pro ´utok, nebo odhalov´an´ı neobvykl´e aktivity paket˚u, kter´a je pˇr´ıznakem prob´ıhaj´ıc´ıho ´utoku [14].

Host intrusion detection system (HIDS) HIDS se od v´yˇse uveden´ych NIDS liˇs´ı t´ım, ˇze jsou vˇzdy instalov´any na urˇcit´y poˇc´ıtaˇc a zajiˇst’uj´ı nad n´ım nepˇretrˇzit´y dohled. Ne-doch´az´ı zde ke sledov´an´ı paket˚u, ale dle projev˚u chov´an´ı jednotliv´ych uˇzivatel˚u syst´em zjiˇst’uje, jestli nedoch´az´ı k naruˇsen´ı bezpeˇcnosti. M˚uˇze se jednat o pokusy o pˇrihl´aˇsen´ı do syst´emu neautorizovan´ymi uˇzivately, ˇci krajnˇe podezˇrel´e chov´an´ı opr´avnˇen´ych uˇzivatel˚u.

Nev´yhodou IDS je, ˇze pˇri rychlostech linky kolem 1Gb/s a v´yˇse, jiˇz pˇrest´avaj´ı tyto syst´emy zvl´adat zpracov´an´ı obrovsk´eho mnoˇzstv´ı proch´azej´ıc´ıch paket˚u a st´avaj´ı se tak ´uzk´ym hrdlem. Pouˇzitelnost IDS na vysoko rychlostn´ıch link´ach je moˇzn´e zajistit pomoc´ı jejich hardwarov´e akcelerace [26]. Vych´az´ı se zde z pˇredpokladu, ˇze vˇetˇsina paket˚u patˇr´ı le-gitimn´ımu provozu a jsou tud´ıˇz neˇskodn´e. Pakety jsou na ´urovni hardwaru porovn´av´any s datab´az´ı nez´avadn´ych paket˚u. V pˇr´ıpadˇe shody jsou zahozeny a do IDS se tedy dostanou pouze pakety potencion´alnˇe patˇr´ıc´ı k ´utoku.

2.3

Intrusion prevention system (IPS)

V tomto pˇr´ıpadˇe se jedn´a o rozˇs´ıˇren´ı jiˇz dˇr´ıve zm´ınˇen´eho syst´emu IDS. IPS dok´aˇze nejen ´

utoky detekovat, ale tak´e narozd´ıl od jeho pˇredch˚udce, se jim tak´e aktivnˇe br´anit. Tuto obranu proti ´utok˚um zajiˇst’uj´ı dvˇe r˚uzn´e techniky. Prvn´ı je zruˇsen´ı prob´ıhaj´ıc´ı komunikace pomoc´ı odesl´an´ı TCP paketu s nastaven´ym pˇr´ıznakem RST, pˇr´ıpadnˇe zasl´an´ı ICMP zpr´avy Unreachable ´utoˇcn´ıkovi [14] a t´ım ukonˇcen´ı prob´ıhaj´ıc´ıho spojen´ı. Tato metoda m´a anglick´y n´azev sniping. Druhou technikou je naˇr´ızen´ı vstupn´ımu firewallu nebo smˇerovaˇci, aby zaˇcal odm´ıtat detekovanou z´avadnou komunikaci (shunning) [14]. IPS se dˇel´ı na Host intrusion prevention system (HIPS) a Network intrusion prevention system (NIPS) dle podobn´e logiky jako IDS.

(10)

2.4

Honeypot

Honeypot, neboli n´avnada je souˇc´ast´ı zabezpeˇcen´ı datov´e s´ıtˇe, kter´a m´a za ´ukol odl´akat ´

utoˇcn´ıka od skuteˇcn´ych syst´em˚u a sv´est jej na faleˇsnou stopu. Vˇetˇsinou b´yv´a um´ıstˇena v demilitarizovan´e z´onˇe s´ıtˇe. Dalˇs´ım ´ukolem n´avnady b´yv´a sbˇer informac´ı o ´utoˇcn´ıc´ıch a jejich technik´ach. Tyto informace jsou pot´e vyuˇzity pro vylepˇsov´an´ı technik obrany pˇred ´

utoky a v pˇr´ıpadˇe pˇred´an´ı incidentu org´an˚um ˇcinn´ym v trestn´ım ˇr´ızen´ı mohou poslouˇzit jako d˚ukazn´ı materi´al. N´avnady se dˇel´ı dle sv´e funkce a sloˇzitosti proveden´ı na tˇri typy [14]:

Monitory port˚u Jedn´a se o nejjednoduˇsˇs´ı typ n´avnady. Poslouchaj´ı na portech ˇcasto vyhled´avan´ych ´utoˇcn´ıky a umoˇzˇnuj´ı jejich pˇripojen´ı. Pokusy o pˇripojen´ı pot´e zazna-men´avaj´ı.

Faleˇsn´e syst´emy Faleˇsn´e syst´emy jdou o krok d´ale neˇz Monitory port˚u. Pˇredst´ıraj´ı, ˇze se jedn´a o plnohodnotn´y syst´em se vˇsemi nezbytnˇe nutn´ymi projevy takov´eho syst´emu a zvyˇsuj´ı tak ˇsanci, ˇze ´utoˇcn´ık uvˇeˇr´ı, ˇze se jedn´a o skuteˇcn´y syst´em a zah´aj´ı ´utok.

N´asobn´e faleˇsn´e syst´emy Jedn´a se o dalˇs´ı rozveden´ı myˇslenky n´avnad. N´asobn´e faleˇsn´e syst´emy umˇej´ı kromˇe pˇredst´ır´an´ı nˇekolika r˚uzn´ych sluˇzeb tak´e pˇredst´ırat r˚uzn´e ope-raˇcn´ı syst´emy.

2.5

SNMP protokol

Protokol SNMP, cel´ym n´azvem Simple Network Management Protocol, je standardizo-van´ym protokolem slouˇz´ıc´ım pro spr´avu poˇc´ıtaˇcov´e s´ıtˇe. K transportu dat pouˇz´ıv´a protokol UDP. Od verze 3 SNMP podporuje tak´e autentizaci a ˇsifrov´an´ı. Umoˇzˇnuje sbˇer d˚uleˇzit´ych dat a jejich n´asledn´e vyhodnocen´ı. V tomto protokolu vystupuj´ı dvˇe entity a to Agent a Manager. Agent pˇr´ıj´ım´a poˇzadavky od Managera a pos´ıl´a mu zpˇet posb´ıran´a dat. Manager pˇr´ıj´ım´a data od a Agent˚u, kter´a pot´e ukl´ad´a a n´aslednˇe zpracov´av´a.

2.6

Antispamov´

a ochrana

Existuje mnoho druh˚u spamu, ale pro ´uˇcely t´eto pr´ace je term´ınem Spam m´ınˇen spam ˇs´ıˇren´y pomoc´ı email˚u. Spam je jedn´ım ze z´asadn´ıch probl´em˚u dneˇsn´ıho internetu. Nˇekter´e zdroje uv´adˇej´ı, ˇze aˇz 79% veˇsker´e emailov´e komunikace je spam [4]. Naprostou vˇetˇsinu z nˇej maj´ı na svˇedom´ı poˇc´ıtaˇce nedobrovolnˇe zapojen´e ve velk´ych s´ıt´ıch, zvan´ych botnety [9]. Ochrana proti spamu je moˇzn´a na v´ıce ´urovn´ıch. Pro tuto pr´aci je d˚uleˇzit´y zp˚usob zabraˇnuj´ıc´ı pˇrijet´ı jiˇz odeslan´ych spam˚u.

2.6.1 Filtrace dle odesilatele

Blacklisting Blacklisting je jednoduch´y zp˚usob filtrov´an´ı spamu, zaloˇzen´y na d˚uvˇ ery-hodnosti adresy odesilatele nebo jeˇstˇe l´epe na d˚uvˇeryhodnosti ip adresy poˇstovn´ıho serveru. Pokud bylo zaznamen´ano ˇs´ıˇren´ı spamu z urˇcit´eho serveru, pak je jeho adresa pˇrid´ana do Blacklistu a emaily pˇr´ıch´azej´ıc´ı z n´ı jsou bud’ pˇr´ımo odm´ıtnuty nebo oznaˇceny jako spam.

Greylisting Jedn´a se vylepˇsen´ı Blacklistingu pomoc´ı dynamick´eho chov´an´ı. Prvn´ı pˇr´ıchoz´ı zpr´ava z emailov´eho serveru je pozdrˇzena a serveru je vr´acena informace o nemoˇznosti

(11)

ji doˇcasnˇe doruˇcit. Pokud dojde k opˇetovn´emu pokusu doruˇcit zpr´avu, filtr ji propust´ı a server je na urˇcitou dobu oznaˇcen jako d˚uvˇeryhodn´y. Dalˇs´ı zpr´avy jiˇz proch´azej´ı po dobu trv´an´ı d˚uvˇery bez zdrˇzen´ı. Po uplynut´ı nastaven´e doby, po kterou je server oznaˇcen jako d˚uvˇeryhodn´y, se proces opakuje. Je zde vyuˇzito faktu, ˇze spam roboti se emaily vˇetˇsinou nepokouˇsej´ı znovu doruˇcit.

2.6.2 Filtrace dle obsahu zpr´avy

Filtrace pomoc´ı pravidel Tento postup je zaloˇzen na filtraci spamu dle pro nˇej charak-teristick´ych vlastnost´ı. Mezi tyto vlastnosti patˇr´ı napˇr´ıklad typick´a kl´ıˇcov´a slova nebo slovn´ı spojen´ı. V z´avislosti na poˇctu splnˇen´ych krit´eri´ı je pot´e zpr´ava pˇr´ıpadnˇe oznaˇcena jako spam.

Bayesovsk´e filtry Tyto filtry jsou zaloˇzeny na uˇcen´ı a umˇel´e inteligenci [10]. Filtr˚um jsou pˇredkl´ad´any emaily oznaˇcen´e jako spam anespam(ham), pomoc´ı kter´ych se uˇc´ı obsah nevyˇz´adan´ych zpr´av. Pˇri vlastn´ı pr´aci je filtru pˇredloˇzen obsah emailu a n´aslednˇe je dle nauˇcen´ych pravidel rozhodnuto o jeho osudu.

(12)

Kapitola 3

Monitorov´

an´ı provozu na z´

akladˇ

e

s´ıt’ov´

ych tok˚

u

3.1

Uvod do NetFlow

´

NetFlow je otevˇren´y protokol pro pˇrenos informac´ı o toc´ıch v datov´e s´ıti p˚uvodnˇe vyvinut´y spoleˇcnost´ı Cisco Systems jako doplˇnkov´a sluˇzba pro jejich smˇerovaˇce. Definici toku (flow) v NetFlow lze vyj´adˇrit tak, ˇze se jedn´a o jednosmˇernou posloupnost paket˚u se shodnou zdro-jovou a c´ılovou ip adresou, zdrojov´ym a c´ılov´ym portem, protokolem (TCP, UDP, ICMP, IGMP), ToS a ˇc´ıslem rozhran´ı [11]. V NetFlow datech jsou zaneseny veˇsker´e informace o spojen´ı, doba jeho vzniku, d´elka trv´an´ı, poˇcet pˇrenesen´ych paket˚u a byt˚u a dalˇs´ı ´udaje. Nen´ı zde vˇsak uloˇzen vlastn´ı obsah paket˚u.

Tradiˇcn´ı architektura dle spoleˇcnosti Cisco dˇr´ıvˇe vypadala tak, ˇze smˇerovaˇce v s´ıti kromˇe sv´e bˇeˇzn´e funkce tak´e sb´ıraly NetFlow data a poˇc´ıtaly z nich statistiky. Takov´a architektura ovˇsem pˇri vˇetˇs´ım provozu zp˚usobovala velk´e vyt´ıˇzen´ı smˇerovaˇc˚u a to aˇz do t´e m´ıry, ˇze mohlo doj´ıt k omezen´ı jejich prim´arn´ı funkce. Proto se pˇristoupilo k pouˇzit´ı specializovan´eho hardwaru, tzv. pasivn´ıch sond. Tyto sondy je moˇzn´e zapojit do libovoln´eho m´ısta v s´ıt´ı. Nejˇcastˇeji se jedn´a o pˇr´ıstupov´e linky do s´ıtˇe, pˇr´ıpadnˇe jej´ı kl´ıˇcov´e uzly. Sondy data pˇres nˇe proch´azej´ıc´ı pouze monitoruj´ı a nijak do nich nezasahuj´ı, proto se naz´yvaj´ı pasivn´ı. Statistiky jsou pot´e odes´ıl´any oddˇelenou linkou do kolektoru a ve sledovan´em provozu se tedy v˚ubec neprojev´ı. Z tohoto d˚uvodu je velmi sloˇzit´e sondy odhalit a jsou tedy obt´ıˇzn´ym c´ılem pro ´utoˇcn´ıky. Dvˇe podstatn´e ˇc´asti NetFlow architektury jsou naz´yv´any Export´er a Kolektor.

Export´er Jak jiˇz bylo v´yˇse uvedeno, jedn´a se bud’ o pasivn´ı sondu, router nebo soft-warovou implementaci [11]. Pˇr´ıchoz´ı paket je Export´erem pˇrijat a jsou z nˇej extra-hov´any poˇzadovan´e informace. Pot´e je vyhled´ano, zda paket patˇr´ı do jiˇz existuj´ıc´ıho flow, kter´e je aktualizov´ano, nebo je zaloˇzeno flow nov´e [11].

Kolektor Kolektor je zaˇr´ızen´ı s velkou ´uloˇznou kapacitou, jeˇz sb´ır´a data z nˇekolika ex-port´er˚u. Nad datov´ym ´uloˇziˇstˇem vˇetˇsinou bˇeˇz´ı aplikace umoˇzˇnuj´ıc´ı operace s NetFlow daty. Mezi bˇeˇzn´e operace patˇr´ı filtrov´an´ı tok˚u na z´akladˇe pravidel, agregace tok˚u dle zadan´ych krit´eri´ı a zobrazov´an´ı dat.

Prvn´ı masovˇe pouˇzitou verz´ı NetFlow protokolu byla verze 5. Protokol verze 9 m´a na rozd´ıl od pˇredchoz´ıch verz´ı svou strukturu danou ˇsablonou. Hlavn´ı v´yhodou tohoto pˇr´ıstupu je, ˇ

(13)

z´aznam ip adres ve form´atu IPv6 a je tak pamatov´ano na pˇripravovanou zmˇenu po vyˇcerp´an´ı adres IPv4. Obr´azek3.1zachycuje hlaviˇcku NetFlow paketu v9. Na z´akladˇe protokolu verze 9 vznikl nov´y prototokol Internet Protocol Information Export (IPFIX). Jedn´a se de facto o NetFlow verze 10, kter´e bylo prohl´aˇseno za nov´y IETF standard [12], aby doˇslo ke sjed-nocen´ı r˚uzn´ych metod pouˇz´ıvan´ych k pr´aci s ip flow.

Obr´azek 3.1: Hlaviˇcka NetFlow paketu v9 [19]

Hlavn´ı v´yhodou, kter´a hovoˇr´ı pro pouˇzit´ı NetFlow, je fakt, ˇze tato technologie je schopna fungovat i na s´ıt´ıch o rychlostech 10 Gb/s a na s´ıt´ıch s velk´ym provozem, kde by bylo nasazen´ı jin´ych technologi´ı nemoˇzn´e nebo velmi obt´ıˇzn´e. Pomoc´ı informac´ı z´ıskan´ych z Net-Flow dat je moˇzn´e tvoˇrit t´emˇeˇr libovoln´e statistiky. Na z´akladˇe tˇechto statistik je moˇzn´e tvoˇrit profily chov´an´ı jednotliv´ych stroj˚u zapojen´ych do s´ıtˇe a pˇri zjiˇstˇen´e odchylce spustit poplach. Silnou str´ankou NetFlow je tak´e jeho imunita proti ˇsifrovan´emu provozu, kter´a vych´az´ı ze skuteˇcnosti, ˇze nen´ı pracov´ano s obsahem paket˚u, ale s chrakteristikou jed-notliv´ych datov´ych tok˚u.

3.2

Software pro zpracov´

an´ı NetFlow dat

Na v´yvoj aplikac´ı pro pr´aci s NetFlow daty se dnes soustˇred´ı mnoho spoleˇcnost´ı. Jedn´a se bud’ o komplexn´ı komerˇcn´ı ˇreˇsen´ı od renomovan´ych firem, jako je Hewlett Packard nebo IBM a nebo je moˇzn´e nal´ezt na internetu nˇekolik velmi dobr´ych kompletn´ıch open source ˇreˇsen´ı. D´ale lze nal´ezt mnoho program˚u pro anal´yzu NetFlow dat a grafick´ych rozhran´ı pro kolektory. Struˇcn´y pˇrehled dostupn´ych softwar˚u lze shl´ednout v pˇriloˇzen´e tabulce 3.1. Podrobnˇejˇs´ı informace je moˇzn´e naj´ıt na n´asleduj´ıc´ım odkazu [20].

Mezi nejzaj´ımavˇejˇs´ı z v´yˇse uveden´ych aplikac´ı patˇr´ı d´ıky sv´ym vlastnostem n´asleduj´ıc´ı programy:

Peak Flow Tento komerˇcn´ı produkt spoleˇcnosti Arbor Networks umoˇzˇnuje bˇeˇzn´y sbˇer a anal´yzu NetFlow dat. V oblasti bezpeˇcnosti je zamˇeˇren na zjiˇst’ov´an´ı p2p s´ıt´ı, moni-torov´an´ı messenger˚u a odhalov´an´ı DDoS ´utok˚u.

StealthWatch Reˇˇ sen´ı od spoleˇcnosti Lancope, technologick´eho partnera Cisco Systems, vyuˇz´ıv´a pro svou detekci bezpeˇcnostn´ıch rizik statistickou anal´yzu NetFlow dat.

(14)

Produkt V´yrobce Licence

NetFlow Monitor Cesnet freeware StealthWatch Lancope komerˇcn´ı NfSen, NfDump Peter Haag, SWITCH freeware

Flow Tools Splintered freeware PeakFlow Arbor Networks komerˇcn´ı Flow Viewer NASA freeware NetFlow Insight Hewlett Packard komerˇcn´ı

Aurora IBM komerˇcn´ı NetFlow Analyzer AdventNet komerˇcn´ı NTOP Ethereal freeware

Tabulka 3.1: Struˇcn´y pˇrehled softwaru pro pr´aci s NetFlow daty

Flow Tools Jedn´a se o bal´ıˇcek program˚u velmi podobn´y bal´ıku NfDump. Jeho nejvˇetˇs´ı nev´yhodou je, ˇze nen´ı schopen pracovat s NetFlow v9, ale zvl´ad´a pouze starˇs´ı verzi 8. Tento softwarov´y bal´ık obsahuje software pro zachyt´avan´ı NetFlow dat a nˇekolik program˚u pro jejich ´upravu. Mezi zaj´ımav´e souˇc´asti bal´ıku patˇr´ı utilita flow-dscan, kter´a umoˇzˇnuje jednoduˇse v NetFlow datech vyhled´avat nˇekter´e typy sken˚u a DoS ´

utok˚u.

3.2.1 NfDump a NfSen

Nfdump je bal´ıˇcek n´astroj˚u urˇcen´y pro sbˇer a zpracov´an´ı NetFlow verze 5, verze 7 a verze 9. Software je distribuov´an pod BSD licenc´ı a je spustiteln´y na vˇsech BSD a Posix platform´ach [21]. C´ılem tohoto bal´ıˇcku je, aby bylo moˇzn´e stejnˇe jednoduˇse prohled´avat jiˇz probˇehl´a flow, stejnˇe jako zaj´ımav´a aktu´aln´ı flow. Princip funkce jednotliv´ych program˚u z bal´ıˇcku pˇri sbˇeru NetFlow dat je zobrazen na obr´azku3.2.

(15)

nfcapd D´emon nfcapd ˇcte data a ukl´ad´a je do soubor˚u s urˇcitou ˇcasovou periodou. Nejˇcastˇeji se jedn´a o pˇetiminutovou periodu. Nfcapd ˇcte NetFlow data verze 5,7 a 9. Pro kaˇzd´y NetFlow stream je tˇreba jeden bˇeˇz´ıc´ı nfcapd.

nfdump Program nfdump ˇcte data uloˇzen´a programem nfcapd. Pomoc´ı tohoto programu je moˇzn´e filtrovat data podle r˚uzn´ych pravidel a generovat statistiky nejv´yraznˇejˇs´ıch flow. Je moˇzn´e vybrat si z nˇekolika ´urovn´ı detailu v´ypis˚u nebo je moˇzn´e si nastavit vlastn´ı form´at vypisovan´ych dat. Toto je velmi uˇziteˇcn´e pro pouˇzit´ı ve skriptech. V´ıce o z´apise pravidel je moˇzn´e zjistit na str´ance projektu nfdump [21].

Grafick´y frontend programu NfDump nese jm´eno NfSen. Jedn´a se o webov´e rozhran´ı nap-san´e v jazyce PHP a je opˇet ˇs´ıˇreno pod BSD licenc´ı. Umoˇzˇnuje zobrazovat grafy Net-Flow dat za pomoci Round Robin Datab´aze. Veˇsker´e grafy v t´eto pr´aci zobrazuj´ıc´ı datov´e toky poch´azej´ı pr´avˇe z programu NfSen. D´ale je moˇzn´e proch´azet NetFlow data v urˇcit´em ˇ

casov´em rozmez´ı, nastavovat upozornˇen´ı na ud´alosti a tak´e doplˇnovat do aplikace vlastn´ı pluginy [22].

3.3

Statistick´

e metody detekce anom´

ali´ı

Bˇeˇznˇe pouˇz´ıvan´e statistick´ych zp˚usoby detekce jsou zaloˇzeny na vytvoˇren´ı profilu chov´an´ı jednotliv´ych poˇc´ıtaˇc˚u v datov´e s´ıti. Pouˇz´ıvaj´ı se zde r˚uznˇe velk´e zp˚usoby agregace NetFlow dat. Na tato data jsou pot´e aplikov´any statistick´e metody. Pomoc´ı statistick´ych metod je moˇzn´e zjiˇst’ovat odchylky provozu od norm´aln´ıho stavu. Pokud profilu poˇc´ıtaˇce odpov´ıd´a nˇekolik pˇripojen´ı na emailov´y server za den, pak m˚uˇze n´ar˚ust na nˇekolik stovek spojen´ı za den znamenat, ˇze poˇc´ıtaˇc byl nakaˇzen nˇekter´ym z ˇcerv˚u a nyn´ı je souˇc´ast´ı botnetu ˇs´ıˇr´ıc´ıho spam. Bohuˇzel ne vˇsechny hrozby v datov´e s´ıti jsou tˇemito metodami odhaliteln´e.

Metoda Minds Minnesota Intrusion Detection System porovn´av´a v r´amci ˇcasov´ych ´usek˚u toky s pˇredch´azej´ıc´ımi pr˚umˇern´ymi hodnotami. Tyto toky jsou agregovan´e dle zdro-jov´e a c´ılov´e ip adresy a zdrojov´eho a c´ılov´eho portu.

Metoda Xu et al. Tato metoda je pojmenov´ana dle sv´ych autor˚u. Metoda urˇcuje en-tropii c´ılov´e ip adresy, c´ılov´eho portu a zdrojov´eho portu jako sadu vˇsech spojen´ı vych´azej´ıc´ıch z kaˇzd´e zdrojov´e ip adresy [13]. Pot´e jsou jednotliv´a spojen´ı klasifikov´ana do tˇr´ıd dle m´ıry sv´e entropie [13].

Metoda Volume Prediction Metoda Volume Prediction postupnˇe poˇc´ıt´a poˇcty tok˚u, byt˚u a paket˚u pro jednotliv´e ip adresy v datov´e s´ıti a kontroluje je oproti hod-not´am v urˇcit´em ˇcasov´em ´useku [13]. Odychylka namˇeˇren´ych hodnot od hodnot pˇredpovˇezen´ych pomoc´ı dat z minulosti, pˇredstavuje m´ıru anom´alie [13]. Model se v dalˇs´ım kroku pr˚ubˇeˇznˇe zaktualizuje pomoc´ı novˇe namˇeˇren´ych hodnot, ˇc´ımˇz se adap-tuje na zmˇeny chov´an´ı s´ıtˇe.

3.4

Detekce pomoc´ı pravidel

Narozd´ıl od v´yˇse zm´ınˇen´eho zp˚usobu detekce anom´ali´ı je detekce navrˇzen´a v t´eto pr´aci zaloˇzena na aplikaci jednoduch´ych pravidel. Tato pravidla jsou vytvoˇrena na m´ıru kaˇzd´e

(16)

V pˇr´ıpadech, kdy je detekce jevu trivi´aln´ı, nebo je potˇreba detekovat jev jen obecnˇe, postaˇcuje pouˇzit´ı jednho detekˇcn´ıho pravidla. Pokud se jedn´a o komplikovanˇejˇs´ı probl´em, nebo je tˇreba dos´ahnout lepˇs´ı pˇresnosti, pak je potˇreba pouˇz´ıt dvˇe nebo obecnˇe v´ıce de-tekˇcn´ıch pravidel. T´ımto se zvyˇsuje ´uˇcinnost detekce a omezuje se poˇcet faleˇsn´ych poplach˚u. Komunikace mus´ı totiˇz odpov´ıdat detekˇcn´ım pravidl˚um na v´ıce m´ıstech a je tak omezena moˇznost n´ahodn´e shody.

Detekce se provede tak, ˇze program nfdump je nejprve spuˇstˇen s prvn´ım pravidlem. ˇC´ım pˇresnˇeji je toto pravidlo nastaveno, t´ım rychleji probˇehne druh´y krok detekce, protoˇze bude zpracov´avat m´enˇe dat. V´ystupem je soubor urˇcit´ych flow. Z tˇechto flow jsou vyˇnaty ´udaje identifikuj´ıc´ı spojen´ı. Jedn´a se o zdrojovou a c´ılovou ip adresu a zdrojov´y a c´ılov´y port. V pˇr´ıpadˇe, ˇze druh´e pravidlo slouˇz´ı k vyhled´an´ı flow, kter´e je odpovˇed´ı na flow vyhledan´e v prvn´ım kroku, dojde k v´ymˇenˇe ´udaj˚u o zdroji a c´ıli. Ze zdrojov´eho portu a ip adresy se stane c´ılov´y port a ip adresa a naopak. Tato data jsou pot´e pˇrid´ana k druh´emu detekˇcn´ımu pravidlu a program nfdump je spuˇstˇen znovu pro kaˇzd´e dˇr´ıve nalezen´e spojen´ı. Jako platn´a jsou br´ana pouze flow s poˇc´ateˇcn´ım ˇcasem vˇetˇs´ım neˇz ˇcas p˚uvodn´ıho flow, ze kter´eho byly z´ısk´any informace o spojen´ı. V pˇr´ıpadˇe, ˇze jsou nalezena platn´a flow, jedn´a se o potvrzen´ı hledan´eho jevu. V opaˇcn´em pˇr´ıpadˇe jde o faleˇsn´y poplach. Princip detekce je zachycen na obr´azku3.3.

(17)

Kapitola 4

Hrozby pro datovou s´ıt’

4.1

Skenov´

an´ı port˚

u

Skenov´an´ı port˚u je velmi ˇcast´ym jevem, zvl´aˇstˇe u poˇc´ıtaˇc˚u pˇr´ımo pˇripojen´ych k internetu. Je obt´ıˇzn´e rozhodnout o z´avaˇznosti tohoto ˇcinu. Na jedn´e stranˇe doch´az´ı ke skenov´an´ı poˇc´ıtaˇc˚u vlastnˇe neust´ale bez v´aˇznˇejˇs´ıch n´asledk˚u. Na druh´e stranˇe si ovˇsem ´utoˇcn´ık m˚uˇze pˇripravovat prostor pro vˇetˇs´ı ´utok nebo se m˚uˇze poohl´ıˇzet po ˇspatnˇe zabezpeˇcen´em syst´emu, nebo nechr´anˇen´em portu, kter´y pouˇz´ıv´a pro nˇej zaj´ımav´a zraniteln´a sluˇzba.

4.1.1 TCP SYN sken

SYN sken je velmi obl´ıben´y sken. Za jeho oblibu m˚uˇze hlavnˇe jeho jednoduchost a rychlost. Tento sken zneuˇz´ıv´a mechanizmus, jak´ym jsou uzav´ır´ana spojen´ı TCP protokolu, kter´y se naz´yv´a Tˇr´ıcestn´y handshake (Three-Way Handshake). Na c´ılov´y port je odesl´an paket s nastaven´ym pˇr´ıznakem synchronizace (SYN paket). Pokud je skenovan´y port uzavˇren, je zpˇet odesl´an paket s pˇr´ıznakem reset (RST). V pˇr´ıpadˇe otevˇren´eho portu je zpˇet na skenuj´ıc´ı poˇc´ıtaˇc odesl´an´a odpovˇed’ SYN/ACK a skenovan´y poˇc´ıtaˇc ˇcek´a na potvrzen´ı paketem s nas-taven´ym pˇr´ıznakem ACK od ´utoˇcn´ıka, aby mohlo b´yt ustaveno spojen´ı. Paket ovˇsem nikdy nepˇrijde a spojen´ı je po chv´ıli zahozeno, nebo je zpˇet m´ısto pˇr´ıznaku ACK odesl´an paket s pˇr´ıznakem RST, kter´y spojen´ı ukonˇc´ı [8].

SYN sken se v NetFlow datech projevuje jako velk´y poˇcet tok˚u se stejn´ymi c´ılov´ymi ip adresami a rozd´ıln´ymi ˇc´ısly port˚u, kter´e probˇehly v kr´atk´em ˇcasov´em okamˇziku. Zdrojov´e ip adresy jsou ve vˇetˇsinˇe pˇr´ıpad˚u u vˇsech tok˚u stejn´e, protoˇze se ´utoˇcn´ık nesnaˇz´ı zamasko-vat sv´e kon´an´ı pomoc´ı faleˇsn´ych sken˚u. Pˇri pouˇzit´ı faleˇsn´ych sken˚u jsou zdrojov´e adresy rozd´ıln´e. V obou pˇr´ıpadech maj´ı toky stejnou velikost a poˇcet paket˚u pˇrich´azej´ıc´ıch na testovan´y port se rovn´a jedn´e. Pro odhalen´ı skenu je moˇzn´e pouˇz´ıt filtr:

proto TCP and (flags S and not flags ARPFU)

4.1.2 FIN sken, Xmas sken a Null sken

Tyto skeny maj´ı na rozd´ıl od SYN skenu tu v´yhodu, ˇze mohou proklouznout skrz nes-tavov´e firewally a jednoduch´e paketov´e filtry na routerech, coˇz ˇcin´ı tyto skeny o nˇeco m´enˇe n´apadn´e. Velkou nev´yhodou je, ˇze ne kaˇzd´y syst´em je postaven dle normy RFC 793 [3], na kterou se tyto skeny spol´ehaj´ı, a tak v´ysledky z´avis´ı na faktu, jestli testovan´y syst´em

(18)

RST pro uzavˇren´e porty. Pokud nen´ı pˇrijata odpovˇed’, je port oznaˇcen jako otevˇren´y nebo filtrovan´y.

Tak´e pravidla pro detekci tˇechto sken˚u se liˇs´ı pouze v mal´em detailu a to, jak je uvedeno n´ıˇze, v nastaven´ych pˇr´ıznac´ıch.

FIN sken FIN sken se pouˇz´ıv´a ke zjiˇstˇen´ı stavu port˚u na poˇc´ıtaˇc´ıch s operaˇcn´ım syst´emem Unix. Jak jiˇz n´azev napov´ıd´a, je odesl´an paket s nastaven´ym pˇr´ıznakem FIN. Pravidlo pro detekci je zaps´ano ve tvaru:

proto TCP and (flags F and not flags PARUS)

Xmas sken Pˇri Xmas skenu je na testovan´y port odesl´an paket s nastaven´ymi flagy FIN, PSH a URG. Pravidlo pro detekci je zaps´ano ve tvaru:

proto TCP and (flags FUP and not flags ARS)

Null sken Na c´ılov´y poˇc´ıtaˇc je odesl´an paket s vynulovan´ymi pˇr´ıznaky. Pravidlo pro de-tekci je zaps´ano ve tvaru:

proto TCP and not flags FUPARS

4.2

Detekce malware

Malware je souhrn´e oznaˇcen´ı pro veˇsker´y ˇskodliv´y software, jmenovitˇe se jedn´a o viry, ˇcervy a trojsk´e konˇe. Tyto ˇskodliv´e k´ody jsou ˇs´ıˇreny za r˚uzn´ym ´uˇcelem. M˚uˇze j´ıt o obyˇcejn´y vandalismus nebo v dneˇsn´ı dobˇe ˇcastˇeji o ´utok zloˇcineck´ych organizac´ı se z´amˇerem z´ıskat od uˇzivatel˚u citliv´a data, jako jsou napˇr´ıklad hesla k internetov´emu bankovnictv´ı a dalˇs´ım sluˇzb´am. Tak´e m˚uˇze j´ıt o pokus zapojit napaden´y poˇc´ıtaˇc do nˇekter´eho z mnoha botnet˚u zodpovˇedn´ych za ˇs´ıˇren´ı spamu a DDoS ´utoky.

Boj proti malwaru je za pomoci NetFlow dat ponˇekud obt´ıˇzn´y. Protoˇze se malware ˇs´ıˇr´ı hlavnˇe pomoc´ı email˚u a z´avadn´ych internetov´ych str´anek, nen´ı moˇzn´e s v´yjimkou pouˇzit´ı blacklist˚u zabr´anit staˇzen´ı tohoto ˇskodliv´eho k´odu a pouˇzit´ı NetFlow dat tedy rozhodnˇe v ˇz´adn´em pˇr´ıpadˇe nenahrazuje antivirov´e a antimalware programy. Je ovˇsem moˇzn´e po-moc´ı jak statistick´ych metod detekce, tak detekˇcn´ıch pravidel vysledovat malwarem infiko-van´e poˇc´ıtaˇce. NetFlow data tedy umoˇzn´ı rychlou reakci a pomohou minimalizovat ˇskody zp˚usoben´e infikovan´ym poˇc´ıtaˇcem.

K nejˇcastˇejˇs´ım projev˚um malware v NetFlow datech patˇr´ı napˇr´ıklad extr´emn´ı zv´yˇsen´ı spojen´ı s SMTP servery. D´ale n´ar˚ust poˇctu sken˚u z poˇc´ıtaˇc˚u ve vnitˇrn´ı s´ıti, kdy se ˇcervi pokouˇsej´ı nal´ezt dalˇs´ı zraniteln´e stroje, aby je mohli infikovat. Tak´e je moˇzn´e detekovat zombie poˇc´ıtaˇce zapojen´e do botnet˚u pomoc´ı odhalen´ı jejich komunikace s botmasterem. Tato komunikace b´yv´a nejˇcastˇeji zaloˇzena na protokolu IRC, ˇci HTTP. V´yjimkou ovˇsem nejsou ani botnety schopn´e komunikovat na libovoln´em portu a svou komunikaci ˇsifrovat. Botnety v NetFlow datech je moˇzn´e odhalovat jak pomoc´ı statistick´ych metod, tak pomoc´ı nalezen´ı vhodn´eho vzorku komunikace ve flow a vytvoˇren´ı detekˇcn´ıho pravidla.

(19)

4.3

Utok na SSH

´

SSH je program a tak´e protokol urˇcen´y pro zabezpeˇcen´y vzd´alen´y pˇr´ıstup k syst´emu. Umoˇzˇnuje autentizaci a ˇsifrov´an´ı. Byl vyvinut za ´uˇcelem nahrazen´ı program˚u komunikuj´ıc´ıch nezabezpeˇcenou cestou, jako je napˇr´ıklad telnet.

Protoˇze SSH umoˇzˇnuje pˇristoupit do syst´emu vzd´alenˇe, b´yv´a ˇcast´ym c´ılem ´utoˇcn´ık˚u, kteˇr´ı se pokouˇs´ı z´ıskat pˇr´ıstupov´e heslo, t´ım z´ıskat pˇr´ıstup do syst´emu a ten n´aslednˇe ovl´adnout nebo poˇskodit. Pro znesnadnˇen´ı detekce mohou b´yt tyto ´utoky vedeny z nˇekolika m´ıst, pˇr´ıpadnˇe mohou b´yt v ˇcase rozloˇzeny tak, aby budily co nejmenˇs´ı podezˇren´ı. Proto by v ide´aln´ım pˇr´ıpadˇe mˇely b´yt ´uˇcty s vysok´ymi pr´avy jako je napˇr´ıklad root pˇres SSH ne-dostupn´e. ´Utoky proti hesl˚um SSH ´uˇct˚u lze rozdˇelit stejnˇe jako veˇsker´e ´utoky proti hesl˚um na dva druhy.

´

Utok hrubou silou je v podstatˇe t´emˇeˇr nepouˇziteln´y pro svoji extr´emn´ıˇcasovou n´aroˇcnost. Doch´az´ı zde ke zkouˇsen´ı vˇsech kombinac´ı znak˚u ze zadan´e mnoˇziny, coˇz u hesla, kter´e m´a 5 znak˚u a je sloˇzeno pouze z mal´ych p´ısmen, pˇredstavuje zhruba 12,4 milionu kombinac´ı.

Druh´ym pouˇz´ıvan´ym ´utokem je ´utok slovn´ıkov´y. Heslo k ´uˇctu je testov´ano proti rozs´ahl´e datab´azi slov, takzavn´emu slovn´ıku. ´Uspˇeˇsnost ´utoku silnˇe z´avis´ı na dokonalosti a obs´ahlosti slovn´ıku a tak´e samozˇrejmˇe na tom, zda je k tomuto typu ´utoku heslo n´achyln´e. Mˇelo by se jednat o smyslupln´e slovo bez speci´aln´ıch znak˚u (/*-+,.?).

´

Utok na SSH se v NetFlow datech projevuje jako velk´y poˇcet tok˚u vykazuj´ıc´ıch velkou m´ıru podobnosti v kr´atk´em ˇcasov´em ´useku. Pˇri jeho hled´an´ı je moˇzn´e se omezit na port 22, kde b´yv´a defaultnˇe spuˇstˇen SSH server. Jednotliv´e toky smˇerem od ´utoˇcn´ıka maj´ı vˇzdy v´ıce neˇz 10 paket˚u, protoˇze pˇri niˇzˇs´ım poˇctu nem˚uˇze j´ıt o korektn´ı pˇrihl´aˇsen´ı [16]. Ve vˇetˇsinˇe pozorovan´ych pˇr´ıpad˚u pˇri tvorbˇe t´eto pr´ace mˇela flow jdouc´ı smˇerem od ´utoˇcn´ıka velikost mezi 1100-1400 byty a poˇcet paket˚u 12-15. Odpovˇedi serveru mezi sebou vykazovaly vˇetˇs´ı podobnost neˇz ´utoˇcn´ıkovy poˇzadavky. Poˇcet paket˚u se zde pohyboval mezi 13-16 a velikost byla 2300-3200 byt˚u. Dominantn´ı hodnotou zde bylo 14 paket˚u a 2316 byt˚u, coˇz pˇredstavovalo pˇri sledovan´ych ´utoc´ıch zhruba 60% vˇsech odpovˇed´ı na toky jdouc´ı smˇerem od ´utoˇcn´ıka.

4.4

Utok odepˇ

´

ren´ım sluˇ

zby

´

Utok odepˇren´ım sluˇzby oznaˇcuje ˇsirok´e spektrum r˚uznorod´ych ´utok˚u skrze poˇc´ıtaˇcovou s´ıt’. C´ılem tˇechto ´utok˚u je ´upln´e znepˇr´ıstupnˇen´ı nebo omezen´ı pˇr´ıstupu k urˇcit´e sluˇzbˇe. Vˇetˇsinou se jedn´a o webov´y, DNS nebo emailov´y server. D´ale m˚uˇze b´yt ´utok pouˇzit pro vynucen´ı restartu serveru pot´e, co na nˇej byl nahr´an ´utoˇcn´ıkem ˇskodliv´y k´od. Tyto ´utoky je moˇzn´e rozdˇelit dle jejich anatomie do dvou n´asleduj´ıc´ıch skupin:

´

Utok hrubou silou V anglick´em jazyce je tento typ ´utoku vˇetˇsinou naz´yv´anFlood, z´aplava. Tyto ´utoky jsou postaveny na zaplaven´ı c´ılov´eho stroje velk´ym poˇctem dat, kter´a je nutn´e zpracovat. Spol´ehaj´ı na vyˇcerp´an´ı pamˇeti nebo spotˇrebov´an´ı procesorov´eho ˇcasu. Typick´ymi pˇredstaviteli jsou ´utok SYN flood, UDP flood a HTTP flood.

Vyuˇzit´ı chyby Tyto ´utoky se naz´yvaj´ıNuke. Nejde zde o vyˇcerp´an´ı zdroj˚u obˇeti, ale ´utok spol´eh´a na zneuˇzit´ı chyby v implementaci sluˇzby. K shozen´ı poˇc´ıtaˇce dojde pomoc´ı zasl´an´ı jedin´eho spr´avnˇe upraven´eho paketu. Nejzn´amˇejˇs´ım pˇr´ıkladem je WinNuke,

(20)

Podle poˇctu ´utoˇcn´ık˚u a proveden´ı je moˇzn´e ´utoky rozdˇelit do tˇr´ı n´asleduj´ıc´ıch skupin:

DoS Jako Denial of Service je pojmenov´an ´utok, kdy ´utoˇc´ı jeden ´utoˇcn´ık na jednu obˇet’. Dnes se t´emˇeˇr v˚ubec nepouˇz´ıv´a, protoˇze jeden ´utoˇcn´ık nen´ı schopen zajistit pˇrevahu v rychlosti linky a hardwaru nad obˇet´ı tak, aby ji mohl zahltit poˇzadavky.

DDoS Distributed Denial of Service je v dneˇsn´ı dobˇe nejbˇeˇznˇejˇs´ım druhem ´utoku. Do ´

utoku b´yvaj´ı zapojeny poˇc´ıtaˇce infikovan´e malwarem a sdruˇzen´e do botnetu. Vzhle-dem k tomu, ˇze poˇcty poˇc´ıtaˇc˚u zapojen´ych do botnet˚u se r˚uzn´ı od des´ıtek tis´ıc aˇz po statis´ıce, jsou tyto ´utoky ˇcasto velmi niˇciv´e.

DRDoS Utok Distributed Reflected Denial of Service prob´ıh´´ a tak, ˇze ´utoˇcn´ık na c´ıl ´utoˇc´ı nepˇr´ımo pomoc´ı podvrˇzen´ı zdrojov´e adresy poˇzadavku, kam je um´ıstˇena adresa obˇeti. Pot´e je poˇzadavek odesl´an na co nejvˇetˇs´ı mnoˇzstv´ı poˇc´ıtaˇc˚u a ty pot´e svou odpovˇed´ı zahlt´ı obˇet’.

4.4.1 HTTP flood

HTTP flood je jeden z nejjednoduˇsˇs´ıch, ale pˇri spr´avn´em proveden´ı i nejz´akeˇrnˇejˇs´ı ´utok˚u [15]. Pouˇz´ıv´an je proti webov´ym server˚um a jeho c´ılem je znepˇr´ıstupnit webov´e str´anky bˇeˇz´ıc´ı na tomto serveru. Principem ´utoku je zas´ıl´an´ı bˇeˇzn´ych ˇci nesmysln´ych GET poˇzadavk˚u na server. Tyto poˇzadavky jsou nav´ıc z hlediska firewallu legitimn´ı a firewall tedy nem´a d˚uvod je filtrovat. T´ım doch´az´ı k zahlcen´ı serveru, kter´y mus´ı tyto nesmysln´e poˇzadavky zpracov´avat a nezb´yvaj´ı mu tedy jiˇz syst´emov´e zdroje pro zpracov´an´ı legitimn´ıch poˇzadavk˚u od uˇzivatel˚u. Pro zd´arn´e proveden´ı ´utoku je potˇreba m´ıt k dispozici dosteˇcnˇe velk´e mnoˇzstv´ı adres, ze kter´ych bude veden ´utok. Jedn´a se tedy o DDoS ´utok. Velmi ˇcasto je tento ´utok implementov´an v botnetech [15].

Simulovan´y HTTP Flood ´utok

V r´amci pokus˚u pro bakal´aˇrskou pr´aci byl proveden simulovan´y DDoS HTTP flood ´utok na server monitorovan´y pomoc´ı NetFlow dat. ´Utok byl simulov´an pomoc´ı jednoduch´eho skriptu v jazyce Perl, kter´y opakovanˇe v nekoneˇcn´e smyˇcce odes´ıl´a na server poˇzadavek ”GET /“. V´ysledek ´utoku na server je zachycen v grafu4.1. ´Utok byl veden ze tˇr´ı poˇc´ıtaˇc˚u v celkov´e d´elce 5-7 minut. Za tuto dobu bylo uskuteˇcnˇeno celkem 16532 flow. Pˇreneseno bylo 82021 paket˚u s celkovou velikost´ı 8.3 MB.

Detekce ´utoku HTTP Flood ´utoku

HTTP flood je tˇreba hledat na portech, na kter´ych naslouchaj´ı webov´e servery ve sle-dovan´e s´ıti, typicky port 80 a ˇsifrovan´y port 443. Ostatn´ı porty jsou pˇri tomto typu ´utoku nezaj´ımav´e. ´Utok je charakteristick´y t´ım, ˇze z ´utoˇc´ıc´ıch poˇc´ıtaˇc˚u pˇrich´az´ı mnoho spojen´ı v kr´atk´em ˇcasov´em intervalu. Spojen´ı se vyznaˇcuj´ı mal´ym poˇctem paket˚u a mal´ym objemem pˇrenesen´ych dat a jsou si navz´ajem velmi podobn´a. Odpovˇedi na spojen´ı jsou z hlediska poˇctu paket˚u a velikosti dat t´emˇeˇr stejn´e, opˇet s mal´ym poˇctem pˇrenesen´ych dat a n´ızk´ym poˇctem paket˚u.

Pˇri proveden´em pokusu mˇely t´emˇeˇr vˇsechny poˇzadavky, tedy flow smˇeˇruj´ıc´ı od ´utoˇcn´ık˚u k obˇeti, velikost 280-400 byt˚u a poˇcet paket˚u byl v rozmez´ı 5-6. V opaˇcn´em smˇeru mˇela flow velikost 700-800 byt˚u pˇri pˇeti paketech4.2.

(21)

Obr´azek 4.1: V grafu je jasnˇe viditeln´y okamˇzik, kdy doˇslo k ´utoku

Obr´azek 4.2: Pˇr´ıklad flow smˇeˇruj´ıc´ıch od ´utoˇcn´ık˚u k c´ılov´emu serveru

Pro detekci HTTP flood ´utoku se jev´ı jako v´yhodnejˇs´ı pouˇz´ıt flow smˇeˇruj´ıc´ı ze serveru k ´utoˇcn´ık˚um4.3, protoˇze parametry flow v opaˇcn´em smˇeru se mohou mˇenit v z´avislosti na zp˚usobu implementace ´utoku. Z´aleˇz´ı zde na tom, jak sloˇzit´e dotazy dok´aˇze n´astroj pouˇzit´y ´

utoˇcn´ıkem skl´adat. Toky ze serveru jsou ovˇsem vˇzdy velmi podobn´e, protoˇze se jedn´a bud’ o odes´ıl´an´ı str´anek, nebo odes´ıl´an´ı HTTP stavov´ych k´od˚u s doplˇnuj´ıc´ımi informacemi. De-tekˇcn´ı pravidlo tedy m´a n´asleduj´ıc´ı tvar:

proto TCP and port 80 and packets 5 and (bytes > 700 and bytes < 800)

Obr´azek 4.3: Oddchoz´ı toky ze serveru popsan´e pomoc´ı v´yˇse zm´ınˇen´eho pravidla

(22)

kter´em se m˚uˇze ˇs´ıˇrit malware a warez ve vˇsech podob´ach do jinak dobˇre zabezpeˇcen´e s´ıtˇe. Zde lze napˇr´ıklad zm´ınit rozˇs´ıˇren´ı ˇcerv˚u rodiny Stration [23], s alternativn´ım n´azvem Ware-zov, kter´y se ˇs´ıˇril tak´e pomoc´ı odkaz˚u odes´ılan´ych v s´ıti ICQ. Po kliknut´ı na URL adresu obsaˇzenou ve zpr´avˇe st´ahl do poˇc´ıtaˇce dalˇs´ı malware. Tento ˇcerv byl rovnˇeˇz odpovˇedn´y za rozes´ıl´an´ı spamu. Pomoc´ı messenger˚u tak´e mohou unikat ven z vnitˇrn´ı s´ıtˇe citliv´e informace v libovoln´em mnoˇzstv´ı. V neposledn´ı ˇradˇe nen´ı ide´aln´ı, aby zamˇestnanci tr´avili podstatnou ˇ

c´ast pracovn´ı doby komunikac´ı s pˇr´ateli pomoc´ı Instant Messenger˚u.

4.5.1 Protokol OSCAR

Protokol OSCAR, cel´ym n´azvem Open System for CommunicAtion in Realtime je protokol, kter´y pouˇz´ıv´a firma AOL pro sv´e instant messengery ICQ a AIM. Jedn´a se o propriet´aln´ı bin´arn´ı TCP protokol. Do ned´avn´e doby byly vˇsechny informace o protokolu dostupn´e pouze skrze reverzn´ı inˇzen´yrstv´ı. Dne 5.bˇrezna 2008 spoleˇcnost AOL uveˇrejnila dokumentaci popisuj´ıc´ı nˇekter´e ˇc´asti protokolu, aby ulehˇcila pr´aci v´yvoj´aˇr˚um. Dokumentace je dostupn´a na webov´ych str´ank´ach [7].

Na zaˇc´atku komunikace se klient pˇripoj´ı na pˇrihlaˇsovac´ı server spoleˇcnosti AOL, kde se pokus´ı pˇrihl´asit ke sv´emu ´uˇctu. Po ´uspˇeˇsn´em pˇrihl´aˇsen´ı je klient pˇrihlaˇsovac´ım serverem pˇrepojen na komunikaˇcn´ı server, pˇres kter´y pot´e prob´ıh´a po celou dobu trv´an´ı jeho pˇripojen´ı komunikace s ostatn´ımi klienty s´ıtˇe.

4.5.2 Protokol XMPP

Protokol XMPP je otevˇren´y protokol na b´azi XML slouˇz´ıc´ı pro instant messenging. Kromˇe pouˇzit´ı v jabber serverech byl tak´e pouˇzit firmou Google v jejich modifikaci Google Talk. XMPP je tak´e pouˇz´ıv´an pro vnitrofiremn´ı komunikaci. Mezi v´yhody protokolu patˇr´ı moˇznost pouˇzit´ı ˇsifrov´an´ı a decentralizace. To znamen´a, ˇze t´emˇeˇr kdokoliv si m˚uˇze spustit vlastn´ı Jabber server a pˇripadn´e blokov´an´ı bude mnohem n´aroˇcnejˇs´ı, neˇz u dˇr´ıve uveden´eho pro-tokolu OSCAR.

Komunikace mezi klientem a serverem prob´ıh´a obdobnˇe jako u protokolu OSCAR s tou v´yjimkou, ˇze v komunikaci nen´ı pˇr´ıtomen ˇz´adn´y pˇrihlaˇsovac´ı server nebo sp´ıˇse pˇrihlaˇsovac´ı server je i serverem komunikaˇcn´ım. Probl´em komunikace s uˇzivateli na jin´em serveru, jako d˚usledek decentralizace, prob´ıh´a na ´urovni server-to-server a je pro klienta transparentn´ı. To znamen´a, ˇze napˇr´ıklad uˇzivatel pˇripojen´y pˇres jin´y server m˚uˇze vyuˇz´ıvat sluˇzby na sv´em domovsk´em serveru.

4.6

Detekce Instant Messengeru

4.6.1 Obecn´a detekce Instant Messengeru

V´yhodou detekce messenger˚u v takto obecn´em tvaru je, ˇze nen´ı tˇreba tvoˇrit detekˇcn´ı pravidla pro kaˇzd´y zn´am´y protokol zvl´aˇst’, ale ˇze je moˇzn´e odhalovat r˚uzn´e messengery pomoc´ı stejn´e sady pravidel. Dan´ı za takto obecn´y pˇr´ıstup je ovˇsem vˇetˇs´ı nepˇresnost neˇz v pˇr´ıpadˇe pravidel zac´ılen´ych na specifick´y protokol. V tomto pˇr´ıpadˇe byly pozorov´any protokoly OSCAR a XMPP, kter´e jsou pouˇzity u messenger˚u ICQ, AIM, Google Talk a Jabber.

Obecn´a detekce vych´az´ı z vlastnosti spoleˇcn´e pro vˇsechny messengery jako takov´e. Touto spoleˇcnou vlastnost´ı je zprostˇredkov´an´ı komunikace mezi uˇzivateli. Protoˇze je tˇreba mes-senger pouze detekovat a ne sledovat jeho chov´an´ı, je tedy moˇzn´e ignorovat jeho sekund´arn´ı

(23)

funkce, jako je napˇr´ıklad pˇrenos soubor˚u. Tyto funkce neposlouˇz´ı pˇri detekov´an´ı pˇr´ıtomnosti messengeru v s´ıti, protoˇze se odehr´avaj´ı pouze minim´aln´ı mnoˇzstv´ı ˇcasu z komunikace mezi uˇzivateli. Nav´ıc by jejich zahrnut´ım do jedin´eho detekˇcn´ıho pravidla doˇslo ke sn´ıˇzen´ı ´

uspˇeˇsnosti, protoˇze pˇrenos soubor˚u vykazuje diametr´alnˇe odliˇsn´e charakteristiky neˇz prost´a komunikace mezi uˇzivateli.

Vzhledem k tomu, ˇze hled´an´ı Instant Messenger˚u prob´ıh´a v cel´em rozsahu port˚u a ip adres, nen´ı moˇzn´e tyto ´udaje pouˇz´ıt pro vytvoˇren´ı detekˇcn´ıho pravidla. Prvn´ı vˇec´ı, na kterou je moˇzno se spolehnout u komunikace messenger˚u, je fakt, ˇze spojen´ı mezi klientem a serverem, pˇr´ıpadnˇe mezi klienty navz´ajem, zajiˇst’uje TCP protokol. Z pozorov´an´ı re´aln´e komunikace vyplynulo, ˇze 47% vˇsech flow u sledovan´ych protokol˚u obsahuje m´enˇe neˇz 3 pakety. Procentu´aln´ı zastoupen´ı flow podle poˇctu paket˚u v komunikaci je patrn´e v grafu

4.4.

Obr´azek 4.4: Graf zobrazuj´ıc´ı poˇcet paket˚u v jednotliv´ych flow v sledovan´e s´ıti

Dalˇs´ım zjiˇstˇen´ym faktem je, ˇze 67% datov´ych tok˚u komunikace messenger˚u obsahuje v paketech pˇr´ıznaky ACK a PUSH. Nyn´ı je tˇreba urˇcit, jak´y je pr˚umˇern´y poˇcet byt˚u v paketech v jednotliv´ych flow komunikace. Vzhledem k tomu, ˇze se jedn´a o obecnou detekci, je tˇreba zvolit tuto hodnotu velmi peˇclivˇe, protoˇze v pˇr´ıpadˇe pˇr´ıliˇs velk´eho rozsahu hodnot se bude zvyˇsovat poˇcet chybnˇe detekovan´ych flow. Po ˇradˇe pokus˚u byl rozsah ustanoven na hodnot´ach 200-400 byt˚u. D´ale bylo vypozorov´ano, ˇze hodnotaPoˇcet byt˚u za sekundu (bps) je u tˇechto flow v naprost´e vˇetˇsinˇe pˇr´ıpad˚u rovna nule. Pravidlo je zaps´ano ve tvaru:

proto TCP and (flags AP and not flags RFUS) and (bpp > 200 and bpp < 400) and (packets < 3) and tos 0 and bps 0

(24)

nen´ı tˇreba pravidlo upravovat, pokud budou st´avaj´ıc´ı protokoly lehce poupraveny, coˇz se dˇeje napˇr´ıklad u protokolu OSCAR pomˇernˇe ˇcasto. Pomoc´ı tohoto pravidla byl tak´e ´uspˇeˇsnˇe detekov´an i jabber klient komunikuj´ıc´ı se serverem na portu 443, kter´y je bˇeˇznˇe urˇcen pro HTTPS komunikaci, a proto je moˇzn´e se pˇres nˇej pˇripojit i skrze restriktivn´ı firewall.

4.6.2 Detekce protokolu OSCAR

Pravidla pro detekci protokolu OSCAR byla sestavena na z´akladˇe pozorov´an´ı jeho charak-teristick´ych projev˚u v NetFlow datech. C´ılem bylo naleznout ˇcasto se opakuj´ıc´ı vzorek dat a umoˇznit tak rychlou detekci klienta v s´ıti.

Po ˇradˇe pokus˚u bylo nalezeno prvn´ı flow, kter´e smˇeˇruje od klienta smˇerem k serveru. Ve flow jsou obsaˇzeny dva pakety aPoˇcet byt˚u na paket (bpp) je 40. Jedin´ym nastaven´ym flagem je A (Ack) Pro detekci slouˇz´ı n´asleduj´ıc´ı pravidlo:

(flags A and not flags RPFUS) and bpp 40 and bps 0 and packets < 3

Druh´ym datov´ym tokem je tok smˇeˇruj´ıc´ı v opaˇcn´em smˇeru s n´asleduj´ıc´ım z´apisem:

(((flags AP and not flags RFUS) and (bytes 76 or bytes 75) and packets 1) or ((flags AR and not flags PFUS) and (bytes 40) and packets 1))

and (vystup pravidla 1)

4.6.3 Detekce protokolu XMPP

Detekce protokolu XMPP je stejnˇe jako u pˇredchoz´ıho protokolu zaloˇzena na jeho po-zorov´an´ı a hled´an´ı pro nˇej chrakteristick´ych flow. Pravidla pro tato flow byla otestov´ana proti ˇctyˇrem server˚um. Konkr´etnˇe se jednalo o tyto servery: Google Talk server na portu 5222, jabber server FIT VUT na portu 5223 a servery Jabbim na portech 5222 a 443. Vypozorovan´a pravidla jsou n´asleduj´ıc´ı:

(bytes 77 or bytes 366) and (flags AP and not flags RFUS) and packets 1 (flags A and not flags RPFUS) and bpp 40 and bps 0 and packets < 3 and (vystup pravidla 1)

Nen´ı bez zaj´ımavosti, ˇze druh´e detekˇcn´ı pravidlo je stejn´e jako pravidlo ˇc´ıslo jedna u detekce protokolu OSCAR. Toky se odliˇsuj´ı pouze smˇerem. Zde flow smˇeˇruje od serveru ke klientovi.

4.7

Sd´ılen´ı dat pomoc´ı protokolu BitTorrent

BitTorrent je protokol urˇcen´y pro peer-to-peer (p2p) sd´ılen´ı dat navrˇzen´y Bramem Co-henem. Jeho prvn´ı implementace byla vyd´ana 2.ˇcervence 2001. Od doby sv´eho vyd´an´ı se stal jedn´ım z nejbˇeˇznˇejˇs´ıch protokol˚u pro sd´ılen´ı soubor˚u. Provoz protokolu BitTorrent pˇredstavoval v roce 2004 cel´ych 35% provozu v internetu [24]. Z´avaˇzn´ym probl´emem je, ˇ

ze BitTorrent klienti navazuj´ı za kr´atk´y ˇcasov´y okamˇzik velk´e mnoˇzstv´ı spojen´ı. M˚uˇze j´ıt i o 300-500 spojen´ı za sekundu, coˇz rychle zaplˇnuje pˇrekladov´e tabulky NAT na routerech. Rozd´ıl mezi s´ıt´ı s jedin´ym bˇeˇz´ıc´ım BitTorrent klientem a s´ıt´ı bez BitTorrent provozu je pro ilustraci zachycen na obr´azc´ıch 4.5a 4.6.

(25)

Obr´azek 4.5: S´ıt’ s bˇeˇz´ıc´ım BitTorrent klientem

Obr´azek 4.6: S´ıt’ za norm´aln´ıho stavu

Torrent Torrent oznaˇcuje jak data staˇziteln´a pomoc´ı protokolu BitTorrent, tak soubor s pˇr´ıponou .torrent. Tento soubor obsahuje metadata vˇsech soubor˚u, kter´e pomoc´ı nˇej mohou b´yt staˇzeny. Konkr´etnˇe se jedn´a o n´azvy soubor˚u, jejich velikosti a tak´e kontroln´ı souˇcty vˇsech ˇc´ast´ı torrentu. D´ale je v nˇem obsaˇzena adresa Trackeru.

Peer Takto je oznaˇcov´ana jedna instance BitTorrent klienta v s´ıti internet. Navazuje spo-jen´ı s ostatn´ımi peery a pokouˇs´ı se zkompletovat stahovan´e soubory. Pˇri zjednoduˇsen´ı terminologie lze povaˇzovat slovo peer za synonymum proklienta.

Tracker Tracker je oznaˇcen´ı pro server, kter´y udrˇzuje pohromadˇe r˚uzn´e torrent soubory a poskytuje klient˚um informace o ostatn´ıch klientech spolupracuj´ıc´ıch na kompletaci konkr´etn´ıho torrentu. Provoz mezi klientem a trackerem obvykle prob´ıh´a pomoc´ı HTTP/HTTPS komunikace. Mezi nejzn´amˇejˇs´ı trackery patˇr´ı Isohunt, The Pirate Bay a Mininova. Existuje ovˇsem obrovsk´e mnoˇzstv´ı dalˇs´ıch tracker˚u. Nˇekter´e z nich jsou veˇrejn´e a nˇekter´e soukrom´e (pouze na pozv´anku).

(26)

Sd´ılen´ı dat postaven´e nad protokolem BitTorrent je pomoc´ı bˇeˇzn´ych technik obt´ıˇznˇe blokovateln´e. Tradiˇcn´ı techniky spol´ehaj´ı na blokov´an´ı rozsahu port˚u, coˇz je vzhledem k tomu, ˇze program m˚uˇze bˇeˇzet nad libovoln´ym portem, ne´uˇcinn´e. Dalˇs´ım bˇeˇzn´ym zp˚usobem je blokov´an´ı spojen´ı s Trackerem a t´ım znemoˇznˇen´ı vyhled´an´ı protˇejˇsk˚u pro stahov´an´ı a n´asledn´eho staˇzen´ı souboru. Vzhledem k tomu, ˇze datab´aze slouˇz´ıc´ı k blokov´an´ı tohoto provozu nebude pravdˇepodobnˇe nikdy zn´at vˇsechny Trackery v internetu, je ´uspˇeˇsnost t´eto metody rovnˇeˇz diskutabiln´ı.

Jako pokusn´y objekt byl pouˇzit poˇc´ıtaˇc s bˇeˇz´ıc´ım programem rTorrent [18]. Na tento poˇc´ıtaˇc byla staˇzena linuxov´a distribuce a pot´e byla po ˇctyˇri dny sd´ılena. Takto dlouh´a doba byla urˇcena proto, ˇze se nejedn´a o pˇr´ıliˇs ˇcasto stahovan´y obsah a tak bylo tˇreba poˇckat na klienty hledaj´ıc´ı tato konkr´etn´ı data. V´yhodou pˇr´ıstupu bylo, ˇze v dobˇe kdy se tvoˇrila monitorovac´ı pravidla, byla zjednoduˇsena kontrola provozu, protoˇze byla zn´ama ip adresa stroje, na kter´em BitTorrent klient bˇeˇz´ı a vˇsechny dalˇs´ı okolnosti byly pod kontrolou.

Pˇri vytvoˇren´ı detekce bitTorrent protokolu byla v´ychoz´ım materi´alem specifikace pro-tokolu uveˇrejnˇen´a na webov´ych str´ank´ach [6] a [25]. Z hlediska NetFlow dat nen´ı moˇzn´e odliˇsit kv˚uli absenci obsahu paket˚u, stahov´an´ı dat z Trackeru od ostatn´ı HTTP/HTTPS komunikace. Pro ´uspˇeˇsnou detekci tedy bylo nutn´e naleznout vzorek flow charakteristik samotn´eho sd´ılen´ı dat a komunikace mezi klienty.

Prvn´ı zjiˇstˇen´y poznatek je, ˇze pakety vys´ılan´e pˇri komunikaci bitTorrent klienty maj´ı nastaveny hodnotu Type of Service na 8, coˇz znamen´a maxim´aln´ı propustnost [2].

Dalˇs´ım poznatkem je, ˇze se klienti po staˇzen´ı torrent souboru z trackeru a dotazu ohlednˇe klient˚u na tracker pokouˇs´ı nav´azat spojen´ı s ostatn´ımi aktivn´ımi klienty posky-tuj´ıc´ım stejn´a data, aby mohli spolupracovat na kompletaci souboru. V NetFlow datech se tento pokus o spojen´ı projev´ı jako s´erie stejn´ych nebo velmi podobn´ych tok˚u v kr´atk´em ˇ

casov´em okamˇziku. Tuto komunikaci je moˇzn´e zachytit pravidlem:

((flags S and not flags ARPFU) or (flags A and not flags RPFUS)) and (bpp > 50 and bpp < 61) and packets < 4 and tos 8

D˚uleˇzit´ym v´ystupem tohoto pravidla jsou ip adresy a ˇc´ısla port˚u mezi poˇc´ıtaˇci, kde panuje podezˇren´ı na bˇeˇz´ıc´ıho BitTorrent klienta. Toto podezˇren´ı se ´umˇernˇe zvyˇsuje s poˇctem nalezen´ych flow se stejnou charakteristikou. Pokud je v r´amci jednoho souboru s NetFlow daty zachyceno v´ıce flow z urˇcit´eho zdroje s v´yˇse uveden´ymi charakteristikami, pak se jedn´a s velkou pravdˇepodobnost´ı o stroj s bˇeˇz´ıc´ım BitTorrent klientem. Nyn´ı je tˇreba podezˇren´ı potvrdit pomoc´ı vyhled´an´ı probˇehl´eho pˇrenosu dat.

Zde je moˇzn´e z komunikace mezi klienty detekovat dva druhy v´ymˇeny dat. Prvn´ı je poˇzadavek jednoho klienta druh´emu na odesl´an´ı seznamu blok˚u, kter´e m´a k dispozici pro v´ymˇenu. Velikost poˇzadavku v bytech je podle specifikace protokolu definov´an jako 16-32 kilobyt˚u [25]. Druh´a detekovateln´a ud´alost je vlastn´ı v´ymˇena dat mezi BitTorrent klienty. Dle specifikace je maxim´aln´ı velikost bloku 1MB [25]. Nejlepˇs´ı je dle [25] nastavit velikost bloku na 512kB nebo m´enˇe.

Obˇe v´yˇse uveden´e ˇcinnosti je moˇzn´e vyhledat pomoc´ı n´asleduj´ıc´ıho pravidla:

((bytes > 15k and bytes < 33k) or ((bytes > 255k and bytes < 1m) and bpp > 1000)) and proto TCP and (vystup pravidla 1)

(27)

Kapitola 5

avˇ

er

Na z´akladˇe sezn´amen´ı se s technologi´ı NetFlow a po prostudovan´an´ım r˚uzn´ych hrozeb v da-tov´e s´ıti a jejich projev˚u v NetFlow datech, byla navrˇzena detekˇcn´ı pravidla pro odhalov´an´ı v´yˇse uveden´ych hrozeb a neˇz´adouc´ıho provozu. D˚uleˇzit´a byla pˇritom co nejvˇetˇsi moˇzn´a obecnost hledan´ych ˇreˇsen´ı, coˇz se podaˇrilo splnit. Napˇr´ıklad tam, kde nen´ı explicitnˇe po-ˇ

zadov´ano sledov´an´ı urˇcit´eho portu, jsou pravidla na portech naprosto nez´avisl´a. D´ale bylo pro pouˇzit´ı s pravidly navrˇzeno vyhled´av´an´ı pomoc´ı dvou pravidel. Pˇri tomto vyhled´an´ı jsou pouˇzity informace z´ıskan´e prvn´ım pravidlem upˇresnˇena pomoc´ı pravidla ˇc´ıslo dvˇe.

V r´amci pr´ace bylo provedeno nˇekolik test˚u s poˇc´ıtaˇcem slouˇz´ıc´ım jako pokusn´y objekt a um´ıstˇen´ym v s´ıti monitorovan´e pomoc´ı NetFlow. Jednalo se hlavnˇe o sledov´an´ı chov´an´ı BitTorrent klienta a nalezen´ı zp˚usobu pro jeho ´uˇcinn´e odhalen´ı. V menˇs´ı m´ıˇre byl poˇc´ıtaˇc pouˇzit pro otestov´an´ı odhalen´ı jabber klienta komunikuj´ıc´ıho na portu pro https komunikaci. Dalˇs´ım pokusem byl po domluvˇe se spr´avcem s´ıtˇe veden´y simulovan´y DDoS ´utok.

Nejd˚uleˇzitˇejˇs´ım bodem t´eto pr´ace bylo objeven´ı princip˚u a vzor˚u popisovan´ych hrozeb. Po t´e, co byly objeveny charakteristick´e toky v popisovan´ych hrozbach, bylo mozn´e tyto hrozby efektivnˇe odhalit. Nyn´ı je moˇzn´e zjiˇstˇen´e v´ysledky zapracovat do libovoln´eho syst´emu pro detekci hrozeb v datov´e s´ıti pomoc´ı NetFlow dat a umoˇznit tak jejich odhalen´ı.

Ochrana datov´e s´ıtˇe se zd´a b´yt velmi perspektivn´ı, zvl´aˇstˇe na vysokorychlostn´ıch link´ach internetov´ych poskytovatel˚u. Zaj´ımav´a tak´e m˚uˇze b´yt pro univerzitn´ı s´ıtˇe a pro s´ıtˇe velk´ych firem. V obou pˇr´ıpadech jde o spr´avu rozs´ahl´ych s´ıt´ı, kter´a by byla pomoc´ı konvenˇcn´ıch prostˇredk˚u ponˇekud obt´ıˇzn´a. V bl´ızk´e budoucnosti lze oˇcek´avat zv´yˇsenou potˇrebu moni-torov´an´ı vysokorychlostn´ıch s´ıt´ı, a proto lze pˇredpokl´adat rozmach technologie NetFlow a j´ı obdobn´ych ˇreˇsen´ı schopn´ych pracovat na vysokorychlostn´ıch link´ach.

(28)

Literatura

[1] Alkharobi, T.: Firewalls. Kvˇeten 2007, [cit. 2009-4-27].

URLhttp://ocw.kfupm.edu.sa/user062/CSE55101/firewall.pdf

[2] Almquist, P.: Type of Service in the Internet Protocol Suite. ˇCervenec 1992, [cit. 2009-5-14].

URLhttp://rfc.sunsite.dk/rfc/rfc1349.html

[3] autor˚u, K.: Transmission Control Protocol. Srpen 1981, [cit. 2009-4-27]. URLhttp://www.ietf.org/rfc/rfc793.txt

[4] Bowers, D.: The State of Spam A Monthly Report–February 2009. Technick´a zpr´ava, Symantec, Bˇrezen 2009.

[5] Claise, B.: Cisco Systems NetFlow Services Export Version 9. ˇR´ıjen 2004, [cit. 2009-4-27].

URLhttp://www.ietf.org/rfc/rfc3954.txt

[6] Cohen, B.: The BitTorrent Protocol Specification. Leden 2008, [cit. 2009-5-10]. URLhttp://www.bittorrent.org/beps/bep_0003.html

[7] Developer Network: OSCAR Protocol — dev.aol.com. Bˇrezen 2008, [cit. 2009-5-14]. URLhttp://dev.aol.com/aim/oscar/

[8] Fyodor: Manu´alov´a str´anka programu Nmap. insecure.org, Z´aˇr´ı 2007, dostupno tak´e na http://nmap.org/book/man.html.

[9] Houser, P.: Jak´y botnet nejv´ıc spamuje? Duben 2009, [cit. 2009-4-28].

URLwww.securityworld.cz/securityworld/Jaky-botnet-nejvic-spamuje-1606

[10] Kasprzak, J.: Spam vˇcera, dnes, a bohuˇzel asi i z´ıtra. [cit. 2009-4-28]. URLhttp://www.fi.muni.cz/~kas/papers/spam.pdf

[11] ˇZ´adn´ık Martin: NetFlow. Str´anky pˇredmˇetu ISA, [cit. 2009-4-27].

[12] Quittek, J.; Zseby, T.; Claise, B.; aj.: Requirements for IP Flow Information Export (IPFIX). ˇR´ıjen 2004, [cit. 2009-4-27].

URLhttp://www.ietf.org/rfc/rfc3917.txt

[13] Rehak, M.; Celeda, P.; Pechoucek, M.; aj.: CAMNEP: Multistage Collective Network Behavior Analysis System with Hardware Accelerated NetFlow Probes. [cit.

2009-5-13].

(29)

[14] Thomas, T. M.:Zabezpeˇcen´ı poˇc´ıtaˇcov´ych s´ıt´ı bez pˇredchoz´ıch znalost´ı. Computer Press, 2004, ISBN 80-251-0417-6.

[15] Turek, R.: Botnety.

URLhttp://blog.synopsi.com/2008-04-27/botnety#ddos

[16] Vykopal, J.; Plesnik, T.; Minarik, P.: Validation of the Network-based Dictionary Attack Detection. In Security and Protection of Information 2009, 2009, ISBN 987-80-7231-641-0, s. 128–136.

[17] WWW str´anky: How to Choose A Firewall That is Right for Your Needs. [cit. 2009-4-27].

URLwww.apluskb.com/scripts/How_to_choose_a_Firewall_answer187.html

[18] WWW str´anky: The libTorrent and rTorrent Project. URLhttp://libtorrent.rakshasa.no/

[19] WWW str´anky: NetFlow Services Solutions Guide - Cisco Systems. [cit. 2009-5-15]. URLhttp://www.cisco.com/en/US/products/sw/netmgtsw/ps1964/products_ implementation_design_guide09186a00800d6a11.html

[20] WWW str´anky: Str´anka programu NfDump.

URLhttp://netflow.caligare.com/applications.htm

[21] WWW str´anky: Str´anka programu NfDump.

URLhttp://sourceforge.net/projects/nfdump/

[22] WWW str´anky: Str´anka programu NfSen. URLhttp://nfsen.sourceforge.net/

[23] WWW str´anky: VIRY.CZ: Win32/Stration.

URLhttp://www.viry.cz/go.php?p=viry&t=popis&id=218

[24] WWW str´anky: Bit Torrent: 35% of all Traffic. 2004, [cit. 2009-5-14]. URLhttp://www.dslreports.com/shownews/56403/

[25] WWW str´anky: Bittorrent Protocol Specification v1.0. Bˇrezen 2009, [cit. 2009-5-5]. URLhttp://wiki.theory.org/BitTorrentSpecification

[26] WWW str´anky: IDS a IPS syst´emy. [cit. 2009-4-28]. URLhttp://www.invea.cz/cs/solutions/ids-ips

(30)

Dodatek A

Obsah CD

• Zdrojov´e soubory t´eto pr´ace.

• Testovac´ı data.

Figure

Updating...