Network Protocol Analyzer

33  Download (0)

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

ANALYZ ´

ATOR S´I ˇ

TOV ´

YCH PROTOKOL ˚

U

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

DANIEL P ˇ

SORN

AUTHOR

(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

ANALYZ ´

ATOR S´I ˇ

TOV ´

YCH PROTOKOL ˚

U

NETWORK PROTOCOL ANALYZER

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

DANIEL P ˇ

SORN

AUTHOR

VEDOUC´I PR ´

ACE

Ing. JI ˇ

R´I TOBOLA

SUPERVISOR

(3)

Abstrakt

C´ılem t´eto pr´ace je nal´ezt zp˚usob, jak naprogramovat analyz´ator s´ıt’ov´eho provozu na nejvyˇsˇs´ı vrstvˇe modelu ISO/OSI. K tomu je nutn´e pouˇz´ıt nˇekterou z metod detekce aplikaˇcn´ıch protokol˚u. Program popsan´y v t´eto pr´aci pouˇz´ıv´a metodu zaloˇzenou na ˇc´ıslech port˚u a metodu zaloˇzenou na signatur´ach. C´ılov´a platforma je operaˇcn´ı syst´em FreeBSD. Imple-mentaˇcn´ım jazykem je jazyk C s pouˇzit´ım knihovny libpcap.

Kl´ıˇ

cov´

a slova

S´ıt’ov´a komunikace, Model ISO/OSI, FreeBSD, BPF, libpcap

Abstract

Object of this thesis is to find the way how to program network protocol analyzer on the highest level of ISO/OSI model. We need to use some of the methods for detection of application protocols. The software described in this thesis uses traditional application-level traffic identification method and signature-mapping-based method. Basic platform is FreeBSD operating system. Programming language is C using libpcap library.

Keywords

Network communication, Model ISO/OSI, FreeBSD, BPF, libpcap

Citace

Daniel Pˇsorn: Analyz´ator s´ıt’ov´ych protokol˚u, bakal´aˇrsk´a pr´ace, Brno, FIT VUT v Brnˇe, 2009

(4)

Analyz´

ator s´ıt’ov´

ych protokol˚

u

Prohl´

sen´ı

Prohlaˇsuji, ˇze jsem tuto bakal´aˇrskou pr´aci vypracoval samostatnˇe pod veden´ım pana Ing. Jiˇr´ıho Toboly. Uvedl jsem vˇsechny liter´arn´ı prameny a publikace, ze kter´ych jsem ˇcerpal.

. . . . Daniel Pˇsorn 23. ledna 2009

c

Daniel Pˇsorn, 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´avnˇen´ı autorem je nez´akonn´e, s v´yjimkou z´akonem definovan´ych pˇr´ıpad˚u.

(5)

Obsah

1 Uvod´ 2 2 S´ıt’ov´e protokoly 3 2.1 Model ISO/OSI . . . 3 2.2 TCP/IP . . . 4 2.3 Pˇrenos dat . . . 6 2.3.1 Aplikaˇcn´ı vrstva . . . 6 2.3.2 Transportn´ı vrstva . . . 6 2.3.3 Internetov´a vrstva . . . 7

2.3.4 Vrstva s´ıt’ov´eho rozhran´ı . . . 8

3 Technologie odchyt´av´an´ı s´ıt’ov´ych paket˚u 10 3.1 Berkeley Packet Filter . . . 11

3.2 Libpcap . . . 13

3.3 Anal´yza protokol˚u aplikaˇcn´ı vrstvy . . . 13

4 N´avrh a implementace 15 4.1 N´avrh . . . 15

4.1.1 Anal´yza probl´emu . . . 15

4.2 Implementace . . . 16

4.2.1 Odchyt´av´an´ı dat . . . 16

4.2.2 Zpracov´an´ı pˇrijat´ych dat . . . 17

4.2.3 Anal´yza payload . . . 19

5 Testov´an´ı a v´ysledky 21 5.1 Metodika testov´an´ı . . . 21

5.2 Testy a v´ysledky . . . 22

6 Z´avˇer 25

(6)

Kapitola 1

´

Uvod

Poˇc´ıtaˇcov´e s´ıtˇe a telekomunikaˇcn´ı technologie zaˇz´ıvaj´ı v posledn´ıch nˇekolika desetilet´ıch bouˇrliv´y rozvoj. Pˇredevˇs´ım ´uspˇech Internetu pˇrinesl s´ıt’ov´e technologie do komerˇcn´ı sf´ery a do velk´eho mnoˇzstv´ı dom´acnost´ı. D´ıky pˇripojen´ı do Internetu mohou uˇzivatel´e vyuˇz´ıvat mnoho sluˇzeb, od prohl´ıˇzen´ı webov´ych str´anek pˇres pouˇz´ıv´an´ı elektronick´e poˇsty, tele-fonov´an´ı aˇz po n´aroˇcn´e multimedi´aln´ı aplikace jako je sledov´an´ı videa. Abychom mohli vˇsechny tyto sluˇzby vyuˇz´ıvat, potˇrebujeme spolehliv´y chod poˇc´ıtaˇcov´e s´ıtˇe jako celku. Z toho d˚uvodu vzniklo velk´e mnoˇzstv´ı n´astroj˚u na monitorov´an´ı s´ıt´ı. Popisem jednoho zp˚usobu monitorov´an´ı, anal´yzou paket˚u, se zab´ıva tato pr´ace.

Pˇri n´avrhu analyz´atoru s´ıt’ov´ych protokol˚u je n˚utn´e d˚ukladnˇe se sezn´amit s principy fungov´an´ı poˇc´ıtaˇcov´e s´ıtˇe. Pro komunikaci mezi sebou pouˇz´ıvaj´ı zaˇr´ızen´ı s´ıt’ov´e protokoly. S´ıt’ov´y protokol je norma definovan´a na pap´ıˇre. Jako referenˇcn´ı norma je pouˇz´ıv´ana norma ISO/OSI, kter´a je pops´ana v druh´e kapitole. S´ıt’ Internet normu ISO/OSI nepouˇz´ıv´a, pouˇz´ıv´a s´ıt’ov´e protokoly rodiny TCP/IP.

Samotn´a technologie odchyt´av´an´ı paket˚u je pˇredstavena ve tˇret´ı kapitole. Nejprve jsou rozebr´any principy, jak´e je moˇzn´e pouˇz´ıt k odchyt´av´an´ı dat. Pot´e n´asleduje popis zaˇr´ızen´ı bpf (Berkeley Packet Filter), jejˇz bude vyuˇzt k odchyt´av´an´ı paket˚u. Nakonec je pops´ano programov´e vybaven´ı (API), kter´e je moˇzn´e pouˇz´ıt na realizaci s´ıt’ov´eho analyz´atoru. Na operaˇcn´ıch syst´emech unixov´eho typu je to knihovna libpcap a na operaˇcn´ıch syst´emech rodiny MS Windows je to knihovna winpcap.

ˇ

Ctvrt´a kapitola popisuje samotn´y n´avrh a implementaci analyz´atoru s´ıt’ov´ych paket˚u na aplikaˇcn´ı vrstvˇe. Je zde pops´ana jak metoda analyzov´an´ı na z´akladˇe ˇc´ısel port˚u, tak i metoda zaloˇzen´a na signatur´ach.

N´asleduj´ıc´ı kapitola shrnuje v´ysledky pr´ace a testov´an´ı, pˇr´ıpadnˇe porovn´av´a s jin´ymi podobn´ymi aplikacemi.

Posledn´ı kapitola je z´avˇer, ve kter´em je shrnuto hodnocen´ı implementovan´eho syst´emu. D´ale jsou zde navrˇzen´a r˚uzn´a zlepˇsen´ı, zejm´ena co se t´yˇce rychlosti detekov´an´ı aplikaˇcn´ıch protokol˚u.

(7)

Kapitola 2

S´ıt’ov´

e protokoly

Komunikace mezi poˇc´ıtaˇci je sloˇzit´a vˇec. Abychom tedy mohli porozumˇet anal´yze paket˚u, je d˚uleˇzit´e pochopit principy komunikace poˇc´ıtaˇc˚u navz´ajem. V t´eto kapitole se zamˇeˇr´ım na popis referenˇcn´ıho modelu ISO/OSI, architekturu TCP/IP a pˇrenos dat.

2.1

Model ISO/OSI

Referenˇcn´ı model ISO/OSI (Open Systems Interconnections) [7] byl vypracov´an organi-zac´ı ISO (International Organization for Standardization) a v roce 1984 byl schv´alen jako mezin´arodn´ı norma ISO 7489. Model OSI nespecifikuje implementaci konkr´etn´ıho proto-kolu, ale je abstraktn´ım popisem sedmivrstv´e s´ıt’ov´e architektury. Kaˇzd´a vrstva m´a funkce, kter´e vyuˇz´ıvaj´ı sluˇzeb nejbliˇzˇs´ı niˇzˇs´ı vrstvy a poskytuj´ı sv´e sluˇzby nejbliˇzˇs´ı vyˇsˇs´ı vrstvˇe. Sousedn´ı vrstvy mezi sebou komunikuj´ı pˇres pˇr´ıstupov´y bod sluˇzby (Service Access Point). Komunikace mezi dvˇema poˇc´ıtaˇci je zn´azornˇena na obr´azku 2.1.

Aplikační Prezentační Relační Transportní Síťová Linková Fyzická Aplikační program Aplikační Aplikační program Prezentační Relační Transportní Síťová Linková Fyzická Fyzická vrstva Aplikační vrstva Relační vrstva Prezentační vrstva Transportní vrstva Síťová vrstva Linková vrstva

Obr´azek 2.1: Komunikace na sedmivrstv´e architektuˇre ISO/OSI

(8)

Aplikaˇcn´ı vrstva

Aplikaˇcn´ı vrstva, nejvyˇsˇs´ı vrstva OSI modelu, poskytuje rozhran´ı aplikac´ım, pomoc´ı kter´eho mohou pˇristupovat k prostˇredk˚um komunikaˇcn´ıho syst´emu. Jedn´a se o r˚uzn´e sluˇzby typu elektronick´e poˇsty, pˇrenos soubor˚u pomoc´ı protokolu FTP nebo bezpeˇcn´e pˇrihl´aˇsen´ı na vzd´alen´y termin´al (SSH).

Prezentaˇcn´ı vrstva

Prezentaˇcn´ı vrstva m´a za ´ukol transformovat pˇr´ıchoz´ı data do vhodn´e podoby, kter´e pouˇz´ıv´a aplikaˇcn´ı vrstva. Jedn´a se pˇredevˇs´ım o k´odov´an´ı dat (probl´em nejvyˇsˇs´ıho bitu v bajtu) nebo zabezpeˇcen´ı pˇren´aˇsen´e informace ˇsifrov´an´ım, zabezpeˇcen´ı integrity dat aj.

Relaˇcn´ı vrstva

Relaˇcn´ı vrstva ˇr´ıd´ı sezen´ı (dialog) mezi dvˇema zaˇr´ızen´ımi, vˇcetnˇe zah´ajen´ı a ukonˇcen´ı spo-jen´ı.

Transportn´ı vrstva

Hlavn´ım c´ılem transportn´ı vrstvy je poskytov´an´ı spolehliv´eho spojen´ı mezi procesy. Trans-portn´ı vrstva se tedy nezab´yv´a spojen´ım mezi vzd´alen´ymi poˇc´ıtaˇci, ale zajiˇst’uje komuni-kaci mezi aplikacemi. Mezi dvˇema poˇc´ıtaˇci je tedy moˇzn´e m´ıt nˇekolik transportn´ıch spojen´ı souˇcasnˇe. Transportn´ı vrstva zajiˇst’uje jak spolehliv´y pˇrenos dat (ˇr´ızen´ı toku, potvrzov´an´ı pˇrijet´ı, poˇrad´ı paket˚u), tak i nespolehliv´e spojen´ı (bez pˇr´ım´eho nav´az´an´ı spojen´ı, nezajiˇst’uje potvrzov´an´ı). Adresov´an´ı aplikac´ı je jednoznaˇcn´e v r´amci jednoho zaˇr´ızen´ı.

S´ıt’ov´a vrstva

S´ıt’ov´a vrstva je zodpovˇedn´a za pˇrenos dat mezi vzd´alen´ymi poˇc´ıtaˇci. Star´a se o vytv´aˇren´ı s´ıt’ov´ych paket˚u a o jejich smˇerov´an´ı pˇri pr˚uchodu s´ıt´ı. S´ıt’ov´a vrstva je tak´e zodpovˇedn´a za jednoznaˇcn´e adresov´an´ı s´ıt’ov´eho rozhran´ı v cel´e s´ıti.

Linkov´a vrstva

Linkov´a vrstva zajiˇst’uje v´ymˇenu dat v r´amci lok´aln´ı s´ıtˇe nebo mezi dvˇema zaˇr´ızen´ımi. Z´akladn´ı jednotkou pro pˇrenos dat je datov´y r´amec, kter´y se skl´ad´a ze z´ahlav´ı, pˇren´aˇsen´ych dat a z´apat´ı. V z´ahlav´ı se nach´az´ı linkov´a adresa odes´ılatele a pˇr´ıjemce (MAC adresa) a ˇr´ıd´ıc´ı informace. V pˇren´aˇsen´ych datech jsou uloˇzeny informace pro vyˇsˇs´ı vrstvy. Z´ahlav´ı obsahuje kontroln´ı souˇcet, pomoc´ı nˇehoˇz lze zjistit, zda doˇslo k poˇskozen´ı dat pˇri pˇrenosu.

Fyzick´a vrstva

Fyzick´a vrstva je nejniˇzˇs´ı vrstva OSI modelu. Definuje fyzik´aln´ı a elektrick´e vlastnosti pouˇz´ıvan´e pˇri komunikaci mezi zaˇr´ızen´ımi. Fyzick´a vrstva zahajuje a ukonˇcuje spojen´ı, popisuje sign´aly na konektorech, urˇcuje napˇet’ov´e ´urovnˇe a specifikuje vlastnosti kabel˚u.

2.2

TCP/IP

Rodina protokol˚u TCP/IP je pojmenov´ana po dvou d˚uleˇzit´ych protokolech, kter´ymi jsou Transmission Control Protocol (TCP) a Internet Protocol (IP). V odborn´e literatuˇre je moˇzne se setkat i s n´azvy Internet Protocol Suite (IPS).

Soubor protokol˚u TCP/IP vznikl na ˇz´adost agentury DARPA (Defense Advanced Re-search Projects Agency) pro potˇreby v´aleˇcn´eho ohroˇzen´ı. Jedn´a se o decentralizovan´y, ro-bustn´y syst´em, kter´y je nez´avisl´y na typu fyzick´eho m´edia - metalick´e veden´ı, optick´a

(9)

vl´akna, bezdr´atov´e technologie. Postupem ˇcasu se z rodiny protokol˚u TCP/IP stal stan-dard souˇcasn´eho Internetu.

Protokoly TCP/IP, jako vetˇsina protokol˚u v s´ıti Internet, jsou rozdˇeleny do vrstev. Vrstvy jsou ˇctyˇri, nejniˇzˇs´ı je vrstva s´ıt’ov´eho rozhran´ı, nasleduje internetov´a vrstva, trans-portn´ı vrstva a nejv´yˇs se nach´az´ı vrstva aplikaˇcn´ı.

Aplikační vrstva Prezentační vrstva Relační vrstva Transportní vrstva Síťová vrstva Linková vrstva Fyzická vrstva Model ISO/OSI Aplikační vrstva Transportní vrstva Internetová vrstva Vrstva síťového rozhraní Data TCP/UDP paket IP datagram Rámec Bit Model TCP/IP Datové jednotky

Obr´azek 2.2: Porovn´an´ı model˚u OSI a TCP

Aplikaˇcn´ı vrstva

Aplikaˇcn´ı vrstvu vyuˇz´ıvaj´ı programy, kter´e potˇrebuj´ı k pˇrenosu dat po s´ıti protokoly TCP/IP. Tato vrstva obsahuje aplikace jako je HTTP, FTP, Telnet a dalˇs´ı.

Transportn´ı vrstva

Transportn´ı vrstva poskytuje pˇrenos dat mezi aplikacemi bˇeˇz´ıc´ımi na vzd´alen´ych poˇc´ıtaˇc´ıch (vytv´aˇr´ı tzv. logick´e spojen´ı mezi procesy). Hlavn´ımi protokoly transportn´ı vrstvy jsou TCP (Transmission Control Protocol) a UDP (User Datagram Protocol). Protokol TCP zajiˇst’uje spolehliv´y pˇrenos dat, tzn. vytvoˇr´ı na dobu spojen´ı virtu´aln´ı okruh mezi aplikacemi. Pro-tokol UDP je na rozd´ıl od proPro-tokolu TCP nespojovan´a sluˇzba, tj. nezajiˇst’uje spolehliv´e spojeni. Odes´ılatel pouze odeˇsle UDP datagram a uˇz se v˚ubec nestar´a, zda doˇsel pˇr´ıjemci. Oba typy protokol˚u maj´ı sv´e v´yhod´y (UPD rychlost, TCP spolehlivost) i nev´yhody (UDP nespolehliv´e spojen´ı, TCP protokol je pomalejˇs´ı neˇz UDP).

Internetov´a vrstva

Internetov´a vrstva (t´eˇz naz´yvan´a s´ıt’ov´a vrstva) m´a za ´ukol dopravovat data mezi r˚uzn´ymi poˇc´ıtaˇci v Internetu, tj. i pˇres mnoh´e LAN. Na t´eto vrstvˇe je pouˇz´ıvan´y protokol IP (Inter-net Protocol). D´ıky protokolu IP jsou data od odes´ılatele smˇerov´ana na m´ısto urˇcen´ı pˇres smˇerovaˇce. Na cestˇe od odes´ılatele k pˇr´ıjemci se m˚uˇze vyskytovat nˇekolik smˇerovaˇc˚u.

Vrstva s´ıt’ov´eho rozhran´ı

Nejniˇzˇs´ı vrstva poskytuje pˇr´ıstup na pˇrenosov´e m´edium. Rodina protokol˚u TCP/IP pˇresnˇe nespecifikovala pˇr´ıstup na fyzick´e m´edium, je schopn´a pouˇz´ıvat r˚uzn´e pˇrenosov´e technologie (Ethernet, Token Ring, FDDI, Frame Relay, RS-232 aj.).

(10)

2.3

renos dat

Pˇri pˇrenosu dat po s´ıti se vyuˇz´ıv´a datov´ych jednotek (PDU - Protocol Data Unit), kter´e maj´ı na r˚uzn´ych vrstv´ach jin´e n´azvy. Nejmenˇs´ı jednotkou informace je jeden bit, jenˇz slouˇz´ı pro pˇrenos dat na nejniˇzˇs´ı, fyzick´e vrstˇe. Na druh´e vrstˇe je r´amec, n´asleduje IP datagram, TCP/UPD paket a posledn´ı jsou data (obr. 2.2) [7].

Pˇrenos informace z jednoho zaˇr´ızen´ı na druh´e vyuˇz´ıv´a zapouzdˇren´ı. Zapouzdˇren´ı je pro-ces, kdy doch´az´ı k pˇrenosu dat z vyˇsˇs´ı vrstvy do niˇzˇs´ı. Tedy nˇejak´y program chce poslat data na vzd´alen´y poˇc´ıtaˇc. K pˇrenosu pouˇzije model TCP/IP. Pomoc´ı sady pravidel aplikaˇcn´ıho protokolu vytvoˇr´ı zpr´avu a pˇred´a ji transportn´ı vrstˇe. Transportn´ı vrstva zpr´avu pˇrijme a pˇrid´a k n´ı z´ahlav´ı. Zpr´avu zapouzdˇr´ı (vznikne paket) a pˇred´a s´ıt’ov´e vrstvˇe. S´ıt’ov´a vrstva paket pˇrijme, pˇrid´a z´ahlav´ı, zpr´avu zapouzdˇr´ı (vznikne datagram) a pˇred´a linkov´e vrstvˇe. Linkov´a vrstva pˇrid´a z´ahlav´ı a z´apat´ı, kde je um´ıstˇen kontroln´ı souˇcet. Data zapouzdˇr´ı a vznikne r´amec, kter´y pˇred´a fyzick´e vrstvˇe. Fyzick´a vrstva pˇremˇen´ı r´amec na posloupnost bit˚u a odeˇsle je. Cel´y proces je zn´azornˇen na obr. 2.3. Nyn´ı n´asleduje podrobn´y rozbor z´ahlav´ı jednotliv´ych vrstev.

Data Data Záhlaví Data Data Zápatí Transportní vrstva Aplikační vrstva Síťová vrstva Záhlaví Záhlaví

Vrstva síťového rozhraní

Obr´azek 2.3: Zapouzdˇren´ı dat bˇehem pˇrenosu

2.3.1 Aplikaˇcn´ı vrstva

Aplikaˇcn´ı vrstva poskytuje pˇr´ıstup proces˚um ke komunikaˇcn´ımu syst´emu. Poskytuje velk´e mnoˇzstv´ı protokol˚u (ftp, http, xmpp aj.), kter´e definuj´ı pravidla s´ıt’ov´e komunikace a form´aty datov´ych struktur. Nˇekter´e sluˇzby vyˇzaduj´ı bud’ protokol TCP nebo protokol UDP. Jin´e sluˇzby jsou schopn´e vyuˇz´ıvat oba protokoly (z´aleˇz´ı na implementaci ˇci konfiguraci). Data mohou b´yt pˇren´aˇsena jak ve formˇe bin´arn´ı tak i textov´e.

2.3.2 Transportn´ı vrstva

´

Ukolem transportn´ı vrstvy je vytv´aˇret tzv. logick´e spojen´ı mezi procesy. Mezi nejd˚uleˇzitˇejˇs´ı protokoly transportn´ı vrstvy patˇr´ı TCP [17] a UDP [18]. Protokol TCP poskytuje spolehliv´y pˇrenos dat (doruˇc´ı adres´atovy data tak, jak byla odesl´ana). Nav´az´an´ı spojen´ı je realizov´ano

(11)

pomoc´ı mechanizmu three-way handshake. Protokol TCP dokonce umoˇzˇnuje, aby obˇe strany navazovaly spojen´ı souˇcasnˇe. TCP segment m´a strukturu zn´azornˇenou na obr. 2.4.

Zdrojový port (source port) Cílový port (destination port) Pořadové číslo odesílaného bajtu (sequence number)

0 8 16 24 31

Pořadové číslo přijatého bajtu (acknowledgment number) Délka

záhlaví Rezerva Příznaky (flags) Délka okna (window size) Kontrolní součet (TCP checksum) Ukazatel naléhavych dat(urgent pointer)

Volitelné položky záhlaví

DATA

Obr´azek 2.4: Z´ahlav´ı TCP paketu

Protokol UDP je narozd´ıl od protokolu TCP nespolehlivou nespojovanou sluˇzbou, tzn. nenavazuje spojen´ı. Odes´ılatel odeˇsle UDP datagram pˇr´ıjemci a uˇz se nestar´a, zda pˇr´ıjemci skuteˇcnˇe pˇriˇsel (o to se star´a vyˇsˇs´ı vrstva). Typicky se pouˇz´ıv´a v aplikac´ıch, kter´e poˇzaduj´ı jednoduchost a malou reˇzii spojenou s pˇrenosem. Z´ahlav´ı UDP datagramu je zn´azornˇeno na obr. 2.5

Adresov´an´ı na transportn´ı vrstvˇe je ˇreˇseno tzv. ˇc´ıslem portu, kter´y jednoznaˇcnˇe iden-tifikuje sluˇzbu na dan´em zaˇr´ızen´ı. ˇC´ıslo portu je dvoubajtov´e, takˇze m˚uˇze nab´yvat hodnot 0 aˇz 65535. U ˇc´ısel port˚u se t´eˇz ud´av´a typ protokolu zapisovan´y za lom´ıtko. Pro protokol UDP je jin´a sada protokol˚u neˇz pro protokol TCP, tzn. port 53/tcp nem´a nic spoleˇcn´eho s portem 53/udp. Seznam pˇridˇelen´ych port˚u se na operaˇcn´ıch syst´emech unixov´eho typu nach´az´ı v souboru /etc/services.

Zdrojový port (source port) Cílový port (destination port)

0 16 31

Kontrolní součet (UDP checksum) Délka dat (UDP length)

DATA

Obr´azek 2.5: Z´ahlav´ı UDP paketu

2.3.3 Internetov´a vrstva

Internetov´a vrstva umoˇzˇnuje propojit jednotliv´e lok´aln´ı s´ıtˇe do celosvˇetov´eho Internetu. Obsahuje jeden ze z´akladn´ıch komunikaˇcn´ıch protokol˚u, protokol IP (Internet Protocol [16]). IP protokol je tvoˇren nˇekolika d´ılˇc´ımi protokoly a to jsou samotn´y protokol IP, sluˇzebn´ı

(12)

protokoly ICMP a IGMP a sluˇzebn´ı protokoly ARP a RARP, kter´e jsou ˇcasto vyˇcleˇnov´any jako samostatn´e, protoˇze jejich r´amce neobsahuj´ı IP z´ahlav´ı. Struktura IP datagramu je na obr. 2.6.

Verze IP Celková délka IP datagramu Identifikace IP datagramu 0 8 16 24 31 Doba života Datagramu (TTL) IP adresa odesilatele IP adresa příjemce Volitelné položky záhlaví

DATA

Délka

záhlaví Typ služby

Příznaky Posunutí fragmentu od počatku Protokol vyšší

vrstvy Kontrolní součet z IP záhlaví(checksum)

Obr´azek 2.6: Z´ahlav´ı IP datagramu

Adresov´an´ı na internetov´e vrstvˇe je reprezentov´ano IP adresou, coˇz je 32-bitov´e ˇc´ıslo oddˇelen´e teˇckami. Napˇr. 147.229.201.5 je platn´a IP adresa v s´ıti Internet. IP adresa jedno-znaˇcnˇe identifikuje s´ıt’ov´e rozhran´ı syst´emu (anglicky se jednoznaˇcn´a adresa naz´yv´a uni-cast). Pokud m´a syst´em (poˇc´ıtaˇc) v´ıce s´ıt’ov´ych rozhran´ı, pak kaˇzd´e rozhran´ı m´a svoj´ı IP adresu. Je tak´e moˇzn´e pouˇz´ıvat v´ıce IP adres na jednom s´ıt’ov´em rozhran´ı. Struktura adresy se skl´ad´a z ˇc´asti, kter´a identifikuje s´ıt’, ve kter´e se poˇc´ıtaˇc nach´az´ı a z ˇc´asti identifikuj´ıc´ı poˇc´ıtaˇc. IP adresy v Internetu pˇridˇeluje organizace Internet Assign Numbers Authority (IANA). V souˇcasn´e dobˇe se pouˇz´ıv´a IP protokol verze 4 (IPv4) a verze 6 (IPv6). Nicm´enˇe IPv6 se zat´ım moc nerozˇs´ıˇril. Existence dvou verz´ı je z d˚uvodu nedostatku adresn´ıho pro-storu u IP verze 4.

Problematika adresace je velice sloˇzit´a a vydala by na naps´an´ı samotn´e pr´ace. Proto z´ajemce odkazuji na pˇr´ısluˇsnou literaturu [7].

2.3.4 Vrstva s´ıt’ov´eho rozhran´ı

Rodina protokol˚u TCP/IP se nezab´yv´a linkovou a fyzickou vrstvou. Proto je moˇzn´e tyto protokoly provozovat na r˚uzn´ych s´ıt´ıch typu WAN (Wide Area Network - rozs´ahl´e s´ıtˇe) a LAN (Local Area Network - lok´aln´ı s´ıtˇe). Jelikoˇz analyz´ator s´ıt’ov´eho provozu popisovan´y v t´eto pr´aci bude um´ıstˇen v lok´aln´ı s´ıti, je zde pops´ana pouze technologie Ethernet.

Poˇc´ıtaˇcov´a s´ıt’ Ethernet byla vyvinuta firmami DEC, Intel a Xerox. P˚uvodn´ı Ethernet pracoval s pˇrenosovou rychlost´ı 10Mb/s, pozdˇejˇs´ı varianta uvedena na trh pod n´azvem Fast Ethernet umoˇzˇnovala pouˇz´ıvat rychlost 100 Mb/s. V souˇcasn´e dobˇe je bˇeˇznˇe pouˇz´ıv´an tzv. Gigabit Ethernet pracuj´ıc´ı rychlost´ı 1000 Mb/s.

K pˇrenosu dat se pouˇz´ıv´a ethernetov´y r´amec, kter´y m´a promˇenlivou d´elku. Minim´aln´ı d´elka je 68 byt˚u (544 bit˚u), maxim´aln´ı 1522 byt˚u (12176 bit˚u) [7]. Struktura r´amce je zobrazena na obr. 2.7.

Ethernet m´a na zaˇc´atku synchronizaˇcn´ı preambuli, kter´a je souˇc´ast´ı fyzick´e vrstvy. N´asleduje MAC (Media Access Control) adresa pˇr´ıjemce a odes´ılatele, coˇz je 48 bitov´e

(13)

Adresa

příjemce odesílateleAdresa RámceTyp DATA

Záhlaví CRC

64 bitů 48 bitů 48 bitů 16 bitů 368 - 12000 bitů 64 bitů

Obr´azek 2.7: Form´at Ethernet r´amce

ˇ

c´ıslo, kter´e jednoznaˇcnˇe identifikuje s´ıt’ov´e rozhran´ı. MAC adresa je rozˇelena na dvˇe ˇc´asti. Prvn´ı ˇc´ast identifikuje v´yrobce dan´eho zaˇr´ızeni a druhou ˇc´ast urˇcuje s´am v´yrobce, aby definoval celosvˇetovou jedineˇcnost zaˇr´ızen´ı. Typ r´amce pro normu IEEE 802.3 vyjadˇruje d´elku datov´eho pole v bajtech a pro normu Ethernet II (pouˇz´ıv´ano protokolem TCP/IP) urˇcuje typ paketu. N´asleduje promˇenn´e pole, kter´e obsahuje data vyˇsˇs´ı (internetov´e vrstvy) a kontroln´ı souˇcet (CRC).

(14)

Kapitola 3

Technologie odchyt´

av´

an´ı s´ıt’ov´

ych

paket˚

u

V souˇcasn´e dobˇe existuje velk´e mnoˇzstv´ı n´astroj˚u na odchyt´av´an´ı paket˚u jak na operaˇcn´ıch syst´emech typu Unix, tak i na syst´emech MS Windows. Rozsah t´eto pr´ace neumoˇzˇnuje popsat jednotliv´e n´astroje na r˚uzn´ych operaˇcn´ıch syst´emech, proto se zamˇeˇr´ım na syst´emy unixov´eho typu (konkr´etnˇe FreeBSD [13]). Nebudu zde popisovat jednotliv´e aplikace, ale n´astroje a techniky, pomoc´ı kter´ych je moˇzn´e aplikace naprogramovat. Existuj´ı jˇestˇe hard-warov´a ˇreˇsen´ı, nicm´enˇe tˇem se vˇenovat tak´e nebudu.

Hlavn´ı v´yhodou softwarov´ych n´astroj˚u na odchyt´av´an´ı paket˚u je jejich univerz´alnost. Naopak velk´a nev´yhoda spoˇc´ıv´a v mal´e vykonnosti u vysokorychlostn´ıch s´ıt´ı. D´ıky tˇemto probl´em˚um vznikly dva pˇr´ıstupy n´avrhu a implementace s´ıt’ov´ych analyz´ator˚u [15].

Demux

process Network Kernel Destinationprocess

Obr´azek 3.1: Pˇrep´ın´an´ı na ´urovni uˇzivatelsk´eho procesu

Prvn´ı pˇr´ıstup vyuˇz´ıv´a dˇelen´ı toku dat na ´urovni uˇzivatelsk´eho procesu (obr´azek ˇc. 3.1). Jak je z obr´azku patrn´e, doruˇcen´ı dat ze s´ıt’ov´eho toku c´ılov´emu procesu je celkem n´aroˇcn´e, coˇz je velk´a nev´yhoda. Naopak v´yhodou pouˇzit´ı pomocn´eho procesu na ˇr´ızen´ı toku dat je v jednoduch´e implementaci analyz´atoru.

(15)

syst´emu se t´yk´a s´ıt’ov´ych sluˇzeb. Proto i samotn´y n´astroj pro odchyt´av´an´ı paket˚u je um´ıstˇen v j´adˇre (obr´azek ˇc. 3.2). Z obr´azku proti pˇredchoz´ımu ˇreˇsen´ı je vidˇet, ˇze pokud je analyz´ator souˇc´ast´ı j´adra, dok´aˇze stejnou sluˇzbu vykon´avat mnohem rychleji. Dalˇs´ım nezanedbateln´ym pozitivem je i moˇznost aplikovat jednoduch´y filtr, kter´y dok´aˇze propustit konkr´etn´ı pakety. T´ım se n´am propustnost dat jeˇstˇe zv´yˇs´ı.

Network Kernel Destinationprocess

Obr´azek 3.2: Pˇrep´ın´an´ı na ´urovni j´adra

Mezi nev´yhody patˇr´ı pˇredevˇs´ım sloˇzitost realizace analyz´atoru jako souˇc´ast j´adra. Pˇri ladˇen´ı a hled´an´ı chyb v analyz´atoru ˇcasto doch´az´ı k nenad´al´ym p´ad˚um nebo k zatuhnut´ı operaˇcn´ıho syst´emu. Na z´akladˇe tˇechto probl´em˚u vzniklo nˇekolik v´ıce ˇc´ı m´enˇe ´uspˇeˇsn´ych projekt˚u. Mezi zn´am´e patˇr´ı napˇr. syst´em NIT (Network Interface Tap), kter´y byl uvolnˇen spoleˇcnˇe s operaˇcn´ım syst´emem SunOS 4.1, nebo syst´em BPF (Berkeley Packet Filter).

3.1

Berkeley Packet Filter

Berkeley Packet Filter (BPF) [14] [20] [11] je souˇc´ast j´adra operaˇcn´ıho syst´emu, kter´y umoˇzˇnuje pln´y (

”raw“) pˇr´ıstup na linkovou vrstvu s´ıt’ov´eho rozhran´ı. BPF pouˇz´ıv´a rozho-dovac´ı filtr pracuj´ıc´ı na registrech, d´ıky ˇcemuˇz dosahuje vysok´e propustnosti dat. P˚uvodn´ı unixov´y paketov´y filtr pouˇz´ıval rozhodovac´ı mechanismus zaloˇzen´y na principu z´asobn´ıku, a proto byl aˇz 20 kr´at pomalejˇs´ı.

BPF m´a dlouhou, t´emˇeˇr 30ti letou historii. Pˇredch˚udce BPF je paketov´y filtr Enet, kter´y byl vytvoˇren v roce 1980 p´any Mike Accetta a Rick Rashid na Carnegie Mellon University. Filtr Enet byl ´uspˇeˇsn´y, a proto ho Jeffrey Mogul [15] pˇrenesl na operaˇcn´ı syst´em BSD (Berkeley Software Distribution), kde ho d´ale do roku 1983 vylepˇsoval. D´ıky desetilet´emu v´yvoji filtru Enet vznik´a v roce 1990 BPF. Autory jsou p´anov´e Steven McCanne a Van Jacobson.

BPF se skl´ad´a z n´asled˚uj´ıc´ıch dvou souˇc´ast´ı. Prvn´ı ˇc´ast je s´ıt’ov´y odposlech (Network Tap) a druh´a ˇc´ast je paketov´y filtr. Na obr´azku 3.3 je zn´azornˇen cel´y syst´em odchyt´av´an´ı paket˚u.

S´ıt’ov´e funkce operaˇcn´ıho syst´emu norm´alnˇe (bez spuˇstˇen´eho BPF) funguj´ı tak, ˇze pa-kety pˇrich´azej´ı na rozhran´ı s´ıt’ov´e karty, kter´e jsou d´ale pˇred´av´any do z´asobn´ıku s´ıt’ov´ych protokol˚u. Jakmile je BPF aktivov´an (zaˇcne poslouchat na rozhran´ı s´ıt’ov´e karty), ˇcinnost s´ıt’ov´eho podsyst´emu j´adra se zmˇen´ı. Pˇri doruˇcen´ı paketu na rozhran´ı s´ıt’ov´e karty jsou data nejdˇr´ıve pˇred´ana BPF, a pot´e i do z´asobn´ıku s´ıt’ov´ych protokol˚u (kde jsou d´ale

(16)

zpra-Buffer Buffer Buffer

Filter Filter Filter

BPF

Network Tap Network Interface Card (NIC) driver Other protocol stacks Kernel Kernel Network User Packets User code Libpcap Library User code Libpcap Library User code Direct access to the BPF

Obr´azek 3.3: Berkeley Packet Filter

cov´ana pˇr´ısluˇsnou aplikac´ı). BPF pˇrevezme data a pˇred´a je do filtru ke zpracov´an´ı. Ve filtru jsou uˇzivatelem definov´ana pravidla, kter´a urˇcuj´ı, zda budou ˇci nebudou moci data putovat do vyrovn´avac´ı pamˇeti (buffer) a pak d´ale k pˇr´ısluˇsn´emu procesu. Jakmile jsou data ve vyrovn´avac´ı pamˇeti, BPF pˇred´av´a ˇr´ızen´ı s´ıt’ov´e kartˇe a ˇcek´a na dalˇs´ı pˇr´ıchoz´ı paket.

Jelikoˇz BPF filtruje kaˇzd´y paket, kter´y mu je pˇred´an a ˇcas mezi doruˇcen´ymi pakety je velmi mal´y (ˇr´adovˇe mikrosekundy), nen´ı moˇzn´e pouˇz´ıt pro kaˇzd´y paket syst´emov´e vol´an´ı

read. Z toho d˚uvodu je pouˇzita vyrovn´avac´ı pamˇet’, kter´a je rozdˇelena na dvˇe ˇc´asti (store

a hold). Do ˇc´asti store se ukl´adaj´ı pˇr´ıchoz´ı data. Jakmile dojde k naplnˇen´ı, obˇe ˇc´asti BPF prohod´ı. Nyn´ı se z ˇc´asti store st´av´a ˇc´ast hold, kter´a uvoln´ı data uˇzivatesk´emu procesu. T´ım je vypr´azdnˇena a ˇcek´a na zaplnˇen´ı store ˇc´asti a na n´aslednou v´ymˇenu. Pomoc´ı tohoto mechanismu m´a BPF vysokou datovou propustnost.

(17)

3.2

Libpcap

Libpcap [2] [9] je program´atorsk´e rozhran´ı (API), kter´e poskytuje n´astroje k odchyt´av´an´ı a filtrov´an´ı paket˚u. Vytv´aˇr´ı abstraktn´ı rozhran´ı mezi samotnou aplikac´ı a j´adrem operaˇcn´ıho syst´emu, d´ıky ˇcemuˇz je n´avrh a realizace programu jednoduˇsˇs´ı.

Knihovna pracuje na uˇzivatelsk´e ´urovni, nen´ı tolik z´avisl´a na operaˇcn´ım syst´emu, a proto ji bylo moˇzn´e ´uspˇeˇsnˇe pˇren´est na nˇekolik druh˚u operaˇcn´ıho syst´emu Unix. Nev´yhodou nˇekter´ych Unix˚u je absence BPF (napˇr. Solaris), d´ıky ˇcemuˇz mus´ı knihovna libpcap emulo-vat BPF a jej´ı v´ykonnost kles´a. Na operaˇcn´ıch syst´emech rodiny Windows existuje knihovna WinPcap [3], kter´a m´a podobn´e vlastnosti jako knihovna libpcap. Pomoc´ı knihovny libpcap je vytvoˇren i tento analyz´ator, v´ıce o implementaci je v n´asleduj´ıc´ı kapitole.

3.3

Anal´

yza protokol˚

u aplikaˇ

cn´ı vrstvy

Anal´yza protokol˚u na s´ıt’ov´e a transportn´ı vrstvˇe nen´ı sloˇzit´a, protoˇze vˇsechny d˚uleˇzit´e infor-mace jsou pˇren´aˇsen´e v z´ahlav´ı pˇr´ısluˇsn´e vrstvy. N´aroˇcnˇejˇs´ı na anal´yzu je ale vrstva nejvyˇsˇs´ı, aplikaˇcn´ı. Pˇri zkoum´an´ı payload (samostatn´a pˇren´aˇsen´a data, bez TCP/IP z´ahlav´ı) m˚uˇzeme vyuˇz´ıt ˇc´ıslo portu [1] z TCP/UDP z´ahlav´ı. Toto ˇreˇsen´ı nen´ı ´uplnˇe ide´aln´ı, protoˇze vˇetˇsina port˚u nem´a pˇridˇelen´e konkr´etn´ı ˇc´ıslo. Situaci komplikuj´ı i novˇe vznikaj´ıc´ı sluˇzby a pro-gramy, kter´e si ˇc´ısla port˚u n´ahodnˇe vyb´ıraj´ı. Proto vzniklo nˇekolik metod na identifikov´an´ı a anal´yzu dat na aplikaˇcn´ı ´urovni [12] [8].

• Bˇeˇzn´a metoda urˇcov´an´ı aplikaˇcn´ıch protokol˚u

Bˇeˇzn´a metoda je zaloˇzen´a na dobˇre zn´am´ych ˇc´ıslech port˚u. Zn´am´a ˇc´ısla mus´ı b´yt menˇs´ı neˇz 1024 a nebo mus´ı b´yt uvedena na seznamu orgranizace IANA [1]. Pomoc´ı ˇc´ısel port˚u m˚uˇzeme snadno rozpoznat pouˇzit´y protokol. Dˇr´ıve tato metoda dostaˇcovala k identifikaci t´emˇeˇr veˇsker´eho s´ıt’ov´eho provozu. V´yhoda bˇeˇzn´e metody je v jedno-duch´e implementaci. Hlavn´ı nev´yhoda je neschopnost identifikace dynamicky genero-van´ych ˇc´ısel port˚u (napˇr. stremov´an´ı multim´edi´ı).

• Metoda zaloˇzen´a na vyˇsetˇrov´an´ı payload

Metoda zaloˇzen´a na vyˇsetˇrov´an´ı dat nejvyˇsˇs´ı vrstvy je schopn´a odhalit aplikace, kter´e vyuˇz´ıvaj´ı dynamick´e generov´an´ı ˇc´ısel port˚u. ˇCasto se s touto metodou setk´ame u strea-mov´an´ı hudby nebo videa a taky u Peer-to-Peer (P2P) program˚u, kde je nutn´e vytvoˇrit kontroln´ı a datov´y kan´al mezi komunikuj´ıc´ımi stranami. Metoda je velice pˇresn´a, coˇz je jej´ı v´yhoda. Naopak nepˇr´ıjemn´e je, ˇze v´ıce zatˇeˇzuje syst´em, a proto m˚uˇze m´ıt niˇzˇs´ı propustnost.

• Metoda zaloˇzen´a na signatur´ach

Metoda vyuˇz´ıvaj´ıc´ı signatury (signatura je textov´y ˇretˇezec) je zaloˇzen´a na faktu, ˇze ˇc´ast aplikaˇcn´ıho protokolu je jednoznaˇcnˇe urˇcena. Signatura pˇresnˇe odpov´ıd´a charak-teristick´e ˇc´asti protokolu. Pˇri anal´yze je kaˇzd´y payload porovn´an se signaturou. D´ıky porovn´av´an´ı vˇsech paket˚u je pˇresnost metody vysok´a. Naopak nepˇr´ıjemn´a je velk´a n´aroˇcnost na syst´emov´e prostˇredky.

• Metoda pouˇz´ıvan´a k identifikaci P2P provozu

V posledn´ı dobˇe se mnoˇzstv´ı pˇrenesen´ych dat posouv´a od klasick´ych sluˇzeb (web, e-mail) ke sd´ılen´ı soubor˚u a pˇren´aˇsen´ı velk´eho objemu dat. Existuje spousty program˚u

(18)

nab´ızej´ıc´ıch sluˇzby typu P2P, DirectConnect nebo KaZaA. ˇCasto jsou pˇren´aˇsen´y ne-leg´aln´ı soubory a je nutn´e tyto sluˇzby omezit. Proto byly vytvoˇreny speci´aln´ı ana-lyz´atory na konkr´etn´ı typ sluˇzby, napˇr. DirectConnect. ´Uˇcinnost tˇechto analyz´atoru je vysok´a, pouze pokud’ jsou pouˇzity na konkr´etn´ı protokol, na kter´y byly vytvoˇreny.

(19)

Kapitola 4

avrh a implementace

V t´eto kapitole nejprve na z´akladˇe anal´yzy dan´eho probl´emu zvol´ım nejvhodnˇejˇs´ı ˇreˇsen´ı a pot´e pop´ıˇsu implementaci koneˇcn´e aplikace. C´ılem n´avrhu a implementace je co nejrych-lejˇs´ı ˇcinnost analyz´atoru s´ıt’ov´eho provozu, a tak´e schopnost bˇehu na r˚uzn´ych operaˇcn´ıch syst´emech unixov´eho typu (FreeBSD, Linux, Solaris aj.).

4.1

avrh

Kvalitn´ı n´avrh aplikace je pro v´yvoj kl´ıˇcov´y, protoˇze se od nˇej odv´ıjej´ı veˇsker´e vlast-nosti koneˇcn´eho programu. Je tedy d˚uleˇzit´e vˇenovat n´avrhu patˇriˇcnou pozornost. Jako nejv´yhodnˇejˇs´ı se mi jev´ı prozkoumat podobn´e n´astroje na analyzov´an´ı s´ıt’ov´eho provozu (tcpdump, wireshark, snort atd.) a pot´e implementovat pouˇzit´e techniky z tˇechto n´astroj˚u.

4.1.1 Anal´yza probl´emu

Aby bylo moˇzn´e navrhnout co moˇzn´a nejefektivnˇejˇs´ı ˇreˇsen´ı dan´eho probl´emu, je nutn´e ho d˚ukladnˇe analyzovat. Tato anal´yza by mˇela odpovˇedˇet na dvˇe hlavn´ı ot´azky, kter´ymi jsou:

• Jak´y pouˇz´ıt syst´em na odchyt´av´an´ı paket˚u s´ıt’ov´e komunikace?

• Jak efektivnˇe analyzovat provoz na aplikaˇcn´ı vrstvˇe?

Odpovˇed’ na prvn´ı ot´azku nen´ı tolik n´aroˇcn´a, protoˇze v souˇcasn´e dobˇe existuje velk´e mnoˇzstv´ı ˇreˇsen´ı. Na odchyt´av´an´ı paket˚u je moˇzn´e pouˇz´ıt jak speci´aln´ı hardwarov´a zaˇr´ızen´ı, tak i optimalizovan´e softwarov´e n´astroje. V´yhodou hardwarov´ych zaˇr´ızen´ı je vysok´a efekti-vita odchyt´av´an´ı s´ıt’ov´eho provozu. Nopak nepˇr´ıjemn´a je horˇs´ı dostupnost tˇechto zaˇr´ızen´ı, a tak´e cena je dost vysok´a. U softwarov´ych n´astroj˚u je situace opaˇcn´a. Jsou snadno dostupn´e, nˇekter´e se distribuuj´ı pod svobodnou licenc´ı. Mezi dalˇs´ı v´yhodu patˇr´ı univerz´alnost ˇreˇsen´ı. V t´eto pr´aci byl pouˇzit softwarov´y n´astroj na odchyt´av´an´ı paket˚u, konkr´etnˇe knihovna libpcap [2].

Zodpovˇezen´ı druh´e ot´azky je o nˇeco n´aroˇcnˇejˇs´ı. Jeˇstˇe v ned´avn´e minulosti se na roz-pozn´av´an´ı protokol˚u aplikaˇcn´ı vrstvy v´yhradnˇe pouˇz´ıvaly ˇc´ısla port˚u [1]. Nicm´enˇe v souˇcasn´e dobˇe nen´ı tento mechanizmus tak spolehliv´y. D˚uvodem je pouˇz´ıv´an´ı r˚uzn´ych aplikac´ı, kter´e vyuˇz´ıvaj´ı ke komunikaci s protistranou dynamicky generovan´a ˇc´ısla port˚u. Z tohoto d˚uvodu vzniklo nˇekolik mechanizm˚u, kter´e analyzuj´ı pakety jinou metodou neˇz jenom zkoum´an´ım ˇ

(20)

ˇretˇezce specifick´e pro konkr´etn´ı aplikaˇcn´ı protokol. V t´eto pr´aci je nejen pouˇzita metoda zaloˇzen´a na detekci ˇc´ısel port˚u, ale i metoda zaloˇzen´a na signatur´ach.

Nem´enˇe d˚uleˇzit´e je i pouˇzit´ı vhodn´eho operaˇcn´ıho syst´emu. Jak jsem se zm´ınil dˇr´ıve, popisovan´a aplikace vyuˇz´ıv´a knihovnu libpcap a je ji moˇzn´e pouˇz´ıvat na operaˇcn´ım syst´emu FreeBSD. Je moˇzn´e ale pouˇz´ıt jin´e kombinace, jako napˇr. OS Linux. Take existuj´ı n´astroje vhodn´e pro operaˇcn´ı syst´emy rodiny Microsoft Windows, konkr´etnˇe knihovna winpcap.

4.2

Implementace

Bˇehem v´yvoje byl jako referenˇcn´ı pouˇzit osobn´ı poˇc´ıtaˇc s procesorem architektury i386, konkr´etnˇe AMD Athlon 1800+. Pamˇeti bylo moˇzn´e vyuˇz´ıt 1024 MB. S´ıt’ov´e rozhran´ı poˇc´ıtaˇce je typu Ethernet. Jako implementaˇcn´ı jazyk byl pouˇzit jazyk C. S´ıt’ov´y analyz´ator je rozdˇelen na dvˇe ˇc´asti. Jedna se star´a o odchyt´av´an´ı s´ıt’ov´eho provozu a druh´a o samotn´e dek´odov´an´ı komunikace. Cel´y syst´em je zn´azornˇen na obr´azku ˇc. 4.1.

Jádro analyzátoru (libpcap/BPF) TCP/UDP Filtr Analýza TCP paketu Analýza UDP paketu Odchytávání dat Analyzování dat

Obr´azek 4.1: Sch´ema analyz´atoru

4.2.1 Odchyt´av´an´ı dat

J´adrem s´ıt’ov´eho analyz´atoru je syst´em na odchyt´av´an´ı dat, kter´y je implementov´an pomoc´ı knihovny libpcap. D´ıky t´eto knihovnˇe je vytvoˇren´ı j´adra analyz´atoru jednoduˇsˇs´ı, protoˇze nen´ı nutn´e pˇristupovat k n´ızko´urovˇnov´ym funkc´ım operaˇcn´ıho syst´emu.

Prvn´ı vˇec, jenˇz program mus´ı vykonat, je zjiˇstˇen´ı jm´ena s´ıt’ov´eho zaˇr´ızen´ı, na kter´em bude odposlouch´avat s´ıt’ovou komunikaci. Jelikoˇz je velmi ˇcast´e, ˇze poˇc´ıtaˇc obsahuje v´ıce s´ıt’ov´ych karet, je dobr´e vyhledat vˇsechny n´azvy (zajist´ı funkce pcap findalldevs()), a pot´e si spr´avnˇe ze seznamu vybrat. N´asleduje nastaven´ı s´ıt’ov´e karty na odposlouch´av´an´ı a

(21)

pˇrepnut´ı do tzv.promiskuitn´ıho reˇzimu. Promiskuitn´ı reˇzim zp˚usob´ı, ˇze s´ıt’ov´a karta pˇrij´ım´a veˇsker´e r´amce linkov´e vrstvy.

Nev´yhodou pˇr´ıj´ıman´ı vˇsech linkov´ych r´amc˚u je v zahlcen´ı syst´emu. Jakmile ˇcas potˇrebn´y k anal´yze jednoho r´amce je vyˇsˇs´ı neˇz rozd´ıl ˇcas˚u po sobˇe jdouc´ıch r´amc˚u, doch´az´ı ke ztr´atˇe pˇrijat´ych r´amc˚u a t´ım i nemoˇznost urˇcit aplikaˇcn´ı protokol. Proto je vhodn´e vyuˇz´ıt pake-tov´y filtr BPF [14], kter´y umoˇzˇnuje filtrovat data na s´ıt’ov´e a transportn´ı vrstvˇe. Zaˇr´ızen´ı BPF odposlouch´av´a data na ´urovni j´adra operaˇcn´ıho syst´emu a je d´ıky tomu velmi efek-tivn´ı. Konfigurace filtru je velice rozs´ahl´a a ani nen´ı pˇredmˇetem t´eto pr´ace. ´Upln´y popis jednotliv´ych v´yraz˚u je moˇzn´e naj´ıt v manu´alov´ych str´ank´ach programu tcpdump [10].

Pokud je s´ıt’ov´e rozhran´ı spr´avnˇe nastaveno a BFP zaˇr´ızen´ı vhodnˇe nakonfigurov´ano, m˚uˇze zaˇc´ıt odposlouch´av´an´ı s´ıt’ov´e komunikace a pˇred´av´an´ı dat analyz´atoru aplikaˇcn´ıch pro-tokol˚u. Knihovna libpcap pˇri kaˇzd´em zachycen´em r´amci pˇred´av´a ukazatel na jeho zaˇc´atek a z´aroveˇn strukturu pcap pkthdr, ve kter´e je uloˇzen ˇcas odchycen´ı r´amce, velikost odchy-cen´ych dat a skuteˇcnou velikost dat. Pˇrijat´a data odeb´ır´a druh´a ˇc´ast analyz´atoru, kter´a m´a za ´ukol prov´est rozbor kaˇzd´eho r´amce a zjistit protokol aplikaˇcn´ı vrstvy pˇr´ıpadnˇe jin´e informace.

4.2.2 Zpracov´an´ı pˇrijat´ych dat

Jelikoˇz knihovna libpcap pˇred´av´a ukazatel na zaˇc´atek odchycen´eho r´amce (obr´azek ˇc. 4.2), nen´ı moˇzn´e hned analyzovat data na aplikaˇcn´ı vrstvˇe, ale je potˇreba se k nim nejdˇr´ıve dostat, tzn. vhodnˇe posunout ukazatel na zaˇc´atek aplikaˇcn´ı vrstvy. Proto je velmi d˚uleˇzit´e zn´at pˇresn´e uspoˇr´ad´an´ı hlaviˇcky kaˇzd´e vrstvy.

Ethernet

Header IP Header UDP/TCPHeader Payload

Obr´azek 4.2: Odchycen´y r´amec

Prvn´ı z´ahlav´ı na obr´azku 4.2 je z´ahlav´ı vrstvy s´ıt’ov´eho rozhran´ı ethernet. Skl´ad´a se z MAC (Media Access Control) adresy pˇr´ıjemce a z MAC adresy odes´ılatele. Posledn´ı poloˇzka m´a dvoj´ı pouˇzit´ı. Pokud struktura r´amce odpov´ıd´a normˇe Ethernet II, pot´e tato poloˇzka nese typ protokolu. Pokud struktura r´amce odpov´ıd´a normˇe ISO 8802-3, tak v t´eho ˇ

c´asti je zaznamen´ana d´elka pˇren´aˇsen´ych dat. V souˇcasn´e dobˇe se v naprost´e vˇetˇsinˇe pˇr´ıpad˚u v Internetu setk´av´ame s protokolem Etherent II. Velikost hlaviˇcky je 14 bajt˚u. Abychom mohli z´ıskat jednotliv´e ud´aje z hlaviˇcky, je nutn´e v jazyce C definovat n´asleduj´ıc´ı strukturu:

struct ether_header {

u_char ether_dhost[ETHER_ADDR_LEN]; // destination host address u_char ether_shost[ETHER_ADDR_LEN]; // source host address

u_short ether_type; // type

(22)

Pomoc´ı pˇretypov´an´ı pˇrijat´ych dat touto strukturou je moˇzn´e z´ıskat MAC adresy a typ protokolu vyˇsˇs´ı vrstvy. Tento princip pˇretypov´an´ı je pouˇzit i u s´ıt’ov´e a transportn´ı vrstvy. D˚uleˇzit´e je d´at si pozor na ukazatele, aby neukazovaly na ˇspatn´e m´ısto v pamˇeti. T´ım bychom dostaly nepˇresn´e ´udaje nebo by byl moˇzn´y p´ad cel´e aplikace.

Posunut´ım ukazatele o velikost z´ahlav´ı linkov´e vrstvy (v naˇsem pˇr´ıpadˇe 14 bajt˚u) je moˇzn´e pˇristupovat k jednotliv´ym poloˇzk´am z´ahlav´ı s´ıt’ov´e vrstvy. Opˇet je nutn´e pouˇz´ıt strukturu kv˚uli pˇretypov´an´ı, kter´a vypad´a takto:

struct ip_header {

u_char ip_vhl; // version (4 bits) + IP header length u_char ip_tos; // type of service

u_short ip_len; // total length IP datagram u_short ip_id; // identification

u_short ip_flags_fo; // flags (3 bits) + fragment offset u_char ip_ttl; // time to live

u_char ip_proto; // protocol transport layer u_short ip_crc; // checksum

struct in_addr ip_src, ip_dst; // source and destination address };

Jedn´a se o protokol IP verze 4. Z pohledu analyz´atoru protokol˚u aplikaˇcn´ı vrstvy jsou nejd˚uleˇzitˇejˇs´ı poloˇzky d´elka z´ahlav´ı IP datagramu a typ protokolu vyˇsˇs´ı vrstvy. D´elka z´ahlav´ı nen´ı uv´adˇena v bajtech, ale ve ˇctyˇrbajtech. Proto mus´ı b´yt d´elka z´ahlav´ı n´asobena ˇctyˇrmi, abychom dostali spr´avnou hodnotu. Poloˇzka protokol vyˇsˇs´ı vrstvy bude nab´yvat hodnot pouze TCP nebo UDP, ostatn´ı protokoly budou ignorov´any.

Dek´odov´an´ı na transportn´ı vrstvˇe je podobn´e jako v pˇredchoz´ım pˇr´ıpadˇe. Rozd´ıl je v pouˇzit´ı dvou transportn´ıch protokol˚u – TCP a UDP. TCP je sloˇzitˇejˇs´ı protokol. Definice TCP hlaviˇcky je n´asleduj´ıc´ı:

struct tcp_header {

u_short th_sport; // source port u_short th_dport; // destination port u_int th_seq; // sequence number

u_int th_ack; // acknowldgement number

u_char th_hl; // header length (4 bits) + reserve (4 bits) u_char th_flags; // flags (8 bits)

u_short th_win; // window size u_short th_crc; // checksum

u_short th_urp; // urgent pointer };

D˚uleˇzit´e poloˇzky TCP protokolu jsou zdrojov´y a c´ılovy port, nˇekter´e pˇr´ıznaky a d´elk´a z´ahlav´ı. D´elka z´ahlav´ı je opˇet uv´adˇena ve ˇctyˇrbajtech. V souˇcasn´e dobˇe se pouˇz´ıv´a osm pˇr´ıznak˚u (RFC 3168 [19]) m´ısto dˇr´ıvˇejˇs´ıch ˇsesti.

Z´ahlav´ı UDP protokolu je jednoduˇsˇs´ı neˇz u TCP. Skl´ad´a se pouze ze ˇctyˇr poloˇzek, mezi kter´e patˇr´ı ˇc´ıslo zdrojov´eho a c´ılov´eho portu, kontroln´ı souˇcet a d´elka dat. D´elka dat je v tomto pˇr´ıpadˇe velikost z´ahlav´ı a velikost dat, kter´e protokol nese. Minim´aln´ı d´elka z´ahlav´ı je tedy 8 bajt˚u, tj. UDP paket obsahuj´ıc´ı pouze z´ahlav´ı a ˇz´adn´a data.

(23)

4.2.3 Anal´yza payload

Jakmile jdou zjiˇstˇeny d˚uleˇzit´e hodnoty ze s´ıt’ov´e a transportn´ı vrstv´y a ukazatel je nasta-ven na zaˇc´atek aplikaˇcn´ı vrstvy, je moˇzn´e pˇristoupit k samotn´e anal´yze aplikaˇcn´ı vrstvy. Program pouˇz´ıv´a k rozboru dat dva r˚uzn´e pˇr´ıstupy. Prvn´ı pˇr´ıstup urˇcuje typ aplikaˇcn´ıho protokolu na z´akladˇe ˇc´ısel port˚u, naopak druh´y pˇr´ıstup je zaloˇzen na signatur´ach.

Metoda vyuˇz´ıvaj´ıc´ı k anal´yze aplikaˇcn´ı vrstvy ˇc´ısla port˚u je nejstarˇs´ı metoda, a proto je velice rozˇs´ıˇren´a. Jej´ı v´yhoda je v jednoduch´em pouˇzit´ı. Vˇsechny zn´am´e ˇc´ısla port˚u pˇriˇrazen´e konkr´etn´ım aplikaˇcn´ım protokol˚um je moˇzn´e naj´ıt na webov´ych str´ank´ach or-ganizace IANA [1], pˇr´ıpadnˇe na operaˇcn´ıch syst´emech typu Unix je moˇzn´e ˇc´ısla naj´ıt v sou-boru /etc/services. Struktura sousou-boru je pevnˇe dan´a, kaˇzd´y ˇr´adek obsahuje jeden z´aznam a vypad´a n´asledovnˇe:

jm´eno protokolu ˇc´ıslo portu/[udp|tcp] koment´aˇr

Po spuˇstˇen´ı analyz´ator naˇcte vˇsechny z´aznamy ze souboru do pole struktur. Pole obsa-huje 65 536 struktur a indexem je ˇc´ıslo portu. Kaˇzd´a struktura obsahuje jm´eno aplikaˇcn´ıho protokolu, ˇc´ıslo portu, typ transportn´ıho protokolu a koment´aˇr. Definice struktury je ta-kov´ato:

struct TPortInfo {

const char *m_pcszName; const char *m_pcszComment;

const u_char m_cucSupportedProtocols; unsigned m_uCountTCPsrc, m_uCountTCPdst; unsigned m_uCountUDPsrc, m_uCountUDPdst; unsigned m_uCountDDPsrc, m_uCountDDPdst; };

Posledn´ı tˇri ˇr´adky slouˇz´ı k uchov´av´an´ı poˇctu pouˇzit´ı jednotliv´ych port˚u a n´aslednˇe k v´ypisu statistik. Pˇri odchytnut´ı linkov´eho r´amce a n´asledn´em analyzov´an´ı dojde pouze k porovn´an´ı ˇc´ısel port˚u. Pokud ˇc´ıslo portu odpov´ıd´a nˇejak´emu z´aznamu, je pˇr´ısluˇsn´e jm´eno protokolu vyps´ano na standardn´ı v´ystup. V opaˇcn´em pˇr´ıpadˇe program ozn´am´ı, ˇze aplikaˇcn´ı protokol je nezn´am´y. D´ıky tomuto jednoduch´emu mechanizmu je moˇzn´e z´ıskat celkem vˇerohodn´y pˇrehled o pouˇzit´ı r˚uzn´ych aplikac´ı ve sledovan´e s´ıti.

Nepˇr´ıjemn´a vlastnost analyz´atoru, kter´y rozpozn´av´a aplikaˇcn´ı protokoly pouze na z´akladˇe ˇ

c´ısel port˚u, je v neschopnosti vyp´atrat r˚uzn´e programy, jejˇz pouˇz´ıvaj´ı ke komunikaci n´ahodn´a ˇ

c´ısla port˚u. Pro anal´yzu protokol˚u, kter´e vyuˇz´ıvaj´ı dynamicky generovan´e ˇc´ısla port˚u, je tedy nutn´e pouˇz´ıt d˚umyslnˇejˇs´ı n´astroje. Jedn´ım z nich je zkoum´an´ı signatur jednotliv´ych aplikaˇcn´ıch protokol˚u (na podobn´e metodˇe je zaloˇzen syst´em IDS Bro [4], nebo projekt l7-filter [5] [6]).

Program vyuˇz´ıv´a pro popis signatur aplikaˇcn´ıch protokol˚u regul´arn´ı v´yrazy. Regl´arn´ı v´yrazy m˚uˇze uˇzivatel vymyslet s´am, nebo je moˇzn´e nˇekt´er´e regul´arn´ı v´yrazy pˇrevz´ıt z pro-jektu l7-filtr [5]. Regul´arn´ı v´yraz je ˇretˇezec popisuj´ıc´ı celou mnoˇzinu ˇretˇezc˚u. Regul´arn´ı v´yraz se skl´ad´a z liter´al˚u textu, kter´e se maj´ı shodovat, a speci´aln´ıch znak˚u, kter´e nejsou souˇc´ast´ı hledan´eho textu.

Programov´e vybaven´ı, tedy funkce a struktury pro pr´aci s regul´arn´ımi v´yrazy je moˇzn´e naj´ıt v souboruregex.h, kter´y se nach´az´ı ve zdrojov´ych k´odech operaˇcn´ıho syst´emu (napˇr. FreeBSD m´a tento soubor v adres´aˇri/usr/include). Pokud m´a program pouˇz´ıt regul´arn´ı

(24)

v´yrazy na anal´yzu s´ıt’ov´eho provozu, je nejdˇr´ıve nutn´e pˇreloˇzit dan´y regul´arn´ı v´yraz do tzv. vnitˇr´ıho stavu (deterministick´y koneˇcn´y automat). Toho dos´ahneme pomoc´ı funkce

regcomp(). Jakmile je regul´arn´ı v´yraz ve formˇe struktury, kter´a popisuje deterministick´y koneˇcn´y automat, je moˇzn´e pouˇz´ıt funkciregexec()na vyhled´av´an´ı retˇezce v odchyt´avan´ych datech.

Nev´yhodou v pouˇzit´ı regul´arn´ıch v´yraz˚u je n´aroˇcnost na v´ykon poˇc´ıtaˇce. Nen´ı vˇetˇsinou moˇzn´e, aby anal´yza s´ıt’ov´eho provozu pomoc´ı signatur prob´ıhala na veˇsker´ych odchycen´ych datech, zvl´aˇstˇe pak na vysokorychlostn´ıch s´ıt´ıch. Doch´azelo by k ´uniku dat a t´ım i k nemoˇznosti analyzovat kaˇzd´y paket. Proto je nutn´e vhodnˇe nastavit n´ızko´urovˇnov´y filter zaˇr´ızen´ı BPF (napˇr. na tcp or udp nebo na port 80). D´ıky tomu nebude tolik doch´azet k zahlcen´ı syst´emu.

(25)

Kapitola 5

Testov´

an´ı a v´

ysledky

V t´eto kapitole jsou pops´any r˚uzn´e testy, kter´e byly prov´adˇen´e na sledovan´em syst´emu. Pˇri realizaci analyz´atoru s´ıt’ov´eho provozu je nutn´e obslouˇzit vˇsechny pˇr´ıchoz´ı linkov´e r´amce a to v co nejkratˇs´ı dobˇe. D´ıky test˚um je moˇzn´e odhalit slab´a m´ısta syst´emu a navrhnou optimalizace. Testy byly prov´adˇeny na s´ıti typu Ethernet. Pouˇzit´y poˇc´ıtaˇc mˇel procesor AMD Athlon 64 o frekvenci 2400 MHz a 1024 MB RAM. Operaˇcn´ı syst´em byl pouˇzit FreeBSD 7.1.

5.1

Metodika testov´

an´ı

Z´akladem proveden´ych test˚u bylo mˇeˇren´ı ˇcasu mezi r˚uzn´ymi dvˇema ˇc´astmi programu. Na tyto ´uˇcely se hod´ı funkce a struktury deklarovan´e v hlaviˇckov´em souborutime.h. Konkr´etn´ı pouˇzit´a struktura se jmenuje timespecdefinovan´a n´asledovnˇe:

struct timespec {

time_t tv_sec; // seconds long tv_nsec; // nanoseconds };

Ve zdrojov´em k´odu programu jsou pouˇzity dvˇe tyto struktury – na zaˇc´atku a na konci mˇeˇren´eho ´useku. Pomoc´ı funkceclock gettime() jsou inicializov´any. Rozd´ılem hodnot ze struktury timespec je moˇzn´e z´ıskat dobu anal´yzy jednoho r´amce.

Vˇsechna mˇeˇren´ı byla prov´adˇena v ˇsesti pokusech. Rychlost pˇren´aˇsen´ı dat byla na tˇrech ´

urovn´ıch – 10 Mb/s, 100 Mb/s a 1000 Mb/s. Pˇri kaˇzd´em testu je moˇzn´e nastavit filtro-van´ı na ´urovni BPF. Vˇsechny testy maj´ı stejnou ´urovˇeˇn nastav´en´ı filtru a to na hodnotu ”ip“. V re´aln´em provozu je moˇzn´e r˚uznˇe optimalizovat tento filtr a dos´ahnout tak lepˇs´ıch v´ysledk˚u.

Testy jsou rozdˇeleny na dvˇe ˇc´asti. Prvn´ı ˇc´ast vyuˇz´ıva k anal´yze ˇc´ısla port˚u, druh´a ˇ

c´ast signatury. Nejprve je otestov´ana rychlost detekce bˇeˇznˇe pouˇz´ıvan´ych protokol˚u. Pot´e n´asleduje test vyt´ıˇzen´ı poˇc´ıtaˇce a poˇcet odchycen´ych, zpracovan´ych a odm´ıtnut´ych r´amc˚u. Zejm´ena pomˇer poˇctu odchycen´ych paket˚u ku poˇctu zpracovan´ych paket˚u vypov´ıd´a o efek-tivnosti navrhnut´eho syst´emu. Posledn´ı test byl zamˇeˇren na zjiˇstˇen´ı ˇc´ısel port˚u, kter´e jsou ve sledovan´e s´ıti pouˇz´ıv´any.

(26)

5.2

Testy a v´

ysledky

C´ılem prvn´ıho mˇeˇren´ı bylo zjistit rychlost urˇcov´an´ı aplikaˇcn´ıho protokolu na z´akladˇe ˇc´ısla portu. Jak je vidˇet z tabulky 5.1, detekce prob´ıhala celk´em rychle a v podobn´ych ˇcasech u vˇsech zkouman´ych protokol˚u. Je to z toho d˚uvodu, ˇze urˇcov´an´ı aplikaˇcn´ıch protokol˚u na z´akladˇe vˇsech zn´am´ych port˚u je pro vˇsechny aplikaˇcn´ı protokoly stejn´a. Analyz´ator obslouˇzil vˇsechny odchycen´e r´amce, protoˇze pˇripojen´ı do Internetu je ˇr´adove v jednotk´ach Mb/s.

Mˇeˇren´ı: 1. [µs] 2. [µs] 3. [µs] 4. [µs] 5. [µs] 6. [µs] Pr˚umˇer

HTTP 15,37 17,32 15,64 15,37 15,65 15,95 15,88 FTP 15,64 28,78 15,66 15,92 15,65 25,98 19,61 SMTP 20,31 16,23 15,39 15,33 15,92 15,37 16,43 POP3 17,04 15,64 15,92 21,51 15,64 15,62 16,90 DNS 15,65 15,92 16,48 15,37 40,23 15,62 19,88 SSH 16,20 15,92 15,36 15,64 15,92 16,48 15,92

Tabulka 5.1: ˇCas potˇrebn´y k anal´yze jednoho r´amce (ˇc´ısla port˚u)

N´asleduj´ıc´ı test byl provedem s ohledem na celkovou datovou propust analyz´atoru, zejm´ena pak co se t´yˇce rychlosti anal´yzy paket˚u. Za t´ımto ´uˇcelem byl vytvoˇren soubor o velikosti 200 Mb, kter´y byl kop´ırov´an z jednoho poˇc´ıtaˇce na druh´y. Oba poˇc´ıtaˇce jsem zapojil pˇr´ımo kˇr´ıˇzov´ym kabelem, aby doch´azelo co moˇzn´a nejm´enˇe ke koliz´ım. Z tabulky 5.2 je vidˇet, ze v pˇr´ıpadˇe rychlosti pˇrenosu dat 10 Mb/s je ´uspˇeˇsnost analyzov´an´ı paket˚u vysok´a. I vyt´ıˇzen´ı procesoru je na pˇrijateln´y ´urovni.

Rychlost s´ıtˇe 10 Mb/s

Vyuˇzit´ı CPU Odchycen´e Zpracovan´e Nezpracovan´e Uspˇ´ eˇsnost

HTTP 58 % 202 350 195 537 6 709 96 % FTP 66 % 205 422 202 114 3 216 98 % Rychlost s´ıtˇe 100 Mb/s HTTP 88 % 201 363 28 387 172 965 14 % FTP 97 % 211 618 23 274 188 331 11 % Rychlost s´ıtˇe 1000 Mb/s HTTP 98 % 220 523 3 876 216 647 1,75 % FTP 98 % 213 711 3 625 210 086 1,69 %

Tabulka 5.2: ´Uspˇeˇsnost anal´yzy odchycen´ych r´amc˚u

Naopak u s´ıt´ı o rychlostech 1 000 Mb/s nebo vyˇsˇs´ıch je pouˇzit´ı tohoto analyz´atoru t´emeˇr nemoˇzn´e. Procesor je zat´ıˇzen ´uplnˇe na maximum a vˇetˇsina pˇrijat´ych paket˚u mus´ı b´yt zahozena. Zpracov´an´ych r´amc˚u jsou necel´a dvˇe procenta, coˇz je kaˇzd´y 56t´y.

Zat´ımco urˇcov´an´ı aplikaˇcn´ıch protokol˚u vyuˇz´ıvaj´ıc´ı ˇc´ısla port˚u je na pomalejˇs´ıch s´ıt´ıch celkem ´uspˇeˇsn´e, pˇri pouˇzit´ı signatur k detekci je situace komplikovanˇejˇs´ı. Z´aleˇz´ı totiˇz na sloˇzitosti regul´arn´ıho v´yrazu, kter´y dan´y aplikaˇcn´ı protokol popisuje. Z tohoto d˚uvodu je doba potˇrebn´a k analyzov´an´ı konkr´etn´ıho protokolu r˚uznˇe dlouh´a.

Tabulka 5.3 shrnuje dobu anal´yzy jednoho r´amce konkr´etn´ıho protokolu. Na prvn´ı po-hled je vidˇet, ˇze pr˚umˇern´e ˇcasy se zv´yˇsily, nˇekter´e dokonce nˇekolikr´at. Zejm´ena u protokolu

(27)

Mˇeˇren´ı: 1. [µs] 2. [µs] 3. [µs] 4. [µs] 5. [µs] 6. [µs] Pr˚umˇer HTTP 75,37 87,37 89,14 95,37 98,65 91,92 88,63 FTP 44,64 47,87 55,63 49,92 53,65 60,98 52,27 SMTP 30,32 36,23 29,39 31,33 35,25 33,37 32,65 POP3 37,24 31,64 45,29 35,73 32,46 39,42 36,97 DNS 65,45 55,32 59,48 69,37 54,83 65,65 61,68 SSH 26,23 22,25 31,36 25,47 29,92 31,65 27,81

Tabulka 5.3: ˇCas potˇrebn´y k anal´yze jednoho r´amce (signatury)

http je n´ar˚ust ˇcasu detekce vysok´y. Nicm´enˇe zv´yˇsen´ı ˇcasu se dalo oˇcek´avat, protoˇze re-gul´arn´ı v´yraz popisuj´ıc´ı http protokol je pomˇernˇe komplikovan´y. Nav´ıc vysok´y ˇcas detekce je tak´e nepˇr´ıjemn´y z dalˇs´ıho d˚uvodu, kter´ym je ˇcast´e pouˇzit´ı protokolu http. A jak je vidˇet z tabulky 5.5, t´emˇeˇr 72% komunikace je uskuteˇcnˇen´a pomoc´ı protokolu http.

Rychlost s´ıtˇe 10 Mb/s

Vyuˇzit´ı CPU Odchycen´e Zpracovan´e Nezpracovan´e Uspˇ´ eˇsnost

HTTP 98 % 203 012 35 557 166 943 18 % FTP 98 % 206 131 71 736 134 394 34 % Rychlost s´ıtˇe 100 Mb/s HTTP 98 % 201 954 5 161 196 634 2,6 % FTP 98 % 212 147 8 951 203 195 4,2 % Rychlost s´ıtˇe 1000 Mb/s HTTP 98 % 218 936 876 217 839 0,5 % FTP 98 % 211 375 1 394 209 980 0,7 %

Tabulka 5.4: ´Uspˇeˇsnost anal´yzy odchycen´ych r´amc˚u (signatury)

Pro zaj´ımavost je v tabulce 5.4 uvedena ´uspˇeˇsnost detekce aplikaˇcn´ıch protokol˚u v z´avislosti na r˚uznˇe pouˇzit´e pˇrenosov´e rychlosti. U rychlost´ı kolem 1 Gb/s a v´yˇse je prakticky nemoˇzn´e rozumn´ym zp˚usobem analyzovat s´ıt’ov´y provoz t´ımto analyz´atorem. Je potˇreba pouˇz´ıt jin´e techniky, aby v´ysledek nebyl tak ˇzalostn´y jako v tomto pˇr´ıpadˇe.

Posledn´ı test byl zamˇeˇren na zjiˇstˇen´ı vˇetˇsiny ˇc´ısel port˚u, kter´e jsou na sledovan´e s´ıti pouˇz´ıv´any. D´ıky tomuto testu je moˇzn´e z´ıskat celkov´y pˇrehled pouˇz´ıvan´ych aplikac´ı. Sle-dovan´a s´ıt’ se skl´ad´a ze ˇctyˇr poˇc´ıtaˇc˚u a jednoho serveru, kter´y slouˇz´ı jako datov´e uloˇzistˇe. Tato s´ıt’ je pˇripojena do Internetu prostˇrednictv´ım br´any (router), na kter´e bˇeˇzel analyz´ator 24 hodin. Rychlost pˇripojen´ı do Internetu je 2 Mb/s. Jednalo se o malou firemn´ı s´ıt’. Po ukonˇcen´ı progrma vytiskl statistiku pouˇzit´ych port˚u. Seznam ˇc´ısel port˚u je zobrazen v ta-bulce 5.5.

Proveden´y test odhalil nˇekter´e zaj´ımavosti. Vˇetˇsina s´ıt’ov´eho provozu uskuteˇcnˇen´eho smˇerem do Internetu pouˇz´ıv´a protokol http, konkr´etnˇe 71 %. Na druh´em m´ıstˇe je za-bezpeˇcen´y protokol https. N´asleduj´ı dalˇs´ı protokoly aplikaˇcn´ı vrstvy, kter´e jsou ale pouˇzity v menˇs´ı m´ıˇre. Druh´e zajimav´e zjiˇstˇen´ı je, ˇze vˇetˇsina (t´emˇeˇr 90 %) ˇc´ısel port˚u je menˇs´ı neˇz 1024. Je to zp˚usoben´e firemn´ı politikou, kdy je zak´azan´e sd´ılen´ı soubor˚u. U jin´ych s´ıt´ı je pouˇzit´ı s´ıt’ov´ych aplikac´ı r˚uzn´e a t´ım i seznam ˇc´ısel port˚u se bude jistˇe liˇsit. Zejm´ena pokud se bude jednat o r˚uzn´e komunitn´ı s´ıtˇe, pˇr´ıpadnˇe pir´atsk´e s´ıtˇe, tak bude v´yskyt dynamicky

(28)

Protokol Port Poˇcet r´amc˚u % R´amc˚u HTTP 80 963 551 71,23 % HTTPS 443 85 898 6,35 % FTP 21 38 147 2,82 % SSH 22 16 773 1,24 % SMTP 25 19 885 1,47 % POP 110 25 160 1,86 % DNS 53 43 963 3,25 % ICQ 5190 74 129 5,48 % XMPP 5222 38 552 2,85 % Zbytek 46 669 3,45 % <1024 1 193 380 88,22 % ≥1024 159 351 11,78 % celkem 1 352 731 100 %

Tabulka 5.5: ˇCasto pouˇz´ıvan´a ˇc´ısla port˚u

generovan´ych ˇc´ısel port˚u mnohon´asobnˇe v´ıce d´ıky pouˇz´ıv´an´ı r˚uzn´ych aplikac´ı typu torrent aj.

(29)

Kapitola 6

avˇ

er

Hlavn´ım c´ılem t´eto pr´ace bylo nal´ezt zp˚usob, jak naprogramovat aplikaci typu s´ıt’ov´y ana-lyz´ator, kter´y je schopen efektivnˇe odchyt´avat s´ıt’ov´y provoz a analyzovat aplikaˇcn´ı vrstvu. Tento probl´em nespoˇc´ıv´a v prost´em naprogramov´an´ı dan´e aplikace, ale je nutn´e pocho-pit princip fungov´an´ı poˇc´ıtaˇcov´ych s´ıt´ı a operaˇcn´ıch syst´em˚u. Tak´e je nutn´e nastudovat problematiku kolem regul´arn´ıch v´yraz˚u.

Ve druh´e a tˇret´ı kapitole je probr´ana teorie ohlednˇe technologi´ı poˇc´ıtaˇcov´ych s´ıt´ı a mechanizm˚u odchyt´av´an´ı dat. D´ıky tˇemto teoretick´ym poznatk˚um jsem byl schopen im-plementovat s´ıt’ov´y analyz´ator. Konkr´etn´ı popis implementace je rozebr´an ve ˇctvrt´e kapi-tole. Nejdˇr´ıve je pops´ana metoda odchyt´av´an´ı samotn´ych dat za pouˇzit´ı knihovny libpcap. V druh´e ˇc´asti ˇctvrt´e kapitoly je rozebr´ano analyzov´an´ı dat na aplikaˇcn´ı ´urovni.

Pˇredposledn´ı, p´at´a, kapitola obsahuje testov´an´ı programu. Byly pouˇzity r˚uzn´e testy na ovˇeˇren´ı funkˇcnosti aplikace. D´ıky tˇemto test˚um byly odhaleny nedostatky, kter´ymi ana-lyz´ator trp´ı. Zejm´ena neschopnost vyuˇz´ıt´ı programu na s´ıt´ıch s rychlostmi vyˇsˇs´ımi neˇz 100 Mb/s, kdy je t´emˇeˇr nemoˇzn´e analyz´ator pouˇz´ıt. D˚uvodem takto ˇspatn´ych v´ysledk˚u je n´avrh aplikace, protoˇze pouˇz´ıv´a pouze jedno vl´akno na vykon´av´an´ı instrukc´ı. Jestliˇze tedy chceme pouˇz´ıt softwarov´y analyz´ator k detekov´an´ı aplikaˇcn´ıch protokol˚u na modern´ıch vysokorych-lostn´ıch s´ıt´ıch, je nezbytn´e, aby n´avrh a n´asledn´a implementace pouˇz´ıvala v´ıce vl´aken. Zejm´ena v dneˇsn´ı dobˇe, kdy je na trhu velk´e mnoˇzstv´ı v´ıcej´adrov´ych procesor˚u, a proto se hod´ı vyuˇz´ıt v´ıce vl´aken, pˇr´ıpadnˇe proces˚u.

Pokud ani v´ıcevl´aknov´e aplikace nestaˇc´ı na analyzov´an´ı s´ıt’ov´eho provozu, potom nezb´yv´a nic jin´eho neˇz pouˇz´ıt specializovan´a hardwarov´a zaˇr´ızen´ı, kter´a jsou velice rychl´a a efek-tivn´ı.

(30)

Literatura

[1] WWW str´anky organizace IANA (ˇc´ısla port˚u), Naposledy navˇst´ıveno 19. 12. 2008.

http://www.iana.org/assignments/port-numbers.

[2] WWW str´anky projektu Libpcap/Tcpdump, Naposledy navˇst´ıveno 26. 12. 2008.

http://www.tcpdump.org.

[3] WWW str´anky projektu WinPcap, Naposledy navˇst´ıveno 26. 12. 2008.

http://www.winpcap.org.

[4] WWW str´anky projektu IDS Bro, Naposledy navˇst´ıveno 5. 1. 2009.

http://www.bro-ids.org.

[5] WWW str´anky projektu L7-filter, Naposledy navˇst´ıveno 5. 1. 2009.

http://l7-filter.sourceforge.net.

[6] WWW str´anky, Naposledy navˇst´ıveno 5. 1. 2009. http://www.protocolinfo.org. [7] Libor DOST ´ALEK and Alena KABELOV ´A. Velk´y pr˚uvodce protokoly TCP/IP a

syst´emem DNS. Computer Press, Praha, 1999.

[8] Holger DREGER, Anja FELDMANN, Michael MAI, Vern PAXSON, and Robin SOMMER. Dynamic application-layer protocol analysis for network intrusion detection. [online], Naposledy navˇst´ıveno 3. 1. 2009.

http://www.icir.org/robin/papers/usenix06.pdf.

[9] Van JACOBSON, Craig LERES, and Steven MCCANNE. pcap – packet capture library. Manu´alov´e str´anky FreeBSD.

[10] Van JACOBSON, Craig LERES, and Steven MCCANNE. tcpdump – dump traffic on a network. Manu´alov´e str´anky FreeBSD.

[11] Van JACOBSON and Steven MCCANNE. bpf – berkeley packet filter. Manu´alov´e str´anky FreeBSD.

[12] Myung-Sup KIM, Young J. WON, and James Won-Ki HONG. Application-level traffic monitoring and an analysis on ip networks. [online], Naposledy navˇst´ıveno 3.

1. 2009. http://dpnm.postech.ac.kr/papers/ETRI-Journal/04/

application-layer-analysis/application-layer-analysis.pdf.

[13] Michael LUCAS. S´ıt’ov´y operaˇcn´ı syst´em FreeBSD. Computer Press, Brno, 2003. ISBN 80-7226-795-7.

(31)

[14] Steven MCCANE and Van JACOBSON. The bsd packet filter: A new architecture for user-level packet capture. [online], Naposledy navˇst´ıveno 28. 12. 2008.

http://www.tcpdump.org/papers/bpf-usenix93.pdf.

[15] Jeffrey C. MOGUL. The packet filter: An efficient mechanism for user-level network code. [online], Naposledy navˇst´ıveno 28. 12. 2008.

http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-2.pdf.

[16] Jon POSTEL. Internet protocol, rfc 791. [online], Naposledy navˇst´ıveno 6. 12. 2008.

http://www.ietf.org/rfc/rfc0791.txt.

[17] Jon POSTEL. Transmission control protocol, rfc 739. [online], Naposledy navˇst´ıveno 6. 12. 2008. http://www.ietf.org/rfc/rfc0793.txt.

[18] Jon POSTEL. User datagram protocol, rfc 768. [online], Naposledy navˇst´ıveno 6. 12. 2008. http://www.ietf.org/rfc/rfc0768.txt.

[19] R. RAMAKRISHNAN, S. FLOYD, and D. BLACK. The addition of explicit congestion notification to ip, rfc 3168. [online], Naposledy navˇst´ıveno 10. 1. 2009.

http://tools.ietf.org/html/rfc3168.

[20] Fulvio RISSO and Loris DEGIOANNI. An architecture for high performance network analysis. [online], Naposledy navˇst´ıveno 19. 12. 2008.

(32)

Dodatek A

Pouˇ

zit´ı programu

Program je pˇred pouˇzit´ım nutn´e pˇreloˇzit. K tomu slouˇz´ı souborMakefile, kter´y je dod´av´an spolu se zdrojov´ymi k´ody. D´ale jsou pˇriloˇzeny jˇeˇstˇe souboryetc.servicearegexp. V sou-boru etc.services jsou pops´any vˇsechny zn´am´e ˇc´ısla port˚u a v souboru regexp jsou regul´arn´ı v´yrazy popisuj´ıc´ı protokoly aplikaˇcn´ı vrstvy. Pro spr´avn´y chod analyz´atoru je nutn´e m´ıt tyto soubory ve stejn´em adres´aˇri jako samotn´y program.

Aplikace je navrˇzena na pouˇzit´ı z pˇr´ıkazov´e ˇr´adky. Chov´an´ı programu je moˇzn´e ovlivnit parametry pˇri spouˇstˇen´ı.

Parametry programu:

• -f (filtr)podm´ınka pro zaˇr´ızen´ı BPF

• -p (poˇcet) poˇcet zobrazovan´ych znak˚u aplikaˇcn´ı vrstvy (implicitnˇe = 0)

• -d (zaˇr´ızen´ı) potlaˇc´ı dotaz na ˇc´ıslo odposlouch´avan´eho zaˇr´ızen´ı a zvol´ı ho pˇr´ımo

• -r m´ısto ˇc´ısel port˚u se pouˇzij´ı k detekci regul´arn´ı v´yrazy

• -R (v´yraz)vlastn´ı regul´arn´ı v´yraz

• -n (poˇcet) poˇcet znak˚u aplikaˇcn´ı vrstvy zkouman´ych regul´arn´ım v´yrazem

• -h tisk n´apovˇedy

V pr˚ubˇehu ˇcinnosti analyz´atoru jsou o kaˇzd´em odchycen´em r´amci vypisov´any tyto ´udaje:

• Cas odchycen´ı r´ˇ amce

• Poˇcet odchycen´ych r´amc˚u

• IP adresa pˇr´ıjemce a odes´ılatele

• C´ıslo portu pˇˇ r´ıjemce a odes´ılatele

• Velikost celkem pˇrenesen´ych dat v bajtech

• Typ protokolu transportn´ı vrstvy

• V pˇr´ıpadˇe protokolu TCP typ pˇr´ıznaku

(33)

• Tisk aplikaˇcn´ıch dat v hexa a ascii form´atu

• Poˇcet vˇsech pˇrijat´ych r´amc˚u (knihovna libpcap)

• Poˇcet vˇsech nezpracovan´ych r´amc˚u (knihovna libpcap)

Ukonˇcen´ı programu je moˇzn´e zasl´an´ım sign´alu SIGINT (Ctrl + c). Jakmile je sign´al SIGINT odchycen analyz´atorem, tak jsou vytiˇstˇeny statistiky a program je ukonˇcen. Sta-tistiky jsou n´asleduj´ıc´ı:

• Seznam detekovan´ych aplikaˇcn´ıch protokol˚u a poˇcet r´amc˚u

• Poˇcet TCP paket˚u menˇs´ıch neˇz 1024

• Poˇcet TCP paket˚u vˇetˇs´ıch neˇz 1024

• Poˇcet UDP paket˚u menˇs´ıch neˇz 1024

• Poˇcet UDP paket˚u vˇetˇs´ıch neˇz 1024

• Celkov´y poˇcet TCP paket˚u

Figure

Updating...

References

Related subjects :