}w !"#$%&'()+,-./012345
Masarykova univerzita Fakulta informatiky
Určení zdroje síťové komunikace na základě IP adresy Bakalářská práce
Martin Rábek
Brno, jaro 2013
Místo této strany bude vložena kopie zadání.
ii
Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
V Brně dne 17. května 2013
Martin Rábek
Vedoucí práce: Ing. Pavel Čeleda, Ph.D. iii
Poděkování Děkuji Ing. Pavlu Čeledovi, Ph.D. za cenné rady, náměty a zkušenosti, které mi při psaní práce poskytl.
iv
Shrnutí Bakalářská práce se zabývá určováním zdrojů síťové komunikace v prostředí vysokorychlostních sítí. Geolokace přispívá ke snadnější intepretaci síťového provozu, proto byly navrženy úpravy nástrojů, které monitorují sítě pomocí IP toků. Díky tomu je možné uložené záznamy analyzovat i z hlediska zemí původu zdroje na základě zdrojové a cílové IP adresy komunikace. Důležitým přínosem práce je vizualizace síťového provozu podle těchto geolokačních údajů v reálném čase. To přináší snadnější detekci bezpečnostních incidentů a lokalizaci škodlivého síťového zařízení.
Klíčová slova NetFlow, IPFIX, IP toky, geolokace, exportér, kolektor, sonda, NFDUMP, NfSen, FlowMon
v
Obsah 1 2
3
4
5
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitorování síťového provozu pomocí IP toků . . . 2.1 Principy monitorování sítě pomocí IP toků . . . . . . 2.1.1 Srovnání protokolů NetFlow a IPFIX . . . . . 2.1.2 Využití záznamů IP toků . . . . . . . . . . . . 2.2 Architektura monitorování sítě pomocí IP toků . . . . 2.2.1 Exportér . . . . . . . . . . . . . . . . . . . . . 2.2.2 Kolektor . . . . . . . . . . . . . . . . . . . . . . 2.3 Nástroje pro zpracování NetFlow/IPFIX . . . . . . . . 2.3.1 NfSen/NFDUMP . . . . . . . . . . . . . . . . . 2.3.2 SiLK . . . . . . . . . . . . . . . . . . . . . . . . Geolokace podle IP adresy . . . . . . . . . . . . . . . . 3.1 Principy IP geolokace . . . . . . . . . . . . . . . . . . 3.1.1 Standard ISO 3166 . . . . . . . . . . . . . . . . 3.1.2 Využití geolokace . . . . . . . . . . . . . . . . . 3.2 Pasivní metody geolokace . . . . . . . . . . . . . . . . 3.2.1 Doménová jména a DNS LOC . . . . . . . . . . 3.2.2 Databáze whois . . . . . . . . . . . . . . . . . . 3.2.3 Geolokační databáze . . . . . . . . . . . . . . . 3.3 Aktivní metody geolokace . . . . . . . . . . . . . . . . 3.3.1 Metody založené na měření zpoždění . . . . . . 3.3.2 Metody založené na znalosti topologie sítě . . . 3.3.3 Statistické metody geolokace . . . . . . . . . . 3.3.4 Metody geolokace využívající informace z webu Návrh geolokace v prostředí vysokorychlostních sítí 4.1 Stanovení požadavků . . . . . . . . . . . . . . . . . . . 4.2 Volba geolokačních údajů . . . . . . . . . . . . . . . . 4.3 Výběr geolokační služby . . . . . . . . . . . . . . . . . 4.4 Návrh geolokační funkcionality . . . . . . . . . . . . . 4.5 Navržené přístupy geolokace . . . . . . . . . . . . . . . Vývoj geolokace na straně kolektoru . . . . . . . . . . 5.1 Analýza nástrojů NFDUMP . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 3 3 4 5 5 6 6 7 7 8 9 10 10 11 11 12 12 12 13 13 14 14 15 16 16 17 17 19 20 22 23 vi
5.2 Návrh vlastního geolokačního rozšíření . . . . . . . . . 5.3 Návrh ukládání geolokačních údajů . . . . . . . . . . . 5.4 Návrh doplnění operací pro nfdump . . . . . . . . . . 6 Vývoj geolokace na straně exportéru . . . . . . . . . . 6.1 Analýza geolokace pomocí FlowMon sondy . . . . . . 6.2 Návrh začlenění podpory pro geolokaci . . . . . . . . . 6.3 Návrh distribuovaného směrování dat podle kódů států 7 Testování a ověření funkčnosti navrženého řešení . . 7.1 Testování geolokačního výkonu . . . . . . . . . . . . . 7.2 Testování geolokace na straně kolektoru . . . . . . . . 7.3 Testování geolokace na straně exportéru . . . . . . . . 7.4 Porovnání navrženého řešení s podobnými programy . 8 Prezentace výsledků geolokace . . . . . . . . . . . . . . 8.1 Profilování provozu . . . . . . . . . . . . . . . . . . . . 8.2 Detekce anomálií . . . . . . . . . . . . . . . . . . . . . 9 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
23 25 27 28 29 29 30 31 31 32 33 34 36 36 40 42 44
Přílohy 49 A Seznam elektronických příloh . . . . . . . . . . . . . . . . . . . 49
vii
Seznam obrázků 2.1 2.2
Ukázka monitorování programu ping pomocí dvou toků. 4 Architektura monitorování sítě pomocí toků podle [1]. 5
3.1
Pomocí webové služby [2] zjistí uživatel Internetu svou polohu. Na obrázku je správně určeno umístění počítače připojeného v Brně. 9
4.1 4.2
Schéma geolokační funkcionality 19 Ukázka architektury monitorování toků s více exportéry
5.1 5.2 5.3 5.4
Architektura geolokace na straně kolektoru 22 Soubory změněné při vytvoření vlastního rozšíření 24 Soubory změněné při zahrnutí geolokace v nfcapd 26 Soubory změněné při doplnění operací pro nfdump 27
6.1
Architektura geolokace na straně exportéru
7.1
Srovnání výkonu dotazování na databázi GeoLite Country 31 Ověření správnosti geolokace pro různé protokoly toků 33 Demonstrace distribuce dat na porty stejného kolektoru 34
7.2 7.3 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9
21
28
Geolokační profil IPv4 komunikace (1 den) 37 Geolokační profil IPv6 komunikace (1 den) 37 Vizualizace vstupního provozu podle portů (2 hodiny) 38 Vizualizace příchozí/odchozí HTTP komunikace (2 hodiny) 39 Vizualizace příchozí/odchozí HTTPS komunikace (2 hodiny) 39 Profil TCP komunikace bez geolokace (1 den) 40 Profil TCP komunikace zobrazující provoz států s vysokým výskytem anomálií (1 den) 40 Anomálie profilu ICMP komunikace (18 hodin) 41 Normální a anomální profil HTTP komunikace (2 dny) 41
viii
Kapitola 1
Úvod Internet tvoří neodmyslitelnou součást dnešní společnosti. Více než 2,4 miliardy uživatelů [3] z celého světa přistupuje do virtuálního prostředí, kde nehraje roli geografická vzdálenost. Anonymita komunikujících účastníků je pouze zdánlivá, a to díky tomu, že každý počítač vystupuje pod svojí IP adresou. Ačkoliv mezi ní a geografickou polohou není přímá souvislost, existuje řada možností, jak určit polohu zdroje síťové komunikace. Tato práce si klade za cíl prozkoumání a implementování geografické lokalizace nebo-li geolokace. Určování zdrojů síťové komunikace na základě IP adresy, spadající do pasivních geolokačních metod, zaznamenalo prudký rozvoj během poslední let, což dokazuje využití v online reklamě cílené na lokalitu návštěvníka stránek a v analýze síťové bezpečnosti. I přes tento pokrok je zde stále prostor na zlepšení, protože současná řešení provádějí geografické určení polohy pouze na požádání nebo v malém rozsahu. Na počátku řešení bakalářské práce stálo několik rozhodujících otázek, zejména jak provádět geolokaci v reálném čase tak, aby tento proces byl výpočetně uskutečnitelný i na rozsáhlých a vysokorychlostních sítích. V navrženém mechanismu pro zjištění geolokace na základě IP adresy byla využita lokální databáze GeoLite Country od společnosti MaxMind [4], ke které se přistupuje pomocí volání metod GeoIP, přidruženého rozhraní pro programování aplikací v jazyku C. Dalším předmětem úvah bylo, jaké geolokační údaje má smysl ukládat pro následnou analýzu provozu. Z původně zamýšlené trojice údajů země, kraj a město byl v první fázi získáván abecední kód země. Protože uchování názvů v řetězci by neúměrně zvýšilo objem dat, bylo nutné implementovat převod do číselného kódu dle standardu ISO 3166 [5]. Při testování zbylých polí se zjistilo, že databáze nevrací na testovacím vzorku dat přesné výsledky, a to byl jeden z důvodů, proč geolokace zůstala pouze na úrovni rozpoznávání států. Výsledkem práce jsou dva přístupy lišící se místem doplňování geolokačních údajů. První probíhá na straně kolektoru, kde byla implementována nativní podpora geolokace do balíčku nástrojů NFDUMP [6]. Ta je prováděna v rámci nástroje nfcapd, který ke zpracovávanému toku dat přidává nové 1
1. Úvod pole obsahující zdrojové a cílové číslo státu, zatímco nástroj nfdump umožňuje nad těmito údaji provádět klasické operace, jako agregaci, filtrování a počítání statistik. Druhý přístup na straně exportéru spočívá ve vytvoření zásuvného modulu GeoPlugin pro sondu FlowMon [7], který umožňuje ukládat údaje o zemi přímo do záznamů toků, který je následně zpracován kolektorem. Díky tomuto přístupu je pak možné distribuovat provoz předem vybraných států na určené kolektory. Závěrem následuje stručný přehled jednotlivých částí práce. Nejprve jsou popsány základy monitorování sítě pomocí IP toků, rozdíly dvou nejpoužívanějších protokolů pro uchovávání a export toků, architektura monitorování sítě a dva nástroje pro zpracování toků. Třetí kapitola se zabývá základy geolokace a rozborem dostupných metod zjišťování polohy na základě IP adresy. Následuje shrnutí požadavků na geolokaci v prostředí vysokorychlostních sítí a návrh optimální geolokační funkcionality využívající bezplatnou databázi GeoLite Country od společnosti MaxMind. Další dvě kapitoly popisují geolokaci na straně kolektoru a na straně exportéru. Dále jsou shrnuty poznatky o testování navržených úprav programů a porovnání s ostatními nástroji v oblasti síťové analýzy. Na závěr je prezentováno využití geolokace formou grafů a analýz reálného síťového provozu na kolektoru Masarykovy univerzity.
2
Kapitola 2
Monitorování síťového provozu pomocí IP toků Monitorování síťového provozu představuje proces neustálého sledování sítě s možností upozornit na poruchu zařízení v síti nebo na jiné nestandardní chování. Síťoví administrátoři obvykle volí jeden ze tří základních druhů monitorování – hloubkové zkoumání paketů, statistiky o provozu nebo statistiky IP toků – lišících se svou detailností a výpočetními nároky. Hloubkové zkoumání paketů poskytuje detailní informace o síťovém provozu. Velkou nevýhodou je nízká škálovatelnost a vysoké vypočetní nároky kvůli zkoumání každého paketu. Tato metoda je využívána v systémech pro odhalení průniku (Intrusion Detection Systems), které se snaží detekovat škodlivé aktivity namířené na koncové zařízení v síti. Statistiky o provozu lze odvodit s využitím protokolu SNMP (Simple Network Management Protocol), který na základě síťových rozhraní zařízení v síti (např. směrovačů, tiskáren či serverů) počítá přenesené bajty a pakety. Ačkoliv tyto statistiky podávají informace o síťovém chování a stavu sítě, nelze rozlišit datové přenosy konkrétních aplikací či zjistit, kdo s kým komunikoval. Statistiky IP toků představují kompromis mezi předchozími metodami monitorování sítě. Na rozdíl od hloubkového zkoumání paketů se prochází pouze hlavičky IP (Internet Protocol) paketů, což umožňuje zjišťovat základní údaje jako např. IP adresy a porty dané komunikace. Díky údajům tvořící tok lze určit kdo s kým komunikoval, kdy, jak dlouho, kolik dat bylo přeneseno a jaký používal protokol a službu.
2.1
Principy monitorování sítě pomocí IP toků
Monitorování síťového provozu založeného na konceptu IP toků bylo vyvinuto společností Cisco Systems v roce 1996 jako protokol NetFlow [8], který dodnes představuje nejpoužívanější protokol v oblasti monitorování IP toků. Existují však i další podobné protokoly (např. Jflow či NetStream), které jsou prosazovány dalšími prodejci směrovačů. Nový standard IPFIX [9] si klade za cíl stát se univerzálním standardem pro export a ukládání dat. 3
2. Monitorování síťového provozu pomocí IP toků Pojmem tok (flow) rozumíme jednosměrnou sekvenci paketů s určitými stejnými vlastnosti. Podle tradiční definice IP tok obsahuje pět klíčových údajů: zdrojovou IP adresu, zdrojový port, cílovou IP adresu, cílový port a IP protokol. Všechny pakety se stejnými vlastnostmi jsou sloučeny do jednoho záznamu toku, ke kterému se dopočítá počet přenesených paketů a bajtů a doplní další informace, např. časové razítko (timestamp). Počet údajů v záznamu toku závisí na použitém protokolu IP toků. zdrojová a cílová IP adresa časové razítko zdrojový a cílový port počet paketů číslo protokolu počet přenesených bajtů localhost
ICMP request
147.251.5.231
ICMP reply Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes 2013-04-07 07:06:56.084 60.060 ICMP 10.0.0.1:0 -> 147.251.5.231:8.0 7 588 2013-04-07 07:06:56.106 60.060 ICMP 147.251.5.231:0 -> 10.0.0.1:0.0 7 588
Obrázek 2.1: Ukázka monitorování programu ping pomocí dvou toků. Zařízení, které monitoruje síťový provoz, vytváří a exportuje IP toky, se nazývá exportér. Jeho funkci dříve plnily směrovače jako dodatečnou úlohu, ale pro vysokorychlostní sítě je nutné využít hardwarově akcelerované sondy, které plní pouze roli exportéru. Kolektor představuje zařízení s velkou diskovou kapacitou, které přijímá záznamy toků a ukládá je pro následnou analýzu. 2.1.1 Srovnání protokolů NetFlow a IPFIX Protokol NetFlow vznikl v několika verzích, z nichž nejpoužívanějšími jsou verze 5 a 9. NetFlow verze 5 představuje nejjednodušší způsob monitorování sítě pomocí toků. Jeho nevýhodou je však fixní velikost záznamu, který může obsahovat pouze předdefinované údaje, a dále absence podpory IPv6 protokolu. NetFlow verze 9 (RFC 3954 [10]), využívající šablonovou strukturu, umožňuje přidat do záznamu flexibilně další informace (např. údaje protokolu MLPS (Multi Protocol Label Switching), MAC adresy a další) a zavádí podporu monitorování IPv6 toků. V těle exportního paketu se nacházejí sekvence tvořené jednou šablonou (vymezuje typy ukládaných údajů toku) a libovolným počtem záznamů (ukládají vymezené údaje). IP Flow Information Export, zkráceně IPFIX (RFC 5101 [9]), je standard z roku 2008 pro export informací o IP tocích a jejich formátování. Nevýhodou NetFlow verze 9 bránící větší flexibilitě v záznamech toků 4
2. Monitorování síťového provozu pomocí IP toků je používání pouze těch údajů, které jsou uvedeny v proprietárním seznamu definovaným společností Cisco. IPFIX ponechává centrální množinu globálně známých údajů, kterou spravuje organizace IANA (Internet Assigned Numbers Authority). Nově lze definovat vlastní údaje v rámci každé organizace, která má přidělené unikátní číslo (enterprise number). Tyto údaje se nazývají enterprise údaje nebo enterprise elementy. Mezi další vylepšení patří podpora vzorkování provozu skrze protokol PSAMP (Packet Sampling Protocol) a změna výpočtu časových známek, která umožňuje definovat přesnější časové značky. 2.1.2 Využití záznamů IP toků Monitorování sítě pomocí IP toků umožňuje dohled nad sítí v reálném čase a přináší tyto klíčové možnosti využití: •
monitorování síťových aplikací a uživatelů;
•
monitorování stavu sítě a předcházení výpadků služeb;
•
detekce vnějších i vnitřních útoků sloužící ke zvýšení bezpečnosti sítě;
•
optimalizace plánování sítí;
•
účtování provozu na základě přenesených dat;
•
přehled o dlouhodobém využívání sítě.
2.2
Architektura monitorování sítě pomocí IP toků
Při monitorování sítě pomocí IP toků se obvykle využívá jeden nebo více exportérů, které odesílají záznamy toků do jednoho kolektoru. Schéma je zobrazeno na obrázku 2.2. směrovač
rozdělovač
směrovač
síťové pakety
záznamy toků exportér (sonda)
kolektor
Obrázek 2.2: Architektura monitorování sítě pomocí toků podle [1].
5
2. Monitorování síťového provozu pomocí IP toků 2.2.1 Exportér Exportér je zařízení, které analyzuje procházející pakety na monitorované lince. Jeho úkolem je sbírat informace o tocích a následně z nich vytvářet záznamy toků, které exportuje na kolektor. Paměť exportéru, ve které jsou ukládány informace o jednotlivých tocích, se nazývá vyrovnávací paměť toků (flow cache). Doba, za kterou vznikne záznam a dojde k jeho exportu, je ovlivněna nastavením časového limitu (timeout), který se dělí na aktivní a neaktivní. Pokud se v paměti toků nachází tok, jehož příslušný paket po dobu neaktivního časového limitu (typicky 30 s) neobdržel exportér, je takový tok ukončen. Aktivní časový limit (typicky 300 s) vymezuje dobu, za kterou budou všechny aktivní toky ukončeny a vytvořené záznamy budou odeslány na kolektor. Podle toho, jaké zařízení plní funkci exportéru, se rozlišuje tradiční nebo moderní architektura monitorování sítě. Tradiční architektura používá směrovače (např. CISCO, Juniper a Enterasys), které umožňují monitorování toků jako doplňkovou službu ke své hlavní činnosti – směrování. Z toho plyne hned několik nevýhod: omezený výkon, který má za následek nutnost vzorkovat toky, možnost útoků na viditelný směrovač a nemožnost použít pokročilé technologie. Moderní architektura využívá pasivní sondy (např. FlowMon [7] nebo nProbe [11]) specializované pouze na roli exportéru. Vedle vyššího výkonu oproti směrovačům a schopnosti zpracovávat všechny toky, umožňují sondy transparentní napojení na monitorovanou síťovou linku, proto sonda není z pohledu útočníka vidět.
2.2.2 Kolektor Kolektor, zařízení s velkou diskovou kapacitou, slouží pro ukládání záznamů toků odeslaných jedním nebo více exportéry. Záznamy toků jsou nejčastěji uloženy do relační databáze (např. SQL) nebo do zvláštních souborů na disku. Aplikace tvořící kolektor pak umožňují zobrazení a analýzu síťových statistik nejčastěji přes přehledné webové rozhraní. Vedle vizualizace provozu v grafech, které podávají rychlý přehled o dění v síti, umožňují aplikace vypisovat toky a jejich top N statistiky, filtrovat či agregovat (slučovat) záznamy, popř. nastavit automatické upozornění na definované události. Typickým příkladem kolektorové aplikace je NfSen (NetFlow sensor), který je grafickou nástavbou nad sadou programů NFDUMP tools (popis viz 2.3.1). 6
2. Monitorování síťového provozu pomocí IP toků
2.3
Nástroje pro zpracování NetFlow/IPFIX
Na trhu je dostupná široká škála aplikací pro kolektory [12], které stačí nainstalovat a používat. Vedle mnoha komerčních produktů existuje několik open-source programů, které poskytují širokou nabídku vlastností, podporu a univerzální nasazení. Blíže představím bezplatné kolekce nástrojů NfSen/NFDUMP (do kterých bude začleněna podpora geolokace) a SiLK. Nástroje typicky podporují protokol NetFlow v hlavních verzích (5 a 9) a některé také IPFIX, ale nejedná se o podporu plného standardu. Nejčastěji je pokryto zpracování na úrovni NetFlow verze 9, ale možnost přijímat uživatelem definované údaje z enterprise elementu chybí. 2.3.1 NfSen/NFDUMP Nejpoužívanější kolektor v Evropě představuje NfSen/NFDUMP, dvojice nástrojů určená pro operační systémy typu UNIX šířených pod BSD licencí. Jejich autorem je Peter Haag, bezpečnostní inženýr pracující v organizaci SWITCH-CERT. Ačkoliv NfSen bezprostředně využívá nástroje sady NFDUMP, jsou oba programové celky vyvíjeny samostatně. Použitelnost a stabilita činí tyto nástroje škálovatelné a velmi oblíbené mezi síťovými administrátory a bezpečnostními analytiky. NFDUMP [6] představuje sadu nástrojů pro zpracování NetFlow dat (ve verzích 5/7 a 9) a IPFIX dat (na úrovni NetFlow verze 9). NFDUMP se skládá z šesti programů napsaných v programovacím jazyku C a spouštěných přes příkazový řádek, z nichž zmíním dva nejdůležitější: •
nfcapd (netflow capture daemon) má na starost sbírání a ukládání dat odesílaných z exportéru. Záznamy IP toků jsou ukládány v časových oknech (typicky 5 minut) do adresářové struktury se jmény obsahující čas vzniku souboru.
•
nfdump (netflow dump) slouží pro zobrazování uložených záznamů toků dat a provádění klasických operací nad nimi: počítání top-N statistik, agregaci a filtrování podle zadaných kritérií.
NfSen [13] je webová nástavba nad sadou programů NFDUMP napsaná v jazycích PHP a Perl. Kromě pohodlnější obsluhy programu nfdump umožňuje grafické znázornění profilů snímaného provozu. V neposlední řadě je možné rozšířit jeho funkcionalitu pomocí pluginů (např. SURFmap znázorní geografickou polohu podle IP adres pro monitorované toky). 7
2. Monitorování síťového provozu pomocí IP toků 2.3.2 SiLK Kolektor SiLK (System for Internet-Level Knowledge) [14] je kolekcí nástrojů pro analýzu síťového provozu pomocí toků. Jedná se projekt vyvíjený týmem CERT Network Situational Awareness oblíbený především v USA. SiLK se skládá z mnoha malých nástrojů, které byly navrženy v duchu UNIXové filozofie „prováděj pouze jednu věc, a to pořádně“. Nástroje jsou rozděleny do dvou skupin: pro ukládání toků dat (SiLK Packing System) a pro analýzu dat (Analysis Suite). Vedle nutnosti naučit se používat mnoho nástrojů se jako další nevýhoda může jevit ovládání pouze z příkazové řádky. Další analýzu a vizualizaci dat je možné provádět pomocí přídavných nástrojů, ale ve výsledku je takový systém příliš složitý pro používání [15].
8
Kapitola 3
Geolokace podle IP adresy Geografická lokalizace, zkráceně geolokace (geolocation), znamená proces rozpoznání zeměpisné polohy osoby nebo zařízení prostřednictvím digitálních informací přenášených Internetem. Na rozdíl od pozičních systémů popisující polohu pomocí zeměpisných souřadnic, geolokační údaje mají srozumitelnější formu podobnou poštovní adrese. Obsahují informace o státu, kraji, městu, PSČ a ulici, volitelně také o poskytovateli Internetu, časové zóně či zeměpisných souřadnicích. Pro určení polohy zařízení na Internetu postačuje znalost IP (Internet Protocol) adresy, která jednoznačně identifikuje dané zařízení. Protože však mezi IP adresou a její polohou není žádná souvislost, je nutné zvolit jednu z metod geolokace podle IP adresy, zkráceně IP geolokace. Je nutné počítat s tím, že existující metody zjišťování polohy vykazují různě velké nepřesnosti: od desítek metrů až po stovky kilometrů.
Obrázek 3.1: Pomocí webové služby [2] zjistí uživatel Internetu svou polohu. Na obrázku je správně určeno umístění počítače připojeného v Brně. 9
3. Geolokace podle IP adresy Rozvoj mobilních zařízení a tzv. chytrých telefonů umožnil do geolokace zapojit také další technologie – GPS, sítě mobilních operátorů nebo WiFi sítě. Uživatelé těchto zařízení mohou svou polohu sdílet na Internetu v online aplikacích (např. mapy či sociální sítě). Jedná se o přesnější metody geolokace (v rozmezí jednotek až stovek metrů), které ale nelze použít vzdáleně bez vědomí uživatele a spolupráce daného zařízení. IP geolokace tak zůstává jedinou možností, jak zjistit polohu zařízení na Internetu.
3.1
Principy IP geolokace
Metody IP geolokace dělíme podle komunikace s hledaným zařízením na dvě základní skupiny – pasivní a aktivní. Pasivní metody (viz 3.2) vyhledávají informaci o poloze na základě dostupných informací o síťovém zařízení. Nejjednodušší metoda odvozuje zemi původu podle doménového jména. Pro zjištění přesnější polohy se využívají geolokační databáze IP adres, které jsou základem většiny geolokačních služeb díky jednoduchému a rychlému dotazování. Pro IP adresu zařízení je vyhledán záznam s geolokačními údaji jejího vlastníka, resp. poskytovatele internetového připojení. Aktivní metody (viz 3.3) vypočítají polohu zařízení za pomocí měřitelných vlastností sítě, nejčastěji zpoždění přenosu k cílové stanici nebo znalosti topologie sítě. Základní metody odvozují vztah mezi zpožděním a zeměpisnou polohou pomocí systému referenčních uzlů se známými zeměpisnými souřadnicemi. Pro zpřesnění polohy se využívají i další přístupy, např. statistické odhady nebo informace z webových stránek. Přesnost určení polohy závisí na zvolené metodě geolokace. Obecně k odchylkám dochází při mapování skupin počítačů na několik unikátních IP adres. Nelze například odlišit polohu různých zařízení, pokud na Internetu vystupují pod jednou veřejnou IP adresou své brány; výsledkem geolokace pak bývá poloha této brány. Dalším rysem geolokace je, že uživatel Internetu může maskovat svou IP adresu při využití proxy připojení nebo anonymizačních služeb (např. TOR [16]). Geolokační služby umožňují proxy připojení detekovat a zjistit skutečnou IP adresu. 3.1.1 Standard ISO 3166 Mezinárodní standard ISO 3166 (Codes for the representation of names of countries and their subdivisions, [5]) definuje unikátní kódy zemí a jejich regionů. Standard vznikl roku 1974 a obsahoval pouze kódy zemí. V roce 1997 byl rozšířen o kódy regionů a rozdělen na tři části: 10
3. Geolokace podle IP adresy •
ISO 3166-1 definuje kódy zemí ve třech formátech: alpha-2 kód (dvoupísmenný), alpha-3 kód (třípísmenný) a číselný kód (trojciferný), např. České republice odpovídá záznam CZ, CZE, 203 ;
•
ISO 3166-2 je tvořen dvěma údaji oddělenými pomlčkou: alpha-2 kód států (dle ISO 3166-1) a kód regionu (délky 1-3 znaků), např. Jihomoravský kraj je určen jako CZ-JM ;
•
ISO 3166-3 obsahuje kódy zemí odstraněných z ISO 3166-1 oproti původnímu standardu z roku 1974.
Z těchto tří částí je nejvíce používaná část ISO 3166-1. Alpha-2 kód se stal nejznámějším standardem pro zkratky států využívaný například v doménových jménech nejvyšší úrovně (viz 3.2.1). 3.1.2 Využití geolokace Většina návštěvníků webových stránek se s využitím geolokace setkává ve formě reklamy cílené na stát nebo město, ve kterém daný člověk žije. Mezi nejdůležitější možnosti využití geolokace patří: •
cílené webové služby zahrnující zobrazení zpravodajství, počasí nebo reklamy podle regionu uživatelů Internetu;
•
filtrování obsahu webových stránek pro vyhovění legislativních pravidel určitých zemí;
•
rozvoj sociálních sítí s možností sdílení polohu mezi uživateli;
•
odhalování zneužití platebních karet;
•
provádění analýzy síťového provozu;
•
boj proti spamu.
3.2
Pasivní metody geolokace
Pasivní metody geolokace nejčastěji vycházejí z centralizovaného systému přidělování IP adres. Organizace IANA (Internet Assigned Number Authority) rozděluje velké bloky IP adres mezi pět regionálních Internetových registrátorů (Regional Internet Registries) pro regiony Afrika (AfriNIC ), 11
3. Geolokace podle IP adresy Asie/Tichomoří (APNIC ), Severní Amerika (ARIN ), Jižní Amerika (LACNIC ) a Evropa/Střední Východ/centrální Asie (RIPE NCC ). Poskytovatelé internetových služeb (Internet Service Providers) požádají příslušného registrátora, aby jim přidělil bloky IP adres, které následně dělí mezi koncové uživatele Internetu (firmy, organizace či běžné uživatele). 3.2.1 Doménová jména a DNS LOC Nejprimitivnější metodou zjištění polohy je zpětný překlad IP adresy na doménové jméno, které pro člověka představuje srozumitelný a lépe zapamatovatelný údaj. Na základě většiny domén nejvyššího řádu (cz, us, gb) lze odvodit polohu zařízení s danou IP adresou. Například zařízení s IP adresou 147.251.5.231 a doménovým jménem www.muni.cz se pravděpodobně nachází v České republice. Pro některé domény (např. com) však není možné zjistit zemi původu. Snahou zahrnout geolokační (resp. lokalizační) údaje do DNS záznamů bylo definování položky LOC (RFC 1876 [17]) pro zeměpisné souřadnice směrovačů, ale podle studie [18] bylo doplněno jen 1% údajů na Internetu. 3.2.2 Databáze whois Veřejné databáze whois představují nejjednodušší variantu databází IP adres. Díky centrálnímu systému přidělování IP adres je Internet rozdělen na pět regionů a každý má vyhrazený svůj whois server. Uživatel (resp. poskytovatel internetového připojení, firma nebo organizace) si do příslušné regionální databáze registruje své kontaktní a geolokační údaje pro IP adresy, které využívá. V databázích je pak možné vyhledávat polohu pomocí nástroje whois podle IP adresy, doménového jména nebo čísla autonomního systému. Odpověď na dotaz je vrácena v různorodém textovém formátu, který je obtížně automatizovaně zpracovatelný [19]. Velkou nevýhodou je registrace souvislých bloků IP adres poskytovateli Internetu nebo velkými společnostmi. Vrácená poloha pak neodpovídá umístění koncového uživatele, ale sídlu firmy. Další nepřesnost způsobuje absence kontroly zadaných údajů, které mohou být nesprávné nebo zastaralé. 3.2.3 Geolokační databáze Geolokace pomocí geolokačních databází IP adres představuje nejpoužívanější metodu zjišťování polohy zařízení na Internetu kvůli své jednoduché manipulaci. Databáze se skládají ze záznamů, které obsahují rozsahy IP adres 12
3. Geolokace podle IP adresy (označované jako bloky nebo prefixy IP adres) a k nim odpovídající geolokační údaje (např. stát, kraj, město a další). Při geolokaci jsou pro zadanou IP adresu vráceny údaje o poloze vždy ve stejném formátu, takže jsou na rozdíl od whois přístupu jednoduše zpracovatelné. Geolokační databáze tvoří základ většiny geolokačních služeb a jsou poskytované nejčastěji komerčně, protože udržování těchto databází v aktuálním stavu vyžaduje mnoho úsilí. Údržba úzce souvisí s tím, jak jsou geolokační údaje těchto databází zjišťovány, což není u většiny komerčních společností dostatečně objasněno. Muir a Van Oorschot [18] rozebírají možnosti použitelné při vytváření databází: od whois databází přes doménová jména, uživatelem zadávané údaje, metody založené na měření zpoždění až po zakoupení síťových topologií od poskytovatelů internetového připojení. Při volbě geolokační služby je nutné zvážit, jaké geolokační údaje je potřeba zjistit. Základním údajem je země původu a většina databází zahrnuje i další informace, např. o městě či zeměpisných souřadnicích. Na výběr je z volně dostupných (např. MaxMind GeoLite [4], Software77 [20], HostIP [21] a IPInfoDB [22]) nebo z placených databází (např. MaxMind GeoIP [23], IP2Location [24], Neustar IP Intelligence [25] a NetAcuity [26]). Srovnání přesnosti geolokačních databází bylo předmětem několika vědeckých článků ([27], [28] a [29]). Autoři poslední studie dospěli k závěru, že jediným spolehlivým údajem je zjištění země původu. Nepřesnost na úrovni měst je způsobena podobně jako u whois databází tím, že celé bloky adres jsou přiděleny pod adresu poskytovatele Internetu.
3.3
Aktivní metody geolokace
Aktivní geolokační metody hledají polohu zařízení na požádání. Oproti pasivním metodám odpadá nutnost udržovat databáze a výhodou některých metod je relativně přesnější určení polohy. Na druhou stranu je nutné počítat s určitou dobou (automatizovaného) výpočtu. Zásadní nevýhodou aktivních metod pro potřeby této práce je nicméně absence nasazení a vyzkoušení navržených algoritmů v praxi – výjimkou je služba Spotter (viz 3.3.3). 3.3.1 Metody založené na měření zpoždění Nejstarší skupina metod je založena pouze na měření zpoždění (doby nutné pro přenos datového segmentu od zdroje k příjemci) nebo RTT (Rount-Trip Time, zpoždění obousměrného přenosu) mezi hledaným zařízením a systémem referenčních uzlů (zařízení se známou zeměpisnou polohou). Nejjednodušším nástrojem pro měření zpoždění je ping. Přesnost bývá ovlivněna 13
3. Geolokace podle IP adresy rozmístěním referenčních uzlů (pomocí hustější struktury lze přesněji určit polohu zařízení) a zátěží uzlů (má vliv na nepřesnost přepočtu na vzdálenost). Nejméně přesnou metodou je GeoPing [30], která na základě měření zpoždění vypočítá nejbližší referenční uzel k hledanému zařízení a vrátí jeho polohu. Jednodušší Shortest Ping [31] využívá měření RTT a dosahuje výrazně přesnějších výsledků blížících se metodě CBG. Nepřesnost obou metod zvyšuje samotné zanedbání vzdálenosti mezi cílovým a referenčním uzlem. Constraint-Based Geolocation (CBG) [32] pro určení polohy využívá triangulační techniku (podobně jako GPS navigace). Zpoždění od jednotlivých referenčních uzlů jsou přepočítána na tzv. hranice vzdálenosti, které vymezují okolo každého uzlu kruhovou oblast, v níž se hledané zařízení může nacházet. Poloha je pak geometricky určena jako střed oblasti vzniklé jako průnik kruhů výskytu okolo všech uzlů. Speed of Internet (SOI) [31] představuje výrazné zjednodušení metody CBG při zachování přibližně stejné přesnosti určení polohy. 3.3.2 Metody založené na znalosti topologie sítě Topology-Based Geolocation (TBG) [31] zpřesňuje metodu CBG díky zahrnutí znalostí o topologii sítě. Nástroj traceroute vypisuje mezilehlé směrovače, na kterých je měřena doba RTT a odhadováno zpoždění skoků (hop) mezilehlých optických vláken. Pro určení polohy hledaného zařízení jsou využity zpoždění jak z referenčních uzlů, tak i z nalezených mezilehlých směrovačů. Znalost topologie sítě tak snižuje závislost na původních referenčních uzlech a umožňuje detekovat nepřímé směrovací cesty a cykly. Hlavní rozdíl mezi metodou Octant [33] a TBG je vymezení místa, kde se cíl nemůže nacházet. Tato negativní informace určuje minimální vzdálenost cíle od uzlu, zatímco pozitivní informace výskytu určuje maximální vzdálenost. Poloha se počítá díky triangulaci protínajících se mezikruží různých uzlů, kdy na základě četnosti průniků jsou jednotlivým oblastem přiřazeny váhy. Vrácená poloha cíle je vybrána na základě nejvyšší váhy regionů, čímž je dosaženo výrazně nižších odchylek než v případě CBG. 3.3.3 Statistické metody geolokace Přesnost CBG metody lze zvýšit pomocí statistických odhadů, které pro odvození polohy počítají pravděpodobnostní funkce – Statistical Geolocation [34], Learning-Based Geolocation [35] a Maximum Likelihood Estimation [36]. 14
3. Geolokace podle IP adresy Metoda Spotter [37] se od předchozích metod odlišuje zejména svou vysokou přesností (medián odchylky byl 30 km oproti 100 km u CBG a 120 km u metody Octant). Jedná se o jedinou aktivní metodu, kterou lze vyzkoušet online na Internetu. Spotter je založen na detailní statistické analýze vztahu mezi zpožděním a vzdáleností. Zatímco metody CBG a Octant přepočítávají zpoždění na 2D modely pro každý referenční uzel zvlášť, Spotter ze získaných dat odvozuje obecný 3D model zpoždění a vzdálenosti. Výsledkem je nejen určená poloha, ale i pravděpodobnost vyjádřená prostorovou výškou grafu. 3.3.4 Metody geolokace využívající informace z webu Metoda Street-Level Geolocation (SLG) [38] díky kombinaci dolování dat z webových stránek a odvození relativního síťového zpoždění dosahuje podle autorů zatím nejpřesnější lokalizace polohy (medián chyb dosáhl 2,11 km). Nevýhodami je testování pouze na území USA a relativně vysoká výpočetní náročnost. SLG využívá třívrstvý systém, který pro každou vrstvu snižuje prohledávanou oblast a zvyšuje tak přesnost geolokace. V první vrstvě je využita metoda SOI, která pomocí známých referenčních uzlů identifikuje oblast, kde se hledaný cíl nachází. Na základě dat z webových stránek jsou zjištěna poštovní směrovací čísla (PSČ) patřící do nalezené oblasti. Ve druhé vrstvě jsou díky zjištěným PSČ identifikovány a verifikovány nové referenční uzly, jejichž poloha je odhadnuta s pomocí nástroje traceroute, a které pomocí multilaterace dále pomáhají zpřesnit hledanou oblast. V poslední vrstvě jsou dohledány na základě PSČ další referenční uzly v dané oblasti. Pro určení polohy cílové stanice je použit princip relativních délek – na dostatečně malém území je poloha cíle rovna místu nejbližšího referenčního uzlu – pomocí kterého dosahuje metoda velmi přesných odhadů polohy cílové stanice.
15
Kapitola 4
Návrh geolokace v prostředí vysokorychlostních sítí Monitorování síťového provozu pomocí IP toků umožňuje provádět analýzu síťového provozu z mnoha hledisek. Geolokace pomáhá určovat zeměpisné souvislosti v síťové komunikaci, díky čemuž lze snadno indentifikovat polohu zařízení, které narušuje bezpečnost sítě (např. nevyžádanou poštu, viry nebo bezpečnostní incidenty). I přes tuto výhodu současné programy provádějí geolokaci pouze v malém měřítku nebo na požádání (podrobněji viz 7.4). Geolokační údaje bývají většinou dopočítány až po uložení záznamů toků na kolektoru, což není z výpočetního hlediska škálovatelné. Téma získávání a reprezentace geografických informací o IP tocích bylo náplní bakalářské práce Martina Husáka [39]. Jejím výsledkem byl plugin (zásuvný modul) pro NfSen, který u anonymizovaných záznamů toků zjišťoval země původu podle IP adres a ukládal do databáze. Plugin z těchto výsledků počítal statistiky o deseti nejvíce komunikujících zemích a znázornil je na mapě světa. Autor při testování dospěl k závěru, že geoplugin je „schopen pracovat i na sítích s velkým množstvím IP toků“. Představené řešení není optimální, protože geolokaci na vysokorychlostních sítích není vhodné provádět až po zpracování záznamů toků kolektorem. Autor původně používal centrální databázi přístupnou přes webové rozhraní a teprve při testování vyšlo najevo, že tento přístup je pomalý a nevhodný pro zpracování velkého množství dat v krátkém čase. Nevýhodu představuje také způsob uložení v databázi (kód země a počet toků), ze kterého není možné dodatečně zjistit geolokační údaje daného toku nebo odvodit profil síťové komunikace na základě států. Předkládaná práce se snaží výše uvedené nedostatky odstranit a umožnit plnohodnotnou geolokaci ve vysokorychlostních sítích.
4.1
Stanovení požadavků
Vysokorychlostními sítěmi rozumíme 10 Gbps sítě, kterými může každým směrem procházet až 14,88 milionu paketů za sekundu. Na síti Masarykovy univerzity reálný průtok dat obsahuje 0,5 milionu paketů za sekundu, kterým 16
4. Návrh geolokace v prostředí vysokorychlostních sítí odpovídá v průměru 6 000 toků za sekundu. Páteřní sítí CESNET2 v České republice pak obvykle prochází 60 000 až 70 000 toků za sekundu. Pro použití geolokace na vysokorychlostních sítích je nutné vymyslet, jak ukládat geolokační údaje během zpracování záznamů toků. Pro návrh geolokační funkcionality, která bude zodpovědná za získání informací o poloze podle IP adresy, jsou rozhodující tyto požadavky: 1.
Vybrat geolokační službu provádějící geolokaci pro IPv4 i IPv6 adresy.
2.
Rozhodnout, jaké geolokační údaje má smysl zjišťovat.
3.
Navrhnout optimální geolokační funkcionalitu pro získání těchto údajů.
4.
Začlenit geolokaci do vhodného programového vybavení a omezit vliv na výkon.
4.2
Volba geolokačních údajů
Původním cílem bakalářské práce bylo zjistit pro každou IP adresu trojici údajů (země, kraj a město). Na základě závěru studie [29] (viz v 3.2.3) byly geolokační údaje omezeny pouze na zemi původu. Kromě možné nepřesnosti určování polohy na úrovni měst byl dalším argumentem pro vypuštení těchto údajů fakt, že ukládání dalších informací by zatížilo dostupné diskové kapacity. S ohledem na optimální prostorovou složitost se pro ukládání kódu zemí dá využít standard ISO 3166-1 (viz 3.1.1), který definuje unikátní trojciferná čísla. Pro ukládání regionů by bylo možné využít ISO 3166-2, ale nevýhodou je, že kódy nemusí být pouze čísla, ale i řetězce jednoho až tří znaků. Mezinárodní standard pro kódy měst neexistuje, proto by se musely ukládat dlouhé názvy měst, což by neúměrně zvýšilo velikost záznamů toků. Závěr je tedy takový, že ve velkém je potřeba provést geolokaci pouze na úrovni států, která podává základní přehled o zěmepisné poloze síťového zařízení. Detailnější polohu (kraj, město a zeměpisné souřadnice) je vhodnější zjišťovat pouze pro několik vybraných toků, u kterých je vyžadována detailnější analýza.
4.3
Výběr geolokační služby
Při volbě geolokační služby bývá rozhodující přesnost vrácené polohy. Dalšími kritérii, které zmiňuje práce [39] jsou komerční zázemí, rozhraní a umístění databáze. Tabulka 4.1 ukazuje rozdělení nejznámějších geolokačních služeb na základě prvního a třetího kritéria. 17
4. Návrh geolokace v prostředí vysokorychlostních sítí Geolokační služby se dělí podle ceny na komerční a bezplatné, což úzce souvisí s tím, jaké geolokační údaje obsahují. Zatímco bezplatné databáze poskytují spíše jen informace o zemi původu a některé i o městu, komerční služby sbírají více geolokačních údajů (např. město, zeměpisné souřadnice a informace o poskytovateli internetového připojení) pro přesnější určení polohy. Umístění databáze, na kterém závisí typ rozhraní, má velký vliv na rychlosti dotazování. Centrálně spravované databáze (např. HostIP [21], IPInfoDB [22], Neustar IP Intelligence [25] a NetAcuity [26]) jsou základem webových služeb, které pro zadané IP adresy vrací geolokační údaje. Hlavní nevýhodou tohoto přístupu je latence způsobená vzájemnou komunikací, která brání nasazení na vysokorychlostních sítích. Lokální databáze si musí uživatel stáhnout a průběžně aktualizovat, ale poskytují rychlý a snadný přístup k datům obvykle pomocí volání funkcí přidruženého rozhraní pro programovací jazyky (API, Application Programming Interface). Software77 [20] od společnosti Webnet77 představuje bezplatnou databázi, ke které je možné přistupovat pomocí API různých programovacích jazyků (C, PHP, Perl, Java). Jediným geolokačním údajem je země původu, proto se jedná o nejméně přesnou databázi [27]. Společnost MaxMind [40] je jedním z průkopníků IP geolokace a odhalování zneužití platebních karet. Nabízí širokou škálu databází s různými geolokačními údaji a šíří je buď bezplatně (GeoLite [4]), nebo komerčně (GeoIP [23]). K databázím se přistupuje pomocí API s podporou množství programovacích jazyků (C, Perl, Python, PHP, Ruby, Java, C#). Pro bezplatnou verzi jsou k dispozici databáze GeoLite Country (informuje pouze o zemi původu) a GeoLite City (informuje o zemi, regionu a městu). Komerční databáze GeoIP přináší vyšší přesnost geolokace a umožňuje získávat další údaje o organizaci, poskytovateli internetového připojení a doménovém jméně. Podobné služby a různé verze databází jako GeoIP nabízí i společnost IP2Location [24], ale již pouze komerčně.
Databáze Centrální Lokální
Bezplatné služby IPInfoDB Hostip.info MaxMind GeoLite Software77
Komerční služby Neustar IP Intelligence NetAcuity MaxMind GeoIP IP2Location
Tabulka 4.1: Přehled nejznámějších geolokačních databází 18
4. Návrh geolokace v prostředí vysokorychlostních sítí Vzhledem k popularitě a dlouhému působení společnosti MaxMind byla vybrána její bezplatná databáze GeoLite Country, která je aktualizována jednou měsíčně. Přístup k ní je umožněn přes rozhraní pro programovací jazyk C a vyhledávání je možné zrychlit pomocí načtení do paměti.
4.4
Návrh geolokační funkcionality
Rozhraní pro programovací jazyk C se jmenuje GeoIP a zahrnuje zdrojové soubory pro používání ve vlastních projektech, databázi GeoLite Country a trojici programů (geoiplookup, geoiplookupv6 a geoipupdate) pro geolokaci z příkazového řádku a aktualizaci nainstalovaných databází. Při programování je nutné importovat hlavičkové soubory (GeoIP.h), které slouží pro získávání údajů z různých typů geolokačních databází. Pro získání kódu země stačí zavolat funkci GeoIP_country_code_by_addr přebírající jako argumenty ukazatel na databázi a IP adresu v textovém formátu (např. 147.251.5.231). Funkce zavolá GeoIP_id_by_name vracející index země a pokud je větší než 0, pole GeoIP_country_code[country_id] vrací (alpha-2) kód země odpovídající ISO 3166-1 standardu. Pomocí indexu země lze vrátit také alpha-3 kód nebo jeho jméno. GeoIP nepodporuje vrácení číselného kódu dle ISO 3166-1, který je vhodnější pro rychlé porovnávání údajů. Pro překlad řetězce na číslo byla vytvořena struktura country_code_iso3166_t obsahující alpha-2 a číselný kód. Pro získání číselného kódu byly navrženy dva přístupy, které jsou spolu s celým schématem geolokace znázorněny na obrázku 4.1. Původním řešením bylo vytvořit pole obsahující 248 států a číselný kód IP adresa (v4/v6) dotaz na GeoLite Country databázi b) přímý přístup přes index
index země a) překlad pomocí pole název země
kód země (alpha-3)
kód země (alpha-2)
MaxMind GeoIP funkcionalita
kód země (číselný)
doplněná podpora ISO 3166-1
Obrázek 4.1: Schéma geolokační funkcionality 19
4. Návrh geolokace v prostředí vysokorychlostních sítí získávat překladem pomocí sekvenčního prohledávání pole podle alpha-2 údaje. Ačkoliv testování prokázalo, že geolokační výkon prováděný tímto způsobem je dostatečný, bylo nutné se zamyslet nad efektivnějším způsobem. Optimalizace výpočtu číselného kódu je založena na vytvoření identického pole odpovídající GeoIP_country_code[256] (vrací alpha-2 kód), které bude obsahovat strukturu country_code_iso3166_t. Pro automatizované vytváření takového pole byl připraven jednoduchý nástroj numcode-tool [41], který pro aktuální verzi rozhraní GeoIP a vstupní seznam ISO standardu vytvoří pole iso3166_GeoIP_country_codes[256] obsahující kódy zemí v číselném a alpha-2 formátu. Pseudokód geolokační funkcionality je znázorněn v algoritmu 1. Rozhraní GeoIP poskytuje funkce pro načtení a odstranění databáze, proto odpadá nutnost programovat vlastní obslužný kód. Typ otevření specifikuje, zda bude databáze čtena z disku, nebo bude načtena do paměti, což ovlivňuje rychlost dotazování databáze a celkový výkon (viz 7.1). Algorithm 1 Vypočítání číselných kódů zemí pro dané IP adresy ukazatel geoipv4 ← GeoIP _new(typ otevření) ukazatel geoipv6 ← GeoIP _open_type(databáze IPv6, typ otevření) for all IP _adresa do if IP _adresa je IPv4 then ctry_id ← GeoIP _id_by_ipnum(geoipv4, IP _adresa) else if IP _adresa je IPv6 then ctry_id ← GeoIP _id_by_ipnum_v6(geoipv6, IP _adresa) end if end if ulož iso3166_GeoIP _country_codes[ctry_id].num_code end for GeoIP _delete(geoipv4) GeoIP _delete(geoipv6)
4.5
Navržené přístupy geolokace
Posledním krokem je začlenění geolokační funkcionality do vhodného existujícího programového vybavení. První možností je provádět geolokaci na straně kolektoru (viz kapitola 5). Vzhledem k popularitě kolektoru NfSen/NFDUMP na sítích Masarykovy univerzity i v Evropě se nabízí řešení provádět geolokaci v balíku nástrojů NFDUMP, zatímco NfSen umožní vy20
4. Návrh geolokace v prostředí vysokorychlostních sítí kolektor směrovač
sonda
směrovač
sonda sonda
Obrázek 4.2: Ukázka architektury monitorování toků s více exportéry tvářet profily komunikace na základě zemí původu. Navržený přístup umožňuje oproti předchozímu přístupu [39] výrazně redukovat výpočetní nároky pro dodatečné dopočítání geolokačních údajů. Díky ukládání geolokačních údajů v záznamu toku je možné v následné analýze dat pro země původu provádět obvyklé operace nástroje nfdump (počítání top N statistik, filtrování a agregování záznamů). Doplněná geolokační funkcionalita musí být schopná pro každý tok na základě zdrojové a cílové adresy efektivně dopočítat geolokační údaje a uložit je. Druhou možností je provádět geolokaci na straně exportéru (viz kapitola 6), což je výhodné např. v situaci znázorněné na obr. 4.2. Byl vytvořen geolokační plugin pro FlowMon sondu, který provádí geolokaci před exportem toků. Geolokační údaje jsou uloženy do záznamu toků, které jsou následně zpracovány kolektory. Součástí je i možnost distribuovat data na kolektory podle zadaných údajů.
21
Kapitola 5
Vývoj geolokace na straně kolektoru V předchozí kapitole bylo popsáno, jak efektivně spočítat geolokační údaje síťové komunikace na základě zdrojové a cílové IP adresy měřeného IP toku. Tato funkcionalita bude nyní doplněna do nejpoužívanějšího kolektoru tvořeného nástroji NfSen/NFDUMP představených v 2.3.1. Vytvořené řešení je označováno jako geolokace na straně kolektoru, protože umožňuje během zpracování dat na kolektoru přidat do ukládaných záznamů toků geolokační údaje. Pro přidání podpory geolokace je nutné upravit nástroje nfcapd a nfdump sady NFDUMP tools, jak je vidět na obrázku 5.1. Oproti tomu nástroj nfprofile nevyžaduje změny pro vytváření profilů provozu podle zemí původu. Úpravy provedené ve webovém rozhraní NfSen (povolení počítání statistik na základě geolokačních údajů) jsou natolik transparentní, že nepotřebují větší pozornost. Tato kapitola shrnuje poznatky o doplnění podpory geolokace pro sadu NFDUMP, které mohou posloužit jako návod při doplnění další funkcionality nebo údaje do těchto nástrojů. Výsledkem geolokace na straně kolektoru je patch (opravný kus kódu) pro aktuální NFDUMP verze 1.6.9. Úpravy ve zdrojovém kódu jsou pro vyšší transparentnost obaleny makrem preprocesoru GEOIP pro podmíněný překlad souborů. Makro je definováno uživatelem, pokud před sestavením sady NFDUMP zadá konfigurační příkaz: ./configure --with-geoipmaxmind. Sbírání dat
Zpracování dat
NetFlow/IPFIX v5, v9
výpis záznamů nfcapd
úložiště
nfdump top N statistiky agregování
geolokace
filtrování nfprofile
NfSen profily
Obrázek 5.1: Architektura geolokace na straně kolektoru 22
5. Vývoj geolokace na straně kolektoru
5.1
Analýza nástrojů NFDUMP
Při doplňování geolokační funkcionality je klíčovou otázkou, kam ukládat zjištěné kódy států. Pro ověření smyslu a výkonu geolokace byly údaje nejprve zapisovány do dvojice existujících polí pro zdrojový a cílový autonomní systém (AS). Vhodnější je definovat vlastní dvojici políček pro 16bitová čísla, což vyžaduje znalost ukládání záznamů toků. Záznamy jsou programem nfcapd ukládány do speciální struktury, která může obsahovat proměnlivý počet údajů v závislosti na konfiguraci nástroje a měřených vlastnostech toků. Z důvodu rozšiřitelného záznamu se hovoří o tzv. rozšíření, nebo-li údaji v záznamu (od IP adres, přes čítače paketů či bajtů, VLAN záznam, až po MAC adresy). Přehled dostupných rozšíření z roku 2009 je rozebrán v diplomové práci [15]. Mohou existovat údaje záznamu, které nemají definované odpovídající rozšíření, a naopak. Autor nástrojů NFDUMP u zdrojového kódu popsal, které soubory musí být změněny pro definování vlastního rozšíření, což bude využito při návrhu vlastního geolokačního rozšíření: 1.
Přidej vhodnou definici pro nové rozšíření do souboru nffile.h.
2.
Aktualizuj pole extension_descriptorv nfx.c o nové rozšíření a zvyš uživatelské číslo rozšíření.
3.
Přidej filtr do grammar.y a otestuj ho v souboru nftest.c.
4.
Uprav soubor nffile_inline.c.
5.
Definuj funkce pro výpis v souboru nf_common.c.
6.
Přidej definici pro počítání statistik do souboru nfstat.c.
5.2
Návrh vlastního geolokačního rozšíření
Při vytváření vlastního rozšíření je nutné upravit čtyři zdrojové soubory znázorněné na obrázku 5.2, které jsou společné pro všechny nástroje NFDUMP. Dále je nutné upravit soubory pro podporu filtrování, agregování a počítání statistik na základě nového rozšíření. Protože jsou tyto soubory využívané pouze nástrojem nfdump, budou jejich úpravy popsány v 5.4. V souboru nffile.h jsem nejprve definoval makro EX_COUNTRY_CODE (určuje pořadové číslo rozšíření) a strukturu tpl_ext_50_s (obsahuje 16bitové číselné proměnné pro uložení zdrojové a cílové země). 23
5. Vývoj geolokace na straně kolektoru definice rozšíření nffile.h
nfx.c popis rozšíření
nf_common.c názvy a zkratky pro zobrazení
nffile_inline.c načtení údajů pro zobrazení
Obrázek 5.2: Soubory změněné při vytvoření vlastního rozšíření
#define EX_COUNTRY_CODE 50 typedef struct tpl_ext_50_s { uint16_t src_ctry; uint16_t dst_ctry; uint8_t data[4]; // points to further data } tpl_ext_50_t; V druhé části souboru je definovaná struktura master_record_s, která obsahuje všechny dostupné údaje o záznamu IP toků (od IP adres a portů, přes čítače paketů a bajtů, po MAC adresy). Každé rozšíření musí být zarovnáno na 64 bitů a na proměnné se odkazuje pomocí ofsetu, masky a posunu. Špatné zarovnání rozšíření vede k chybně určeným odkazům na uložené údaje, což se projevuje u agregování, filtrování a počítání statistik. uint16_t src_ctry; // index 50 0xffff’0000’0000’0000 uint16_t dst_ctry; // index 50 0x0000’ffff’0000’0000 uint32_t ctry_fill; // align 64bit word #define OffsetCtryCode (offsetof(master_record_t,src_ctry)>>3) #ifdef WORDS_BIGENDIAN #define MaskSrcCtry 0xffff000000000000LL #define ShiftSrcCtry 48 #define MaskDstCtry 0x0000ffff00000000LL #define ShiftDstCtry 32 #else #define MaskSrcCtry 0x000000000000ffffLL #define ShiftSrcCtry 0 #define MaskDstCtry 0x00000000ffff0000LL #define ShiftDstCtry 16 #endif 24
5. Vývoj geolokace na straně kolektoru Soubor nfx.c obsahuje pole extension_descriptor[] popisující každé rozšíření pomocí těchto údajů: číslo rozšíření v souboru nffile.h, velikost v bajtech, uživatelské číslo rozšíření (využito v nfcapd), zda se jedná o výchozí rozšíření a popis. Pro geolokační rozšíření je to: { EX_COUNTRY_CODE, 4, 33, 0, "2 byte src/dst ctry code"} V souboru nf_common.c je pole format_token_list[], které definuje symbol pro výpis údaje, poté zda se jedná o IP adresu, nadpis sloupce pro nfdump a funkci pro vypsání políčka do řetězce – například: { { { {
"%scc", "%dcc", "%sccan", "%dccan",
0, 0, 0, 0,
"Src "Dst "Src "Dst
Ctry", Ctry", Ctry", Ctry",
String_SrcCtry }, String_DstCtry }, String_SrcCtryAN }, String_DstCtryAN },
Posledním upravovaným souborem je nffile_inline.c, který obsahuje funkce ExpandRecord_v2() a PackRecord() pro převod údajů ze strukturního typu tpl_ext_50_t do master_record_t a naopak.
5.3
Návrh ukládání geolokačních údajů
Základem nástroje nfcapd je zdrojový soubor nfcapd.c, který pro zpracování a uložení toků dat volá funkce definované v souborech NetFlow_v5_v7.c, NetFlow_v9.c a ipfix.c. Pro přidání geolokační funkcionality je zapotřebí upravit právě tyto soubory (viz obrázek 5.3). Pro optimalizované získání číselného kódu země (viz 4.4) byly vytvořeny pomocné soubory countrycode.h a countrycode.c deklarující a definující pole const country_code_iso3166_t iso3166_GeoIP_country_codes[256]; vytvořeného strukturního typu country_code_iso3166_t (obsahuje číselný a alpha-2 kód dle ISO 3166-1). Do souboru nfcapd.c bylo přidáno otevření dvou databází GeoIP.dat a GeoIPv6.dat. K nim se přistupuje za pomoci ukazatelů, které budou využívány během výpočtu geolokace v dalších třech souborech. Funkce run() zpracová toky a podle typu exportovaného toku volá Process_v5_v7(), Process_v9() nebo Process_IPFIX(). Před ukončením programu je nutné pro oba ukazatele zavolat funkce GeoIP_delete(), které uvolní databáze z paměti. Protože NetFlow v5/v7 má předem danou strukturu záznamu toku, zpracování je jednodušší než v případě NetFlow v9. V souboru netflow_v5_v7.c 25
5. Vývoj geolokace na straně kolektoru otevření a zavření databáze nfcapd.c
netflow_v5_v7.c
netflow_v9.c
ipfix.c
výpočet zemí původu a uložení do záznamu na disku
Obrázek 5.3: Soubory změněné při zahrnutí geolokace v nfcapd je nutné rozšířit statické pole v5_full_mapp[] (definuje sedm rozšíření pro tuto verzi NetFlow) a makro EX_COUNTRY_CODE. Dále se musí přidat výpočet geolokace v těle funkce Process_v5_v7(), která zpracovává jednotlivé údaje v záznamech toků. Zdrojová a cílová IP adresa pro výpočet geolokace je získána ze struktury ipv4_block. Vypočítaný číselný kód země je pak uložen do paměti určené ukazatelem data_ptr takto: tpl_ext_50_t *tpl = (tpl_ext_50_t *)data_ptr; tpl->src_ctry = iso3166_GeoIP_country_codes[src_id].num_code; tpl->dst_ctry = iso3166_GeoIP_country_codes[dst_id].num_code; data_ptr = (void *)tpl->data; Úpravy souboru netflow_v9.c jsou složitější, protože NetFlow verze 9 využívá šablony pro specifikaci, jaké údaje (rozšíření) budou zpracovávány. Nejprve je nutné přidat 32bitový ofset (ctry_offset) do struktury input_translation_s, který slouží jako dočasná proměnná během zpracovávání záznamu. Statický funkční ukazatel *setup_translation_table() pak vyplní vstupní tabulku ofsetů table typu input_translation_t, do které se mj. budou ukládat kódy zemí. Z toho důvodu je nutné přidaný ofset inicializovat na první bajt geolokačního rozšíření. Funkce Process_v9() zpracovává základní údaje o záznamu a volá funkce podle typu záznamu: šablona, šablona voleb nebo data. Každá šablona specifikuje, jaká políčka (rozšíření) se nachází v následujících datových záznamech. Ve funkci Process_v9_templates() je nutné povolit geolokační rozšíření, protože program by jako výchozí rozšíření použil pouze ta, která jsou součástí šablony záznamu. Geolokace a uložení hodnot je provedeno ve funkci Process_v9_data() v místě, kde se zpracovávají údaje, které nejsou součástí záznamu toku. IP adresy se získají pro typ IPv4 z 32bitových polí data_record->data[0] (zdrojová adresa) a data_record->data[1] (cílová). Každá 128bitová IPv6 26
5. Vývoj geolokace na straně kolektoru adresa je uložena ve dvou 64bitových hodnotách, které je nutné převést na strukturu in6_addr. V té je IP adresa uložena jako 4 prvky 32bitového pole v tzv. síťovém uspořádání (network byte order), což znamená, že se musí převrátit pořadí bitů. Výsledný kód země je uložen do paměti podobně jako u NetFlow_v5_v7.c: tpl_ext_50_t *tpl = (tpl_ext_50_t *)&out[table->ctry_offset];
5.4
Návrh doplnění operací pro nfdump
Předchozí úpravy umožňují ukládání záznamů toků včetně geolokačních údajů a výpis v programu nfdump. Pro podporu operací jako agregování, filtrování a počítání statistik je nutné doplnit rozšíření i k souborům uvedeným na obrázku 5.4. Na rozdíl od úprav programu nfcapd není potřeba upravovat soubor nfdump.c, který pouze volá operace definované v samostatných souborech. nfdump.c
nflowcache.c agregování
nfstat.c statistiky
grammar.y
scanner.l
filtrování
Obrázek 5.4: Soubory změněné při doplnění operací pro nfdump V souboru nflowcache.c pole aggregate_info[] definuje agregační funkcionalitu. Ta byla doplněna o agregační řetězce (srcctry a dstctry) spojené s nastavením ofsetu, masky a posunu pro geolokační údaje. Podobně se rozšíří i soubor nfstat.c, který v poli StatParameters[] definuje základní údaje pro počítání statistik. Výpis je možný pro číselné hodnoty (srcctry, dstctry a ctry) nebo dvoupísmenný kód (srcctryan, dstctryan a ctryan) podle ISO 3166-1 standardu. Filtrovací syntaxe je definovaná v souboru grammer.y a klíčové slovo ctry pak v scanner.l. Filtrování je možné buď ve tvaru ctry kód státu, nebo ctry in [několik kódů za sebou].
27
Kapitola 6
Vývoj geolokace na straně exportéru Geolokační funkcionalita může být vedle kolektoru doplněna také na exportér. Geolokace bude provedena před exportem dat a údaje o zemi původu budou zapsány přímo do záznamu toku. Kolektor přijímající tyto toky zjistí, že záznam obsahuje geolokační údaje, a proto už je nemusí zjišťovat. V případě zpracování dat z několika exportérů je tak výpočet zemí původu distribuován mezi několik zařízení, což zvyšuje škálovatelnost geolokace v prostředí vysokorychlostních sítí. Navržené řešení je označováno jako geolokace na straně exportéru a bylo implementováno jako plugin (zásuvný modul) pro FlowMon sondu [7]. Pomocí pluginů je možné definovat chování exportéru při vytváření, zpracování, filtrování a exportu toků. Na obrázku 6.1 je znázorněna architektura FlowMon sondy, ve které plugin pro vstupní data v paměti toků vytváří jednotlivé záznamy toků. Po uplynutí definovaného časového limitu jsou toky z paměti odstraněny a předány exportovacímu pluginu, který ukládá záznamy do NetFlow či IPFIX paketů. Před uložením jsou jednotlivé záznamy toků doplněny o geolokační údaje pomocí vytvořeného pluginu. Vedle snížení výpočetních nároků centrálního kolektoru lze na základě zemí původu distribuovaně směrovat data mezi kolektory. Exportér bude schopen pro definovaný seznam zemí odesílat dané záznamy toků na určený kolektor. Příkladem použití je oddělení síťového provozu ze zemí jako Čína, Ukrajina a Tajvan, který je podroben detailnější analýze (viz obr. 7.3).
pakety
vstupní data
IPFIX (NetFlow v9)
export
paměť toků toky
toky obohacené o geolokační údaje
flowmon-geo-filter
Obrázek 6.1: Architektura geolokace na straně exportéru 28
6. Vývoj geolokace na straně exportéru
6.1
Analýza geolokace pomocí FlowMon sondy
Pro doplnění geolokační funkcionality do FlowMon sondy je nutné vytvořit filtrovací plugin, který vybírá, jaké záznamy toků budou exportovány. Každý plugin je tvořen dvěma funkcemi: plugin_filter_init() slouží pro získání údajů ze záznamů toků a plugin_filter_filter() nad těmito údaji provádí filtrování. Geolokační funkcionalitu je nutné doplnit do první funkce (viz 6.2), zatímco distribuce dat na různé kolektory bude prováděna ve filtrovací funkci (viz 6.3). Oproti geolokaci na straně kolektoru musí být geolokační údaje zapsány přímo do záznamu toků NetFlow nebo IPFIX. Při ukládání informací je nutné vycházet z vlastností těchto protokolů, aby byly údaje transparentní vůči kolektorům. U protokolu NetFlow verze 9 s předem danou množinou údajů o toku není možné definovat vlastní políčka, která by obsahovala zdrojový a cílový kód země. Pro otestování funkcionality je proto nutné zapisovat údaje do stávajících polí. Příkladem je dvojice polí SRC_AS a DST_AS obsahující číslo autonomního systému pro dané IP adresy, která bývají zřídka vyplněna. IPFIX protokol umožňuje na rozdíl od NetFlow v9 definovat vlastní políčka (enterprise elements), ale používané kolektory stále nedokážou zpracovat tyto flexibilní údaje. Pro praktické nasazení geolokace na straně exportéru je proto nutné rozšířit nástroje o čtení a ukládání těchto přizpůsobitelných údajů.
6.2
Návrh začlenění podpory pro geolokaci
Funkce plugin_filter_init() přebírá dvojici argumentů: parametry zadané uživatelem a seznam ukládaných údajů (getter_list). Pro získání konkrétního údaje z toku slouží funkce označovaná jako getter. Následuje ukázka upravené šablony pro NetFlow v9, kterou využívá sonda FlowMon: IP_PROTOCOL_VERSION=L3_PROTO IPV4_SRC_ADDR=L3_IPV4_ADDR_SRC IPV4_DST_ADDR=L3_IPV4_ADDR_DST SRC_AS=*SRC_GEO DST_AS=*DST_GEO Vlevo se nachází název údaje podle NetFlow protokolu, do kterého bude uložena hodnota vrácená getterem vpravo. Na posledních dvou řádcích je číslo autonomního systému nahrazeno geolokačními údaji o zemi původu, které budou dále navrženy (hvězdička znamená, že pokud není getter dostupný, bude vrácena hodnota 0). 29
6. Vývoj geolokace na straně exportéru Mezi seznam ukládaných údajů je nutné přidat nové gettery vracející kódy zemí dle standardu ISO 3166-1 (viz 3.1.1). Klíčovým argumentem jsou funkce value_fill_geo_src a value_fill_geo_dst, které jsou odpovědné za vyplnění těchto getterů. Právě v těchto funkcích bude probíhat geolokace pro IP adresy toku. getter_add(getter_list,"SRC_GEO", sizeof(uint32_t), retval, &value_ok, &value_length, &value_fill_geo_src); getter_add(getter_list,"DST_GEO", sizeof(uint32_t), retval, &value_ok, &value_length, &value_fill_geo_dst); V těle funkce plugin_filter_init() je před přidáním těchto getterů nutné inicializovat ukazatele na geolokační databáze pro IPv4 a IPv6 adresy. Ve funkcích value_fill_geo_src a value_fill_geo_dst, kde probíhá geolokace, je nejprve rozhodnuto, o jaký typ IP adresy se jedná. IPv4 adresa je přímo získána z proměnné record->l3.addr.ipv4.src.ip4_addr32[0], zatímco u IPv6 adresy je nutné provést inverzi bitů do síťového pořadí pomocí funkce htnol (host to network order long) pro čtveřici 32bitových čísel.
6.3
Návrh distribuovaného směrování dat podle kódů států
Funkce plugin_filter_filter() definuje toky, které budou odeslány k exportu (konstanta FLOW_FILTER_PASS) a které budou zahozeny (konstanta FLOW_FILTER_DROP). Filtrování je možné využít pro distribuované směrování dat podle kódů států. Cílem je vymyslet způsob, jak odesílat toky pouze vybraných definovaných zemí. Při spouštění exportéru je možné uvést vedle jména filtrovacího pluginu i soubor, který bude obsahovat státy, které mají být odeslány na exportér (resp. zahozeny). Například s tímto příkazem -F flowmon-geo-filter:/home/flowmon/geo-distr/malicious.cfg jsou načteny údaje ze souboru malicious.cfg. Soubor obsahuje řádky ve formátu podobné filtrovací syntaxi v nfdumpu: (not) (src/dst) ctry
Ze souboru jsou ve funkci plugin_filter_init() načítány kódy zemí, které jsou ukládány do dynamického spojovaného seznamu. Na jeho základě jsou toky ve funkci plugin_filter_filter() filtrovány.
30
Kapitola 7
Testování a ověření funkčnosti navrženého řešení Obě navržené metody geolokace byly nasazeny na 10 Gbps vysokorychlostní síť Masarykovy univerzity, která je napojena na národní síť pro vzdělání a výzkum, CESNET (Czech Education and Scientific NETwork). Důležitou podmínkou pro nasazení je, aby přidaná geolokace neznemožnila plnění hlavních cílů exportérů a kolektorů – export a sběr dat. Proto je nezbytné optimalizovat dotazování na geolokační databáze, které je nejnáročnější částí přidané funkcionality.
7.1
Testování geolokačního výkonu
Geolokační výkon je ovliněn příznakem, který se nastavuje při otevírání databáze a určuje, jak rychlé bude dotazování. Bez uvedení příznaku je databáze otevřena na disku, což zpomaluje vyhledávání kvůli zpoždění přístupu k pevnému disku (GEOIP_STANDARD). Pro urychlení je možné načíst databázi do paměti (GEOIP_MMAP_CACHE, GEOIP_CHECK_CACHE a GEOIP_MEMORY_CACHE). Bylo provedeno srovnání rychlosti dotazování geolokačních databází IPv4 a IPv6 adres, které je znázorněno na obrázku 7.1.
dotazů/s (v milionech)
16
GEOIP_STANDARD
14
GEOIP_MMAP_CACHE
12 GEOIP_CHECK_CACHE
10
GEOIP_MEMORY_CACHE
8 6 4 2 0 IPv4
IPv6
Obrázek 7.1: Srovnání výkonu dotazování na databázi GeoLite Country 31
7. Testování a ověření funkčnosti navrženého řešení Z grafu vyplývá, že načtení Country databáze IPv4 adress do paměti (příznak GEOIP_MMAP_CACHE a GEOIP_MEMORY_CACHE) umožňuje zpracovat 27x více dotazů za sekundu než v případě standardního čtení z disku. Podobné optimalizace dosahuje načítání databáze IPv6 adres. Měření při plném zatížení procesoru ukázalo, že je možné provádět až 157 milionu (resp. 54 milionu) dotazů pro IPv4 (resp. IPv6) adresy. Z tohoto důvodu bylo v navržené geolokační funkcionalitě použito načítání do paměti s příznakem GEOIP_MMAP_CACHE. Navržená geolokace zvládne teoreticky při výtížení procesoru 50 % provést geolokaci u 39 milionu (resp. 14 milionu) toků pro IPv4 (resp. IPv6) provoz. Na monitorované síti Masarykovy univerzity s počtem 6 000 toků za sekundu nemá geolokace vliv na výkon exportéru nebo kolektoru. Nízké výpočetní nároky byly ověřeny také během testování na páteřní síti CESNET2 obsahující 60 000 – 70 000 toků za sekundu.
7.2
Testování geolokace na straně kolektoru
Pro výpočet geolokace je nutné v nástroji nfcapd povolit geolokační rozšíření (číslo 33), jinak se údaje nebudou počítat. Ověření správnosti geolokace na straně kolektoru probíhalo ve dvou krocích: během vývoje a po nasazení. Nejprve bylo nutné ověřit správné doplnění zemí původu do vytvořeného geolokačního rozšíření (viz 5.2). Protože se liší způsob uložení geolokačních údajů v protokolech NetFlow v5 a NetFlow v9/ IPFIX, musela být otestována správnost úprav pro každý protokol zvlášť takto: 1.
Ověřit v ladicím režimu, že nástroj nfcapd vypisuje geolokační rozšíření a správné údaje v něm.
2.
Vypsat uložené záznamy nástrojem nfdump a zkontrolovat, že údaje ve sloupcích %scc a %dcc jsou správně vyplněné.
3.
Otestovat, zda agregování, filtrování a počítání statistik vrací správné výsledky.
Upravená sada nástrojů NFDUMP byla nasazena na vývojový kolektor, na kterém bylo ověřeno, že geolokace nezatěžuje výkon programů pro zpracování toků dat a spolehlivě plní svou funkci. Důkaz o tom, že nfcapd dokáže korektně uložit země původu pro zahrnuté standardy toků podává obrázek 7.2 (výstup z webového rozhraní NfSen). Exportér posílá data o vstupním provozu MU do kanálů NetFlow_v5, NetFlow_v9a IPFIX. Pro každý profil provozu je spočítána statistika (-s srcctry) s počty toků, která je zobrazena 32
7. Testování a ověření funkčnosti navrženého řešení RRDTOOL / TOBI OETIKER
Toky během 14.5 16:00 až 15.5 12:00 10 k 9 k 8 k 7 k 6 k 5 k 4 k 3 k 2 k 1 k 18:00
00:00
NetFlow_v5 203 840 156 276 643 372 826 703 250 528
299529(32.4) 265321(28.7) 69258(7.5) 30970(3.3) 25085(2.7) 23641(2.6) 19939(2.2) 13486(1.5) 12989(1.4) 10104(1.1)
06:00
12:00
NetFlow_v9 203 840 156 276 643 372 826 703 250 528
299528(32.4) 265318(28.7) 69257(7.5) 30970(3.3) 25083(2.7) 23639(2.6) 19938(2.2) 13485(1.5) 12989(1.4) 10104(1.1)
IPFIX 203 840 156 276 643 372 826 703 250 528
299530(32.4) 265320(28.7) 69258(7.5) 30970(3.3) 25085(2.7) 23642(2.6) 19939(2.2) 13486(1.5) 12989(1.4) 10104(1.1)
Obrázek 7.2: Ověření správnosti geolokace pro různé protokoly toků pod grafem. Z údajů vyplývá, že geolokační údaje jsou u tří nejpoužívanějších protokolů toků korektně vypočítány a uloženy do záznamu NFDUMP.
7.3
Testování geolokace na straně exportéru
Jak bylo popsáno v sekci 6.1, geolokace na straně exportéru neumožňuje zapisovat geolokační údaje do vlastního vytvořeného pole jako na straně kolektoru. Aby se mohly zapsané údaje porovnat s údaji doplněnými nástrojem nfcapd, musí se ukládat do některého existujícího pole. Pro ověření správnosti doplněných údajů bylo zapisováno do dvojice polí s čísly autonomního systému (AS), která zůstávají běžně nevyplněné. Díky porovnání kódů států v AS polích a v geolokačním rozšíření sady NFDUMP bylo dokázáno, že exportér doplňuje správné údaje. Distribuce dat na různé kolektory je demonstrována na obrázku 7.3. FlowMon sonda do kanálu škodlivý exportuje provoz z Číny, Tajvanu a Ukrajiny, zatímco ostatní zahrnuje zbývající státy. Poslední kanál vše zahrnuje celý vstupní provoz do MU, který je nefiltrovaný. Na obrázku je vidět, že geolokační plugin rozdělil příchozí toky do dvou skupin. Pro profil toků podle 33
7. Testování a ověření funkčnosti navrženého řešení RRDTOOL / TOBI OETIKER
Toky během 11. 5. 00:00 až 13.5. 00:00 1.4 k 1.2 k 1.0 k 0.8 k 0.6 k 0.4 k 0.2 k So 00:00
škodlivý
So 12:00
Ne 00:00
ostatní
Ne 12:00
Po 00:00
vše
Obrázek 7.3: Demonstrace distribuce dat na porty stejného kolektoru spojení TCP jsou na grafu viditelné odchylky kanálu škodlivý, které značí útoky z trojice oddělených států.
7.4
Porovnání navrženého řešení s podobnými programy
Existuje několik programů, které umožňují síťovou analýzu na základě geolokačních údajů. Protože provádějí geolokaci pouze na požádání nebo v malém měřítku, je jejich nasazení na vysokorychlostní sítě nevhodné. Programy lze rozdělit do tří skupin podle toho, ve které fázi zpracování toků dat je geolokace prováděna: na exportéru, na kolektoru nebo v rámci vyhrazené analytické aplikace. Geolokaci na straně exportéru provádí nProbe [11], sonda pro export NetFlow/IPFIX toků na kolektor. Pro geolokaci je využita bezplatná databáze GeoLite City od společnosti MaxMind a mezi zjišťované údaje patří stát a město. Data jsou ukládána ve speciálních polích, které nemohou zpracovat ostatní kolektory a analytické aplikace, což je hlavní rozdíl od navrženého zásuvného modulu pro FlowMon sondu. Přesto se jedná o geolokaci schopnou pracovat i na vysokorychlostních sítích. Na straně kolektoru je několik programů, které provádějí geolokaci pouze na požádání a až po uložení toků dat. Analytický nástroj ntop [42] umožňuje dopočítat geolokační údaje (podobně jako nProbe) pro vybrané toky a znázornit je na mapě světa. Sada nástrojů SiLK [14] získává geolokační údaje z databáze GeoLite Country a umožňuje na požádání mapovat toky na dvoupísmennou zkratku státu a vypočítat statistiky. Posledním zmíněným nástrojem je Argus [43], který také využívá databázi od společnosti 34
7. Testování a ověření funkčnosti navrženého řešení MaxMind a oproti předchozím dvěma programům je možné doplnit dvoupísmenné kódy zemí přímo do NetFlow toků dat. Na rozdíl od nativní podpory geolokace v sadě nástrojů NFDUMP je zde nutné geolokační údaje počítat dodatečně. Poslední skupinu tvoří speciální analytické aplikace, které na základě toků dat z kolektoru provádějí dodatečnou geolokaci. SURFmap [44] představuje zásuvný modul do kolektoru NfSen, který umožňuje vizualizovat toky na mapě světa s využitím programovatelného rozhraní Google Maps. Geolokační údaje jsou získány z geolokačních databází IP2Location [24] (placená) nebo MaxMind GeoLite (bezplatná). Při zobrazení zdrojů síťové komunikace na mapě je použit geokodér (GeoCoder), který vypočítá zeměpisné údaje pro danou adresu. Nevýhodou je fakt, že geokodér může zjišťovat pouze omezený počet dotazů za den. SURFmap poskytuje 4 úrovně přesnosti zobrazení polohy (na úrovni států, krajů, měst a konkrétní polohy), která závisí na přesnosti získaných údajů z geolokační databáze pro dané IP adresy toku.
35
Kapitola 8
Prezentace výsledků geolokace Geolokační údaje doplněné v záznamech toků mají tři základní případy užití: plánování sítí, profilování provozu a detekci anomálií. Ačkoliv lze síťové chování analyzovat na základě statistik programu nfdump, uživatelsky přívětivějším je webové rozhraní aplikace NfSen. S využitím filtrování podle států původu lze vytvářet grafy síťového provozu pro definované státy. Sada nástrojů rrdtool [45] vykresluje grafy zvlášť pro toky, pakety a bajty; ke každému typu pak ještě zobrazuje komunikaci podle protokolu (celý provoz, TCP, UPD, ICMP a ostatní). Pro každou sledovanou komunikaci je nutné vytvořit vlastní profil (viz obrázky 8.1, 8.2, 8.7, 8.8 a 8.9). Tyto grafy zobrazují reálný provoz Masarykovy univerzity s celým světem. Údaje byly získány z vývojového kolektoru, na kterém byl nasazen geolokační patch pro NFDUMP.
8.1
Profilování provozu
Profilování síťového provozu umožňuje analyzovat používané služby a protokoly v monitorované síti. S podporou geolokace v záznamech toků je možné vytvářet profily také na základě zeměpisné polohy. Výhodou navrženého řešení je, že geolokační statistiky mohou být generovány v reálném čase a nemusí být dopočítány dodatečně jako u ostatních programů. Na obrázcích 8.1 a 8.2 jsou ukázány profily komunikace protokolu IPv4 a IPv6. Zajímavý je vysoký podíl provozu z USA (US_IN a US_OUT), který souvisí se soustředěním významných poskytovatelů služeb a sociálních sítích právě zde. Z profilu IPv6 komunikace je vidět nízký podíl USA a naopak vysoká účast Irska (IE_IN a IE_OUT). To je způsobeno tím, že většina těchto služeb má své ústředí v USA, ale data jsou obvykle umístěna blíže (v tomto případě na serverech v Irsku). Tento příklad ukazuje nepřesnost geolokačních databází. Dále je demonstrován i jiný přístup k profilování provozu, než statické profily nástroje NfSen. S využitím D3.js [46], knihovny JavaScriptu pro vizualizaci dat, byly vytvořeny dva typy grafů. Na obrázku 8.3 je ukázán dvou36
8. Prezentace výsledků geolokace
RRDTOOL / TOBI OETIKER
3.0 k
2.0 k
1.0 k
0.0
-1.0 k
-2.0 k
-3.0 k St 00:00
CA_IN OTHER_IN FR_OUT
St 06:00
St 12:00
St 18:00
CN_IN CZ_IN DE_IN FR_IN GB_IN RU_IN US_IN CA_OUT CN_OUT GB_OUT IE_OUT N_A_OUT OTHER_OUT
IE_IN CZ_OUT RU_OUT
Čt 00:00
N_A_IN DE_OUT US_OUT
Obrázek 8.1: Geolokační profil IPv4 komunikace (1 den)
RRDTOOL / TOBI OETIKER
14 12 10 8 6 4 2 0 -2 -4 -6 -8 -10 -12 -14 St 00:00
BY_IN OTHER_IN GB_OUT
St 06:00
St 12:00
St 18:00
CZ_IN DE_IN FR_IN GB_IN IE_IN RU_IN US_IN BY_OUT CZ_OUT IE_OUT IT_OUT N_A_OUT OTHER_OUT
IT_IN DE_OUT RU_OUT
Čt 00:00
N_A_IN FR_OUT US_OUT
Obrázek 8.2: Geolokační profil IPv6 komunikace (1 den)
37
8. Prezentace výsledků geolokace
CZ
HTTPS
HTTP
hodinový profil příchozí síťové komunikace. Na základě IP toků byly určeny nejpoužívanější služby (porty), které byly namapovány na 10 států s nejvyšší komunikací.
NTP
DNS
MUNI
US
RU DE GB IE
SK NL
ostatní
jiné porty
FR CN
Obrázek 8.3: Vizualizace vstupního provozu podle portů (2 hodiny) Na obrázcích 8.4 a 8.5 jsou znázorněny příchozí i odchozí IP toky do sítě MU. Ze statistik HTTP a HTTPS provozu pro dvouhodinové časové okno je možné získat představu o využívání těchto služeb deseti nejvíce komunikujícími státy.
38
8. Prezentace výsledků geolokace CN
příchozí toky US
CZ
SK
CZ,CZ,2064136 US,CZ,1800013 SK,CZ,191393 GB,CZ,131332 DE,CZ,131254 RU,CZ,127386 NL,CZ,111750 jiné,CZ,482975 IE,CZ,104612 CN,CZ,68907 JP,CZ,4089
RU
odchozí toky
NL
CZ,CZ,2018458 CZ,US,1663494 CZ,jiné,448639 CZ,JP,251941 CZ,SK,189599 CZ,RU,128680 CZ,GB,128547 CZ,DE,127777 CZ,NL,108749 CZ,IE,103857 CZ,CN,68350
JP
jiné
IE GB DE
Obrázek 8.4: Vizualizace příchozí/odchozí HTTP komunikace (2 hodiny) neznámé AT
příchozí toky US
SK
CZ
CZ,US,1218039 CZ,IE,293175 CZ,AT,118402 CZ,neznámé,109372 CZ,DE,63846 CZ,SK,38109 CZ,SE,32439 CZ,GB,23565 CZ,FR,20461 CZ,jiné,72114
SE
odchozí toky
jiné
IE GB FR DE
CZ,CZ,1269889 US,CZ,1216310 IE,CZ,292698 AT,CZ,117664 neznámé,CZ,109142 DE,CZ,65340 SK,CZ,38659 SE,CZ,32405 GB,CZ,24365 FR,CZ,21683 jiné,CZ,75744
Obrázek 8.5: Vizualizace příchozí/odchozí HTTPS komunikace (2 hodiny) 39
8. Prezentace výsledků geolokace
8.2
Detekce anomálií
Vytvořené geolokační profily mohou posloužit také pro detekci anomálií síťového provozu. V jednom profilu zahrnující celou příchozí komunikaci může být obtížné detekovat různé typy bezpečnostních incidentů (obr. 8.6). Geolokační profily pomáhají rozpoznat anomálie v grafu způsobené zvýšenou aktivitou určitých států (např. Čína, Ukrajina, Rusko). Na obrázku 8.7 je znázorněn profil zaměřující se právě na tyto země. Tento profil usnadňuje síťovým administrátorům práci při identifikování zdrojů anomálií, které pochází většinou z Číny a Ukrajiny. RRDTOOL / TOBI OETIKER
1.6 k 1.4 k 1.2 k 1.0 k 0.8 k 0.6 k 0.4 k 0.2 k 0.0 -0.2 k -0.4 k -0.6 k -0.8 k -1.0 k -1.2 k -1.4 k St 00:00
St 06:00
St 12:00
St 18:00
p3001
Čt 00:00
p3000
Obrázek 8.6: Profil TCP komunikace bez geolokace (1 den) RRDTOOL / TOBI OETIKER
1.6 k 1.4 k 1.2 k 1.0 k 0.8 k 0.6 k 0.4 k 0.2 k 0.0 -0.2 k -0.4 k -0.6 k -0.8 k -1.0 k St 00:00
CZ_IN UA_OUT
St 06:00
US_IN
UA_IN RU_IN RU_OUT
St 12:00
CN_IN
St 18:00
OTHER_IN CN_OUT
CZ_OUT
Čt 00:00
US_OUT OTHER_OUT
Obrázek 8.7: Profil TCP komunikace zobrazující provoz států s vysokým výskytem anomálií (1 den) 40
8. Prezentace výsledků geolokace Následující grafy prezentují další případy odhalených anomálií síťového provozu. Na obrázku 8.8 je znázorněna ICMP komunikace, která odpovídá času 01:00 – 19:00 předchozího grafu 8.7. Pro nižší měřítko monitorovaných toků lépe vyniknou anomálie příchozího provozu (mezi 2:00 – 4:00 a 10:00 – 11:00) a odchozího provozu (okolo 18:00). Obrázek 8.9 znázorňuje dvoudenní průběh HTTP komunikace. Ve středu mezi 10:00 – 18:00 proběhl DoS útok, který byl proveden z ostatních států (OTHER_IN), než jsou zobrazeny. RRDTOOL / TOBI OETIKER
80 70 60 50 40 30 20 10 0 -10 -20 -30 -40 -50 -60 02:00
CZ_IN CZ_OUT CN_OUT
04:00
US_IN US_OUT
06:00
08:00
10:00
12:00
14:00
OTHER_IN TH_IN TW_IN UA_IN OTHER_OUT TH_OUT TW_OUT
16:00
RU_IN UA_OUT
18:00
CN_IN RU_OUT
Obrázek 8.8: Anomálie profilu ICMP komunikace (18 hodin) RRDTOOL / TOBI OETIKER
800 700 600 500 400 300 200 100 0 -100 -200 -300 -400 -500 -600 Út 00:00
CZ_IN RU_IN N_A_OUT
Út 12:00
DE_IN GB_IN SK_IN US_IN NL_OUT
St 00:00
IE_IN CZ_OUT OTHER_OUT
St 12:00
JP_IN N_A_IN DE_OUT GB_OUT RU_OUT
NL_IN IE_OUT SK_OUT
Čt 00:00
OTHER_IN JP_OUT US_OUT
Obrázek 8.9: Normální a anomální profil HTTP komunikace (2 dny)
41
Kapitola 9
Závěr Bakalářská práce se zabývala geolokací jako technikou určení zdrojů síťové komunikace na základě IP adresy. Existující programy jsou pro využití v prostředí vysokorychlostních sítí nevhodné. Proto bylo nutné navrhnout optimální způsob provádění geolokace a začlenit ho do vybraného programového vybavení. Bylo rozhodnuto, že při geolokaci tisíců toků za sekundu je vhodné zjišťovat pouze země původu podle IP adresy. S využitím bezplatných databází MaxMind GeoLite Country pro IPv4 i IPv6 adresy a přidruženého programovacího rozhraní GeoIP jsou získávány číselné kódy komunikujících států, které jsou výhodné pro ukládání a porovnávání. Výsledkem jsou dva přístupy geolokace síťových toků lišící se místem provádění a způsobem ukládání údajů. Hlavním přínosem této práce je přidání nativní podpory geolokace do balíčku nástrojů NFDUMP. Kódy států jsou ukládány do vytvořeného geolokačního rozšíření, na základě kterého byla doplněna podpora obvyklých operací nástroje nfdump. Záznamy toků s geolokačními údaji je možné zobrazovat, filtrovat, agregovat a počítat statistiky. Ve webovém rozhraní NfSen se pak dají generovat profily síťové komunikace, které umožňují v reálném čase zobrazení provozu a detekci anomálií z pohledu mezinárodních aktivit na síti. Prezentované úpravy byly vystaveny formou patche pro aktuální verzi sady NFDUMP a konzultovány s autorem nástrojů, Petrem Haagem, který přislíbil začlenění podpory geolokace do jím vyvíjeného zdrojového kódu. Druhým výsledkem práce je prototyp geolokačního zásuvného modulu pro sondu FlowMon, který provádí geolokaci toků před jejich exportem na kolektor. Vypočítané kódy států dále umožňují distribuovat provoz na různé kolektory podle zadaných států. Protože pro protokol NetFlow v5/v9 v záznamu exportovaného toku není možné přidat vlastní geolokační pole, bude tento druh geolokace vhodný pro nasazení až po přechodu na protokol IPFIX. Aby zůstala zachována funkcionalita operací na kolektoru NFDUMP/NfSen, bude nutné v budoucnu provést další úpravy. Pokud bude schopen nástroj nfcapd při zpracování IPFIX provozu číst geolokační údaje uložené ve vlastních definovaných polích, geolokace na straně kolektoru ne42
9. Závěr bude již muset být prováděna. To je výhodné pro distribuované rozložení výpočetní zátěže v případě kolektoru zpracovávající toky z více exportérů. Navržené přístupy ke geolokaci byly otestovány na vysokorychlostních sítích Masarykovy univerzity a národní páteřní síti CESNET2. Praktické nasazení dokázalo vysokou škálovatelnost a nízkou zátěž programů, které mají za úkol exportovat nebo zpracovat IP toky dat. V kapitole 8 jsou demonstrovány způsoby prezentace geolokace, které mají využití především při profilování provozu a analýze anomálií. Za zmínku dále stojí, že na základě výsledků implementační části této práce byl napsán článek Large-Scale Geolocation for NetFlow na mezinárodní konferenci IFIP/IEEE IM 2013. Další výzkum v této oblasti by mohl zahrnovat vytvoření zásuvného modulu pro NfSen, který provede detailnější geolokaci vybraných síťových toků na požádání. Na webové stránce by se počítaly souhrnné statistiky o síťovém provozu a na základě dynamické vizualizace zjištěných dat by bylo možné lépe odvozovat síťové chování z hlediska komunikujících zemí, které podají více informací o zeměpisných souvislostech v síťovém provozu. Další možností je vytvoření detekčního systému, který využije geolokační údaje pro automatické informování o výchylkách sledovaného provozu.
43
Literatura [1] VELAN, P.: Processing of a Flexible Network Traffic Flow Information [online]. Diplomová práce, Masarykova univerzita, Fakulta informatiky, 2012 [cit. 2013-04-30]. URL
[2] What Is My IP Address? [online]. [cit. 2013-04-30]. URL
[3] Internet Users in the World [online]. [cit. 2012-11-11]. URL
[4] MaxMind: GeoLite Free Downloadable Databases [online]. [cit. 201305-01]. URL [5] ISO: Country Codes – ISO 3166 [online]. [cit. 2013-05-01]. URL [6] HAAG, P.: NFDUMP – NetFlow processing tools [online]. 2013 [cit. 2013-05-01]. URL [7] INVEA-TECH: FlowMon – Network monitoring [online]. 2013 [cit. 2013-05-01]. URL [8] Cisco: Cisco IOS NetFlow [online]. [cit. 2013-05-01]. URL [9] CLAISE, B.: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information [online]. 2008 [cit. 2013-04-29]. URL 44
Literatura [10] CLAISE, B.: Cisco Systems NetFlow Services Export Version 9 [online]. 2004 [cit. 2013-04-29]. URL [11] NProbe – An Extensible NetFlow v5/v9/IPFIX Probe [online]. [cit. 2013-05-01]. URL [12] COTTRELL, L.: Network Monitoring Tools [online]. [cit. 2013-05-01]. URL [13] HAAG, P.: NfSen – Netflow Sensor [online]. 2011 [cit. 2013-05-01]. URL [14] SiLK – CERT NetSA Security Suite [online]. [cit. 2013-05-01]. URL [15] KREJČÍ, R.: Network Traffic Collection with IPFIX Protocol [online]. Diplomová práce, Masarykova univerzita, Fakulta informatiky, 2009 [cit. 2013-04-29]. URL [16] Tor Project – Anonimity Online [online]. [cit. 2013-05-01]. URL [17] Davis, C.; Dickinson, I.; Goodwin, T.; aj.: A Means for Expressing Location Information in the Domain Name System [online]. 2004 [cit. 201304-29]. URL [18] MUIR, J. A.; OORSCHOT, P. C. V.: Internet geolocation: Evasion and counterevasion. ACM Computing Surveys (CSUR), 2009: str. 4. [19] VERNER, L.; KOMOSNÝ, D.: Geolokace síťových zařízení v internetových sítích. Elektrorevue, 2011/33. [20] Webnet77: Software77 – IP to Country Database [online]. [cit. 2013-0501]. URL [21] Hostip.info – My IP Addess Lookup [online]. [cit. 2013-05-01]. URL 45
Literatura [22] IPInfoDB – Free IP Address Geolocation Tools [online]. [cit. 2013-0501]. URL [23] MaxMind: GeoIP, IP Address Location Database [online]. [cit. 2013-0501]. URL [24] IP2Location – IP Address Geolocation [online]. [cit. 2013-05-01]. URL [25] Neustar: IP Inteligence [online]. [cit. 2013-05-01]. URL [26] Element, D.: NetAcuity IP Location Technology [online]. [cit. 2013-0501]. URL [27] HUFFAKER, B.; FOMENKOV, M.: kc claffy. Geocompare: a comparison of public and commercial geolocation databases. In Network Mapping and Measurement Conference (NMMC), 2011. [28] SHAVITT, Y.; ZILBERMAN, N.: A geolocation databases study. Selected Areas in Communications, IEEE Journal on, 2011: s. 2044–2056. [29] POESE, I.; UHLIG, S.; KAAFAR, M. A.; aj.: IP geolocation databases: unreliable? ACM SIGCOMM Computer Communication Review, 2011: s. 53–56. [30] PADMANABHAN, V. N.; SUBRAMANIAN, L.: An investigation of geographic mapping techniques for internet hosts. In ACM SIGCOMM Computer Communication Review, ACM, 2001, s. 173–185. [31] KATZ-BASSETT, E.; JOHN, J. P.; KRISHNAMURTHY, A.; aj.: Towards IP geolocation using delay and topology measurements. In Proceedings of the 6th ACM SIGCOMM conference on Internet measurement, ACM, 2006, s. 71–84. [32] GUEYE, B.; ZIVIANI, A.; CROVELLA, M.: Constraint-based geolocation of internet hosts. In Proceedings of the 4th ACM SIGCOMM conference on Internet measurement, ACM, 2004, s. 288–293. 46
Literatura [33] WONG, B.; STOYANOV, I.; SIRER, E. G.: Octant: A comprehensive framework for the geolocalization of Internet hosts. In Proceedings of the NSDI, 2007. [34] YOUN, I.; MARK, B. L.; RICHARDS, D.: Statistical geolocation of Internet hosts. In Computer Communications and Networks, 2009. ICCCN 2009. Proceedings of 18th Internatonal Conference on, IEEE, 2009, s. 1–6. [35] ERIKSSON, B.; BARFORD, P.; SOMMERS, J.; aj.: A learning-based approach for IP geolocation. In Passive and Active Measurement, Springer, 2010, s. 171–180. [36] ARIF, M. J.; KARUNASEKERA, S.; KULKARNI, S.; aj.: Internet host geolocation using maximum likelihood estimation technique. In Advanced Information Networking and Applications (AINA), 2010 24th IEEE International Conference on, IEEE, 2010, s. 422–429. [37] LAKI, S.; MÁTRAY, P.; HÁGA, P.; aj.: Spotter: A model based active geolocation service. In INFOCOM, 2011 Proceedings IEEE, IEEE, 2011, s. 3173–3181. [38] WANG, Y.; BURGENER, D.; FLORES, M.; aj.: Towards street-level client-independent IP geolocation. In NSDI’11. Proceedings of the 8thUSENIX conference on networked systems design and implementation, 2011, s. 27–36. [39] HUSÁK, M.: Získávání a reprezentace geografických informací o IP tocích [online]. Bakalářská práce, Masarykova univerzita, Fakulta informatiky, 2010 [cit. 2013-02-17]. URL [40] MaxMind: IP Geolocation and Online Fraud Prevention [online]. [cit. 2013-05-01]. URL [41] ČELEDA, P.: Geolocation tools – Homepage [online]. [cit. 2013-05-01]. URL [42] Ntop – Traffic analysis [online]. [cit. 2013-05-01]. URL [43] Argus – Auditing Network Activity [online]. [cit. 2013-05-01]. URL 47
Literatura [44] HOFSTEDE, R.: SURFmap – A Network Monitoring Tool [online]. [cit. 2013-05-01]. URL [45] OETIKER, T.: RRDtool [online]. [cit. 2013-05-01]. URL [46] D3.js: Data-Driven Documents [online]. [cit. 2013-05-01]. URL
48
Příloha A
Seznam elektronických příloh Archiv IS MU obsahuje tyto elektronické přílohy: •
Text práce v textovém i v elektronickém formátu.
•
Geolokační patch pro NFDUMP verze 1.6.9 a instalační pokyny.
•
Nástroj numcode-tool slouží pro vygenerování polí umožňující optimalizovaný překlad ISO 3166-1 dvoupísmenného kódu na číselný. V případě nové verze rozhraní GeoIP (aktuálně 1.5.0) je nutné pomocí tohoto nástroje vygenerovat novou dvojici polí, kterou uživatel doplní do zdrojového kódu souboru countrycode.c.
•
Zásuvný plugin flowmon-geo-filter pro geolokaci na FlowMon sondě spolu se šablonou NetFlow v9 pro zápis geolokačních údajů do AS políček. K otestování distribuce dat slouží soubory malicious.cfg a other.cfg.
•
Obrázky v pdf formátu využité v této práci.
49
