O tom, že Česká republika patří při zavádění IPv6 minimálně mezi evropské lídry, jsme psali již několikrát; aktuální statistiky vytvářené na základě 500 nejnavštěvovanějších stránek poskytuje např. IPv6 Observatory.
V rámci evropského projektu GEN6 pak CZ.NIC monitoruje připravenost veřejné správy na IPv6. Zde dosavadní výsledky opět potvrzují vedoucí postavení České republiky. Na žádost Ministerstva průmyslu a obchodu jsme nyní náš průzkum rozšířili o analýzu TOP100 firem (dle obratu). Výsledky „tahounů“ českého hospodářství celkem překvapivě ukázaly, že IPv6 nepatří ve velkých firmách mezi favority a na svých webových serverech ji podporuje jen 5 společností ze 100. Jak ukazuje následující tabulka, o poznání lepší není situace ani u jmenných a poštovních serverů.
| Webové servery | DNS servery | E-mailové servery | |
| Veřejná správa | 28,4 % | 50,4 % | 10,4 % |
| TOP100 firem | 5,0 % | 44,0 % | 5,0 % |
| Průměr za doménu .cz | 19,2 % | 54,7 % | 16,2 % |
Výše uvedené srovnání ukazuje, že při zavádění IPv6 jsou nejvýznamnější firmy jak pod celostátním průměrem, tak daleko za veřejnou správou. Zklamáním je, že IPv6 příliš nepodporují na svých stránkách ani technologické firmy jako T-Mobile, Vodafone či Česká pošta, která se snaží působit jako státní integrátor v oblasti IT. Jedinou společností z TOP100, která podporuje IPv6 jak na svých webových, tak jmenných a poštovních serverech je pak trochu překvapivě Sokolovská uhelná.
Jiří Průša
Generace Y? Ne! Generace DNS!
Generace Y je termín, který používají sociologové pro populaci, která se narodila na začátku 80. let a tedy vyrůstala převážně v době, kdy už byly dostupné mnohé moderní technologie včetně Internetu. A jelikož úplně první standardy, definující protokol DNS, RFC 882 a RFC 883 vznikly v listopadu 1983, tedy akorát před třiceti lety, dala by se Generace Y s trochou nadsázky označit také termínem Generace DNS.
Ať už patříte ke Generaci X, Y nebo Z, tak v každém případě si s námi můžete tuto sobotu DNS připomenout a to na konferenci Internet a Technologie 13.2, kde mu bude patřit celý jeden blok. Kapacita v sále je už delší dobu vyčerpána, ale pokud byste měli zájem, živý přenos z akce začne přibližně v 9:20.
Ondřej Surý
Školy mají o spolupráci s CZ.NIC zájem
22 akcí pro školy základní, střední i vysoké a 820 studentů a pedagogů. I tak vypadal rok 2013 z pohledu Akademie CZ.NIC. Spolupráce se školami na podpoře internetové gramotnosti studentů i učitelů u nás představuje klíčovou součást vzdělávacích projektů a jsme rádi, že je o ni rok od roku vyšší zájem.
Letos jsme se na českých školách nejvíce věnovali z našeho pohledu již tradičním tématům jako IPv6, DNS, bezpečnosti na Internetu apod. Ale přibyla i nová, třeba přístupnost webů.
Té se naposledy věnoval kolega Petr Závodský, vedoucí týmu testerů CZ.NIC, na přednášce určené studentům ČVUT, kteří navštěvují předmětu Asistivní technologie. Měla takový úspěch, že se vyučující rozhodl obsah přednášky začlenit do sylabu předmětu. A to je pro nás vždy ta nejlepší odměna.
A pokud by snad problematika přístupnosti webu pro uživatele se zrakovým, sluchovým, pohybovým omezením nebo duševním onemocněním apod. zaujala i čtenáře našeho blogu, napište nám na akademie@nic.cz. Pokud bude dostatek zájemců, připravíme pro vás speciální kurz s touto tematikou.
Vilém Sládek
Změna je život Aneb .blog mění název
V lednu 2008 jste si na této stránce mohli přečíst první příspěvek, který nebyl o ničem jiném, než o tom, že začínáme s blogováním. Stránce jsme dali název „.blog“, a to z pochopitelných důvodů – tečka je náš hlavní symbol, symbol doménového světa. Díky zásahu ICANNu :) o tento název nyní přicházíme. V rámci vzniku nových gTLD se totiž již brzy rozšíří doménový prostor o doménu nejvyššího řádu, která ponese stejný název. Podobně se budeme muset na začátku příštího roku postavit i k našemu, ještě staršímu, newsletteru „.news“. I tato doména prvního řádu prošla schvalovacím procesem a čeká na svoji delegaci.
S novým názvem – CZ.NIC blog – samozřejmě nesouvisí změna naší „redakční politiky“. Nadále vás na těchto stránkách budeme informovat o novinkách ze světa domén, doménových technologií, Internetu, a to tak, jak je vidí zaměstnanci sdružení. Pracujeme také na novém designu, který by se měl ukázat v nejbližší době. Zachovejte nám tedy přízeň i do budoucna. Děkujeme za ni.
Vilém Sládek
Brusel mírní návrh na regulaci SSL certifikátů
Je tomu již více než rok, co jsem zde psal o snaze Evropské komise regulovat pod hlavičkou revize rámce pro elektronické podpisy a eID (tzv. eIDAS) rovněž oblast certifikátů pro webové stránky, tzv. SSL certifikátů. O tom, že projednávání návrhu tohoto nařízení bude běh na dlouhou trať, svědčí mimo jiné to, že i po roce a půl od jeho představení jsme stále daleko od jeho schválení. To se v ideálním případě očekává až před volbami do Evropského parlamentu, tj. v květnu 2014, s tím, že v platnost by tato, pro členské státy přímo účinná, legislativa vstoupila v platnost 1. ledna 2015.
V rámci projednávání návrhu na půdě Rady byla Česká republika mezi těmi, kteří hned na úvod projednávání nesouhlasili s rozšířením současné regulace rovněž o SSL certifikáty s tím, že postupně se k nám přidaly další státy. V současné době litevské předsednictví dokonce navrhuje vypuštění textu, jisté zmírnění požaduje rovněž Evropský parlament, konkrétně výbor ITRE (Výbor pro průmyslu, dopravu, výzkum a energetiku). Ten na svém říjnovém zasedání navrhl (viz tučný text) zohlednit rovněž zapojení internetové komunity (skrývající se v euro-slangu pod pojmem stakeholders) a vypracování analýzy dopadu.
|
Article 37 Requirements for qualified certificates for website authentication
|
Ponechme nyní stranou, zda by evropská legislativa měla obsahovat spojení jako „nejlépe“ (preferably) a raději se zaměřme na zohlednění zájmu internetové komunity. Text totiž v tomto ohledu hovoří o jejím zapojení, na druhou stranu však Evropská komise „znovu vynalézá“ kolo, když se v příloze č. IV snaží definovat obsahové náležitosti SSL certifikátů. Na tomto místě by však měla být zohledněna práce IETF a již existující RFC (Request For Comments), které jsou v prostředí Internetu obdobou klasických standardů.
Zmiňovaným SSL certifikátům se věnuje zejm. RFC 5246 a RFC 3039, které definuje mj. obsah certifikátů, tj. tu samou věc, o kterou se Komise snaží v příloze IV. Na tuto skutečnost upozornil na svém říjnovém zasedání rovněž RIPE, který svoji pozici vyjádřil v dopise adresovaném Evropskému parlamentu.
V rámci nadcházejících jednání bude důležité, aby se členské státy za návrh Předsednictví postavily, při jednání s Evropský parlamentem i Komisí regulaci certifikátů jasně odmítly a podpořily tím principy správy Internetu i dosavadní práce na IETF.
Jiří Průša
Služba CAPTCHA Help se dočkala řady změn
Službu CAPTCHA Help provozuje CZ.NIC od srpna tohoto roku. Za tuto poměrně krátkou dobu si už ale stihla najít své věrné uživatele; těch je aktuálně více než 200 a stále přibývají. Když k tomu přidáme cca 10 vyřízených požadavků týdně, můžeme směle tvrdit, že si své místo a zájemce našla. A právě proto, že se služba ukazuje jako perspektivní, pracují vývojáři na jejím vylepšování.
Vývojáři proto nedávno zveřejnili dokument nazvaný S CAPTCHA Help doplňkem o krok dál. Ten je rozdělený do jednotlivých kapitol – Instalace, Nastavení a Použití, předposlední díl je potom věnovaný roli operátora a poslední budoucnosti. V této závěrečné části vývojář Petr Závodský kromě jiného píše: „Ke službě CAPTCHA Help velice brzy přibudou doplňky pro další prohlížeče: Internet Explorer, Mozilla Firefox, Safari. Doplňky prohlížečů chceme také vylepšit o některé další funkcionality, např. dát uživateli možnost zvolit si rozsah screenované části kolem CAPTCHA obrázku. Služba bude také postupně optimalizovaná tak, aby uživatel obdržel odpověď do několika desítek sekund. CAPTCHA Help také začínají využívat zahraniční uživatelé a i na ně se proto postupně začínáme zaměřovat.“
Celý dokument je proložen řadou obrázků a postupů, jak se službou efektivně pracovat. Měl by tedy bez problémů posloužit všem, kteří se chystají nové funkcionality využívat.
Vilém Sládek
Videorozhovor pro ISOC: Jaromír Talíř představuje Knot DNS
V ISOC existuje projekt Deploy 360 Programm, který si klade za cíl překlenout propast mezi IETF standardy a jejich zavedením do praxe. Deploy360 Programm je zaměřený například na IPv6, DNSSEC nebo routing. V jeho rámci má na internetových stránkách ISOCu své místo také náš Knot DNS.
Tuto záložku nedávno rozšířila prezentace kolegy Jaromíra Talíře z poslední konference ENOG, která se týkala mimo jiné také toho, že připravovaná verze Knot DNS (1.4.0) bude umět podepisování DNSSEC. Na záložce najdete vedle ní také rozhovor s Danem Yorkem, o který se s vámi rádi podělíme i na našem blogu:
Vilém Sládek
Laboratoře CZ.NIC odhalily závažnou zranitelnost linuxového jádra
V rámci vývoje a testování softwaru pro nový router CZ.NICu Turris jsme objevili nebezpečnou chybu v linuxovém jádře, která umožňuje vzdáleně způsobit kernel panic; pád jádra lze vyvolat posláním vhodně zformátovaných IPv6 fragmentů. Podle našeho názoru má chyba potenciál na DoS útoky.
Ve skutečnosti se jedná o dvě chyby v různých částech Linuxového jádra, které mohou nastat při zpracování IPv6 datagramu s nekorektně vyplněným fragmentation headerem. První chyba je známá od května 2011 pod označením CVE-2011-1927 a byla opravena ve verzi 2.6.38.9 linuxového jádra. Nyní došlo k pravděpodobné regresi této chyby v aktuálních jádrech počínaje verzí 3.11 a v mailinglistu vývojářů síťových driverů a TCP/IP stacku už je k dispozici patch, který tuto chybu opravuje. Oprava bude pravděpodobně začleněna do nejbližší budoucí udržovací verze jádra.
Druhá chyba, která dosud nebyla známá, se netýká samotného sestavování fragmentů k předání vyšší vrstvě síťového modelu, ale týká se Netfilteru – Linuxového firewallu, který sestavuje IP packety (IPv4 i IPv6) jen virtuálně, aby o nich mohl rozhodnout podle pravidel v INPUT resp. FORWARD chainech v tabulce filter. Problém, na který jsme v Laboratořích CZ.NIC narazili je, že překrývající se fragmenty můžou vyvolat kernel panic za podmínky, že dochází k pokusu o virtuální sestavení datagramu a to pravděpodobně z velmi podobných důvodů, jako v případě první chyby.
Chybu jsme reportovali v mailinglistu a spolupracujeme na vytvoření patche s vývojáři Linuxového TCP/IP stacku a Netfilteru.
Tomáš Hlaváček
Pomsta za Internet?
Síťové sekci konference Intel European Research and Innovation Conference 2013 (program) jednoznačně vévodily dvě zkratky: SDN (Software Defined Networking) a NFV (Network Functions Virtualization). O SDN jsem už na tomto místě psal a na další příspěvek se chystám v souvislosti s účastí CZ.NIC v FP7 projektu NetIDE.
O virtualizaci síťových funkcí přednášeli především zástupci velkých telekomunikačních operátorů (Telefónica, Verizon) a firem, které jim navrhují infrastrukturu a dodávají služby. Mně osobně daly jejich příspěvky možnost nahlédnout pod pokličku sítí 4G LTE, o nichž, přiznám se, jsem toho dosud mnoho nevěděl. Ne že bych byl teď o mnoho moudřejší, ale jeden základní dojem jsem si přece jenom odnesl – tyhle sítě jsou v porovnání se standardním Internetem pekelně složité. Už jen ta záplava zkratek, namátkou: OSS, BSS, HSS, MME, PCRF, OTT, BRAS, SGSN, GGSN, VAS … Virtualizace je pak celkem pochopitelně jednou z cest, jak tento moloch zvládnout.
Přemýšlel jsem o tom, kde se ta složitost vlastně bere. Zčásti jde jistě na vrub známých nedostatků v reálném Internetu, jakými jsou třeba nefungující multicast či chabá podpora mobility. Hlubším důvodem je ale podle mého známý end-to-end princip, na němž jsou protokoly TCP/IP postaveny, tedy v podstatě hloupá a ne zcela spolehlivá síť, jež funguje díky tomu, že pokročilejší funkce jsou soustředěny v koncových stanicích. Je jasné, že v takové best-effort síti je obtížné nabízet zákazníkům diferencované služby a podle toho je pak také kasírovat.
Když tedy technologičtí experti předestírají vize budoucího Internetu jakožto sítě chytrých telefonů a jiných mobilních zařízení, musíme si uvědomit, že se nejedná jen o osvobození od kabelů, ale dost možná taky o podstatné změny v architektuře globální sítě – bude to vlastně ještě Internet, jak jej dnes známe?
Ladislav Lhotka
Nový projekt: DNS Collector sbírá a analyzuje provoz v DNS
Primární účel DNS (Domain Name System) je zprostředkovat překlad doménových jmen na adresy v síti. Ve zjednodušené formě – klient generuje dotazy a server poskytuje odpovědi. Jako takový tvoří DNS jednu z důležitých služeb v IP sítích. Ve většině případů začíná komunikace na internetu právě DNS dotazem. Stopy této komunikace lze nalézt na různých úrovních DNS hierarchie. Analýzou těchto stop (DNS dotazů) lze získat užitečné informace o stavu sítě a chování jejích uživatelů.
Sběr DNS dat
DNS provoz je potřeba extrahovat z celkového síťového provozu. Převážná část DNS provozu je přenášena nefragmentovanými UDP pakety. Abychom získali pokud možno celistvý pohled na přenášená data, je nutné u zbylého provozu provést defragmentaci paketů a provést rekonstrukci TCP spojení. Je také nutné se vypořádat s poškozenými pakety nebo nedokončenými datovými přenosy.
V DNS provozu na serverech obsluhujících .cz TLD převládá síťový protokol IPv4. V závislosti na objemu provozu a umístění serveru se jeho zastoupení pohybuje kolem 90 %. Výjimku tvoří server akuma, umístěný v Japonsku, u kterého je poměr IPv4/IPv6 převrácený. Na transportní vrstvě dominuje UDP.
Aplikace DNS Collector zjednodušuje zpracování DNS provozu tím, že je schopna poslouchat provoz na několika síťových rozhraních současně. V současné době k tomu využívá knihovnu libpcap. Zachycený síťový provoz je defragmentován. V případě TCP provozu je sledováno správné ustanovení a ukončení TCP relace. Přerušená TCP spojení nebo neúplné pakety jsou po čase zahozeny. Zrekonstruované surové (tak jak jsou přenášené po síti) DNS pakety jsou v závislosti na použité síťové a transportní vrstvě opatřeny daty z IPv4/IPv6 a UDP/TCP hlaviček. Takto připravená data jsou předána ke zpracování do modulů.
DNS Collector umožňuje zpracovávat také archivovaný provoz uložený v souborech na disku (ve formátu podporovaném knihovnou libpcap). V tom případě pak ale není možné současně zpracovávat archivovaný provoz s živým provozem ze síťových rozhraní. V současné době také není také možné zpracovávat více archivů (souborů) současně, protože doposud nebyl implementován mechanismus řazení paketů podle časových značek uložených v souborech. V případě, že je potřeba zpracovat více archivů současně, je nutné použít externí aplikaci jako je například mergecap nebo PCAPMerger.
Zpracování provozu v modulech
Modul je funkční jednotka, která se zabývá zpracováním surových DNS dat. Tyto data mu připravuje DNS Collector způsobem zmíněným v předcházející části. Moduly představují funkční abstrakci, umožňující izolovat jednotlivé činnosti nad DNS daty. Moduly si udržují vlastní kontexty, mohou tedy pracovat nezávisle na ostatních modulech.
Moduly lze nahrávat nebo uvolňovat za běhu celé aplikace. V porovnání se samostatnými aplikacemi provádějícími ekvivalentní činnost mají moduly výhodu menší režie. Všechny moduly totiž společně sdílí společnou vrstvu, která se stará o přípravu vstupních dat. Tato vrstva by v případě samostatných procesů musela existovat ve všech procesech.
DNS Collector neposkytuje žádné rozhraní pro parsování surových DNS dat. V závislosti na povaze zpracovávaných dat je možné implementovat vlastní jednoduchý parser DNS paketu, nebo v případě složitějších operací použít některou z existujících knihoven, jako je například ldns.
Detektor anomálií
Tento modul vychází ze samostatného projektu detektoru DNS anomálií. Původní samostatná aplikace prováděla statistickou analýzu části DNS provozu, která byla dostupná v úplných UDP paketech. Na základě vzájemné podobnosti zjištěných vzorů pak posuzovala, zda je provoz „normální“. Je nutné upozornit, že se jedná o hodnocení ve smyslu: normální je převažující chování. V tomto smyslu anomálie nemusí být nutně škodlivé, pouze se něčím vymykají charakteristice většiny. Díky použití v DNS Collectoru je možné zpracovávat data pocházející z fragmentovaných paketů a dat přenášených přes TCP.
Výstupem tohoto modulu je textové hlášení o detekovaných anomálních identifikátorech. Volitelným výstupem jsou soubory vykreslující výskyt detekovaných anomálií ve formátu vhodném pro zpracování gnuplotem.
Na následujících obrázcích je ukázka několika typů detekovaných anomálií. Data byla zachytávána a analyzována v desetiminutových intervalech 1. října na serveru dns-b-01. Grafy zobrazují zastoupení anomálního provozu v poměru k celkovém provozu. IP adresy jsou záměrně nahrazeny.
Na grafech je zobrazeno zastoupení provozu označeného jako anomální:
IP A – hromadné rozesílání emailů, provoz obsahuje dotazy na MX a adresy mailserverů
IP B – opakovaný dotaz se stejným ID v krátkém intervalu (300x během 2ms)
IP C, D, F, G – rekurzivní resolvery
IP E – DKIM spam-filter
IP H – opakované dotazy na adresy tří nameserverů, postupně se zvyšující ID dotazů
Spouštění skriptů v Pythonu
Ne každá analýza si zaslouží samostatný modul psaný v C. V případech, kdy není jisté, zda bude výsledek použitelný, je výhodnější použít jazyk s méně pracnou správou paměti a přívětivější správou datových struktur, který je vhodnější pro prototypování. Teprve v případě, kdy je ověřeno, že testovaný postup bude fungovat, bude nutné algoritmus přepsat do C nebo C++.
Pro účely rychlého návrhu slouží modul pro spouštění pythoních skriptů. Modul implementuje wrapper pro rozhraní DNS Collectoru. Toto rozhraní je pak možné využívat ve spouštěném skriptu. Samotný modul volá interpret jazyka Python (libpython). Kód wrapperu obaluje předávané C-čkové struktury a vytváří z nich PyObjecty. Za cenu snížení výkonu aplikace, v důsledku obalování datových struktur, je možné využívat všechny výhody dynamicky typovaného interpretovaného jazyka s automatickou správou paměti. Surová DNS data je možné v Pythonu zpracovávat pomocí pyLDNS (wrapper okolo LDNS).
Použití tohoto modulu není pro jiné účely, než je testování, doporučeno. Důvodem je samotná knihovna libpython. Tato knihovna nepodporuje více samostatných interpretů v rámci jednoho procesu. Libpython nepoužívá kontext pro předávání konfigurace interpretru; kontext interpretu existuje jako globální struktura(y) v prostoru procesu. Libpython sice implementuje něco, čemu říká sub-interpreter, ale jak sami tvůrci v dokumentaci uvádí, izolace těchto „pod-interpretrů“ není úplná. Při použití funkcí z nízkoúrovňových operací připouštějí jejich vzájemné ovlivňování.
Konfigurace
DNS Collector je možné spouštět na popředí z příkazové řádky. V tom případě je možné konfigurovat a používat pouze jedno síťové rozhraní či archiv a jeden modul. Tento režim slouží zejména k testování modulů nebo ke spouštění v dávkovém režimu pro postupné zpracování více archivů. Primární určení DNS Collectoru je být spuštěn jako daemon pro monitorování DNS provozu. V tomto případě je vhodnější používat konfigurační soubor, ve kterém je možné současně specifikovat nastavení několika síťových rozhraní společně s několika moduly.
Experimentální konfigurace NETCONFem
Pro použití ve vzdálených zařízeních je experimentálně implementována možnost konfigurace pomocí protokolu NETCONF. NETCONF je protokol založený na XML, umožňující konfiguraci síťových zařízení. Funkce NETCONF serveru je naprogramována s využitím knihovny libnetconf. Tato knihovna implementuje NETCONF server a klient a bezpečný komunikační SSH kanál.
DNS Collector na listopadové konferenci CZ.NIC
Pokud vás tento projekt zaujal a máte k němu otázky, můžete samozřejmě využít komentářového formuláře. Jestli se ale chcete dozvědět více a zeptat se přímo, doporučil bych vám, abyste si udělali čas na naši konferenci Internet a Technologie 13.2 (30. 11., MFF UK, Praha), v jejímž již brzy zveřejněném programu prezentace na toto téma bude.
Karel Slaný