Martin Liška Pasivn´ı analyzátor s´ıt´ı - NEPAL

Transkript

Univerzita Karlova v Praze
Matematicko-fyzikálnı́ fakulta
BAKALÁŘSKÁ PRÁCE
Martin Liška
Pasivnı́ analyzátor sı́tı́
Katedra aplikované matematiky
Vedoucı́ bakalářské práce: Mgr. Martin Mareš, Ph.D.
Studijnı́ program: Informatika, obor Programovánı́
2010
Chtěl bych poděkovat Mgr. Martinu Marešovi, Ph.D. za vedenı́ bakalářské práce, cenné rady,
účelné připomı́nky a za ochotu při společné práci.
Prohlašuji, že jsem svou bakalářskou práci napsal(a) samostatně a výhradně s použitı́m citovaných pramenů. Souhlası́m se zapůjčovánı́m práce a jejı́m zveřejňovánı́m.
V Praze dne 3. srpna 2010
Martin Liška
2
Obsah
1 Úvod
1.1 Analýza sı́t’ového provozu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Problémy s provozovánı́m sı́tě . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Rodina protokolů TCP/IP
2.1 Architektura protokolu TCP/IP . . . .
2.2 Historie protokolu TCP/IP . . . . . . .
2.3 Porovnánı́ s modelem ISO/OSI . . . .
2.4 Linková vrstva a technologie Ethernet .
2.5 Sı́t’ová vrstva IP . . . . . . . . . . . . .
2.6 Transportnı́ vrstva . . . . . . . . . . .
2.6.1 Protokol UDP . . . . . . . . . .
2.6.2 Protokol TCP . . . . . . . . . .
3 Pasivnı́ sı́t’ové analyzátory
3.1 Definice . . . . . . . . . . . .
3.2 Tcpdump . . . . . . . . . . .
3.3 Tcpflow . . . . . . . . . . . .
3.4 Wireshark . . . . . . . . . . .
3.4.1 Historie . . . . . . . .
3.4.2 Filtrovánı́ . . . . . . .
3.4.3 Analýza rámců . . . .
3.4.4 Statistické komponenty
3.5 Netgrind . . . . . . . . . . . .
4 Sı́t’ový analyzátor NEPAL
4.1 Představenı́ . . . . . . . . . .
4.2 Zapojenı́ programu . . . . . .
4.3 Datový objekt . . . . . . . . .
4.4 Představenı́ modulů . . . . . .
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 Ovládánı́ programu NEPAL
5.1 Překlad programu . . . . . . . . . . .
5.2 Ukázka programu . . . . . . . . . . .
5.3 Ovládánı́ a programátorské rozhranı́ .
5.4 Spouštěnı́ programu . . . . . . . . . .
.
.
.
.
29
29
29
30
32
.
.
.
.
.
.
.
.
.
33
33
33
33
34
35
35
37
37
39
.
.
.
.
.
42
42
42
42
43
43
8 Závěr
8.1 Zhodnocenı́ práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Možnosti budoucı́ho vývoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
45
45
Literatura
46
6 Ukázky z programu NEPAL
6.1 Modul pro HTTP . . . . .
6.1.1 Prvnı́ přı́klad . . .
6.1.2 Druhý přı́klad . . .
6.1.3 Třetı́ přı́klad . . .
6.2 Grafový modul . . . . . .
6.2.1 Prvnı́ přı́klad . . .
6.2.2 Druhý přı́klad . . .
6.3 Modul ARP/RARP . . . .
6.4 Modul DNS . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Vnitřnı́ řešenı́ analyzátoru
7.1 Soubory programu . . . . . . . .
7.2 Implementace datového objektu .
7.3 Zásobnı́k událostı́ . . . . . . . . .
7.4 Programovánı́ modulů . . . . . .
7.5 Představa fungovánı́ modulu TCP
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Název práce: Pasivnı́ analyzátor sı́tı́
Autor: Martin Liška
Katedra (ústav): Katedra aplikované matematiky
Vedoucı́ bakalářské práce: Mgr. Martin Mareš, Ph.D.
E-mail vedoucı́ho: [email protected]
Abstrakt: Cı́lem práce je navrhnout a implementovat program pro monitorovánı́ a analýzu provozu v počı́tačových sı́tı́ch, který bude pracovat čistě pasivně, tedy aniž by ovlivňoval měřenou komunikaci. Informace o chovánı́ sı́tě bude zı́skávat odposlouchávánı́m přenášených paketů, z nichž
bude rekonstruovat chod sı́t’ových spojenı́ a činnost přenosových protokolů.
Klı́čová slova: analýza, TCP/IP, počı́tačové sı́tě
Title: A passive network analyser
Author: Martin Liška
Department: Department of Applied Mathematics
Supervisor: Mgr. Martin Mareš, 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
Úvod
1.1
Analýza sı́t’ového provozu
Provozovánı́ sı́t’ové komunikace mezi počı́tači je v dnešnı́ době již dávno zaběhlá praxe a množstvı́
datového provozu a počet lidı́, kteřı́ majı́ přı́stup k Internetu budiž toho důkazem. Počet
uživatelů sı́tě Internet se vyšvihl na dnešnı́ hodnotu 1,8 miliardy lidı́, což odpovı́dá vı́ce než
čtvrtině obyvatelstva planety a oproti roku 2000 vzrostl tento počet uživatelů čtyřnásobně.
Jenom v rámci páteřnı́ sı́tě NIX.CZ v České republice vzrostlo množstvı́ přenesených dat
dvojnásobně oproti roku minulému. Z pohledu samotného sı́t’ového provozu je valná většina
informacı́ přenášena pomocı́ rodiny protokolů TCP/IP a dı́ky nezašifrované většině provozu
je možné záznamy komunikace sledovat, ukládat a následně analyzovat. Viděno očima běžného
uživatele, napřı́klad sı́tě Internet, je komunikace a přenos dat v rámci sı́tě černou skřı́ňkou, která
zdánlivě funguje velmi spolehlivě, intuitivně a bezpečně.
1.2
Problémy s provozovánı́m sı́tě
Druhá strana mince ale jasně ukazuje, že zneužitı́ přenášených informacı́ je vcelku snadné,
přı́kladem budiž možnost sledovánı́ navštı́vených webových stránek, odeslaných formulářů a
emailových zpráv obsahujı́cı́ch osobnı́ informace, zobrazených obrázků, odeslaných zpráv napřı́klad pomocı́ protokolu IRC či možnost dohledánı́ hesel, kterými se uživatel autorizuje na
nezašifrovaných webových serverech. Se svojı́ velikostı́ se stal Internet kolbištěm nejrůznějšı́ch
zájmů, počı́naje masivnı́ reklamou na každém kroku, přes rozesı́lánı́ nevyžádané pošty, šı́řenı́
internetových červů a konče útoky na citlivé osobnı́ údaje v podobě databázových aplikacı́.
Druhým fenoménem dnešnı́ch počı́tačových sı́tı́ je tempo narůstánı́ přenosového výkonu infrastruktury. Docházı́ k nasazovánı́ stále sofistikovanějšı́ch sı́t’ových zařı́zenı́, které si ale s sebou
nesou problémy úzkých hrdel. Rychlost v počı́tačové sı́ti se řı́dı́ rychlostı́ jejı́ho nejužšı́ho mı́sta,
přestože v globálnı́ měřı́tku můžeme o sı́ti uvažovat jako o předimenzované. Jako přı́klad mohou
posloužit různé proxy servery, jenž zprostředkovávajı́ komunikaci mimo lokálnı́ sı́t’ nebo protokoly pro sdı́lenı́ souborů typu P2P, které dokáži otevřı́t velké množstvı́ spojenı́. Návaznostı́ na
zmı́něné problémy je dobré problémům porozumět a analýza sı́t’ového provozu může být dobrým
pomocnı́kem pro zı́skávánı́ důležitých informacı́.
1.3
Motivace
Cı́lem bakalářské práce nenı́ zneužitı́ slabin sı́t’ového modelu, nýbrž právě naopak vytvořenı́
programu, který bude schopen nashromážděná sı́t’ová data načı́tat, analyzovat a poskytovat
specifické informace, v podobě člověku co možná nejvı́ce přı́větivé. Přenášená data pomocı́
rodiny protokolů TCP/IP jsou přenášena ve formě rámců (paketů), jenž v sobě nesou pouze
dı́lčı́ část mozaiky a skladba kompletnı́ mozaiky, chápané napřı́klad ve smyslu přenesených
emailů či HTML stránek potřebuje většı́ úsilı́ při syntéze. Již od rané fáze návrhu programového
6
řešenı́ je kladen důraz na modularitu a možná dalšı́ rozšı́řenı́ libovolného druhu. Software lze
chápat jako kmen stromu, který poskytuje základnı́ funkčnost a na který lze naroubovat různá
rozšı́řenı́ a vylepšenı́. Ambicı́ programu nemůže být v žádném přı́pade podpora pro všechny
známé protokoly, ale cı́lem je poskytnout framework, jenž nabı́dne jednoduché rozšı́řenı́ v podobě
modulu v Pythonu či modulu v jazyce C, který bude optimalizovaný na rychlost. Program
bude implementovat podporu základnı́ch protokolů vrstevnatého modelu TCP/IP: Ethernetový
protokol, sı́t’ový protokol verze 4 i 6, protokol TCP a UDP. Zmı́něné protokoly chápu jako nosnou
kostru, na které probı́há přenos většiny dnešnı́ch aplikačnı́ch protokolů a ukázkové moduly
budou právě pracovat na zmı́něném základu.
7
Rodina protokolů TCP/IP
2.1
Architektura protokolu TCP/IP
Rodinou protokolů TCP/IP nazýváme množinu sı́t’ových protokolů užı́vaných v sı́ti Internet a
v jiných počı́tačových sı́tı́. Název rodiny je odvozen z jména protokolu sı́t’ové vrstvy (Internet
Protocol) a jména spojovaného protokolu transportnı́ vrstvy (Transmission Control Protocol).
Rodina pokrývá 4 vrstvy sı́t’ového modelu: linková, sı́t’ová, transportnı́ a aplikačnı́. Vznik protokolu je pevně svázán s rozvojem a prvopočátkem celosvětové počı́tačové sı́tě Internet. Protokol
vznikl v lůně Internetu a stal se jeho hlavnı́m nosným médiem. Myšlenka paketového přenosu je
téměř 50 let stará a vznikla jako duálnı́ idea k sı́ti telefonnı́, kterou odstartoval Alexander Graham Bell v 80. letech 19. stoletı́. Ve svém návrhu počı́tá s umı́stěnı́m inteligence do koncových
uzlů sı́tě, negarantuje přenosovou kapacitu, ale pracuje v režimu best effort“ (maximálnı́ možná
”
snaha). Standardy a specifikace kolem protokolu vznikly ve formě dokumentů RFC (Request for
Comments), kde se široké množstvı́ odbornı́ků shodlo na svobodných, nelicencovaných standardech a vložili tı́m tak do vı́nku velké množstvı́ potenciálu do budoucna. Drobným problémem
dokumentů RFC je nemožnost jejich modifikace a nutnost vydávánı́ nového dokumentu při modifikaci. Pro tyto účely vznikly dokumenty STD (standard) dokumenty, které si lze představit
jako pořadač, do kterého se ukládajı́ RFC dokumenty, týkajı́cı́ se stejného problému.
2.2
Historie protokolu TCP/IP
Jak již bylo výše zmı́něno, myšlenka paketového přenosu se rozvinula na počátku 60. let 20.
stoletı́ v USA v rámci armádnı́ grantové agentury ARPA. Spojené státy v době Studené války
prohrály pomyslný souboj o dobytı́ vesmı́ru v roce 1957 vesmı́rnou lodı́ Sputnik a rozhodly
se investovat do budoucı́ch technologiı́. Na ověřenı́ faktu, zda je myšlenka paketového přenosu
uskutečnitelná vznikla na konci 70. let sı́t’ Arpanet. V sı́ti byl nasazen experimentálnı́ protokol
NCP (Network Control Program), který kopı́roval z dnešnı́ho hlediska funkci transportnı́ vrstvy.
Prvnı́ představa rodiny protokolů TCP/IP byla prezentována v roce 1972 a jejı́ jméno je spjato
s osobou Vintona Gray Cerfa, který jako postgraduálnı́ student na Kalifornské univerzitě a
Stanfordské univerzitě pořádá sı́t’ové semináře, jichž se účastnı́ např. Robert Metcalfe (3Com)
nebo Jack Haverty. Původně měl být nástupce experimentálnı́ho protokolu také monolitický,
ale posléze autoři změnili koncepci a došlo k rozpadu na protokol sı́t’ový (IP) a transportnı́
(TCP). Na přelomu let 70. a 80. se stává protokol TCP/IP preferovaným Ministerstvem obrany
Spojených států a 1. 1. 1983 na něj přešlo všech zhruba 200 směrovačů předchůdce dnešnı́ sı́tě
Internet. Za druhé datum narozenı́ některé autority považujı́ zářı́ 1981, kdy spatřily světlo
světa RFC dokumenty 791 a 793, v nichž se specifikujı́ protokoly IP a TCP. V rámci přechodu
vlastnictvı́ a plánovánı́ problematiky kolem Internetu a protokolů TCP/IP vznikla organizace
ISOC (Internet Society), která převzala od vlády Spojených států odpovědnost za dalšı́ vývoj
a vystupuje jako organizace k ostatnı́m subjektům na trhu. V rámci organizace je kladen důraz
na kontinuitu a stromovou strukturu, kde jednotlivé divize zastřešujı́ na jedné straně vývoj do
budoucna a řešenı́ aktuálnı́ch problému např. s nedostatkem IPv4 veřejných adres konče.
8
2.3
Porovnánı́ s modelem ISO/OSI
Referenčnı́ model ISO/OSI vznikl jako model pro počı́tačové sı́tě z dı́lny Mezinárodnı́ organizace pro standardy (ISO) v roce 1984. Model pocházı́ ze světa spojů a v průběhu své geneze a
vývoje se ubı́ral značně odlišně od rodiny protokolů TCP/IP, se kterými nakonec prohrál na plné
čáře. Koncepce se zrodila od zeleného stolu, definovaly se obecně funkce jednotlivých vrstev bez
korespondence s realitou a vyzkoušenou implementacı́. Pro porovnánı́ je nutné v 2. fázı́ přijetı́
dokumentu RFC pro protokoly souvisejı́cı́ s TCP/IP vytvořit alespoň dvě funkčnı́ implementace
a v praxi je ověřit a důkladně otestovat. Autoři nakladli velkou množinu požadavků na sı́t’ovou
architekturu a prosadili ji do standardu. Organizace ISO měla velký vliv na fungovánı́ státu a
správa států tlačila na pořizovánı́ zařı́zenı́, jež by vyhovovalo standardům a bylo plně kompatibilnı́. V důsledku širokého rozpětı́ referenčnı́ho modelu museli ze svých požadavků tvůrci ustupovat a vyjasnili je až v podmnožině, známé pod jménem GOSIP (Government OSI Profile). Pro
porovnánı́ ukažme paralelu s protokoly TCP/IP, které vznikaly od jednoduššı́ho ke složitějšı́mu.
Jako přı́klad bych rád uvedl elektronickou poštu a SMTP protokol. Prvnı́ verze uměla pouze
přenášet zprávy v prostém textu bez možnosti formátovánı́, vkládánı́ obrázků, přı́loh a to včetně
možnosti užitı́ národnı́ch znaků abecedy. Na poptávku reagovalo rozšı́řenı́ MIME (Multipurpose
Internet Mail Extensions – vı́ceúčelové rozšı́řenı́ internetové pošty), jež specifikovalo a zahrnovalo výše zmı́něné nedostatky. Na následujı́cı́m obrázku si můžete prohlédnout korespondenci
sedmi vrstev modelu ISO/OSI s čtyřmi vrstvami v přı́padě modelu TCP/IP.
Za nejvı́ce kritizované vrstvy modelu ISO/OSI považuji vrstvu relačnı́ a prezentačnı́, které
majı́ velmi omezené penzum práce oproti ostatnı́m. Naopak velké portfolio služeb se soustředilo
do vrstvy linkové, jež se následkem toho rozpadla na podvrstvy LLC a MAC. Dalšı́m důležitým
rozdı́lem je přı́tomnost spojovaného charakteru přenosu a spolehlivého doručovánı́ v ISO/OSI.
Autoři ze světa telefonnı́ch systémů považovali nespolehlivou službu za zbytečnou, neviděli
důvod, proč by jı́ měl někdo koupit a v důsledku toho museli investovat do drahé vnitřnı́ infrastruktury sı́t’ových prvků. V prostředı́ TCP/IP je negarantovaný přenos hojně užı́ván např.
v P2P sı́tı́ch (sı́tě, kde se informace přenášı́ mezi uzly bez centrálnı́ho serveru), kdy aplikace
implementuje algoritmus pro potvrzovánı́ přenesených dat dle vlastnı́ logiky a potřeby. Spo9
jovaný charakter komunikace zase vycházel z fungovánı́ telefonnı́ sı́tě, avšak na přenos malého
množstvı́ dat se nevyplatı́ navazovat spojenı́. V rámci propojovánı́ sı́tı́ se ukázal model ISO/OSI
jako velmi slabý, od začátku předpokládal topologie sı́ti v dikci vlád, proto je podpora propojovánı́ sı́tı́ (internetworking) velmi slabá. Problematiky se týká i návrh linkové vrstvy pouze
na dvoubodových spojı́ch, načež musel být dodatečně zakomponován mechanismus pracujı́cı́ se
sdı́leným médiem, který vyústil v rozpad linkové vrstvy. Model počı́tal s podobou velmi rozsáhlé
sı́tě oproti sı́ti lokálnı́ a dlouho dobu byl prosazován jako oficiálnı́ a certifikované řešenı́. Po
třech fázı́ch přibližovánı́ a smiřovánı́ s potřebami počı́tačové sı́tě se stal ISO/OSI model prakticky mrtvým řešenı́m, na kterém se ukázaly prvotnı́ nedostatky v celkové koncepci a filosofii
přı́stupu.
2.4
Linková vrstva a technologie Ethernet
Sı́t’ový model TCP/IP nespecifikuje linkové vrstvy použité na přenosové sı́ti, pouze specifikuje vrstvu sı́t’ového rozhranı́, která je závislá na použitı́ konkrétnı́ho linkového protokolu. Nejpoužı́vanějšı́m linkovým protokolem je Ethernet, dále pak z historického hlediska Token ring,
FDDI či X.25. Technologie Ethernetu se zrodila ve středisku PARC a nejznámějšı́ jména spjatá
s jeho genezı́ jsou Robert Metcalfe a David Boggs. Firma Xerox si nechala po vývoji zaregistrovat
jméno jako ochranou známku. Po předloženı́ návrhu na standardizaci společnosti IEEE se vývoj
vydal dvěma hlavnı́mi vývojovými směry. IEEE standardizovalo Ethernet, původně navržený
firmou Xerox, jako standard 802.3, který se odlišuje od původnı́ho návrhu. Autoři původnı́ho
návrhu zakotvili koncepci Ethernetu do průmyslového standardu, známému jako Ethernet II
(RFC 894). Oba zmı́něné formáty nevylučujı́ vzájemnou koexistenci a dle RFC 894 musı́ být ve
světě TCP/IP každý počı́tač schopen komunikovat pomocı́ Ethernetu II. Atributy paketů dle
obou specifikacı́ naleznete na dalšı́m obrázku.
Při svém návrhu byl Ethernet koncipován jako technologie s přı́stupovou metodou
CSMA/CD, kdy se předpokládá sdı́lené médium, zařı́zenı́ majı́ přı́poslech nosné a jsou schopny
detekovat kolize. Filosofie nezaručuje každému, že bude hned schopen vysı́lat a proto technologie nenı́ vhodná automaticky do mı́st, kde potřebujeme nějaké záruky na maximálnı́ dobu
do odvysı́lánı́. Od podpory na linkové vrstvě se odvı́jı́ i garance služeb QoS, na něž musı́ být
myšleno již od nejnižšı́ch vrstev. Ethernet byl navržen jako 1-perzistentnı́, tedy čekajı́cı́ na konec
jiného vysı́lánı́, ale v důsledku mikrosegmentace na úrovni přepı́načů je princip dnes zastaralý
a použı́vaný hojně spı́še v sı́tı́ch typu 802.11 (bezdrátové lokálnı́ sı́tě).
10
Při programovánı́ modulu pro načı́tánı́ a zpracovánı́ Ethernetových rámců jsou nejdůležitějšı́mi atributy: zdrojová a cı́lová hardwarová adresa ve formátu EUI-48 a typ použitého
sı́t’ového protokolu, zabaleného uvnitř paketu. Vzájemná koexistence schopnosti detekce rámců
typu Ethernet II a 802.3 je možná za předpokladu, že všechny typy sı́t’ového nosiče majı́ konstantu většı́, než je maximálnı́ velikost linkového rámce (1 500B). Podmı́nka je zajištěna, ale
nenı́ přesně dáno, že do budoucna nemůže IEEE, správce Ethernetu, přiřadit konstanty nižšı́
než maximálnı́ velikost. Adresy ve formátu EUI-48 se skládajı́ ze dvou částı́: prvnı́ čtyři bajty jednoznačně identifikujı́ výrobce zařı́zenı́, jenž lze nalézt ve veřejně dostupném zdroji na stránkách
standardů IEEE[4] a zbytek adresy je již jednoznačným identifikátorem vyrobené sı́t’ové karty,
avšak některé operačnı́ systémy umožňujı́ přesto jejich konfiguraci.
2.5
Sı́t’ová vrstva IP
Prvnı́ vrstva, kterou plně pokrývá protokol TCP/IP je vrstva sı́t’ová, jedná se o jediný přenosový
protokol, který se snažı́ být hardwarově nezávislý a univerzálnı́. Ve své podstatě funguje jako
poklička, která umı́ fungovat nad všemi linkovými protokoly a na druhé straně jsou všechny
transportnı́ protokoly implementovány právě nad nı́. Ve verzi 4, která se pomalu stává nedostačujı́cı́ hlavně z hlediska množiny možných unikátnı́ch veřejných adres, se užı́vajı́ virtuálnı́
adresy, zcela bez korespondence k hardwaru (v modelu TCP/IP). Hlavnı́m úkolem sı́t’ové vrstvy
je volba směrů odesı́lánı́ paketů (směrovánı́) a přenos datagramů. Pro ochranu proti zacyklenı́
během přenosu, je do hlavičky zanesena informace o počtech hopů, které ještě může paket
překonat před svých zánikem, problémem je ale fakt, že při každém průchodu směrovačem
musı́me přepočı́távat kontrolnı́ součet. Implementace vrstvy je nutná jak v hostitelských počı́tačı́ch, tak v uzlech přenosové infrastruktury. Oproti tomu ale samotný protokol poskytuje pouze
nespolehlivou a nespojovanou službu, je nositelem pouze nutného minima. V důsledků této
vlastnosti nemáme žádné záruky o doručenı́, nemáme garanci nepoškozenı́ dat, doba doručenı́
se může značně lišit a i proto nenı́ podporovaná garance kvality služeb (QoS – kvalita služby).
Volba variabilnı́ velikosti přenášeného paketu je závislá na užı́vané přenosové linkové vrstvě
a v protokolu je implementován mechanizmus fragmentace, kdy se při přenosu velkého rámce
rozdělı́ na segmenty, které již co do velikosti vyhovujı́ technologie přenosu. Nejrozšı́řenějšı́ verzı́
protokolu IP je verze 4, která v sobě nese 32-bitové sı́t’ové adresy, jejichž kapacita, co do velikosti přidělených veřejných adres, dosahuje svého limitu. Dnes se zvolna přecházı́ na verzi IPv6.
Atributy sı́t’ové vrstvy ve verzi 4 najdete na následujı́cı́m obrázku.
K podstatným atributům sı́t’ových paketů musı́m zařadit identifikaci spolu s offsetem, které
sloužı́ pro účely fragmentace. Atribut TTL (Time to live – životnost paketu) zamezuje zacyklenı́
paketu v sı́ti donekonečna a udává, kolik maximálně může paket navštı́vit přepı́načů před tı́m,
než bude zamı́tnut. Protokolem odlišujeme typ transportnı́ho protokolu, jenž je uložen v datech. Nejčastěji vyskytujı́cı́mi konstantami jsou konstanty pro TCP a UDP. Identifikace sı́t’ových
karet (rozhranı́) je zajištěná dı́ky sı́t’ovým adresám délky 4B, které nejčastěji zapisujeme ve
formátu např. 192.168.0.1. Adresy v protokolu TCP/IP nemajı́ žádnou korespondenci s hardwarem sı́t’ové karty a jedno rozhranı́ (karta) může obsahovat vı́ce adres zároveň. Délka hlavičky
vymezı́ volitelná rozšı́řenı́ hlavičky a určı́ počátek dat vyššı́ vrstvy.
V důsledku velké rychlosti přidělovánı́ veřejných IPv4 adres vznikl problém s jejich nedostatkem, který se částečně podařilo zbrzdit přidělovánı́m menšı́ch bloků IP adresa (za použitı́
11
sı́t’ových masek). Dále vznikl NAT a PAT, které majı́ za úkol maskovat navenek uzly, připojené
v lokálnı́ch sı́tı́ch LAN. Přes to bylo nevyhnutelné přejı́t na novou verzi, která pracuje se
sı́t’ovými adresami velikosti 16B, které jsou bohatě nadimenzovány co do spektra veřejných
adres. Kromě většı́ho adresnı́ho prostoru přibyla bezstavová autokonfigurace, plná podpora
multicastu (vysı́lánı́ k vı́ce uzlům současně), možnost odesı́lánı́ jumbogramů (velké pakety).
Kontrolnı́ součet součástı́ hlavičky a jako novinka přibyla možnost přı́davných hlaviček, které
podporujı́ napřı́klad zabezpečenı́ či mobilnı́ adresovánı́. Detail hlavičky paketu je prezentován
na následujı́cı́m obrázku.
Atributy nejsou nepodobné staršı́ verzi, novinkou ale je možnost připojenı́ rozšiřujı́cı́ch
hlaviček, které na jednu stranu šetřı́ mı́sto, pokud nechceme nést navı́c informace, a na druhou stranu lze rozšı́řenı́ navzájem kombinovat a můžeme jich mezi základnı́ hlavičku a data
připojit vı́ce. Oproti staršı́ verzi IPv4 odpadl kontrolnı́ součet, protože transportnı́ vrstvy
počı́tajı́ kontrolnı́ součet také z metahlavičky sı́t’ové vrstvy a nenı́ nutná jeho modifikace.
Základnı́ i rozšiřujı́cı́ hlavička obsahujı́ ukazatel, identifikujı́cı́ dalšı́ hlavičku a vzniká tak jakýsi
spojový seznam připojených hlaviček. Nejpoužı́vanějšı́ hlavičky jsou tyto: fragmentačnı́, za12
bezpečenı́ či směrovacı́. Sı́t’ové adresy narostly co do velikosti čtyřnásobně a nejčastěji se zapisujı́ po 2-bajtových blocı́ch oddělených dvojtečkou s vynechánı́m nulových segmentů, např.
2001:db8::1428:57ab.
2.6
Transportnı́ vrstva
V rodině TCP/IP rozlišujeme dva základnı́ typy transportnı́ch protokolů: TCP a UDP, oba
protokoly budou představeny v následujı́cı́ch kapitolách. Z pohledu sı́t’ové vrstvy nerozlišujeme
jednotlivé entity (programy, démony, atd.) sı́t’ového rozhranı́, ale pouze doručujeme mezi uzly
sı́tě. Entity v systému se připojujı́ k portům, které nejsou ničı́m jiným než čı́sly v rámci systému
a konkrétnı́ implementace jejich použitı́ závisı́ na operačnı́m systému, kdy např. u BSD či Unixu
se hojně užı́vajı́ sockety, což je jakási abstrakce nad soubory. Ve světě Internetu se postupem
času zabydlely tzv. well-known (dobře známé) porty, jejichž seznam byl udržován v RFC dokumentech (poslednı́ RFC 1700), dnes došlo k přechodu k online databázi na stránkách organizace IANA. TCP (Transmission Control Protocol) přinášı́ možnost spolehlivého a spojovaného
kanálu, jenž se dı́ky udržovánı́ stavů dokáže vypořádat se ztrátou či modifikacı́ dat. Při přenosech
dat vzniká režie s tı́mto mechanismem spojená, kdy základnı́ ideou, která zajišt’uje spolehlivost
je kontinuálnı́ zası́lánı́ potvrzenı́ o přijatých datech.
2.6.1
Protokol UDP
Datagramová služba poskytuje základnı́ nadstavbu nad sı́t’ovými protokoly, stala se hojně
využı́vanou pro aplikace požadujı́cı́ rychlost a malou režii. Funguje nespolehlivě a nespojovaně,
vytvářı́ uživateli iluzi blokového přenosu a funguje bezstavově. Zajı́mavostı́ je kontrolnı́ součet,
který kromě samotné hlavičky a dat UDP paketu použı́vá i pseudohlavičku ze sı́t’ové vrstvy.
Atributy UDP paketu jsou znázorněny na obrázku.
Pakety obsahujı́ pouze dvoubajtová čı́sla zdrojového a cı́lového portu, dále délku hlavičky
protokolu UDP a již zmiňovaný kontrolnı́ součet. Pro ještě většı́ urychlenı́ existuje i modifikace
UDP protokolu tzv. protokol UDP Lite, který neobsahuje kontrolnı́ součet hlavičky a použı́vá
se např. při přenosu hlasu či videa, kde požadujeme pravidelné a rychlé doručovanı́.
2.6.2
Protokol TCP
Protokol TCP (Transmision Control Protocol) se stal úspěšným transportnı́m protokolem, který
se dokáže efektivně vypořádat s nespolehlivým a nespojovaným charakterem sı́t’ové vrstvy a na13
stolı́ uživateli systém, jenž garantuje plnou spolehlivost. Služba je poskytována na spojovaném
charakteru, tj. nejprve je navázáno spojenı́ mezi uzly, poté se přenášı́ data (obousměrně) a
nakonec se strany domluvı́ na ukončenı́ spojenı́ (i jednostranně). Garance spolehlivosti zahrnuje oblasti jako je výpadek paketu, duplicitnı́ doručenı́ a také špatné pořadı́ doručených dat.
Jak již bylo zmı́něno, spojenı́ se navazujı́ pouze dvoubodově, přı́jemce i odesı́latel je unikátnı́.
K atributům protokolu lze zmı́nit řı́zenı́ toku, kontinuálnı́ potvrzovánı́ přišedšı́ch dat, schopnost
vypořádat se s zahlcenı́m (prostřednictvı́m publikovánı́ velikosti okna) a tvorba iluze bajtové
roury, jež distribuuje informace po bajtech (nikoli po blocı́ch). Čtenáři se může vybavit lehká
paralela s přepojovánı́m okruhů, ale ve skutečnosti se jedná o softwarovou emulaci virtuálnı́ho
okruhu, o kterém vnitřnı́ uzly sı́t’ové infrastruktury nic nevědı́ a nebo ani nepodporujı́ tak vysokou vrstvu rodiny protokolů TCP/IP. Na samotnou strukturu paketů protokolu TCP můžete
nahlédnout na obrázku.
Úvod hlavičky je identický s bratrským protokolem UDP, obsahuje tedy zdrojový a cı́lový
port. Následuje pořadové čı́slo, udávajı́cı́ pozici v bajtové rouře, dalšı́m 4-bajtovým identifikátorem je potvrzovacı́ čı́slo, jenž dává najevo protistraně, které poslednı́ pořadové čı́slo
bylo úspěšně přijato. Určenı́ vlastnostı́ paketu, které lze považovat za platné se uplatňuje dı́ky
přepı́načům, např. ACK (potvrzovacı́ čı́slo je platné), PSH (okamžité odeslánı́ dat), RST (resetovánı́ spojenı́), SYN (žádost o sestavenı́ spojenı́) a FIN (žádost o ukončenı́ relace). Pro účely
řı́zenı́ toku obsahuje paket velikost okna, kterým si obě strany předávajı́ informaci o volném
mı́stu v zásobnı́cı́ch.
Na následujı́cı́m obrázku můžeme vidět průběh navazovánı́ spojenı́, přenos dat a ukončenı́
spojenı́. Navazovánı́ spojenı́ se realizuje pomocı́ tzv. třı́stavového handshaku“ (podánı́ ruky),
”
kdy žadatel o založenı́ spojenı́ (klient) sestavı́ paket se zapnutým přı́znakem SYN, náhodně vygeneruje sekvenčnı́ čı́slo a odešle paket cı́lovému počı́tači (server). Server po korektnı́m doručenı́
paketu sestavı́ obdobný paket, ale navı́c uvede přı́znak ACK, kterým potvrdı́ inicializačnı́ sekvenčnı́ čı́slo. Pokud je rámec správně doručen, je na klientovi, aby odeslal paket pouze s potvrzenı́m a spojenı́ dále považujeme za ustavené, na druhé straně je opakováno odeslánı́ paketu a
obě strany se řı́dı́ algoritmem pro délky vypršenı́ časového limitu. Při následném odesı́lánı́ dat
14
je vždy paket opatřen sekvenčnı́m čı́slem, které koresponduje s pozicı́ v bajtovém proudu, bráno
od inicializačnı́ho sekvenčnı́ho čı́sla. Druhá strana přenosového kanálu má za úkol odesı́lat potvrzenı́ o přišedčı́ch datech a to průběžně. Na závěr spojenı́ dojde k vyžádánı́ ukončenı́ z jedné
ze stran, zmı́něná strana odešle rámec se zapnutým přı́znakem FIN a korektnı́m sekvenčnı́m
čı́slem. Po doručenı́ potvrzenı́ od druhé strany se kanál stává pouze jednosměrným a po opakovánı́ stejného kroku stranou druhou spojenı́ definitivně zaniká jako ukončené. Během celého
přenosu je potvrzovacı́ čı́slo vždy o jedna většı́ než je přišı́dšı́ sekvenčnı́ čı́slo.
15
Pasivnı́ sı́t’ové analyzátory
3.1
Definice
Pasivnı́m sı́t’ovým analyzátorem rozumı́me software, jenž je zaměřený na rozbor sı́t’ové komunikace na základě odchycených záznamů paketů ze sı́t’ové karty bez jakékoliv modifikace
přenášených dat. Data jsou ukládána do binárnı́ch souborů různých formátů, mezi nejznámějšı́
formáty patřı́: pcap, pcapng či cap (Sun Microsystems, Microsoft Network Monitor). Úkolem
analyzátoru je načı́st odchycená data a dle vrstvy sı́t’ového protokolu vyhodnotit hlavičku a odeslat vrstvě vyššı́, pokud je v datech zachycena. Takto mohou z odchycených rámců na úrovni linkové vrstvy vznikat např. TCP spojenı́, na nichž je kupřı́kladu provozován hojně užı́vaných protokol HTTP. Schopnosti analyzátoru lze klasifikovat dle několika metrik: přı́tomnost grafického
rozhranı́ (GUI), množina podporovaných protokolů na vrstvách sı́t’ového modelu TCP/IP či
přı́tomnost statistických výstupů.
Při komunikaci se sı́t’ová karta chová tı́m způsobem, že na základě své hardwarové adresy
přijı́má pouze data pro ni určená a předává je jádru operačnı́ho systému. V promiskuitnı́m módu
jsou ale přijı́mána všechna data, bez ohledu na adresu skutečného adresáta. Typicky jsou pro
zapnutı́ promiskuitnı́ho módu nutná práva superuživatele v přı́padě operačnı́ho systému UNIX
a metoda je základem pro zı́skávánı́ dat pro všechny druhy sı́t’ových analyzátorů.
Na základě definice a deklarovaných kritériı́ jsem zvolil následujı́cı́ analyzátory pro bližšı́
popis: Tcpdump, Tcpflow, Wireshark a Netgrind.
3.2
Tcpdump
Nejstaršı́m analyzátorem z vybrané trojice je Tcpdump, jenž spatřil světlo světa na počátku
90. let 20. stoletı́. Tcpdump je typicky součástı́ každé mutace systému UNIX a funguje pouze
v konzolovém režimu. Program umı́ pracovat s uloženými daty v souboru, umı́ sám ukládat data
do takového souboru (formát pcap) a výhodou pro uživatele je i promiskuitnı́ mód, fungujı́cı́
s daty v reálném čase. Ve volbách je nabı́zena široká paleta přepı́načů pro volbu úrovně výpisů
zobrazených dat, možnosti konverze IP adres na DNS záznamy či rychlosti užitı́ protokolových
modulů. Data se dajı́ lehce filtrovat dle třech základnı́ch kategoriı́: typ, směr a protokol. Pro
ilustraci bude lepšı́ ukázat možnosti filtrovánı́ na přı́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 nativně solidnı́ množinu protokolů, jejichž data dokáže v textové formě prezentovat. K vı́ce specifickým protokolům lze zařadit: protokoly pro sdı́lenı́ souborů
jako NFS či SMB, Kip AppleTalk, IP fragmentace nebo přenosový 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 vloženém přı́kladu je ukázána funkce prezentovánı́ vypsaných dat, prvnı́ 2 řádky se týkajı́
protokolu ARP, který převádı́ virtuálnı́ adresy sı́t’ové vrstvy na adresy fyzické (MAC). Nejprve
se prvek sı́tě s adresou 192.168.2.1 ptá pomocı́ broadcastu na fyzickou adresu 192.168.2.1 a
následně dostává také odpověd’. Třetı́ řádek ukazuje segment TCP spojenı́, které je HTTP
požadavkem, jedná se o druhý paket ze třı́stavového navázánı́ spojenı́.
3.3
Tcpflow
Jako o druhém analyzátoru se zmı́nı́m o programu Tcpflow, který vznikl na přelomu tisı́ciletı́.
Program za pomoci promiskuitnı́ho módu načı́tá pakety a rekonstruuje jednotlivá TCP spojenı́.
Spojenı́ jsou ukládána ve výchozı́m nastavenı́ do souborů ve formátu, kde figurujı́ zdrojová a
cı́lová IP adresa a také porty. Obsahem souborů jsou přenášená data po spojenı́ch, program
bohužel nepodporuje IP fragmentaci a poslednı́ uvolněná stabilnı́ verze se datuje do roku 2003.
Podobně jako v přı́padě předchozı́ho představeného programu umožňuje Tcpflow filtrovat data
za pomoci výrazů. Z filtrovacı́ škály bych zmı́nil možnost filtrovat na základe doménového jména
uzlu, IP adresy uzlu, velikosti datové rámce či ethernetového typu paketu. Program je co do
velikosti minimalistický a jeho funkčnost je zahrnuta v programu Wireshark, kde má uživatel
možnost zobrazit data přenášená po TCP spojenı́. Program nenı́ postavený čistě na spojenı́
TCP, ale poradı́ si i s daty přenášenými po protokolu UDP či ICMP. Výstupnı́ formát si můžete
prohlédnout na přiložené uká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 považovaný za nejlepšı́ open-source sı́t’ový analyzátor s grafickou nadstavbou. Nabı́zı́ širokou podporu sı́t’ových protokolů, funguje na široké množině operačnı́ch systémů
počı́naje UNIX, přes BSD, Solaris a konče operačnı́m systémem Windows. Základem je konzolový analyzátor TShark, jenž se svými výpisy do konzole podobá programu tcpdump, ale nabı́zı́
širšı́ portfolio protokolů. Wireshark dokáže přinutit fungovat sı́tovou kartu počı́tače v promiskuitnı́m módu a tı́m zı́skává pakety ze sı́tě. Zı́skaná data je možno filtrovat, přeskupovat a
ukládat do formátu pcap či dalšı́ch podporovaných. Grafická nadstavba napsaná v GTK+ nabı́zı́
přehledný seznam paketů, přinášı́ možnost zabarvovánı́, filtrovánı́ dle atributů paketů a v ne17
poslednı́ řadě přinášı́ možnost zapojenı́ vlastnı́ho zásuvného modulu či zapojenı́ modulu jiného,
než je ve výchozı́m nastavenı́ vybrán. Za největšı́ přednost programu považuji bohatou paletu
statistických výstupů, zobrazenı́ dat přenesených v rámci TCP spojenı́ a přehledné zobrazenı́
vrstev sı́t’ového modelu u jednotlivých rámců. Ukázku programu lze nalézt na obrázku.
3.4.1
Historie
Historie programu se datuje do roku 1997, kdy Gerald Combs začal vyvı́jet předka dnešnı́ho programu pod jménem Ethereal. Po několika přerušenı́ch vývoje v roce 1998 spojil Gerard Combs
své sı́ly s Richardem Sharpem a odstartovali vývoj dekódovacı́ch modulů, specifických pro jednotlivé protokoly vrstevnatého modelu architektury TCP/IP. V roce 2006 došlo k přejmenovánı́
na nynějšı́ jméno a po deseti letech vývoje byla v roce 2008 uvolněna verze 1.0, která je
považována za prvnı́ kompletnı́ verzi, pokrývajı́cı́ základnı́ množinu protokolů a autoři ji představili téhož roku na konferenci SharkFest.
3.4.2
Filtrovánı́
Filtrovánı́ dat nabı́zı́ uživateli jednak přednastavené filtrovacı́ profily typu: TCP only“, no ARP
”
”
and no DNS“. V zásadě lze vytvořit libovolnou logickou klauzuli pomocı́ předdefinovaných atributů a základnı́ch operandů, jako je porovnánı́, přı́slušnost do množiny, atd. Kritéria lze skládat
z primitivnı́ch atributů, jako je IP adresa zdrojového počı́tače, ale zabrousit lze i do mnohem detailnějšı́ch atributů. Jako zajı́mavé atributy, které lze použı́t při specifikaci podmı́nky,
mohu uvést jméno přı́kazu protokolu SMTP, velikost přenášeného obrázku formátu PNG pomocı́
HTTP či přezdı́vku adresáta přenosového protokolu Yahoo Messanger.
18
3.4.3
Analýza rámců
Analýza přenesených rámců je řı́zena stromem dekodérů, které dle atributů vrstevnatého modelu
rozlišujı́ dekodér, který bude užit. Základnı́mi atributy pro detekci jsou ethertype“ na linkové
”
vrstvě, IP protokol na vrstvě sı́t’ové a zdrojový a cı́lový port na vrstvě transportnı́ jak u TCP,
tak i UDP. Dekodéry užité na rozklad lze měnit a Wireshark nabı́zı́ i možnost naprogramovánı́
takového modulu. Pro úspěch takto velkého programu je zmı́něná část programu klı́čová, kdy
v dnešnı́ době vı́ce jako 500 vývojářů přispı́vá a programuje rozšı́řenı́, která jsou nezávislá na
ostatnı́ch a komunita udržuje bohatou dokumentaci návodů, jak postupovat při vývoji.
3.4.4
Statistické komponenty
Statistickou komponentu Wiresharku považuji za nejvı́ce přı́nosnou část programu. K základnı́m
jednotkám patřı́ sumář obsahujı́cı́ informace o odchycených datech a informace o hierarchii
použitých protokolů během komunikace. Dalšı́m užitečným nástrojem je přehled komunikacı́, kde
na základě protokolů nalezneme informace mezi kterými uzly se přenášela data. Mezi grafické
výstupy musı́m zmı́nit histogram velikosti paketů a velmi názorný Graf toků, jenž v průběhu času
vizualizuje toky dat v obou směrech komunikace. Pro protokol TCP jsou v nabı́dce grafy střednı́
doby obrátky, velikosti přenášených dat v průběhu času či seznamu požadavků na zobrazené
webové stránky.
3.5
Netgrind
Netgrind vznikl jako jednoduchý, srozumitelný a pomocný program při analýze zejména protokolu HTTP a vrstev, které ležı́ pod nı́m. Autorem je vedoucı́ mé práce Mgr. Martin Mareš,
Ph.D. a stal se inspiracı́ pro téma mojı́ práce. Konzolový program nabı́zı́ statistiky o správně
zpracovaných, špatných a neplatných paketech na vrstvách sı́t’ového modelu a jako hlavnı́ produkt prezentuje v přehledném výpisu HTTP spojenı́, detailnı́ informace o adresách, portech,
počtech přenesených dat, URL a typy dokumentu dle standardu rozšı́řenı́ MIME. Po nastavenı́
můžeme nechat zapsat statické informace o jednotlivých přenosech do adresáře pro budoucı́ zobrazenı́ pomocı́ grafového kreslı́cı́ho nástroje gnuplot. K programu je přibalena množina skriptů
v jazyce Perl, které transformujı́ nashromážděné statistiky a vykreslujı́ výstupnı́ grafy. Grafy se
týkajı́ počtu aktuálnı́ch spojenı́ v čase, velikosti přenášených dat v čase či délce čekánı́ HTTP
požadavku.
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
Výstup z programu Netgrind poskytne přehledné informace o jednotlivých HTTP požadavcı́ch, kdy byly uskutečněny v čase, z jakých IP adres a portů došlo k přenosu, dále zı́skáme cenné
informace o velikosti přenesených datech, době vyřı́zenı́ požadavku, MIME typu a v neposlednı́
řadě také požadovaný soubor, jenž byl vyžádat po HTTP démonovi.
19
Sı́t’ový analyzátor NEPAL
4.1
Představenı́
Vlastnı́ sı́t’ový pasivnı́ analyzátor Network Passive Analyser (zkratka NEPAL) byl vyvinut pro
účel bakalářské práce. Program na svém vstupu akceptuje záznamy paketů uložených v souboru
ve formátu PCAP. Program je navržený jako modulárnı́ systém, kdy mezi jednotlivými moduly
putujı́ datové objekty různých třı́d. Každý modul má definovanou množinu typů vstupnı́ch a
výstupnı́ch objektů, kdy po průchodu dat modulem nastane jedna z událostı́, jež modul definuje.
Dı́ky zmı́něnému aparátu je možné pomocı́ skriptů, napsaných v jazyce Python[6], napojit
výstup na libovolné moduly a tı́m sestavit celou škálu funkčnı́ch programů, týkajı́cı́ch se různé
oblasti zpracovánı́ dat ze sı́tě. Moduly jsou napsané v jazycı́ch C a Python, mohou se mezi sebou
libovolně kombinovat a jako pojı́tko mezi oběma světy je užit nástroj SWIG[7], který obaluje kód
psaný v jazyce C do jazyků vyššı́ch, mimo jiné i do Pythonu. Software implementuje načı́tánı́
základnı́ch protokolů TCP/IP a jako ukázkové specifické moduly obsahuje modul pro zobrazenı́
požadavků protokolu HTTP, modul ARP/RARP včetně zobrazovánı́ výrobců sı́t’ových karet,
statistický modul (napsaný v Pythonu) a modul pro zobrazovánı́ DNS požadavků a odpovědı́.
4.2
Zapojenı́ programu
Zapojenı́ práce jednotlivých modulů může čtenář nahlédnout na následujı́cı́m obrázku.
20
Pomocı́ obdélnı́ků různých barev jsou vyznačeny moduly, atributy u modulů symbolizujı́
vybrané události, které může modul vyvolat a na které se následně může dalšı́ modul zavěsit.
Každý modul disponuje zásobnı́kem událostı́, kde se registrujı́ dalšı́ vstupnı́ moduly. Popsaným
způsobem je dosažena modularita, schopnost zapojit vlastnı́ modul na sestavu předešlých a
systém poskytuje základnı́ transparentnı́ programátorské rozhranı́ pro napojovánı́ modulů. V obrázku jsou zmı́něná napojenı́ vyjádřena šipkami a kruh symbolizuje putujı́cı́ datový objekt. Na
zapojenı́ stačı́ pouze zaregistrovat vstupnı́ metodu do zásobnı́ku událostı́ vybraného modulu a
program se již postará o předánı́ dat.
4.3
Datový objekt
Datový objekt je základnı́ jednotkou informacı́ přenášenou mezi moduly. Při svém návrhu byl
kladen důraz na co největšı́ univerzálnost na straně jedné a na co nejúspornějšı́ a nejrychlejšı́
řešenı́ na straně druhé. Datový objekt se stal univerzálnı́ strukturou, do které lze ukládat data
různých typů (viz následujı́cı́ tabulka).
Typ atributu
INT
TIME
IPV4
IPV6
STRING
ARRAY
MAC48
DOBJ
VOIDPTR
Délka
4B
8B
4B
16 B
—
—
6B
4B
4B
Popis typu atributu
celé nezáporné čı́slo v rozsahu [0,4 294 967 295]
uloženı́ času s přesnostı́ na nanosekundy
IPv4 sı́t’ová adresa
IPv6 sı́t’ová adresa
řetězec ASCII znaků
pole bajtů
MAC adresa
ukazatel na jiný datový objekt
všeobecný ukazatel
Součástı́ datového objektu je také zásobnı́k událostı́, do kterého je možné registrovat metody,
které se zavolajı́, když nastane událost. Zmı́něná vlastnost je napřı́klad použita u TCP spojenı́,
u něhož nastane událost, signalizujı́cı́ přenesená data. U datových objektů rozlišujeme jejich
třı́dy, na vstupu modulů si zpravidla moduly kontrolujı́ třı́dy vstupnı́ch dat a rozhodujı́ se,
zda je zpracujı́. V průběhu průchodu je možné za běhu měnit třı́du datového objektu, mohou
se přidávat atributy a často se tak při průchodu moduly rodiny TCP/IP i děje. V následujı́cı́
kapitole zı́skáte přehled, jaké třı́dy objektu vznikajı́ v jakých modulech, jaké třı́dy moduly
podporujı́ na svém vstupu a také jaké vznikajı́ události.
4.4
Představenı́ modulů
Program pracuje jako sı́t’ový analyzátor nad rodinou protokolů TCP/IP a implementuje moduly, které odpovı́dajı́ protokolům sı́t’ového modelu. Pro ukázku specifických aplikacı́ je přidána
množina modulů, které se týkajı́ problematiky převodu fyzických a sı́t’ových adres, protokolu
HTTP pro přenos dokumentů či protokolu DNS, který mimo jiné převádı́ doménová jména na
sı́t’ové adresy (at’ už verze 4 či 6). Jako demonstrace kombinovánı́ modulů v obou jazycı́ch jsem
naprogramoval grafový modul v jazyce Python, jenž užı́vá velmi dobře propracovanou knihovnu
21
pro výstupy grafů pod jménem Matplotlib[8]. V následujı́cı́ tabulce může čtenář nahlédnout do
přehledu implementovaných modulů v programovacı́m jazyce C a v dalšı́ch sekcı́ch jsou moduly
charakterizovány včetně atributů objektů, které při průchodu těmito moduly vznikajı́.
Jméno 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
Výstupnı́ 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 modulů
4.4.1
Modul PCAP
Vstupnı́ modul každého zapojenı́ načı́tá sekvenčně uložené a přenášené rámce, modul využı́vá
služeb knihovny PCAP[9], jež ukládá do souboru s přı́ponou pcap celé rámce v binárnı́ podobě.
V hlavičce takového souboru jsou deklarovány atributy o maximálnı́ délce zachycených rámců,
časovém posunu oproti času nultému polednı́ku či typu linkové vrstvy. Po průchodu modulem
vzniká datový objekt, jenž nese binárnı́ data po médiu přenášená, informace o původnı́ a odchycené velikosti a v poslednı́ řadě také čas průchodu paketu sı́t’ovou kartou. O detailech atributů
vás seznámı́ následujı́cı́ tabulka, po nı́ž následuje tabulka s výpisem událostı́.
Atribut
pcap frame
pcap time
pcap origlen
pcap packet
Typ
INT
TIME
INT
ARRAY
Popis atributu
pořadové čı́slo paketu
datum odchycenı́ paketu
původnı́ velikost odchyceného rámce
data odchyceného paketu
22
Událost Popis události
Typ objektu
packet
vznik nového rámce PCAP packet
4.4.2
Modul Ethernet
Ethernetový modul se stará o správné načtenı́ atributů pro datový objekt Ethernet packet.
Ve své podstatě podporuje rodina protokolů TCP/IP velké portfolio linkových protokolů, ale
v průběhu času se Ethernet stal nejpoužı́vanějšı́m a nejrozšı́řenějšı́m. Vı́ce informacı́ o modulu
přinesou dvě bezprostředně následujı́cı́ tabulky.
Atribut Typ
eth smac MAC48
eth tmac MAC48
INT
eth type
Událost
packet
drop
4.4.3
Popis atributu
zdrojová MAC adresa ve formátu MAC-48
cı́lová MAC adresa ve formátu MAC-48
typ protokolu vyššı́ vrstvy
0x0800 pro IPv4, 0x86DD pro IPv6, 0x0806 pro ARP
Popis události
Typ objektu
vznik nového paketu
Ethernet packet
zahozenı́ nekompatibilnı́ho paketu
PCAP packet
(např. z důvodu nekompletnosti paketu při odchycenı́)
Modul ARP
Modul dekóduje hlavičky paketů protokolu ARP (Address resolution protocol – RFC 826[11]) a
protokolu RARP (Reverse address resolution protocol – RFC 903[12]) a odesı́lá je spřátelenému
modulu pro jejich vizualizaci. Tabulka specifikuje atributy objektu, modul nedisponuje žádnými
událostmi, všechna data jsou automaticky posunuta ná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 hardwarové adresy
(0x0001 pro Ethernet II)
typ sı́t’ového protokolu
0x0800 pro IPv4, 0x86DD pro IPv6
typ požadavku
0x0001 pro ARP dotaz, 0x0002 pro ARP odpověd’
0x0003 pro RARP dotaz, 0x0004 pro RARP odpověd’
fyzická adresa odesı́latele
(typ na základě délky, pro délku 6 typ MAC48, ARRAY jinak)
sı́t’ová adresa odesı́latele
(typ na základě atributu arp ptype)
fyzická adresa přı́jemce
(typ na základě délky, pro délku 6 typ MAC48, ARRAY jinak)
sı́t’ová adresa přı́jemce
(typ na základě atributu arp ptype)
23
4.4.4
Modul ARP view
Úkolem modulu ARP view nenı́ nic jiného než prezentovat odchycené datové objekty typu
ARP packet. Modul má zabudované rozšı́řenı́ pro prezentovánı́ výrobce sı́t’ové karty, ke které
se váže odchycená MAC adresa, a to v podobě tzv. OUI-48 (Organizationally unique identifier).
Seznam výrobců je uveden na stránkách IEEE[4] a součástı́ bakalářské práce je i program pro
staženı́ a transformaci dat pod jménem: oui.py, který stahuje z webových stránek organizace
IEEE aktuálnı́ databázi přidělených rozsahů MAC adres jednotlivých výrobců a ukládá je do
souboru pro modul. Výpis z modulu je přiložen v ukázkách programu.
4.4.5
Modul IPv4
Ze jména modulu vyplývá jeho funkce, modul pouze dekóduje datové objekty typu IPv4 packet
a veškerá data jsou odesı́lána modulu IP reassembler, který rozhodne o tom, zda je nutné
zakládat IP reassembly nebo zda jsou data nefragmentovaná a stačı́ je odeslat vyššı́ vrstvě.
Odesı́lánı́ datových objektů pro jejich kontrolu je činěno automaticky, nenı́ nutné registrovat
událost. Specifikace paketu byla poprvé představena v RFC 791[13]. Následujı́cı́ dvě tabulky
přinášejı́ vı́ce informacı́ o vzniklých objektech a o udá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
Událost
drop
4.4.6
Popis atributu
verze sı́t’ového protokolu
délka hlavičky paketu v bajtech
typ přenášené služby v datech
celková délka paketu v bajtech
identifikace pro účely fragmentace
flagy spolu s fragmentačnı́m offsetem
TTL – životnost paketu
typ protokolu vyššı́ vrstvy
0x0006 pro TCP, 0x0011 pro UDP
kontrolnı́ součet IP paketu
zdrojová sı́t’ová adresa
cı́lová sı́t’ová adresa
Popis události
Typ objektu
zahozenı́ nekompatibilnı́ho paketu Ethernet packet
Modul IPv6
Nová verze sı́t’ového protokolu se od svého sourozence co do formátu hlavičky značně odlišuje,
vznikla úplně nová koncepce přı́davných hlaviček ve formě spojového seznamu, který rozšiřuje
hlavičku základnı́, jež v sobě nese pouze nutné informace. Hlaviček najdeme ve specifikaci celkem
mnoho a jsou podporované 4 základnı́: Hop-by-Hop, cı́lová, fragmentačnı́ a trasovacı́. K ostatnı́m
hlavičkám můžeme přistupovat pomocı́ atributů, které jsou specifikované na konci následujı́cı́
tabulky, po nı́ž následuje přehled událostı́. Specifikace paketu a protokolu nalezneme v RFC
2460[14], podobně jako v přı́padě předchozı́ho modulu se modul stará o dekódová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]
Událost
drop
4.4.7
INT
IPV6
IPV6
ARRAY
ARRAY
INT
INT
ARRAY
INT
INT
INT
ARRAY
INT
Popis atributu
verze sı́t’ového protokolu (6 pro IPv6)
typ přenášené služby v datech
identifikátor proudu dat (Flow label)
celková délka paketu v bajtech
identifikátor dalšı́ hlavičky (po přečtenı́ všech přı́davných)
44 pro fragmentaci, 17 pro UDP, 6 pro TCP (RFC[14])
TTL – životnost paketu
volby rozšı́řenı́ Hop-by-Hop
volby pro cı́lové rozšı́řenı́
typ trasovánı́ rozšiřujı́cı́ hlavičky
zbývajı́cı́ počet segmentů trasovánı́
volby trasovacı́ rozšiřujı́cı́ hlavičky
offset fragmentovaného paketu
flag fragmentačnı́ rozš. hlavičky
identifikace v rámci fragmentace
rozšiřujı́cı́ hlavičky typu t
typ i-té rozšiřujı́cı́ hlavičky
Popis události
Typ objektu
zahozenı́ nekompatibilnı́ho paketu Ethernet packet
Modul IP reassembler
Úkolem modulu je načı́tat vstupnı́ pakety IPv4 packet a IPv6 packet a na základě atributů
se rozhodovat, zda budou pakety fragmentované či nikoliv. V přı́padě nefragmentovaných dat
okamžitě nastane událost, signalizujı́cı́ vznik nového paketu. V opačném přı́padě dojde k založenı́
objektu typu IP reassembly, který představuje datagram, který vzniká skládánı́m fragmentů
(obou verzı́ sı́t’. protokolu). Pokud uživatele zajı́majı́ pouze kompletnı́ IP pakety, nenı́ nutné s IP
reassembly pracovat. Na druhé straně pokud chceme programovat modul, který se jakýmkoliv
způsobem dotýká IP fragmentace, máme možnost se k jednotlivým procházejı́cı́m fragmentům
dostat. Skladba fragmentů probı́há spojovánı́m fragmentů do seznamu, který když se stane
kompletnı́m, tak dojde k události vzniku nového datového objektu. Jako obrana před velkým
počtem otevřených IP datagramů sloužı́ časový limit, který aktivuje událost conn timeout,
pokud do IP datagramu nepřibyl po určitou dobu žádný paket.
Atribut
ipreass time
ipreass
ipreass
ipreass
ipreass
Typ
TIME
IPV4
saddr
IPV6
IPV4
daddr
IPV6
ident
INT
version INT
Popis atributu
čas založenı́ IP reassembly
identifikace IP reassembly
rozlišenı́ mezi verzemi 4 a 6
25
Událost
Popis události
vznik nefragmentovaného IP paketu
packet
zahozenı́ nekompatibilnı́ho paketu
drop
conn create
založenı́ nového IP datagramu
conn close
korektnı́ uzavřenı́ IP datagramu
conn timeout vypršenı́ časové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 tvořı́ jenom jakousi malou nadstavbu nad sı́t’ovým protokolem, proto nenı́ nutné
dlouze vysvětlovat fungovánı́ a nahlédneme rovnou na popis atributů modulu a událostı́, jež
mohou nastat. Vı́ce informacı́ můžete čerpat v RFC 768[15].
Atribut
udp sport
udp dport
udp length
udp checksum
Událost
packet
drop
4.4.9
Typ
INT
INT
INT
INT
Popis atributu
zdrojový port
cı́lový port
délka nesených dat
kontrolnı́ součet hlavičky
Popis události
Typ objektu
UDP packet
zahozenı́ nekompatibilnı́ho paketu IPv4 packet
IPv6 packet
Modul TCP
Modul má za úkol dekódovat hlavičky datových objektů typu IPv4 packet a IPv6 packet,
všechny atributy vzniklého datového objektu spolu s událostmi naleznete ve dvou tabulkách.
Dalšı́ informace lze čerpat 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
zdrojový port
cı́lový port
pořadové čı́slo v bajtovém proudu
potvrzovacı́ čı́slo
délka hlavičky v bajtech
flagy pro jednotlivé volby
velikost okna
kontrolnı́ součet hlavičky
urgentnı́ ukazatel
dalšı́ volby
26
Událost
packet
drop
4.4.10
Popis události
Typ objektu
TCP packet
zahozenı́ nekompatibilnı́ho paketu IPv4 packet
IPv6 packet
Modul TCP flow
Nejsložitějšı́ modul, implementovaný v program, je bezpochyby modul pro rekonstrukci spojenı́,
pracujı́cı́ s oběma verzemi sı́t’ového protokolu. Na vstupu je TCP packet a při korektnı́m
navázánı́ spojenı́ vzniká datový objekt typu TCP flow. Objekt v sobě uchovává informace
o zdrojovém a cı́lovém portu a také o adresách, mezi kterým se přenos uskutečňuje. Zmı́něný
objekt disponuje zásobnı́kem událostı́, ve kterém nastává událost, signalizujı́cı́ přenášená data
po spojenı́ typu TCP data. Stejně jako v přı́padě modulu IP reassembler je činnost spojenı́
monitorována a nečinná spojenı́ jsou po uplynutı́ časového limitu uzavı́rána. Přehled obou typů
datových objektů následuje na přiložených tabulkách.
Atribut
Typ
IPV4
tcpflow saddr
IPV6
IPV4
tcpflow daddr
IPV6
tcpflow sport INT
tcpflow dport INT
4.4.11
Popis atributu
zdrojová adresa
cı́lová adresa
zdrojový port
cı́lový port
Atribut
tcpdata time
tcpdata direct
tcpdata data
tcpdata conn
Typ
TIME
INT
ARRAY
DOBJ
Popis atributu
čas vzniku přenesených dat
směr přenesených dat po spojenı́
data přenesená po spojenı́
ukazatel na datový objekt se spojenı́m
Událost
conn create
conn reset
conn close
conn timeout
data
Popis události
vznik nového spojenı́
resetovánı́ spojenı́
korektnı́ uzavřenı́ spojenı́
vypršenı́ časové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 dnešnı́ době těšı́ obrovské oblibě, spousta
doposavad desktopových aplikacı́ se zabydlela ve formě webových stránek (kancelářský balı́k,
webmail, atd.), vznikly masivně se rozvı́jejı́cı́ sociálnı́ sı́tě a přibývá na dynamičnosti webových
stránek. Modul HTTP rekonstruuje transfery, zaznamenává dokumenty, které si uživatel vybere
a dopočı́tává délku vyřı́zenı́ požadavků. S přı́kladem výstupu modulu se můžeme seznámit
27
v dalšı́ části práce a jedna sekce kapitoly je věnovaná popisu, jak se takový modul musı́ správně
napojit, aby poskytoval vytoužené výsledky. Specifikace protokolu je definována v RFC 2616[17].
4.4.12
Modul DNS
Modul DNS opět prezentuje nashromážděné informace, do práce byl modul zahrnut hlavně z hlediska demonstrace univerzálnosti návrhu programu, kdy modul pracuje s vı́ce typy vstupnı́ch datových objektů, v přı́padě DNS se jedná o UDP datagram a TCP flow. Modul se vypořádá
s hlavnı́ množinou typů požadavků a odpovědı́: CNAME (kanonické jméno), NS (name server),
A (IPv4 adresa), AAAA (IPv6 adresa), SOA (záznam autority), TXT (textový řetězec), RRSIG
(elektronický podpis). Podobně jako v přı́padě výstupu modulu HTTP i tento modul dopočı́tává
dobu, za jakou došlo v vyřı́zenı́ požadavku. Ukázku práce modulu naleznete v dalšı́ch kapitolách.
28
Ovládánı́ programu NEPAL
5.1
Překlad programu
Program je napsaný v jazycı́ch C a Python a je určený primárně pro operačnı́ systém Unix,
pro který je vytvořený Makefile. Program spolupracuje s knihovnou LibUCW[5] (aktuálnı́ verze
4.0) a s programem SWIG[7] (aktuálnı́ verze 1.3.40-r1). V jazyce Python nejsou užı́vány žádné
složité konstrukce a otestována je funkčnost ve verzi 2.6 a vyššı́. Jako nutná prerekvizita pro
překlad programu pomocı́ GCC[10] je umı́stěnı́ knihovny LibUCW, které se detekuje pomocı́
známého programu pkg-config (v souboru Makefile naleznete cestu ke knihovně, kterou je
nutné pro překlad správně vyplnit). Po překladu vznikne dynamická knihovna, kterou lze již
importovat z prostředı́ jazyka Python, jenž spouštı́ připravené ukázkové skripty.
5.2
Ukázka programu
#!/usr/bin/env python2.6
from nepal import *
import sys
def entrypoint(file):
bind module("PCAP", "ETH", "packet") # registrace module Ethernet na vznik nového paketu
bind func("ETH", meth dispatcher, "packet") # registrace funkce pro filtrovánı́ paketů
bind module("ARP", "ARPVIEW", "packet") # registrace vizualizačnı́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 <filename>"
else:
entrypoint(sys.argv[1])
Po představenı́ modulů, datových objektů a událostı́ nastal konečně čas na představenı́ jednoduchého zapojenı́ našeho analyzátoru. Jako prvnı́ najdete registrovánı́ funkcı́ do zásobnı́ků
událostı́ pro moduly, které budou řı́dit celý běh programu. Jak si můžete všimnout, docházı́ i k registrovánı́ našı́ metody, psané v Pythonu, která nastane pokud vznikne Ethernet packet. Po
vzniku paketu dojde k rozhodnutı́, zda se jedná o ARP paket a použije se metoda pro odeslánı́ datového objektu do dalšı́ho modulu. V demonstračnı́m skriptu jsou představeny všechny potřebné
29
metody pro naprogramovánı́ zapojenı́ a v následujı́cı́ kapitole bude specifikováno veškeré programátorské rozhranı́.
5.3
Ovládánı́ a programátorské rozhranı́
Jak bylo možno vidět z předchozı́ ukázky, skripty jsou řı́zeny množinou funkcı́, které pracujı́
s datovými objekty a zásobnı́ky událostı́. Čtenáři jistě neuniklo, že jádro programu je napsané
v jazyce C a pro jeho zpřı́stupněnı́ je k dispozici množina metod, představených 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
registrovánı́ události, vzniklé z modulu, prvnı́m
argumentem je zkratka modulu (viz. tabulka 4.1),
následuje ukazatel na funkci, jež má být zavolána
a poslednı́m argumentem je jméno události, na
kterou se má funkce zavěsit
registrovánı́ události, vzniklé z modulu, prvnı́m
argumentem je zkratka modulu (viz. 4.1),
následuje zkratka cı́lového modulu (dest module),
jenž má být zavolán a poslednı́m argumentem je
jméno události, na kterou se má funkce zavěsit
nastavenı́ informacı́ modulů, jejich specifikace
je v následujı́cı́ tabulce, prvnı́m argumentem je
jméno atributu, druhým je typ atributu dle definice v kapitole 4.3 a poslednı́ je hodnota, která
odpovı́dá attr type a bude představena
zı́skánı́ atributu jménem attr name z objektu
modifikace atributu attr name hodnotou value
metoda pro vloženı́ nové hodnoty typu INT
metoda pro vloženı́ nové hodnoty času
metoda pro vloženı́ nové IPv4 adresy
metoda pro vloženı́ nové IPv6 adresy
metoda pro vloženı́ nového řetězce
metoda pro vloženı́ nového pole
metoda pro vloženı́ nové hodnoty MAC adresy
metoda pro vloženı́ nového obecného ukazatele
registrovánı́ funkce func, pokud nastane na datovém objektu událost event
registrace modulu, jenž se použije pro událost
event
přidánı́ reference na datový objekt
odebránı́ reference na datový objekt
zavolánı́ hlavnı́ho modulu s jménem vstupnı́ho
souboru jako argumentem
odeslánı́ datového objektu na zpracovánı́ modulem jménem module (např. TCP nebo ARP)
30
Pro spojenı́ světů obou programovacı́ch jazyků je důležité specifikovat korespondenci jednotlivých typů atributů. Jejich vztah naleznete v následujı́cı́ tabulce. U přiřazenı́ a metody setnew
ukládáme do datového objektu hodnotu ve formě Python objektu, který musı́ odpovı́dat typem
atributu, který 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
dvouprvkové pole ve formátu [sekundy, milisekundy] (obojı́ typu Long)
Python String ve standardnı́m formátu a.b.c.d (RFC 791[13])
Python String ve standardnı́m formátu dle RFC 2460[14]
Python String
Python ByteArray (novinka ve verzi Pythonu 2.6)
Python String ve formátu aa:bb:cc:dd:ee:ff
Python Long, umožňuje zapouzdřit void ukazatel
Pro ilustraci přidávám pár ukázek užitı́ přiřazenı́ hodnot a jejich zı́skávánı́:
obj.pcap frame ... zı́skánı́ pořadového čı́sla paketu typu Python Long
obj.smac = "00:0e:2e:aa:aa:aa"... nastavenı́ nové zdrojové MAC adresy objektu
obj.set string("pcap popis", "DUPL") ... uloženı́ nového atributu
obj.pcap popis = 123 ... chyba, špatný typ objektu
obj.set int("pcap popis", 12345 ... úspěšné přepsánı́ atributu objektu
data = obj.pcap packet ... zı́skánı́ dat paketu typu Python ByteArray
Pro úplnost specifikace rozhranı́ je nutné ještě dodat seznam atributů modulů, které lze
nastavovat pomocı́ již představené metody set info. Přiložená tabulka ukazuje všechny možné
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
Počet paketů prošlých modulem PCAP
Počet správně zpracovaných paketů modulem Ethernet
Počet zahozených paketů modulem Ethernet
Počet zahozených paketů modulem ARP
Cesta k souboru s OUI jmény výrobců
Počet správně zpracovaných paketů modulem ARP view
Počet správně zpracovaných paketů modulem IPv4
Počet zahozených paketů modulem IPv4
Zapnutı́ kontrolnı́ho součtu u IPv4 packet
Počet správně zpracovaných paketů modulem IPv6
Počet zahozených paketů modulem IPv6
Časový limit pro vypršenı́ IP datagramu a TCP spojenı́
Zapnutı́ kontrolnı́ho součtu u UDP packet
Počet správně zpracovaných paketů modulem TCP
Počet zahozených paketů modulem TCP
31
module tcp dupl
Počet duplicitnı́ch paketů prošlých modulem TCP
module tcp checksum
Zapnutı́ (1) či vypnutı́ (0) kont. součtu paketů v modulu TCP
module tcpflow treshold Počet paketů v zásobnı́ku spojenı́, při kterém rušeno spojenı́
5.4
Spouštěnı́ programu
Ukázková zapojenı́ jsou představena ve čtyřech připravených skriptech, každý se nacházı́ v samostatném souboru. Pro spuštěnı́ programu stačı́ spustit soubor s jediným argumentem, kterým
je jméno vstupnı́ho souboru. Přı́klad spuštěnı́ programu:
./script http.py ../../nepal-data/www pages.pcap
Dojde ke spuštěnı́ skriptu script http.py, který rekonstruuje HTTP spojenı́. Přehled všech
přiložených skriptů je znázorněn v následujı́cı́ tabulce.
Jméno souboru
script http.py
script graph.py
script arp.py
script dns.py
Popis skriptu
HTTP modul, rekonstuuje a vizualizuje HTTP spojenı́
Grafový modul, vytvářı́ grafy základnı́ch informacı́
ARP/RARP modul, zobrazuje (R)ARP požadavky a odpovědi
DNS modul, načı́tá a zobrazuje DNS dotazy a odpovědi
32
Ukázky z programu NEPAL
6.1
6.1.1
Modul pro HTTP
Prvnı́ přı́klad
Jako úvodnı́ ukázku vůbec jsem si vybral odchycená data, která jsou použita pro zobrazenı́
třech webových stránek, v prvnı́m sloupci výstupu můžete nalézt pravděpodobně nejzajı́mavějšı́
atribut, jedná se o dobu (v sekundách), za jakou byl požadavek na webovou stránku vyřı́zen.
Následuje návratový kód webového serveru, ve většině přı́padů je navrácen kód 200, jenž značı́
úspěšný požadavek. Kódem 304 označujeme stav, kdy již stránka byla v minulosti přenesena a
na serveru se dokument nezměnil, v tomto přı́padě nenı́ nutná data znovu přenášet, a proto je i
celkové délka přeneseného těla nastavena na nulovou hodnotu. Za zmı́nku stojı́ ještě návratový
kód 301, který nesignalizuje nic jiného než fakt, že stránka byla trvale přemı́stěna. Po atributu
kódu následujı́ zdrojová a cı́lová adresa a také zdrojový a cı́lový port. Do poslednı́ trojice atributů spadajı́: URL dorazu, typ obsahu (content-type) a celková velikost přenášených informacı́
v těle 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
Druhý přı́klad
Druhý přı́klad zapojenı́ modulu se týká opět zobrazovánı́ webových stránek, protentokrát jsem
nasimuloval velmi pomalou linku na úrovni modemu (28kb/s). Stránka obsahuje náhledy obrázků
a stejná odchycená data jsou užita i v ukázce modulu následujı́cı́ho. U stránek, které jsou stále
platné a uložené v cache, je doba odezvy menšı́ něž jedna sekunda, což ovšem nemůžeme tvrdit o přenášených obrázcı́ch, jejichž průměrná doba přenesenı́ tvořı́ dnes nepředstavitelných
1
Round-trip time – doba mezi odeslánı́m zprávy a jejı́m potvrzenı́m
33
30 sekund. I přes velikost v řádu desı́tek kilobajtů je přenos neskutečně pomalý a můžeme
s povděkem kvitovat, že se jedná o odezvy z dob dávno minulých.
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
Třetı́ přı́klad
Pro poslednı́ přı́klad v podkapitole jsem zvolil modul, který ukazuje využitı́ protokolu sı́t’ové
vrstvy ve verzi 6 a záznam komunikace vznikl po lokálnı́ sı́ti. Adresy jsou dlouhé co do výpisu,
proto jsem zvolil jejich menšı́ zkrácenı́ pro účely prezentovánı́ do bakalářské prá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
Grafový modul
Grafový modul nám dává základnı́ charakteristiku dat, která jsou v souboru odchyceném ze sı́tě.
Modul disponuje histogramem velikosti rámce, přenášeného po sı́t’ové infrastruktuře, dále máme
k dispozici koláčový graf, který udává poměr užitých transportnı́ch protokolů, a to jak co do
počtu rámců, tak i co do celkové velikosti dat tı́mto způsobem přenesených. Jako poslednı́ pár
grafových výstupů nabı́zı́ modul graf toků, tedy kolik paketů bylo přeneseno za jednotku času,
resp. kolik bajtů bylo přeneseno. Následujı́cı́ obrázky demonstrujı́ použitı́ modulu s popisem
dat, která byla vložena na vstupu.
Přı́klad 1: Flow graf velikosti přenášených dat
Přı́klad 1: Flow graf počtu přenášených dat
6.2.1
Prvnı́ přı́klad
Jako prvnı́ sadu vstupnı́ch dat jsem si připravil data, které jsou odchycené při navštı́venı́ stránek
www.devnull.cz, navštı́vil jsem stránku s ukázkovými fotografiemi a navı́c jsem nasimuloval
omezenı́ rychlosti podobné modemu (28kbit/s) pomocı́ Simple Queue u operačnı́ho systému
MikroTik RouterOS[18]. Prvnı́ dvojice grafů ukazuje průtok dat v čase, na prvnı́m obrázku je
krásně vidět průměrná rychlost 3.5 kB/s, na kterou byla linka degradována a druhý obrázek
fakticky koresponduje s prvnı́m, počı́tá však jenom počet paketů, které se v praxi velmi diametrálně lišı́ co do velikosti, počı́naje potvrzovacı́m paketem spojenı́ TCP a konče přenášenými
35
Přı́klad 1: Histogram velikosti přenášených rámců
(a)
(b)
Přı́klad 1: Podı́l užitých transportnı́ch protokolů
daty v takovém spojenı́. Následuje klasický histogram velikosti rámců, jenž dokazuje zmiňované
rozloženı́ velikosti paketů a najdete ho na třetı́m obrázku. Jako poslednı́ v sadě ukázek grafů
najdete koláčový graf, který reflektuje percentuálnı́ využitı́ transportnı́ch protokolů, at’ už co
do počtu paketů přenesených nebo co do velikosti dat. Z analýzy dat vyplývá, že se většina
přenosu odehrává po TCP, což reálně odpovı́dá přenosu webových stránek. Po protokolu UDP
docházı́ k přenosu hlavně DNS dotazů a jejich odpovědı́ a nakonec po ICMP docházı́ k přenosu
zpráv hlavně o nedostupném DNS serveru.
36
6.2.2
Druhý přı́klad
Pro druhý přı́klad jsem si vybral DNS požadavky na všechny domény nejvyššı́ úrovně. Pro
demonstraci jsem použil program dig, jenž dokáže formulovat požadavek na doménu, vybral
jsem volbu na dotaz na všechny atributy domény. Záměrně jsem použil protokol UDP, který
je ostatně výchozı́m protokolem pro DNS požadavky. Avšak v důsledku požadavku na všechny
atributy domény docházı́ k tomu, že po UDP lze dle specifikace přenášet pouze DNS odpovědi
do velikosti 512B. Pokud je překročena velikosti, je v odpovědi zapnutý přı́znak truncated“ a
”
požadavek je opakován po spojovaném kanále TCP.
Přı́klad 2: Histogram velikosti přenášených rámců
Na grafu s histogramem názorně vidı́me, že se nám oproti prvnı́mu přı́kladu zmenšilo spektrum velikosti paketů, velikost odpovědı́ pro UDP je limitována velikostı́ 512B. Pro požadavky,
které jsou většı́ docházı́ k navazovánı́ TCP spojenı́, avšak velikost DNS odpovědı́ nenı́ o mnoho
většı́, než zmiňovaných 512B. Na druhou stranu ale rozloženı́ velikostı́ kopı́ruje minulý histogram, největšı́ hustota je na počátku a konci spektra. Jako druhý graf v přı́kladu nalezneme
využitı́ transportnı́ch protokolů, který jasně dává do souvislosti zastoupenı́ UDP a TCP protokolů. Co do počtu paketů, přenesených po protokolu, má většinu protokol TCP, avšak jak vı́me,
protokol vytvářı́ spojenı́, které spolyká jistou režii a na druhém grafu je zastoupenı́ opačné, což
odpovı́dá realitě, kdy se většina odpovědı́ vracı́ ve formě UDP datagramu.
6.3
Modul ARP/RARP
Modul ARP/RARP netřeba dlouze představovat, sloužı́ pro převod hardwarových adres a
sı́t’ových (resp. naopak). Do modulu je zakomponován převod MAC adres na výrobce hardwaru
a můžete se o fungovánı́ přesvědčit na následujı́cı́ch dvou ukázkách. Vstup pro prvnı́ ukázku
pocházı́ z bezdrátové sı́tě, kde došlo na routeru k zakázánı́ sı́t’ové karty a posléze k jejı́mu zapnutı́. Klienti se proto znovu zaregistrovali a znovu je nutná registrace na úrovni MAC adres.
37
(a)
(b)
Přı́klad 2: Podı́l užitých transportnı́ch protokolů
Druhou ukázku jsou stáhl na stránkách programu Wireshark[19], jedná se o tzv. ARP bouřku,
kterou vyvolal jeden z prvků 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
Závěrečná ukázka demonstruje práci při dotazovanı́ a odpovı́dánı́ server DNS, který má na
starost překlad čı́selných adres na doménová jména, dále udržuje informace o poštovnı́m serveru
domény, atd. U každé navrácené odpovědi naleznete informaci o čase, za jaký došlo k vyřı́zenı́,
dále protokol, přes který odpověd’ a identifikace dotazu proběhla. Následuje vyčı́slenı́ počtu
otázek (resp. odpovědı́) a na dalšı́ch řádcı́ch výpisu již figurujı́ otázky a odpovědi. U většiny
známých typů odpovědı́ jsou znázorněny detailnı́ informace. Prvnı́ ukázka pocházı́ z programu
Tcpdump a ukazuje běžné dotazy, uskutečňované při brouzdánı́ po webových stránká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)
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 závěr ukázek přidávám právě výstup z programu dig, konkrétně se jedná o DNS požadavek
na doménu CZ, tedy na českou doménu nejvyššı́ úrovně. Výstup ukazuje např. záznamy o pod40
pisech a jejich klı́čı́ch, dále list DNS serverů domé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 <root> 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
Vnitřnı́ řešenı́ analyzátoru
7.1
Soubory programu
Na úvod závěrečné kapitole začnu s představenı́m všech zdrojových souborů, které v programu
naleznete. Jejich seznam spolu s vysvětlenı́m naleznete v následujı́cı́ tabulce.
Jméno 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 datovými typy
implementace datového objektu, zejména velká množina
funkcı́ pro ukládánı́ hodnot
zásobnı́k události, funkce pro registrace a vyřı́zenı́
událostı́
logovacı́ systém, převzatý z knihovny LibUCW
soubor s definicı́ kompilace a linkovánı́ programu
deklarace a implementace všech modulů, které jsou
použity v programu
soubor pro definovánı́ obalu pro program SWIG
soubor s pomocnými funkcemi
Implementace datového objektu
Datový objekt je univerzálnı́ struktura pro ukládánı́ informacı́ o datagramech, paketech, spojenı́ch atd. Pro ukládánı́ dat do datového objektu sloužı́ hešovacı́ tabulka z dı́lny knihovny
LibUCW[5], která zahešuje atribut nějakého typu do tabulky. Atributy zpravidla rozdělujeme do
dvou základnı́ch kategoriı́: hodnotové a referenčnı́. Hodnotové atributy sedı́ přı́mo ve struktuře
pro atribut a jsou jimi např. INT, IPV4, DOBJ. Na druhé straně stojı́ atributy o kterých předem
nevı́me, jak budou dlouhé. Přı́kladem budiž STRING či ARRAY, pro takové atributy je nutné
alokovat mı́sto mimo strukturu a uložit si jejich referenci. Pro veškerou alokaci paměti pro datový objekt je použit memory pool, pro uvolněnı́ paměti objektu. Nenı́ nutné dealokovat po
jednom všechny atributy, ale stačı́ zavolat metodu poolu, jež uvolnı́ celý blok paměti. Popsaná
technika urychluje práci s pamětı́ a zapouzdřuje data společná pro jeden objekt. Každý datový
objekt jasně definuje, jaké je třı́dy, a disponuje také zásobnı́kem událostı́.
7.3
Zásobnı́k událostı́
Dı́ky zásobnı́ku událostı́ můžeme o programu hovořit jako o událostmi řı́zeném. Nedocházı́
k přı́mému volánı́ metod, nýbrž nastane událost, která posléze zavolá všechny metody, které
jsou v zásobnı́ku událostı́ zaregistrované. O zásobnı́ku mluvı́me z toho důvodu, že pokud nastane
událost, nenı́ nikam uložena do kalendáře pro vyřı́zenı́, ale jsou sekvenčně procházeny události
42
a zavolány jejich metody pro obslouženı́. Hlavnı́ smyčka je prováděna v modulu PCAP, jenž
načı́tá data ze souboru a volá pro každý paket obsluhu události packet. Zásobnı́kem disponujı́ téměř všechny naprogramované moduly a i některé typy datových objektů, které zpravidla
představujı́ nějaký IP datagram, spojenı́, atd. Z hlediska vlastnı́ implementace je nejprve nutné
registrovat jméno události do hešovacı́ tabulky. Pro registrovánı́ metody do zásobnı́ku je nutné
uložit identifikátor události do hešovacı́ tabulky. Po vypuknutı́ události nejprve naleznu událost
v zásobnı́ku a začnu sekvenčně procházet všechny zaregistrované funkce. Volánı́ funkcı́ je vytvořeno pomocı́ Python C API, kde jako jediný argument vyplnı́m datový objekt a obalený
objekt v Pythonu posléze může vstoupit jednak do funkce v jazyce C, tak do funkce v Pythonu.
Řešenı́ je celkem jednoduché a pro správné volánı́ funkcı́ si vystačı́me s klasickým zásobnı́kem
volánı́, nenı́ nutné realizovat centrálnı́ kalendář nebo jinou, podobně orientovanou, datovou
strukturu.
7.4
Programovánı́ modulů
Při programovánı́ modulů musel být brát zřetel na několik věcı́. Každý modul dostává na svém
vstupu datový objekt a je nutné filtrovat jejich typ. Pro tyto účely sloužı́ datové třı́dy a jejich
otestovánı́ je velmi rychlé. Dalšı́ nepřı́jemnostı́ se stává skutečnost, že paket nebyl odchycen ze
sı́tě v celé své velikosti. Proto je během načı́tánı́ informacı́ vždy nutné kontrolovat velikost dat
a celý program je kontrolami protkán. Pro programovánı́ komplikovanějšı́ch modulů si nelze
vystačit pouze s datovými objekty a je nutné vytvářet i dalšı́ pomocné datové struktury. Jako
velmi šikovný se ukázat void ukazatel, dı́ky němuž nenı́ složité uložit do datového objektu
ukazatel na nějakou pomocnou strukturu a při resetovánı́ či vypršenı́ časového limitu se nejen
smaže spojenı́, ale dojde i k uvolněnı́ paměti, takto vzniklých struktur.
7.5
Představa fungovánı́ modulu TCP
Modul TCP považuji za nejsložitějšı́ v rámci programu a proto bych se rád zmı́nil o jeho
fungovánı́. Jako vstup se načtou pakety sı́t’ové vrstvy, následně dojde k dekódovánı́ atributů
hlavičky a nalezenı́ spojenı́, do něhož paket zapadá. Pro ukládánı́ spojenı́ je použita hešovacı́
tabulka, kde za pomoci adres a portů vzniká jednoznačná identifikace spojenı́. Prvnı́m omezenı́m, které je nutné brát na zřetel, je potvrzovánı́: data prošlá po sı́t’ové infrastruktuře jsou
předávána aplikačnı́ vrstvě až v okamžiku, kdy dorazı́ potvrzenı́ od druhé strany. Proto je nutné
vstupnı́ data ukládat do zásobnı́ků a uvolňovat je až po doručenı́ potvrzenı́. Za druhý problém
považuji ztrátu přenesených paketů během odchytávánı́, které je povětšinou způsobeno tı́m,
že pakety přicházı́ ve špičkách rychleji, než je disk stačı́ ukládat. Jak již bylo zmı́něno, modul
vytvářı́ datový objekt TCP flow, které disponuje vlastnı́m kalendářem událostı́, uchovává si
stav spojenı́ a na obou směrech kanálu držı́ data prošlá po sı́ti, která ještě nejsou potvrzena.
Pro ilustraci fungovánı́ sloužı́ přiložený obrázek.
Na hornı́ části obrázku můžeme nahlédnout dva moduly, které již byly ukázány v schématu
zapojenı́ programu. Z modulu TCP flow vidı́me, že nastala událost conn create, jež symbolizuje vznik nového spojenı́. Na obrázku jsou znázorněny jak vlastnı́ zásobnı́k událostı́, tak
zásobnı́ky paketu, které čekajı́ na potvrzenı́. Kromě ještě nepotvrzených paketů můžeme vidět i
TCP data, jenž vznikajı́ při události data. Data v sobě nesou pouze základnı́ informace a na
43
zmı́něnou událost se typicky navěšujı́ dalšı́ moduly (např. Modul HTTP), data zpracovávajı́
a také uvolňujı́ (uvolněná data symbolizuje proškrtlý obdélnı́k). Z hlediska konečného množstvı́
paměti, jenž máme k dispozici nenı́ možné vše držet v paměti a systém datových objektů nám
sloužı́ jako dobrý mechanizmus. Jako obrana proti velkému množstvı́ alokované paměti jsou implementovány dva mechanizmy pro uvolňovánı́ užité paměti. Prvnı́m mechanizmem je limit na
hornı́ počet paketů v zásobnı́ku spojenı́, limit lze v modulu TCP flow nastavit a při dosaženı́
hranice je celé spojenı́ prohlášeno za neplatné a nastane událost conn timeout. Druhým mechanizmem je kontrola poslednı́ho došlého paketu do spojenı́, kdy se kontrolujı́ neaktivnı́ spojenı́
a jsou následně prohlašována za neplatná (nastane událost conn timeout a dojde k ukončenı́
spojenı́).
44
Závěr
8.1
Zhodnocenı́ práce
Ve vytvořeném programu nenı́ množina pokrytých protokolů modelu TCP/IP kompletně pokryta a ani být nemůže. Nenı́ v možnostech bakalářské práce zahrnou stovky dnešnı́ch protokolů
do jednoho programu. Za mnohem důležitějšı́ považuji fakt, že funkčnı́ program je dostatečně
obecný a otevřený, a proto při přidávánı́ nového protokolu nenarazı́ autor na žádné překážky.
Při vytvářenı́ specifikace programu byla dlouho otevřená otázka propojenı́ jádra programu, napsaném v jazyce C, se skriptovacı́m jazykem. Nakonec jsem zvolil jazyk Python, se kterým jsem
doposud neměl žádnou zkušenost. Python se osvědčil po všech stránkách: poskytl prostředky
pro tvorbu skriptů, lze jı́m lehce obalit kód v jazyce C a doplnit jej o metody třı́d a nakonec
byl jazyk také zvolen pro jeho nezávislost na operačnı́m systému.
Jak zkušenosti s programem ukazujı́, rychlost programu na stroji s procesorem Intel Core2
Duo 2GHz, s pevným diskem s 5 400 otáčkami za minutu dosahuje při spuštěnı́ skriptu HTTP
rychlost asi 13 MB/s, což odpovı́dá 100 Mb/s. Při této rychlosti zpracovánı́ dat je možné program nasadit v reálném čase na poloduplexnı́ 100Base-TX linku. Jak testy hlavně jednoduššı́ch
skriptů ukázaly, největšı́ hardwarovou slabinou se stává pevný disk, který v přı́padě notebooku
pracuje téměř na plný výkon. V rané fázi návrhu jsem přemýšlel nad myšlenkou vı́cevláknové
aplikace, ale protože se našı́m největšı́m omezenı́m stává právě pevný disk, byl by přı́nos vı́ce
výpočetnı́ch jader zanedbatelný a vznikala by nemalá režie spojená se synchronizacı́.
Co se vlastnı́ho programovánı́ týče, tak se od počátku počı́talo s programovacı́m jazykem C.
Dı́ky knihovně LibUCW se ale programovánı́ stalo pohodlnějšı́, pro alokaci paměti se osvědčil
mempool a celý program je protkán hešovacı́mi tabulkami, počı́naje těmi jednoduchými s atomickým typem a konče složitějšı́mi s vı́cesložkovým klı́čem. Trendem dnešnı́ doby se stává
programovánı́ ve stále vyššı́ch programovacı́ch jazycı́ch za pomoci silné knihovny funkcı́. Musı́m
ale přiznat, že práce v jazyce C má stále své kouzlo a již jednou zmı́něná knihovna dodá programátorovi potřebný komfort při práci.
8.2
Možnosti budoucı́ho vývoje
Program umı́ pracovat zhruba s jednou desı́tkou protokolů rodiny TCP/IP, což v porovnánı́ s celkovým počtem protokolů představuje pouze malou podmnožinu. Jistě by bylo velmi zajı́mavé
zpracovánı́ protokolů jako jsou napřı́klad: SIP (Session Initiation Protocol), SMTP (Simple Mail
Transfer Protocol) či FTP (File Transfer Protocol). Jako dalšı́ vylepšenı́ vidı́m možnost např.
v on-line analyzátoru, kdy by vznikla webová stránka s množinou podporovaných analýz. Na
uživateli by poté bylo si vybrat analýzy, které chce provést a program by mu následně odeslal
jejich výsledky. Podobně by mohl být analyzátor nasazen za běhu sı́tě v režimu on-line, kdy by
se data neukládala do souboru, ale přı́mo by se zası́lala analyzátoru. Nasazenı́ za běhu sı́tě by
jistě vyžadovalo drobné změny, ale výsledky by mohly být zajı́mavé a stá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, přednáška Rodina protokolů 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] Mareš 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ı́ matematická 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
[13] Information Sciences Institute (1981): Request For Comments: 791, Internet Protocol
[14] Deering S. a kol. (1998): Request For Comments: 2460, Internet Protocol, Version 6 (IPv6)
[15] Postel J. a kol. (1980): Request For Comments: 768, User Datagram Protocol
[16] Information Sciences Institute (1981): Request For Comments: 793, Transmission Control
Protocol
46
[17] Feeling R. a kol. (1999): Request For Comments: 2616, Hypertext Transfer Protocol
[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

Martin Liška Pasivn´ı analyzátor s´ıt´ı - NEPAL

Transkript

Podobné dokumenty

Praktikum z operacnıch systému˚ Jméno: I. Strucné odpovedi 1