MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w¤§¨!"#$%&123456789@ACDEFGHIPQRS`ye| Mapa světa s vyznačením polohy Onion Routerů BAKALÁ Ř SKÁ PRÁ CE Ondřej Kotek Brno, jaro 2007 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. Vedoucí práce: Mgr. Vlastimil Holer ii Poděkování Velmi děkuji mému vedoucímu bakalářské práce Mgr. Vlastimilu Holerovi za dobré vedení a velmi cenné rady. iii Shrnutí Výsledkem této práce je webová aplikace, která by měla sloužit uživatelům a vývojářům sítě Tor pro vizualizaci umístění onion routerů ve světě a zároveň poskytovat základní informace o routerech a síti. iv Klíčová slova Tor, onion routing, geolokace, lokalizace podle IP adresy, Google Maps, Google Maps API, TorMap v Obsah 1 Ú vod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Tor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Onion routing obecně . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Onion routing v síti Tor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3 Adresář . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3.1 Distribuce adresáře . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3.2 Struktura adresáře . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Geolokace na internetu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Standardy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Zdroje dat a postupy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Projekty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Služby a produkty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4 Webové mapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1 Google Maps API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.2 Projekt gmaps-utility-library . . . . . . . . . . . . . . . . . . . . . . 13 5 TorMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1 Získání dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2 Modul googleIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3 Grafy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.1 Počet běžících routerů . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.2 Provoz na routeru . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.3 Provoz v síti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4 Webová stránka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4.1 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A Obsah přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 vi Kapitola 1 Ú vod Anonymizační sít'Tor (The Onion Routing) je distribuovaná sít'serverů, jejímž hlavním cílem je skrýt spojení mezi komunikujícími partnery. Uzly této sítě se nazývají onion routery (podle způsobu zabezpečení přenášených dat). Pro snazší správu sítě Tor je potřeba mít přehled o jejích jednotlivých uzlech. Vhod- ným prostředkem je filtrovatelný sezname uzlů, který poskytuje podrobnější informace a ideálně také grafy zobrazující provoz pro každý router. Důležitý je také přehled o geo- grafickém rozmístění uzlů sítě. Bylo by vhodné, aby byl také filtrovatelný a případně aby interaktivně zobrazoval bližší informace o jednotlivých routerech. Autoři Toru hledají dobrovolníky [1] pro různé oblasti vývoje a podpory svého pro- jektu. Tato práce vznikla za účelem vytvoření jedné z podpůrných aplikací Toru ­ zobra- zení onion routerů do mapy světa, které se s růstem a změnami sítě aktualizuje. Pro vytvoření takové aplikace je potřeba nalézt geografickou polohu jednotlivých onion routerů ­ tedy zjistit, jak je v Internetu lokalizovat. Nalezené routery pak dále zobrazit do (nejlépe interaktivní) mapy světa. Využitelné interaktivní mapové systémy nabízejí v dnešní době některé větší firmy v podobě webových stránek. Pomocí progra- mového rozhraní k danému systému je možné zakomponovat takovouto mapu do vlastní webové stránky. Výsledkem této práce je webová aplikace, která by měla sloužit uživatelům a vý- vojářům sítě Tor pro vizualizaci umístění onion routerů ve světě a zároveň poskytovat základní informace o routerech a síti. Projekt Tor je popsán v druhé kapitole této práce, geolokaci v Internetu je věnována kapitola třetí a kapitola čtvrtá se zabývá technologiemi webových mapových systémů. Pátá kapitola pak pojednává o výsledku této práce ­ projektu TorMap. 1 Kapitola 2 Tor Anonymizační sít' Tor (The Onion Routing) umožňuje lidem zlepšit jejich soukromí a bezpečnost na Internetu. Jde o sít'mixů s nízkou latencí, jejímž cílem je skrýt spojení mezi komunikujícími partnery. 2.1 Onion routing obecně Klient se do sítě onion routerů připojí přes vstupní bod (což obvykle bývá služba na stejném počítači), který vytvoří virtuální cestu (okruh) složenou z dalších známých onion routerů a stanoví symetrický kryptografický klíč s každým uzlem šifrujícím data. Výstup- ním bodem je obvykle poslední z uzlů v cestě, ale může jím být kterýkoliv kromě prvního. Několikrát zašifrovaná data putují okruhem a na každém uzlu se provede jedno dešifro- vání (viz obrázek 2.1). Po posledním dešifrování odešle uzel data skutečnému adresátovi. Vlastní data může vidět pouze vstupní a výstupní uzel. Obrázek 2.1: Šifrování dat v okruhu (přejato z [2]) 2.2 Onion routing v síti Tor Onion routery běží jako normální uživatelské procesy bez zvláštních práv a udržují spo- jení s ostatními onion routery pomocí protokolu TLS [3], který zajišt'uje bezpečnost komu- 2 2. TOR nikace. Na uživatelských počítačích je spuštěna onion proxy, která zpracovává adresáře onion routerů, vytváří okruhy skrze sít'a spravuje spojení od uživatelských aplikací. Každý onion router udržuje dlouhodobý identifikační klíč (identity key) a krátko- dobý onion klíč. Identifikačním klíčem se podepisují certifikáty TLS, deskriptor routeru (descriptor; souhrn informací o stavu routeru obsahující klíče, adresu, výstupní politiku apod.) a u adresářových serverů také adresáře. Onion klíčem se dešifrují požadavky od uživatelů pro ustanovení okruhu a s jeho pomocí se ustanovují dočasné klíče. Protokol TLS také ustanový krátkodobý klíč spojení (link key) pro komunikaci mezi onion routery. Krátkodobé klíče jsou nezávisle a pravidelně měněny, aby se zamezilo jejich kompromi- taci. Uživatelské onion proxy si zvolí routery pro okruh a postupným ustanovováním klíčů symetrického šifrování se všemy routery v okruhu jej vytvoří. Po vytvoření okruhu je možné posílat data. Jako výstupní uzel může být zvolen i jiný než poslední router v okruhu, a to kvůli výstupním politikám nebo pro zachování nespojitelnosti. 2.3 Adresář Tor pomocí malé skupiny onion routerů sleduje stav uzlů a změny topologie sítě, včetně klíčů a výstupních politik. Každý takovýto adresářový server funguje jako HTTP server, ze kterého mohou klienti získávat seznam routerů a informace o síti. Onion routery pravidelně odesílají podepsané deskriptory všem adresářovým serverům. Adresářové servery kombinují tyto informace s vlastním pohledem na sít'a generují podepsaný popis stavu celé sítě, tzv. adresář (directory). Klientský software je přednahrán se seznamem adresářových serverů a jejich klíčů. Každý adresářový server také pravidelně vytváří podepsaný kompaktní dokument zvaný network-status, který obsahuje informace serveru z jednotlivých deskriptorů a stavů známých routerů, ale neobsahuje deskriptory samotné. 2.3.1 Distribuce adresáře Deskriptory by měli být znovu vygenerovány pokud uplyne určitá doba od posledního generování (standardně 18 hodin), změní se vlastnosti routeru (kromě šířky pásma a času běhu), změní se šířka pásma od posledního generování o více než 50% a od této změny uplynul určitý časový interval (standardně 20 minut) nebo pokud byl čas běhu vynulován (restartem). Po vytvoření deskriptoru jej router odešle všem adresářovým autoritám, které zná, na URL http:///tor/. Routery mohou fungovat jako adresářová zrcadla (také se nazývají cache), aby snížily zá- těž adresářových autorit. Toto oznamují ve svém deskriptoru. Adresářová zrcadla stahují a uchovávají dokumenty network-status a dále je zprostředkovávají klientům. Klienti, adresářová zrcadla a autority zjišt'ují pomocí dokumentů network-status, zda není jejich seznam routerů zastaralý. Pokud ano, stáhnou si chybějící deskriptory routerů. Klienti získávají deskriptory od zrcadel, zrcadla a autority od autorit. Deskriptory jsou stahovány podle jejich hashe (ne podle identifikačního klíče serveru). Tím se předchází útokům klientů na servery dodáním deskriptoru, který nikdo jiný nepoužívá. 3 2. TOR Koordinace mezi adresářovými autoritami je prováděna na straně klienta, který se rozhodne pomocí hlasovacího algoritmu na základě dokumentů o stavu sítě. 2.3.2 Struktura adresáře Adresář onion routerů je uveden vlastní hlavičkou, za kterou následují deskriptory jed- notlivých routerů. Deskriptory routerů a adresáře jsou v následujícím lehko rozšířitelném formátu. Formální popis převzatý z dokumentu [4]: Document ::= ( Item | NL )+ Item ::= KeywordLine Object* KeywordLine ::= Keyword NL | Keyword WS ArgumentsChar+ NL Keyword = KeywordChar+ KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-' ArgumentChar ::= any printing ASCII character except NL. WS = (SP | TAB)+ Object ::= BeginLine Base-64-encoded-data EndLine BeginLine ::= "-----BEGIN " Keyword "-----" NL EndLine ::= "-----END " Keyword "-----" NL Počáteční a koncová řádka objektu (BeginLine a EndLine) musí obsahovat stejné klíčové slovo. Až do verze Tor 0.1.2.5-alpha se pro nekritické rozšiřující funkce používalo klíčové slovo opt. Deskriptor routeru začíná položkou router a končí položkou router-signature, po které následuje ještě jeden znak nového řádku, a obsahuje právě jeden výskyt následujících položek: published, onion-key, router-signature, signing-key a bandwidth. Dále může obsa- hovat nejvýše jeden výskyt následujících položek: contact, uptime, fingerprint, hibernating, read-history, write-history, eventdns, platform a family a také více výskytů položek accept, reject a opt. Položky jsou v následujícím formátu: router nickname address ORPort SocksPort DirPort Označuje začátek deskriptoru routeru. bandwidth bandwidth-avg bandwidth-burst bandwidth-observed Odhadovaná šířka pásma routeru (v bytech/s). platform string Pro člověka srozumitelný řetězec popisující systém, na kterém router běží. published YYYY-MM-DD HH:MM:SS Čas (GMT), kdy byl deskriptor vytvořen. 4 2. TOR fingerprint Hash identifikačního klíče routeru. hibernating 0|1 Pokud je router ve stavu hybernace, hodnota je 1 a router nemůže být použit pro stavbu okruhů. uptime Doba (v sekundách) běhu procesu routeru. onion-key NL a public key in PEM format signing-key NL a public key in PEM format Dlouhodobý identifikační klíč onion routeru. accept exitpattern reject exitpattern Tyto řádky popisují výstupní politiku routeru. router-signature NL Signature NL Hash deskriptoru routeru. contact info NL Kontakt na administrátora routeru. family names NL names obsahuje seznam routerů. Pokud se mají routery vzájemně v těchto sezna- mech, je s nimi z hlediska výběru cesty zacházeno jako s jedním. read-history YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,... NL write-history YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,... NL Obsahují využití šířky pásma (počet přečtených/zapsaných bytů) v intervalech po NSEC sekundách. Pole YYYY-MM-DD HH:MM:SS obsahuje čas konce posledního intervalu. Čísla jsou řazena od nejstaršího po nejnovější. eventdns bool NL Popisuje, zda roter používá novější DNS logiku. Neterminály v deskriptorech routerů (přejato z dokumentu [4]): nickname ::= between 1 and 19 alphanumeric characters, case-insensitive. hexdigest ::= a '$', followed by 20 hexadecimal characters. 5 2. TOR exitpattern ::= addrspec ":" portspec portspec ::= "*" | port | port "-" port port ::= an integer between 1 and 65535, inclusive. addrspec ::= "*" | ip4spec | ip6spec ipv4spec ::= ip4 | ip4 "/" num_ip4_bits | ip4 "/" ip4mask ip4 ::= an IPv4 address in dotted-quad format ip4mask ::= an IPv4 mask in dotted-quad format num_ip4_bits ::= an integer between 0 and 32 ip6spec ::= ip6 | ip6 "/" num_ip6_bits ip6 ::= an IPv6 address, surrounded by square brackets. num_ip6_bits ::= an integer between 0 and 128 bool ::= "0" | "1" Příklad deskriptoru: router tor26 86.59.21.38 443 0 80 platform Tor 0.2.0.0-alpha-dev on Linux i686 published 2007-05-02 04:38:41 opt fingerprint 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D uptime 31801 bandwidth 102400 10485760 1854403 opt extra-info-digest 14ABF7ABC5631F73F1F1D1B5116141C4432B3F1F onion-key -----BEGIN RSA PUBLIC KEY----- MIGJAoGBALrI5BZYe/wBWvzXDtZd+TGvsa3k0esdeRlBw/2/a1vwJXjdL1nNXzk/ xdkROElexohEo8HPGjDP9l08dKwisEmmbI+lXimx0R9FdyUJoTTuoJFVoDVpQBeD MinfQ8lwYYOvUff9h59c6sMQTRKdagj252OrBCaJfOuSatU79zv3AgMBAAE= -----END RSA PUBLIC KEY----- signing-key -----BEGIN RSA PUBLIC KEY----- MIGJAoGBAMQgV2gXLbXgesWgeAsj8P1Uvm/zibrFXqwDq27lLKNgWGYGX2ax3LyT 3nzI1Y5oLs4kPKTsMM5ft9aokwf417lKoCRlZc9ptfRbgxDx90c9GtWVmkrmDvCK ae59TMoXIiGfZiwWT6KKq5Zm9/Fu2Il3B2vHGkKJYKixmiBJRKp/AgMBAAE= -----END RSA PUBLIC KEY----- family $C556E87A59100DD095748AB3AF7EFDB04CECFE4C opt write-history 2007-05-02 04:30:30 (900 s) 971204608,1198451712, ... opt read-history 2007-05-02 04:30:30 (900 s) 668173312,890525696, ... contact Peter Palfrader (PGP Key: 0x94C09C7F; ... accept 18.244.0.188:9031 accept 18.244.0.114:80 accept 86.59.21.38:80 reject *:* router-signature -----BEGIN SIGNATURE----- OWKTbAn5G03mEQVSsK5djXtB0fVG/yOJHzfPL6jL8jc37j6ADtyBuR/u4ygtdrYv dR0Mk3Kembnp7+DGLpqJPIil0DVSFV9S3T8uTyZ3NZnlaCHo+wEki2z6S4g+CIIo TLcY21HT4izrzodHhVDoVAkPWwOpM9B7ocmyHcbxdZU= -----END SIGNATURE----- 6 2. TOR Dokument network-status obsahuje pro každý router tři položky. První je uvozena písmenem ,,r" a následují za ní základní informace o routeru (název, hash identifikačního klíče, IP adresa, atp.). Druhá položka je uvedena písmenem ,,s" a obsahuje bílými znaky oddělené charakteristiky routeru v libovolném pořadí: Authority ­ router je adresářová autorita BadExit ­ router se zdá nevhodný jako výstupní uzel BadDirectory ­ router se zdá nevhodný jako adresářové zrcadlo Exit ­ router je vhodný jako výstupní uzel okruhů pro obecné účely Fast ­ router je vhodný pro vysokokapacitní okruhy Guard ­ router je vhodný jako vstupní uzel Named ­ přiřazení identity a názvu routeru je kanonické Stable ­ router je vhodný pro dlouhodobější okruhy Running ­ router je momentálně použitelný Valid ­ router byl ,,validován" V2Dir ­ router implementuje adresářový protokol verze 2 Poslední položka (nepovinná) je uvedena písmenem ,,v" a popisuje verzi protokolu, který router používá. Příklad záznamu z dokumentu network-status: r moria1 /8tG2xM52oRnTHDXy1hkNMQ3BEE +3b1Z5seSM5zQ3GWy7RAO3qjL7k 2007-05-01 21:55:05 18.244.0.188 9001 9031 s Authority Fast Named Running Valid V2Dir opt v Tor 0.2.0.0-alpha-dev 7 Kapitola 3 Geolokace na internetu Informace o geografické poloze jsou v dnešním světě internetu pro některé služby ne- zbytné. Mezi aplikace, které využívají těchto informací, mohou patřit různé navigační služby, lokalizace při přístupu na webové stránky, správa zařízení v terénu, přehled o umístění routerů či serverů na mapě, služby pro stav nouze (první pomoc) a další. Geolokaci můžeme rozdělit na chtěnou a nechtěnou. Uživatelé mohou chtít být v ur- čitých případech přesně lokalizováni, jindy naopak upřednostňují své soukromí. Tímto tématem se zabývá pracovní skupina Geopriv (Geographic Location/Privacy) asociace IETF. Informaceo této skupině společně se seznamem RFC můžeme nalézt na [5]. 3.1 Standardy Asociace IETF (Internet Engineering Task Force) již několik návrhů RFC pro zprostředko- vání geolokačních zdrojů a infrastruktury vytvořila. Například RFC 1876 definuje experi- mentální mechanismus, který pro systém DNS umožňuje přenos informací o geografické poloze. DNS (Domain Name System) je herarchický systém doménových jmen, jehož účelem je převod doménových jmen a IP adres. Realizován je pomocí serverů DNS, které si vyměňují informace protokolem DNS. Příklad získání informace o geografickém umístění z DNS: $ host -t LOC caida.org caida.org location 32 53 1.000 N 117 14 25.000 W 107.00m 30m 10m 10m Nebo RFC 3825 specifikuje variantu protokolu DHCP pro geografickou lokalizaci klienta zprostředkovanou serverem. DHCP (Dynamic Host Configuration Protocol) je aplikační protokol pro automatické přidělování IP adres koncovým stanicím v síti. Protože zatím nebyl příliš velký zájem o zprostředkování určení polohy uživatele nebo o automatickou lokalizaci služeb, jsou tyto návrhy podporovány pouze málo. Například dále zmíněný systém NetGeo nepoužíval dotazy na DNS, kvůli jejich mizivé účinnosti. Některé společnosti dnes nabízejí určení polohy podle IP adresy jako placenou službu. 3.2 Zdroje dat a postupy Pro určení geografické polohy počítače v internetu můžeme mít k dispozici informace, jako jsou IP adresa, nastavený jazyk, obsah webových stránek, časová zóna, metadata v obrázcích a další. Základní metody geolokace vycházejí z IP adresy (počítač nemusí být využíván pro navštěvování webových stránek a nemusí ne něm běžet žádné služby). 8 3. GEOLOKACE NA INTERNETU Existuje několik zdrojů, ze kterých lze čerpat údaje o IP adrese. Nejvíce informací obvykle obsahují databáze WHOIS, další informace mohou být získány z DNS systému, z překladů doménových jmen nebo metodou sledování (geografické) cesty paketů doru- čovaných na dotazovanou adresu. Protokol WHOIS1 se užívaná k zaslání dotazu/odpovědi na/z databáze pro určení vlastníka IP adresy, doménového jména nebo čísla autonomního systému v Internetu. Databáze jsou na tzv. serverech WHOIS a mohou obsahovat bud' všechny informace o určité podmnožině záznamů2 (například o doméně .org) nebo informace, na kterém serveru WHOIS jsou data uložena3 (například servery WHOIS pro doménu .com). V databázích WHOIS jsou uloženy pouze údaje pro větší bloky IP adres, které bývají přiřazeny větším společnostem a organizacím. Na základě těchto informací se dá určit geografická poloha konkrétní IP adresy pouze zhruba. Například telefonní operátor po- skytující připojení k Internetu má sídlo v jednom městě, ale připojení poskytuje po většině území státu. Pro účely geolokace by bylo dobré, kdyby se silně podpořil protokol RWhois4 (Referral Whois), jehož ideou je zozšířit koncept WHOIS do hierarchické podoby podobné systému DNS. Servery RWhois by běžely i u menších poskytovatelů internetu a celkově by se dosáhlo podrobnějšího přehledu o přiřazení IP adres a tedy i případné možnosti přesnější geolokace. Z databází WHOIS lze získat pouze textový popis polohy, ideálně stát a město držitele adresového rozsahu, který je však pro snazší zobrazení v mapě potřeba převést na geo- grafické souřadnice. Ty můžeme získat z vhodné databáze. Na internetu jsou k dispozici například Google Maps a podobné mapové nástroje dalších firem, geografická databáze Geonames nebo databáze z NGA GEOnet Names Server (GNS). 3.3 Projekty Před několika lety vytvořila CAIDA (Cooperative Association for Internet Data Analysis) systém geolokace zvaný NetGeo. Jde o veřejně dostupnou databázi IP adres s přiřazenou geografickou polohou. Přestože byl projekt zastaven a licencován novým partnerům, zastarávající databáze je stále k dispozici a pro hrubou lokalizaci je použitelná. ,,Nástupcem" této databáze by mohl být projekt hostip.info. Projekt je postaven přede- vším na dobrovolnictví návštěvníků, kteří zadají své umístění (stát a město). Tím své IP adrese přiřadí geografickou polohu pro databázi. 3.4 Služby a produkty Na internetu lze nalézt mnoho firem nabízejících produkty a služby pro nalezení geo- grafické polohy podle IP adresy. Většinou se jedná o produkty ve formě programu nebo modulu či rozhraní pro různé programovací jazyky. Následující přehled popisuje některé z nich. Uváděné přesnosti jsou převzaty z informací o produktech. 1. RFC 3912 2. thick model 3. thin model 4. RFC 2167 9 3. GEOLOKACE NA INTERNETU http://www.ip2location.com/ ­ komerční souborová databáze, k dispozici je demo obsa- hující blok adres od 0.0.0.0 do 99.255.255.255 http://www.maxmind.com/ ­ databáze ve formě souboru nebo formátu CSV, ve dvou variantách: ˇ neplacená GeoLite City ­ přesnost: 98% stát, 60% město, aktualizována měsíčně ˇ komerční GeoIP ­ přesnost: 99% stát, 80% město, aktualizována týdně http://www.digital-element.net/ ­ komerční produkt, přesnost: 99% země, 94% město http://software77.net/cgi-bin/ip-country/geo-ip.pl ­ online dotazy, pouze země http://www.geobytes.com/ ­ komerční produkty http://www.quova.com/ ­ komerční produkty http://www.ip2country.net/ ­ komerční produkty http://www.visualroute.com/ ­ komerční produkty http://www.cyscape.com/products/chawk/ ­ komerční produkt http://www.netgeo.com/ ­ komerční produkt, přesnost: 99% země http://www.activetarget.com/ ­ komerční produkt, přesnost: 97% země http://www.tamos.com/products/ip-location-database/ ­komerčnídatabázový produkt, přesnost: 98% země http://sourceforge.net/projects/javainetlocator/ ­ zdarma, pouze země 10 Kapitola 4 Webové mapy Webové mapy zprostředkovávají mapy (a další geografická data) skrze webové stránky. Obecně lze webové mapy rozdělit do dvou hlavních skupin: mapy statické a mapy dy- namické. Tyto skupiny pak můžeme dále rozdělit na mapy interaktivní a mapy určené pouze k prohlížení. Dynamické mapy, narozdíl od statických, používají tzv. dynamický zoom ­ zvětšení/zmenšení mapového výřezu dynamicky mění obsah mapy. Interaktivní mapou se rozumí mapa obsahující interaktivní prvky nebo mapa poskytující možnost zís- kání dalších informací o prvcích mapy v aktuálním výřezu. Vzhledem k našim potřebám nás budou zajímat mapy dynamické ­ interaktivní. Takové mapy zpravidla zprostředkovávají funkce jako je zoom, neomezený pohyb po mapě, vyhledávání států, měst, míst, firem apod. Mezi nejznámější světové webové mapy patří například Google Maps, Yahoo Maps, Microsoft Windows Live Local, Mapquest a Ask Maps. Z českých webových map jsou to například Amapy.cz nebo Mapy.cz. Některé webové mapy nabízejí programové rozhraní (API) umožňující začlenit mapu do vlastníwebové stránky. API zpravidla umožňuje přidánía úpravu různých komponent mapy, například zoomu, bodů, čar, popisků, ikon apod. Protože české webové mapy pokrývají pouze území ČR (popř. Evropy), nejsou pro nás příliš zajímavé. Zajímavé API nabízejí Google Maps [6], Yahoo Maps [7], Microsoft Windows Live Local [8] a Mapquest [9]. Všechna uvedená API jsou bezplatná a použitelná pro nekomerční účely. Všechna jsou omezena na 50 000 požadavků denně (kromě Microsoft Windows Live Local umožňující 100 000 požadavků denně). Pro naši aplikaci potřebujeme perspektivní rozhraní s dobrou podporou a dokumen- tací, které je schopné zobrazovat/spravovat stovky bodů. Pro toto kritérium se nejvíce hodí Google Maps a Yahoo Maps. Virtual Earth Map Control (Microsoft Windows Live Local) nabízí zajímavé funkce, například pohledy ,,bird's eye", ale celkově zaostává za ostatními. Mapquest se zaměřuje především na vyhledávání různých druhů cest, uži- vatelské rozhraní není tak propracované jako u ostatních a nenabízí satelní snímky jako mapový podklad. Yahoo Maps nabízí velmi propracované API v různých verzích (AJAX, Flash, Flex). Pro vlastní práci s mnoha body však žádnou třídu neobsahuje a pro získávání dat ze souborů XML je omezeno na formát GeoRSS, který ovšem dokáže zpracovat. Google Maps API nabízí pro práci s mnoha body třídu GMarkerManager a umožňuje získat data z libovolného souboru XML. Zpracování techto dat je však necháno na uživateli. Naše aplikace by mohla využívat libovolné z těchto rozhraní, ale protože se našim požadavkům nejvíce přibližuje Google Maps API, bylo vybráno právě ono. 11 4. WEBOVÉ MAPY 4.1 Google Maps Google Maps je webová aplikace a technologie vytvořená firmou Google. Umožňuje inter- aktivní prohlížení mapy světa v různých úrovních přiblížení. Lze pomocí ní vyhledávat státy, města, místa, firmy apod. Nabízí tři druhy zobrazení (mapových podladů): Map (mapa ulic a silnic), Satellite (mapa ze satelitních a leteckých snímků) a Hybrid (mapa ulic a silnic zobrazená na podkladové mapě ze satelitních snímků). Aplikace je implementována technologií AJAX (JavaScript a XML, asynchronní dotazy na server). Při průchodu mapou jsou ze serveru stahovány čtvercové části mapy, které se pak zobrazují uživateli. 4.1.1 Google Maps API Google Maps API je javascriptové objektově orientované rozhraní, pomocí kterého lze začlenit Google Maps do vlastní webové stránky. Použití API je bezplatné, ale vyžaduje registraci, při které je vygenerován přístupový klíč vázaný na URL (stačí doména). Pro vlastní použití pak stačí importovat jediný javascriptový soubor obsahující všechny po- třebné symboly. Nejaktuálnější stabilní verze je nyní verze 2 z dubna 2006. API je neustále vyvíjeno a komunita kolem je také činná (viz 4.1.2). V následujícím příkladu je ukázáno, jak integrovat mapu do webové stránky. Příklad také ukazuje některé nejdůležitější funkce Google Maps API. Jak je vidět, pro použití stačí vložit soubor obsahující API. Globální metoda GBrowserIsCompatible kontroluje, zda je rozhraní použitelné s prohlížečem. Třída GMap2 představuje samotnou mapu, do které se metodou addControl přidány komponenty ovládání zoomu a mapového podkladu. Metoda setCenter nastaví polohu a přiblížení mapového výřezu. Ve funkci createMarker vytvoříme z třídy GMarker nový bod a metodou GEvent.addListener registrujeme ob- sluhu události. Klepnutím na vytvořený bod se otevře okno s textem difinované třídou openInfoWindowHtml. Metodou addOverlay umístíme bod do mapy. Příklad
Tento příklad by zobazil stránku obsahující mapu, která by po klepnutí na umístěný bod vypadala jako na obrázku 4.1. Obrázek 4.1: Výsledek příkladu použití API Bod bychom mohli vytvořit také s jinou ikonou (vytvořenou z třídy GIcon) a umístit jej pomocí správce budů (třída GMarkerManager), který umožňuje spravovat mnoho bodů pro různé úravně přiblížení. Důležitá je také funkce GDownloadUrl, pomocí které je možné stáhnout soubor obsahující data pro body, čáry apod. 4.1.2 Projekt gmaps-utility-library Tento open source projekt má být centrálním úložištěm užitečných knihoven pro Google Maps API. Momentálně jsou dostupné pouze knihovny MarkerManager, LabeledMarker a vývojářská verze knihovny GZoom [10]. 13 4. WEBOVÉ MAPY Třída knihovny MarkerManager nahrazuje třídu GMarkerManager ze standardního Google Maps API a implementuje některé funkce, které ve třídě GMarkerManager výrazně chybí (především odstraňování bodů). Třída LabeledMarker rozšiřuje třídu GMarker ze standardního API a umožňuje vytvářet body s textovými popisky. Knihovna GZoom umožní přiblížení oblasti vytvořením výběrového obdélníku myší. 14 Kapitola 5 TorMap Výsledkem této práce je interaktivní webová aplikace s názvem TorMap zobrazující onion routery sítě Tor v mapě světa. Základem aplikace je skript v programovacím jazyce Perl, který získává, zpracovává a ukládá informace o onion routerech. Jeho výstupem je dokument XML obsahující data pro webovou stránku. Další součástí je perlový modul s pracovním názvem googleIP. Zatím pracuje jako sekundární zdroj pro získání geografické polohy z IP adresy. Grafy provozu na jednotlivých routerech a grafy celkových statistik jsou také generovány perlovými skripty. Uživatelské rozhraní je tvořeno webovou stránkou (obrázek 5.1) s interaktivní mapou zprostředkovanou Google Maps API. Na stránce je dále fitrovatelná tabulka onion routerů sítě Tor. Filtry použité na tabulku se dají aplikovat i na mapu. Ve spodní části stránky jsou umístěny grafy zobrazující počet běžících routerů a provoz v síti Tor. Celý běh stránky je zajištěn JavaScriptem. Obrázek 5.1: Uživatelské rozhraní 15 5. TORMAP Uživatelské rozhraní aplikace TorMap by mělo být dostupné na webové adrese http://www.fi.muni.cz/~xkotek1/tormap/map/. 5.1 Získání dat Pro vytvoření aplikace bylo potřeba zjistit dostupné zdroje informací o onion routerech sítě Tor. Nejdůvěryhodnějším a zároveň nejsnáze dostupným a zpracovatelným zdrojem jsou adresářové servery sítě Tor. Nyní máme k dispozici tři adresáře: ˇ http://tor.noreply.org/tor/ ˇ http://moria.mit.edu:9031/tor/ ˇ http://belegost.mit.edu/tor/ Dokumenty network-status všech známých adresářových autorit by měli být dotupné na těchto serverech pod adresami http:///tor/status/all. Jak je vidět z příkladu deskriptoru (viz 2.3.2), nejvíce informací o geografickém umís- tění onion routeru můžeme získat z IP adresy (viz 3.2). Stačí tedy projít adresář a k IP adrese každého routeru nalézt odpovídající geografickou polohu. Pro toto hledání je možné využít databázi NetGeo (viz 3.3), která by poskytla alespoň hrubou představu o rozmístění routerů v mapě světa. Databáze však bude čím dál tím více zastaralá ­ pro dlouhodobější projekt tedy nepoužitelná. Další možností je využití některého z běžících projektů nebo zdarma poskytovaných služeb. V úvahu přichází projekt hostip.info a databáze GeoLite City od firmy MaxMind. Kromě toho, že poskytují vcelku kvalitní výstup, se dá také očekávat, že budou ještě nějaký čas dostupné. Také je možné vyvinout vlastní aplikaci, která bude geolokaci provádět. Placené komerční produkty nepřicházejí pro naši aplikaci v úvahu. Protože se vývoj modulu googleIP ukázal z časového hlediska neperspektivní (vývoj zabere ještě mnoho času), bylo nutné vybrat nějakou vhodnou databázi nebo službu, která by sloužila jako hlavní zdroj pro geolokaci. Vybrána byla databáze GeoLite City, protože se z dostupné nabídky zdá nejpřesnější, nejsnáze dostupná, dobře podporovaná a doku- mentovaná a časově dále perspektivní. Uváděná přesnost je 98% pro stát a 60% pro město v USA (v okruhu 25 mil). Ú daje o přesnosti pro ostatní státy lze naléz na [11]. Databáze je dostupná v binárním formátu nebo ve formátu CSV, který umožňuje její import do SQL databáze. Databáze v binárním formátu [12] je optimalizována pro vyhledávání pomocí open source API, které je dostupné pro nejpoužívanější programovací jazyky. Ze skriptu je k ní přistupováno pomocí modulu Geo::IP. Adresy, které se nepodařilo lokalizovat touto databází, jsou pak hledány modulem googleIP. Z adresáře onion routerů a dokumentů network-status sítě Tor jsou pro každý router vyextrahovány informace o onion routerech, které jsou pak spolu s informacemi o jejich geografické poloze uloženy do dokumentu XML. Data jsou do dokumentu uložena tak, aby se dala velmi snadno zpracovávat JavaScriptem, zůstala čitelná a zároveň nezabírala příliš místa1. 1. týká se to názvů atributů a atributu obsahujícího stav routeru 16 5. TORMAP 5.2 Modul googleIP V rámci této práce byla snaha vyvinout vlastní modul (pro Perl) zajišt'ující geolokaci. Protože se toto ukázalo jako dlouhá a strastiplná cesta, zůstává modul zatím ve fázi vývoje a je využíván pouze pro hledání záznamů nenalezených pomocí hlavního zdroje (databáze GeoLite City). Modul pro zadanou IP adresu vyhledá její záznam v databázi WHOIS. Ve většině získaných záznamů se vyskytuje řádek uvedený položkou ,,country:", za kterou následuje dvoupísmenný kód země ve formátu ISO 3166. Některé záznamy mívají také řádky uvedené položkami ,,City:" a ,,StateProv:". Záznamy z některých států nemají řádek uvedený položkou ,,Country:", ale vyskytujíse v nich specifické vzorky, například Brazílie (vzorek: ,,% Copyright (c) Nic.br"). Touto metodou lze vcelku dobře nalézt přibližné umístění (většinou ,,amerických") IP adres obsahující položky ,,City:" a ,,StateProv:" a určit stát pro většinu ostatních. Dále se v mnoha záznamech vyskytují řádky uvedené položkou ,,address:". Z těchto řádků se ve většině případů dá vyextrahovat použitelná adresa a tedy i přibližná ge- ografická poloha IP adresy. Modul upraví informace získané z řádek uvedených touto položkou a z vhodné kombinace slov se pokouší získat adresu (především město), ke které přidá název země (získaný například z dvoupísmenného kódu). Každý pokus zašle přes protokol HTTP jako dotaz na Google Maps, aby pro danou adresu získal geogra- fické souřadnice. Podle odpovědi pak zkouší jiné kombinace nebo přijme geografické souřadnice. Odpověd' je vyžádána ve formátu csv a obsahuje popořadě návratový kód, přesnost, zeměpisnou délku a zeměpisnou šířku oddělené čárkami. V případě správného návrato- vého kódu (200) a vyhovující přesnosti (4 a výše) jsou souřadnice přijaty. Příklad adresy získané z IP adresy 85.178.94.115: HanseNet Telekommunikation GmbH Ueberseering 33 A D-22297 Hamburg Germany Příklad upravené adresy: HanseNet Telekommunikation GmbH Ueberseering Hamburg Germany Příklad odeslaného dotazu: http://maps.google.com/maps/geo?q=Hamburg,+Germany&output=csv&key= ABQIAAAAu1_-T0PvR325-pPtZomxeRRjhB4hd7FExw3mRqUYzQ4UGpTNqhQfuo l9nNZHnDwUU2lQOpzlC_pZcQ 17 5. TORMAP Příklad odpovědi: 200,4,53.549839,9.973259 Příklad dat navrácených modulem: Hamburg DE 53.549839 9.973259 Při zkoumání výsledků z hledání IP adres onion routerů (kolem 1200 adres) byla úspěšnost této metody zhruba 60%, přičemž ne všechny záznamy byly určeny správně (existovala lepší varianta adresy). Stát byl určen zhruba v 95% případů. V případě existence položky ,,City:" se adresa již dále nehledá a odešle se dotaz využívající této položky. Pokud je neúspšný, přidá se do dotazu položka ,,StateProv:". U dotazů tohoto typu nebyl zatím pozorován neúspěch ­ pomocí prvního dotazu je nalezeno zhruba 75%, zbytek pomocí druhého. Pokud by měl být tento modul používán jako hlavní zdroj pro geolokaci, bylo by třeba upravit způsob jejího používání. Protože je metoda, kterou používá, poměrně náročná na počet dotazů zaslaných na Google Maps, bylo by vhodné implementovat jakousi cache, ze které by se již nalezeným IP adresám přiřazovala geografická poloha. Další možností by bylo vytvořit si vlastní databázi pro geolokaci. Modul není používán jako hlavní metoda, kvůli nekorektnosti některých výsledků a neobjasnění nekonzistentního chování odpovědí na dotazy ­ některé dotazy jsou přes webové rozhraní Google Maps nalezeny, avšak pomocí dotazu přes HTTP ne (a naopak). Další vývoj se bude ubírat také k používání jiných databází, například Geonames (viz 3.2). Vývoj jeho metod si vyžádá ještě poměrně dost času. 5.3 Grafy První skript generuje grafy provozu pro jednotlivé onion routery a graf sledující počet běžících routerů a jeho podmnožiny s různými charakteristikami (viz 2.3.2). Druhý skript generuje graf celkového provozu. 5.3.1 Počet běžících routerů Z počtu běžících routerů je sledován počet uzlů s charakteristikami Fast, Exit, Stable a Guard, dále teké počet uzlů umožňující výstup na port 80 a počet těchto uzlů s charak- teristikou Fast. Pro soubor rrd obsahující tato data byl zvolen krok 8 hodin, což by mělo pro přehlednost stačit (obrázek 5.2). 5.3.2 Provoz na routeru Skript nejprve z adresáře získá pro každý router data položek read-history a write-history, která pomocí nástroje RRDtool uloží do souborů rrd. Současně s tím počítá běžící routery 18 5. TORMAP Obrázek 5.2: Počet běžících routerů a ověřuje jejich charakteristiky. Protože se může čas konce posledního intervalu lišit a intervaly mohou být různě veliké 2, jsou soubory rrd pro záznam objemu zápisovaných a čtených dat vytvářeny zvlášt'. Pro tyto soubory byl zvolen krok 900 sekund (čtvrt hodiny), protože je to standardníhodnota délky intervalu vyskytujícíse v adresáři u těchto položek. Data z obou souborů pro každý router jsou pak vynesena do společného grafu (obrázek 5.3). Obrázek 5.3: Provoz na konkrétním routeru 5.3.3 Provoz v síti Druhý skript získává ze souborů rrd jednotlivých routerů hodnoty za určité časové ob- dobí. Začátek období byl zvolen dva dny zpět a konec období jeden den zpět. To by mělo zajišt'ovat, že všechny potřebné soubory budou již pro získávané období aktuální a generovaný graf je zároveň co nejaktuálnější. Data (přečtené/zapsané byty) z tohoto období jsou po jednotlivých krocích sečtena a uložena do souboru rrd. Pro tento soubor byl také zvolen krok 900. Následně je vygenerován graf (obrázek 5.4). 2. jediná pozorovaná hodnota je však zatím 900 sekund 19 5. TORMAP Obrázek 5.4: Provoz na síti 5.4 Webová stránka Webová stránka slouží jako uživatelské rozhraní celé aplikace. V horní části je interaktivní mapa zobrazující onion routery v mapě světa. Vpravo od mapy jsou dva obdélníky ­ horní zobrazuje informace o aktuálních datech, dolní obdélník pak obsahuje seznam všech onion routerů získaných z dokumentu XML. Pod mapou se nacházítabulka onion routerů, kterou je možné filtrovat pomocí filtrů v jejím záhlaví. Filtry umožňují tři nastavení: YES (routery s danou vlastností se budou zobrazovat), NO (routery s danou vlastností se nebudou zobrazovat) a ONLY (zobrazí se pouze routery s danou vlastností). Tyto filtry je možné aplikovat na mapu3. Pod tabulkou jsou umístěny dva grafy zobrazující statistiky počtu běžících routerů a celkového provozu na routerech. Tělo stránky je tvořeno hierarchií tagů div, do kterých je pomocí JavaScriptu vkládán jejich obsah. Jednotlivé tagy jsou umístěny pomocí kaskádových stylů (CSS). Ke stránce jsou připojeny tři soubory js. První vkládá symboly pro Google Maps API, druhý obsahuje třídu MarkerManager (viz 4.1.2), třetí pak vytváří funkcionalitu celé stránky. 5.4.1 JavaScript Při načítání těla webové stránky je volána funkce load, která pomocí Google Maps API zkontroluje kompatibilitu prohlížeče, vytvoří mapu a další potřebné objekty a začne stahovat dokument XML vytvořený perlovým skriptem. Na stažená data je aplikována funkce readData, která obsah dokumentu zpracuje a informace o routerech ve formě objektů uloží do pole. Routery jsou pak z tohoto pole zobrazeny přes filtry do mapy a do tabulky. Protože neobsahuje třída GMarkerManager žádné fukce pro odebrání bodů, bylo nutné hledat, jak jinak vyřešit filtrování routerů pro mapu. Naštěstí existuje projekt 3. neděje se tak automaticky kvůli rychlosti zpracování 20 5. TORMAP gmaps-utility-library (viz 4.1.2), který obsahuje knihovnu s třídou MarkerManager. Tato třída již požadované metody implementuje. Jak se v komentáři v souboru [13] píše, umožňuje tato třída spravovat deset tisíc bodů rozprostřených ve velké oblasti, jestliže jich v náhledovém výřezu zůstává viditelných maximálně 100 až 200. Pokud se jich zob- razuje více, lze očekávat delší dobu výpočtu. Proto je aplikace při zobrazování celé mapy světa pomalá. Pro lepší výkon by bylo vhodné implementovat funkci, která by na menších úrovních přiblížení (zobrazení celé mapy světa) body nějakým způsobem sdružovala. Vhodné by mohlo být využití bodů různých velikostí podle počtu seskupených routerů a ty seskupovat podle země, v níž leží. Také je možné využít bodů s textovými popisky obsahujícími počet seskupených routerů. 21 Kapitola 6 Závěr Z této práce tedy vzešla webová aplikace TorMap, která správcům a uživatelům ano- nymizační sítě Tor poskytuje celkový přehled o síti i jednotlivých routerech. Zahrnuje v sobě interaktivní mapu světa, tabulku onion routerů a grafy zobrazující statistiky sítě i jednotlivých uzlů. Tabulku i mapu lze podle charakteristik routerů filtrovat. Vznikl také základ modulu googleIP, který lze použít pro získání hrubého odhadu geografické polohy IP adresy. Tor neustále roste a vyvíjí se ­ těsně před dokončením tohoto textu již vyšla třetí verze dokumentu [4] popisující nové postupy práce s dokumenty v síti Tor. Počet běžících onion routerů začíná přesahovat jeden tisíc a další růst bude mít určitě dopad na rychlost práce našeho projektu. Stejně jako se vyvíjí Tor, bude potřeba vyvíjet a přizpůsobovat projekt TorMap, aby zůstal pro administrátory a uživatele Toru užitečným. Tato práce je dobrým příkladem toho, že často nestačí aplikaci pouze vytvořit, ale že je potřeba ji nějakým způsobem i dále spravovat. Protože jsem se setkal se všemi použitými technologiemi ve své praxi poprvé, mnoho jsem se toho naučil a věřím, že další prací na tomto projektu se toho naučím ještě více. 22 Literatura [1] Tor: Volunteer. URL: http://tor.eff.org/volunteer.html.en, květen 2007. [2] Mgr. Vlastimil Holer. Practical Onion Routing. http://www.fi.muni.cz/ ~xholer/content/school/tor/poster.pdf, květen 2006. [3] T. Dierks a C. Allen. The TLS Protocol ­ Version 1.0. RFC 2246 (URL: http:// www.ietf.org/rfc/rfc2246.txt), leden 1999. [4] Nick Mathewson. Tor directory protocol, version 2. URL: http://tor.eff.org/ svn/trunk/doc/spec/dir-spec-v2.txt, březen 2007. [5] Geographic Location/Privacy (geopriv) Charter. URL: http://www.ietf.org/ html.charters/geopriv-charter.html, duben 2007. [6] Google Maps API Documentation. URL: http://www.google.com/apis/ maps/documentation/, 2007. [7] Yahoo! Maps Web Services ­ The Yahoo! Maps Developer APIs. URL: http:// developer.yahoo.com/maps/, 2007. [8] Virtual Earth Map Control SDK. URL: http://msdn2.microsoft.com/en-us/ library/bb429619.aspx, 2007. [9] Mapquest: Features. URL: http://www.mapquest.com/features/main.adp? page=developer_tools_oapi_quickstart, 2007. [10] pammyla.fox. gmaps-utility-library-dev ­ Google Code. URL: http:// code.google.com/p/gmaps-utility-library-dev/wiki/Libraries, du- ben 2007. [11] MaxMind ­ GeoIP City Accuracy for Selected Countries. URL: http:// www.maxmind.com/app/city_accuracy, březen 2007. [12] MaxMind ­ GeoIP City Geolocation IP Address to City. URL: http:// www.maxmind.com/app/city, květen 2007. [13] Doug Ricket. markermanager.js. URL: http://gmaps-utility-library. googlecode.com/svn/trunk/markermanager/release/src/ markermanager.js, 2007. [14] Andrew Turner. Geolocation by IP Address. URL: http://linuxjournal.com/ article/7856, říjen 2004. 23 Příloha A Obsah přiloženého CD Přiložené CD obsahuje: ˇ text této práce ve formátu PDF a TEX ˇ soubory se zdrojovými kódy implementace ˇ licenci obsahující podmínky šíření této implementace ˇ demo (vyžaduje připojení k Internetu) 24