Evropa je bez IPv4 adres!

Tak nakonec to ani netrvalo tak dlouho, jak jsem ještě nedávno předpovídal. RIPE NCC před pár minutami oznámil, že Evropa je v současnosti jako druhý region bez IPv4 adres. Od dnešního dne již žádný poskytovatel nedostane více než 1024 IPv4 adres, což je pochopitelně velmi nepříjemná situace. Velice zajímavé je, že velký podíl na alokacích v posledních dvou měsících mají íránské společnosti. Ty alokovaly 2,7 miliónu adres, což obvykle vystačilo celému evropskému regionu, který zahrnuje i Střední východ, na tři týdny. Ještě se k celé situaci vrátím v nějakém budoucím příspěvku, ale to hlavní je řečeno. Evropa je bez adres, doufejme, že to urychlí nástup IPv6.

Ondřej Filip

Dnes je ten slavný den, kdy k nám byl zaveden… mojeID

Právě v těchto dnech bylo zavedeno mojeID do systémů prvních knihoven. Na konferenci Knihovny současnosti 2012, která se koná tento týden v Pardubicích, představila Moravská zemská knihovna v Brně svoji implementaci služby mojeID a společnost KP SYS svůj katalog s podporou mojeID. V tuto chvíli to znamená, že kromě Moravské zemské knihovny v Brně mohou využívat mojeID také návštěvníci knihoven v Chebu a Liberci (knihovna Technické univerzity).

Společnost KP-SYS implementovala do svého systému mojeID společně s OpenID. Nasazení proběhlo nejdříve na testovacích firemních serverech a po důkladném otestování došlo na implementaci do ostré verze webového knihovního katalogu Portaro (technologie PHP). V současnosti implementují v KP-SYS mojeID do druhé generace katalogu Portaro (technologie JAVA) a rozšiřují funkcionalitu o další údaje přenášené do lokální databáze uživatelů. V plánu je dále představení tohoto řešení zástupcům knihoven na konferenci Bibliotheca Academica 2012 a samozřejmě koncovým uživatelům (podzimní Setkání uživatelů katalogu Portaro).

Moravská zemská knihovna v Brně integrovala mojeID mezi své služby počátkem minulého týdne. Úvahy o ostrém nasazení jsou už rok staré; první zmínky o mojeID se mezi knihovníky rozšířily právě před rokem na konferenci Knihovny současnosti, kde byl systém poprvé představen. Knihovna si od zavedení slibuje zejména zpříjemnění registrace do knihovny pro své čtenáře, ale zároveň propojení služeb pro již stávající uživatele. V současnosti je možné mojeID využít nejen při nové registraci do knihovny, ale také při prodlužování platnosti průkazu. V blízké budoucnosti mají v MZK v plánu umožnit plnohodnotnou registraci na dálku.

Pozadu ale nezůstávají ani ostatní producenti knihovních systémů. Intenzivně probíhají jednání o implementaci služby mojeID do systému Clavius (společnost LANius), kde je přislíbena implementace do konce roku 2012. Tento systém využívá přibližně 2 000 městských knihoven v Čechách, ale i na Slovensku. Zavedení mojeID řeší i ve společnosti Multidata Praha, která provozuje knihovnicko-informační systém ALEPH. Ten využívají především akademické knihovny, z nichž namátkou vybírám knihovnu Akademie věd České republiky, Národní technickou knihovnu nebo knihovnu Masarykovy univerzity v Brně. Oslovili jsme rovněž řadu dalších menších firem nebo společností zaměřených na open source řešení. Zde jsou jednání teprve v zárodku.

Radim Ponert

mojeID přivítalo jubilejního uživatele

S rostoucím počtem provozovatelů internetových služeb, kteří se rozhodli systém pro jednotné přihlašování mojeID implementovat, roste i počet jeho uživatelů. K dnešnímu dni jich sdružení CZ.NIC eviduje více než 70 tisíc. Podíl plně a částečně identifikovaných je přitom téměř vyrovnaný – 41 procent ku 59 procentům.

Podle statistik v uplynulém měsíci vzniklo zhruba 3 800 nových mojeID účtů, denní počet přihlášení pomocí mojeID se pohybuje okolo 1500. Mezi společnostmi, které službu pro své zákazníky aktuálně zavádí, jsou například Jízdomat.cz, Moravská zemská knihovna v Brně nebo Česká zemědělská univerzita v Praze (ČZU se tak stane první vzdělávací institucí podporující mojeID). A vývoj a podpora mojeID v CZ.NIC také nezahálí – mezi poslední novinky patří například přizpůsobení editoru mojeID profilu pro mobilní zařízení nebo nové moduly pro open source systémy.

Ondřej Písek

Tak už jen měsíc

Jsou to již tři měsíce od světového dne IPv6, kdy jsem naposledy na tomto blogu glosoval neradostnou situaci ubývání IPv4 adres. Oproti tehdejší prognóze došlo k mírnému posunu data vyčerpání IPv4 v Evropě, nicméně pořád platí, že toto datum je velice nepříjemně blízko. V současnosti se jeví jako pravděpodobné, že adresy by mohly dojít přibližně do měsíce. Ale dost předbíhání a pojďme se podívat, jak se v letním čase alokovalo. Za uplynulé tři měsíce bylo vydáno ze zásoby RIRů přes 28 miliónů adres a z toho téměř 14 z evropského RIPE NCC. Pořád tedy platí, že Evropané chtějí přibližně čtyři milióny adres měsíčně. Rozložení alokací dle regionů ilustruje následující graf.

IPv4 alokace dle RIR 06-08/2012

Vzhledem k tomu, že v Asii již IPv4 fakticky došlo, je APNIC jako již tradičně nejslabší. Pojďme se ale soustředit na Evropu a blízký východ, protože těm hrozí podobná situace v nejbližších dnech. Zde se stalo něco velmi překvapivého. Zemí, která přes léto žádala nevíce adres, je Írán. Íránci zažádali za červen až srpen o téměř 2,5 miliónu adres a jejich apetit pokračuje, protože na začátku září požádali o další milión. Je těžké spekulovat nad tím, co za touto aktivitou stojí, ale rozhodně to je velmi překvapivé, že Internet dosahuje takového rozmachu právě v této zemi. Na druhém místě skončili Rusové a za nimi Britové. Následující graf ukazuje podíly deseti nejaktivnějších států.

IPv4 alokace států EU regionu 06-08/2012

Každopádně RIPE NCC ohlásilo, že má už jen posledních 4 milióny adres krom posledního bloku, a že tedy brzy drasticky omezí jejich poskytování. Situace kolem IPv4 je tedy v celku neradostná, pojďme se podívat na IPv6. Za uplynulé tři měsíce požádalo o IPv6 prefix 474 LIRů, což zhruba odpovídá průměru posledních měsíců, jak je vidět na následujícím grafu.

IPv6 alokace

Nejvíce žádostí přišlo z USA (60), Velké Británie (33) a Německa (29). Češi si řekli o slušných 10 prefixů. A když už mluvím o Česku, měl bych ještě jednu potěšitelnou zprávu. V IPv6 statistikách za měsíc srpen jsme zaznamenali milník, který již nějakou dobu vyhlížíme. Podíl domén s IPv6 jmennými servery se přehoupl přes 50 % a díky tomu můžeme nyní prohlásit: „Každá druhá doména má jmenné servery dostupné po IPv6“. A protože dobrých zpráv není nikdy dost, je tu ještě jedna, tak trochu popelka mezi statistikami. IPv6 na poštovních serverech o sobě dává vědět a díky přírůstku 35228 domén za srpen se nejen přehoupla přes 10 %, ale se svými 13.04 % se přiblížila těsně pod hodnotu statistik webových stránek. Nezbývá jen doufat, že podobné přírůstky zaznamenáme i v dalších měsících.

Toť ze světa alokací zatím vše a určitě se s nějakým příspěvkem na toto téma nejpozději do měsíce ozvu.

Ondřej Filip

Z IETF 84: Interface to the Routing System

Novou zkratkou, kterou bylo často slyšet v kuloárech vancouverského meetingu IETF, je IRS. Cílem této iniciativy je, jak už název napovídá, standardizované rozhraní pro přístup do „střev“ IP směrovačů. Toto rozhraní má zprostředkovat externím softwarovým aplikacím poměrně detailní náhled do stavu směrovacího subsystému, ale také umožnit přímé zásahy do směrování a modifikace směrovacích tabulek (RIB) a dalších datových struktur, například LFIB (pro MPLS) a multicast RIB.

Více informací o IRS lze prozatím získat ze dvou Internet draftů:

Oba dokumenty lze těžko obvinit z přílišné skromnosti, pokud jde o šíři očekávaných aplikací. Autoři předpokládají nasazení IRS jak pro monitoring a diagnostiku směrování, tak i pro implementaci nejrůznějších administrativních politik v oblastech jako QoS, bezpečnost, diferencované nakládání se zákazníky apod., prostě všude tam, kde standardní konfigurace a směrovací protokoly (údajně) nestačí.

Prezentace IRS při jednání pracovní skupiny Routing Area vyvolala velmi bohatou diskusi. Reakce byly většinou pozitivní a podpůrné, kritické komentáře upozorňovaly hlavně na nebezpečí přílišné šíře záběru – jak se pěkně anglicky říká: „boiling the ocean“.

IRS se má od existujících metod interakce se směrovacím systémem (CLI, SNMP, IPFIX, NETCONF) lišit možností rychlého přístupu k detailním informacím o stavu systému a možností operativních softwarově řízených zásahů. První z uvedených dokumentů však při analýze vhodnosti protokolu NETCONF coby mechanismu pro realizaci IRS vycházel v řadě ohledů ze zastaralých anebo přímo nesprávných informací – NETCONF byl pak na jejich základě zavržen. Tyto nedostatky byly v diskusi také zmíněny a aktivisté IRS přislíbili, že se k výchozí analýze ještě vrátí a použití NETCONFu a jeho datových modelů znovu zváží.

Moje osobní dojmy jsou zatím smíšené. Samotná idea IRS jako mechanismu pro přístup ke směrovacím datům je v pořádku, trochu mne ale dráždí jeho avizované použití. Vychází totiž z předpokladu, že směrování v Internetu lze optimalizovat aktivním řízením routerů z nějakého „inteligentního“ centra. Dosavadní zkušenosti mne přesvědčují, že se v takových případech výkon sítě často spíše zhorší.

Otázky IRS jsou intenzivně diskutovány v konferenci  irs-discuss. Pokud půjde vše podle předpokladů, bude se na příštím meetingu IETF 85 v Atlantě konat zasedání typu BoF (Birds of a Feather) a z něj by následně mohla vzejít nová pracovní skupina IRS při IETF.

Ladislav Lhotka

Hodí Evropská komise VeriSign a další přes palubu?

Na začátku června Evropská komise s více než půlročním zpožděním představila návrh nové legislativy zaměřené na elektronickou identifikaci, autentizaci a elektronické transakce. Přesto, že hlavním cílem návrhu je sjednocení pravidel pro elektronický podpis a nahrazení, resp. novelizace Směrnice č. 1999/93/ES o zásadách pro elektronické podpisy, se zdá, že předkládaný návrh jde mnohem dál a postihuje nejen certifikáty pro elektronický podpis, ale rovněž certifikáty, které jsou využívány pro zajištění důvěryhodnosti webových stránek a zabezpečení komunikace s nimi, např. VeriSign patřící dnes pod křídla Symantec.

Obdobně jako současná Směrnice o elektronických podpisech upravuje návrh nařízení zohledňuje rovněž činnost certifikačních autorit. Ty rozděluje do dvou úrovní – poskytovatele důvěryhodných služeb a kvalifikované poskytovatele důvěryhodných služeb.

Zatímco na ty první nejsou, podobně jako dnes na vydavatele tzv. komerčních certifikátů, kladeny žádné požadavky, činnost těch druhých lze připodobnit k současným akreditovaným poskytovatelům certifikačních služeb typu První certifikační autorita (ICA) či PostSignum. Činnost těchto poskytovatelů je však oproti současné praxi vymezena mnohem šířeji a nově rozšiřuje oblast regulace nejen na vytváření, ověřování, potvrzování, zpracovávání a uchovávání elektronických podpisů, elektronických značek, elektronických časových razítek, ale rovněž na elektronické dokumenty, elektronické doručování a ověřování webových stránek.

Evropská komise se tak snaží zabrousit do vod, kde působí např. americký VeriSign a po nápadu na zřízení evropské ratingové agentury je zde snaha o zřízení evropských certifikačních autorit, které by vytvořily protiváhu americkým konkurentům. Jejich certifikáty by pak mohly být v Evropské unii přijímány pouze v okamžiku uzavření mezinárodní dohod. Proces uzavření takovéto smlouvy je upraven ve Smlouvě o fungování EU, konkrétně čl. 218, který mj. předpokládá zmocnění ze strany Rady (tj. členských států), kdy např. uzavření dohody s USA by pravděpodobně nebyla záležitost týdnů ani měsíců, ale spíše roků.

Návrh vzešlý z pera Komise zároveň opomíjí současnou praxi, kdy zajištění důvěryhodnosti dané webové stránky, resp. certifikátu, nepředstavuje otázku legislativy, ale zejména otázku, jak „dostat“ svůj certifikát do prohlížeče tak, aby se daná stránka nezobrazovala jako nedůvěryhodná. V této souvislosti lze zmínit např. americký certifikát GeoTrust, který nahradil certifikát PostSignum používaný informačním systémem datových schránek. Vzhledem k tomu, že návrh se akceptování certifikátů vůbec nevěnuje, je možné, že bychom se mohli v budoucnu setkávat s tím, že zejména vládní servery by nám nabízely „důvěryhodné certifikáty“, které by se však v prohlížeči zobrazovaly jako nedůvěryhodné, zatímco ty důvěryhodné z druhé břehu Atlantiku by zase neodpovídaly požadavkům evropské legislativy.

Jiří Průša

Co vše o vás může říct jeden „neškodný“ toolbar

Nedávno jsme zjišťovali, jak často jsou navštěvované naše stránky CSIRT.CZ, konkrétně záložka Aktuálně z bezpečnosti. Při tom jsme celkem náhodou přišli na zajímavou věc, která je spojená s doplňkem pro prohlížeč Mozilla Firefox, konkrétně s toolbarem od společnosti Alexa.

Tato společnost je předním poskytovatelem svobodných, globálních webových metrik. Jejich toolbar vám umožní vyhledávat na internetu informace třeba podle klíčového slova, kategorie nebo země. Dále můžete využít i její další nástroje, například pro optimalizaci přítomnosti firemních stránek na webu, analýzu růstu přístupů na web, statistiku nejčastěji hledaných slov na webu vaší společnosti a mnoho dalších.

Tento toolbar používají také někteří naši kolegové, především pro zjišťování návštěvnosti webových stránek. Ukázalo se však, že i takovýto zdánlivě neškodný nástroj může skrývat bezpečnostní riziko. Alexa toolbar totiž funguje tak, že se při přístupu na URL zeptá uvedený toolbar na návštěvnost dané domény na serveru alexa.com. Toolbar Vám pak zobrazí návštěvnost právě navštívené domény a naopak server alexa.com si udělá u domény další čárku za návštěvu. A nyní se dostáváme k jádru problému. Pokud zkusíte na webu alexa.com vyhledat libovolnou doménu, najdete tam také část „Where Visitors Go on“, kde můžete vidět návštěvnost jednotlivých subdomén této domény. Problém nastává, pokud máte subdoménu, například interní.vasedomena.cz, jejíž existenci chcete spíš utajit, aby se například útočníci nesnažili na tuto adresu dostat. Pokud ale uživatelé ve vaší síti používají tento toolbar a zároveň z prohlížeče přistupují na takovouto interní subdoménu, máte na problém zaděláno. Ano, hádáte správně, subdoména se objeví v části „Where Visitors Go on“ u údajů o návštěvnosti vašeho webu.

Pokud jste právě našli vaši úzkostlivě střeženou subdoménu v seznamu subdomén u vaší domény, máte v podstatě dvě možnosti. Používání tohoto doplňku ve společnosti zakázat, nebo se obrátit na technickou podporu služby Alexa.

Nutno říci, že podpora funguje dobře a že je pravděpodobně na tyto situace proškolená. Když totiž založíte nový ticket nebo položíte dotaz, přijde vám potvrzení o přijetí vašeho požadavku. Za pár hodin dostanete další e-mail, kde naleznete také jméno osoby, která vaší situaci řeší.

Podle naší zkušenosti bylo do dvou dnů vše napraveno. Pokud by to šlo, dal bych jim palec nahoru ;-). Podotýkám ale, že společnost nebo žádající osoba musí mít u Alexy založený svůj vlastní účet.

Doporučujeme tedy všem bezpečákům, aby zkontrolovali, zda se na těchto internetových stránkách, nevyskytují také nějaké interní URL vaší společnosti a aby se případně zařídili podle svého nejlepšího vědomí a svědomí ;-).

Michal Prokop

Z IETF 84: SNMP data pod křídla NETCONFu?

Můj druhý postřeh z meetingu IETF 84 se také týká protokolů a nástrojů pro síťový management. Zatímco minulý příspěvek byl věnován konfiguračním datům, dnes bych se rád zmínil o jedné diskusi týkající se stavových dat, která jsou pro efektivní správu síťových zařízení také velmi důležitá. Čím se liší od těch konfiguračních? Rozdíl můžeme ukázat na jednoduchém příkladu IP adresy. Ta může být pro dané rozhraní buď statická, a pak je zapsána někde v konfiguračních datech, anebo se získává pomocí DHCP a její aktuální hodnotu může správce zjistit ze stavových dat. Za stavová data se obvykle považují i různé statistické čítače, kupříkladu počty bajtů přijatých a odeslaných přes dané rozhraní.

Pro práci s oběma typy dat jsou k dispozici dva konkurenční protokoly: SNMP a jeho mladší bratranec NETCONF. Pokud jde o konfigurační data, hovoří vše celkem jasně pro NETCONF, SNMP se v této oblasti neosvědčil a dnes se prakticky nepoužívá. U stavových dat je ale situace do velké míry opačná a SNMP tu zatím jednoznačně vládne. Síťovým operátorům už se ovšem dosti zajídá spravovat sítě pomocí dvou různých protokolů – a začínají se hlasitě ozývat.

Diskuse na toto téma propukla na IETF 84 poněkud nečekaně během jednání pracovní skupiny OPSAWG, když byl na programu Internet draft draft-schoenw-opsawg-vm-mib-01, který definuje část databáze SNMP MIB se stavovými daty pro virtuální počítače s hypervizorem. Rozbuškou však nebyl tento celkem nevinný dokument, ale osoba přednášejícího: byl jím Jürgen Schönwälder, který je jednou z vůdčích figur stojících za návrhem protokolu NETCONF. Dotaz z pléna zněl zhruba takto: „Jestli to s NETCONFem myslíte vážně, proč nás pořád zásobujete novými daty pro SNMP a neimplementujete raději stejná data v NETCONFu?“ Většina diskutujících se pak skutečně přiklonila k názoru, že by bylo velmi prospěšné toto schizma postupně odstranit a mít všechna stavová data k dispozici prostřednictvím NETCONFu.

To se snadno řekne, ale hůře udělá. Převod všech definic objektů z databáze MIB (zapsaných v jazyku SMIv2) na datový model pro NETCONF (v jazyku YANG) je sice možný, vzhledem k vysokému počtu MIB objektů je to ale práce pro vraha, a tak se do ní nikomu nechce. Druhou alternativou, která se již také testovala, je proto automatický převod. Pro tento účel dokonce existuje specifikace v RFC 6643, jehož autorem je shodou okolností rovněž Jürgen Schönwälder.

Jenže, jak víme i z jiných případů, výsledky strojového překladu nebývají zrovna ideální. V daném případě se naráží jednak na některé nekompatibility mezi jazyky SMIv2 a YANG (příkladem je rozdílný způsob indexace objektů v databázi), ale také na problém převodu důležitých informací zapsaných v MIB modulech volným textem – doplňujících popisů a implementačních instrukcí.

Momentálně tedy převládá názor, že automatický převod lze použít ad hoc v případě akutní potřeby přístupu k MIB datům pomocí protokolu NETCONF. Z dlouhodobého hlediska bude ale asi nezbytné podstoupit martyrium spojené s ruční konverzí. Vypadá to tedy, že internetová komunita má v této oblasti o práci postaráno na řadu příštích let.

Ladislav Lhotka

Z IETF 84: standardizace konfiguračních dat

Během posledního meetingu IETF, který měl pořadové číslo 84 a konal se v kanadském Vancouveru, se výsledky mých „kmenových” pracovních skupin NETCONF a NETMOD objevily v zajímavé diskusi na širších fórech, konkrétně v mailing listu ietf@ietf.org, při jednání pracovní skupiny OPSAREA (Operations and Management Area), jakož i v kuloárních debatách.

Diskusi zahájil svým příspěvkem polský kolega Robert Raszuk. Pozastavil se nad tím, že ve specifikacích nových protokolů chybí schéma konfiguračních dat, a navrhl, aby všechna RFC povinně obsahovala oddíl s takovým schématem, protože bez něho si každá implementace vytváří svůj vlastní způsob konfigurace, který nemusí být s ostatními zrovna kompatibilní. Problém je to reálný, kdo by tomu nevěřil, ať si zkusí mezi sebou převést netriviální konfigurace směrovačů různých výrobců (včetně našeho BIRDa).

Navrhované řešení, tedy zavést toto jako povinnost, se ovšem setkalo s jednoznačným odporem. Robertovi se též dostalo doporučení, aby se seznámil s výsledky pracovní skupiny NETMOD, kde se již datové modely pro některé základní protokoly a subsystémy vyvíjejí.

V této souvislosti se ale ukázalo, že datové modely NETMOD tak docela nenaplňují vizi unifikace konfiguračních schémat. Jsou totiž poměrně pružné a umožňují definovat schémata v různých podobách, od odlišností v pojmenování objektů (klasickým příkladem jsou třeba jména síťových rozhraní) až po menší či větší rozdíly v logice a uspořádání konfiguračních dat. Důvody jsou nasnadě: Nelze očekávat, že přední výrobci směrovačů a jiných zařízení po zveřejnění datových modelů srazí paty a překopou svá konfigurační rozhraní, která si po léta hýčkají a školí na nich své zákazníky. Jistá míra pružnosti proto dává naději, že by se konkrétní implementace datových modelů mohly naopak přizpůsobit existujícím konfiguračním rozhraním. Lze pak ovšem očekávat, že nebude možné jednoduše vzít konfiguraci jednoho boxu a instalovat ji beze změn na obdobném zařízení jiného výrobce.

Toto je docela složité dilema, uvidíme, jak se věci vyvinou. Rozhodně by ale bylo dobré, kdyby se specifikace konfiguračního schématu staly součástí standardů aspoň pro nové protokoly – byť třeba nepovinně.

Ladislav Lhotka

Odvrácená strana internetu

Úvodem článku musím říci, že jsem nějaký čas přemýšlel, zda k sepsání tohoto blogpostu přistoupit. Nakonec jsem se rozhodl, že to udělám, protože ten, kdo bude chtít tyto věci zneužít, ten si tyto informace stejně dokáže opatřit a naopak si myslím, že znalost toho, jakým způsobem a kde jsou obchodována ukradená data, může přispět k větší opatrnosti i u běžných uživatelů. Navíc lze očekávat, že s nedávným úspěšným zátahem FBI na prodejce kradených údajů o platebních kartách bude většina těchto obchodů již nadále probíhat pouze v níže popsaném prostředí. FBI totiž při zatýkání uspěla díky spuštění vlastního on-line webu na doméně carderprofit.cc, který měl výměnu a prodej informací o platebních kartách umožňovat.

Screenshot původního webu carderprofit.cc, před tím, než jej FBI letos v květnu vypnula

Jako důkazy pak použila i informace o IP adresách, ze kterých bylo k tomuto webu přistupováno. To by se jí v prostředí, o kterém dnes bude řeč, nejspíš tak snadno nepodařilo získat.

Pro cestu na odvrácenou stranu internetu jsou potřeba dva open source programy: Tor a Bitcoin. Ten druhý pouze v případě, že bychom chtěli skutečně něco kupovat. V našem případě je uveden proto, aby bylo patrné, jakým způsobem probíhá anonymní obchod. Bitcoin je digitální měna, která funguje od roku 2009. Měna je stejně jako běžná hotovost při dodržení určitých pravidel těžko vystopovatelná, tedy se hodí právě k nakupování na černém trhu. Nejprve je třeba nějaký ten bitcoin získat, bitcoin lze bez problémů směnit v příslušné směnárně například za Eura. Jakmile máme bitcoiny, můžeme se vydat nakupovat.

Bitcoinová peněženka

K tomu budeme potřebovat stáhnout Tor Browser ze stránek projektu Tor. Ten má hned dvě zásadní funkce. Jeho použitím zajistíte svou anonymitu a zároveň získáte přístup ke skrytým serverům v doméně .onion, ke kterým se z „běžného“ internetu nedostanete. Skryté servery jsou běžně používány k provozování široké plejády nelegálních aktivit, od šíření návodů na výrobu různých nelegálních chemických látek až po šíření dětské pornografie. Vzhledem k povaze této sítě je totiž velmi obtížné někoho chytit a obvinit. Je však zároveň potřeba říci, že tato její vlastnost je také důležitá a užitečná. Umožňuje uživatelům z nedemokratických  režimů anonymně hledat, či naopak publikovat informace, jejichž hledání či publikování by pro ně jinak mohlo znamenat problémy.

Po spuštění tohoto prohlížeče tedy zkusíme přes Google vyhledat slovní spojení Tor Directories. Tím si najdeme v „běžném internetu“ seznamy adres existujících v doméně .onion. Na načtení stránek si ovšem chvíli počkáme, síť je obvykle dost pomalá. Asi nejznámější adresářová služba pro Tor je Nobody@Zerodays.

Nobody@Zerodays

Jeden ze zde nabízených odkazů je například na Hidden Wiki, kde se můžete dovědět spoustu informací, které obvykle lidé znát nepotřebují, od návodů na výrobu drog, až po to, jak si zařídit svůj vlastní server s ilegálním obsahem, tak abyste zůstali nepostižitelní.

Hidden Wiki

Najdete zde také rozcestníky na další nelegální weby, či obchody, kde si můžete koupit cokoliv, od zbraní, přes drogy až třeba po DDOS útok.

Na jedné z .onion adres pak najdete skutečně originální e-shop s názvem Black Market Reloaded. Pro možnost obchodování je potřeba se zaregistrovat, e-mailová adresa pro registraci může být smyšlená.

BlackMarket

Tento obchod nabízí snad úplně vše, co v běžných e-shopech nenajdete. Nástroje na výrobu vlastních platebních karet, odcizená čísla platebních karet, ukradené identity uživatelů, zbraně, drogy, či dokonce trhavinu na bázi C4. Dokonce nabízí i možnosti známé především z běžných bazarových a aukčních obchodů. Kupující tedy může například po realizaci obchodu ohodnotit prodávajícího.

Je libo trhavinu i s rozbuškou?

V doméně .onion by se dala jistě najít spousta dalších „zajímavých“ věcí, se kterými se na internetu běžně nesetkáte, ale pro představení tohoto svébytného prostoru byly myslím předchozí řádky více než dostatečné. Doufám, že tato malá exkurze na odvrácenou stranu internetu pro vás byla zajímavá. A pokud se po přečtení článku také zamyslíte, zda svá data před podobnými obchodníky dobře chráníte, pak článek splnil svůj účel.

Pavel Bašta