Distribuovaná kybernetická bezpečnost

Na konferenci IT 13 jsme mimo jiné představili nový projekt zaměřený na vývoj bezpečného domácího routeru. Ten je součástí většího projektu zaměřeného na zlepšení bezpečnosti v českém síťovém prostředí a to pomocí aktivního monitoringu a analýzy síťového provozu. Zmíněný domácí router bude v rámci tohoto projektu plnit roli síťové sondy a zároveň aktivního prvku v ochraně koncových uživatelů.

V tomto krátkém článku si představíme především hlavní důvody vzniku tohoto projektu a jeho cíle.

Motivace

Každý, kdo provozuje nějaký veřejně dostupný server a podívá se občas do jeho logů, ví, že internet není klidné a bezpečné místo. I bez jakéhokoli zásahu uživatele se s počítačem připojeným k internetu neustále pokouší spojit různé cizí stroje a to málo kdy s dobrými úmysly (vizte např. výsledky z našeho honeypotu).

Vzhledem k tomu, že většina domácích sítí je připojená k síti svého poskytovatele přes jeden přístupový bod, kterým je domácí router, a často používá NAT, který schovává celou domácí síť za jedinou IP adresu, vedou první útoky v podstatě vždy právě na domácí router. Ten je tedy ideálním místem jak pro detekci pokusů o neoprávněný přístup do sítě, tak pro aktivní ochranu před nimi. Pokud by si navíc routery byly schopny mezi sebou informace o detekovaných útocích vyměňovat, mohlo by to vést ke zvýšení účinnosti ochrany jednotlivých strojů a zároveň detekci velkých útočníků.

Protože se v našem sdružení dlouhodobě věnujeme problematice internetové bezpečnosti, rozhodli jsme se vytvořit systém, který by s pomocí sítě domácích routerů dokázal monitorovat podezřelý síťový provoz a reagovat na zjištěné bezpečnostní hrozby úpravou pravidel pro přístup do sítě. Takto získané výsledky by pak byly k dispozici i pro ochranu dalších uživatelů Internetu.

Distribuovaný adaptivní firewall

Systém, který jsem nastínil v minulém odstavci, interně nazýváme „distribuovaný adaptivní firewall“ a je v této chvíli ve fázi aktivního vývoje. Součástí systému je klientská část, která po aktivaci na domácím routeru monitoruje nevyžádané pokusy o přístup do sítě zastavené firewallem a také provádí analýzu protékajících dat. V těch se pokouší odhalit anomálie, které by mohly být příznakem úspěšného útoku nebo již existující nákazy. Výsledky obou zmíněných částí klientského systému jsou nahrávány na druhou část systému, kterou je centrální server, kde jsou data dále zpracovávána a porovnávána s výsledky z ostatních sond.

Pokud je systémem některá část provozu vyhodnocena jako anomální a odborná obsluha systému vyhodnotí danou anomálii jako potenciální útok, připraví pro ni nové pravidlo pro firewall. To je potom formou aktualizace nahráno zpět na všechna zařízení zapojená do sběru dat.

Pro případy, kdy je třeba o dané anomálii získat doplňující informace, je součástí systému také nástroj na spouštění specializovaných „mikrosond“, které je možné formou modulů nahrávat na sledovaná zařízení. Ty pak umožní zaměřit analýzu na konkrétní typ provozu a získat detailnější data o daném jevu.

Výsledkem výše popsaných opatření je systém, v rámci kterého budou moci uživatelé chránit své sítě i sítě ostatních účastníků před vnějšími útoky a který se bude postupně „učit“ reagovat na nové hrozby. Navíc bude možné takto získaná data použít i pro ochranu další uživatelů Internetu, kteří nejsou do projektu přímo zapojeni, a také pro další analýzy získaných informací.

Závěr

V tomto článku jsme si představili nový projekt sdružení CZ.NIC zaměřený na distribuovanou kybernetickou bezpečnost. V blízké budoucnosti si v samostatném příspěvku ukážeme hlavního aktéra tohoto projektu, kterým je otevřený domácí router vyvíjený pod interním označením „CZ.NIC router“.

Bedřich Košata

Zlatý erb přispěl k rozšíření „šestky“ a DNSSEC v českých městech a obcích

Spolu s posledním únorovým dnem skončilo rovněž krajské hodnocení webových stránek měst a obcí, které se přihlásily do již 15. ročníku soutěže Zlatý erb. Na začátku ledna jsme na našem blogu psali o novince, kterou je hodnocení podpory DNSSEC a IPv6. Za CZ.NIC jsem měl tu čest zasednout v porotě a podílet se na hodnocení jednotlivých webů. Do krajských kol soutěže o nejlepší web samosprávy se přihlásilo celkem 84 měst a 131 obcí. Nyní se pojďme podívat, jak si zúčastnění v podpoře IPv6 a DNSSEC vedli a kdo získal zvláštní cenu CZ.NIC.

Jak se hodnotilo

V rámci nové kategorie Zlatého erbu, pojmenované „Podpora IPv6 a DNSSEC“, mohli v uplynulých krajských kolech jednotliví soutěžící získat maximálně 5 bodů. Jeden bod byl přidělen těm, kteří měli svoji doménu podepsánu prostřednictvím DNSSEC, další čtyři body bylo možno obdržet za podporu IPv6, kdy se zvlášť posuzovala podpora u web serveru, name serverů a e-mailových serverů. Za podporu u každého typu serverů získali soutěžící po bodu, přičemž bylo důležité mít nejen AAAA záznam, ale i fungující služby, tedy například u WWW úspěšnou odpověď přes HTTP protokol. Pokud některý ze soutěžících pak podporoval IPv6 jak u webového serveru, name serverů i poštovního serveru, získal zvláštní, bonusový bod. Stejné hodnocení a jeho váha pak bude použita i v začínajícím celostátním kole.

Pro dokreslení celkového obrázku o hodnocení Zlatého erbu je třeba si uvědomit, že kritérium „Podpora IPv6 a DNSSEC“ představuje v krajských kolech, stejně jako v kole národním, pouze jedno z kritérií. Mezi ta další patří např. zveřejňování tzv. povinných informací, vedení elektronické úřední desky, ovládání webu či jeho přístupnost pro zdravotně postižené a další kriteria.

Kdo vyhrál?

Z celkem 215 webů, které se zúčastnily krajských kol Zlatého erbu, získalo plný počet bodů celkem „sedm statečných“, z toho překvapivě 5 obcí (Čížkov, Petrovice, Podomí, Vranov nad Dyjí a Vranovice), jedna pražská městská část (Praha 19) a jen jedno město (Úštěk). Zvláštní uznání si pak zaslouží dvě obce z Jihomoravského kraje a to Vranov nad Dyjí a Vranovice, které měly podporu IPv6 zapnutou vedle web serveru rovněž na všech name a mail serverech. V případě Vranova se jednalo o celkem 3 name servery a 2 mail servery, u Vranovic pak dokonce 4 name servery a 7 mail serverů.

Na druhou nejvyšší příčku (tj. 4 body) pak dosáhlo rovněž 7 zástupců a to obce Bělušice, Skršín, Podkopná Lhota, Pustina a městské části Praha Dolní Počernice, Satalice a Vinoř. Podpora IPv6 u nich byla vynikající, bohužel však chybělo podepsání domény přes DNSSEC. Ve třech případech bylo důvodem to, že jejich registrátor toto zabezpečení webových stránek zatím nenabízí, ve třech případech pak tím, že obce svého registrátora o zapnutí této služby nepožádaly. Jedna obec (Pustina) pak má svoje stránky umístěny na doméně .info, kde je podpora DNSSEC opět především správnou volbou registrátora.

Do celostátního kola soutěže o nejlepší web města a obce nyní postoupí vítězové jednotlivých krajských kol. Jména celkových vítězů se pak dozvíme 8. dubna 2013 na konferenci ISSS (Internet ve státní správě a samosprávě) v Hradci Králové. Vzhledem k tomu, že podpora DNSSEC a IPv6 bude hodnocena i v celostátním kole, mají města a obce ještě čas své hodnocení zlepšit. Zatím nulové hodnocení za DNSSEC získalo 77 měst a obcí, které mají své stránky umístěny na doméně .cz, přičemž 71 % z nich má svoji doménu u registrátora, který DNSSEC podporuje. Do začátku dubna je ještě poměrně dost času a zavedení podpory DNSSEC je často otázkou 5 minut. V závěrečném celorepublikovém finiši se počítá každý bod a byla by škoda o tento snadno získatelný přijít.

Jak jsou na tom ostatní města a obce?

Při pohledu na celkové výsledky je potěšující, že jak podpora IPv6, tak DNSSEC je u přihlášených soutěžících mnohem vyšší, než u ostatních měst v České republice, tak i než je celorepublikový průměr. Svoji doménu mělo přes DNSSEC podepsáno 53 % měst a obcí, IPv6 pak na svém webovém serveru podporovalo 54 % přihlášených. Ještě vyšší byla podpora u name serverů (60 %). Potěšitelná je ve srovnání s republikovým průměrem i podpora u mail serverů (18 %).

Zlaty_erb

Jiří Průša

IPv6 a DNSSEC pomohou vybrat nejlepší weby měst a obcí

Mezi zástupci měst a obcí oblíbená soutěž „Zlatý Erb“, která hodnotí nejlepší internetové stránky českých měst a obcí, letos vstupuje již do 15. ročníku. Jubilejní ročník je doprovázen rovněž jednou významnou novinkou a to novým kritériem pro hodnocení nejlepších webů. V letošním ročníku tak nebudou obecní weby posuzovány jen podle tradičních kritérií, jako je uveřejňování povinných informací, výtvarné zpracování či ovládání webu a navigace, ale nově rovněž podle podpory IPv6 a DNSSEC. Implementace těchto technologií bude hodnocena jak v krajských kolech, tak i v kole celostátním.

Hodnocení kritéria „Podpora IPv6 a DNSSEC“ bude mít na starosti naše sdružení, které všem účastníkům splňujícím nové kritérium na plný počet bodů (tj. budou mít podepsánu doménu DNSSECem a zároveň všechny jejich webové, DNS a e-mailové servery budou podporovat IPv6) věnuje zvláštní cenu. Věříme, že nové kritérium přispěje k dalšímu rozšíření nových technologií do veřejné správy (služby eGovernmentu by měly jít ostatním příkladem).

Zařazení nových kritérií je rovněž reakcí na strategii „Digitální Česko 2.0“, jejímž cílem je podpořit digitální ekonomiku a konkurenceschopnost České republiky. Na zavádění IPv6 se pak zaměřuje Usnesení vlády číslo 727 z 8. června 2009, které má pro hejtmany a pražského primátora doporučující povahu. V souvislosti se zářijovým vyčerpáním IPv4 adres potom 14. listopadu 2012 přijal Hospodářský výbor Parlamentu ČR usnesení, v němž vyzval představitele orgánů samosprávy, aby i oni zpřístupnili své elektronické služby prostřednictvím IPv6 a zahrnuli požadavky na zajištění kompatibility s IPv6 do zadání výběrových řízení.

Podle průzkumu sdružení CZ.NIC realizovaného v rámci evropského projektu GEN6 podporuje IPv6 u svých webových služeb pouze jeden krajský úřad a 9,8 % nejvýznamnějších měst a obcí (obcí s rozšířenou působností). DNSSEC má pak zapnuto pouze 30 % krajských úřadů a 26 % obcí s rozšířenou působností, což je pod celostátním průměrem (37 %).

Jiří Průša

Nové statistiky CZ.NIC

Nedávné dosažení jednoho milionu registrovaných domén v doméně .cz vyvolalo mimo jiné zvýšený zájem o statistické údaje o rychlosti růstu počtu domén, jejich využívání, atp.

Sdružení CZ.NIC dlouhodobě publikuje na svých stránkách statistické informace o české národní doméně a snaží se také reagovat na nové trendy vytvářením nových statistik, které jdou nad rámec obsahu registru. Na našich stránkách tak můžete najít nejen informace o počtu aktuálně registrovaných domén, ale také třeba o hostingu či zavádění IPv6.

Bohužel jedním z vedlejších efektů zavádění nových statistik je jejich roztříštěnost – jsou k dispozici na několika URL a v různé podobě.

Abychom tuto situaci napravili a dali návštěvníkům našich stránek lepší přehled o všech publikovaných statistikách, rozhodli jsme se je sjednotit do jedné aplikace. Ta umožní jejich snadnou a především jednotnou vizualizaci a manipulaci s nimi. Aplikace je nyní k dispozici v Beta provozu na stránkách vývojového oddělení Laboratoře CZ.NIC.

Náhled přehledu nejdůležitějších statistik

Nové statistiky obsahují úvodní grafickou stránku, kde si může návštěvník udělat rychlý přehled o aktuálním stavu nejdůležitějších statistik. V druhé části jsou pak k dispozici všechny aktuální statistické výstupy CZ.NIC roztříděné do kategorií. Všechny statistiky mají stejné uživatelské rozhraní, které umožňuje interaktivně měnit parametry zobrazení statistik, např. časové období či způsob zobrazení dat. U grafů, které obsahují větší množství sérií, je možné si ručně vybrat některé z nich a udělat si tak například přehled o vývoji počtu domén u vybraných registrátorů.

Náhled stránky jedné statistiky

Právě zobrazená data na každé stránce je možno stáhnout ve formátu CSV a stejně tak je k dispozici odkaz na právě nastavené zobrazení statistiky, který umožňuje např. snadné sdílení nebo uložení konkrétního grafu.

V současné době pracujeme na dolaďování nového systému statistik, stejně jako na jejich rozšiřování o nové výstupy. Po tuto dobu budou k dispozici jak nové, tak původní statistiky.

Doufáme, že se vám budou nové statistiky líbit a poskytnou vám větší komfort při získávání informací nejen o naší národní doméně.

Bedřich Košata

Tak už nejsme první

S počátkem vzniku technologie DNSSEC odstartovala mezi jednotlivými správci domén nejvyšší úrovně jakási neformální soutěž o to, kdo bude mít více podepsaných domén nižší úrovně. Zde je třeba připomenout, že poměrně dlouho dominovali Švédové, kteří nasadili tuto technologii jako úplně první. Na začátku roku 2010 jsme vedoucí místo získali my a díky úžasné práci našich registrátorů jsme si jej drželi až do tohoto měsíce. V české doméně je v současnosti podepsáno přes 350 tisíc domén. A ačkoliv jsme spíše čekali nový nástup Švédů, novým králem této disciplíny se stal registr Nizozemí. Holanďané mají v současnosti hodně přes půl miliónu podepsaných domén. Je to již druhá příležitost v poměrně krátké době ke gratulaci pro tuto doménu. Nedávno totiž překročili hranici 5 miliónů domén a řadí se tak k největším doménám světa.

V absolutních číslech jsme už tedy pozici ztratili, ale zatím jsme špičkou alespoň v procentuálním podílu podepsaných domén. Dovolte mi ještě jednou českým registrátorům poděkovat za úctyhodných 37 % podepsaných domén. Jen tak dál, snad brzy překročíme i těch magických 50 % a počet podepsaných domén převýší počet těch nezabezpečených.

Ondřej Filip

Slabé RSA kľúče v TLS a DNSSEC

Praktických dôkazov, že RSA kľúče s modulum menším 1024 bitov (špeciálne 512-bitových) môžu predstavovať bezpečnostné riziko, sa za posledný rok objavilo viacero. Autori malware zneužili slabé 512-bitové RSA kľúče z certifikátov, ktoré mali vhodnú kombináciu X.509v3 extensions a podpisovali nimi malware. Útočníci v tomto prípade pravdepodobne faktorizovali modulus a získali tak privátny kľúč. Výskumníci tiež ukázali, že „okamžitá“ faktorizácia 512-bit RSA modulu je uskutočniteľná a relatívne lacná (menej než cca $150).

Aj keď to boli najskôr posledné X.509 certifikáty zneužiteľné na podpis kódu (ostatné známe sme našli a sú revokované), stále existuje mnoho serverov, ktoré posielajú 512-bitové certifikáty v TLS handshake, napríklad pri naväzovaní HTTPS komunikácie. Doporučené veľkosti kľúčov k rôznym algoritmom uvádza prehľadná tabuľka vychádzajúca z doporučení ECRYPT II (podrobný popis ako sa k hodnotám dostali obsahuje objemný ECRYPT II Yearly Report on Algorithms and Keysizes 2011).

Našťastie od júla 2012 platia nové požiadavky CAB fóra na certifikáty vydávané od CA – už nesmú mať RSA moduly menšie než 1024 bitov, naviac tie s dlhodobou platnosťou musia mať modulus veľkosti aspoň 2048 bitov. Microsoft tiež čoskoro začne blokovať certifikáty s RSA modulom menším než 1024 bitov. Zmeny k lepšiemu je už vidieť ako postupne CA revokujú staršie certifikáty so slabými RSA modulmi, ale stále sa občas nejaký 512-bit nájde.

Podobný problém so slabými RSA sa samozrejme netýka len TLS komunikácie, ale môže nastať tiež v DNSSEC. Ak útočník kľúč faktorizuje, môže pri man-in-the-middle útoku na DNSSEC falšovať podpisy DNS záznamov (tým pádom aj prípadne meniť asociácie na kľúče a certifikáty pinované cez záznamy typu SSHFP alebo TLSA).

Ako to vyzerá s RSA kľúčmi v doméne CZ? Keď sme robili prieskum DNSSEC kľúčov používaných v doméne .CZ pred pol rokom, tak domén s DNSSEC kľúčom s RSA modulom menším než 1024 bitov bolo mnoho (rádovo stotisíc), pri teste 20. júla 2012 už je ich zásadne menej:

  • domén s kľúčom menším ako 1023 bitov: 6635
  • unikátnych kľúčov so slabým modulom: 5209
  • v dvoch prípadoch sa jedná o Key Signing Key, zbytok sú Zone Signing Keys; jeden z týchto KSK už nie je používaný (ale je v zóne)
  • päť kľúčov má 768-bit modulus, zbytok 512-bit
  • jedna doména má kľúč so slabým verejným exponentom (3)
  • existuje jeden revokovaný DNSKEY RSA kľúč s malým modulom

Pre porovnanie veľkosti kľúča a periódy zmeny ZSK odkážem na blog Erica Rescorlu, kde ukazuje, že priame použitie silnejšieho kľúča prináša lepšiu bezpečnosť než častá zmena (key rollover).

Súčasné doporučenia pre KSK a ZSK RSA kľúče znejú:

  • KSK  2048 bitov
  • ZSK  1024 bitov
  • verejný exponent 65537 (0x10001 hex)

Uvedené hodnoty sú minimálne. Tu zase platí, že ani s veľkosťou kľúčov to netreba preháňat – príliš veľké moduly alebo exponenty majú za následok spomalenie overovania RSA podpisu.

Poznámka na koniec: Teoreticky verejný exponent môže byť aj menší (napr. 3), vyšší exponent ale bráni proti implementačným chybám umožňujúcim varianty Bleichenbacherovho útoku (u schém používajícich PKCS#1 v1.5 RSA padding, stalo sa nedávno u openssl – netýkalo sa SSL/TLS, ale CMS).

Ondrej Mikle

Další klíčky změnily svá zabarvení

Důležitá oznámení o zavedení DNSSEC jsme naposledy zaznamenali na konci loňského roku a týkaly se Vodafone a Telefónicy. Od té doby se žádná společnost nepochlubila, až do dnešního dne.

Centrum Holdings dnes vydalo tiskovou zprávu, ve které oznamuje zavedení DNSSEC pro řadu svých webů, mezi které patří například Centrum.cz, Aktuálně.cz nebo katalog firem Najisto.cz. Rádi se přiznáme k tomu, že tuto implementaci vítáme hned dvakrát. Typicky přesně tyto služby si totiž DNSSEC zaslouží.

Druhým přírůstkem do rodiny je potom portál Bezpečnostní informační služby – www.bis.cz. Podepsána je tedy internetová stránka dalšího významného státního úřadu a co víc, první z bezpečnostních sborů v naší zemi.

A pár čísel na závěr, pro připomenutí. DNSSEC je tu s námi od podzimu 2008, kdy se Česká republika stala teprve pátou zemí na světě, která tuto bezpečnostní technologii do své národní domény zavedla. V současnosti chrání DNSSEC 343 478 domén .cz, což je více než třetina z celkového počtu zaregistrovaných domén s českou národní koncovkou. Tato čísla nás udržují nad ostatními registry domén využívající DNSSEC.

Vilém Sládek

333333 podepsaných domén a velká sázka o malé pivo

Nedávno překročil počet podepsaných domén v .cz magickou hranici 333 333, což je rozhodně důvod ke spokojenosti. Naše národní doména si v penetraci tohoto zabezpečení drží stále první příčku na světě. Skvělé je, že k těmto počtům nepřispívají pouze doménoví registrátoři, kteří automaticky podepisují všechny domény s jejich nameservery, ale že se připojují i firemní koncoví držitelé. Podívejme se třeba na média – iHNed.cz, Lidovky.cz, všechny servery Internet Info. Důležitý je i přístup státní správy a v tomto mi například naposledy udělal radost Český telekomunikační úřad, který nedávno podepsal obě své domény. A rozhodně je důležité, že začali validovat i velcí telekomunikační operátoři.

Nicméně naše prvenství už není tak suverénní jako dříve. Velmi silně se probudila země, která jako první DNSSEC implementovala, tedy Švédsko. Tamní registr velmi tlačí na své registrátory a ti už dokázali podepsat zhruba 180 tisíc domén. V poslední době to maličko spadlo, protože jeden registrátor migruje na novou technickou platformu, ale i tak mají téměř 150 tisíc.

Povzbuzen tímto úspěchem se mi nedávno ozval ředitel .SE, Dany Aerts (mimochodem ač spravuje švédskou doménu, je to původem Nizozemec) a navrhl mi, že se vsadíme o to, kdo bude mít do konce roku vyšší procento podepsaných domén. Kdo prohraje platí tomu druhému národní pivo. Pravda, nejsem velkým fanouškem švédských piv, ale na druhou stranu jsem soutěživý človek, takže jsem sázku přijal :-). Čili sázka je na světě, a tak se na vás správce, registrátory a všechny, co mohou něco udělat, obracím s prosbou: pojďte zavést DNSSEC a pomozte mi toto holandského Švéda pokořit!!! Kdo mi pomůže nejvíce, toho zvu na české pivo na oplátku zase já.

Ondřej Filip

Liberální nebo striktní? A co na to All Blacks?

Když John Postel v roce 1980 definoval pravidlo robustnosti (známé také jako Postelův zákon), tak se zdálo být rozumné jej definovat jako: „Buď liberální v tom, co přijímáš, ale buď striktní v tom, co vysíláš.“ O pár let později bylo toto pravidlo rozšířeno v RFC 1122 o požadavek nejen přežít divoké prostředí špatně naformátovaných paketů, ale také nadále spolupracovat a komunikovat s implementacemi, které se takto neslušně chovají. Internet byl ve svých počátcích a bylo těžké odhadovat, jaká všechna zařízení budou do sítě připojena a jak dobře nebo špatně budou naprogramována.

Nicméně zpátky k návrhu internetových protokolů. Již o deset let později v roce 2001 popisuje Marshall Rose v RFC 3117 problémy, které přináší aplikace principu robustnosti do interoperability aplikací. Představte si, že máme dvě implementace:

  • implementaci Locke, kterou psal hodně šikovný programátor a docela si s ní vyhrál, takže je velmi liberální a dokáže přijmout a zpracovat libovolně naformátovaný paket a…
  • implementaci Demosthenes, kterou psal programátor hodně ve spěchu a posílá takové pakety, ze kterých se dělá trochu špatně i směrovačům po cestě.

Locke si s Démosthenem v klidu dokáží povídat. Locke se sice občas diví, co to Démosthenés říká, ale vcelku dobře si rozumějí a komunikace volně plyne. To se ovšem radikálně mění ve chvíli, kdy na scénu přichází implementace Rochester, kde byl programátor velmi striktní a naprogramoval Rochestera tak, že přesně odpovídá specifikaci protokolu a odmítá jakékoli odchylky od standardu, zatímco si Locke s Rochesterem může bez problému popovídat (ostatně jsou oba dva angličané). Dokonce pro Lockeho je komunikace s Rochesterem jednodušší, protože oba dva při komunikaci dodržují správný komunikační protokol. Naopak Démosthenés má se svou antickou řečtinou najednou problém. Démosthenés se může snažit mluvit s Rochesterem jak chce, ale ten mu prostě nemůže rozumět, protože nemluví společným jazykem.

A co by na to řekli All Blacks? Kdyby se o Postelově zákonu dozvěděli v půlce prosince minulého roku, tak by asi zareagovali takto:

Proč? Správci novozélandské domény .NZ v půlce prosince dokončili proces implementace DNSSEC, vypublikovali správný klíč a poslali jej do kořenové zóny. Následně byli upozorněni, že jejich klíč má nezvyklou sekvenci znaků v místě, kde je uveden RSA exponent. Pro srovnání si tento rozdíl pojďme ukázat konkrétně.

Klíč pro doménu .CZ vypadá takto:


cz.	     IN DNSKEY 257 3 10 (
		AwEAAaVU8EMQrZ6Tix2zBaAmizMQ7W0m94qSJUXV4eVW
		S9ZpXh9t1uj8U/B5Nnqge4G0Te0/NJIqflihZKXs8Hyh
		JqjF852RKnvNWPu2wMujYjHP0T4lIhu4rTym9+sPNsfi
		oqvMyyDeqyhVPx21nvLW5oaKjaLd3XJxijRbDTddRU97
		mJVVS50PKdDmh5n/4KdRKV7ifR2Ap8L1bvUiCOxl4GAq
		LoXft+L896bkVj6mefdCSyYaCbgsDc2+10ZBOSF1t89N
		J6O1yO+y5/7vS3dYKEqj+p4ygaCY0spvrhZxncUeASix
		g224bNYZM5TLk2/YoKgAEjaIoCwu7SAXB5iUvLU=
		) ; key id = 14568

Pokud rozkódujeme prvních pár znaků, dostaneme následující výstup:

$ dig dnskey cz +short | grep '^257' | awk '{print $4}' | base64 -d | xxd -l 12 -b
0000000: 00000011 00000001 00000000 00000001 10100101 01010100  .....T
0000006: 11110000 01000011 00010000 10101101 10011110 10010011  .C....

Délka exponentu je uvedena na prvním místě (00000011), tj. exponent je dlouhý tři bajty. Exponent je v tomto případě 65537 (00000001 00000000 00000001).

DNSSEC klíč pro novozélandskou doménu vypadal takto:

nz.          IN DNSKEY 257 3 8 (
                BAABAAGwfTiEoh71o6S55+Mdy1qqVRnpKY1VHznrv+wx
                rPfvRGB5VivFFPFN+33fsaTxJQTceOtOna7IKxTffj6p
                bBG4a9vtk2FqF551IwXomKWJnzRVKqYzuAx+Os/5gLIN
                BH7+qRWAkJwCdQXIaJGyGmshkO5Ci5Ex5Cm3EZCeVrie
                0fLI03Ufjuhi6IJ7gLzjEWw84faLIxWHEj8w0UVcXfaI
                2VL0oUC/R+9RaO7BJKv93ZqoZhTOSg9nH51qfubbK6FM
                svOWEyVcUNE6NESYEbuCiUByKfxanvzzYUUCzmm+JwV7
                7Ebj3XZSBnWnA2ylLXQ4+HD84rnqb1SgGXu9HZYn
                ) ; key id = 2517

Opět rozkódujeme prvních pár bajtů:

dig dnskey nz +short | grep '^257' | awk '{print $4}' | base64 -d | xxd
-l 12 -b
0000000: 00000100 00000000 00000001 00000000 00000001 10110000  ......
0000006: 01111101 00111000 10000100 10100010 00011110 11110101  }8....

Již na první pohled je vidět, že exponent je v tomto případě delší (00000100), tj. 4 bajty. Nicméně hodnota exponentu (00000000 00000001 00000000 00000001) zůstává stejná, tedy rovna 65537.

V čem je tedy zádrhel? Dle standardu RFC 3110, který definuje kódování RSA klíčů pro použití v DNS, jsou počáteční nuly v exponentu zakázány. A nyní se dostáváme zpátky k počátečnímu sporu Postel vs Rose.

Správci novozélandské domény samozřejmě nasazení DNSSEC klíče pečlivě otestovali a vše správně fungovalo. Jinými slovy Démosthenés si při testování povídal s Lockem. Nakonec se bohužel ukázalo, že na scéně se skrýval Rochester v podobě implementace rekurzivního resolveru od firmy Nominum, která je při dekódování exponentu velmi striktní a po přijetí klíče novozélandské domény selhala při DNSSEC validaci. Toto nakonec vedlo k tomu, že bylo zapotřebí klíč novozélandské domény opravit a do kořenové zóny poslat klíč ve správném kódování.

Jaké z toho nakonec plyne poučení? Druhá část pravidla robustnosti stále platí, je zapotřebí být velmi striktní při implementaci protokolu, aby byla zajištěna dobrá interoperabilita. Nicméně je jistě ke zvážení, jestli nebýt striktní také při implementaci přijímací části, aby bylo možné odhalit chyby včas již při testování.

A co si myslíte vy? Je lepší být v implementaci striktní nebo liberální?

Ondřej Surý

P.S. Tento článek, respektive odkaz na něj, zahajuje naši komunikaci na Google Plus. Pokud tedy tuto sociální síť využíváte a chcete být informováni o našich projektech a aktivitách, přidejte si nás do svých kruhů.

Statistika DNSSEC resolverů

Jako správce české domény máme poměrně dobrý přehled o tom, kolik existuje zabezpečených domén s koncovkou .CZ. Jak to ale vypadá na druhé straně?

Samotné měření toho, kolik je validujících resolverů, není bohužel jednoduchá záležitost. Žádný resolver nehlásí autoritativnímu serveru „já jsem validující“, takže pro detekci lze použít nepřímé techniky, které využívají znalost toho, jakým způsobem validující resolver žádá o DNS záznamy. Asi nejkomplexnější metodu měření navrhl Olafur Gudmundsson a Steve Crocker na konferenci SATIN 2011; popsanou ji najdete v článku Guðmundsson, Crocker: Observing DNSSEC validation in the wild. Tuto metodiku jsme použili pro naše měření. Kromě toho, že nemá smysl znovu vynalézat kolo, je jednotná metodika také důležitá pro srovnání s ostatními registry. V případě, že by každý registr vynalézal znovu a znovu metodiku měření validujících resolverů, bylo by následné porovnávání výsledků příslovečným porovnáváním jablek s hruškami.

Stručné shrnutí metodiky:

Pro zjednodušení bereme jednu IP adresu za jeden resolver, i když ve skutečnosti se za jednou IP adresou může v případě NATu skrývat více resolverů.

Pro detekci validujících resolverů se metodika snaží hledat odlišnosti mezi chováním „zastaralých“, tedy nevalidujících resolverů, a těch validujících. Ty se liší především dotazy na DS a DNSKEY záznamy:

  1. dotaz na DS záznam – resolver označíme jako určitě validující
  2. opakovaný dotaz na DNSKEY záznam v časových intervalech odpovídající době platnosti (TTL) tohoto záznamu – resolver také označíme jako určitě validující
  3. samostatný dotaz na DNSKEY záznam – resolver označíme jako pravděpodobně validující

Z charakteru protokolu DNS vyplývá, že není možné, aby byla tato metodika absolutně spolehlivá. K jistému zjednodušení dochází proto, protože na straně autoritativního serveru není možné poznat, zda-li položený dotaz na DS nebo DNSKEY záznam vznikl na základě požadavku na validaci nebo jej vznesl nějaký testovací nebo monitorovací skript. Ke zkreslení výsledků přispívají i lidé, kteří prostými dotazy pomocí různých DNS nástrojů mohou způsobit zařazení IP adresy do jedné z výše uvedených kategorií. Podrobnější diskuzi nad použitou metodikou lze nalézt ve výše zmíněném článku.

Nejprve uvedeme výsledky měření z dubna 2011 a pak pro porovnání z prosince 2011. Měření se provádělo vždy tři pracovní dny na stejných autoritativních serverech.

Data z dubna 2011

Dle popsané metodiky jsme v našich DNS datech našli 6767 určitě a 727 pravděpodobně validujících resolverů. Vzhledem k tomu, že většina provozovatelů DNS serverů nemá ve svých sítích pouze jeden server, tak jsme získané IP adresy následně museli ručně agregovat na základě vlastníka IP adresy serveru. Toto seskupení představuje další zjednodušení, které ovšem v případě resolverů s největším provozem můžeme zanedbat.

V následující tabulce naleznete top 10 českých společností jejichž sítě provozují validující resolvery (podle počtu DNSKEY dotazů zaslaných z validujících resolverů).

#DNSKEY   ISP
  5320    Casablanca
  4224    České Radiokomunikace
  3024    Telefónica O2
  2089    GTS NOVERA
  1624    UPL Telecom
  1338    NFX
   710    OMEGA tech
   537    Dial Telecom
   513    Ignum
   441    VUT Brno

Data z prosince 2011

Počet validujících resolverů se zvýšil: evidujeme 11403 určitě a 1201 pravděpodobně validujících resolverů.

Pořadí top 10 českých společností počtu DNSKEY dotazů z validujících resolverů se mírně promíchalo:

#DNSKEY   ISP
  7894    Telefónica O2
  6309    Vodafone
  4342    ACTIVE 24
  3441    UPC
  3285    GTS NOVERA
  3075    RIOMEDIA
  2712    2 connect
  2029    T-Mobile
  1946    Casablanca
  1737    CESNET

Pokud by vás zajímalo, zda váš ISP validuje, podívejte se na www.dnssec.cz, kde najdete jednoduchý a průkazný test. V komentářích nám potom můžete napsat, jak jste uspěli či neuspěli, kdo má nebo nemá zájem na větším bezpečí svých zákazníků.

Ondřej Mikle