VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

Transkript

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS BEZPEČNÝ TRANSPORT DAT NETFLOW SECURE TRANSPORT OF NETFLOW DATA BAKALÁŘSKÁ PRÁCE BACHELOR S THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR TOMÁŠ RUČKA Ing. MATĚJ GRÉGR BRNO 2012

2

3 Abstrakt Tématem této bakalářské práce je zabezpečení komunikace v nástroji NetFlow. Komunikace v NetFlow není nijak chráněná proti neoprávněnému vniknutí, navíc pracuje nad transportním protokolem UDP, což je protokol, který připouští ztrátu dat. Cílem této práce je vytvoření šifrovaného tunelu, přes který bude probíhat komunikace mezi exportérem a kolektorem. Abstract The aim of my bachalor s thesis is secure transport NetFlow data. Communication in Net- Flow is not protected against unauthorized intrusion, in addition works over UDP protocol which is protocol that allows data loss. The aim of this work is to create an encrypted tunnel through which communication will take place between the exporter and collector. Klíčová slova NetFlow, SSL, hash, certifikát, veřejný klíč, soukromý klíč, šifrování, dešifrování, podpis Keywords NetFlow, SSL, hash, certificate, public key, private key, encrypt, decrypt, signature Citace Tomáš Ručka: Bezpečný transport dat NetFlow, bakalářská práce, Brno, FIT VUT v Brně, 2012

4 Bezpečný transport dat NetFlow Prohlášení Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně pod vedením Ing. Matěje Grégra Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal Tomáš Ručka 16. května 2012 Poděkování Děkuji Ing. Matěji Grégrovi za odborné konzultace, připomínky a vedení bakalářské práce. c Tomáš Ručka, Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.

5 Obsah 1 Úvod 3 2 NetFlow Exportér Kolektor Datový tok Vlastnosti přenosu Protokol komunikace NetFlow Kryptografie Klasická kryptografie Symetrická kryptografie Asymetrická kryptografie Certifikát a certifikační autorita Hash funkce Elektronický podpis SSL - Secure sockets layer Record Protokol Handshake Protokol Change Cipher Specification a Alert Protokol Rozdíly mezi SSL a TLS Návrh aplikace Popis činnosti klienta a serveru Šifrování a podpisy Implementační jazyk Implememtace Vytvoření šifrované komunikace pomocí protokolu SSL Zpracování parametrů popisující propojení mezi kolektorem a exportérem Vytvoření TCP spojení se serverem Vytvoření podpisu zprávy Odeslání informací o adresách kolektorů Spojení s exportérem a jeho obsluha Popis činnosti serveru Testování 26 1

6 8 Závěr 28 Literatura 29 Přílohy 30 Seznam příloh A Obsah CD 32 A.1 Adresářová struktura B Spuštění programů 33 B.1 Spuštění proxy exportéru: B.2 Spuštění proxy kolektoru: C Tabulky popisující formáty paketů, přenášené v NetFlow 35 2

7 Kapitola 1 Úvod Počítačové sítě dnes patří mezi nejvíce využívané médium. Počítačovou sít dnes lidé nejčastěji využívají pro komunikaci, sdílení dat nebo poskytování různých služeb. Pomocí protokolu NetFlow a monitorování provozu lze zjistit, kdo, jak často a jak dlouho využívá jaké služby. Přenos dat v NetFlow není nijak chráněný proti falšování nebo podvržení falešných zpráv. Navíc jsou data v NetFlow přenášená pomocí transportního protokolu UDP, který připouští ztrátu dat. Cílem této práce je realizace zabezpečeného přenosu dat mezi exportérem a kolektorem v NetFlow komunikaci. Přenos dat mezi exportérem a kolektorem bude probíhat přes tzv. proxy programy, které před samotným přenosem mezi sebou vytvoří šifrované spojení. Exportér bude posílat data proxy exportéru, který data zašifruje, připojí k nim vytvořený podpis a pošle takto vytvořený paket přes šifrované spojení směrem k druhému proxy. Proxy na straně kolektoru bude data načítat ze šifrovaného kanálu a pomocí podpisu bude kontrolovat integritu a autora přijatých dat. Po ověření zprávy pošle data kolektoru. Práce je složena z několika kapitol, které se postupně zabývají celým životním cyklem této práce. Po úvodní kapitole následuje kapitola zabývající se základy NetFLow (2). Rozebírají se v ní postupně prvky, které v NetFlow vystupují a také vlastnosti přenosu. Kapitola kryptografie (3) popisuje klasickou, symetrickou a asymetrickou kryptografii. Dále popisuje pojmy jako jsou elektronický podpis, certifikát, hash funkce nebo certifikační autorita. Kapitola SSL (4) podrobně popisuje všechny části SSL protokolu a rozdíl mezi TLS a SSL. Kapitola Návrh aplikace (5) se zabývá samotným návrhem implementace, návrhem komunikačního protokolu, který je využíván v šifrovaném spojení, nebo výběrem vhodného šifrovacího algoritmu. Kapitola implementace (6) popisuje datové struktury a jednotlivé funkce, které jsou v aplikaci použity. Kapitola testování (7) popisuje jaké testy byly použity pro ověření správného chování aplikace. Kapitola závěr (8) shrnuje dosavadní výsledky a navrhuje možná rozšíření. 3

8 Kapitola 2 NetFlow NetFlow je protokol, který vyvinula firma Cisco Systems. Úkolem protokolu NetFlow je monitorování provozu sítě a nasbírané informace uložit na datové úložiště. Jednotkou komunikace v technologii NetFlow je datový tok. Technologii NetFlow tvoří: exportér kolektor komunikační protokol Exportér se stará o monitorování sítě a posílání získaných informací po síti ke kolektoru. Většinou je řešen jako součást aktivního prvku na síti například jako směrovač nebo jako samostatné zařízení, které je na síti vloženo mezi dva monitorované prvky. Kolektor nám slouží k příjímání dat od exportéru a ukládání těchto dat do své dlouhodobé paměti, kterou má k dispozici. Z těchto uložených dat se později mohou vytvářet statistiky o komunikaci, nebo mohou sloužit jako pomůcka pro odhalování slabých míst na síti. Komunikační protokol nám definuje formát komunikace mezi exportérem a kolektorem, protože exportér a kolektor bývají obvykle umístěny na jiných místech v síti. Podrobněji se o všech prvcích píše v následujících kapitolách. NetFlow funguje jako monitoring sítě a data, která díky tomu získáme nám slouží k: analýze provozu na síti nalezení málo nebo hodně vytížených míst účtování poplatků za služby zabezpečení na síti plánování budoucího rozvoje sítě Přenos dat mezi exportérem a kolektorem probíhá nad transportním protokolem UDP, což je protokol, který uvažuje možnost ztráty dat. Přenos dat může být realizován jak přes privátní sít (firmy, domácnosti), tak přes veřejnou sít. Útočník tedy jednoduše může odposlouchávat data, která mohou být citlivá. Cílem této práce je vytvořit přenos mezi exportérem a kolektorem, který bude šifrovaný a zároveň bude garantovat spolehlivý přenos bez ztráty dat. 4

9 2.1 Exportér Stará se o monitorování provozu na síti. Vytváří záznamy a posílá je kolektoru. Exportér snímá z daného toku konkrétní informace. Mezi tyto informace patří např: zdroj posílání daného toku (IP adresa zdroje) cíl posílání toku (IP adresa cíle) protokol (mezi tyto protokoly patří např. UDP nebo TCP) čas započetí nebo ukončení datového toku objem dat, který byl přenesen Tyto informace exportér posílá prostřednictvím protokolu NetFlow směrem ke kolektoru, který tyto informace uloží do své paměti. Exportér může být na síti reprezentován jako samostatný prvek, nebo jako součást aktivního zařízení. Druhá možnost sebou nese tu nevýhodu, že aktivní prvek tráví většinu svého času směrováním paketů, tudíž se nemůže zabývat monitorováním přenosu a vytvářením dat NetFlow. Dochází k tzv. vzorkování paketů (z celkového počtu paketů, které projdou aktivním zařízením se jen část využije ke zpracování v NetFlow). V dnešní době se častěji objevuje varianta, kde exportér je realizován jako samostatný fyzický prvek. V takovém případě exportér neovlivňuje práci ostatních zařízení na síti. Exportéru se někdy říká pasivní sonda, protože pakety, které do ní vstupují nijak neovlivňuje. Dochází pouze k monitorování dat. 2.2 Kolektor Kolektor se stará o příjem NetFlow dat od exportéru a o jejich uložení do vlastní dlouhodobé paměti. V NetFlow technologii je možno použít několik kolektorů (N) a několik exportérů (M) v poměru M:N. V praxi však bývá spíše jeden kolektor, který může přijímat a ukládat data od více exportérů [3]. Kolektor navíc běží na jiném počítači než exportér. Komunikace mezi těmito prvky je popsána v další kapitole. 2.3 Datový tok Datový tok si lze představit jako jednu úplnou sít ovou konverzaci. Například připojení na webový server představuje započetí jednoho datového toku, následuje komunikace ve formě stahování webových stránek a nakonec odpojení se od webového serveru jako ukončení komunikace a tedy ukončení datového toku. Každý tok se rozlišuje unikátní skupinou následujících údajů: cílová IP adresa zdrojová IP adresa cílový port zdrojový port 5

10 číslo protokolu typ služby vstupní rozhraní Pro každý tok, který je během monitorování zaznamenáván se ukládá doba, kdy daný tok vznikl, doba trvání daného toku, objem dat, který se přenesl, počet paketů a další údaje. Jestli exportér nalezne další paket, který patří do daného toku, pak inkrementuje čítač počtu paketů v datovém toku a navýší objem dat. Nový datový tok vznikne příchodem paketu, který obsahuje zcela nové hodnoty ve výše uvedeném výčtu, tedy jej nelze přirovnat k již existujícímu datovému toku. Další možností vzniku je vypršení časovače timeout. Datový tok je vždy jednosměrný. Tzn. že jedna adresa je pouze cílovou adresou a druhá adresa je pouze zdrojovou adresou. S využitím příkladu HTTP serveru, který je výše by se tato vlastnost dala popsat jako jeden tok, který je od uživatele k webovému serveru a druhý tok od webového serveru zpět k uživateli [2]. 2.4 Vlastnosti přenosu Komunikace pomocí protokolu NetFlow probíhá pouze jedním směrem. Exportér data pouze posílá kolektoru a kolektor zase data pouze přijímá. Jde o jednoduchý proces, který není náročný na hardware. Z hlediska spolehlivosti jde o přenos, který akceptuje ztrátu paketů. Přenos je totiž realizován nad transportním protokolem UDP, což je nespolehlivý přenos, který toleruje již výše zmíněnou ztrátu paketů bez možnosti získání paketu zpět. To se v některých situacích nemusí vyplatit, například když se poskytovateli nějaké služby nedostávají informace o tom, kdo a jak danou službu využívá. A někdy zase lze ztrátu paketů tolerovat, jako například při posílání a ukládání statistik o provozu sítě. Ztráta paketů a nemožnost poslat daný paket znova není jen otázkou transportního protokolu, ale také filozofií komunikace v NetFlow. Komunikace totiž probíhá pouze jedním směrem a kolektor, který data pouze přijímá nemá možnost požádat o znovu zaslání ztracených dat. 2.5 Protokol komunikace NetFlow Protokol pro komunikaci mezi exportérem a kolektorem v NetFlow byl vyvinut v několika verzích. Nejdříve se nejvíce prosadila verze 5, dnes se hojně využívá verze 9. Protokoly NetFlow nezahrnují žádné prostředky, které by byly určené ke konfiguraci spojení mezi exportérem a kolektorem a také nevyžadují žádné zásahy do prvků monitorované sítě jako jsou například směrovače. Formát paketu NetFlow verze 5 je jednoduchý. Paket se skládá z hlavičky a těla. Hlavička obsahuje 24 bajtů dat a tělo 48 bajtů dat. Formát paketu, který se používá v NetFlow verze 5 je uveden v příloze C.1. Podrobný popis všech položek paketu je také uveden v příloze C.3. NetFlow verze 9 je založen na šablonách, díky kterým lze vytvářet různé záznamy dat NetFlow. Na počátku datagramu je opět hlavička stejně jako ve verzi 5. Po hlavičce následuje minimálně jeden záznam se šablonou (šablona flow-set), které specifikují pořadí a význam jednotlivých položek v záznamu toku. Na straně kolektoru je 6

11 nutné aby si kolektor ukládal šablony, které přijal. Kolektor podle ID šablony v záznamu dat zjistí, ke které šabloně data patří. Šablony jsou časově limitované a po uplynutí času se musí aktualizovat [7]. Kromě hlavičky a šablon se v NetFlow posílají také data (flow-set data), která jsme získali monitorováním sítě. Každý záznam dat obsahuje ID šablony, velikost dat, jednotlivé položky dat a zarovnání. Podle ID šablony kolektor zjistí, jak má příchozí data interpretovat. V příloze C.5 naleznete veškeré tabulky popisující formáty zpráv, které se posílají v Net- Flow verze 9. 7

12 Kapitola 3 Kryptografie Kryptografie je vědní obor zabývající se zabezpečením obsahu. V počítačové síti, tak budeme užívat pro zabezpečení zpráv, které se po této síti posílají. Mechanizmus zabezpečení je založen na matematických metodách a spočívá v zašifrování zprávy na straně odesilatele a dešifrování zprávy na straně příjemce. V této oblasti vystupuje několik základních pojmů: otevřený text čitelný text, který chceme zašifrovat zašifrovaný text text, který byl upraven do nečitelné podoby pomocí šifrovacího algoritmu šifra matematická funkce, která převádí čitelný text na nečitelný a opačně klíč slovo, číslo nebo libovolný řetězec, který využívá šifra pro šifrování a dešifrování šifrování proces jejímž vstupem je šifra a otevřený text a výstupem je zašifrovaný text dešifrování - proces jejímž vstupem je šifra a zašifrovaný text a výstupem je otevřený text Kryptografie je součástí většího celku, který se jmenuje kryptologie. Do tohoto celku dále patří kryptoanalýza, která nám slouží k luštění šifer. Kryptografie se dnes zabývá také otázkou autorizace a autentizace. Autentizace je proces, při kterém se ověřuje identita např. uživatele systému. Autorizace je proces, při kterém se ověřuje, zda má daný uživatel práva na jistou činnost. Kryptografie se rozděluje na další části, které si podrobněji popíšeme v dalších kapitolách: klasická kryptografie symetrická kryptografie asymetrická kryptografie 3.1 Klasická kryptografie Tato část kryptografie se využívala spíše v historii. Byla založena na principu nahrazování znaků ve zprávě jinými znaky (substituční šifry), nebo přehození jejich pořadí dle pravidel (transpoziční šifry). 8

13 3.2 Symetrická kryptografie Zde se pro šifrování na straně odesilatele a dešifrování na straně příjemce užívá stejného klíče. Tento klíč je třeba před komunikací distribuovat druhé straně. Toto řešení je oblíbené pro svou nenáročnost na výpočetní výkon a také rychlost. Velká nevýhoda tohoto řešení spočívá v nutnosti distribuce klíče po veřejném médiu. Tímto se ke klíči může dostat třetí strana, která toho může využít ve svůj prospěch. Symetrické šifry jsou dvojího typu: proudové šifry blokové šifry Proudové šifry šifrují otevřený text po částech stejného počtu bitů nebo bajtů. Před šifrováním není třeba abychom měli k dispozici celý text, ale stačí pouze jeho část. Na každou část se postupně aplikuje šifrovací algoritmus. Blokové šifry pracují s bloky dat o pevném počtu bitů. Obvykle se jedná o 64, 128 nebo 256 bitů. Platí, že čím větší blok se užívá pro šifrování, tím je pro útočníka složitější identifikovat šifrovací klíč [4]. 3.3 Asymetrická kryptografie V asymetrické kryptografii se pro šifrování a dešifrování používá rozdílných klíčů. Každý z těchto klíčů vlastní obě strany komunikace. Tyto klíče jsou veřejný klíč soukromý klíč Veřejný klíč se v asymetrické kryptografii používá pro šifrování a soukromý klíč se užívá pro dešifrování. Veřejný klíč vlastník pošle po síti protější straně. Soukromý klíč se nikam neposílá a zůstává na straně vlastníka. V asymetrické kryptografii platí, že když zašifrujeme zprávu veřejným klíčem, tak ji dešifrujeme soukromým klíčem. Nevýhoda použití asymetrické kryptografie je její rychlost oproti symetrické kryptografii. Další nevýhodou je výměna veřejných klíčů. Tuto výměnu může odchytnout třetí strana, která může odchyceným veřejným klíčem šifrovat svoje data a posílat je příjemci. Poslednímu problému se dá zabránit například pomocí elektronického podpisu, o kterém se dozvíme více v další kapitole. 3.4 Certifikát a certifikační autorita Pojmy, které se spojují s asymetrickou kryptografii jsou certifikát a certifikační autorita. Certifikát je dokument, který dává dohromady objekt a jeho veřejný klíč. Objekt je zde chápána například jako organizace nebo společnost. Certifikát obsahuje následující položky: veřejný klíč identifikace objektu (společnosti...) sériové číslo certifikátu doba platnosti 9

14 identifikace organizace, která certifikát vydala Jak už bylo naznačeno výše, certifikát vydávají organizace, tzv. certifikační autority, které zaručí, že daný objekt, ke kterému veřejný klíč patří je opravdu ten, za kterého se vydává. Tedy certifikát, který byl vydán certifikační autoritou je považován za kvalifikovaný certifikát. Mezi další úkoly certifikační autority patří: příjem žádosti o certifikát a její registrace ověření identity objektů vydávání/deaktivace certifikátů zveřejnění ne/platných certifikátů 3.5 Hash funkce Hash funkce vytváří otisk dat, které dostane na vstupu. Na vstupu můžeme mít data o libovolné velikosti [6], a na výstupu dostaneme pokaždé jiná data s pevně definovanou délkou. Tyto funkce se dnes používají také v kryptografii zejména při zajištění integrity. V hash funkcích se klade důraz na dva základní požadavky: jednosměrnost odolnost proti kolizím První z požadavků vyjadřuje, že lze vytvořit otisk z libovolné zprávy, ale z otisku se zpráva nedá zpětně vytvořit. Této vlastnosti se využívá nejčastěji při šifrování přístupových hesel, kde se heslo při registraci pomocí hash funkce zašifruje a šifrovaná podoba se uloží do databáze. Potencionální útočník se může dostat do databáze, ale data z ní získaná mu nemohou být nijak ku prospěchu. Při autentizaci se vytvoří hash hesla a tento hash se poté porovnává s hesly uloženými v databázi. Druhým požadavkem, který je kladen na hash funkce je odolnost proti kolizím. Nesmí se tedy stát situace, kdy máme dvě rozdílné zprávy a na každou z nich aplikujeme hash funkci a v obou případech dostaneme stejný otisk. V tomto případě mluvíme o kolizi. 3.6 Elektronický podpis Je další pojem, který se vyskytuje ve spojení s asymetrickou kryptografii. Jde o vypočítaná data, kde se pro výpočet zprávy užívá soukromého klíče odesilatele a hash z původní zprávy. Z důvodu rychlosti se podepisuje pouze hash zprávy místo původní celé zprávy. Takovýto vytvořený podpis se pak připojí k původní zprávě. Takto složená zpráva se nakonec zašifruje pomocí veřejného klíče příjemce. Na straně příjemce se nejdříve pomocí svého soukromého klíče dešifruje obálka zprávy. Poté se přejde k samotnému podpisu. Ten se dešifruje pomocí veřejného klíče odesilatele. Veřejný klíč odesilatele většinou poskytuje certifikační autorita. Pokud se veřejným klíčem nepodaří dešifrovat zprávu, pak lze usoudit, že nám zprávu poslala třetí strana, která do komunikace nepatří. Takováto zpráva se pak zahodí. Pokud se však podaří bez problému elektronický podpis dešifrovat, vznikne nám hash původní zprávy. Tuto původní zprávu poté porovnáme s hash podobou původní zprávy. Pokud se zprávy shodují, pak máme jistotu, že se zprávou během přenosu nikdo nemanipuloval. 10

15 Takovýto postup se opakuje pro každou zprávu zvlášt. Podpis je tedy originální pro každou zprávu. Originalita spočívá v různosti zpráv, které se užívají pro hash výpočet. Elektronický podpis nám zaručuje: jednoznačná identifikace osoby, která dokument podepsala zajištění integrity zjištění, zda se s dokumentem po podepsání manipulovalo podpis je pro každou zprávu originální uživatel, který dokument podepíše se nemůže zříct své zodpovědnosti 11

16 Kapitola 4 SSL - Secure sockets layer SSL je protokol, který umožňuje bezpečnou komunikaci na veřejné síti. Je vložen mezi aplikační a transportní vrstvu ve vrstvovém modelu TCP/IP. Protokol používá spolehlivý transportní protokol TCP. Je plně duplexním protokolem, který využívá architektury klient server. Protokol poskytuje šifrování přenosu dat a také autentizaci komunikujících stran. Pro zabezpečení komunikace lze použít symetrické či asymetrické metody, hash funkce či algoritmy pro elektronický podpis. Následuje stručný seznam podporovaných metod a algoritmů: DES symetrický šifrovací algoritmus Triple DES trojitý DES DSA algoritmus elektronického podpisu MD5, SHA, SHA-1 algoritmus pro vytváření jednoznačného otisku RC2 a RC4 symetrický šifrovací algoritmus RSA algoritmus elektronického podpisu Mezi nejčastější využití protokolu SSL patří zabezpečení komunikace s internetovými servery. Jedná se o HTTPS, což je vlastně zabezpečené HTTP, nebo zabezpečení přenosu souborů v protokolu FTP, čímž vzniká FTPS. Dále se využívá při zpracování osobních citlivých údajů, v zaměstnání jako komunikace s obchodním partnerem, v on-line obchodech při zpracování plateb pomocí platební karty atd. Protokol SSL se skládá ze čtyř částí: 1. Record Layer Protokol 2. Handshake Protokol 3. Change Cipher Specification Protokol 4. Alert Protokol Podrobněji se o dílčích protokolech píše v následujících kapitolách. 12

17 4.1 Record Protokol Record Layer Protokol je nejnižší vrstvou protokolové architektury SSL. Všechny ostatní části jsou nad touto vrstvou v jedné vrstvě přesně jak ukazuje obrázek 4.1. V SSL jsou data, které se mají přenášet zabalená do objektu, kterému se říká record. Record se skládá z těla a hlavičky. Tělo recordu obsahuje užitečná aplikační data. Než jsou tyto data vložena do recordu, je třeba je nejdříve upravit. Tato úprava se skládá ze čtyř fází: fragmentace komprimace aplikace MAC - Message Authentication Code šifrování V první fázi jsou data, které protokol SSL přebírá od aplikace rozdělena do tzv fragmentů. Tyto fragmenty mohou být velké až 2 14 B. V druhé fázi je provedena komprimace fragmentu. To, jaký algoritmus bude použit pro fragmentaci se dohodne v handshake protokolu. Stále platí, že výsledný zkomprimovaný fragment nesmí být větší než 2 14 B. Navíc při komprimaci nesmí dojít ke ztrátě dat. Ve třetí fázi se ke komprimovanému obsahu vypočte pomocí hash funkce ověřovací informace MAC. Hodnota MAC nám slouží k ověření, zda nebyla zpráva během přenosu nějak upravena. Strana, která přijme zprávu vypočte z této zprávy svou hodnotu MAC a porovná ji s hodnotou MAC, kterou přijal ve zprávě. Hash algoritmy, které jsou podporovány v SSL jsou vypsány výše. Algoritmus, který se provede pro hash je stejně jako komprimační algoritmus dohodnut v handshake protokolu. V poslední čtvrté fázi se provede šifrování celého fragmentu. Máme dva typy šifrovacích algoritmů: proudový - algoritmus nevyžaduje pevnou délku fragmentu blokový - algoritmus vyžaduje pevnou délku fragmentu, fragment musí být doplněn, aby měl velikost 2 14 B Výčet šifrovacích algoritmů, které protokol SSL podporuje je vypsán výše. Po provedení všech čtyř fází vzniká upravený fragment, ke kterému se připojí hlavička. Hlavička má velikost přesně 5 B a skládá se ze tří částí: typ zprávy (změna specifikace šifrování, výstraha, handshake nebo aplikační data) verzi protokolu SSL informace o velikosti datového pole 4.2 Handshake Protokol Význam tohoto protokolu spočívá ve vytvoření bezpečné cesty mezi dvěma účastníky. Provádí se to v několika fázích: ověření serveru klientem dohoda na šifrovacích a komprimačních algoritmech 13

18 ověření klienta serverem výměna šifrovacích parametrů vytvoření zabezpečeného SSL spojení Tento protokol má také svůj formát zprávy, které si mezi sebou komunikující strany posílají. Zpráva se skládá ze tří částí: typ handshake zprávy číslo, které udává délku zprávy v bajtech parametry přidané ke zprávě 4.3 Change Cipher Specification a Alert Protokol Change cipher specification protokol nám slouží k oznámení o změně bezpečnostních parametrů. Pomocí handshake protokolu se připravily parametry pro komunikaci, tedy pro práci record layer protokolu a tyto parametry je třeba překlopit do aktuálních parametrů pro dané spojení a začít šifrovat podle těchto nových parametrů. Alert protokol nám slouží k posílání chybových zpráv. Chyba může být fatální nebo varovná. Když se objeví varovná chyba, tak komunikace může pokračovat. Pokud se ale objeví fatální chyba, pak komunikace musí skončit. Jako fatální chybu si můžeme představit vypočtení špatné hodnoty MAC. Naopak jako varovná chyba může být vypršení certifikátu. Obrázek 4.1: Protokolová architektura SSL 4.4 Rozdíly mezi SSL a TLS Zabezpečovací protokol TLS vychází z protokolu SSL v3.0 a stejně jako SSL zajišt uje zabezpečení zprávy od odposlechu či padělání. Principy obou protokolů jsou takřka stejné, liší se pouze v detailech [5]. 14

19 První z odlišností spočívá ve výpočtu MAC údaje, což je kód pro ověření toho, že zprávu nikdo při přenosu neupravil. Další rozdíl spočívá v sadě zpráv, které si strany vyměňují prostřednictvím alert protokolu. Další rozdíl spočívá v doplňování datových bloků do násobku určité velikosti. To se musí provést před šifrováním, které se provádí po blocích. V TLS se může doplnění dokončit v libovolné délce, která je násobkem délky šifrovacího bloku. V SSL protokolu musí být doplněk nejkratší možné velikosti. 15

20 Kapitola 5 Návrh aplikace Pro usnadnění si zavedeme dva pojmy: server - proxy na straně kolektoru klient - proxy na straně exportéru Implementace problému bude realizována jako dva samostatné programy. První z nich bude fungovat jako klient a druhý bude fungovat jako server. Klient bude mít na starosti příjem dat od exportéru. Přijatá data bude následně šifrovat a posílat je šifrovaným tunelem směrem k serveru. Server bude data od klienta dešifrovat a posílat příslušným kolektorům. Situace je popsána na obrázku 5.1. Jak naznačuje obrázek, spojení mezi exportérem a klientem je nešifrováno stejně tak jako mezi serverem a kolektorem. Tato záporná vlastnost se dá vyloučit tím, že exportér může fungovat se svou proxy na jednom počítači. Stejně tak může fungovat kolektor a server. Oba programy nebudou mít implementované žádné grafické rozhraní a budou se spouštět z příkazové řádky s různými parametry. Informovat uživatele o svých krocích bude program vypisováním informací na standardní výstup, nebo budou směrovány do souboru, který se specifikuje pomocí parametrů při spuštění programu. Obrázek 5.1: Popis zabezpečení přenosu mezi exportérem a kolektorem Popis propojení mezi exportérem a kolektorem bude popsán pomocí parametrů, které jsou popsány v příloze B. Informace načtené z parametrů se uloží do datové struktury, která je popsána v následující kapitole 6. 16

21 ./exporter\_kolektor -e p :2000 -k :9995 Výše uvedený příklad se dá vysvětlit takto: klient, který načte a zpracuje parametry se připojí na server, který poběží na adrese a bude naslouchat na portu Poté klient vytvoří UDP spojení a na portu 9965 bude naslouchat data od exportéru. Tato data pošle na adresu serveru. Server převezme data a pošle je kolektoru, který je na adrese a naslouchá na portu Pokud by server běžel na stejném počítači jako kolektor, pak se musí pro kolektor zadat adresa pro localhost viz. příklad spuštění níže: ahoj./exporter\_kolektor -e p :2000 -k : Popis činnosti klienta a serveru V této podkapitole se pomocí obrázků bude popisovat komunikační protokol. Poměr velikostí jednotlivých sekcí v jednotlivých paketech nesouhlasí se skutečností. Obrázek je takto vytvořen pouze pro názornou ukázku protokolu, který mezi sebou klient a server využívá. Klient bude tedy sloužit pro načtení dat, které popisují propojení mezi kolektorem a exportérem. Tato data se musí přesunout po síti směrem k serveru. Před tím než však proběhne samotný přesun po síti, musí být nejdříve vytvořeno šifrované spojení na stávajícím TCP spojení, aby potenciální útočník neodposlechl informace o konfiguraci propojení mezi exportérem a kolektorem. Informační paket bude mít podobu viz. obrázek 5.2: Obrázek 5.2: Podoba informačního paketu Paket je rozdělen do dvou částí. První část obsahuje IPv4 adresu počítače, na kterém kolektor běží a druhá část obsahuje číslo portu, na kterém kolektor naslouchá. Části jsou odděleny dvojtečkou. V této podobě se to bude pomocí regulárních výrazů snadno zpracovávat na straně serveru. Celý informační paket je ukončen středníkem. Po odeslání informačního paketu serveru a následného zpracování paketu serverem, započne vytváření zdrojů pro sít ovou komunikaci s exportéry a kolektory. Spojení mezi klientem a serverem je realizováno nad transportním protokolem TCP. Tím bude zaručeno, že se data nebudou ztrácet a budou přijímána ve správném pořadí. IP adresy verze 6 se v této implementaci pro zjednodušení nebudou používat a v této situaci je lze chápat jako možnost rozšíření. Když při pokusu o připojení klienta na server dojde k chybě (může nastat v situaci, kdy server ještě neběží), tak se program nesmí ukončit, ale musí ve smyčce opakovat připojení, dokud se nepřipojí. To samé platí o připojení klienta na exportéry. Jakmile jsou vytvořena všechna potřebná spojení, pak může začít samotné přeposílání šifrovaných dat. Klient postupně načítá data od exportéru. K těmto datům vytvoří informační část paketu, kterou znázorňuje obrázek 5.3. Položka velikost dat od exportéru bude serveru sloužit jako objem dat, které má najednou načíst z bufferu, který se mu postupně plní daty z šifrovaného kanálu. Informační paket je opět uzavřen středníkem pro snadnější režii na straně serveru. 17

22 Obrázek 5.3: Informace, které pro svou režii potřebuje server Takto vytvořený paket se připojí k datům, která byla načtena od exportéru. Takto vytvořený paket má nyní podobu popisující obrázek 5.4. Obrázek 5.4: Podoba paketu, z kterého se bude vytvářet podpis Z takového paketu se pak musí vytvořit podpis, kterým zajišt ujeme integritu dat a jistotu rozpoznání cizí zprávy od zprávy, kterou nám poslal námi známý odesilatel. Výhoda podpisu spočívá také v jeho velikosti. Podpis má totiž bez ohledu na obsah, který podepisuje stejnou délku. Podobu paketu po přidání podpisu popisuje obrázek 5.5. Obrázek 5.5: Podoba paketu, který se posílá serveru Takový paket se odešle šifrovaným spojením a příjme se na straně serveru. Na straně serveru se nejdříve načte podpis. Jak bylo uvedeno výše, tak podpis má pevnou délku. Stačí tedy načíst objem dat o zadané délce. Potom je třeba postupně načíst a zpracovat informační část paketu, z kterého se dozvíme velikost dat, které máme načíst z třetí části paketu. Po načtení poslední části paketu, která obsahuje data od exportéru je třeba zpátky složit informační část a datovou část a zkontrolovat ji vůči podpisu. Pokud při verifikaci nebyla zjištěna žádná chyba, pak pošleme data příslušejícímu kolektoru. Pokud bylo při verifikaci podpisu zjištěno, že bylo s daty během přenosu manipulováno, nebo že byly poslány jiným klientem než je očekáváno, pak data zahodíme a spojení mezi klientem a serverem se ukončí. 5.2 Šifrování a podpisy Pro šifrování zpráv se používá zabezpečovacího protokolu SSL. Patří mezi nejvíce používané a má výbornou podporu v programovacích jazycích (například jazyce C). Pro účely implementace se nám nabízí knihovna OpenSSL, která zahrnuje vše od šifrování, přes vytváření hash, výměny veřejných klíčů a jejich následná validace až po podpisy [1]. Pro vytváření hash se nám nabízí řada algoritmů, které mají také podporu v knihovně OpenSSL. Mezi nejvíce užívané patří MD5 a SHA-1, které mají zároveň podporu v SSL protokolu. Pro implementaci jsem vybral hash algoritmus SHA-1. Protože v roce 2004 byl 18

23 nalezen postup vytváření kolizí při použití algoritmu MD5. Navíc MD5 algoritmus má výstup o velikosti 128 bitů což je v dnešní době považováno za nedostatečné [6]. Pro šifrování se bude používat soukromých klíčů a dešifrování veřejných klíčů. Proto jsem kvůli podpoře klíčů zvolil algoritmus RSA, který pro svou práci při podepisování potřebuje soukromého klíče odesilatele a pro ověřování podpisu potřebuje veřejný klíč odesilatele. Naproti tomu druhý často užívaný algoritmus DSA byl navržen pouze pro podepisování. Navíc verifikace takového podpisu je několikanásobně pomalejší než u RSA [6]. Klíče pro šifrování a dešifrování budou mít pro vysokou bezpečnost délku 2048 bitů a budou při startu programu načítána ze souboru typu PEM. 5.3 Implementační jazyk Za implementační jazyk jsem vybral jazyk C. Tento jazyk je nízkoúrovňový a kompilovaný. Navíc je dobře přenositelný na jiné architektury. Dále obsahuje knihovny pro práci se šifrováním. 19

24 Kapitola 6 Implememtace Jak bylo uvedeno v předchozí kapitole, tak aplikace je řešena ze dvou částí. První část je implementace proxy na straně exportéru. Druhá část je implementace proxy na straně kolektoru. Programy jsou implementovány jako kolekce funkcí, kde každá funkce ohraničuje určitou funkcionalitu. V implementacích vystupují různé datové struktury, které se používají jako jednotné místo v paměti, kde jsou všechny důležité informace. Mezi tyto informace patří například adresy a porty kolektorů, nebo informace nutné pro šifrování dat. Základním datovým prvkem u klienta je struktura TSpojeni. Podrobný popis je uveden níže: proxy_kol_adresa IPv4 adresa serveru proxy_kol_port číslo portu, na kterém naslouchá server proxy_kol_socket číslo socketu, jehož prostřednictvím bude probíhat komunikace se serverem na úrovni transportního protokolu TCP ssl_ovladac číslo socketu, jehož prostřednictvím bude probíhat komunikace se serverem na úrovni SSL spojení ssl_kontext struktura uchovávající vlastnosti SSL spojení na straně klienta cert obsahuje certifikát, který poslal server klientovi rsa struktura uchovávající privátní klíč klienta certifikat cesta k souboru s certifikátem privatni_klic cesta k souboru s privátním klíčem exporter_port port, na který se připojí exportér kol_adresa IPv4 adresa kolektoru kol_port číslo portu, na kterém kolektor naslouchá Poslední tři položky ze struktury se posílají v informačním paketu směrem k serveru. Server tyto položky načte, zpracuje a uloží do své struktury. Struktury, které se používají na straně serveru jsou popsány níže. Datová struktura TSpojeni, která se používá na straně serveru: 20

25 kol_adresa IPv4 adresa kolektoru, na který se má server připojit kol_port číslo portu, na kterém kolektor naslouchá kol_socket číslo struktury, přes kterou se bude komunikovat s kolektorem sockaddr_in *sa struktura obsahující položky nutné pro UDP spojení (např. port) Datová struktura TKlice, která se používá na straně serveru: certifikat cesta k souboru s certifikátem privatni_klic cesta k souboru se soukromým klíčem validni_cert cesta k souboru s certifikáty klientů používá se pro validaci ssl_ovladac číslo socketu, jehož prostřednictvím bude probíhat komunikace se serverem na úrovni SSL spojení ssl_kontext struktura uchovávající vlastnosti SSL spojení na straně serveru rsa struktura uchovávající privátní klíč serveru 6.1 Vytvoření šifrované komunikace pomocí protokolu SSL Na obou stranách komunikace se musí vytvořit prostředky, jejichž prostřednictvím bude probíhat šifrovaná komunikace. Základem je vytvoření tzv. kontextu šifrování. Kontext je v implementaci veden jako struktura, která obsahuje informace jako: ukazatel na metody používané na straně klienta nebo na straně serveru ukazatel na soubor s certifikátem ukazatel na soubor se soukromým klíčem Do vytvořeného kontextu se musí načíst certifikát, který obsahuje veřejný klíč. Soukromý klíč, který je uložen jako samostatný soubor se musí také načíst. Nakonec se kontextu nastaví metody, které se budou na dané straně používat. Máme na výběr metody na straně klienta nebo na straně serveru. Spolu s metodami se také nastavuje verze SSL, která bude při implementaci podporována. V našem případě je to SSL verze 2 a 3. Po vytvoření a inicializaci struktury s kontextem se vytváří SSL socket, což je obdoba TCP socketu. Po samotném vytvoření SSL socketu se tento socket sváže s TCP socketem. V dalších krocích se implementace liší jak na straně, tak na straně serveru. Na straně klienta se dále už jen volá funkce pro vytvoření SSL spojení. Poté co je spojení navázáno klient čeká na příjem certifikátu, který mu server automaticky posílá. Na straně serveru se musí nastavit chování serveru po připojení klienta. Server se může zachovat dvěma možnými způsoby, a to že server požádá klienta o jeho certifikát obsahující veřejný klíč nebo o něj nepožádá. V našem případě potřebujeme klientův certifikát pro práci s podpisem klienta. Po nastavení této možnosti se specifikuje soubor obsahující certifikát, s kterým se bude porovnávat certifikát přijatý od klienta. Je tedy nutné, aby certifikát klienta byl zároveň fyzicky přítomen na počítači, kde běží server. Po těchto nastaveních se volá funkce pro akceptaci připojení po šifrované vrstvě. Po připojení klienta, server obdrží od klienta jeho certifikát, který zkontroluje vzhledem k certifikátu, který má server u sebe. 21

26 Z certifikátu server vybere veřejný klíč, který poté zkontroluje, zda jde o klíč vygenerovaný algoritmem RSA, který má podporu v této implementaci. Postup činností klienta a serveru je znázorněna na obrázku Zpracování parametrů popisující propojení mezi kolektorem a exportérem Implementace obsahuje funkci pro zpracování vstupních parametrů programu, které obsahují informace o IPv4 adrese a portu kolektoru, IPv4 adrese a portu serveru a portu, pomocí kterého se připojí exportér ke klientovi. Parametry se při spuštění programu zadávají v následující podobě: adresa serveru: -p IPv4_ADRESA:PORT adresa kolektoru: -k IPv4_ADRESA:PORT port, na kterém naslouchá klient: -e PORT Argumenty parametrů se do funkce pro zpracování parametrů dostávají jako pole znaků. Adresa kolektoru a serveru se testuje pomocí regulárního výrazu, který kontroluje, zda uživatel zadal adresy ve správném formátu. V případě portů se musí argument vstupního parametru překonvertovat na celočíselnou podobu. Pokud uživatel zadal adresy ve špatném formátu, nebo nezadal některý z parametrů, pak program končí s výpisem chybové hlášky. 6.3 Vytvoření TCP spojení se serverem Pokud byla všechna potřebná data správně načtena ze souboru popřípadě ze vstupních parametrů a uložená do struktury TSpojeni, pak program pokračuje vytvořením TCP spojení se serverem. Před samotným navázáním spojení se vytvoří a inicializují struktury, potřebné pro TCP komunikaci. Po vytvoření prostředků se vytváří TCP spojení. 6.4 Vytvoření podpisu zprávy Zde se nejdříve vytvoří hash původní zprávy. Používá se hash algoritmus SHA-1, který ze vstupu vytvoří řetězec dlouhý 20 bajtů. Takto vytvořený řetězec se předá další funkci pro vytvoření samotného podpisu. Dále se této funkci předá soukromý klíč odesilatele. Výsledkem této funkce je podpis o fixní délce 256 bajtů. 6.5 Odeslání informací o adresách kolektorů Když máme vytvořeno šifrované spojení, pak může klient poslat informace o adrese a portu kolektoru serveru. Tyto informace byly načteny už dříve ze vstupních parametrů programu. Podoba paketu a vysvětlení jednotlivých položek je vysvětlena v kapitole popisující návrh programu 5.2. Informační paket se vytvoří načítáním údajů ze struktury TSpojeni, jejichž postupným konvertováním na řetězec a spojením dohromady. 22

27 Nakonec se z paketu vytvoří podpis a tento podpis s původním paketem se pošle po šifrovaném spojení. 6.6 Spojení s exportérem a jeho obsluha Na počátku se vytvoří socket, který slouží ke komunikaci s exportérem. Poté se nově vytvořený socket naváže na port, na kterém bude proces naslouchat, tj. bude přijímat data od exportéru. K tomu nám poslouží funkce bind(), která se volá v cyklu tak dlouho, dokud nenaváže spojení s exportérem. To nastane, když nám exportér pošle první data. Toto spojení je na rozdíl od spojení mezi oběma proxy utvářeno nad transportním protokolem UDP. Když máme vytvořeny a inicializovány zdroje pro komunikaci po UDP, tak můžeme započít samotnou komunikaci. To se děje v nekonečném cyklu, ve kterém se jako první načítají data, která přicházejí z portu, na kterém proces naslouchá. Tyto data se musí poslat směrem k serveru spolu s paketem, který obsahuje řídící informace (viz. obrázek 5.4). Po načtení dat a vytvoření informačního paketu je třeba vytvořit podpis. Po vytvoření podpisu je možné celý paket (viz. obrázek 5.5) poslat směrem k serveru. Na standardní výstup nebo do souboru se postupně v každém projití cyklu vypíše hláška o úspěšném přeposlání dat. Následuje kapitola popisující implementaci serveru. 6.7 Popis činnosti serveru Největší součástí implementace proxy na straně kolektoru je funkce pro navázání spojení s klientem a posílání dat směrem ke kolektorům. Na počátku funkce se opět vytvoří zdroje pro navázání spojení s novým klientem. Pokaždé když klient požádá o spojení se vytvoří nový proces, který bude obsluhovat daného klienta. Jako první se vytvoří šifrované spojení. Poté se začnou načítat data z druhé strany. Jako první server dostane paket, který v sobě obsahuje podpis a informaci o adrese kolektoru na který se má připojit (viz. podoba paketu: 5.2). Podpis, který má pevnou délku se načte v jednom kroku. Paket se načítá postupně po jednom znaku dokud se nenačte středník, který oznamuje konec zprávy. Po dokončení příjmu se informační paket zkontroluje proti podpisu. Získaný paket se potom zkontroluje regulárním výrazem, který navíc rozdělí celý řetězec do podřetězců. Takovéto podřetězce se pak postupně budou ukládat do struktury TSpojeni. Volný pamět ový prostor se pro strukturu TSpojeni nejdříve alokuje. Když máme ve struktuře TSpojení všechna potřebná data, pak může započít postupné vytváření zdrojů pro komunikaci s kolektorem. Po navázání spojení s kolektorem se začnou načítat pakety od klienta. Paket obsahuje podpis, informaci o objemu dat a nakonec samotná data. Po načtení celého paketu se oddělí podpis od zbytku paketu. Nakonec se provádí verifikace zprávy pomocí podpisu a veřejného klíče klienta. Popis postupu činností klienta a serveru popisuje obrázek

28 Obrázek 6.1: Postup vytváření SSL spojení mezi klientem a serverem 24

29 Obrázek 6.2: Postup činností klienta a serveru 25

30 Kapitola 7 Testování Testování probíhalo propojením exportéru a kolektoru pomocí klienta a serveru a zkoumáním přenosu mezi nimi pomocí nástroje pro analýzu sít ového přenosu. Výstup ze sít ového analyzátoru je znázorněn na obrázku 7.1. Obrázek 7.1: Výstup programu Wireshark, kterým byl analyzován přenos dat Obrázek zobrazuje seznam záznamů, kde každý záznam představuje činnost na síti. Mezi tyto činnosti patří odeslání dat o určité velikosti na cílový port jiné aplikace, nebo potvrzení doručení paketu, které obstarává protokol TCP. Záznamy, které jsou zabarveny tmavší barvou popisují toky dat mezi exportérem a klientem, nebo také kolektorem a serverem. Záznamy, které jsou ve světle šedé barvě popisují toky dat mezi klientem a serverem. Pomocí obrázku lze dokázat, že všechna data, která se přijmou od exportéru se přes klienta a server dostanou ke kolektoru. V tomto případě testování sice probíhalo na jednom počítači, testem se však mělo prokázat, že z důvodu režie zpracování dat během přenosu nedochází k zahazování dat přijatých od exportéru. Z obrázku je dále patrné, že objem dat, který protéká mezi klientem a serverem je menší než mezi klientem a exportérem, nebo serverem a kolektorem. Je to dáno tím, že v SSL komunikaci dochází před odesláním dat k jejich komprimaci. Ve světleji zabarvených záznamech vystupují dva typy protokolů: TLSv1 a TCP. První znázorňuje šifrovanou komunikaci směrem od klienta k serveru. Druhý znázorňuje potvrzení doručení paketu. Tím je dokázáno, že spojení je opravdu šifrováno a probíhá na transportním protokolu TCP, který zaručuje doručení paketů druhé straně. Protokol TLSv1 je zde vyznačen, protože program pro monitorování a analýzu sít ového provozu nerozlišuje mezi TLSv1 a SSLv3. 26

31 Další test spočíval v ověření, zda server dokáže rozeznat upravenou, nebo neočekávaným klientem podvrženou zprávu. Jak bylo popsáno výše, server pokus o podvržení nebo upravení zprávy dokáže rozpoznat pomocí podpisu, který se ověří vůči zbylému příchozímu paketu. Test se prováděl formou unit testu, kde se na straně klienta vytvořil podpis a tento podpis se připojil k jiné zprávě. Takto vytvořený paket se pošle směrem k serveru. Na straně serveru došlo k rozpoznání pokusu o úpravu zprávy během přenosu. Dalším testem jsme měli za úkol rozpoznat podvrženou zprávu. Test probíhal jednorázovým použitím cizího soukromého klíče při podpisu zprávy. Cizí soukromý klíč nemá vazbu na certifikát, který byl poslán serveru. Takto vytvořený paket byl odeslán serveru, který pokus o podvržení zprávy rozeznal. Po rozpoznání pokusu o doručení podvržené nebo během přenosu upravené zprávy server správně ukončil spojení s daným klientem. Klient rovněž zareagoval ukončením spojení. Dále se testovalo, zda server dokáže obsluhovat více klientů najednou. Test probíhal spuštěním klientů na dvou různých počítačích. Klientům se pomocí parametrů nastavila adresa stejného serveru. K oběma klientům se připojil jeden exportér a server se připojil k dvěma kolektorům. Data byla načítána od obou exportérů a pomocí klienta a serveru byla přeposlána oběma kolektorům. Posledním testem jsme měli ověřit, zda server rozpozná pokus o přihlášení uživatele, jehož certifikát není mezi validními certifikáty na straně serveru. Před testem byl vytvořen nový certifikát. Tento certifikát byl použit při pokusu o připojení na server. Server identifikoval příchozí certifikát a provedl kontrolu vůči validním certifikátům, které má uložené v jednom souboru. Při kontrole byl rozpoznán pokus o přihlášení uživatele s neznámým certifikátem. K testování byly použity nástroje: exportér: fprobe kolektor: nfcapd analyzátor sít ového provozu: Wireshark K testování byly použity certifikáty a soukromé klíče vygenerované na webových stránkách: Testování probíhalo na počítačích v laboratoři FIT VUT. 27

32 Kapitola 8 Závěr Cílem této práce bylo realizovat zabezpečený transport dat v NetFlow. Konfigurace propojení mezi jednotlivými exportéry a kolektory se dá popsat pomocí parametrů při spuštění programu pomocí příkazového řádku. Cíl této práce byl splněn a nyní lze vytvářet zabezpečené spojení mezi kolektory a exportéry, které spolu komunikují přes veřejnou nebo soukromou sít prostřednictvím svých proxy programů, které řídí šifrovanou komunikaci. Samotné šifrování užitečného obsahu se provádí na straně proxy exportéru. Na straně proxy kolektoru se provádí dešifrování a přeposílání dat na kolektor. K zabezpečení spojení byl použit protokol SSL, který dnes patří mezi nejužívanější. Navíc má dobře zpracovanou dokumentaci svých prostředků pro realizaci šifrovaného přenosu. Veřejné a soukromé klíče využívané pro šifrování a dešifrování jsou generovány pomocí algoritmu RSA. Testování aplikace prokázalo, že program přesune veškerá data, která přijal ze strany exportérů směrem ke kolektorům, bez jediné ztráty. Dále se prokázalo, že server dokáže rozeznat narušená data nebo pokus podvržení zprávy neočekávaným klientem. K vypracování této bakalářské práce bylo potřeba prostudovat problematiku NetFlow a zabezpečení přenosu dat po síti. Dále bylo potřeba si osvojit základy programování sít ových prostředků. Nakonec se seznámit s prostředky, které pro možnosti šifrování nabízí knihovna OpenSSL. Na závěr ještě vypíšu možnosti rozšíření, které by bylo možné do projektu zakomponovat: v tomto projektu se počítá pouze s adresami IP verze 4, s budoucím rozmachem adres IP verze 6 by bylo dobré tuto možnost realizovat pro vytvoření plnohodnotnější šifrované sítě by bylo dobré přidat možnost klientovi směrovat data šifrovaným přenosem na více než jeden server realizace schopnosti serveru přijímat certifikáty, které byly podepsány certifikační autoritou realizace dočasného ukládání dat od exportéru na straně klienta v případě že dojde k přerušení komunikace mezi serverem a klientem na úrovni fyzické vrstvy TCP/IP modelu 28

33 Literatura [1] Open SSL [online]. Dostupné z , [Online; navštíveno ]. [2] Dostalek, L.: Administrace a diagnostika sítí, pomocí OpenSource utilit a nástrojů. Computer press, 2004, isbn [3] Halfar, P.: Zabezpečený transportní protokol monitorovacích systémů. Diplomová práce, FIT VUT v Brně, URL [4] Karger, M.: WWW průvodce moderní kryptografií. Diplomová práce, FAI UTB ve Zlíně, URL pdf?sequence=1 [5] Odvárka, P.: SSL protokol. Dostupné z , [Online; navštíveno ]. [6] Pospíšil, K.: Výkonnostní testy kryptografických algoritmů. Diplomová práce, FIT VUT v Brně, URL http: //secreg.utko.feec.vutbr.cz/sites/default/files/bc_xpospisil_no_lic.pdf [7] Šoltés, M.: Nástroj pro práci s daty NetFlow. Diplomová práce, FIT VUT v Brně, URL 29

34 Přílohy 30

35 Seznam příloh A Obsah CD 32 A.1 Adresářová struktura B Spuštění programů 33 B.1 Spuštění proxy exportéru: B.2 Spuštění proxy kolektoru: C Tabulky popisující formáty paketů, přenášené v NetFlow 35 31