Najskôr sa už každému podarilo spraviť preklep v názve domény pri ručnom písaní do browseru a dostať sa na doménu zaregistrovanú „typosquatterom“, aby využil preklep k nejakému zisku (typicky reklamy). Artem Dinaburg prezentoval na konferencii Defcon 19 zaujímavú variantu nazvanú bitsquatting.
Bitsquatting je založený na predpoklade, že v počítačoch pripojených k internetu dochádza občas vplyvom tepla, elektromagnetického žiarenia apod. k chybe, ktorá prehodí v pamäti niektorý bit. Takáto bitová chyba nastáva veľmi zriedkavo, preto na „zmysluplné“ využitie sa musí jednať o mimoriadne často dotazovanú doménu.
Dinaburg si zaregistroval niekoľko variant populárnych domén s jedným prehodeným bitom, ktorý je na klávesnici ďaleko od originálneho znaku (napr. mic2osoft.com s prehodeným 7. bitom v znaku ‚r‘, aby sa to jednoduchšie odlíšilo od typosquattingu) a sledoval 7 mesiacov príchodzie dotazy. Za toto obdobie prišlo 52 317 dotazov z 12 949 unikátnych IP adries, čo je dosť malý počet oproti chybám z preklepov. Relatívne nízky počet je očakávateľný kvôli nízkej pravdepodobnosti výskytu bitovej chyby. Nasledujúci graf ilustruje rozloženie počtu spojení od unikátnych IP počas meraného obdobia:
Okrem troch anomálií (označených v grafe A, B, C) je počet IP za deň celkom rovnomerný. Prvé dva extrémy (A, B) podľa autora vznikli chybou cache priamo v infraštruktúre spoločnosti Zynga (tvorca hry Farmville), za posledný (označený C) je zodpovedná proxy alebo DNS resolver spoločný pre menšiu sieť.
Koncept vzbudil miernu nedôveru, pretože je celkom ťažké dokázať, že sa jedná o bitovú chybu a nie o zvláštny preklep alebo aktivitu skriptu, ktorý enumeruje domény. Asi najlepší argument podporujúci Dinaburgove tvrdenie sú rozdiely medzi dotazovanou doménou a HTTP Host hlavičkou: 3 % HTTP spojení na bitsquat domény obsahujú Host hlavičku odpovedajúcu pôvodnej („nebitsquatovej“) doméne, čomu pri typosquattingu nedochádza. Naviac v jeho príkladoch obsahujú bežne HTTP spojenia aj Referer.
Niektoré komentáre namietali, že pri podobných „náhodných“ chybách by neboli schopné počítače pracovať. V skutočnosti si človek takú chybu skôr vôbec nevšimne. Zhodou okolností som asi pred 15 rokmi robil experiment, ako sa PC vysporiada s chybami v RAM. Na starších PC bolo možné preprogramovať cez časovač frekvenciu obnovy pamäte (DRAM refresh). DRAM refresh zaručuje, že pamäť „nevybledne“ (nestratí sa z kondenzátorov náboj). Po znížení frekvencie refreshu trvalo rádovo minúty, než boli chyby človekom viditeľné (refresh je rádovo mikrosekundy až milisekundy). Prvé viditeľné chyby boli zmeny zobrazovaných znakov, logické chyby v aplikáciách a nakoniec pád systému. Podobne Dinaburg zachytil prípady havarujúcich Windows strojov, ktoré odosielali chybové hlásenia na bitsquat domény.
Ďalšie informácie k bitsquattingu sa dajú nájsť v Dinaburgovej prezentácii a článku.
Ondřej Mikle, Laboratoře CZ.NIC
Další zlepšení komunikace registru domén
Od 1.srpna jsme v registru domén začali zasílat novou zprávu s informacemi o datech jednotlivých zákazníků. Jde o e-mail, který se posílá na adresy kontaktů a obsahuje žádost o kontrolu údajů. Generuje se automaticky, jedenkrát za rok, a to pro ty kontakty, které mají dva měsíce do „výročního data“ jejich vzniku. Pokud jste tedy svůj kontakt v registru vytvořili 1. října kteréhokoliv roku, už jste tento e-mail dostali.
Tímto krokem chceme přispět k ještě lepší kvalitě dat v registru. Dva měsíce před výročním datem nebylo zvoleno náhodně – vycházíme z toho, že většina zákazníků si zároveň s kontaktem registrovala i doménu, která tedy bude v daný den expirovat. A pokud si zákazník dva měsíce před tímto datem údaje u kontaktu opraví, prodloužení domény proběhne bez problémů.
Také chceme, aby zákazník byl lépe informován o tom, jaké domény (a nejenom ty) vlastně v našem registru má. Proto mu v tomto e-mailu přikládáme také seznam domén (sad jmenných serverů a sad klíčů), ke kterým je tento kontakt přiřazen. Každý tak má možnost zároveň s kontrolou svých údajů zjistit i to, kde všude je vlastně tento kontakt uveden (případně kde není ;-).
Oprava údajů se provádí prostřednictvím registrátorů – proto v tomto e-mailu (na rozdíl od všech ostatních e-mailů, které zasíláme) dáváme určenému registrátorovi kontaktu možnost do komunikace vstoupit. E-mail může doplnit svými informacemi (jak ho může zákazník kontaktovat apod.); e-mail může být také odeslán s reply-to adresou registrátora. Pokud na něj tedy v takovémto případě odpovíte, dostane se rovnou do správných rukou.
Zákazníka ale nechceme zbytečně opravovat. Pokud tedy v uplynulých dvou měsících (před plánovaným odesláním tohoto e-mailu) provedl u kontaktu nějakou změnu, tuto naši žádost už nedostane. Na řadu přijde znovu za rok.
Dosavadní zkušenosti po týdnu odesílání jsou víceméně pozitivní. Za zákaznickou podporu CZ.NIC mohu konstatovat, že jsme až na jednu nebo dvě výjimky nezaznamenali prakticky žádnou vyloženě negativní reakci. Naopak nám adresáti těchto e-mailů často odpoví i v případě, že jejich údaje jsou v pořádku a není tedy potřeba nijak reagovat. Ani od registrátorů, kteří se zapojili se svými texty a adresami, v tuto chvíli nemám žádnou negativní reakci. Doufejme tedy, že takhle nám to vydrží i nadále.
Na závěr jedno číslo, které vás možná překvapí a možná ne – průměrně každý den odešleme 1730 těchto e-mailů.
Martin Peterka
Červencové alokace táhla Francie
Zatímco červen byl v IPv4 alokacích v evropském regionu velice chudý, v červenci si tento kontinent vše vynahradil. Evropa se s více než sedmi milióny adresami postarala o téměř tři čtvrtiny světové spotřeby. To je trochu překvapivé, protože právě v evropském regionu vstoupila 1. 7. v platnost přísnější alokační pravidla. Je ovšem možné, že provedené alokace byly zahájeny ještě v dřívějším období. Celková světová spotřeba adres dosáhla téměř 10 miliónů; druhým regionem z hlediska spotřeby byla Latinská Amerika. Ostatní tři regiony byly z hlediska alokací téměř nevýznamné. Celou situaci zachycuje následující graf.
Dlužno podotknout, že evropské tempo značně ovlivnila více než čtyř miliónová alokace společnosti Bouygues Telecom. Vzhledem k tomu, že dle pravidel z června by měly být adresy přiděleny na maximálně šest měsíců dopředu, musí tato společnost pracovat na nějakém skutečně velkém projektu. Jinak si to neumím vysvětlit. Druhou největší alokaci provedla mexická společnost Uninet S.A. de C.V., v jejím případě šlo o cca jeden milión adres. Tyto dvě alokace tedy tvořily více než polovinu celkové spotřeby, bez nich by byl červenec podprůměrný.
Bohužel, žádný výrazný impulz nedostaly IPv6 alokace a tak v červenci došlo k očekávatelnému prázdninovému zpomalení. Bylo provedeno 149 alokací, z toho Česká republika zaznamenala tři a ostatní země V4 alokovaly po dvou. Situace je vidět na následujícím grafu.
Kvůli tomuto výraznému francouzskému příspěvku nedošlo k zásadnímu posunu předpokládaného data konce IPv4 adres v Evropě. Stále by se tak mělo stát na přelomu února a března příštího roku.
Ondřej Filip
Okurková sezóna neplatí pro mojeID
Obecně platí, že se v létě nic neděje; jsou prázdniny, dovolené, okurková sezóna jede na plné pecky. Pořekadlo o tom, že výjimka potvrzuje pravidlo ale platí i v létě a v tomto případě pro společnost ZONER software a registrátora domén KRAXNET. Obě jmenované firmy totiž nedávno oznámily zavedení služby mojeID do svých systémů.
V případě ZONERu se jedná o implementaci mojeID do služby inPage, která nabízí moderní systém pro snadné vytvoření a správu webových stránek včetně e-mailu, registrace domény a e-shopu. Jak je uvedeno v dnešní tiskové zprávě, majitelé stránek mohou autorizaci pomocí mojeID jednoduše zapnout v administraci a zákazníkům tak usnadnit nakupování bez zdlouhavého vyplňování objednávkového formuláře. MojeID může od července na plno využívat více než 2 000 uživatelů služby inPage.
Dalším, kdo v nedávné době zavedl mojeID pro své zákazníky, je registrátor domén a poskytovatel webhostingu, společnost KRAXNET. Ta se tak stala už druhým registrátorem, který mojeID implementoval. Zákazníci KRAXNETu se s mojeID mohou setkat na www.xnet.cz. Do budoucna plánuje tento registrátor používat mojeID i pro autorizaci požadavků na změnu údajů v rejstříku domén.
Toto léto tedy zdá se mojeID přeje. Pevně věříme, že to nebyly poslední novinky co se této služby týče, a že nás „okurková sezóna“ dokáže letos ještě příjemně překvapit.
Vilém Sládek
Léto nahrává čtení atd.
Součástí osvětových aktivit našeho sdružení je i publikační činnost. Když se k ní přidá ještě pár rozhovorů, kterých už není za ty roky jako šafránu, dá to na jeden pěkně dlouhý seznam výstupů v médiích. Kam směřuju?
Na našich stránkách teď najdete vyčerpávající přehled tematických seriálů (ENUM, DNSSEC, IPv6), samostatných článků na téma bezpečnost, domény, právo, databáze nebo rozhovorů ve všech možných typech médií. Soubor je už celkem reprezentativní a bohatý, tak nám přišlo škoda se s ním nepochlubit.
Seznam není kompletní; k posledním třem rokům přibudou samozřejmě další léta a další výstupy. Ani my nejsme neomylní, a tak se mohlo klidně stát, že vám bude ve výčtu něco chybět. Budeme rádi, když nás na absentující autorské práce upozorníte v komentářích. Děkujeme předem.
Vilém Sládek
Červnové zpomalení
V minulé glose jsem zmiňoval, že květen byl spíše alokačně chudším měsícem. Červen na tento trend překvapivě navázal a spotřeba IPv4 adres v tomto měsíci nepřekročila devět miliónů. Evropané si sice udrželi první příčku, ale tentokrát jen skutečně těsně před Afrikou a Latinskou Amerikou. Počty spotřebovaných IPv4 adres byly v těchto zmiňovaných regionech velmi podobné a to mírně pod tři milióny. Velice nízkou spotřebu měl opět severoamerický region a žebříček pochopitelně uzavírá region Asie-Pacifik, který téměř výlučně přiděluje po 1024 adresách. V evropském regionu začala od 1. 7. další fáze zpřísnění alokační politiky. Nově už bude možné alokovat pouze na tři měsíce dopředu, což jistě dále evropskou spotřebu ovlivní. Následující graf ilustruje situaci regionů.
Alokační tempo Afriky a Latinské Ameriky ovlivnily dvě veliké alokace čítající přes dva milióny adres. První byla pro společnost Maroc Telecom a druhá pro mexickou společnost Uninet S.A. de C.V. To také pochopitelně vyneslo Mexiko a Maroko na první dvě příčky v pořadí spotřeby států. Další byla Jižní Afrika a až na čtvrtou příčku se dostal zástupce evropského regionu, konkrétně Španělsko. Celou situaci ilustruje následující graf. Jak je vidět Mexiko s Marokem tvořily téměř polovinu světové spotřeby.
Možná jste si podobně jako já kladli otázku, zdali se Světový den IPv6 nějak odrazil v IPv6 alokacích. Odpověď zní, že nijak zvlášť. IPv6 alokací bylo zhruba stejně jako v květnu či dubnu, konkrétně 243. To je ale každopádně vysoké tempo, jak ilustruje následující graf.
Tedy co říci závěrem? Červen byl z hlediska alokací takovým ospalým měsícem a to především v našem regionu. Do budoucna uvidíme, zdali bude v praxi fungovat nové zpřísnění alokační politiky. Mohlo by oddálit konec IPv4 v Evropě, který se dá dle současné rychlosti odhadnou na únor/březen příštího roku.
Ondřej Filip
IPv6 Heartbreak… bez komentáře
Kdo: Chris van Fossen (Hurricane Electric, USA)
Kdy: 8. června 2011 (Světový den IPv6)
Kde: konference Internet a Technologie 11 (Praha)
VS
DNSSEC v další doménové stáji
Je to už nějaký ten pátek, co jsme na domácí DNSSECové scéně zaznamenali nějaký razantnější pohyb. Dobu relativního klidu přerušila včera tisková zpráva společnosti ONEsolution, jejíž pravdivost potvrdily informace z našich statistik. Registrátor ONEsolution podepsal k dnešnímu dni více než 6 tisíc „svých“ domén (s NSSETem u této společnosti). DNSSEC samozřejmě dostanou všechny další domény, které si zde nově zákazníci zaregistrují. Jak se tento krok dotýká situace v České republice? V tuto chvíli je DNSSECem chráněno více než 133 tisíc domén .CZ, což představuje více než 16 procent z celkového počtu. Následující seznam ukazuje, jak se krok ONEsolution projevil mezi registrátory podporující tuto bezpečnostní technologii (první pětka):
1. Active24 (více než 96 tisíc)
2. Web4U (více než 20 tisíc)
3. ONEsolution (více než 6 tisíc)
4. TELE3 (více než 4 tisíce)
5. GRANSY (více než 1 900)
Podle neověřených zpráv můžeme v relativně blízké době očekávat zavedení DNSSEC v další doménové stáji. Která to bude (nebo u koho byste si to přáli) můžete zatím tipovat v komentářích.
Vilém Sládek
Internet má nového šéfa
Poslední zasedání organizace ICANN přineslo neuvěřitelné množství novinek. Tu největší jsem již komentoval na Lupě. Další výstup je velice důležitý pro naši českou komunitu, protože další evropské zasedání ICANNu bude za rok v Praze. To je skvělá zpráva a velké uznání od mezinárodní komunity. Nicméně, rád bych se trochu zamyslel u trochu jiného výsledku jednání. Představenstvo ICANNu bylo mírně obměněno. Jeho předseda, Peter Dengate Thrush, se rozloučil s komunitou poté, co mu vypršel mandát.
Do představenstva byl nominován na konci roku 2005 organizací ccNSO, což je sdružení národních domén (ccTLD). Předsedou byl zvolen na konci roku 2007 a přebíral tuto funkci po téměř legendárním Vintovi, což jistě nebylo jednoduché. A právě tato změna, jako by znamenala určitý přelom v dějinách ICANNu. Za Peterova předsednictví se staly tři významné události, které bych rád zmínil.
Jinými slovy, Peter zvládl udělat za své období neuvěřitelné množství práce a proto byl po právu zapsán do registru speciálních osobností v IANA (v době psaní příspěvku nebyl ještě registr aktualizován, ale Peter dostal celkem logicky číslo 11.) Jsem velice rád, že se mu této velké cti dostalo. Peter je skutečně výjimečný člověk a to jak po pracovní, tak i po osobní stránce. Dokázal přežít neuvěřitelnou osobní tragédii, kdy v jednom hrůzném okamžiku přišel o celou svou rodinu, a možná i právě proto se rozhodl věnovat veškerou svou zbývající energii Internetové komunitě. Ačkoliv byl zvolen za národní domény, největší událost jeho funkčního období souvisí s generickými doménami. Mimo oficiální jednání byl příjemný, vtipný člověk, vždy připravený naslouchat.
Na jeho místo nastupuje skutečný mohykán a stávající místopředseda Steve Crocker. Steve je jedním z otců zakladatelů, je autorem RFC dokumentu číslo 1. A stejně jako mnozí další z této skupiny, je velmi přátelský a bezprostřední. Poznal jsem ho tak, že u příležitosti prvního pražského IETF meetingu prostě pozval zástupce CZ.NIC na pivo. Od té doby jsem s ním spolupracoval na některých fórech, která se týkala DNSSECu, o jehož vznik a propagaci se Steve hodně zasloužil. Samozřejmě fakt, že je Česká republika DNSSECovým lídrem ho velice těší; zajímá se o naši situaci od samého začátku.
Steva čeká hodně práce. Pravidla vzniku nových generických domén stále nejsou zcela hotova. Jistě bude muset absolvovat ještě mnoho jednání s vládním výborem – GAC. A v průběhu toho jej čeká neméně komplikovaná věc, kterou bude revize kontraktu stávajícího ředitele Roda Beckstroma. Rod je člověk poměrně výrazný a už si vysloužil i mnoho kritiky. Za jeho éry ICANN opustilo mnoho zaměstnanců a některé jeho kroky vzbudily rozpaky. Uvidíme, jak se k tomuto Steve postaví.
Ihned po volbě jsem šel pochopitelně Stevovi pogratulovat, poděkoval jsem mu za volbu Prahy jako města pro příští evropské jednání a popřál jsem mu hodně štěstí v jeho náročné roli.
Po Peteroví, jež je původem právník, se kormidla opět ujímá člověk z technické komunity. Bude zajímavé sledovat, jak se tato změna odrazí v projevu ICANNu.
Ondřej Filip
I-D ECDSA pro SSHFP aneb krátký zápis o vzniku jednoho budoucího RFC…
Minulý týden vyšel na serveru Root.cz pěkný článek DNSSEC jako bezpečné úložiště SSH klíčů, který byste si měli přečíst, pokud chcete, aby vám tento blogpost dával aspoň nějaký smysl. Ve zmíněném článku zaznělo jedno takové povzdechnutí „Bohužel, specifikace záznamu SSHFP dosud nebyla rozšířena o podporu pro ECDSA klíče, jejich otisky tedy prozatím není možné do DNS uložit.“, které spustilo řetěz událostí, které (snad) vyústí v aktualizaci RFC.
Po chvilce pátrání v RFC lze zjistit, že autoři RFC 5656, které do Secure Shell protokolu přidává ECDSA algoritmus, opravdu zapomněli zaktualizovat i RFC 4255 definující SSHFP záznam. Seznam algoritmů pro klíče a jejich otisky jsou udržovány v registru IANA v seznamu DNS SSHFP Resource Record Parameters a je možné je zaktualizovat pomocí mechanismu „IETF Consensus“, který je definovaný v BCP 26:
IETF Consensus – New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists).
Ve zkratce řečeno, pro aktualizaci seznamu algoritmů je zapotřebí samostatné RFC. Jelikož pracovní skupina secsh je již uzavřena, tak zbývaly dvě možnosti – najít jinou pracovní skupinu, která by byla blízko, nebo nový draft publikovat jako individuální.
Tak či onak nový Internetový Draft (I-D) se nenapíše sám… a jelikož byl DNSSEC nedávno obohacen o rodinu algoritmů SHA-2, tak nebylo potřeba začínat na zelené louce, ale bylo možné se inspirovat již schváleným RFC. Také proto, ale nejen z tohoto důvodu, nový návrh rozšiřuje záznam SSHFP i o otisky pomocí SHA-256. Původně draft obsahoval i SHA-385 a SHA-512, ale nakonec na základě komentáře Ólafura Guðmundssona (předsedajícího pracovní skupině DNSEXT) byl výčet algoritmů zredukován jen na SHA-256 (aneb pokud to stačí pro otisk v DS záznamu, tak to musí stačit i pro SSHFP záznam). Další komentáře, které jsme dostali a následně začlenili do návrhu, byly od Stephena Kenta (ředitel oblasti Security).
Jedna z připomínek byla, zda-li by draft nemohl také obsahovat příklady nových záznamů. Což bylo již kousek od toho napsat funkční implementaci nových algoritmů do OpenSSH, což, jak se nakonec ukázalo, nebyl nijak heroický výkon a výsledek (používejte pouze na vlastní riziko) naleznete v patchi ssh-sshfp-ecdsa.patch.
Výsledný návrh nového I-D byl publikován pod názvem draft-os-ietf-sshfp-ecdsa-sha2 (zdrojové xml). Stephen Kent také navrhl, že bude nejlepší poslat nové I-D do obecné skupiny SAAG, což proběhlo hned po nahrání I-D do nástrojů IETF. Zatím se k novému návrhu nikdo nevyjádřil, takže doufejme, že je to kvůli tomu, že je to vcelku dost nudný návrh RFC :). Těsně před psaním tohoto příspěvku jsem ředitele oblasti Security požádal, zda-li by náš návrh nesponzoroval. Takže držme palce, aby tento jednoduchý návrh (ECDSA bude mít číslo 3, SHA-256 bude mít číslo 2), který ovšem v jazyce RFC znamená 9 stran textu :), hladce projde schvalovacími procesy IETF.
Na závěr bych chtěl poznamenat, že z hlediska procesů IETF je jedno, jestli je autor Internetového Draftu dlouhodobě zapojen do práce IETF nebo jen přijde, napíše návrh a zase odejde. Za CZ.NIC můžu říci, že bychom byli velice rádi, kdybychom mohli k práci pro IETF přitáhnout více lidí z ČR. K sérii popularizačních článků, které vyšly na Lupě (Cesta do hlubin IETF, Odkud pochází Internetové standardy (aneb bylo jednou jedno RFC) a Vrána k vráně sedá aneb koťátka, dogy a nápoje v IETF), tak přidáváme tuto veřejnou nabídku.
Pokud máte nápad na nový protokol, standard nebo jen menší či větší vylepšení stávajícího (viz toho rozšíření SSHFP o nové algoritmy), tak se na nás můžete kdykoliv obrátit. Velice rádi vám s psaním návrhu nového RFC pomůžeme.
Ondřej Surý