Univerzita Karlova v Praze Matematicko-fyzikální fakulta. Martin Liška. Katedra aplikované matematiky

Univerzita Karlova v Praze Matematicko-fyzikáln´ı fakulta

´ RSK ˇ ´ PRACE ´ BAKALA A

Martin Liˇska Pasivn´ı analyz´ ator s´ıt´ı Katedra aplikované matematiky

Vedouc´ı bakaláˇrské práce: Mgr. Martin Mareˇs, Ph.D. Studijn´ı program: Informatika, obor Programován´ı

2010

Chtˇel bych podˇekovat Mgr. Martinu Mareˇsovi, Ph.D. za veden´ı bakaláˇrské práce, cenné rady, u ´ˇcelné pˇripom´ınky a za ochotu pˇri spoleˇcné práci.

Prohlaˇsuji, ˇze jsem svou bakaláˇrskou práci napsal(a) samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. Souhlas´ım se zap˚ ujˇcován´ım práce a jej´ım zveˇrejˇ nován´ım. V Praze dne 3. srpna 2010

Martin Liˇska

2

Obsah ´ 1 Uvod 1.1 Anal´ yza s´ıt’ového provozu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Problémy s provozován´ım s´ıtˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Rodina protokol˚ u TCP/IP 2.1 Architektura protokolu TCP/IP . . . . 2.2 Historie protokolu TCP/IP . . . . . . . 2.3 Porovnán´ı s modelem ISO/OSI . . . . 2.4 Linková vrstva a technologie Ethernet . 2.5 S´ıt’ová vrstva IP . . . . . . . . . . . . . 2.6 Transportn´ı vrstva . . . . . . . . . . . 2.6.1 Protokol UDP . . . . . . . . . . 2.6.2 Protokol TCP . . . . . . . . . . 3 Pasivn´ı s´ıt’ov´ e analyz´ atory 3.1 Definice . . . . . . . . . . . . 3.2 Tcpdump . . . . . . . . . . . 3.3 Tcpflow . . . . . . . . . . . . 3.4 Wireshark . . . . . . . . . . . 3.4.1 Historie . . . . . . . . 3.4.2 Filtrován´ı . . . . . . . 3.4.3 Anal´ yza rámc˚ u . . . . 3.4.4 Statistické komponenty 3.5 Netgrind . . . . . . . . . . . . 4 S´ıt’ov´ y analyz´ ator NEPAL 4.1 Pˇredstaven´ı . . . . . . . . . . 4.2 Zapojen´ı programu . . . . . . 4.3 Datov´ y objekt . . . . . . . . . 4.4 Pˇredstaven´ı modul˚ u. . . . . . 4.4.1 Modul PCAP . . . . . 4.4.2 Modul Ethernet . . . . 4.4.3 Modul ARP . . . . . . 4.4.4 Modul ARP view . . . 4.4.5 Modul IPv4 . . . . . . 4.4.6 Modul IPv6 . . . . . . 4.4.7 Modul IP reassembler 4.4.8 Modul UDP . . . . . . 4.4.9 Modul TCP . . . . . . 4.4.10 Modul TCP flow . . . 4.4.11 Modul HTTP . . . . . 4.4.12 Modul DNS . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

3

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

6 6 6 6

. . . . . . . .

8 8 8 9 10 11 13 13 13

. . . . . . . . .

16 16 16 17 17 18 18 19 19 19

. . . . . . . . . . . . . . . .

20 20 20 21 21 22 23 23 24 24 24 25 26 26 27 27 28

5 Ovl´ ad´ an´ı programu NEPAL 5.1 Pˇreklad programu . . . . . . . . . . . 5.2 Ukázka programu . . . . . . . . . . . 5.3 Ovládán´ı a programátorské rozhran´ı . 5.4 Spouˇstˇen´ı programu . . . . . . . . . .

. . . .

29 29 29 30 32

. . . . . . . . .

33 33 33 33 34 35 35 37 37 39

. . . . .

42 42 42 42 43 43

8 Z´ avˇ er 8.1 Zhodnocen´ı práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Moˇznosti budouc´ıho v´ yvoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45 45 45

Literatura

46

6 Uk´ azky z programu NEPAL 6.1 Modul pro HTTP . . . . . 6.1.1 Prvn´ı pˇr´ıklad . . . 6.1.2 Druh´ y pˇr´ıklad . . . 6.1.3 Tˇret´ı pˇr´ıklad . . . 6.2 Grafov´ y modul . . . . . . 6.2.1 Prvn´ı pˇr´ıklad . . . 6.2.2 Druh´ y pˇr´ıklad . . . 6.3 Modul ARP/RARP . . . . 6.4 Modul DNS . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

7 Vnitˇ rn´ı ˇ reˇ sen´ı analyz´ atoru 7.1 Soubory programu . . . . . . . . 7.2 Implementace datového objektu . 7.3 Zásobn´ık událost´ı . . . . . . . . . 7.4 Programován´ı modul˚ u . . . . . . 7.5 Pˇredstava fungován´ı modulu TCP

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

4

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

. . . .

. . . . . . . . .

. . . . .

Název práce: Pasivn´ı analyzátor s´ıt´ı Autor: Martin Liˇska Katedra (´ ustav): Katedra aplikované matematiky Vedouc´ı bakaláˇrské práce: Mgr. Martin Mareˇs, Ph.D. E-mail vedouc´ıho: [email protected] Abstrakt: C´ılem práce je navrhnout a implementovat program pro monitorován´ı a analýzu provozu v poˇc´ıtaˇcových s´ıt´ıch, který bude pracovat ˇcistˇe pasivnˇe, tedy aniˇz by ovlivˇ noval mˇeˇrenou komunikaci. Informace o chován´ı s´ıtˇe bude z´ıskávat odposloucháván´ım pˇrenáˇsených paket˚ u, z nichˇz ’ bude rekonstruovat chod s´ıt ových spojen´ı a ˇcinnost pˇrenosových protokol˚ u. Kl´ıˇcová slova: analýza, TCP/IP, poˇc´ıtaˇcové s´ıtˇe

Title: A passive network analyser Author: Martin Liˇska Department: Department of Applied Mathematics Supervisor: Mgr. Martin Mareˇs, Ph.D. Supervisor’s e-mail address: [email protected] Abstract: The aim of this thesis is to design and implement a program for computer network traffic monitoring and analysis that would operate in a purely passive mode, i.e., without affecting the measured traffic. Information about the network performance will be received by tapping the transmitted packets, which will enable the software to reconstruct the operation of network connections as well as activity of the transfer protocols. Keywords: analysis, TCP/IP, computer networks

5

´ Uvod 1.1

Anal´ yza s´ıt’ov´ eho provozu

Provozován´ı s´ıt’ové komunikace mezi poˇc´ıtaˇci je v dneˇsn´ı dobˇe jiˇz dávno zabˇehlá praxe a mnoˇzstv´ı datového provozu a poˇcet lid´ı, kteˇr´ı maj´ı pˇr´ıstup k Internetu budiˇz toho d˚ ukazem. Poˇcet uˇzivatel˚ u s´ıtˇe Internet se vyˇsvihl na dneˇsn´ı hodnotu 1,8 miliardy lid´ı, coˇz odpov´ıdá v´ıce neˇz ˇctvrtinˇe obyvatelstva planety a oproti roku 2000 vzrostl tento poˇcet uˇzivatel˚ u ˇctyˇrnásobnˇe. ˇ e republice vzrostlo mnoˇzstv´ı pˇrenesen´ Jenom v rámci páteˇrn´ı s´ıtˇe NIX.CZ v Cesk´ ych dat dvojnásobnˇe oproti roku minulému. Z pohledu samotného s´ıt’ového provozu je valná vˇetˇsina informac´ı pˇrenáˇsena pomoc´ı rodiny protokol˚ u TCP/IP a d´ıky nezaˇsifrované vˇetˇsinˇe provozu je moˇzné záznamy komunikace sledovat, ukládat a následnˇe analyzovat. Vidˇeno oˇcima bˇeˇzného uˇzivatele, napˇr´ıklad s´ıtˇe Internet, je komunikace a pˇrenos dat v rámci s´ıtˇe ˇcernou skˇr´ıˇ nkou, která zdánlivˇe funguje velmi spolehlivˇe, intuitivnˇe a bezpeˇcnˇe.

1.2

Probl´ emy s provozov´ an´ım s´ıtˇ e

Druhá strana mince ale jasnˇe ukazuje, ˇze zneuˇzit´ı pˇrenáˇsen´ ych informac´ı je vcelku snadné, pˇr´ıkladem budiˇz moˇznost sledován´ı navˇst´ıven´ ych webov´ ych stránek, odeslan´ ych formuláˇr˚ u a emailov´ ych zpráv obsahuj´ıc´ıch osobn´ı informace, zobrazen´ ych obrázk˚ u, odeslan´ ych zpráv napˇr´ıklad pomoc´ı protokolu IRC ˇci moˇznost dohledán´ı hesel, kter´ ymi se uˇzivatel autorizuje na nezaˇsifrovan´ ych webov´ ych serverech. Se svoj´ı velikost´ı se stal Internet kolbiˇstˇem nejr˚ uznˇejˇs´ıch zájm˚ u, poˇc´ınaje masivn´ı reklamou na kaˇzdém kroku, pˇres rozes´ılán´ı nevyˇza´dané poˇsty, ˇs´ıˇren´ı internetov´ ych ˇcerv˚ u a konˇce u ´toky na citlivé osobn´ı u ´daje v podobˇe databázov´ ych aplikac´ı. Druh´ ym fenoménem dneˇsn´ıch poˇc´ıtaˇcov´ ych s´ıt´ı je tempo nar˚ ustán´ı pˇrenosového v´ ykonu infrastruktury. Docház´ı k nasazován´ı stále sofistikovanˇejˇs´ıch s´ıt’ov´ ych zaˇr´ızen´ı, které si ale s sebou nesou problémy u ´zk´ ych hrdel. Rychlost v poˇc´ıtaˇcové s´ıti se ˇr´ıd´ı rychlost´ı jej´ıho nejuˇzˇs´ıho m´ısta, pˇrestoˇze v globáln´ı mˇeˇr´ıtku m˚ uˇzeme o s´ıti uvaˇzovat jako o pˇredimenzované. Jako pˇr´ıklad mohou poslouˇzit r˚ uzné proxy servery, jenˇz zprostˇredkovávaj´ı komunikaci mimo lokáln´ı s´ıt’ nebo protokoly pro sd´ılen´ı soubor˚ u typu P2P, které dokáˇzi otevˇr´ıt velké mnoˇzstv´ı spojen´ı. Návaznost´ı na zm´ınˇené problémy je dobré problém˚ um porozumˇet a anal´ yza s´ıt’ového provozu m˚ uˇze b´ yt dobr´ ym pomocn´ıkem pro z´ıskáván´ı d˚ uleˇzit´ ych informac´ı.

1.3

Motivace

C´ılem bakaláˇrské práce nen´ı zneuˇzit´ı slabin s´ıt’ového modelu, n´ ybrˇz právˇe naopak vytvoˇren´ı ’ programu, kter´ y bude schopen nashromáˇzdˇená s´ıt ová data naˇc´ıtat, analyzovat a poskytovat specifické informace, v podobˇe ˇclovˇeku co moˇzná nejv´ıce pˇr´ıvˇetivé. Pˇrenáˇsená data pomoc´ı rodiny protokol˚ u TCP/IP jsou pˇrenáˇsena ve formˇe rámc˚ u (paket˚ u), jenˇz v sobˇe nesou pouze d´ılˇc´ı ˇcást mozaiky a skladba kompletn´ı mozaiky, chápané napˇr´ıklad ve smyslu pˇrenesen´ ych email˚ u ˇci HTML stránek potˇrebuje vˇetˇs´ı u ´sil´ı pˇri syntéze. Jiˇz od rané fáze návrhu programového 6

ˇreˇsen´ı je kladen d˚ uraz na modularitu a moˇzná dalˇs´ı rozˇs´ıˇren´ı libovolného druhu. Software lze chápat jako kmen stromu, kter´ y poskytuje základn´ı funkˇcnost a na kter´ y lze naroubovat r˚ uzná rozˇs´ıˇren´ı a vylepˇsen´ı. Ambic´ı programu nem˚ uˇze b´ yt v ˇzádném pˇr´ıpade podpora pro vˇsechny známé protokoly, ale c´ılem je poskytnout framework, jenˇz nab´ıdne jednoduché rozˇs´ıˇren´ı v podobˇe modulu v Pythonu ˇci modulu v jazyce C, kter´ y bude optimalizovan´ y na rychlost. Program bude implementovat podporu základn´ıch protokol˚ u vrstevnatého modelu TCP/IP: Ethernetov´ y ’ protokol, s´ıt ov´ y protokol verze 4 i 6, protokol TCP a UDP. Zm´ınˇené protokoly chápu jako nosnou kostru, na které prob´ıhá pˇrenos vˇetˇsiny dneˇsn´ıch aplikaˇcn´ıch protokol˚ u a ukázkové moduly budou právˇe pracovat na zm´ınˇeném základu.

7

Rodina protokol˚ u TCP/IP 2.1

Architektura protokolu TCP/IP

Rodinou protokol˚ u TCP/IP naz´ yváme mnoˇzinu s´ıt’ov´ ych protokol˚ u uˇz´ıvan´ ych v s´ıti Internet a ’ v jin´ ych poˇc´ıtaˇcov´ ych s´ıt´ı. Název rodiny je odvozen z jména protokolu s´ıt ové vrstvy (Internet Protocol) a jména spojovaného protokolu transportn´ı vrstvy (Transmission Control Protocol). Rodina pokr´ yvá 4 vrstvy s´ıt’ového modelu: linková, s´ıt’ová, transportn´ı a aplikaˇcn´ı. Vznik protokolu je pevnˇe svázán s rozvojem a prvopoˇcátkem celosvˇetové poˇc´ıtaˇcové s´ıtˇe Internet. Protokol vznikl v l˚ unˇe Internetu a stal se jeho hlavn´ım nosn´ ym médiem. Myˇslenka paketového pˇrenosu je témˇeˇr 50 let stará a vznikla jako duáln´ı idea k s´ıti telefonn´ı, kterou odstartoval Alexander Graham Bell v 80. letech 19. stolet´ı. Ve svém návrhu poˇc´ıtá s um´ıstˇen´ım inteligence do koncov´ ych uzl˚ u s´ıtˇe, negarantuje pˇrenosovou kapacitu, ale pracuje v reˇzimu best effort“ (maximáln´ı moˇzná ” snaha). Standardy a specifikace kolem protokolu vznikly ve formˇe dokument˚ u RFC (Request for Comments), kde se ˇsiroké mnoˇzstv´ı odborn´ık˚ u shodlo na svobodn´ ych, nelicencovan´ ych standardech a vloˇzili t´ım tak do v´ınku velké mnoˇzstv´ı potenciálu do budoucna. Drobn´ ym problémem dokument˚ u RFC je nemoˇznost jejich modifikace a nutnost vydáván´ı nového dokumentu pˇri modifikaci. Pro tyto u ´ˇcely vznikly dokumenty STD (standard) dokumenty, které si lze pˇredstavit jako poˇradaˇc, do kterého se ukládaj´ı RFC dokumenty, t´ ykaj´ıc´ı se stejného problému.

2.2

Historie protokolu TCP/IP

Jak jiˇz bylo v´ yˇse zm´ınˇeno, myˇslenka paketového pˇrenosu se rozvinula na poˇca´tku 60. let 20. stolet´ı v USA v rámci armádn´ı grantové agentury ARPA. Spojené státy v dobˇe Studené války prohrály pomysln´ y souboj o dobyt´ı vesm´ıru v roce 1957 vesm´ırnou lod´ı Sputnik a rozhodly se investovat do budouc´ıch technologi´ı. Na ovˇeˇren´ı faktu, zda je myˇslenka paketového pˇrenosu uskuteˇcnitelná vznikla na konci 70. let s´ıt’ Arpanet. V s´ıti byl nasazen experimentáln´ı protokol NCP (Network Control Program), kter´ y kop´ıroval z dneˇsn´ıho hlediska funkci transportn´ı vrstvy. Prvn´ı pˇredstava rodiny protokol˚ u TCP/IP byla prezentována v roce 1972 a jej´ı jméno je spjato s osobou Vintona Gray Cerfa, kter´ y jako postgraduáln´ı student na Kalifornské univerzitˇe a Stanfordské univerzitˇe poˇra´dá s´ıt’ové semináˇre, jichˇz se u ´ˇcastn´ı napˇr. Robert Metcalfe (3Com) nebo Jack Haverty. P˚ uvodnˇe mˇel b´ yt nástupce experimentáln´ıho protokolu také monolitick´ y, ’ ale posléze autoˇri zmˇenili koncepci a doˇslo k rozpadu na protokol s´ıt ov´ y (IP) a transportn´ı (TCP). Na pˇrelomu let 70. a 80. se stává protokol TCP/IP preferovan´ ym Ministerstvem obrany Spojen´ ych stát˚ u a 1. 1. 1983 na nˇej pˇreˇslo vˇsech zhruba 200 smˇerovaˇc˚ u pˇredch˚ udce dneˇsn´ı s´ıtˇe Internet. Za druhé datum narozen´ı nˇekteré autority povaˇzuj´ı záˇr´ı 1981, kdy spatˇrily svˇetlo svˇeta RFC dokumenty 791 a 793, v nichˇz se specifikuj´ı protokoly IP a TCP. V rámci pˇrechodu vlastnictv´ı a plánován´ı problematiky kolem Internetu a protokol˚ u TCP/IP vznikla organizace ISOC (Internet Society), která pˇrevzala od vlády Spojen´ ych stát˚ u odpovˇednost za dalˇs´ı v´ yvoj a vystupuje jako organizace k ostatn´ım subjekt˚ um na trhu. V rámci organizace je kladen d˚ uraz na kontinuitu a stromovou strukturu, kde jednotlivé divize zastˇreˇsuj´ı na jedné stranˇe v´ yvoj do budoucna a ˇreˇsen´ı aktuáln´ıch problému napˇr. s nedostatkem IPv4 veˇrejn´ ych adres konˇce. 8

2.3

Porovn´ an´ı s modelem ISO/OSI

Referenˇcn´ı model ISO/OSI vznikl jako model pro poˇc´ıtaˇcové s´ıtˇe z d´ılny Mezinárodn´ı organizace pro standardy (ISO) v roce 1984. Model pocház´ı ze svˇeta spoj˚ u a v pr˚ ubˇehu své geneze a v´ yvoje se ub´ıral znaˇcnˇe odliˇsnˇe od rodiny protokol˚ u TCP/IP, se kter´ ymi nakonec prohrál na plné ˇca´ˇre. Koncepce se zrodila od zeleného stolu, definovaly se obecnˇe funkce jednotliv´ ych vrstev bez korespondence s realitou a vyzkouˇsenou implementac´ı. Pro porovnán´ı je nutné v 2. fáz´ı pˇrijet´ı dokumentu RFC pro protokoly souvisej´ıc´ı s TCP/IP vytvoˇrit alespoˇ n dvˇe funkˇcn´ı implementace a v praxi je ovˇeˇrit a d˚ ukladnˇe otestovat. Autoˇri nakladli velkou mnoˇzinu poˇzadavk˚ u na s´ıt’ovou architekturu a prosadili ji do standardu. Organizace ISO mˇela velk´ y vliv na fungován´ı státu a správa stát˚ u tlaˇcila na poˇrizován´ı zaˇr´ızen´ı, jeˇz by vyhovovalo standard˚ um a bylo plnˇe kompatibiln´ı. V d˚ usledku ˇsirokého rozpˇet´ı referenˇcn´ıho modelu museli ze sv´ ych poˇzadavk˚ u tv˚ urci ustupovat a vyjasnili je aˇz v podmnoˇzinˇe, známé pod jménem GOSIP (Government OSI Profile). Pro porovnán´ı ukaˇzme paralelu s protokoly TCP/IP, které vznikaly od jednoduˇsˇs´ıho ke sloˇzitˇejˇs´ımu. Jako pˇr´ıklad bych rád uvedl elektronickou poˇstu a SMTP protokol. Prvn´ı verze umˇela pouze pˇrenáˇset zprávy v prostém textu bez moˇznosti formátován´ı, vkládán´ı obrázk˚ u, pˇr´ıloh a to vˇcetnˇe moˇznosti uˇzit´ı národn´ıch znak˚ u abecedy. Na poptávku reagovalo rozˇs´ıˇren´ı MIME (Multipurpose Internet Mail Extensions – v´ıce´ uˇcelové rozˇs´ıˇren´ı internetové poˇsty), jeˇz specifikovalo a zahrnovalo v´ yˇse zm´ınˇené nedostatky. Na následuj´ıc´ım obrázku si m˚ uˇzete prohlédnout korespondenci sedmi vrstev modelu ISO/OSI s ˇctyˇrmi vrstvami v pˇr´ıpadˇe modelu TCP/IP.

Za nejv´ıce kritizované vrstvy modelu ISO/OSI povaˇzuji vrstvu relaˇcn´ı a prezentaˇcn´ı, které maj´ı velmi omezené penzum práce oproti ostatn´ım. Naopak velké portfolio sluˇzeb se soustˇredilo do vrstvy linkové, jeˇz se následkem toho rozpadla na podvrstvy LLC a MAC. Dalˇs´ım d˚ uleˇzit´ ym rozd´ılem je pˇr´ıtomnost spojovaného charakteru pˇrenosu a spolehlivého doruˇcován´ı v ISO/OSI. Autoˇri ze svˇeta telefonn´ıch systém˚ u povaˇzovali nespolehlivou sluˇzbu za zbyteˇcnou, nevidˇeli d˚ uvod, proˇc by j´ı mˇel nˇekdo koupit a v d˚ usledku toho museli investovat do drahé vnitˇrn´ı in’ frastruktury s´ıt ov´ ych prvk˚ u. V prostˇred´ı TCP/IP je negarantovan´ y pˇrenos hojnˇe uˇz´ıván napˇr. v P2P s´ıt´ıch (s´ıtˇe, kde se informace pˇrenáˇs´ı mezi uzly bez centráln´ıho serveru), kdy aplikace implementuje algoritmus pro potvrzován´ı pˇrenesen´ ych dat dle vlastn´ı logiky a potˇreby. Spo9

jovan´ y charakter komunikace zase vycházel z fungován´ı telefonn´ı s´ıtˇe, avˇsak na pˇrenos malého mnoˇzstv´ı dat se nevyplat´ı navazovat spojen´ı. V rámci propojován´ı s´ıt´ı se ukázal model ISO/OSI jako velmi slab´ y, od zaˇca´tku pˇredpokládal topologie s´ıti v dikci vlád, proto je podpora propojován´ı s´ıt´ı (internetworking) velmi slabá. Problematiky se t´ yká i návrh linkové vrstvy pouze na dvoubodov´ ych spoj´ıch, naˇceˇz musel b´ yt dodateˇcnˇe zakomponován mechanismus pracuj´ıc´ı se sd´ılen´ ym médiem, kter´ y vy´ ustil v rozpad linkové vrstvy. Model poˇc´ıtal s podobou velmi rozsáhlé s´ıtˇe oproti s´ıti lokáln´ı a dlouho dobu byl prosazován jako oficiáln´ı a certifikované ˇreˇsen´ı. Po tˇrech fáz´ıch pˇribliˇzován´ı a smiˇrován´ı s potˇrebami poˇc´ıtaˇcové s´ıtˇe se stal ISO/OSI model prakticky mrtv´ ym ˇreˇsen´ım, na kterém se ukázaly prvotn´ı nedostatky v celkové koncepci a filosofii pˇr´ıstupu.

2.4

Linkov´ a vrstva a technologie Ethernet

S´ıt’ov´ y model TCP/IP nespecifikuje linkové vrstvy pouˇzité na pˇrenosové s´ıti, pouze specifikuje vrstvu s´ıt’ového rozhran´ı, která je závislá na pouˇzit´ı konkrétn´ıho linkového protokolu. Nejpouˇz´ıvanˇejˇs´ım linkov´ ym protokolem je Ethernet, dále pak z historického hlediska Token ring, FDDI ˇci X.25. Technologie Ethernetu se zrodila ve stˇredisku PARC a nejznámˇejˇs´ı jména spjatá s jeho genez´ı jsou Robert Metcalfe a David Boggs. Firma Xerox si nechala po v´ yvoji zaregistrovat jméno jako ochranou známku. Po pˇredloˇzen´ı návrhu na standardizaci spoleˇcnosti IEEE se v´ yvoj vydal dvˇema hlavn´ımi v´ yvojov´ ymi smˇery. IEEE standardizovalo Ethernet, p˚ uvodnˇe navrˇzen´ y firmou Xerox, jako standard 802.3, kter´ y se odliˇsuje od p˚ uvodn´ıho návrhu. Autoˇri p˚ uvodn´ıho návrhu zakotvili koncepci Ethernetu do pr˚ umyslového standardu, známému jako Ethernet II (RFC 894). Oba zm´ınˇené formáty nevyluˇcuj´ı vzájemnou koexistenci a dle RFC 894 mus´ı b´ yt ve svˇetˇe TCP/IP kaˇzd´ y poˇc´ıtaˇc schopen komunikovat pomoc´ı Ethernetu II. Atributy paket˚ u dle obou specifikac´ı naleznete na dalˇs´ım obrázku.

Pˇri svém návrhu byl Ethernet koncipován jako technologie s pˇr´ıstupovou metodou CSMA/CD, kdy se pˇredpokládá sd´ılené médium, zaˇr´ızen´ı maj´ı pˇr´ıposlech nosné a jsou schopny detekovat kolize. Filosofie nezaruˇcuje kaˇzdému, ˇze bude hned schopen vys´ılat a proto technologie nen´ı vhodná automaticky do m´ıst, kde potˇrebujeme nˇejaké záruky na maximáln´ı dobu do odvys´ılán´ı. Od podpory na linkové vrstvˇe se odv´ıj´ı i garance sluˇzeb QoS, na nˇeˇz mus´ı b´ yt myˇsleno jiˇz od nejniˇzˇs´ıch vrstev. Ethernet byl navrˇzen jako 1-perzistentn´ı, tedy ˇcekaj´ıc´ı na konec jiného vys´ılán´ı, ale v d˚ usledku mikrosegmentace na u ´rovni pˇrep´ınaˇc˚ u je princip dnes zastaral´ y a pouˇz´ıvan´ y hojnˇe sp´ıˇse v s´ıt´ıch typu 802.11 (bezdrátové lokáln´ı s´ıtˇe). 10

Pˇri programován´ı modulu pro naˇc´ıtán´ı a zpracován´ı Ethernetov´ ych rámc˚ u jsou nejd˚ uleˇzitˇejˇs´ımi atributy: zdrojová a c´ılová hardwarová adresa ve formátu EUI-48 a typ pouˇzitého s´ıt’ového protokolu, zabaleného uvnitˇr paketu. Vzájemná koexistence schopnosti detekce rámc˚ u typu Ethernet II a 802.3 je moˇzná za pˇredpokladu, ˇze vˇsechny typy s´ıt’ového nosiˇce maj´ı konstantu vˇetˇs´ı, neˇz je maximáln´ı velikost linkového rámce (1 500B). Podm´ınka je zajiˇstˇena, ale nen´ı pˇresnˇe dáno, ˇze do budoucna nem˚ uˇze IEEE, správce Ethernetu, pˇriˇradit konstanty niˇzˇs´ı neˇz maximáln´ı velikost. Adresy ve formátu EUI-48 se skládaj´ı ze dvou ˇcást´ı: prvn´ı ˇctyˇri bajty jednoznaˇcnˇe identifikuj´ı v´ yrobce zaˇr´ızen´ı, jenˇz lze nalézt ve veˇrejnˇe dostupném zdroji na stránkách standard˚ u IEEE[4] a zbytek adresy je jiˇz jednoznaˇcn´ ym identifikátorem vyrobené s´ıt’ové karty, avˇsak nˇekteré operaˇcn´ı systémy umoˇzn ˇuj´ı pˇresto jejich konfiguraci.

2.5

S´ıt’ov´ a vrstva IP

Prvn´ı vrstva, kterou plnˇe pokr´ yvá protokol TCP/IP je vrstva s´ıt’ová, jedná se o jedin´ y pˇrenosov´ y protokol, kter´ y se snaˇz´ı b´ yt hardwarovˇe nezávisl´ y a univerzáln´ı. Ve své podstatˇe funguje jako pokliˇcka, která um´ı fungovat nad vˇsemi linkov´ ymi protokoly a na druhé stranˇe jsou vˇsechny transportn´ı protokoly implementovány právˇe nad n´ı. Ve verzi 4, která se pomalu stává nedostaˇcuj´ıc´ı hlavnˇe z hlediska mnoˇziny moˇzn´ ych unikátn´ıch veˇrejn´ ych adres, se uˇz´ıvaj´ı virtuáln´ı adresy, zcela bez korespondence k hardwaru (v modelu TCP/IP). Hlavn´ım u ´kolem s´ıt’ové vrstvy je volba smˇer˚ u odes´ılán´ı paket˚ u (smˇerován´ı) a pˇrenos datagram˚ u. Pro ochranu proti zacyklen´ı bˇehem pˇrenosu, je do hlaviˇcky zanesena informace o poˇctech hop˚ u, které jeˇstˇe m˚ uˇze paket pˇrekonat pˇred sv´ ych zánikem, problémem je ale fakt, ˇze pˇri kaˇzdém pr˚ uchodu smˇerovaˇcem mus´ıme pˇrepoˇc´ıtávat kontroln´ı souˇcet. Implementace vrstvy je nutná jak v hostitelsk´ ych poˇc´ıtaˇc´ıch, tak v uzlech pˇrenosové infrastruktury. Oproti tomu ale samotn´ y protokol poskytuje pouze nespolehlivou a nespojovanou sluˇzbu, je nositelem pouze nutného minima. V d˚ usledk˚ u této vlastnosti nemáme ˇza´dné záruky o doruˇcen´ı, nemáme garanci nepoˇskozen´ı dat, doba doruˇcen´ı se m˚ uˇze znaˇcnˇe liˇsit a i proto nen´ı podporovaná garance kvality sluˇzeb (QoS – kvalita sluˇzby). Volba variabiln´ı velikosti pˇrenáˇseného paketu je závislá na uˇz´ıvané pˇrenosové linkové vrstvˇe a v protokolu je implementován mechanizmus fragmentace, kdy se pˇri pˇrenosu velkého rámce rozdˇel´ı na segmenty, které jiˇz co do velikosti vyhovuj´ı technologie pˇrenosu. Nejrozˇs´ıˇrenˇejˇs´ı verz´ı protokolu IP je verze 4, která v sobˇe nese 32-bitové s´ıt’ové adresy, jejichˇz kapacita, co do velikosti pˇridˇelen´ ych veˇrejn´ ych adres, dosahuje svého limitu. Dnes se zvolna pˇrecház´ı na verzi IPv6. Atributy s´ıt’ové vrstvy ve verzi 4 najdete na následuj´ıc´ım obrázku. K podstatn´ ym atribut˚ um s´ıt’ov´ ych paket˚ u mus´ım zaˇradit identifikaci spolu s offsetem, které slouˇz´ı pro u ´ˇcely fragmentace. Atribut TTL (Time to live – ˇzivotnost paketu) zamezuje zacyklen´ı paketu v s´ıti donekoneˇcna a udává, kolik maximálnˇe m˚ uˇze paket navˇst´ıvit pˇrep´ınaˇc˚ u pˇred t´ım, neˇz bude zam´ıtnut. Protokolem odliˇsujeme typ transportn´ıho protokolu, jenˇz je uloˇzen v datech. Nejˇcastˇeji vyskytuj´ıc´ımi konstantami jsou konstanty pro TCP a UDP. Identifikace s´ıt’ov´ ych ’ karet (rozhran´ı) je zajiˇstˇená d´ıky s´ıt ov´ ym adresám délky 4B, které nejˇcastˇeji zapisujeme ve formátu napˇr. 192.168.0.1. Adresy v protokolu TCP/IP nemaj´ı ˇzádnou korespondenci s hardwarem s´ıt’ové karty a jedno rozhran´ı (karta) m˚ uˇze obsahovat v´ıce adres zároveˇ n. Délka hlaviˇcky vymez´ı volitelná rozˇs´ıˇren´ı hlaviˇcky a urˇc´ı poˇcátek dat vyˇsˇs´ı vrstvy. V d˚ usledku velké rychlosti pˇridˇelován´ı veˇrejn´ ych IPv4 adres vznikl problém s jejich nedostatkem, kter´ y se ˇcásteˇcnˇe podaˇrilo zbrzdit pˇridˇelován´ım menˇs´ıch blok˚ u IP adresa (za pouˇzit´ı 11

s´ıt’ov´ ych masek). Dále vznikl NAT a PAT, které maj´ı za u ´kol maskovat navenek uzly, pˇripojené v lokáln´ıch s´ıt´ıch LAN. Pˇres to bylo nevyhnutelné pˇrej´ıt na novou verzi, která pracuje se s´ıt’ov´ ymi adresami velikosti 16B, které jsou bohatˇe nadimenzovány co do spektra veˇrejn´ ych adres. Kromˇe vˇetˇs´ıho adresn´ıho prostoru pˇribyla bezstavová autokonfigurace, plná podpora multicastu (vys´ılán´ı k v´ıce uzl˚ um souˇcasnˇe), moˇznost odes´ılán´ı jumbogram˚ u (velké pakety). Kontroln´ı souˇcet souˇca´st´ı hlaviˇcky a jako novinka pˇribyla moˇznost pˇr´ıdavn´ ych hlaviˇcek, které podporuj´ı napˇr´ıklad zabezpeˇcen´ı ˇci mobiln´ı adresován´ı. Detail hlaviˇcky paketu je prezentován na následuj´ıc´ım obrázku.

Atributy nejsou nepodobné starˇs´ı verzi, novinkou ale je moˇznost pˇripojen´ı rozˇsiˇruj´ıc´ıch hlaviˇcek, které na jednu stranu ˇsetˇr´ı m´ısto, pokud nechceme nést nav´ıc informace, a na druhou stranu lze rozˇs´ıˇren´ı navzájem kombinovat a m˚ uˇzeme jich mezi základn´ı hlaviˇcku a data pˇripojit v´ıce. Oproti starˇs´ı verzi IPv4 odpadl kontroln´ı souˇcet, protoˇze transportn´ı vrstvy poˇc´ıtaj´ı kontroln´ı souˇcet také z metahlaviˇcky s´ıt’ové vrstvy a nen´ı nutná jeho modifikace. Základn´ı i rozˇsiˇruj´ıc´ı hlaviˇcka obsahuj´ı ukazatel, identifikuj´ıc´ı dalˇs´ı hlaviˇcku a vzniká tak jak´ ysi spojov´ y seznam pˇripojen´ ych hlaviˇcek. Nejpouˇz´ıvanˇejˇs´ı hlaviˇcky jsou tyto: fragmentaˇcn´ı, za12

bezpeˇcen´ı ˇci smˇerovac´ı. S´ıt’ové adresy narostly co do velikosti ˇctyˇrnásobnˇe a nejˇcastˇeji se zapisuj´ı po 2-bajtov´ ych bloc´ıch oddˇelen´ ych dvojteˇckou s vynechán´ım nulov´ ych segment˚ u, napˇr. 2001:db8::1428:57ab.

2.6

Transportn´ı vrstva

V rodinˇe TCP/IP rozliˇsujeme dva základn´ı typy transportn´ıch protokol˚ u: TCP a UDP, oba protokoly budou pˇredstaveny v následuj´ıc´ıch kapitolách. Z pohledu s´ıt’ové vrstvy nerozliˇsujeme jednotlivé entity (programy, démony, atd.) s´ıt’ového rozhran´ı, ale pouze doruˇcujeme mezi uzly s´ıtˇe. Entity v systému se pˇripojuj´ı k port˚ um, které nejsou niˇc´ım jin´ ym neˇz ˇc´ısly v rámci systému a konkrétn´ı implementace jejich pouˇzit´ı závis´ı na operaˇcn´ım systému, kdy napˇr. u BSD ˇci Unixu se hojnˇe uˇz´ıvaj´ı sockety, coˇz je jakási abstrakce nad soubory. Ve svˇetˇe Internetu se postupem ˇcasu zabydlely tzv. well-known (dobˇre známé) porty, jejichˇz seznam byl udrˇzován v RFC dokumentech (posledn´ı RFC 1700), dnes doˇslo k pˇrechodu k online databázi na stránkách organizace IANA. TCP (Transmission Control Protocol) pˇrináˇs´ı moˇznost spolehlivého a spojovaného kanálu, jenˇz se d´ıky udrˇzován´ı stav˚ u dokáˇze vypoˇrádat se ztrátou ˇci modifikac´ı dat. Pˇri pˇrenosech dat vzniká reˇzie s t´ımto mechanismem spojená, kdy základn´ı ideou, která zajiˇst’uje spolehlivost je kontinuáln´ı zas´ılán´ı potvrzen´ı o pˇrijat´ ych datech.

2.6.1

Protokol UDP

Datagramová sluˇzba poskytuje základn´ı nadstavbu nad s´ıt’ov´ ymi protokoly, stala se hojnˇe vyuˇz´ıvanou pro aplikace poˇzaduj´ıc´ı rychlost a malou reˇzii. Funguje nespolehlivˇe a nespojovanˇe, vytváˇr´ı uˇzivateli iluzi blokového pˇrenosu a funguje bezstavovˇe. Zaj´ımavost´ı je kontroln´ı souˇcet, kter´ y kromˇe samotné hlaviˇcky a dat UDP paketu pouˇz´ıvá i pseudohlaviˇcku ze s´ıt’ové vrstvy. Atributy UDP paketu jsou znázornˇeny na obrázku.

Pakety obsahuj´ı pouze dvoubajtová ˇc´ısla zdrojového a c´ılového portu, dále délku hlaviˇcky protokolu UDP a jiˇz zmiˇ novan´ y kontroln´ı souˇcet. Pro jeˇstˇe vˇetˇs´ı urychlen´ı existuje i modifikace UDP protokolu tzv. protokol UDP Lite, kter´ y neobsahuje kontroln´ı souˇcet hlaviˇcky a pouˇz´ıvá se napˇr. pˇri pˇrenosu hlasu ˇci videa, kde poˇzadujeme pravidelné a rychlé doruˇcovan´ı.

2.6.2

Protokol TCP

Protokol TCP (Transmision Control Protocol) se stal u ´spˇeˇsn´ ym transportn´ım protokolem, kter´ y se dokáˇze efektivnˇe vypoˇra´dat s nespolehliv´ ym a nespojovan´ ym charakterem s´ıt’ové vrstvy a na13

stol´ı uˇzivateli systém, jenˇz garantuje plnou spolehlivost. Sluˇzba je poskytována na spojovaném charakteru, tj. nejprve je navázáno spojen´ı mezi uzly, poté se pˇrenáˇs´ı data (obousmˇernˇe) a nakonec se strany domluv´ı na ukonˇcen´ı spojen´ı (i jednostrannˇe). Garance spolehlivosti zahrnuje oblasti jako je v´ ypadek paketu, duplicitn´ı doruˇcen´ı a také ˇspatné poˇrad´ı doruˇcen´ ych dat. Jak jiˇz bylo zm´ınˇeno, spojen´ı se navazuj´ı pouze dvoubodovˇe, pˇr´ıjemce i odes´ılatel je unikátn´ı. K atribut˚ um protokolu lze zm´ınit ˇr´ızen´ı toku, kontinuáln´ı potvrzován´ı pˇriˇsedˇs´ıch dat, schopnost vypoˇrádat se s zahlcen´ım (prostˇrednictv´ım publikován´ı velikosti okna) a tvorba iluze bajtové ˇ aˇri se m˚ roury, jeˇz distribuuje informace po bajtech (nikoli po bloc´ıch). Cten´ uˇze vybavit lehká paralela s pˇrepojován´ım okruh˚ u, ale ve skuteˇcnosti se jedná o softwarovou emulaci virtuáln´ıho okruhu, o kterém vnitˇrn´ı uzly s´ıt’ové infrastruktury nic nevˇed´ı a nebo ani nepodporuj´ı tak vysokou vrstvu rodiny protokol˚ u TCP/IP. Na samotnou strukturu paket˚ u protokolu TCP m˚ uˇzete nahlédnout na obrázku.

´ Uvod hlaviˇcky je identick´ y s bratrsk´ ym protokolem UDP, obsahuje tedy zdrojov´ y a c´ılov´ y port. Následuje poˇradové ˇc´ıslo, udávaj´ıc´ı pozici v bajtové rouˇre, dalˇs´ım 4-bajtov´ ym identifikátorem je potvrzovac´ı ˇc´ıslo, jenˇz dává najevo protistranˇe, které posledn´ı poˇradové ˇc´ıslo bylo u ´spˇeˇsnˇe pˇrijato. Urˇcen´ı vlastnost´ı paketu, které lze povaˇzovat za platné se uplatˇ nuje d´ıky pˇrep´ınaˇc˚ um, napˇr. ACK (potvrzovac´ı ˇc´ıslo je platné), PSH (okamˇzité odeslán´ı dat), RST (resetován´ı spojen´ı), SYN (ˇza´dost o sestaven´ı spojen´ı) a FIN (ˇza´dost o ukonˇcen´ı relace). Pro u ´ˇcely ˇr´ızen´ı toku obsahuje paket velikost okna, kter´ ym si obˇe strany pˇredávaj´ı informaci o volném m´ıstu v zásobn´ıc´ıch. Na následuj´ıc´ım obrázku m˚ uˇzeme vidˇet pr˚ ubˇeh navazován´ı spojen´ı, pˇrenos dat a ukonˇcen´ı spojen´ı. Navazován´ı spojen´ı se realizuje pomoc´ı tzv. tˇr´ıstavového handshaku“ (podán´ı ruky), ” kdy ˇzadatel o zaloˇzen´ı spojen´ı (klient) sestav´ı paket se zapnut´ ym pˇr´ıznakem SYN, náhodnˇe vygeneruje sekvenˇcn´ı ˇc´ıslo a odeˇsle paket c´ılovému poˇc´ıtaˇci (server). Server po korektn´ım doruˇcen´ı paketu sestav´ı obdobn´ y paket, ale nav´ıc uvede pˇr´ıznak ACK, kter´ ym potvrd´ı inicializaˇcn´ı sekvenˇcn´ı ˇc´ıslo. Pokud je rámec správnˇe doruˇcen, je na klientovi, aby odeslal paket pouze s potvrzen´ım a spojen´ı dále povaˇzujeme za ustavené, na druhé stranˇe je opakováno odeslán´ı paketu a obˇe strany se ˇr´ıd´ı algoritmem pro délky vyprˇsen´ı ˇcasového limitu. Pˇri následném odes´ılán´ı dat 14

je vˇzdy paket opatˇren sekvenˇcn´ım ˇc´ıslem, které koresponduje s pozic´ı v bajtovém proudu, bráno od inicializaˇcn´ıho sekvenˇcn´ıho ˇc´ısla. Druhá strana pˇrenosového kanálu má za u ´kol odes´ılat potvrzen´ı o pˇriˇsedˇc´ıch datech a to pr˚ ubˇeˇznˇe. Na závˇer spojen´ı dojde k vyˇza´dán´ı ukonˇcen´ı z jedné ze stran, zm´ınˇená strana odeˇsle rámec se zapnut´ ym pˇr´ıznakem FIN a korektn´ım sekvenˇcn´ım ˇc´ıslem. Po doruˇcen´ı potvrzen´ı od druhé strany se kanál stává pouze jednosmˇern´ ym a po opakován´ı stejného kroku stranou druhou spojen´ı definitivnˇe zaniká jako ukonˇcené. Bˇehem celého pˇrenosu je potvrzovac´ı ˇc´ıslo vˇzdy o jedna vˇetˇs´ı neˇz je pˇriˇs´ıdˇs´ı sekvenˇcn´ı ˇc´ıslo.

15

Pasivn´ı s´ıt’ov´ e analyz´ atory 3.1

Definice

Pasivn´ım s´ıt’ov´ ym analyzátorem rozum´ıme software, jenˇz je zamˇeˇren´ y na rozbor s´ıt’ové ko’ munikace na základˇe odchycen´ ych záznam˚ u paket˚ u ze s´ıt ové karty bez jakékoliv modifikace pˇrenáˇsen´ ych dat. Data jsou ukládána do binárn´ıch soubor˚ u r˚ uzn´ ych formát˚ u, mezi nejznámˇejˇs´ı ´ formáty patˇr´ı: pcap, pcapng ˇci cap (Sun Microsystems, Microsoft Network Monitor). Ukolem analyzátoru je naˇc´ıst odchycená data a dle vrstvy s´ıt’ového protokolu vyhodnotit hlaviˇcku a odeslat vrstvˇe vyˇsˇs´ı, pokud je v datech zachycena. Takto mohou z odchycen´ ych rámc˚ u na u ´rovni linkové vrstvy vznikat napˇr. TCP spojen´ı, na nichˇz je kupˇr´ıkladu provozován hojnˇe uˇz´ıvan´ ych protokol HTTP. Schopnosti analyzátoru lze klasifikovat dle nˇekolika metrik: pˇr´ıtomnost grafického rozhran´ı (GUI), mnoˇzina podporovan´ ych protokol˚ u na vrstvách s´ıt’ového modelu TCP/IP ˇci pˇr´ıtomnost statistick´ ych v´ ystup˚ u. Pˇri komunikaci se s´ıt’ová karta chová t´ım zp˚ usobem, ˇze na základˇe své hardwarové adresy pˇrij´ımá pouze data pro ni urˇcená a pˇredává je jádru operaˇcn´ıho systému. V promiskuitn´ım módu jsou ale pˇrij´ımána vˇsechna data, bez ohledu na adresu skuteˇcného adresáta. Typicky jsou pro zapnut´ı promiskuitn´ıho módu nutná práva superuˇzivatele v pˇr´ıpadˇe operaˇcn´ıho systému UNIX a metoda je základem pro z´ıskáván´ı dat pro vˇsechny druhy s´ıt’ov´ ych analyzátor˚ u. Na základˇe definice a deklarovan´ ych kritéri´ı jsem zvolil následuj´ıc´ı analyzátory pro bliˇzˇs´ı popis: Tcpdump, Tcpflow, Wireshark a Netgrind.

3.2

Tcpdump

Nejstarˇs´ım analyzátorem z vybrané trojice je Tcpdump, jenˇz spatˇril svˇetlo svˇeta na poˇca´tku 90. let 20. stolet´ı. Tcpdump je typicky souˇcást´ı kaˇzdé mutace systému UNIX a funguje pouze v konzolovém reˇzimu. Program um´ı pracovat s uloˇzen´ ymi daty v souboru, um´ı sám ukládat data do takového souboru (formát pcap) a v´ yhodou pro uˇzivatele je i promiskuitn´ı mód, funguj´ıc´ı s daty v reálném ˇcase. Ve volbách je nab´ızena ˇsiroká paleta pˇrep´ınaˇc˚ u pro volbu u ´rovnˇe v´ ypis˚ u zobrazen´ ych dat, moˇznosti konverze IP adres na DNS záznamy ˇci rychlosti uˇzit´ı protokolov´ ych modul˚ u. Data se daj´ı lehce filtrovat dle tˇrech základn´ıch kategori´ı: typ, smˇer a protokol. Pro ilustraci bude lepˇs´ı ukázat moˇznosti filtrován´ı na pˇr´ıkladech. ip host ace and not helios tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0) tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 ether[0] & 1 = 0 and ip[16] >= 224 Program Tcpdump podporuje nativnˇe solidn´ı mnoˇzinu protokol˚ u, jejichˇz data dokáˇze v textové formˇe prezentovat. K v´ıce specifick´ ym protokol˚ um lze zaˇradit: protokoly pro sd´ılen´ı soubor˚ u jako NFS ˇci SMB, Kip AppleTalk, IP fragmentace nebo pˇrenosov´ y protokol ATP. 16

21:41:11.005508 arp who-has 192.168.2.104 tell 192.168.2.1 21:41:11.005527 arp reply 192.168.2.104 is-at 00:13:e8:0a:61:93 (oui Unknown) 21:41:11.126551 IP 167.col.prg.mynet.cz.http > 192.168.2.104.50485: S 1862118129:1862118129(0) ack 1764776068 win 65535 Na vloˇzeném pˇr´ıkladu je ukázána funkce prezentován´ı vypsan´ ych dat, prvn´ı 2 ˇra´dky se t´ ykaj´ı ’ protokolu ARP, kter´ y pˇrevád´ı virtuáln´ı adresy s´ıt ové vrstvy na adresy fyzické (MAC). Nejprve se prvek s´ıtˇe s adresou 192.168.2.1 ptá pomoc´ı broadcastu na fyzickou adresu 192.168.2.1 a následnˇe dostává také odpovˇed’. Tˇret´ı ˇra´dek ukazuje segment TCP spojen´ı, které je HTTP poˇzadavkem, jedná se o druh´ y paket ze tˇr´ıstavového navázán´ı spojen´ı.

3.3

Tcpflow

Jako o druhém analyzátoru se zm´ın´ım o programu Tcpflow, kter´ y vznikl na pˇrelomu tis´ıcilet´ı. Program za pomoci promiskuitn´ıho módu naˇc´ıtá pakety a rekonstruuje jednotlivá TCP spojen´ı. Spojen´ı jsou ukládána ve v´ ychoz´ım nastaven´ı do soubor˚ u ve formátu, kde figuruj´ı zdrojová a c´ılová IP adresa a také porty. Obsahem soubor˚ u jsou pˇrenáˇsená data po spojen´ıch, program bohuˇzel nepodporuje IP fragmentaci a posledn´ı uvolnˇená stabiln´ı verze se datuje do roku 2003. Podobnˇe jako v pˇr´ıpadˇe pˇredchoz´ıho pˇredstaveného programu umoˇzn ˇuje Tcpflow filtrovat data za pomoci v´ yraz˚ u. Z filtrovac´ı ˇskály bych zm´ınil moˇznost filtrovat na základe doménového jména uzlu, IP adresy uzlu, velikosti datové rámce ˇci ethernetového typu paketu. Program je co do velikosti minimalistick´ y a jeho funkˇcnost je zahrnuta v programu Wireshark, kde má uˇzivatel moˇznost zobrazit data pˇrenáˇsená po TCP spojen´ı. Program nen´ı postaven´ y ˇcistˇe na spojen´ı TCP, ale porad´ı si i s daty pˇrenáˇsen´ ymi po protokolu UDP ˇci ICMP. V´ ystupn´ı formát si m˚ uˇzete prohlédnout na pˇriloˇzené ukázce. 209.085.135.139.00080-192.168.002.104.44056: HTTP/1.1 200 OK Date: Tue, 13 Jul 2010 20:26:23 GMT Expires: Tue, 13 Jul 2010 21:26:23 GMT Cache-Control: public, max-age=3600 Content-Type: text/javascript; charset=utf-8 Content-Encoding: gzip Server: gws Content-Length: 170 X-XSS-Protection: 1; mode=block

3.4

Wireshark

Wireshark je dnes povaˇzovan´ y za nejlepˇs´ı open-source s´ıt’ov´ y analyzátor s grafickou nadstav’ bou. Nab´ız´ı ˇsirokou podporu s´ıt ov´ ych protokol˚ u, funguje na ˇsiroké mnoˇzinˇe operaˇcn´ıch systém˚ u poˇc´ınaje UNIX, pˇres BSD, Solaris a konˇce operaˇcn´ım systémem Windows. Základem je konzolov´ y analyzátor TShark, jenˇz se sv´ ymi v´ ypisy do konzole podobá programu tcpdump, ale nab´ız´ı ˇsirˇs´ı portfolio protokol˚ u. Wireshark dokáˇze pˇrinutit fungovat s´ıtovou kartu poˇc´ıtaˇce v promiskuitn´ım módu a t´ım z´ıskává pakety ze s´ıtˇe. Z´ıskaná data je moˇzno filtrovat, pˇreskupovat a ukládat do formátu pcap ˇci dalˇs´ıch podporovan´ ych. Grafická nadstavba napsaná v GTK+ nab´ız´ı pˇrehledn´ y seznam paket˚ u, pˇrináˇs´ı moˇznost zabarvován´ı, filtrován´ı dle atribut˚ u paket˚ u a v ne17

posledn´ı ˇradˇe pˇrináˇs´ı moˇznost zapojen´ı vlastn´ıho zásuvného modulu ˇci zapojen´ı modulu jiného, neˇz je ve v´ ychoz´ım nastaven´ı vybrán. Za nejvˇetˇs´ı pˇrednost programu povaˇzuji bohatou paletu statistick´ ych v´ ystup˚ u, zobrazen´ı dat pˇrenesen´ ych v rámci TCP spojen´ı a pˇrehledné zobrazen´ı vrstev s´ıt’ového modelu u jednotliv´ ych rámc˚ u. Ukázku programu lze nalézt na obrázku.

3.4.1

Historie

Historie programu se datuje do roku 1997, kdy Gerald Combs zaˇcal vyv´ıjet pˇredka dneˇsn´ıho programu pod jménem Ethereal. Po nˇekolika pˇreruˇsen´ıch v´ yvoje v roce 1998 spojil Gerard Combs své s´ıly s Richardem Sharpem a odstartovali v´ yvoj dekódovac´ıch modul˚ u, specifick´ ych pro jednotlivé protokoly vrstevnatého modelu architektury TCP/IP. V roce 2006 doˇslo k pˇrejmenován´ı na nynˇejˇs´ı jméno a po deseti letech v´ yvoje byla v roce 2008 uvolnˇena verze 1.0, která je povaˇzována za prvn´ı kompletn´ı verzi, pokr´ yvaj´ıc´ı základn´ı mnoˇzinu protokol˚ u a autoˇri ji pˇredstavili téhoˇz roku na konferenci SharkFest.

3.4.2

Filtrov´ an´ı

Filtrován´ı dat nab´ız´ı uˇzivateli jednak pˇrednastavené filtrovac´ı profily typu: TCP only“, no ARP ” ” and no DNS“. V zásadˇe lze vytvoˇrit libovolnou logickou klauzuli pomoc´ı pˇreddefinovan´ ych atribut˚ u a základn´ıch operand˚ u, jako je porovnán´ı, pˇr´ısluˇsnost do mnoˇziny, atd. Kritéria lze skládat z primitivn´ıch atribut˚ u, jako je IP adresa zdrojového poˇc´ıtaˇce, ale zabrousit lze i do mnohem detailnˇejˇs´ıch atribut˚ u. Jako zaj´ımavé atributy, které lze pouˇz´ıt pˇri specifikaci podm´ınky, mohu uvést jméno pˇr´ıkazu protokolu SMTP, velikost pˇrenáˇseného obrázku formátu PNG pomoc´ı HTTP ˇci pˇrezd´ıvku adresáta pˇrenosového protokolu Yahoo Messanger.

18

3.4.3

Anal´ yza r´ amc˚ u

Anal´ yza pˇrenesen´ ych rámc˚ u je ˇr´ızena stromem dekodér˚ u, které dle atribut˚ u vrstevnatého modelu rozliˇsuj´ı dekodér, kter´ y bude uˇzit. Základn´ımi atributy pro detekci jsou ethertype“ na linkové ” vrstvˇe, IP protokol na vrstvˇe s´ıt’ové a zdrojov´ y a c´ılov´ y port na vrstvˇe transportn´ı jak u TCP, tak i UDP. Dekodéry uˇzité na rozklad lze mˇenit a Wireshark nab´ız´ı i moˇznost naprogramován´ı takového modulu. Pro u ´spˇech takto velkého programu je zm´ınˇená ˇcást programu kl´ıˇcová, kdy v dneˇsn´ı dobˇe v´ıce jako 500 v´ yvojáˇr˚ u pˇrisp´ıvá a programuje rozˇs´ıˇren´ı, která jsou nezávislá na ostatn´ıch a komunita udrˇzuje bohatou dokumentaci návod˚ u, jak postupovat pˇri v´ yvoji.

3.4.4

Statistick´ e komponenty

Statistickou komponentu Wiresharku povaˇzuji za nejv´ıce pˇr´ınosnou ˇcást programu. K základn´ım jednotkám patˇr´ı sumáˇr obsahuj´ıc´ı informace o odchycen´ ych datech a informace o hierarchii pouˇzit´ ych protokol˚ u bˇehem komunikace. Dalˇs´ım uˇziteˇcn´ ym nástrojem je pˇrehled komunikac´ı, kde na základˇe protokol˚ u nalezneme informace mezi kter´ ymi uzly se pˇrenáˇsela data. Mezi grafické v´ ystupy mus´ım zm´ınit histogram velikosti paket˚ u a velmi názorn´ y Graf tok˚ u, jenˇz v pr˚ ubˇehu ˇcasu vizualizuje toky dat v obou smˇerech komunikace. Pro protokol TCP jsou v nab´ıdce grafy stˇredn´ı doby obrátky, velikosti pˇrenáˇsen´ ych dat v pr˚ ubˇehu ˇcasu ˇci seznamu poˇzadavk˚ u na zobrazené webové stránky.

3.5

Netgrind

Netgrind vznikl jako jednoduch´ y, srozumiteln´ y a pomocn´ y program pˇri anal´ yze zejména protokolu HTTP a vrstev, které leˇz´ı pod n´ım. Autorem je vedouc´ı mé práce Mgr. Martin Mareˇs, Ph.D. a stal se inspirac´ı pro téma moj´ı práce. Konzolov´ y program nab´ız´ı statistiky o správnˇe zpracovan´ ych, ˇspatn´ ych a neplatn´ ych paketech na vrstvách s´ıt’ového modelu a jako hlavn´ı produkt prezentuje v pˇrehledném v´ ypisu HTTP spojen´ı, detailn´ı informace o adresách, portech, poˇctech pˇrenesen´ ych dat, URL a typy dokumentu dle standardu rozˇs´ıˇren´ı MIME. Po nastaven´ı m˚ uˇzeme nechat zapsat statické informace o jednotliv´ ych pˇrenosech do adresáˇre pro budouc´ı zobrazen´ı pomoc´ı grafového kresl´ıc´ıho nástroje gnuplot. K programu je pˇribalena mnoˇzina skript˚ u v jazyce Perl, které transformuj´ı nashromáˇzdˇené statistiky a vykresluj´ı v´ ystupn´ı grafy. Grafy se t´ ykaj´ı poˇctu aktuáln´ıch spojen´ı v ˇcase, velikosti pˇrenáˇsen´ ych dat v ˇcase ˇci délce ˇcekán´ı HTTP poˇzadavku. source 192.168.2.104:46414 192.168.2.104:46415 192.168.2.104:46417 192.168.2.104:46414

destination 89.250.246.4:80 89.250.246.4:80 89.250.246.4:80 89.250.246.4:80

-

res 200 200 200 200

cac ... ... ... ...

q len ttime wtime ctype 0 4883 0.075 0.050 text/html 0 2430 0.040 0.040 text/css 0 188 0.054 0.054 image/png 1 1190 0.013 0.012 image/png

met GET GET GET GET

V´ ystup z programu Netgrind poskytne pˇrehledné informace o jednotliv´ ych HTTP poˇzadavc´ıch, kdy byly uskuteˇcnˇeny v ˇcase, z jak´ ych IP adres a port˚ u doˇslo k pˇrenosu, dále z´ıskáme cenné informace o velikosti pˇrenesen´ ych datech, dobˇe vyˇr´ızen´ı poˇzadavku, MIME typu a v neposledn´ı ˇradˇe také poˇzadovan´ y soubor, jenˇz byl vyˇzádat po HTTP démonovi.

19

S´ıt’ov´ y analyz´ ator NEPAL 4.1

Pˇ redstaven´ı

Vlastn´ı s´ıt’ov´ y pasivn´ı analyzátor Network Passive Analyser (zkratka NEPAL) byl vyvinut pro u ´ˇcel bakaláˇrské práce. Program na svém vstupu akceptuje záznamy paket˚ u uloˇzen´ ych v souboru ve formátu PCAP. Program je navrˇzen´ y jako modulárn´ı systém, kdy mezi jednotliv´ ymi moduly putuj´ı datové objekty r˚ uzn´ ych tˇr´ıd. Kaˇzd´ y modul má definovanou mnoˇzinu typ˚ u vstupn´ıch a v´ ystupn´ıch objekt˚ u, kdy po pr˚ uchodu dat modulem nastane jedna z událost´ı, jeˇz modul definuje. D´ıky zm´ınˇenému aparátu je moˇzné pomoc´ı skript˚ u, napsan´ ych v jazyce Python[6], napojit v´ ystup na libovolné moduly a t´ım sestavit celou ˇskálu funkˇcn´ıch program˚ u, t´ ykaj´ıc´ıch se r˚ uzné oblasti zpracován´ı dat ze s´ıtˇe. Moduly jsou napsané v jazyc´ıch C a Python, mohou se mezi sebou libovolnˇe kombinovat a jako poj´ıtko mezi obˇema svˇety je uˇzit nástroj SWIG[7], kter´ y obaluje kód psan´ y v jazyce C do jazyk˚ u vyˇsˇs´ıch, mimo jiné i do Pythonu. Software implementuje naˇc´ıtán´ı základn´ıch protokol˚ u TCP/IP a jako ukázkové specifické moduly obsahuje modul pro zobrazen´ı poˇzadavk˚ u protokolu HTTP, modul ARP/RARP vˇcetnˇe zobrazován´ı v´ yrobc˚ u s´ıt’ov´ ych karet, statistick´ y modul (napsan´ y v Pythonu) a modul pro zobrazován´ı DNS poˇzadavk˚ u a odpovˇed´ı.

4.2

Zapojen´ı programu

Zapojen´ı práce jednotliv´ ych modul˚ u m˚ uˇze ˇctenáˇr nahlédnout na následuj´ıc´ım obrázku.

20

Pomoc´ı obdéln´ık˚ u r˚ uzn´ ych barev jsou vyznaˇceny moduly, atributy u modul˚ u symbolizuj´ı vybrané události, které m˚ uˇze modul vyvolat a na které se následnˇe m˚ uˇze dalˇs´ı modul zavˇesit. Kaˇzd´ y modul disponuje zásobn´ıkem událost´ı, kde se registruj´ı dalˇs´ı vstupn´ı moduly. Popsan´ ym zp˚ usobem je dosaˇzena modularita, schopnost zapojit vlastn´ı modul na sestavu pˇredeˇsl´ ych a systém poskytuje základn´ı transparentn´ı programátorské rozhran´ı pro napojován´ı modul˚ u. V obrázku jsou zm´ınˇená napojen´ı vyjádˇrena ˇsipkami a kruh symbolizuje putuj´ıc´ı datov´ y objekt. Na zapojen´ı staˇc´ı pouze zaregistrovat vstupn´ı metodu do zásobn´ıku událost´ı vybraného modulu a program se jiˇz postará o pˇredán´ı dat.

4.3

Datov´ y objekt

Datov´ y objekt je základn´ı jednotkou informac´ı pˇrenáˇsenou mezi moduly. Pˇri svém návrhu byl kladen d˚ uraz na co nejvˇetˇs´ı univerzálnost na stranˇe jedné a na co nej´ uspornˇejˇs´ı a nejrychlejˇs´ı ˇreˇsen´ı na stranˇe druhé. Datov´ y objekt se stal univerzáln´ı strukturou, do které lze ukládat data r˚ uzn´ ych typ˚ u (viz následuj´ıc´ı tabulka). Typ atributu INT TIME IPV4 IPV6 STRING ARRAY MAC48 DOBJ VOIDPTR

D´ elka 4B 8B 4B 16 B — — 6B 4B 4B

Popis typu atributu celé nezáporné ˇc´ıslo v rozsahu [0,4 294 967 295] uloˇzen´ı ˇcasu s pˇresnost´ı na nanosekundy IPv4 s´ıt’ová adresa IPv6 s´ıt’ová adresa ˇretˇezec ASCII znak˚ u pole bajt˚ u MAC adresa ukazatel na jin´ y datov´ y objekt vˇseobecn´ y ukazatel

Souˇcást´ı datového objektu je také zásobn´ık událost´ı, do kterého je moˇzné registrovat metody, které se zavolaj´ı, kdyˇz nastane událost. Zm´ınˇená vlastnost je napˇr´ıklad pouˇzita u TCP spojen´ı, u nˇehoˇz nastane událost, signalizuj´ıc´ı pˇrenesená data. U datov´ ych objekt˚ u rozliˇsujeme jejich tˇr´ıdy, na vstupu modul˚ u si zpravidla moduly kontroluj´ı tˇr´ıdy vstupn´ıch dat a rozhoduj´ı se, zda je zpracuj´ı. V pr˚ ubˇehu pr˚ uchodu je moˇzné za bˇehu mˇenit tˇr´ıdu datového objektu, mohou se pˇridávat atributy a ˇcasto se tak pˇri pr˚ uchodu moduly rodiny TCP/IP i dˇeje. V následuj´ıc´ı kapitole z´ıskáte pˇrehled, jaké tˇr´ıdy objektu vznikaj´ı v jak´ ych modulech, jaké tˇr´ıdy moduly podporuj´ı na svém vstupu a také jaké vznikaj´ı události.

4.4

Pˇ redstaven´ı modul˚ u

Program pracuje jako s´ıt’ov´ y analyzátor nad rodinou protokol˚ u TCP/IP a implementuje mo’ duly, které odpov´ıdaj´ı protokol˚ um s´ıt ového modelu. Pro ukázku specifick´ ych aplikac´ı je pˇridána mnoˇzina modul˚ u, které se t´ ykaj´ı problematiky pˇrevodu fyzick´ ych a s´ıt’ov´ ych adres, protokolu HTTP pro pˇrenos dokument˚ u ˇci protokolu DNS, kter´ y mimo jiné pˇrevád´ı doménová jména na ’ ’ s´ıt ové adresy (at uˇz verze 4 ˇci 6). Jako demonstrace kombinován´ı modul˚ u v obou jazyc´ıch jsem naprogramoval grafov´ y modul v jazyce Python, jenˇz uˇz´ıvá velmi dobˇre propracovanou knihovnu 21

pro v´ ystupy graf˚ u pod jménem Matplotlib[8]. V následuj´ıc´ı tabulce m˚ uˇze ˇctenáˇr nahlédnout do pˇrehledu implementovan´ ych modul˚ u v programovac´ım jazyce C a v dalˇs´ıch sekc´ıch jsou moduly charakterizovány vˇcetnˇe atribut˚ u objekt˚ u, které pˇri pr˚ uchodu tˇemito moduly vznikaj´ı. Jm´ eno modulu Modul PCAP Modul Ethernet Modul ARP Modul ARP view Modul IPv4 Modul IPv6

Zkratka PCAP ETH ARP ARPVIEW IPV4 IPV6 IPREASS

Modul IP Reassembler Modul UDP Modul TCP Modul TCP Flow Modul HTTP

Vstupn´ı objekty — PCAP packet Ethernet packet ARP packet Ethernet packet Ethernet packet IPv4 packet IPv6 packet

UDP

IPv4 IPv6 TCP IPv4 IPv6 TCPFLOW TCP

packet packet packet packet packet

HTTP

packet data packet flow data

DNS Modul DNS

TCP TCP UDP TCP TCP

V´ ystupn´ı objekty PCAP packet Ethernet packet ARP packet — IPv4 packet IPv6 packet IPv4 packet IPv6 packet IP reassembly UDP packet TCP packet TCP flow TCP data — —

Tabulka 4.1: Tabulka modul˚ u

4.4.1

Modul PCAP

Vstupn´ı modul kaˇzdého zapojen´ı naˇc´ıtá sekvenˇcnˇe uloˇzené a pˇrenáˇsené rámce, modul vyuˇz´ıvá sluˇzeb knihovny PCAP[9], jeˇz ukládá do souboru s pˇr´ıponou pcap celé rámce v binárn´ı podobˇe. V hlaviˇcce takového souboru jsou deklarovány atributy o maximáln´ı délce zachycen´ ych rámc˚ u, ˇcasovém posunu oproti ˇcasu nultému poledn´ıku ˇci typu linkové vrstvy. Po pr˚ uchodu modulem vzniká datov´ y objekt, jenˇz nese binárn´ı data po médiu pˇrenáˇsená, informace o p˚ uvodn´ı a odchycené velikosti a v posledn´ı ˇradˇe také ˇcas pr˚ uchodu paketu s´ıt’ovou kartou. O detailech atribut˚ u vás seznám´ı následuj´ıc´ı tabulka, po n´ıˇz následuje tabulka s v´ ypisem událost´ı. Atribut pcap frame pcap time pcap origlen pcap packet

Typ INT TIME INT ARRAY

Popis atributu poˇradové ˇc´ıslo paketu datum odchycen´ı paketu p˚ uvodn´ı velikost odchyceného rámce data odchyceného paketu

22

Ud´ alost Popis ud´ alosti Typ objektu packet vznik nového rámce PCAP packet

4.4.2

Modul Ethernet

Ethernetov´ y modul se stará o správné naˇcten´ı atribut˚ u pro datov´ y objekt Ethernet packet. Ve své podstatˇe podporuje rodina protokol˚ u TCP/IP velké portfolio linkov´ ych protokol˚ u, ale v pr˚ ubˇehu ˇcasu se Ethernet stal nejpouˇz´ıvanˇejˇs´ım a nejrozˇs´ıˇrenˇejˇs´ım. V´ıce informac´ı o modulu pˇrinesou dvˇe bezprostˇrednˇe následuj´ıc´ı tabulky. Atribut Typ eth smac MAC48 eth tmac MAC48 INT eth type

Ud´ alost packet drop

4.4.3

Popis atributu zdrojová MAC adresa ve formátu MAC-48 c´ılová MAC adresa ve formátu MAC-48 typ protokolu vyˇsˇs´ı vrstvy 0x0800 pro IPv4, 0x86DD pro IPv6, 0x0806 pro ARP

Popis ud´ alosti Typ objektu vznik nového paketu Ethernet packet zahozen´ı nekompatibiln´ıho paketu PCAP packet (napˇr. z d˚ uvodu nekompletnosti paketu pˇri odchycen´ı)

Modul ARP

Modul dekóduje hlaviˇcky paket˚ u protokolu ARP (Address resolution protocol – RFC 826[11]) a protokolu RARP (Reverse address resolution protocol – RFC 903[12]) a odes´ılá je spˇra´telenému modulu pro jejich vizualizaci. Tabulka specifikuje atributy objektu, modul nedisponuje ˇza´dn´ ymi událostmi, vˇsechna data jsou automaticky posunuta následuj´ıc´ımu modulu ARP view. Atribut arp htype arp ptype

Typ INT INT INT

arp opcode ARRAY MAC48 IPV4 arp sendpaddr IPV6 ARRAY arp targhaddr MAC48 IPV4 arp targpaddr IPV6 arp sendhaddr

Popis atributu typ hardwarové adresy (0x0001 pro Ethernet II) typ s´ıt’ového protokolu 0x0800 pro IPv4, 0x86DD pro IPv6 typ poˇzadavku 0x0001 pro ARP dotaz, 0x0002 pro ARP odpovˇed’ 0x0003 pro RARP dotaz, 0x0004 pro RARP odpovˇed’ fyzická adresa odes´ılatele (typ na základˇe délky, pro délku 6 typ MAC48, ARRAY jinak) s´ıt’ová adresa odes´ılatele (typ na základˇe atributu arp ptype) fyzická adresa pˇr´ıjemce (typ na základˇe délky, pro délku 6 typ MAC48, ARRAY jinak) s´ıt’ová adresa pˇr´ıjemce (typ na základˇe atributu arp ptype)

23

4.4.4

Modul ARP view

´ Ukolem modulu ARP view nen´ı nic jiného neˇz prezentovat odchycené datové objekty typu ARP packet. Modul má zabudované rozˇs´ıˇren´ı pro prezentován´ı v´ yrobce s´ıt’ové karty, ke které se váˇze odchycená MAC adresa, a to v podobˇe tzv. OUI-48 (Organizationally unique identifier). Seznam v´ yrobc˚ u je uveden na stránkách IEEE[4] a souˇcást´ı bakaláˇrské práce je i program pro staˇzen´ı a transformaci dat pod jménem: oui.py, kter´ y stahuje z webov´ ych stránek organizace IEEE aktuáln´ı databázi pˇridˇelen´ ych rozsah˚ u MAC adres jednotliv´ ych v´ yrobc˚ u a ukládá je do souboru pro modul. V´ ypis z modulu je pˇriloˇzen v ukázkách programu.

4.4.5

Modul IPv4

Ze jména modulu vypl´ yvá jeho funkce, modul pouze dekóduje datové objekty typu IPv4 packet a veˇskerá data jsou odes´ılána modulu IP reassembler, kter´ y rozhodne o tom, zda je nutné zakládat IP reassembly nebo zda jsou data nefragmentovaná a staˇc´ı je odeslat vyˇsˇs´ı vrstvˇe. Odes´ılán´ı datov´ ych objekt˚ u pro jejich kontrolu je ˇcinˇeno automaticky, nen´ı nutné registrovat událost. Specifikace paketu byla poprvé pˇredstavena v RFC 791[13]. Následuj´ıc´ı dvˇe tabulky pˇrináˇsej´ı v´ıce informac´ı o vznikl´ ych objektech a o událostech. Atribut ipv4 version ipv4 hdrlen ipv4 tos ipv4 length ipv4 ident ipv4 flags ipv4 ttl ipv4 proto

Typ INT INT INT INT INT INT INT INT

ipv4 hdrsum INT ipv4 saddr IPV4 ipv4 daddr IPV4 Ud´ alost drop

4.4.6

Popis atributu verze s´ıt’ového protokolu délka hlaviˇcky paketu v bajtech typ pˇrenáˇsené sluˇzby v datech celková délka paketu v bajtech identifikace pro u ´ˇcely fragmentace flagy spolu s fragmentaˇcn´ım offsetem TTL – ˇzivotnost paketu typ protokolu vyˇsˇs´ı vrstvy 0x0006 pro TCP, 0x0011 pro UDP kontroln´ı souˇcet IP paketu zdrojová s´ıt’ová adresa c´ılová s´ıt’ová adresa

Popis ud´ alosti Typ objektu zahozen´ı nekompatibiln´ıho paketu Ethernet packet

Modul IPv6

Nová verze s´ıt’ového protokolu se od svého sourozence co do formátu hlaviˇcky znaˇcnˇe odliˇsuje, vznikla u ´plnˇe nová koncepce pˇr´ıdavn´ ych hlaviˇcek ve formˇe spojového seznamu, kter´ y rozˇsiˇruje hlaviˇcku základn´ı, jeˇz v sobˇe nese pouze nutné informace. Hlaviˇcek najdeme ve specifikaci celkem mnoho a jsou podporované 4 základn´ı: Hop-by-Hop, c´ılová, fragmentaˇcn´ı a trasovac´ı. K ostatn´ım hlaviˇckám m˚ uˇzeme pˇristupovat pomoc´ı atribut˚ u, které jsou specifikované na konci následuj´ıc´ı tabulky, po n´ıˇz následuje pˇrehled událost´ı. Specifikace paketu a protokolu nalezneme v RFC 2460[14], podobnˇe jako v pˇr´ıpadˇe pˇredchoz´ıho modulu se modul stará o dekódován´ı a data jsou postoupena automaticky modulu IP reassembler. 24

Atribut ipv6 version ipv6 tos ipv6 flabel ipv6 length

Typ INT INT INT INT INT

ipv6 nexthdr ipv6 ipv6 ipv6 ipv6 ipv6 ipv6 ipv6 ipv6 ipv6 ipv6 ipv6 ipv6 ipv6

ttl saddr daddr hophop options dest options route type route segleft route options fragm offset fragm flag fragm ident headers[t] headers type[i] Ud´ alost drop

4.4.7

INT IPV6 IPV6 ARRAY ARRAY INT INT ARRAY INT INT INT ARRAY INT

Popis atributu verze s´ıt’ového protokolu (6 pro IPv6) typ pˇrenáˇsené sluˇzby v datech identifikátor proudu dat (Flow label) celková délka paketu v bajtech identifikátor dalˇs´ı hlaviˇcky (po pˇreˇcten´ı vˇsech pˇr´ıdavn´ ych) 44 pro fragmentaci, 17 pro UDP, 6 pro TCP (RFC[14]) TTL – ˇzivotnost paketu zdrojová s´ıt’ová adresa c´ılová s´ıt’ová adresa volby rozˇs´ıˇren´ı Hop-by-Hop volby pro c´ılové rozˇs´ıˇren´ı typ trasován´ı rozˇsiˇruj´ıc´ı hlaviˇcky zb´ yvaj´ıc´ı poˇcet segment˚ u trasován´ı volby trasovac´ı rozˇsiˇruj´ıc´ı hlaviˇcky offset fragmentovaného paketu flag fragmentaˇcn´ı rozˇs. hlaviˇcky identifikace v rámci fragmentace rozˇsiˇruj´ıc´ı hlaviˇcky typu t typ i-té rozˇsiˇruj´ıc´ı hlaviˇcky

Popis ud´ alosti Typ objektu zahozen´ı nekompatibiln´ıho paketu Ethernet packet

Modul IP reassembler

´ Ukolem modulu je naˇc´ıtat vstupn´ı pakety IPv4 packet a IPv6 packet a na základˇe atribut˚ u se rozhodovat, zda budou pakety fragmentované ˇci nikoliv. V pˇr´ıpadˇe nefragmentovan´ ych dat okamˇzitˇe nastane událost, signalizuj´ıc´ı vznik nového paketu. V opaˇcném pˇr´ıpadˇe dojde k zaloˇzen´ı objektu typu IP reassembly, kter´ y pˇredstavuje datagram, kter´ y vzniká skládán´ım fragment˚ u (obou verz´ı s´ıt’. protokolu). Pokud uˇzivatele zaj´ımaj´ı pouze kompletn´ı IP pakety, nen´ı nutné s IP reassembly pracovat. Na druhé stranˇe pokud chceme programovat modul, kter´ y se jak´ ymkoliv zp˚ usobem dot´ yká IP fragmentace, máme moˇznost se k jednotliv´ ym procházej´ıc´ım fragment˚ um dostat. Skladba fragment˚ u prob´ıhá spojován´ım fragment˚ u do seznamu, kter´ y kdyˇz se stane kompletn´ım, tak dojde k události vzniku nového datového objektu. Jako obrana pˇred velk´ ym poˇctem otevˇren´ ych IP datagram˚ u slouˇz´ı ˇcasov´ y limit, kter´ y aktivuje událost conn timeout, pokud do IP datagramu nepˇribyl po urˇcitou dobu ˇzádn´ y paket. Atribut ipreass time ipreass ipreass ipreass ipreass

Typ Popis atributu TIME ˇcas zaloˇzen´ı IP reassembly IPV4 zdrojová s´ıt’ová adresa saddr IPV6 IPV4 c´ılová s´ıt’ová adresa daddr IPV6 ident INT identifikace IP reassembly version INT rozliˇsen´ı mezi verzemi 4 a 6 25

Ud´ alost

Popis ud´ alosti vznik nefragmentovaného IP paketu

packet

zahozen´ı nekompatibiln´ıho paketu

drop

conn create zaloˇzen´ı nového IP datagramu conn close korektn´ı uzavˇren´ı IP datagramu conn timeout vyprˇsen´ı ˇcasového limitu pro IP reassembly

4.4.8

Typ objektu IPv4 packet IPv6 packet IPv4 packet IPv6 packet IP reassembly IP reassembly IP reassembly

Modul UDP

Modul UDP tvoˇr´ı jenom jakousi malou nadstavbu nad s´ıt’ov´ ym protokolem, proto nen´ı nutné dlouze vysvˇetlovat fungován´ı a nahlédneme rovnou na popis atribut˚ u modulu a událost´ı, jeˇz mohou nastat. V´ıce informac´ı m˚ uˇzete ˇcerpat v RFC 768[15]. Atribut udp sport udp dport udp length udp checksum Ud´ alost packet drop

4.4.9

Typ INT INT INT INT

Popis atributu zdrojov´ y port c´ılov´ y port délka nesen´ ych dat kontroln´ı souˇcet hlaviˇcky

Popis ud´ alosti Typ objektu vznik nového paketu UDP packet zahozen´ı nekompatibiln´ıho paketu IPv4 packet IPv6 packet

Modul TCP

Modul má za u ´kol dekódovat hlaviˇcky datov´ ych objekt˚ u typu IPv4 packet a IPv6 packet, vˇsechny atributy vzniklého datového objektu spolu s událostmi naleznete ve dvou tabulkách. Dalˇs´ı informace lze ˇcerpat z RFC 793[16]. Atribut tcp sport tcp dport tcp seq tcp ack tcp hdrlen tcp flags tcp winsize tcp checksum tcp urgptr tcp options

Typ INT INT INT INT INT INT INT INT INT ARRAY

Popis atributu zdrojov´ y port c´ılov´ y port poˇradové ˇc´ıslo v bajtovém proudu potvrzovac´ı ˇc´ıslo délka hlaviˇcky v bajtech flagy pro jednotlivé volby velikost okna kontroln´ı souˇcet hlaviˇcky urgentn´ı ukazatel dalˇs´ı volby

26

Ud´ alost packet drop

4.4.10

Popis ud´ alosti Typ objektu vznik nového paketu TCP packet zahozen´ı nekompatibiln´ıho paketu IPv4 packet IPv6 packet

Modul TCP flow

Nejsloˇzitˇejˇs´ı modul, implementovan´ y v program, je bezpochyby modul pro rekonstrukci spojen´ı, pracuj´ıc´ı s obˇema verzemi s´ıt’ového protokolu. Na vstupu je TCP packet a pˇri korektn´ım navázán´ı spojen´ı vzniká datov´ y objekt typu TCP flow. Objekt v sobˇe uchovává informace o zdrojovém a c´ılovém portu a také o adresách, mezi kter´ ym se pˇrenos uskuteˇcn ˇuje. Zm´ınˇen´ y objekt disponuje zásobn´ıkem událost´ı, ve kterém nastává událost, signalizuj´ıc´ı pˇrenáˇsená data po spojen´ı typu TCP data. Stejnˇe jako v pˇr´ıpadˇe modulu IP reassembler je ˇcinnost spojen´ı monitorována a neˇcinná spojen´ı jsou po uplynut´ı ˇcasového limitu uzav´ırána. Pˇrehled obou typ˚ u datov´ ych objekt˚ u následuje na pˇriloˇzen´ ych tabulkách. Atribut

Typ IPV4 tcpflow saddr IPV6 IPV4 tcpflow daddr IPV6 tcpflow sport INT tcpflow dport INT

4.4.11

Popis atributu zdrojová adresa c´ılová adresa zdrojov´ y port c´ılov´ y port

Atribut tcpdata time tcpdata direct tcpdata data tcpdata conn

Typ Popis atributu TIME ˇcas vzniku pˇrenesen´ ych dat INT smˇer pˇrenesen´ ych dat po spojen´ı ARRAY data pˇrenesená po spojen´ı DOBJ ukazatel na datov´ y objekt se spojen´ım

Ud´ alost conn create conn reset conn close conn timeout data

Popis ud´ alosti vznik nového spojen´ı resetován´ı spojen´ı korektn´ı uzavˇren´ı spojen´ı vyprˇsen´ı ˇcasového limitu spojen´ı vznik dat po spojen´ı

Typ objektu TCP flow TCP flow TCP flow TCP flow TCP data

Modul HTTP

Protokol HTTP (Hypertext transfer protocol) se v dneˇsn´ı dobˇe tˇeˇs´ı obrovské oblibˇe, spousta doposavad desktopov´ ych aplikac´ı se zabydlela ve formˇe webov´ ych stránek (kanceláˇrsk´ y bal´ık, webmail, atd.), vznikly masivnˇe se rozv´ıjej´ıc´ı sociáln´ı s´ıtˇe a pˇrib´ yvá na dynamiˇcnosti webov´ ych stránek. Modul HTTP rekonstruuje transfery, zaznamenává dokumenty, které si uˇzivatel vybere a dopoˇc´ıtává délku vyˇr´ızen´ı poˇzadavk˚ u. S pˇr´ıkladem v´ ystupu modulu se m˚ uˇzeme seznámit 27

v dalˇs´ı ˇca´sti práce a jedna sekce kapitoly je vˇenovaná popisu, jak se takov´ y modul mus´ı správnˇe napojit, aby poskytoval vytouˇzené v´ ysledky. Specifikace protokolu je definována v RFC 2616[17].

4.4.12

Modul DNS

Modul DNS opˇet prezentuje nashromáˇzdˇené informace, do práce byl modul zahrnut hlavnˇe z hlediska demonstrace univerzálnosti návrhu programu, kdy modul pracuje s v´ıce typy vstupn´ıch datov´ ych objekt˚ u, v pˇr´ıpadˇe DNS se jedná o UDP datagram a TCP flow. Modul se vypoˇra´dá s hlavn´ı mnoˇzinou typ˚ u poˇzadavk˚ u a odpovˇed´ı: CNAME (kanonické jméno), NS (name server), A (IPv4 adresa), AAAA (IPv6 adresa), SOA (záznam autority), TXT (textov´ y ˇretˇezec), RRSIG (elektronick´ y podpis). Podobnˇe jako v pˇr´ıpadˇe v´ ystupu modulu HTTP i tento modul dopoˇc´ıtává dobu, za jakou doˇslo v vyˇr´ızen´ı poˇzadavku. Ukázku práce modulu naleznete v dalˇs´ıch kapitolách.

28

Ovl´ ad´ an´ı programu NEPAL 5.1

Pˇ reklad programu

Program je napsan´ y v jazyc´ıch C a Python a je urˇcen´ y primárnˇe pro operaˇcn´ı systém Unix, pro kter´ y je vytvoˇren´ y Makefile. Program spolupracuje s knihovnou LibUCW[5] (aktuáln´ı verze 4.0) a s programem SWIG[7] (aktuáln´ı verze 1.3.40-r1). V jazyce Python nejsou uˇz´ıvány ˇzádné sloˇzité konstrukce a otestována je funkˇcnost ve verzi 2.6 a vyˇsˇs´ı. Jako nutná prerekvizita pro pˇreklad programu pomoc´ı GCC[10] je um´ıstˇen´ı knihovny LibUCW, které se detekuje pomoc´ı známého programu pkg-config (v souboru Makefile naleznete cestu ke knihovnˇe, kterou je nutné pro pˇreklad správnˇe vyplnit). Po pˇrekladu vznikne dynamická knihovna, kterou lze jiˇz importovat z prostˇred´ı jazyka Python, jenˇz spouˇst´ı pˇripravené ukázkové skripty.

5.2

Uk´ azka programu

#!/usr/bin/env python2.6 from nepal import * import sys

def entrypoint(file): eho paketu bind module("PCAP", "ETH", "packet") # registrace module Ethernet na vznik nov´ an´ ı paket˚ u bind func("ETH", meth dispatcher, "packet") # registrace funkce pro filtrov´ bind module("ARP", "ARPVIEW", "packet") # registrace vizualizaˇ cn´ ıho modulu pro ARP setinfo("module.arpview ouifile", "STRING", "../utils/oui.txt") # nastaven´ ı OUI souboru mpcap(file)

def meth dispatcher(obj): if obj.eth type == 0x0806: # ARP obj.send("ARP")

# Main if len(sys.argv) != 2: print "usage: ./scriptname " else: entrypoint(sys.argv[1])

Po pˇredstaven´ı modul˚ u, datov´ ych objekt˚ u a událost´ı nastal koneˇcnˇe ˇcas na pˇredstaven´ı jednoduchého zapojen´ı naˇseho analyzátoru. Jako prvn´ı najdete registrován´ı funkc´ı do zásobn´ık˚ u událost´ı pro moduly, které budou ˇr´ıdit cel´ y bˇeh programu. Jak si m˚ uˇzete vˇsimnout, docház´ı i k registrován´ı naˇs´ı metody, psané v Pythonu, která nastane pokud vznikne Ethernet packet. Po vzniku paketu dojde k rozhodnut´ı, zda se jedná o ARP paket a pouˇzije se metoda pro odeslán´ı datového objektu do dalˇs´ıho modulu. V demonstraˇcn´ım skriptu jsou pˇredstaveny vˇsechny potˇrebné 29

metody pro naprogramován´ı zapojen´ı a v následuj´ıc´ı kapitole bude specifikováno veˇskeré programátorské rozhran´ı.

5.3

Ovl´ ad´ an´ı a program´ atorsk´ e rozhran´ı

Jak bylo moˇzno vidˇet z pˇredchoz´ı ukázky, skripty jsou ˇr´ızeny mnoˇzinou funkc´ı, které pracuj´ı ˇ aˇri jistˇe neuniklo, ˇze jádro programu je napsané s datov´ ymi objekty a zásobn´ıky událost´ı. Cten´ v jazyce C a pro jeho zpˇr´ıstupnˇen´ı je k dispozici mnoˇzina metod, pˇredstaven´ ych v tabulce. Metoda bind func(module, func, event)

bind module(module, dest module, event)

set info(attr name, attr type, value)

obj.attr name obj.attr name = value obj.set int(attr name, value) obj.set time(attr name, value) obj.set ipv4(attr name, value) obj.set ipv6(attr name, value) obj.set string(attr name, value) obj.set array(attr name, value) obj.set mac48(attr name, value) obj.set voidptr(attr name, value) obj.bind func(func, event) obj.bind module(module, event) obj.incref() obj.decref() mpcap(file) obj.send(module)

Popis metody registrován´ı události, vzniklé z modulu, prvn´ım argumentem je zkratka modulu (viz. tabulka 4.1), následuje ukazatel na funkci, jeˇz má b´ yt zavolána a posledn´ım argumentem je jméno události, na kterou se má funkce zavˇesit registrován´ı události, vzniklé z modulu, prvn´ım argumentem je zkratka modulu (viz. 4.1), následuje zkratka c´ılového modulu (dest module), jenˇz má b´ yt zavolán a posledn´ım argumentem je jméno události, na kterou se má funkce zavˇesit nastaven´ı informac´ı modul˚ u, jejich specifikace je v následuj´ıc´ı tabulce, prvn´ım argumentem je jméno atributu, druh´ ym je typ atributu dle definice v kapitole 4.3 a posledn´ı je hodnota, která odpov´ıdá attr type a bude pˇredstavena z´ıskán´ı atributu jménem attr name z objektu modifikace atributu attr name hodnotou value metoda pro vloˇzen´ı nové hodnoty typu INT metoda pro vloˇzen´ı nové hodnoty ˇcasu metoda pro vloˇzen´ı nové IPv4 adresy metoda pro vloˇzen´ı nové IPv6 adresy metoda pro vloˇzen´ı nového ˇretˇezce metoda pro vloˇzen´ı nového pole metoda pro vloˇzen´ı nové hodnoty MAC adresy metoda pro vloˇzen´ı nového obecného ukazatele registrován´ı funkce func, pokud nastane na datovém objektu událost event registrace modulu, jenˇz se pouˇzije pro událost event pˇridán´ı reference na datov´ y objekt odebrán´ı reference na datov´ y objekt zavolán´ı hlavn´ıho modulu s jménem vstupn´ıho souboru jako argumentem odeslán´ı datového objektu na zpracován´ı modulem jménem module (napˇr. TCP nebo ARP) 30

Pro spojen´ı svˇet˚ u obou programovac´ıch jazyk˚ u je d˚ uleˇzité specifikovat korespondenci jednotliv´ ych typ˚ u atribut˚ u. Jejich vztah naleznete v následuj´ıc´ı tabulce. U pˇriˇrazen´ı a metody setnew ukládáme do datového objektu hodnotu ve formˇe Python objektu, kter´ y mus´ı odpov´ıdat typem atributu, kter´ y je v tabulce v prvn´ım sloupci. Typ atributu INT TIME IPV4 IPV6 STRING ARRAY MAC48 VOIDPTR

Odpov´ıdaj´ıc´ı typ v Pythonu Python Long dvouprvkové pole ve formátu [sekundy, milisekundy] (oboj´ı typu Long) Python String ve standardn´ım formátu a.b.c.d (RFC 791[13]) Python String ve standardn´ım formátu dle RFC 2460[14] Python String Python ByteArray (novinka ve verzi Pythonu 2.6) Python String ve formátu aa:bb:cc:dd:ee:ff Python Long, umoˇzn ˇuje zapouzdˇrit void ukazatel

Pro ilustraci pˇridávám pár ukázek uˇzit´ı pˇriˇrazen´ı hodnot a jejich z´ıskáván´ı: ısk´ an´ ı poˇ radov´ eho c ˇ´ ısla paketu typu Python Long obj.pcap frame ... z´ obj.smac = "00:0e:2e:aa:aa:aa"... nastaven´ ı nov´ e zdrojov´ e MAC adresy objektu zen´ ı nov´ eho atributu obj.set string("pcap popis", "DUPL") ... uloˇ obj.pcap popis = 123 ... chyba, s ˇpatn´ y typ objektu uspˇ eˇ sn´ e pˇ reps´ an´ ı atributu objektu obj.set int("pcap popis", 12345 ... ´ data = obj.pcap packet ... z´ ısk´ an´ ı dat paketu typu Python ByteArray Pro u ´plnost specifikace rozhran´ı je nutné jeˇstˇe dodat seznam atribut˚ u modul˚ u, které lze nastavovat pomoc´ı jiˇz pˇredstavené metody set info. Pˇriloˇzená tabulka ukazuje vˇsechny moˇzné volby pro moduly. Atribut module pcap n module eth valid module eth invalid module arp invalid module arpview ouifile module arpview valid module ipv4 valid module ipv4 invalid module ipv4 checksum module ipv6 valid module ipv6 invalid module iptcp timeout module udp checksum module tcp valid module tcp invalid

Popis atributu Poˇcet paket˚ u proˇsl´ ych modulem PCAP Poˇcet správnˇe zpracovan´ ych paket˚ u modulem Ethernet Poˇcet zahozen´ ych paket˚ u modulem Ethernet Poˇcet zahozen´ ych paket˚ u modulem ARP Cesta k souboru s OUI jmény v´ yrobc˚ u Poˇcet správnˇe zpracovan´ ych paket˚ u modulem ARP view Poˇcet správnˇe zpracovan´ ych paket˚ u modulem IPv4 Poˇcet zahozen´ ych paket˚ u modulem IPv4 Zapnut´ı kontroln´ıho souˇctu u IPv4 packet Poˇcet správnˇe zpracovan´ ych paket˚ u modulem IPv6 Poˇcet zahozen´ ych paket˚ u modulem IPv6 ˇ Casov´ y limit pro vyprˇsen´ı IP datagramu a TCP spojen´ı Zapnut´ı kontroln´ıho souˇctu u UDP packet Poˇcet správnˇe zpracovan´ ych paket˚ u modulem TCP Poˇcet zahozen´ ych paket˚ u modulem TCP

31

module tcp dupl Poˇcet duplicitn´ıch paket˚ u proˇsl´ ych modulem TCP module tcp checksum Zapnut´ı (1) ˇci vypnut´ı (0) kont. souˇctu paket˚ u v modulu TCP module tcpflow treshold Poˇcet paket˚ u v zásobn´ıku spojen´ı, pˇri kterém ruˇseno spojen´ı

5.4

Spouˇ stˇ en´ı programu

Ukázková zapojen´ı jsou pˇredstavena ve ˇctyˇrech pˇripraven´ ych skriptech, kaˇzd´ y se nacház´ı v samostatném souboru. Pro spuˇstˇen´ı programu staˇc´ı spustit soubor s jedin´ ym argumentem, kter´ ym je jméno vstupn´ıho souboru. Pˇr´ıklad spuˇstˇen´ı programu: ./script http.py ../../nepal-data/www pages.pcap Dojde ke spuˇstˇen´ı skriptu script http.py, kter´ y rekonstruuje HTTP spojen´ı. Pˇrehled vˇsech pˇriloˇzen´ ych skript˚ u je znázornˇen v následuj´ıc´ı tabulce. Jm´ eno souboru script http.py script graph.py script arp.py script dns.py

Popis skriptu HTTP modul, rekonstuuje a vizualizuje HTTP spojen´ı Grafov´ y modul, vytváˇr´ı grafy základn´ıch informac´ı ARP/RARP modul, zobrazuje (R)ARP poˇzadavky a odpovˇedi DNS modul, naˇc´ıtá a zobrazuje DNS dotazy a odpovˇedi

32

Uk´ azky z programu NEPAL 6.1 6.1.1

Modul pro HTTP Prvn´ı pˇ r´ıklad

Jako u ´vodn´ı ukázku v˚ ubec jsem si vybral odchycená data, která jsou pouˇzita pro zobrazen´ı tˇrech webov´ ych stránek, v prvn´ım sloupci v´ ystupu m˚ uˇzete nalézt pravdˇepodobnˇe nejzaj´ımavˇejˇs´ı atribut, jedná se o dobu (v sekundách), za jakou byl poˇzadavek na webovou stránku vyˇr´ızen. Následuje návratov´ y kód webového serveru, ve vˇetˇsinˇe pˇr´ıpad˚ u je navrácen kód 200, jenˇz znaˇc´ı u ´spˇeˇsn´ y poˇzadavek. Kódem 304 oznaˇcujeme stav, kdy jiˇz stránka byla v minulosti pˇrenesena a na serveru se dokument nezmˇenil, v tomto pˇr´ıpadˇe nen´ı nutná data znovu pˇrenáˇset, a proto je i celkové délka pˇreneseného tˇela nastavena na nulovou hodnotu. Za zm´ınku stoj´ı jeˇstˇe návratov´ y kód 301, kter´ y nesignalizuje nic jiného neˇz fakt, ˇze stránka byla trvale pˇrem´ıstˇena. Po atributu kódu následuj´ı zdrojová a c´ılová adresa a také zdrojov´ y a c´ılov´ y port. Do posledn´ı trojice atribut˚ u spadaj´ı: URL dorazu, typ obsahu (content-type) a celková velikost pˇrenáˇsen´ ych informac´ı v tˇele protokolu. RTT1

code saddr:sport

daddr:dport

URL, content-type, length

0.066457

200

192.168.2.104:48439

77.75.72.10:80

http://mapy.cz/ text/html, 6846 B

0.039601

304

192.168.2.104:58049

77.75.72.22:80

http://style.seznam.cz/... application/x-javascript, 0 B

0.047120

200

192.168.2.104:51744

77.75.73.27:80

http://api.mapy.cz/... application/x-javascript 1271 B

0.015909

200

192.168.2.104:48439

77.75.72.10:80

http://mapy.cz/firmpoi/... text/xml, 467 B

0.027949

200

192.168.2.104:48442

77.75.72.10:80

http://mapy.cz/basepoi/... text/xml, 701 B

0.035656

200

192.168.2.104:48443

77.75.72.10:80

http://mapy.cz/fotopoi/... text/xml, 2579 B

0.058675

200

192.168.2.104:48444

77.75.72.10:80

http://mapy.cz/trafficpoi/... text/xml, 6451 B

0.061435

200

192.168.2.104:48439

77.75.72.10:80

http://mapy.cz/weatherpoi/... text/xml, 6322 B

0.018402

200

192.168.2.104:37050

77.75.73.15:80

http://mapi.mapy.cz/... image/png, 304 B

0.128821

200

192.168.2.104:55866

195.113.27.37:80

http://www.mff.cuni.cz/ text/html, 6408 B

0.099579

200

192.168.2.104:55866

195.113.27.37:80

http://www.mff.cuni.cz/.../default.css text/css, 24969 B

0.056736

200

192.168.2.104:55869

195.113.27.37:80

http://www.mff.cuni.cz/.../slideshow.css text/css, 1086 B

0.036781

200

192.168.2.104:55867

195.113.27.37:80

http://www.mff.cuni.cz... application/x-javascript, 7516 B

0.018826

301

192.168.2.104:38338

212.24.146.202:80 http://prace.cz/ text/html, 228 B

0.022571

304

192.168.2.104:38339

212.24.146.202:80 http://www.prace.cz/css/print.css, 0 B

6.1.2

Druh´ y pˇ r´ıklad

Druh´ y pˇr´ıklad zapojen´ı modulu se t´ yká opˇet zobrazován´ı webov´ ych stránek, protentokrát jsem nasimuloval velmi pomalou linku na u ´rovni modemu (28kb/s). Stránka obsahuje náhledy obrázk˚ u a stejná odchycená data jsou uˇzita i v ukázce modulu následuj´ıc´ıho. U stránek, které jsou stále platné a uloˇzené v cache, je doba odezvy menˇs´ı nˇeˇz jedna sekunda, coˇz ovˇsem nem˚ uˇzeme tvrdit o pˇrenáˇsen´ ych obrázc´ıch, jejichˇz pr˚ umˇerná doba pˇrenesen´ı tvoˇr´ı dnes nepˇredstaviteln´ ych 1

Round-trip time – doba mezi odesl´ an´ım zprávy a jej´ım potvrzen´ım

33

30 sekund. I pˇres velikost v ˇra´du des´ıtek kilobajt˚ u je pˇrenos neskuteˇcnˇe pomal´ y a m˚ uˇzeme s povdˇekem kvitovat, ˇze se jedná o odezvy z dob dávno minul´ ych. RTT

code saddr:sport

daddr:dport


0.119196

200

192.168.2.104:34433

74.125.87.138:80

http://clients1.google.cz/... text/javascript, 94 B

0.086568

200

192.168.2.104:34433

74.125.87.138:80


0.067575

200

192.168.2.104:34434

74.125.87.138:80


0.023053

304

192.168.2.104:60469

82.208.6.4:80

http://www.bagr.cz/.../16.jpg , 0 B

0.023479

304

192.168.2.104:60468

82.208.6.4:80


0.128240

304

192.168.2.104:60472

82.208.6.4:80


0.267189

304

192.168.2.104:60473

82.208.6.4:80


0.896860

304

192.168.2.104:60479

82.208.6.4:80


0.974960

200

192.168.2.104:59078

195.122.208.167:80 http://www.devnull.cz/docs/index.html text/html, 4453 B

0.336974

301

192.168.2.104:59078

195.122.208.167:80 http://www.devnull.cz/greece text/html, 304 B

1.034904

200

192.168.2.104:59079

195.122.208.167:80 http://www.devnull.cz/greece/ text/html, 2848 B

6.748143

301

192.168.2.104:59085

195.122.208.167:80 http://www.devnull.cz/barcelona text/html, 307 B

4.804956

200

192.168.2.104:59088

195.122.208.167:80 http://www.devnull.cz/barcelona/ text/html, 12438 B

42.917346 200

192.168.2.104:59092

195.122.208.167:80 http://www.devnull.cz/.../P1000492.gif image/gif, 20966 B

44.352634 200

192.168.2.104:59091


0.955253

204

192.168.2.104:46455

77.75.77.156:80

62.694313 200

192.168.2.104:59093


23.477284 200

192.168.2.104:59095


72.921036 200

192.168.2.104:59094


6.1.3

http://d.seznam.cz/hit/... text/html, 0 B

Tˇ ret´ı pˇ r´ıklad

Pro posledn´ı pˇr´ıklad v podkapitole jsem zvolil modul, kter´ y ukazuje vyuˇzit´ı protokolu s´ıt’ové vrstvy ve verzi 6 a záznam komunikace vznikl po lokáln´ı s´ıti. Adresy jsou dlouhé co do v´ ypisu, proto jsem zvolil jejich menˇs´ı zkrácen´ı pro u ´ˇcely prezentován´ı do bakaláˇrské práce. RTT

code saddr:sport

daddr:dport


0.018620

200

fd0:...:6193:36603

fd0:...:e39:80

http://[fd0:...:e39]/Sport.cz.html text/html, 42833 B

0.017950

200

fd0:...:6193:36606

fd0:...:e39:80

http://[fd0:...:e39]/.../userwebprint.css text/css, 716 B

0.018716

200

fd0:...:6193:36608

fd0:...:e39:80

http://[fd0:...:fe30:e39]/.../javascript text/plain, 1339 B

0.045221

200

fd0:...:6193:36603

fd0:...:e39:80

http://[fd0:...:fe30:e39]/.../sportall.js ..., 80087 B

0.024495

200

fd0:...:6193:36604

fd0:...:e39:80

http://[fd0:...:fe30:e39]/.../winplayer.js ..., 5401 B

0.028471

200

fd0:...:6193:36607

fd0:...:e39:80

http://[fd0:...:fe30:e39]/.../sectionhp.css text/css, 4722 B

0.012110

200

fd0:...:6193:36603

fd0:...:e39:80

http://[fd0:...:fe30:e39]/.../gemius.js ..., 6234 B

0.039178

200

fd0:...:6193:36605

fd0:...:e39:80

http://[fd0:...:fe30:e39]/.../userweb.css text/css, 16106 B

0.012024

200

fd0:...:6193:36607

fd0:...:e39:80

http://[fd0:...:fe30:e39]/.../impress text/plain, 43 B

0.022939

200

fd0:...:6193:36608

fd0:...:e39:80

http://[fd0:...:fe30:e39]/.../javascript text/plain, 7891 B

34

6.2

Grafov´ y modul

Grafov´ y modul nám dává základn´ı charakteristiku dat, která jsou v souboru odchyceném ze s´ıtˇe. Modul disponuje histogramem velikosti rámce, pˇrenáˇseného po s´ıt’ové infrastruktuˇre, dále máme k dispozici koláˇcov´ y graf, kter´ y udává pomˇer uˇzit´ ych transportn´ıch protokol˚ u, a to jak co do poˇctu rámc˚ u, tak i co do celkové velikosti dat t´ımto zp˚ usobem pˇrenesen´ ych. Jako posledn´ı pár grafov´ ych v´ ystup˚ u nab´ız´ı modul graf tok˚ u, tedy kolik paket˚ u bylo pˇreneseno za jednotku ˇcasu, resp. kolik bajt˚ u bylo pˇreneseno. Následuj´ıc´ı obrázky demonstruj´ı pouˇzit´ı modulu s popisem dat, která byla vloˇzena na vstupu.

Pˇr´ıklad 1: Flow graf velikosti pˇrenáˇsen´ ych dat

Pˇr´ıklad 1: Flow graf poˇctu pˇrenáˇsen´ ych dat

6.2.1

Prvn´ı pˇ r´ıklad

Jako prvn´ı sadu vstupn´ıch dat jsem si pˇripravil data, které jsou odchycené pˇri navˇst´ıven´ı stránek www.devnull.cz, navˇst´ıvil jsem stránku s ukázkov´ ymi fotografiemi a nav´ıc jsem nasimuloval omezen´ı rychlosti podobné modemu (28kbit/s) pomoc´ı Simple Queue u operaˇcn´ıho systému MikroTik RouterOS[18]. Prvn´ı dvojice graf˚ u ukazuje pr˚ utok dat v ˇcase, na prvn´ım obrázku je krásnˇe vidˇet pr˚ umˇerná rychlost 3.5 kB/s, na kterou byla linka degradována a druh´ y obrázek fakticky koresponduje s prvn´ım, poˇc´ıtá vˇsak jenom poˇcet paket˚ u, které se v praxi velmi diametrálnˇe liˇs´ı co do velikosti, poˇc´ınaje potvrzovac´ım paketem spojen´ı TCP a konˇce pˇrenáˇsen´ ymi 35

Pˇr´ıklad 1: Histogram velikosti pˇrenáˇsen´ ych rámc˚ u

(a)

(b)

Pˇr´ıklad 1: Pod´ıl uˇzit´ ych transportn´ıch protokol˚ u daty v takovém spojen´ı. Následuje klasick´ y histogram velikosti rámc˚ u, jenˇz dokazuje zmiˇ nované rozloˇzen´ı velikosti paket˚ u a najdete ho na tˇret´ım obrázku. Jako posledn´ı v sadˇe ukázek graf˚ u najdete koláˇcov´ y graf, kter´ y reflektuje percentuáln´ı vyuˇzit´ı transportn´ıch protokol˚ u, at’ uˇz co do poˇctu paket˚ u pˇrenesen´ ych nebo co do velikosti dat. Z anal´ yzy dat vypl´ yvá, ˇze se vˇetˇsina pˇrenosu odehrává po TCP, coˇz reálnˇe odpov´ıdá pˇrenosu webov´ ych stránek. Po protokolu UDP docház´ı k pˇrenosu hlavnˇe DNS dotaz˚ u a jejich odpovˇed´ı a nakonec po ICMP docház´ı k pˇrenosu zpráv hlavnˇe o nedostupném DNS serveru.

36

6.2.2

Druh´ y pˇ r´ıklad

Pro druh´ y pˇr´ıklad jsem si vybral DNS poˇzadavky na vˇsechny domény nejvyˇsˇs´ı u ´rovnˇe. Pro demonstraci jsem pouˇzil program dig, jenˇz dokáˇze formulovat poˇzadavek na doménu, vybral jsem volbu na dotaz na vˇsechny atributy domény. Zámˇernˇe jsem pouˇzil protokol UDP, kter´ y je ostatnˇe v´ ychoz´ım protokolem pro DNS poˇzadavky. Avˇsak v d˚ usledku poˇzadavku na vˇsechny atributy domény docház´ı k tomu, ˇze po UDP lze dle specifikace pˇrenáˇset pouze DNS odpovˇedi do velikosti 512B. Pokud je pˇrekroˇcena velikosti, je v odpovˇedi zapnut´ y pˇr´ıznak truncated“ a ” poˇzadavek je opakován po spojovaném kanále TCP.

Pˇr´ıklad 2: Histogram velikosti pˇrenáˇsen´ ych rámc˚ u Na grafu s histogramem názornˇe vid´ıme, ˇze se nám oproti prvn´ımu pˇr´ıkladu zmenˇsilo spektrum velikosti paket˚ u, velikost odpovˇed´ı pro UDP je limitována velikost´ı 512B. Pro poˇzadavky, které jsou vˇetˇs´ı docház´ı k navazován´ı TCP spojen´ı, avˇsak velikost DNS odpovˇed´ı nen´ı o mnoho vˇetˇs´ı, neˇz zmiˇ novan´ ych 512B. Na druhou stranu ale rozloˇzen´ı velikost´ı kop´ıruje minul´ y histogram, nejvˇetˇs´ı hustota je na poˇcátku a konci spektra. Jako druh´ y graf v pˇr´ıkladu nalezneme vyuˇzit´ı transportn´ıch protokol˚ u, kter´ y jasnˇe dává do souvislosti zastoupen´ı UDP a TCP protokol˚ u. Co do poˇctu paket˚ u, pˇrenesen´ ych po protokolu, má vˇetˇsinu protokol TCP, avˇsak jak v´ıme, protokol vytváˇr´ı spojen´ı, které spolyká jistou reˇzii a na druhém grafu je zastoupen´ı opaˇcné, coˇz odpov´ıdá realitˇe, kdy se vˇetˇsina odpovˇed´ı vrac´ı ve formˇe UDP datagramu.

6.3

Modul ARP/RARP

Modul ARP/RARP netˇreba dlouze pˇredstavovat, slouˇz´ı pro pˇrevod hardwarov´ ych adres a ’ s´ıt ov´ ych (resp. naopak). Do modulu je zakomponován pˇrevod MAC adres na v´ yrobce hardwaru a m˚ uˇzete se o fungován´ı pˇresvˇedˇcit na následuj´ıc´ıch dvou ukázkách. Vstup pro prvn´ı ukázku pocház´ı z bezdrátové s´ıtˇe, kde doˇslo na routeru k zakázán´ı s´ıt’ové karty a posléze k jej´ımu zapnut´ı. Klienti se proto znovu zaregistrovali a znovu je nutná registrace na u ´rovni MAC adres.

37

(a)

(b)

Pˇr´ıklad 2: Pod´ıl uˇzit´ ych transportn´ıch protokol˚ u

Druhou ukázku jsou stáhl na stránkách programu Wireshark[19], jedná se o tzv. ARP bouˇrku, kterou vyvolal jeden z prvk˚ u v s´ıti. time

dev company

source paddr

target haddress

16:34:30.66 ARP REQ

type

00:60:b3:2a:47:5e Z-COM, INC.

source haddress

196.168.48.1

00:00:00:00:00:00

dev company target paddr 196.168.48.2

16:34:30.79 ARP REQ

00:60:b3:2a:47:5e Z-COM, INC.

192.168.183.1

00:00:00:00:00:00

192.168.183.2

16:34:31.65 ARP REQ

00:60:b3:2a:47:5e Z-COM, INC.

196.168.48.2

196.168.48.1

00:00:00:00:00:00

16:34:31.74 ARP RESP 00:4f:62:0c:54:e4

196.168.48.2

00:60:b3:2a:47:5e Z-COM, INC. 196.168.48.1

16:34:31.79 ARP REQ

00:60:b3:2a:47:5e Z-COM, INC.

192.168.183.1

00:00:00:00:00:00

192.168.183.2

16:34:32.79 ARP REQ

00:60:b3:2a:47:5e Z-COM, INC.

192.168.183.1

00:00:00:00:00:00

192.168.183.2

16:34:32.86 ARP RESP 00:0e:2e:34:33:8e Edimax Technol. 192.168.183.2

00:60:b3:2a:47:5e Z-COM, INC. 192.168.183.1

16:34:32.99 ARP REQ

00:60:b3:2a:47:5e Z-COM, INC.

192.168.157.1

00:00:00:00:00:00

192.168.157.2

16:34:33.11 ARP REQ

00:60:b3:2a:47:5e Z-COM, INC.

193.168.106.1

00:00:00:00:00:00

193.168.106.2

16:34:33.17 ARP RESP 00:12:0e:34:7c:4c AboCom

193.168.106.2

00:60:b3:2a:47:5e Z-COM, INC. 193.168.106.1

16:34:33.99 ARP REQ

00:60:b3:2a:47:5e Z-COM, INC.

192.168.157.1

00:00:00:00:00:00

192.168.157.2

16:34:34.96 ARP REQ

00:12:0e:34:7c:4c AboCom

193.168.106.2

00:00:00:00:00:00

193.168.106.1

16:34:34.96 ARP RESP 00:60:b3:2a:47:5e Z-COM, INC.

193.168.106.1

00:12:0e:34:7c:4c AboCom

193.168.106.2

16:34:34.99 ARP REQ

192.168.157.1

00:00:00:00:00:00

192.168.157.2

192.168.157.2

00:60:b3:2a:47:5e Z-COM, INC. 192.168.157.1

00:60:b3:2a:47:5e Z-COM, INC.

16:34:35.20 ARP RESP 00:4f:62:07:e4:df

38

time

source haddress

dev company

source paddr

target haddress

16:01:05.27 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.173.159

16:01:05.37 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.172.141

16:01:05.38 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.173.161

16:01:05.48 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

65.28.78.1

00:00:00:00:00:00

65.28.78.76

16:01:05.49 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.173.163

16:01:05.58 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.175.123

16:01:05.60 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.173.165

16:01:05.68 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.175.82

16:01:05.73 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

69.76.216.1

00:00:00:00:00:00

69.76.220.131

16:01:05.76 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.173.168

16:01:05.78 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

69.76.216.1

00:00:00:00:00:00

69.76.221.27

16:01:05.78 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.174.184

16:01:05.81 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.173.169

16:01:05.86 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.174.181

16:01:05.93 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

69.76.216.1

00:00:00:00:00:00

69.76.223.216

16:01:05.96 ARP REQ

00:07:0d:af:f4:54

Cisco Systems

24.166.172.1

00:00:00:00:00:00

24.166.173.172

6.4

type

company target paddr

Modul DNS

Závˇereˇcná ukázka demonstruje práci pˇri dotazovan´ı a odpov´ıdán´ı server DNS, kter´ y má na starost pˇreklad ˇc´ıseln´ ych adres na doménová jména, dále udrˇzuje informace o poˇstovn´ım serveru domény, atd. U kaˇzdé navrácené odpovˇedi naleznete informaci o ˇcase, za jak´ y doˇslo k vyˇr´ızen´ı, dále protokol, pˇres kter´ y odpovˇed’ a identifikace dotazu probˇehla. Následuje vyˇc´ıslen´ı poˇctu otázek (resp. odpovˇed´ı) a na dalˇs´ıch ˇrádc´ıch v´ ypisu jiˇz figuruj´ı otázky a odpovˇedi. U vˇetˇsiny znám´ ych typ˚ u odpovˇed´ı jsou znázornˇeny detailn´ı informace. Prvn´ı ukázka pocház´ı z programu Tcpdump a ukazuje bˇeˇzné dotazy, uskuteˇcn ˇované pˇri brouzdán´ı po webov´ ych stránkách. DNS UDP query: 0.128958

41305

1

1

1

0

(- - RD RA)

Q: www.bonusweb.cz AAAA IN R: answer

www.bonusweb.cz CNAME IN 837 (bonusweb.cz)

R: authority

bonusweb.cz SOA IN 1800 (ns1.mobil.cz, hostmaster.mobil.cz, 2009011601, 1800, 900, 604800, 1800)

DNS UDP query: 0.091388

56210

1

2

2

0

(- - RD RA)

Q: www.hobby.cz A IN R: answer

www.hobby.cz CNAME IN 69290 (c2.idnes.cz)

R: answer

c2.idnes.cz A IN 878 (194.79.52.193)

R: authority

idnes.cz NS IN 2351 (ns2.mafra.cz)

R: authority

idnes.cz NS IN 2351 (ns.mafra.cz)


28638

1

1

1

0

(- - RD RA)

Q: www.hobby.cz AAAA IN R: answer

www.hobby.cz CNAME IN 69290 (c2.idnes.cz)

R: authority

idnes.cz SOA IN 1800 (ns.mafra.cz, hostmaster.mafra.cz, 2010041501, 1800, 900, 604800, 1800)

39

DNS UDP query: 0.089450 63402

1

2

2

0

(- - RD RA)

Q: www.mobil.cz A IN R: answer

www.mobil.cz CNAME IN 1250 (c2.idnes.cz)

R: answer

c2.idnes.cz A IN 877 (194.79.52.193)

R: authority


R: authority



19899

1

1

1

0

(- - RD RA)

Q: www.mobil.cz AAAA IN R: answer

www.mobil.cz CNAME IN 1250 (c2.idnes.cz)

R: authority



8179

1

2

2

0

(- - RD RA)

Q: www.technet.cz A IN R: answer

www.technet.cz CNAME IN 69289 (technet.cz)

R: answer

technet.cz A IN 69289 (194.79.52.193)

R: authority

technet.cz NS IN 4030 (ns.mafra.cz)

R: authority

technet.cz NS IN 4030 (ns2.mafra.cz)


12552

1

1

1

0

(- - RD RA)

Q: www.technet.cz AAAA IN R: answer

www.technet.cz CNAME IN 69289 (technet.cz)

R: authority

technet.cz SOA IN 10800 (ns.mafra.cz, hostmaster.mafra.cz, 2009072001, 28800, 7200, 604800, 86400)


62360

1

2

2

0

(- - RD RA)

Q: www.xman.cz A IN R: answer

www.xman.cz CNAME IN 69289 (c2.idnes.cz)

R: answer

c2.idnes.cz A IN 877 (194.79.52.193)

R: authority


R: authority



41968

1

1

1

0

(- - RD RA)

Q: www.xman.cz AAAA IN R: answer

www.xman.cz CNAME IN 69289 (c2.idnes.cz)

R: authority



19219

1

2

2

0

(- - RD RA)

Q: zdravi.idnes.cz A IN R: answer

zdravi.idnes.cz CNAME IN 1250 (c3.idnes.cz)

R: answer

c3.idnes.cz A IN 828 (194.79.52.194)

R: authority


R: authority


Na závˇer ukázek pˇridávám právˇe v´ ystup z programu dig, konkrétnˇe se jedná o DNS poˇzadavek na doménu CZ, tedy na ˇceskou doménu nejvyˇsˇs´ı u ´rovnˇe. V´ ystup ukazuje napˇr. záznamy o pod40

pisech a jejich kl´ıˇc´ıch, dále list DNS server˚ u domény a jejich IP adresy v obou verz´ıch. DNS TCP query: 0.054798

0

1

22

5

6

(- - RD RA)

Q: CZ A IN R: answer

CZ RRSIG IN 3600 (6 RSA/SHA-1 1 18000 64127 cz xjzl4fNQhkm6...uLnUQh4dd7mX7+Poz+QJLPQ=)

R: answer

cz SOA IN 3600 (a.ns.nic.cz, hostmaster.nic.cz, 1279157753, 900, 300, 604800, 900)

R: answer

cz RRSIG IN 3174 (2 RSA/SHA-1 1 18000 49499 cz dNOcoqK1Su22...gvoJxMRKxL6gV9m+TH0yZQo=)

R: answer

cz RRSIG IN 3174 (2 RSA/SHA-1 1 18000 64127 cz n0QNrrBa7sIa...DxljQchtoozQR4BOyc3UE58=)

R: answer

cz RRSIG IN 900 (47 RSA/SHA-1 1 900 49499 cz YKbIgqstlHYY...RbDLMZo6LhVcHYbdpt4zbvSQ=)

R: answer

cz RRSIG IN 900 (47 RSA/SHA-1 1 900 64127 cz WKgnUHTjaG1j...8LZ8t+DGacNndUhqXNrJsphY=)

R: answer

cz NSEC IN 900

R: answer

cz DNSKEY IN 3600

R: answer

cz DNSKEY IN 3600

R: answer

cz DNSKEY IN 3600

R: answer

cz DNSKEY IN 3600

R: answer

cz NS IN 2200 (b.ns.nic.cz)

R: answer

cz NS IN 2200 (d.ns.nic.cz)

R: answer

cz NS IN 2200 (c.ns.nic.cz)

R: answer

cz NS IN 2200 (a.ns.nic.cz)

R: answer

cz NS IN 2200 (f.ns.nic.cz)

R: answer

cz RRSIG IN 3600 (48 RSA/SHA-1 1 3600 7978 cz 044/071EUNbXYqr...Xb3LhMU2gz6qB9GjCA==)

R: answer

cz RRSIG IN 3600 (48 RSA/SHA-1 1 3600 49499 cz GMrIkQ9mB3M0eze...FiIcPlSzmEBQeOY9Xn8=)

R: answer

cz RRSIG IN 3600 (48 RSA/SHA-1 1 3600 64127 cz kMUY7VCdVazESur...PrtHrxrzWH2sbTc2VUk=)

R: answer

cz RRSIG IN 172799 (43 Unknown algorithm 1 172800 41248 YLEVIwUeei...pCfLkLGMjL1/E=)

R: answer

cz DS IN 172791 (9988 RSA/SHA-1 1 Ghjsr7hXl66hAxcD/Jpuc8kVACs=)

R: answer

cz DS IN 172791 (7978 RSA/SHA-1 1 RwkUzdqY0MwAFojLMsF6CckVAAI=)

R: authority

cz NS IN 2200 (d.ns.nic.cz)

R: authority

cz NS IN 2200 (b.ns.nic.cz)

R: authority

cz NS IN 2200 (a.ns.nic.cz)

R: authority

cz NS IN 2200 (f.ns.nic.cz)

R: authority

cz NS IN 2200 (c.ns.nic.cz)

R: additional a.ns.nic.cz A IN 148648 (194.0.12.1) R: additional a.ns.nic.cz AAAA IN 148648 (2001:678:f::1) R: additional b.ns.nic.cz A IN 148649 (194.0.13.1) R: additional b.ns.nic.cz AAAA IN 148649 (2001:678:10::1) R: additional d.ns.nic.cz A IN 148648 (193.29.206.1) R: additional d.ns.nic.cz AAAA IN 148648 (2001:678:1::1)

41

Vnitˇ rn´ı ˇ reˇ sen´ı analyz´ atoru 7.1

Soubory programu

Na u ´vod závˇereˇcné kapitole zaˇcnu s pˇredstaven´ım vˇsech zdrojov´ ych soubor˚ u, které v programu naleznete. Jejich seznam spolu s vysvˇetlen´ım naleznete v následuj´ıc´ı tabulce. Jm´ eno souboru config.h data obj.c (data obj.h) event calc (event cal.h) logger.c (logger.h) Makefile modules.c (modules.h) nepal.i utils.c (utils.h)

7.2

Popis definice konstant spolu s datov´ ymi typy implementace datového objektu, zejména velká mnoˇzina funkc´ı pro ukládán´ı hodnot zásobn´ık události, funkce pro registrace a vyˇr´ızen´ı událost´ı logovac´ı systém, pˇrevzat´ y z knihovny LibUCW soubor s definic´ı kompilace a linkován´ı programu deklarace a implementace vˇsech modul˚ u, které jsou pouˇzity v programu soubor pro definován´ı obalu pro program SWIG soubor s pomocn´ ymi funkcemi

Implementace datov´ eho objektu

Datov´ y objekt je univerzáln´ı struktura pro ukládán´ı informac´ı o datagramech, paketech, spojen´ıch atd. Pro ukládán´ı dat do datového objektu slouˇz´ı heˇsovac´ı tabulka z d´ılny knihovny LibUCW[5], která zaheˇsuje atribut nˇejakého typu do tabulky. Atributy zpravidla rozdˇelujeme do dvou základn´ıch kategori´ı: hodnotové a referenˇcn´ı. Hodnotové atributy sed´ı pˇr´ımo ve struktuˇre pro atribut a jsou jimi napˇr. INT, IPV4, DOBJ. Na druhé stranˇe stoj´ı atributy o kter´ ych pˇredem nev´ıme, jak budou dlouhé. Pˇr´ıkladem budiˇz STRING ˇci ARRAY, pro takové atributy je nutné alokovat m´ısto mimo strukturu a uloˇzit si jejich referenci. Pro veˇskerou alokaci pamˇeti pro datov´ y objekt je pouˇzit memory pool, pro uvolnˇen´ı pamˇeti objektu. Nen´ı nutné dealokovat po jednom vˇsechny atributy, ale staˇc´ı zavolat metodu poolu, jeˇz uvoln´ı cel´ y blok pamˇeti. Popsaná technika urychluje práci s pamˇet´ı a zapouzdˇruje data spoleˇcná pro jeden objekt. Kaˇzd´ y datov´ y objekt jasnˇe definuje, jaké je tˇr´ıdy, a disponuje také zásobn´ıkem událost´ı.

7.3

Z´ asobn´ık ud´ alost´ı

D´ıky zásobn´ıku událost´ı m˚ uˇzeme o programu hovoˇrit jako o událostmi ˇr´ızeném. Nedocház´ı k pˇr´ımému volán´ı metod, n´ ybrˇz nastane událost, která posléze zavolá vˇsechny metody, které jsou v zásobn´ıku událost´ı zaregistrované. O zásobn´ıku mluv´ıme z toho d˚ uvodu, ˇze pokud nastane událost, nen´ı nikam uloˇzena do kalendáˇre pro vyˇr´ızen´ı, ale jsou sekvenˇcnˇe procházeny události 42

a zavolány jejich metody pro obslouˇzen´ı. Hlavn´ı smyˇcka je provádˇena v modulu PCAP, jenˇz naˇc´ıtá data ze souboru a volá pro kaˇzd´ y paket obsluhu události packet. Zásobn´ıkem disponuj´ı témˇeˇr vˇsechny naprogramované moduly a i nˇekteré typy datov´ ych objekt˚ u, které zpravidla pˇredstavuj´ı nˇejak´ y IP datagram, spojen´ı, atd. Z hlediska vlastn´ı implementace je nejprve nutné registrovat jméno události do heˇsovac´ı tabulky. Pro registrován´ı metody do zásobn´ıku je nutné uloˇzit identifikátor události do heˇsovac´ı tabulky. Po vypuknut´ı události nejprve naleznu událost v zásobn´ıku a zaˇcnu sekvenˇcnˇe procházet vˇsechny zaregistrované funkce. Volán´ı funkc´ı je vytvoˇreno pomoc´ı Python C API, kde jako jedin´ y argument vypln´ım datov´ y objekt a obalen´ y objekt v Pythonu posléze m˚ uˇze vstoupit jednak do funkce v jazyce C, tak do funkce v Pythonu. ˇ Reˇsen´ı je celkem jednoduché a pro správné volán´ı funkc´ı si vystaˇc´ıme s klasick´ ym zásobn´ıkem volán´ı, nen´ı nutné realizovat centráln´ı kalendáˇr nebo jinou, podobnˇe orientovanou, datovou strukturu.

7.4

Programov´ an´ı modul˚ u

Pˇri programován´ı modul˚ u musel b´ yt brát zˇretel na nˇekolik vˇec´ı. Kaˇzd´ y modul dostává na svém vstupu datov´ y objekt a je nutné filtrovat jejich typ. Pro tyto u ´ˇcely slouˇz´ı datové tˇr´ıdy a jejich otestován´ı je velmi rychlé. Dalˇs´ı nepˇr´ıjemnost´ı se stává skuteˇcnost, ˇze paket nebyl odchycen ze s´ıtˇe v celé své velikosti. Proto je bˇehem naˇc´ıtán´ı informac´ı vˇzdy nutné kontrolovat velikost dat a cel´ y program je kontrolami protkán. Pro programován´ı komplikovanˇejˇs´ıch modul˚ u si nelze vystaˇcit pouze s datov´ ymi objekty a je nutné vytváˇret i dalˇs´ı pomocné datové struktury. Jako velmi ˇsikovn´ y se ukázat void ukazatel, d´ıky nˇemuˇz nen´ı sloˇzité uloˇzit do datového objektu ukazatel na nˇejakou pomocnou strukturu a pˇri resetován´ı ˇci vyprˇsen´ı ˇcasového limitu se nejen smaˇze spojen´ı, ale dojde i k uvolnˇen´ı pamˇeti, takto vznikl´ ych struktur.

7.5

Pˇ redstava fungov´ an´ı modulu TCP

Modul TCP povaˇzuji za nejsloˇzitˇejˇs´ı v rámci programu a proto bych se rád zm´ınil o jeho fungován´ı. Jako vstup se naˇctou pakety s´ıt’ové vrstvy, následnˇe dojde k dekódován´ı atribut˚ u hlaviˇcky a nalezen´ı spojen´ı, do nˇehoˇz paket zapadá. Pro ukládán´ı spojen´ı je pouˇzita heˇsovac´ı tabulka, kde za pomoci adres a port˚ u vzniká jednoznaˇcná identifikace spojen´ı. Prvn´ım omezen´ım, které je nutné brát na zˇretel, je potvrzován´ı: data proˇslá po s´ıt’ové infrastruktuˇre jsou pˇredávána aplikaˇcn´ı vrstvˇe aˇz v okamˇziku, kdy doraz´ı potvrzen´ı od druhé strany. Proto je nutné vstupn´ı data ukládat do zásobn´ık˚ u a uvolˇ novat je aˇz po doruˇcen´ı potvrzen´ı. Za druh´ y problém povaˇzuji ztrátu pˇrenesen´ ych paket˚ u bˇehem odchytáván´ı, které je povˇetˇsinou zp˚ usobeno t´ım, ˇze pakety pˇricház´ı ve ˇspiˇckách rychleji, neˇz je disk staˇc´ı ukládat. Jak jiˇz bylo zm´ınˇeno, modul vytváˇr´ı datov´ y objekt TCP flow, které disponuje vlastn´ım kalendáˇrem událost´ı, uchovává si stav spojen´ı a na obou smˇerech kanálu drˇz´ı data proˇslá po s´ıti, která jeˇstˇe nejsou potvrzena. Pro ilustraci fungován´ı slouˇz´ı pˇriloˇzen´ y obrázek. Na horn´ı ˇca´sti obrázku m˚ uˇzeme nahlédnout dva moduly, které jiˇz byly ukázány v schématu zapojen´ı programu. Z modulu TCP flow vid´ıme, ˇze nastala událost conn create, jeˇz symbolizuje vznik nového spojen´ı. Na obrázku jsou znázornˇeny jak vlastn´ı zásobn´ık událost´ı, tak zásobn´ıky paketu, které ˇcekaj´ı na potvrzen´ı. Kromˇe jeˇstˇe nepotvrzen´ ych paket˚ u m˚ uˇzeme vidˇet i TCP data, jenˇz vznikaj´ı pˇri události data. Data v sobˇe nesou pouze základn´ı informace a na 43

zm´ınˇenou událost se typicky navˇeˇsuj´ı dalˇs´ı moduly (napˇr. Modul HTTP), data zpracovávaj´ı a také uvolˇ nuj´ı (uvolnˇená data symbolizuje proˇskrtl´ y obdéln´ık). Z hlediska koneˇcného mnoˇzstv´ı pamˇeti, jenˇz máme k dispozici nen´ı moˇzné vˇse drˇzet v pamˇeti a systém datov´ ych objekt˚ u nám slouˇz´ı jako dobr´ y mechanizmus. Jako obrana proti velkému mnoˇzstv´ı alokované pamˇeti jsou implementovány dva mechanizmy pro uvolˇ nován´ı uˇzité pamˇeti. Prvn´ım mechanizmem je limit na horn´ı poˇcet paket˚ u v zásobn´ıku spojen´ı, limit lze v modulu TCP flow nastavit a pˇri dosaˇzen´ı ym mehranice je celé spojen´ı prohláˇseno za neplatné a nastane událost conn timeout. Druh´ chanizmem je kontrola posledn´ıho doˇslého paketu do spojen´ı, kdy se kontroluj´ı neaktivn´ı spojen´ı a jsou následnˇe prohlaˇsována za neplatná (nastane událost conn timeout a dojde k ukonˇcen´ı spojen´ı).

44

Z´ avˇ er 8.1

Zhodnocen´ı pr´ ace

Ve vytvoˇreném programu nen´ı mnoˇzina pokryt´ ych protokol˚ u modelu TCP/IP kompletnˇe pokryta a ani b´ yt nem˚ uˇze. Nen´ı v moˇznostech bakaláˇrské práce zahrnou stovky dneˇsn´ıch protokol˚ u do jednoho programu. Za mnohem d˚ uleˇzitˇejˇs´ı povaˇzuji fakt, ˇze funkˇcn´ı program je dostateˇcnˇe obecn´ y a otevˇren´ y, a proto pˇri pˇridáván´ı nového protokolu nenaraz´ı autor na ˇzádné pˇrekáˇzky. Pˇri vytváˇren´ı specifikace programu byla dlouho otevˇrená otázka propojen´ı jádra programu, napsaném v jazyce C, se skriptovac´ım jazykem. Nakonec jsem zvolil jazyk Python, se kter´ ym jsem doposud nemˇel ˇza´dnou zkuˇsenost. Python se osvˇedˇcil po vˇsech stránkách: poskytl prostˇredky pro tvorbu skript˚ u, lze j´ım lehce obalit kód v jazyce C a doplnit jej o metody tˇr´ıd a nakonec byl jazyk také zvolen pro jeho nezávislost na operaˇcn´ım systému. Jak zkuˇsenosti s programem ukazuj´ı, rychlost programu na stroji s procesorem Intel Core2 Duo 2GHz, s pevn´ ym diskem s 5 400 otáˇckami za minutu dosahuje pˇri spuˇstˇen´ı skriptu HTTP rychlost asi 13 MB/s, coˇz odpov´ıdá 100 Mb/s. Pˇri této rychlosti zpracován´ı dat je moˇzné program nasadit v reálném ˇcase na poloduplexn´ı 100Base-TX linku. Jak testy hlavnˇe jednoduˇsˇs´ıch skript˚ u ukázaly, nejvˇetˇs´ı hardwarovou slabinou se stává pevn´ y disk, kter´ y v pˇr´ıpadˇe notebooku pracuje témˇeˇr na pln´ y v´ ykon. V rané fázi návrhu jsem pˇrem´ yˇslel nad myˇslenkou v´ıcevláknové aplikace, ale protoˇze se naˇs´ım nejvˇetˇs´ım omezen´ım stává právˇe pevn´ y disk, byl by pˇr´ınos v´ıce v´ ypoˇcetn´ıch jader zanedbateln´ y a vznikala by nemalá reˇzie spojená se synchronizac´ı. Co se vlastn´ıho programován´ı t´ yˇce, tak se od poˇca´tku poˇc´ıtalo s programovac´ım jazykem C. D´ıky knihovnˇe LibUCW se ale programován´ı stalo pohodlnˇejˇs´ı, pro alokaci pamˇeti se osvˇedˇcil mempool a cel´ y program je protkán heˇsovac´ımi tabulkami, poˇc´ınaje tˇemi jednoduch´ ymi s atomick´ ym typem a konˇce sloˇzitˇejˇs´ımi s v´ıcesloˇzkov´ ym kl´ıˇcem. Trendem dneˇsn´ı doby se stává programován´ı ve stále vyˇsˇs´ıch programovac´ıch jazyc´ıch za pomoci silné knihovny funkc´ı. Mus´ım ale pˇriznat, ˇze práce v jazyce C má stále své kouzlo a jiˇz jednou zm´ınˇená knihovna dodá programátorovi potˇrebn´ y komfort pˇri práci.

8.2

Moˇ znosti budouc´ıho v´ yvoje

Program um´ı pracovat zhruba s jednou des´ıtkou protokol˚ u rodiny TCP/IP, coˇz v porovnán´ı s celkov´ ym poˇctem protokol˚ u pˇredstavuje pouze malou podmnoˇzinu. Jistˇe by bylo velmi zaj´ımavé zpracován´ı protokol˚ u jako jsou napˇr´ıklad: SIP (Session Initiation Protocol), SMTP (Simple Mail Transfer Protocol) ˇci FTP (File Transfer Protocol). Jako dalˇs´ı vylepˇsen´ı vid´ım moˇznost napˇr. v on-line analyzátoru, kdy by vznikla webová stránka s mnoˇzinou podporovan´ ych anal´ yz. Na uˇzivateli by poté bylo si vybrat anal´ yzy, které chce provést a program by mu následnˇe odeslal jejich v´ ysledky. Podobnˇe by mohl b´ yt analyzátor nasazen za bˇehu s´ıtˇe v reˇzimu on-line, kdy by se data neukládala do souboru, ale pˇr´ımo by se zas´ılala analyzátoru. Nasazen´ı za bˇehu s´ıtˇe by jistˇe vyˇzadovalo drobné zmˇeny, ale v´ ysledky by mohly b´ yt zaj´ımavé a stály by za to.

45

Literatura [1] W. Richard Stevens: TCP/IP Illustrated, Volume 1, The Protocols 1. vydan´ı, Reading: Addison-Wesley, 1994, ISBN 0-201-63346-9 [2] Lamping U. a kol. (2010): Wireshark User’s Guide [online] http://www.wireshark.org/docs/wsug_html/ (5.6.2010) [3] Peterka J. (2010): E-archiv, pˇrednáˇska Rodina protokol˚ u TCP/IP [online] http://www.earchiv.cz/l221/index.php3 (6.6.2010) [4] IEEE OUI list [online] http://standards.ieee.org/regauth/oui/oui.txt (29.6.2010) [5] Mareˇs M. a kol. (2010): Knihovna UCW [online] http://www.ucw.cz/libucw/ (30.6.2010) [6] Python Software Foundation: Programovac´ı jazyk Python [online] http://python.org/ (18.7.2010) [7] Software Freedom Conservancy: SWIG, Simplified Wrapper and Interface Generator [online] http://swig.org/ (18.7.2010) [8] Hunter J. a kol. (2010): Matplotlib, vykreslovac´ı matematická knihovna pro Python [online] http://matplotlib.sourceforge.net/ (18.7.2010) [9] Carstens T.: PCAP, Packet capture library [online] http://tcpdump.org/ (18.7.2010) [10] GCC team: GCC, The GNU Compiler Collection [online] http://gcc.gnu.org/ (20.7.2010) [11] Plummer D.C. (1982): Request For Comments: 826, An Ethernet Address Resolution Protocol [online] http://www.ietf.org/rfc/rfc826.txt (26.7.2010) [12] Finlayson a kol. (1984): Request For Comments: 903, A Reverse Address Resolution Protocol [online] http://www.ietf.org/rfc/rfc903.txt (26.7.2010) [13] Information Sciences Institute (1981): Request For Comments: 791, Internet Protocol [online] http://www.ietf.org/rfc/rfc791.txt (26.7.2010) [14] Deering S. a kol. (1998): Request For Comments: 2460, Internet Protocol, Version 6 (IPv6) [online] http://www.ietf.org/rfc/rfc2460.txt (26.7.2010) [15] Postel J. a kol. (1980): Request For Comments: 768, User Datagram Protocol [online] http://www.ietf.org/rfc/rfc768.txt (26.7.2010) [16] Information Sciences Institute (1981): Request For Comments: 793, Transmission Control Protocol [online] http://www.ietf.org/rfc/rfc793.txt (26.7.2010) 46

[17] Feeling R. a kol. (1999): Request For Comments: 2616, Hypertext Transfer Protocol [online] http://www.ietf.org/rfc/rfc2616.txt (26.7.2010) [18] SIA ”Mikrotikls”(2010): RouterOS, operating system of RouterBOARD [online] http://www.mikrotik.com/ (26.7.2010) [19] Wireshark sample files, arp-storm.pcap [online] http://wiki.wireshark.org/SampleCaptures (26.7.2010)

47

Univerzita Karlova v Praze Matematicko-fyzikální fakulta. Martin Liška. Katedra aplikované matematiky

Recommend Documents