Masarykova univerzita Fakulta informatiky Rozdělení síťových toků podle časových charakteristik Bakalárska práca Tomáš Dobrôtka Brno, 2012 Prehlásenie Prehlasujem, že táto bakalárska práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj. Tomáš Dobrôtka Vedúci práce: Mgr. Pavel Piskač ii Poďakovanie Na tomto mieste by som rád vyjadril poďakovanie vedúcemu práce Mgr. Pavlovi Piskačovi za jeho odborný dohľad pri analýze dát a poskytnutie užitočných rád a v neposlednom rade za pomoc pri interpretácii výsledkov. iii Zhrnutie Bakalárska práca sa zaoberá analýzou sieťových tokov, pričom cieľ práce predstavuje detekcia a popis charakteristík tokov, založených na veľkosti paketov a časových značkách. Sieťové toky bolo potrebné pred analýzou roztriediť do skupín podľa určitých vlastností, aby bolo možné efektívne vyhľadávanie vzorov, k práci s tokmi sme navrhli a vytvorili sadu skriptov a modulov, ktoré zohľadňujú typ vyhľadávaných charakteristík. Záver je venovaný spracovaniu a analýze tokov, spojený s interpretáciu získaných výsledkov. iv Kľúčové slová protokol, tok, paket, NetFlow, časové značky, charakteristika, klasifikácia tokov v Obsah 1 Úvod................................... 2 2 NetFlow................................. 3 2.1 Použitie NetFlow......................... 4 2.2 IP Tok................................ 5 2.3 Architektúra............................ 7 2.4 Exportný formát.......................... 8 2.4.1 Verzia 5 .......................... 8 2.4.2 Verzia 7 .......................... 9 2.4.3 Verzia 8 .......................... 9 2.4.4 Verzia 9 .......................... 10 3 Protokoly aplikačnej vrstvy...................... 11 3.1 File Transfer Protocol....................... 11 3.2 Secure Shell............................ 11 3.3 Simple Mail Transfer Protocol.................. 12 3.4 Domain Name System...................... 12 4 Skripty na spracovanie tokov..................... 13 4.1 Formát vstupných dát...................... 13 4.2 Skripty a moduly......................... 14 5 Charakteristiky a vzory tokov .................... 18 5.1 Zápis charakteristík a vzorov tokov............... 19 5.2 Analýza sieťových protokolov................. 21 5.2.1 File Transfer Protocol................... 21 5.2.2 Secure Shell........................ 24 5.2.3 Simple Mail Transfer Protocol.............. 25 5.2.4 Domain Name System.................. 28 5.3 Zhrnutie používania skriptov a analýzy dát.......... 29 6 Záver................................... 31 A Obsah přiloženého CD ........................ 32 1 Kapitola 1 Úvod Technológie počítačových sietí umožnili obrovský rozmach internetu, čo do počtu užívateľov, tak i do množstva obsahu, ktorý je užívateľom dostupný. Prístup k vybranému obsahu sa líši aplikáciami, službami a protokolmi, čo sa odzrkadľuje na používaní rôznych štandardov z vrstiev ISO/OSI (International Standards Organization/Open System Interconnection)1 modelu. V dôsledku zvyšovania množstva obsahu dochádza k zvyšovaniu objemu prene-sených dát, čo kladie ďalšie požiadavky (bezpečnosť, priepustnosť, oneskorenie atď.) na sieťovú infrastrukturu. Základnou súčasťou moderných systémov sú nástroje na monitorovanie a analýzu sieťovej prevádzky, ktoré s ďalšími nástrojmi tvoria ucelené riešenie správy siete. Začiatok monitorovania stavu siete ako takej pripisujeme protokolu Simple Network Management Protocol (ďalej len SNMP). SNMP bol navrhnutý na sledovanie sieťových komponentov z pohľadu ich funkčnosti a dostupnosti na modeli klient - server. Nevýhodou je, že pomocou SNMP nie sme schopní detailne sledovať toky v sieti. S riešením tohto problému prišla až spoločnosť Cisco Systems, ktorá uviedla otvorený protokol NetFlow[l]. Neskôr bol rozširovaný až do aktuálnej verzie 9 a slúži na monitorovanie sieť ovej prevádzky na základe IP tokov v reálnom čase. V druhej kapitole sa podrobne venujeme protokolu NetFlow, jeho významu, fungovaniu, využitiu, architektúre a exportnému formátu. Tretia kapitola sa zaoberá sieťovým protokolmi, ktoré boli v rámci praktickej časti boli analyzované. Vybrali sme štyri odlišné protokoly, na ktorých boli hladané určité charakteritiky. Praktická časť začína štvrtou kapitolou, ktorá sa zaoberá účelom vytvorenej sady skriptov a modulov. Postupne prechádza jednotlivými skriptami a formátom dát, ktorý je spracovávaný skriptami. Nasledujúca kapitola je venovaná spracovaniu a analýze NetFlow dát, ktoré boli rozšírené o časové značky. 1. Abstraktný model založený na vrstvách, popisujúci ich funkcie a služby siete 2 Kapitola 2 NetFlow NetFlow je technológia vyvinutá spoločnosťou Cisco Systems na monitorovanie sieťovej prevádzky, i keď sa jedná o otvorený protokol, je chránený patentom1. Cisco Systems implementuje NetFlow v rámci sieťových zariadení podporujúcich systém Cisco IOS (Internet-work Operating System). Zvyšný výrobcovia sieť ovej infrastruktury integrovajú NetFlow, často rôznymi zmenami, ako napr. Juniper Networks (J-Flow), Hewlett-Packard a Hu-awei Technologies (NetStream), ale aj Alcatel-Lucent (Cflowd). Bolo im to umožnené po vyhlásení, že Cisco System nemá záujem uplatňovať patent nato, aby zabránilo ostáným výrobcom v implementácií podobných riešení na báze NetFlow. Pôvodne bol NetFlow vyvíjaný ako technológia na prepínanie paketov pre smerovače Cisco System. Počiatkom deväť desiatych rokov bol implementovaný do Cisco IOS 11.x ako vylepšenie technológie Cisco Fast Swit-ching. NetFlow záznam predstavoval akýsi záznam cesty uložený vo vyrovnávacej pamäti, ktorý mal zefektívniť prepínanie paketov. Prepínanie na základe záznamov sa ukázalo ako nevhodné, a preto ju okolo roku 1995 Cisco Systems nahradilo technológiou Cisco Express Forwarding. Vývoj NetFlow ako protokolu na monitorovanie siete, stále pokračuje aktuálnou verziou 9, ktorá sa stala podkladom pre vznik IETF protokolu IPFIX (Internet Protocol Flow Information Export), ktorý ma reprezentovať univerzálny štandard. Verzia 1, ktorá bola prvotným exportným formátom podporovaným Cisco IOS 11.0, sa už skoro nepoužíva. Cisco Systems ho neodporúča nasadzovať, pokiaľ túto verziu nevyžaduje samotný systém pre svoje používanie. Verzie 2, 3, a 4 boli interné a neboli nikdy vydané, verzia 6 už nie je v súčasnosti podporovaná. 1. United States Patent 6,243,667 3 2. NetFlow 2.1 Použitie NetFlow S NetFlow je možné zachytávať rozsiahly súboru štatistík o sieti. Tieto štatistické dáta obsahujú informácie o čase, protokole, porte a typu služby, podrobnejšie sa danej téme venuje podkapitola Exportný formát NetFlow. Na základe vyššie spomenutých atribútov dokážeme povedať kto, s kým, kedy a ako dlho komunikoval. NetFlow sa používa na rôzne účely[2], akými môžu byť analýza sieť ovej prevádzky a plánovanie kapacity liniek, bezpečnosti, fakturácie zo strany poskytovateľov internetu. • Monitorovanie užívateľov a aplikácií - NetFlow umožňuje monitorovanie siete takmer v reálnom čase. Detailná štatistika vyťaženia siete aplikáciou v čase sa dá využiť napríklad na plánovanie a alokáciu siete samotnej, ale aj ďalších zdrojov pre danú aplikáciu. NetFlow poskytuje proaktívnu detekciu problémov na sieti a ich odstraňovanie. Ďalšou možnosťou je efektívna alokácia sieťových zdrojov na detekciu a riešenie potenciálnych bezpečnostných rizík. Techniky založené na analýze NetFlow exportov sa používajú k prehľadnému zobrazovaniu IP tokov2, ktoré prechádzajú monitorovanou sieťovou. • Plánovanie a analýza siete - zachytené NetFlow dáta za dlhší časový úsek poskytujú náhľad na využívanie siete, predvídať rast siete a plánovať modernizáciu sieť ových prvkov. Exporty obsahujú aj dôležité údaje pre optimalizáciu strategického plánovania siete, ako kto s kým komunikuje, rozširovanie sieťových liniek a plánovanie smerovacej politiky. Hlavným cieľom je minimalizácia nákladov na sieťovú infrastrukturu a pritom maximalizovať výkon, kapacitu a spoľahlivosť. • Bezpečnostná analýza - NetFlow dáta sa dajú využiť na identifikáciu komunikácie škodlivého softvér. Zmeny v správaní siete indukujú anomálie, ktoré sa zreteľne prejavia v NetFlow záznamoch. Tieto dáta sú cenným nástrojom, ktorý napomáha pochopiť a opätovne reagovať na bezpečnostný incident z minulosti. • Účtovanie a platby - záznam IP toku obsahuje napríklad zdrojové a cílové IP adresy, počet paketov a bytov, časové známky (začiatok a koniec toku), port aplikácie a typ služby. To robí z NetFlow metriku vhodnú pre vysoko flexibilné a podrobné účtovníctvo využívania zdrojov. Poskytovatelia pripojenia využívajú tieto informácie k preplácaniu svojich služieb, na základe objemu prenesených dát, na zá- 2. jednosmerná postupnosť paketov medzi zdrojom a cieľom 4 2. NetFlow klade času, počas ktorého boli služby využívané, na základe využitia šírky pásma a využitia aplikácie alebo na základe kvality služby. • Plánovanie sieťovej prevádzky - NetFlow umožňuje pochopiť sieťovú prevádzku v smere od zdroja k cieľu. Dáta sú využívané k vyvažovaniu záťaže na linkách, alebo k preposielaniu určitej prevádzky preferovanými trasami. Tam však ešte možnosti NetFlow nekončia, pretože sa využíva aj na meranie množstva dát, ktoré pretečie transportnými uzlami. • Ukladanie NetFlow dát a data mining - NetFlow exporty môžu byť uložené k neskoršej analýze, na základe ktorej sa vytvárajú rôzne obrazy sieť ovej prevádzky, s analýzou je často spojené aj generovanie štatistík a grafov vyťaženia jednotlivých liniek, z takto reprezentovaných dát je jednoduchšie zistiť, ktoré aplikácie alebo služby zákazníci používajú, resp. potrebujú. 2.2 IP Tok Za základnú jednotku NetFlow považujeme IP tok, ďalej len tok. Tok je definovaný ako jednosmerná postupnosť paketov medzi zdrojom a cieľom -na sieť ovej vrstve (IP adresa) a transportnej vrstve (port služby), z pohľadu NetFlow je tok jednosmerný, čo má za následok, že obojsmerná komunikácia medzi dvoma bodmi v sieti by pozostávala minimálne z dvoch tokov. Na jedinečnú identifikáciu toku tradičný NetFlow používa sedem atribú-tov[3]: • zdrojová IP adresa • cieľová IP adresa • zdrojový port (pre UDP3/TCP4, ostatné protokoly 0) • cieľový port (pre UDP/TCP, typ a kód ICMP5, ostatné protokoly 0) • protokol sieť ovej vrstvy • typ služby (Type of Service byte) 3. User Datagram Protocol je nespoľahlivý protokol na prenos datagramov po sieti[4] 4. Transmission Control Protocol je spoľahlivý komunikačný protokol transportnej vrstvy [5] 5. Internet Control Message Protocol sa používa na zasielanie chybových správ v sieti[6] 5 2. NetFlow • vstupné/výstupné rozhranie Ak by zachytený paket mal jeden z vyššie uvedený atribútov odlišný, bol by považovaný za súčasť iného toku. Tok však môže obsahovať aj ďalšie atribúty, napr. NetFlow export verzie 5 je rozšírený o číslo autonómneho systému6, o tom aké atribúty obsahuje určitý záznam toku, rozhoduje použitá verzia NetFlow exportného formátu záznamu. Nový tok vzniká zachytením paketu, ktorý nepatrí do žiadneho už existujúceho aktívneho toku. Nasledujúce pakety, patriace do tohto toku, sú rozpoznané na základe hodnôt spomenutých vyššie a tvoria záznam dát o toku. k ukončeniu aktívneho toku, resp. záznamu môže dôjsť v nasledujúcich štyroch prípadoch: • vypršaním neaktívneho časovaču • vypršaním aktívneho časovaču • zaplnením cache pamäti, v ktorej sú uložené informácie o tokoch • detekováním príznaku FIN (FINished, ukončenie TCP spojenia) alebo príznaku RST (ReSeT, vzdialený hostiteľ resetoval spojenie) Aktívny i neaktívny časovač definujú maximálnu dobu, počas ktorej je aktívny tok udržiavaný vo vyrovnávacej pamäti zariadení. Pod neaktívnym časovačom rozumieme dobu, ktorá uplynie od získania posledného paketu daného toku. Po uplynutí neaktívneho časovača je záznam toku ukončený a čaká na export. Hodnota je uvádzaná v sekundách a je přednastavená na 15 sekúnd (parameter je možné nastaviť v rozmedzí 10-600 sekúnd). Aktívny časovač je ďalším konfigurovateľným parametrom monitorovacích zariadení, v tomto prípade hovoríme o dobe, ktorá uplynie od prvého paketu daného toku, pričom sa následne tok ukončí a je vyexportovaný, v dôsledku toho nasledujúci paket, ktorý by patril ešte do toku, sa stáva počiatočným paketom nového toku. Môže dochádzať k rozdeľovaniu dlhších tokov na časovo kratšie toky, v závislosti od nastavení tohto parametru a dĺžky tokov v sieti. Cisco System má aktívny časovač na svojich zariadeniach přednastavený na 30 minút (nastavenie je obmedzené v rozmedzí 1-60 minút), v reálnom nasadení sa častejšie používajú pre aktívny časovač nižšie hodnoty v jednotkách minút, pretože môže dochádzať k zaplneniu cache pamäti. Vtedy dochádza k vybratiu najstaršieho toku vo vyrovnávacej pamäti a je označený za skončený. 6. je množina IP sietí pod spoločnou správou, ktorá reprezentuje voči Internetu spoločnú smerovaciu politiku 6 2. NetFlow 2.3 Architektúra Pod architektúrou NetFlow rozumieme usporiadanie zariadení na získavanie, prenos a spracovanie NetFlow dát. Predtým je však vhodné popísať proces fungovania NetFlow, a to z dôvodu, že jeho časti sú do veľkej miery previazané so samotnou architektúrou. NetFlow proces je rozdelený do troch základných častí: • Monitorovanie tokov - zahŕňa nielen monitorovanie, ale aj zber informácii o tokoch a ich následný export. Zariadenie, ktoré sa o to stará sa nazýva exportér. Exportéry po ukončení tokov majú na starosti odosielanie záznamov transportným protokolom na kolektor. • Zber NetFlow záznamov - kolektor prijíma informácie o tokoch odoslané exportérom. Zároveň tento kolektor zbiera a spracováva NetFlow dáta z viacerých exportérov. Záznamy, prijaté v tejto fáze, môžu byť na základe požadovaných atribútov ďalej filtrované, prípadne agregované. Takto získané dáta o tokoch je možné uložiť do súboru, resp. databázy alebo priamo poskytnúť na ďalšie spracovanie (napr. pri spracovaní NetFlow v reálnom čase). • Analýza získaných dát - sa zaoberá spracovaním NetFlow záznamov, jej výsledkom môže byť grafická reprezentácia dát v podobe rozličných grafov v závislosti od sledovaných vlastnostiach a parametroch sieťovej prevádzky. Exportéry monitorujú komunikáciu na sieťovej vrstve a obvykle sa jedná o hardwarové zariadenie. Úlohy exportéru zastávajú aktívne sieťové prvky, akými sú smerovače a prepínače, i keď ich primárnou úlohou je zabezpečiť smerovanie/prepínanie paketov, a až sekundárnou úlohou je tvorba NetFlow štatistík. Výpočet štatistík môže mať v krajných prípadoch dopad na smerovací výkon celého zariadenia, preto bola pridaná podporada vzorkovania paketou na vstupe pre niektoré modely smerovačov. Myšlienka vzorkovania spočíva v tom, že na výpočet sa používa iba každý n-tý paket. Častejšie sa však v sieť ach stretávame s iným typom exportéru, NetFlow sondy. Sondy prechádzajúce dáta iba monitorujú a nezasahujú do nich, preto patria k pasívnym sieťovým prvkom, na rozdiel od smerovačov. Ďalší rozdiel oproti smerovacom je ten, že sondy je možné pripojiť do ľubovoľného bodu v sieti. To je možné za pomoci zariadenia TAP7 alebo zariadenia 7. hardvérové zariadenie, ktoré poskytuje prístup sieti 7 2. NetFlow SPAN (Switch Port ANalyzer)8. z pohľadu siete sú sondy transparentné. Hardwarová akcelerácia predurčuje sondy k nasadeniu na veľmi rýchlych a vyťažených linkách. 2.4 Exportný formát Po dosiahnutí aktívneho a neaktívneho časovača, sú toky zoskupené do exportných paketov NetFlow a zasielané na kolektor. Počet záznamov obsiahnutých v paket závisí od použitej verzie NetFlow protokolu, no maximálne 30 (verzia 5 a 9) záznamov na paket. Pre všetky verzie NetFlow paket pozostáva z hlavičky a sekvencie záznamov o tokoch. Hlavičky a záznamy NetFlow sú silno previazané s verziou NetFlow, preto formát záznamov bude presnejšie popísaný v ďalších častiach, ktoré sa podrobnejšie venuje rôznym verziám NetFlow (1, 5, 7, 8, a 9) a ich vzájomným odlišnostiam. 2.4.1 Verzia 5 Verzia 5 sa stala prvou širokopoužívanou aj vďaka tomu, že pridala k predchádzajúcej verzii dve podstatné vylepšenia. Prvým vylepšením je pridaná informácia o zdrojovom a cieľovom autonómnom systéme (AS), založená na protokole BGP9. Druhým vylepšením je pridanie poradového čísla toku do hlavičky NetFlow paketu. Pretože NetFlow využíva UDP k exportu datagramov, je tu možnosť, že datagramy sa pri prenose stratia. Okrem toho, že UDP nevie zaručiť doručenie datagramu, ďalší problém s tým spojený je, že UDP neposkytuje informáciu o tom, že datagram sa stratený. Práve tento nedostatok odstraňuje nový pridaný atribút vo verzii 5, t.j. vieme zistiť, či bol určitý tok exportovaný alebo nie. Detekcia stratených paketov sa deje v réžií protokolu NetFlow s využitím overovania poradia. Poradové číslo by malo byť rovné súčtu predchádzajúceho poradového čísla a počtu záznamov v predchádzajúcom datagrame. Aplikácia po prijatí nového datagramu odpočíta predpokladané poradové číslo od poradového čísla uvedeného v hlavičke, aby získala počet chýbajúcich záznamov, t.j. nenulová hodnota rozdielu zodpovedá počtu stratených záznamov[7]. Datagram NetFlow verzie 5 má pevne stanovenú štruktúru, ktorá pozostáva z hlavičky a záznamov tokov. Hlavička obsahuje polia, ako verziu 8. analyzuje sieťovú prevádzku prechádzajúcu cez porty a preposiela kópiu premávky 9. Border Gateway Protocol - protokol zabezpečujúci základné smerovanie na backbone linkách. Udržuje tabuľku IP sietí alebo prefixov daných sietí, ktoré označujú, či sieť je dostupná naprieč autonómnym systémami 8 2. NetFlow exportného formátu, počet tokov pakete (medzi 1-30) a informácie o čase nasledované poradovým číslom toku, typom a číslom slotu prepínača. Posledné pole je vyhradené vzorkovaciemu módu a hodnote vzorkovacieho intervalu. 2.4.2 Verzia 7 Oproti verzii 5 obsahuje v zázname o toku pole router_sc. Pri využitím viacvrstvového prepínania sú na kolektor zasielané dva záznamy - jeden z prvku, sfárajúceho sa o smerovanie prvého paketu toku a druhý z prvku zabezpečujúceho preposielanie zvyšnej časti toku. Princíp sa zakladá na tom, že smerovanie paketov je vzhľadom na výkon podstatne náročnejšie ako prepínanie, a keď vieme, kam prvý paket smeruje, zvyšné pakety toku už stačí prepínať. Pole router_sc obsahuje IP adresu MSFC, a to preto, aby bolo možné oba záznamy toho istého toku zlúčiť do jedného, pretože záznamy mali rozdielne zdrojové IP adresy. 2.4.3 Verzia 8 Charakteristikou tejto verzie je pridaná podpora pre agregačné schémy (ďalej len schéma), ktorá je tvorená kombináciou rôznych polí toku, tie sú pevne dané predvolenými schémami[8].Agregácia založená na smerova-čoch prináša nový druh vyrovnávacej pamäti do architektúry NetFlow, vznik samostatnej agregačnej pamäti je previazaný s použitím určitej schémy. Je možné využívať viac schém súčasne, preto aj počet agregačných pamätí je variabilný. Na základe schém sa rozhoduje o aktualizácii zodpovedajúceho toku v agregačnej pamäti. Schéma sa aplikuje na expirované toky v hlavnej pamäti. Ak je agregácia povolená, nie je dôvod exportovať záznamy z hlavnej vyrovnávacej pamäti (NetFlow v5), pretože by dochádzalo k zasielaniu redundantných informácii zo strany smerovača.Výnimkou je prípad, ak obsah z hlavnej pamäti je exportovaný na jeden kolektor (z dôvodu monitorovania bezpečnosti), zatiaľ čo obsah z agregačenej pamäti je exportovaný na ďalší kolektor z dôvodu účtovania. Agregácia exportovaných dát typicky prebieha na strane NetFlow exportéru, t.j. dáta sa zosumarizujú na strane smerovača a následne exportujú. Toto riešenie má hneď niekoľko výhod, ako nižšie nároky na prenosové pásmo medzi smerovacom a pracovnými stanicami, ale aj zlepšenie výkonu a škálovateľnosti na smerovačoch, ktoré spracúvajú veľké objemy tokov. Vzhľadom na kombináciu použitých polí je tvorený aj formát exportovaného záznamu, ktorý je pre každú schému špecifický. Obmedzením je, že 9 2. NetFlow exportný formát verzie 8 je dostupný iba pre agregačné vyrovnávacie pamäti, a nemôže byť rozšírený o ďalšie prvky. 2.4.4 Verzia 9 Základným výstupom NetFlow je záznam toku, ten zaznamenal v priebehu času niekoľko väčších, či menších zmien, ktoré sme si spomenuli vyššie. Prístup v predchádzajúcich verziách (1, 5, 7 a 8) sa ale nezmenil, exportný formát je pevne daný a nemenný. Výnimku z určitého pohľadu tvorí verzia 8, kde exportný formát je sice nemenný, ale pre každú agregačnú. schému jedinečný. Exportný formát verzie 9 je založený na šablónach, čo robí z NetFlow flexibilný a rozšíriteľný protokol. Šablóny poskytujú rozšíriteľný návrh záznam toku (napr. pridávanie nových polí do záznamu) (závorky jsou zbytečné). Ten prístup umožňuje aby v budúcnosti mohlo dochádzať k zmenám/vylepšenia NetFlow bez toho aby bolo nutné meniť štruktúru exportovaných paketov alebo samotného protokol. Verzia 9 neprináša len možnosť rýchlejšieho pridávania nových vlastností bez porušenia súčasných implementácii ale pridáva aj nové vlastnosti a podporu pre sieťové technológie. 10 Kapitola 3 Protokoly aplikačnej vrstvy Tretia kapitola tvorí teoretický základ k spracovaniu tokov z pohľadu protokolov, na ktorých boli vyhľadávané špecifické charakteristiky. Stručný popis protokolu zahŕňa jeho použitie a fungovanie v rámci siete, to znamená aký transportný protokol sa využíva k prenosu a na ktorých portoch pracuje. 3.1 File Transfer Protocol File Transfer Protocol (FTP) [9] je sieťový protokol určený na prenos súborov z určitého uzlu na ďalší uzol a využíva pritom TCP/IP siete. FTP je založený na architektúre klient-server, pri ktorej bol kladený dôraz na komunikáciu medzi nimi s minimom obmedzení. FTP výhradne používa TCP transportný protokol, čo nie je bežné, pretože protokoly aplikačnej vrstvy majú na výber medzi TCP a UDP protokol. FTP komunikácia medzi klientom a serverom je zabezpečená pomocou dvoch spojení. Riadiace alebo príkazové spojenie na porte port 21 slúži na zasielanie FTP príkazov, druhé spojenie sa stará o prenos dát na port 20. Port 20 nemusí byť vždy využitý na prenos dát, závisí to od nastaveného FTP módu, ktorý je buď aktívny alebo pasívny. 3.2 Secure Shell Secure Shell (SSH)[10] protokol umožňuje vzdialené zabezpečené prihlasovanie, tunelovanie sieťovej prevádzky alebo preposielanie ľubovoľného TCP portu. SSH protokol bol navrhnutý, aby nahradil protokoly, akými sú telnet, rlogin alebo rsh, ktoré zasielali heslo v nezabezpečenej textovej podobe. SSH medzi klientom a serverom vytvára zabezpečený kanál. Šifrovanie používané protokolom SSH poskytuje dôvernosť a integritu dát cez nezabezpečené siete, pretože sa zakladá na šifrovaní verejným kľúčom. SSH sa skladá z hlavný hlavných častí: 11 3. Protokoly aplikačnej vrstvy • Transport Layer Protocol - poskytuje serveru autentifikáciu, dôvernosť a integritu. Ďalej môže poskytovať kompresiu, ak to prenos vyžaduje. Transport layer typicky postavený na TCP/IP spojení, avšak je možné využiť aj iný protokol zabezpečujúhlaci spoľahlivý prenos dát. • User Authentication Protocol - autentizuje klientskú časť užívateľa na serveri. • Connection Protocol - rozdeľuje zabezpečené spojenie na viacero logických kanálov. 3.3 Simple Mail Transfer Protocol Simple Mail Transfer Protocol (SMTP) [11] je protokol určený na zasielanie elektronickej pošty. SMTP je z pohľadu prenosového protokolu nezávislé, požaduje však spoľahlivý prenosový kanál, ktorý zaručí usporiadanie pa-ketov. v aktuálnom RFC je ako transportný protokol pre SMTP podrobne popísaný protokol TCP. Bez ohľadu na prenosový protokol, SMTP odosielateľ iniciuje obojsmerný kanál ku SMTP príjemcovi na porte 25. SMTP odosielateľ pošle príkazy SMTP príjemcovi a on naspäť pošle odpovede v závislosti na príkazoch, ktoré mu boli zaslané. 3.4 Domain Name System Domain Name System (DNS)[12] je distribuovaná internetová adresářová služba, ktorá sa primárne zabezpečuje preklad doménových mien na IP adresy a naopak. Všeobecne DNS uchováva rôzne typy informácii, akými sú zoznamy poštových serverov, ktoré akceptujú elektronickú poštu pre danú internetovú doménu. DNS primárne používa protokol UDP na komunikáciu a na porte 53 spracúva požiadavky. DNS dotazy pozostávajúce z jedinej UDP požiadavky klienta sú nasledované jednou UDP odpoveďou zo strany serveru. TCP protokol sa využíva vtedy, keď veľkosť dát odpovede presiahne 512 bajtov alebo pre úlohy typu zóne transfer1. Niektoré implementácie DNS resolve-rov2 používajú TCP pre všetky typy dotazov. 1. Typ dns transakcie, týkajúcej sa replikácie databáz 2. Klientská časť dns zabezpečujúca preklad 12 Kapitola 4 Skripty na spracovanie tokov Táto kapitola je venovaná praktickému prínosu tejto práce, v podobe sady skriptov a modulov, určených na spracovanie dát, ktoré sme mali k dispozícii. Dôležitú časť tvorí podkapitola venovaná formátu vstupných dát, pretože vytvorené skripty a moduly je možné do určitej miery používať nezávisle na sebe alebo z dôvodu rozšírenia o ďalšie funkcie. Pri podrobnejšom opise skriptov, okrem ich účelu budú spomenuté zmeny vo formáte záznamov, ktoré vykonávajú. Podkapitola 4.1 Formát vstupných dát preto popisuje iba vstup pre prvý skript. 4.1 Formát vstupných dát NetFlow dáta získané z kolektoru NfSen, ktoré sme používali pri práci boli rozšírené o časové značky v podobe medzipaketových medzier. Medzipa-ketová medzera pre nás predstavuje dobu, ktorá v rámci toku uplynie medzi koncom jedeného paketu a začiatku nasledujúceho.Tieto NetFlow záznamy boli uložené v textovom formáte, kde jeden riadok predstavoval jeden záznam toku. Podrobný popis parametrov, ktoré obsahuje NetFlow záznam je dôležitý pre ďalšie použitie skriptov a modulov, prípadne pre ich úpravu na odlišný NetFlow vstupný formát. Prvý a druhý parameter predstavujú začiatok a koniec toku v nanosekundách od 1. 1. 1970, nasledovaný tretím parametrom - počtom paketov, štvrtým - počtom prenesených bajtoch a piatym - identifikačným číslom protokolu sieťovej vrstvy. Šiesty a siedmy parameter reprezentujú zdrojovú a cieľovú IP adresu. Na ďalšej pozícii je identifikačné číslo transportného protokolu v následnosti zdrojového a cieľového portu služby. Počet zvyšných NetFlow parametrov záznamu je priamo úmerný počtu paketov toku, pretože obsahuje jednotlivé veľkosti paketov toku v bajtoch a medzipaketových medzier v nanosekundách. Toky, obsahujúce jeden paket, majú po cieľovom porte služby iba jeden parameter a to veľkosť paketu v bajtoch. Ukážka vstupných dát bola príliš dlhá a musela byť rozdelená na 2 riadky. 13 4. Skripty na spracovanie tokov 1318058062510266895-1318058062519780369, 5,1149, 4 1.0.0.1->1.0.0.2,6,54656:80,60,4558201,46,102597,951,4702325,46,150210,46 Záznamy, s ktorými sme pracovali, mali jednotlivé parametre oddelené čiarkou. Výnimku tvorili parametre typu začiatok a koniec toku, ktoré boli oddelené znakom „-", zdrojová a cieľová IP adresa boli oddelené pomocou znakou „->", na oddelenie zdrojového a cieľového portu bol použitý znak „:". Tento formát záznamu nebol vhodný na ďalšie spracovanie, a preto sa budeme venovať jeho úprave. 4.2 Skripty a moduly Cieľom skriptov a modulov je uľahčiť prácu so vstupnými záznamami, ktoré boli získané reálnej sieťovej prevádzky na rozhraní MU-Internet. Primárnym účelom skriptov je triedenie tokov na základe určitých parametrov tak, aby práca s danými tokmi bola čo najefektívnejšia. Sekundárny účel zahŕňa zmenu formátovania záznamov ale i rozširovanie záznamov o ďalšie údaje, ktoré pomôžu presnejšie charakterizovať komunikáciu uzlov v sieti. Pri návrhu skriptov a modulov bol kladený dôraz na modularitu celého riešenia, a s tým je spojená aj jednoduchosť a rozšíriteľnosť jednotlivých častí. Ďalšia časť sa venuje popisu funkcií jednotlivých skriptov a modulov, navyše niektoré popisy sú rozšírené o formát výstupov. Zdrojové kódy sú dostupné na priloženom CD v adresári new, k popisu daných skriptov a modulov nie sú potrebné. Na CD v adresári old sú zdrojové kódy skriptov, ktoré sme používali na začiatku analýzy a postupne upravovali tak, aby spĺňali požadované funkcie. Prvým rozdielom je, že dané skripty nepracujú automatizované, druhým potom samotná implementácia, pričom vstupný a výstupný formát zostal zachovaný, v adresári old sa nachádzajú skripty, ktorých funkcionalita nie je popísaná v tejto kapitole, čo je spôsobené tým, že v praxi sa neosvedčili a nemôžeme ich odporučiť na spracovanie dát. Skript: trigger.pl Účelom skriptu je spúšťanie ostatných skriptov a funkcií z vybraných modulov. Okrem toho je v ňom možné meniť vstupné parametre skriptov. Modul: adjust.pm Modul zabezpečuje správne formátovanie dát. Vstupné dáta, s ktorými pracuje sú popísané v kapitole 4.1. Ich formát nám však pre ďalšie využi- 14 4. Skripty na spracovanie tokov tie nevyhovoval z dôvodu oddelenia údajov rôznymi znakmi. Nekonzistentné oddeľovanie parametrov neumožňovalo spracovanie dát v aplikáciách, ktoré sme neskôr používali na analýzu tokov. Ako výstupný formát sme použili CSV1, pričom jednotlivé údaje sú oddelené bodkočiarkou Tento modul je voliteľný, to znamená, že ak dáta majú zhodné formátova-nie ako ukážka výstupného záznamu nižšie, nie je dôvod ho spúšťať. Modul: cutter.pm Modul sa stará o orezávanie dát. v našom prípade orezáva toky, ktoré obsahujú menej ako 5 paketov. Toky, obsahujúce maximálne 4 pakety sú príliš krátke, t.j. poskytujú málo špecifických informácii na jednoznačnú identifikáciu protokolov na základe veľkosti paketov a časových medzier medzi nimi. Využitie toho modulu je taktiež voliteľné. Skript: processor.pl Skript spracúva toky a rozširuje záznamy o ďalšie údaje, ktoré neskôr môžu byť použité k presnejšej identifikácii tokov, v našom prípade každý záznam toku bol rozšírený o minimálnu a maximálnu veľkosť paketu, priemernú veľkosť a smerodajnú odchýlku paketov. Rovnaké informácie sme pridali aj vzhľadom na medzipaketové medzery. Záznam bol rozšírený o osem parametrov, čo sa však nezaobišlo bez zmeny výstupného formátu. Nové údaje boli vložené s ohľadom na logickú štruktúru záznamu medzi cieľový port služby a veľkosť prvého paketu. Skript: portSieve.pl Port služby pre nás predstavuje jediný identifikátor, podľa ktorého môžeme odhadnúť protokol. Skript na základe tejto informácie triedi záznamy tokov do súborov na ďalšie spracovanie. Zoznam portov, podľa ktorých majú byť dáta roztriedené, je uložený v module ports.pm. Záznamy, ktoré nemajú zhodný zdrojový ani cieľový port s portami uvedenými v module, sú kopírované do osobitného súboru, ktorý môže byť neskôr použitý na dodatočné triedenie. Každý súbor vo svojom názve obsahuje číslo portu pre jednoduchšiu identifikáciu. Skript okrem triedenia ešte poskytuje štatistické informácie o počte vytriedených záznamov, pre každý port jednotlivo, výnimku tvoria porty, ktoré nie sú uvedené v module. 1. Jednoduchý súborový formát určený pre výmenu tabuľkových dát 15 4. Skripty na spracovanie tokov Skript: evaluator.pl Statistický skript, ktorý poskytuje informácie pre automatizované triedenie záznamov, ale aj statistiky týkajúce IP adries a veľkosti paketov. Výstup, pre každý port zvlášť, tvorí textový súbor, ktorý je určený na ručné spracovanie. Jeho obsahom sú údaje o počte tokov, počte zdrojových a cieľových IP adresách, tieto údaje sú spracované pre zdrojový a cieľový port. Ak má tok rovnaký zdrojový a cieľový port, tak sa pracuje so zdrojovým portom. Pre port 22 vyzerá ukážka nasledovne. 022 random: 215 61 11 random 022:16 2 1 Súbor ďalej obsahuje zoznam IP adries, pri ktorých je uvedený výskyt danej IP adresy, t.j. koľko tokov pochádzalo z určitého port konkrétnej IP adresy. Zápis formátu je doplnený o ukážku. (počet zhodných IP adries) IP adresa (131) 1.0.0.1 (84) 1.0.0.11 Posledná časť súboru obsahuje informácie o veľkosti paket, čo zahŕňa minimálnu a maximálnu veľkosť paketov a ich počet, pričom je zohľadnený zdrojový a cieľový port. Príklad na minimálnu veľkosť paketu (v zátvorke je uvedený počet výskytov). 52 (213); 92 (1); 46 (1); Formátovanie a štruktúra tohto súboru nie je vhodná pre automatizované spracovanie, preto výstup tvorí ešte jeden súbor, ktorý je súčasne aj vstupom pre ďalší skript. Obsahuje cestu a názov súborov, ktoré majú byť spracované, a identifikátor zdrojovej/cieľovej adresy spolu s IP adresou (zložená IP adresa). Ako oddeľovací znak medzi parametrami je použitá bodkočiarka. Počet IP adries, ktoré majú byť spracované, závisí od nastavenia vstupného parametru v skripte trigger.pl . Parameter je nastaviteľný v rozmedzí 1-100% a reprezentuje podiel počtu tokov jednej IP adresy na celkovom počte tokov na danom porte. c: \ Data\5port022.csv;srcl. 0.0. l;dstl. 0.0.2; 16 4. Skripty na spracovanie tokov Skript: ipSieve.pl Jeho úlohou je triedenie tokov podľa IP adries uvedených vo vstupnom súbore. Zložená IP adresa sa použije na jednoznačnú identifikáciu súboru, do ktorého sú ukladané záznamy, následne je rozdelená na identifikátor a IP adresu. Toky, ktorých IP adresa nie je zhodná so žiadnou uvedenou vo vstupnom súbore, sú skopírované do súboru, ktorý v názve obsahuje _rest. Skript: format.pl Tvorí poslednú fázu automatizovaného spracovania NetFlow záznamov, zameranú na zmenu formátovania dát. Zo záznamov sú vypustené údaje, ktoré nie sú skúmané v ďalšej analýze, ako začiatok/koniec toku, identifikačné číslo protokolu transportnej a sieťovej vrstvy. Cieľový a sieťový port sú presunuté medzi počet prenesených bajtov a zdrojovú IP adresu. Všetky informácie o medzipaketových medzerách uvedené v nanosekundách sú skonvertované na milisekundy, pretože aj tak poskytovali dostatočnú presnosť pre popis charakteristík a vzorov. Pri analýze sa ukázalo, že niektoré mezdzipaketové medzery sa pohybovali v jednotkách až desiatkach sekúnd. Priemerné hodnoty a smerodajné odchýlky veľkosti paketov a medzipaketových medzier sú zaokrúhlené na tri desatinné miesta. Každá z týchto zmien dopomáha k sprehľadneniu dát a zefektívneniu práce s nimi. Ukážka záznamu toku, aké sme analyzovali. 17 Kapitola 5 Charakteristiky a vzory tokov Analýza dát sa skladala z dvoch častí, prvej automatizovanej pomocou sady skriptov a následne časti manuálnej, pri ktorej boli dáta opäť postupne triedené a prechádzané. Štvrtá kapitola je zameraná na popis skriptov, ale dostatočne sa nevenuje samotnej analýze a dôvodom, prečo jednotlivé úpravy robíme. Skript processor.pl pridáva k záznamov údaje, ktoré mali pomôcť pri charakterizácii dát. Tieto údaje boli zamerané na veľkosť paketov a me-dzipaketových medzier. Rovnaké údaje využívali pri klasifikácii tokov aj T. Nguyen a G. Armitage[13][14], v ich práci ale, už nie je spomenuté, ako veľmi boli jednotlivé údaje užitočné pri identifikácii vzorov, resp. klasifikácii tokov. Maximálna veľkosť paketu spolu s aritmetickým priemerom mali, určitý význam, pretože na základe týchto hodnôt sme mohli odhadovať napríklad, či sa jedná prenos dát alebo príkazov v danom toku. v prípade minimálnej veľkosti paketov sme vedeli, aké veľké sú zasielané TCP potvrdenia. Minimálna veľkosť medzipaketovej medzery neskôr uvádzaná v milisekundách, pre nás nemala žiadny význam, pretože v 99% bola rovná nule. Oproti tomu maximálna medzipaketová medzera v toku poskytovala informácie, ktoré sa dali využiť pri charakteristike toku, s aritmetickým priemerom, to bolo o niečo horšie, pretože nie vždy poskytoval konzistentné výsledky. Údaje o smerodajnej odchýlke, či už veľkosti paketov alebo medzi-paketových medzier, sme v závere nezohľadňovali, pretože netvorili charakteristický údaj pre žiadnu skupinu tokov. Skript portSieve.pl, ktorý na základe čísla portu služby triedi toky. Čísla portov sú registrované organizáciou IANA pre sieťové protokoly, avšak aplikácie môžu využívať aj porty už registrované inými protokolmi, a tak sa maskovať[15]. Podiel sieťovej prevádzky na známych portoch klesá, a preto sa klasifikácii, ktorá sa nezakladá na portoch venuje čim ďalej viac pozornosti. Port služby pre nás predstavoval efektívny spôsob odhadova-nia sieťových protokolov vzhľadom nato, aký typ dát sme mali k dispozícii. 18 5. Charakteristiky a vzory tokov Skript ipSieve.pl triedi záznamy na základe zdrojovej alebo cieľovej IP adresy. Našim cieľom je dostatočne špecifikovať množinu tokov, tak aby sme boli schopný určiť vzor, a pritom charakterizoval, čo najviac tokov na danom porte. Predpokladáme, že toky na IP adrese budú mať jeden alebo viacej vzorov, ktoré sa budú podobať alebo aspoň toky, ktoré budú mať určité charakteristiky spoločné. Manuálna analýza a vyhľadávanie vzorov, boli realizované v prostredí Microsoft Excel 2010, pretože uspokojivo pracoval s formátom súborov CSV. Na začiatku spracovania dát, triedenie bolo vykonávané na všetkých parametroch záznamov, časom sme však prešli na triedenie, podľa veľkosti prvého paketu toku. Previazanie medzi veľkosťou paketov a medzipake-tovými medzerami umožnilo efektívne vyhľadávať vzorov založených na časových značkách. Výhodou prostredia bola taktiež možnosť generovania grafov na základe vybraného parametru, táto technika primárne slúžila na zisťovanie rozloženia hodnôt daného parametru. 5.1 Zápis charakteristík a vzorov tokov Výstupom práce, okrem skriptov a modulov sú aj vzory, resp. charakteristiky protokolov aplikačnej vrstvy. Našim cieľom bolo reprezentovať získané informácie čo najprehľadnejšie tak, aby umožňovali jednoduchú interpretáciu štruktúry získaného vzoru. Zvolili sme preto formu dvoch tabuliek, ako pre zdrojový, tak i pre cieľový port služby, to znamená, že pri každom protokole by mali byť uvedené 4 tabuľky. Tabuľky obsahujú charakteristiky analyzovaných tokov z určitej IP adresy a špecifického portu, v tabuľke Informácie o toku sme sa zamerali na štatistické informácie, ktoré charakterizovali analyzovanú skupinu tokov, ale netvorili hlavný cieľ našej práce. Štruktúra tabuľky je pevne daná. Polia, ktoré obsahuje: • zIP/cIP - počet zdrojových/cieľových IP adries • cTok - počet tokov pre daný zdrojový/cieľový port • ipTok - počet analyzovaných tokov z určitej IP adresy pre zdrojový/ cieľový port • vTok - minimálny počet tokov, ktoré charakterizuje vzor pre zdrojový/ cieľový port • MinP/MaxP - minimálna/maximálna veľkosť paketov v bajtoch • prieP - aritmetický priemer veľkosti paketov v bajtoch 19 5. Charakteristiky a vzory tokov • MaxM - maximálna medzipaketová medzera v milisekundách • prieM - aritmetický priemer medzipaketových medzier v milisekundách Hodnoty uvedené v intrevaloch sú orezané o krajné extrémy, aby intervaly čo najpresnejšie charakterizovali väčšinu spracovaných tokov. Tabuľky môžu obsahovať polia, ktoré nie sú vyplnené, a to z dôvodu, že toky nemali jednoznačnú reprezentáciu daného parametru. Tabuľka Vzor tokov opisuje jednotlivé vzory založené na veľkosti pa-ketov a medzipaketových medzerách. Oproti prvej tabuľke disponuje variabilným počtom stĺpcov, pretože získané vzory nemajú danú dĺžku a k čo najpresnejšiemu popisu vzoru je potrebný rôzny počet paketov. Prvý riadok obsahuje poradové čísla paketov/medzipaketových medzier, druhý riadok obsahuje veľkosti uvedené v bajtoch a v treťom riadku sú hodnoty medzipaketových medzier v milisekundách. Hodnoty z tabuľky je možné interpretovať dvomi spôsoby, buď po riadkoch alebo po stĺpcoch. Ak prechádzame tabuľku po riadkoch získame dva nezávislé vzory tokov, praktické možnosti medzipaketových medzier pri klasifikácii tokov sú zhrnuté v poslednej kapitole. Druhý spôsob je prechádzanie tabuľky po stĺpcoch, ktorý umožňuje zaznamenať previazanie medzi hodnotami. Hodnota tri bodky predstavuje v prvom riadku doplnenie poradia, a v druhom a treťom riadku rovnaké hodnoty, ako boli uvedené v predchádzajúcom stĺpci daného riadku. Hodnota tilda má byť v rámci druhého a tretieho riadku interpretovaná ako rôzne hodnoty, ktoré sme nevedeli popísať vzorom, ak nie uvedené ináč v popise protokolu. Tabuľka 5.1 obsahuje popis toku, ktorého prvý paket má veľkosť 46 bajtov (začiatočný paket toku, výnimku tvorí DNS) a medzipaketová medzera medzi-prvým a druhým paketom z intervalu 50 až 100 milisekund, druhý paket má veľkosť 84 bajtov, atp. až po n-tý paket (posledný paket, výnimku opäť tvorí protokol DNS). Poradie 1 2 3 n-1 n Paket Medzera 46 50-100 84 10-20 1500 0 50 46 Tabuľka 5.1: Ukážka tabuľky vzoru toku 20 5. Charakteristiky a vzory tokov 5.2 Analýza sieťových protokolov Ďalšie podkapitoly, sa venujú zisteným charakteristikám a nájdeným vzorom. Cieľom je správne interpretovať dané charakteristiky, pretože pri protokoloch sme pracovali s rôznym počtom tokov, ale aj s odlišným počtom zdrojových a cieľových IP adries. 5.2.1 File Transfer Protocol FTP toky pri našej analýze predstavovali výnimky hneď v niekoľkých pohľadov tým, že operuje na dvoch rozdielnych portoch, 20 a 21, ale zistením, že dáta neobsahujú toky, ktoré by ako cieľový port mali nastavený port 20, resp. pre cieľový port 21 bolo zaznamenaných 15 tokov, z toho dôvodu sú uvedené len toky na zdrojovým portom. Port 20 FTP tok medzi dvoma IP adresami, s počtom tokov 281. Na konci sme daným vzorom dokázali popísať 273 tokov, z teoretickej časti vieme, že na porte 20 máme očakávať dátový FTP prenos, čo sa nám aj potvrdilo, pretože priemerná veľkosť paketov bola 1300 a viac bajtov, pričom bola takmer zhodná s maximálnou dĺžkou prenášaných paketov, 1380 bajtov. Znamená to, že skoro po celú dobu komunikácie boli zasielané pakety maximálnej veľkosti. Práve táto charakteristika indikuje prenos dát. v tejto chvíli sme zohľadnili aj informáciu, že komunikácia prebiehala práve medzi dvoma koncovými uzlami. Počet paketov v jednotlivých tokoch sa pohyboval medzi 20 až 7000, hodnoty boli rovnomerne rozložené na intervale medzi 500 až 1000 paketov na tok. Predpokladáme, že takto široký interval nameraných hodnôt bol spôsobený rôznou veľkosťou súborov, ktoré boli prenášané. Ako je možné vidieť v tabuľke 5.3, na popísanie vzoru FTP toku sme potrebovali, vo väčšine prípadov, informácie o veľkosti prvých troch paketov. Veľkosť tretieho paketu bola smerodajná pre nasledujúce pakety, pretože boli zhodné a tvorili samotný prenos dát. Prenos dát bol ukončený predposledným paketom, ktorý mal variabilnú veľkosť odvíjajúcu sa od veľkosti prenášaného súboru. Posledný paket tvorilo 52 bajtové TCP potvrdenie. Pri pohľade na medzipaketové medzery v tabuľke 5.3 vidieť previazanie medzi nimi a veľkosťami jednotlivých paketov. Rozsahy medzier, uvedené pri prvej, druhej a poslednej, sú s vysokou pravdepodobnosťou spô-sobné na strane aplikácie a spracovania toku. Zo vzoru nieje možné vidieť, že medzipaketami dĺžky 1380 bajtov sa objavujú medzery, ktoré nemajú 21 5. Charakteristiky a vzory tokov hodnotu 0,lms ale lOOms. Ich výskyt je závislý na dĺžke toku, čím dlhší tok tým je väčší počet paketov medzi tými medzerami. Vzdialenosť medzi lOOms medzerami bola nameraná medzi 1 až 25 paketmi. Avšak sa nám už nepodarilo zistiť, prečo dané skoky medzipaketových medzier vznikajú a čo ich spôsobuje. zIP cIP cTok ipTok vTok MinP MaxP prieP MaxM prieM 1 1 283 281 272 52 1380 1300+ 100-300 <10 Tabuľka 5.2: Informácie o FTP toku, zdrojový port 1 2 3 n-2 n-1 n 60 52 1380 1380 52 10-100 1-20 0,1 0,1 20-100 Tabuľka 5.3: Vzor FTP toku, zdrojový port 22 5. Charakteristiky a vzory tokov Port 21 Počet tokov a počet cieľových IP adries, ktoré sme mohli analyzovať sa zvýšil, čo dopomohlo k objektívnejším výsledkom oproti portu 20. Nedostatok z pohľadu dát stále pre nás ale predstavuje počet tokov zo zdrojovej IP adresy na porte ku všetkým tokom na porte (99,3%). Spracovávané toky obsahovali v 98% prípadoch 15 až 30 paketov, to znamná, že počet paketov na tok bol stabilný, v tabuľke 5.4 sa zameriame len na niektoré údaje, ktoré podrobnejšie vysvetlíme, ako napr. počet cieľových IP adries, priemernú veľkosť paketov a maximálnu medzipaketovú medzeru. Počet cieľových IP adries je 87 a počet tokov je 1725, ak by sme mali rovnomerné rozloženie tokov na IP adresy. Medzi IP adresami sa nachádza práve jedna, na ktorú smeruje 1177 tokov z celkového počtu, preto treba brať do úvahy, že počet tokov ktoré popisuje vzor v tabuľke 5.5 je z troch štvrtín tvorený komunikáciou medzi dvoma uzlami, kde je vysoká pravdepodobnosť, že toky budú mať rovnaký vzor. Pri porovnaní priemerných veľkostí paketov na portoch 20 a 21, zistíme, že na porte 21 je niekoľkonásobne nižšia veľkosť, len 138 bajtov, čo sme však očakávali, pretože vieme, že na porte 21 môže prebiehať komunikácia zabezpečujúca prenos FTP príkazov. Maximálna medzipaketová medzera v jednotkách až desiatkach sekúnd sa objavila pri 80 tokoch smerujúcich na 20 rôznych IP adries. Pre väčšinu z týchto tokov platilo, že takáto medzera sa objavila len raz, a to na konci toku. Nepredpokladáme, že takéto medzery by spôsobovala sieťová infrastruktura, ale skôr aplikácia na strane užívateľa. V tabuľke 5.5 je uvedená časť identifikovaného vzoru, pretože bol vzor príliš dlhý, pokračoval až k desiatemu paketu. Aj v tomto prípade bolo zistené previazanie medzi veľkosťou paketov a medzipaketovými medzerami z dát. Na medzipaketových medzerách sa prejavilo rôzne sieťové, resp. geografické umiestnenie cieľových IP adries, t.j. veľkosť paketov sa nemenila, ale medzipaketové medzery záviseli od IP adresy, na ktorú boli zasielané. zIP cIP cTok ipTok vTok MinP MaxP prieP MaxM prieM 1 87 1751 1725 1550 52 1003 138 20ms-30s Tabuľka 5.4: Informácie o FTP toku, zdrojový port 23 5. Charakteristiky a vzory tokov 1 2 3 4 n-1 n 60 128 52 127 52 120-200 10-120 0,7 10-120 10-120 Tabuľka 5.5: Vzor FTP toku, zdrojový port 5.2.2 Secure Shell Celkovo sme mali k dispozícii 2889 tokov pre zdrojovú IP adresu sme z nich analyzovali 1685 a pre cieľovú 110. Okrem týchto tokov sme ešte detailnej analýze podrobili aj ďalšie, ktoré netvorili primárny cieľ skúmania, ale na základe získaných údajov a štruktúre triedenia dát, sme sa ich rozhodli spracovať, čo nám pomohlo s celkovou interpretáciou získaných vzorov v tejto práci. Vysoká hodnota vTok, je spôsobená tým, že toky so zdrojovým portom 22 obsahujú cieľovú IP adresu, na ktorú je smerovaných 1673 tokov z 1685 (celkový počte tokov danej zdrojovej IP adrese). Počet paketov na jednotlivé toky sa pohyboval v rozmedzí 20 až 38 paketov. Všetky toky z pohľadu hodnôt boli konzistentné, a preto aj intervaly hodnôt v tabuľke 5.6 a tabuľke 5.7 sú také tesné. zIP cIP cTok ipTok vTok MinP MaxP prieP MaxM prieM 1 4 2889 1685 1682 52 836 140-180 85-100 30-35 Tabuľka 5.6: Informácie o SSH toku, zdrojový port 1 2 3 4 5 n-1 n 60 84 52 836 52 52 52 60-70 48-55 0-1,5 85-95 48-85 1,5 Tabuľka 5.7: Vzor SSH toku, zdrojový port Aj toky na ostatných IP adresách sme podrobili analýze. Výsledkom bolo, že sme identifikovali ďalšie dva vzory, ale v podobe tabuľky spracujeme len jeden, pretože sme ho dokázali zaznamenať v dvoch rôznych skupinách tokov. Toky, ktoré by bolo možne klasifikovať prvým vzorom, boli zachytené medzi jednou zdrojovou a dvoma cieľovými adresami, v počte 95 tokov. Druhý vzor sme získali zo 750 tokov, medzi 209 zdrojovými adresami a jednou cieľovou. Vzory z pohľadu veľkosti paketov sú rovnaké. Veľkosti medzipaketových medzier a ich minimálne rozdiely medzi 24 5. Charakteristiky a vzory tokov vzormi, sú s vysokou pravdepodobnosťou spôsobené umiestnením koncových uzlov v rámci siete, pretože vzory pochádzajú z rôznych skupín IP adries. Vzor využívajúci iba medzipaketove medzery z tabuľke 5.7 alebo tabuľke 5.8, by dokázal detekovať aj druhú skupinu tokov na iných IP adresách ako bol získaný, čo je pre nás pozitívny výsledok vzhľadom na klasifikáciu založenú na časových značkách. 1 2 3 4 5 6 n-1 n 60 84 52 956 52 52 52 10-20 3-5 4-6 40 4-6 2 6-10 Tabuľka 5.8: Vzor SSH toku, zdrojový port, zvyšné toky 1 2 3 4 5 6 n-1 n 60 84 52 956 52 52 52 5-30 0-30 0-5 30-60 0-5 0-5 2-20 Tabuľka 5.9: Vzor SSH toku, zdrojový port, zvyšné toky Pri zameraní sa na cieľový port, sme sa dostali do podobnej situácie ako pri zdrojovom porte, jedna zdrojová IP adresa mala prevahu v počte tokov, pre túto IP adresu je vytvorený aj vzor v tabuľke 5.2.2-4. Toky na tejto adrese by sme mohli rozdeliť do 2 skupín, na základe počtu paketov 32 až 36, tok má stabilný počet paketov, líšiaci sa len TCP potvrdenia dĺžky 52 bajtov. Priemerná dĺžka paketov v tejto skupine je maximálne 450 bajtov. Druhá skupina obsahuje počet paketov v rozmedzí 60 až 11700, rozdiel v toku tvoria pakety dĺžky 1500 bajtov, reprezentujúce prenos dát, a preto sa priemerná veľkosť paketov limitné blíži 1500 bajtov v tejto skupine, vzhľadom na zvyšujúci sa počet paketov v toku. Dôležité je, že nižšie uvedený vzor charakterizuje obe skupiny tokov, pričom sme schopný vytvoriť vzor popisujúci veľkosť každého jedného paketu a medzipaketovej medzery v toku. zIP cIP cTok ipTok vTok MinP MaxP prieP MaxM prieM 3 1 122 110 100 52 1500 100-145 <30 Tabuľka 5.10: Informácie o SSH tokoch, cieľový port 5.2.3 Simple Mail Transfer Protocol Toky na porte 25 nám poskytli výsledky, ktoré môžeme interpretovať ako objektívnejšie oproti predchádzajúcim, pretože počet cieľových IP adries 25 5. Charakteristiky a vzory tokov 1 2 3 4 5 6 n-1 n 60 52 52 73 900 52 52 52 15-25 20-30 0 15-25 40-60 10-20 100-120 Tabuľka 5.11: Vzor SSH tokov, cieľový port narástol. Podstatné je, že žiadna z týchto IP adries nemala prevahu v počte tokov, a neskreslila výsledky v podobe charakteristík a vzorov, t.j. vzor nepopisuje len komunikáciu medzi dvoma koncovými uzlami, ale medzi množinou koncových uzlov. Spracované toky z danej zdrojovej IP adresy, sme rozdelili do dvoch súborov na základe veľkosti prvého paketu toku, pretože vykazovali rôzne charakteristiky. Pre oba súbory následne boli vytvorené vzory, s ktorými sme na konci dokázali klasifikovať 95% tokov na skúmanej zdrojovej IP adrese, resp. minimálne 69,5% prevádzky na zdrojom porte 25. V prvom súbore charakteristický údaj predstavovala aj hodnota počtu paketov v toku, pretože interval bol medzi 5 až 14 paketmi. Až v dvoch tretinách prípadov bol počet paketov v toku rovný siedmim, v tabuľke 5.10 je zaujímavou práve hodnota maximálnej medzipaketovej medzery, ktorá je o niekoľko rádov vyššia ako v predchádzajúcich spracovávaných tokoch. Vzhľadom na formu dát, ktorú sme mali k dispozícií a vzhľadom na typ analýzy, ktorú sme vykonávali, neboli sme schopní určiť príčinu takto vysokých hodnôt. Predpokladáme, že v danom prípade sa jedná o charakteristiku samotného fungovania protokolu a nespôsobuje to ani koncová aplikácia, a ani sieťová infrastruktura. Maximálna medzipaketová medzera v 36 prípadoch prekročila 9 sekúnd a hraničnú hodnotu tvoril neaktívny časovač. Vzor v tabuľke 5.11 predpokladá, že veľkosť prvého paketu môže byť, okrem uvedenej hodnoty aj 46 alebo 52 bajtov. zIP cIP cTok ipTok vTok MinP MaxP prieP MaxM prieM 1 100+ 2573 1585 1515 46 <500 70-160 ls-9s Tabuľka 5.12: Informácie o SMTP tokoch, zdrojový port 1 2 3 n-1 n 48 139 46 52 ls-8s 30ms-3s 0-0,4 150-500 Tabuľka 5.13: Vzor SMTP tokov, zdrojový port 26 5. Charakteristiky a vzory tokov Druhý súbor obsahoval toky dĺžky 5 až 23 paketov. Dlhšie toky ako spomínaný interval, obsahovali navyše iba pakety veľkosti 52 bajtov TCP potvrdenia až do konca toku. z pohľadu veľkosti paketov sa oba vzory líšia, ale z pohľadu medzipaketových medzier je práve zaujímavá prvá medzera, pretože je dostatočne charakteristická pre dané toky a intervaly sa z podstatnej časti prekrývajú. zIP cIP cTok ipTok vTok MinP MaxP prieP MaxM prieM 1 40+ 2573 229 229 52 ls-6s Tabuľka 5.14: Informácie o SMTP tokoch, zdrojový port 1 2 3 n-1 n 60 151 52 52 ls-6s 3-330 0 Tabuľka 5.15: Vzor SMTP tokov, zdrojový port Z tabuliek nižšie je vidieť, že sa jedná o veľmi špecifický prenos, kde počet paketov bol 9, jedinú zmenu predstavovala veľkosť piateho a šiesteho paketu. Rozhodli sme sa preto analyzovať aj zvyšné toky na cieľovom porte. zIP cIP cTok ipTok vTok MinP MaxP prieP MaxM prieM 1 1 1836 1053 1033 52 80-165 60-76 1-1,5 <1 Tabuľka 5.16: Informácie o SMTP tokoch, cieľový port 1 2 3 4 5 6 7 8 9 60 52 52 76 40-165 78-91 58 58 52 1 1 0 1 1 1 1 1 Tabuľka 5.17: Vzor SMTP tokov, cieľový port Pre zvyšné toky si uvedieme len vzor, ktorým sme ich dokázali popísať 720 z počtu 810. Komunikácia prebiehala z 3 rôznych zdrojových IP adries a smerovala na viac ako 100 cieľových IP adries. Vzor sme museli do určitej miery zovšeobecniť, čo sa prejavilo na štvrtom pakete, kde vzor akceptuje veľkosti paketov 75, 76 a 79 bajtov, ktoré sa vyskytovali v tokoch, a aj na poslednom pakete, kde pripúšťame veľkosť 46 alebo 52 bajtov. u časových charakteristík, problém predstavuje druhá medzipaketová medzera, kde je 27 5. Charakteristiky a vzory tokov rozsah v rámci troch rádov, čo pre nás predstavuje skoro akúkoľvek hodnotu. 1 2 3 4 n-1 n 60 52 52 7x 46/52 1-20 4ms-2s 1 4-20 0-50 Tabuľka 5.18: Vzor SMTP tokov, cieľový port, zvyšné toky 5.2.4 Domain Name System Spracovaný je iba zdrojový port, pretože na cieľovom porte bolo zachytených iba 24 tokov, k dispozícii sme mali 2291 tokov, ale nedarilo sa nájsť žiadny vzor pre tieto záznamy. Preto sme z nich vyextrahovali 1312 tokov, ktoré tvorili prenos medzi dvoma koncovými uzlami. Cieľom bolo vytvoriť dostatočne špecifickú vzorku dát, aby v nich bolo možné nájsť vzor. Problém bol však v prístupe, akým sme vzory vyhľadávali, pretože najskôr analyzujeme začiatok toku (napr. prvých 5 paketov), potom pakety na konci toku, a ak je to nutné, aj informácie vo zvyšku toku. Pre vybrané toky sme taktiež zistili, že nemajú jednoznačnú sekvenciu veľkosti paketov na začiatku toku a ani charakteristickú veľkosť posledných paketov, ako tomu bolo pri predchádzajúcich portoch. Zaznamenali sme charakteristické veľkosti paketov, ktoré sa vyskytujú v tokoch a aj to, že niektoré z týchto veľkostí sú usporiadané do sekvencie, ktorá je popísaná v tabuľke 5.18. Toky nemusia obsahovať celú sekvenciu, stačí, aby obsahovali časť z nej, pričom toky začínali a končili v akomkoľvek pakete sekvencie. Okrem týchto faktorov prácu komplikovali pakety mimo sekvencie, ktoré taktiež tvorili začiatok a koniec niektorých tokov, ich veľkosť neprekročila hodnotu 300 bajtov. To, že toky nemuseli obsahovať celú sekvenciu, sa prejavilo aj na hodnote minimálnej veľkosti paketov, 110 bajtové pakety sa vyskytovali v 70% tokov, v predchádzajúcich prípadoch výskyt minimálnej veľkosti paketov uvedenej v tabuľke prevyšoval 97%. Dĺžka tokov bola v rozmedzí 5 až 300 paketov, pričom 80% tokov malo dĺžku pod 50 paketov. Časové charakteristiky pre zistenú sekvenciu poskytli nadmieru presné výsledky so žiadnym, alebo len minimálny rozptylom hodnôt, avšak treba brať do úvahy, že tejto chvíli sme spracovávali veľmi špecifické dáta a takéto výsledky sme mohli očakávať. Maximálne hodnoty medzipa-ketových medzier dosahovali 3 sekúnd, ale na vzore sa neprejavili. Jednotlivé medzery sa vyskytovali v iných častiach tokov a prevažne v tokoch, ktoré neobsahovali daný vzor. 28 5. Charakteristiky a vzory tokov zIP cIP cTok ipTok vTok MinP MaxP prieP MaxM prieM 1 1 2360 1312 950+ 110 124-286 120-220 0s-3s 0-100 Tabuľka 5.19: Informácie o DNS toku, zdrojový port 1 2 3 4 5 6 7 8 110 122 122 124 123 127 125 147 0,3 0,3 0,3 0,3 0,3 0,3 0,3 2-40 Tabuľka 5.20: Vzor DNS toku, zdrojový port Na zvyšné toky sme aplikovali rovnaký postup, vybrali sme deväť cieľových IP adries, na ktorých toky mali rovnaké charakteristiky. Pre 770 tokov bol počet paketov v toku 7, preto vzor v tabuľke 5.20 popisuje všetky veľkosti a medzipaketové medzery v týchto tokoch. Toky, obsahujúce 6 paketov, neobsahovali prvý paket s veľkosťou 128 bajtov a toky dlhšie (8 až 13 paketov) začínali iným, ako prvým paketom z uvedeného vzoru. Všetky dlhšie toky mohli byť identifikovateľné na základe sekvencie paketov z tabuľky 5.20, pretože ju obsahovali, posledný paket toku mal vždy veľkosť 127 bajtov. zIP cIP cTok ipTok vTok MinP MaxP prieP MaxM prieM 1 9 2360 850 850 114 128 123 10s l,6s Tabuľka 5.21: Informácie o DNS toku, zdrojový port 1 2 3 4 5 7 128 114 122 122 124 123 127 10s 7-8 7-8 7-8 7-8 7-8 7-8 Tabuľka 5.22: Vzor DNS toku, zdrojový port 5.3 Zhrnutie používania skriptov a analýzy dát Z pohľadu funkčnosti sadu skriptov považujeme za dobrú, podstatne pomáha zefektívniť prácu s tokmi. Avšak k intenzívnejšiemu použitiu sady skriptov pri identifikácii vzorov navrhujeme rozšírenie o niekoľkých nových skriptov, ktoré podľa našich skúseností so spracovaním tokov, významne znížia čas potrebný na samotnú identifikáciu vzoru a poskytnú presnejšie štatistiky. 29 5. Charakteristiky a vzory tokov Prvý skript by na usporiadaných dáta podľa veľkosti prvého paketu, orezával prvých päť paketov, resp. päť medzipaketových medzier a posledné tri pakety každého toku, pre všetky toky ktoré chceme analyzovať. Tieto veľkosti paketov a medzipaketové medzery by sme ukladali do nového súboru, ktorý by sa analyzoval ako prvý. Skript by bolo možné spúšťať ako posledný. Druhý skript je obdobou skriptu evaluator.pl, len by sa aplikoval na výstup zo skriptu ipSieve.pl, získali by sme tým presnejšie informácie o vytriedených tokoch na základe IP adries. Naša práca spočívala v zistení, či toky, resp. protokoly, majú vzory založené na časových značkách a v prípade, ak majú, tak ich podrobne popíšeme. Vo všetkých prípadoch sme identifikovali charakteristiky tokov a vytvorili vzory jednotlivých protokolov, s využitím týchto vzorov sme boli schopný popísať väčšinu tokov na danom porte, čo považujeme za priaznivé pre ďalší výskum vzhľadom na využitie časových značiek na klasifikáciu tokov, s tým je spojených hneď niekoľko komplikácií, ktoré si myslíme, že bude nutné vyriešiť predtým, ako sa klasifikácia začne reálne používať Prvý problém predstavujú časové značky z pohľadu siete. Za jeden z významných faktorov, ovplyvňujúcich veľkosť medzipaketovej medzery, považujeme umiestnenie v sieti. Tým myslíme aj umiestnenie geografické, teda ako ďaleko sú od seba komunikujúce uzly vzdialené fyzicky, ale aj umiestnenie v rámci siete, t.j. koľko sieťových zariadení sa nachádza medzi danými uzlami, s tým je spojené aktuálne vyťaženie komunikačnej linky medzi uzlami. Druhý problém predstavujú časové značky z pohľadu aplikácie, o spracovanie a zasielanie paketov sa stará koncová aplikácia, vplyv na veľkosť medzipaketovej medzery môžu mať faktory ako implentácia protokolu t.j. spracovania paketov v aplikácii, ale aj to, ako systém prideľuje zdroje aplikácii. Cieľom je, aby medzipaketové medzery neobsahovali tieto premenlivé faktory, pretože priamo ovplyvňujú presnosť klasifikácie založenej na časových značkách. 30 Kapitola 6 Záver Cieľom tejto bakalárskej práce bola identifikácia charakteristík protokolov podľa štatistík medzipaketových medzier a dĺžky paketov. Druhý cieľ, kladeným na túto prácu, bolo návrh a vytvorenie sady skriptov, ktoré pomôžu s analýzou získaných NetFlow dát z reálnej prevádzky, v úvodnej kapitole sa venujeme dôvodom monitorovania sieťovej prevádzky. Druhá kapitola sa zaoberá protokolom NetFlow, s ktorého upravenými dátami sme mali možnosť pracovať. Sieťovými protokolmi aplikačnej vrstvy, ktoré sme analyzovali, sa venuje tretia kapitola, v popise sa sústreďujeme na funkciu protokolu a vlastnosti, ktoré by sme mohli využiť pri jeho identifikácii. Praktická časť je rozdelená do dvoch kapitol. Sade skriptov sa venuje kapitola štvrtá. Kde sú popísané jednotlivé skripty a moduly, ktoré boli v rámci práce vytvorené a používané, z dôvodu rozšírenia skriptov sú v tejto kapitole uvedené vstupné a výstupne formáty pre dané skripty. Proces analýzy záznamov, spolu s charakteristikami a vzormi tokov pre vybrané protokoly, tvorí piatu kapitolu spolu s výsledkami. Výsledky tejto práce nadväzujú na časť výskum Mgr. Pavla Piskača o možnostiach využitia časových značiek na klasifikáciu tokov v sieti. Jeho časť výskumu snaží poskytnúť odpoveď, či časové značky zabezpečujú dostatočnú presnosť ako metrika na klasifikáciu protokolov. Naša časť výskumu sa zaoberala detekciou vzorov protokolov, založených na medzipaketových medzerách a ich využiteľnosti pri klasifikácii. V práci je vyzdvihnuté previazanie medzipaketových medzier a veľkosťou packetov, ktoré môže byť využité pri efektívnej detekcii vzorov založených na časových značkách. Už môžeme povedať, že vzory založené na časových značkách sme schopný detekovať, ale s ohľadom na klasifikáciu protokolov to už také jednoduché nie je. Klasifikácia protokolov na báze časových značiek, musí vyriešiť dva hlavné komplikácie, ktorými sú oneskorenie vznikajúce na strane siete a na strane aplikácie. Obe tieto hodnoty určitou mierou ovplyvňujú medzipaketové medzery, cieľom ďalšieho výskumu by mohlo byť meranie vplyvu prípadne eliminácia, týchto faktorov na celkovú hodnotu medzipaketových medzier. 31 Dodatok A Obsah přiloženého CD Priložené CD obsahuje zdrojové kódy skriptov, ktoré boli popisané v kapitole 4. v adresári new, sa nachádzajú posledné verzie skriptov, ktoré boli použité pri práci. Na CD v adresári old sú zdrojové kódy skriptov, ktoré sme používali na začiatku analýzy a postupne upravovali, aby spĺňali požadované funkcie. Prvým rozdielom je, že dané skripty nepracujú automatizované, druhým potom je samotná implementácia. Avšak stále je ich možné využiť pri spracovaní dát, pretože vstupný a výstupný formát zostali zachované. Avšak v adresári old sa nachádzajú aj iné skripty, ktorých funkcionalita nie je popísaná v 4. kapitole, to je spôsobené tým, že v praxi sa neosvedčili. 32