Dnsmasq je jednoduchá implementace základních síťových služeb — vše v jednom: DNS, DHCP, router advertisement a bootování ze sítě. Pro svou velikost (maličkost) a nenáročnost na systémové prostředky si našel místo na mnoha domácích routerech. Dnsmasq také spravuje virtuální sítě v sadě nástrojů libvirtd. A v neposlední řadě je k nalezení i na některých smartphonech (včetně Androidu), kde se používá pro tethering.
9. dubna 2014 vyšel Dnsmasq verze 2.69, který do vínku dostal podporu validace DNSSEC. To určitě stojí za vyzkoušení.
Města a obce dokázaly, že implementace IPv6 a DNSSEC nemusí být problém
V rámci tradiční soutěže Zlatý erb hodnotící nejlepší webové stránky měst a obcí je již druhým rokem jako jedno ze soutěžních kritérií zařazena „Podpora IPv6 a DNSSEC“, jehož hodnocení má na starosti naše sdružení.
Pomůže usnesení vlády k většímu rozšíření IPv6 a DNSSEC?
Na konci loňského roku přijala vláda Usnesení č. 982, které zavádí povinnost zabezpečení domén držených státní správou prostřednictvím technologie DNSSEC. Usnesení vlády se zaměřuje rovněž na podporu IPv6, kdy ve srovnání s usnesením z roku 2009 rozšiřuje okruh subjektů, které musí u svých elektronických služeb podporovat IPv6. Ve svém dnešním příspěvku bych se rád na nové usnesení vlády podíval trošku podrobněji a zároveň přidal pár statistických dat jako příspěvek do diskuze na téma, zda má cenu mít usnesení vlády, které nemá žádné sankce a zda takovýto dokument není jen „prázdným plácnutím do vody“.
IPv6: současný stav
Povinnost podporovat na svých serverech IPv6 byla vládou schválena již v červnu 2009 s tím, že jednotlivé orgány státní správy (tj. ministerstva a další centrální úřady jako např. Český statistický úřad či Energetický regulační úřad) měly za povinnost do 31. prosince 2010 zabezpečit přístup ke svým stránkám jak prostřednictvím protokolu IPv4, tak protokolu IPv6. Stejná povinnost pak byla doporučena pro kraje včetně hl. města Prahy.
Pokud se podíváme na aktuální výsledky podpory IPv6 u jednotlivých orgánů veřejné správy (viz graf), zjistíme, že podpora nové verze internetového protokolu je u státní správy mnohem vyšší, než ve zbytku domény .cz, přičemž vidíme znatelný rozdíl mezi státní správou, která je přímo dotčena usnesením vlády č. 727 z roku 2009, a samosprávou. U měst a obcí pak stojí za povšimnutí téměř čtyřnásobný růst podpory IPv6 na straně webových serverů, který je částečně způsoben rovněž zahrnutím podpory této technologie jako jednoho z kritérií soutěže Zlatý erb, kterou jsme se rozhodli jako technologický partner podpořit rovněž v letošním roce.
IPv6: co přináší nové usnesení vlády
V rámci nového usnesení vlády přijatého na sklonku loňského roku považuji osobně za nejdůležitější nový bod 1. d), tj. „zahrnout požadavek na podporu IPv6 do všech relevantních výběrových řízení, a to jak na dodávky služeb, tak zboží (hardware), i jako nedílnou součást požadavků na všechny nově podpořené projekty a jejich součásti financované ze strukturálních fondů v tomto i nadcházejícím finančním období.“ Oproti původnímu usnesení vlády se povinnost podpory IPv6 rozšiřuje rovněž o příjemce prostředků ze strukturálních fondů. Zde je nutné si uvědomit, že v rámci tzv. publicity patří webové prezentace mezi nejoblíbenější nástroje, přičemž často se nejedná o samostatný web, ale jen o začlenění jedné (či několika málo stránek) do stávajícího firemního webu. V této souvislosti stojí za připomenutí, že z TOP100 firem podporuje na webových serverech IPv6 pouze 5 % největších podniků.
V případě zájmu se mocným nástrojem na prosazení IPv6 může pak stát požadavek jejího povinného zahrnutí do všech relevantních výběrových řízení. Je ale nutné si uvědomit, že pod pojmem „relevantní výběrová řízení“ se již nemusí skrývat jen tendery související se zajištěním webové prezentace, ale rovněž s nákupem datových služeb (včetně mobilních), což podporuje rovněž Český telekomunikační úřad, který 20. prosince 2013 zveřejnil Obecná pravidla řízení datového provozu. Podle těchto pravidel se pak službou přístupu k síti internet rozumí:
veřejně dostupná služba elektronických komunikací, která umožňuje využívání obsahu, aplikací a služeb sítě internet, a tím propojení prakticky všech koncových bodů připojených k síti internet (a to protokolem IPv4 a IPv6), bez ohledu na použitou technologii sítě.
Zde bude zajímavé sledovat, zde se povinnost zajištění konektivity jak přes IPv4 či IPv6 nestane další součástí boje v rámci elektronické aukce komunikační infrastruktury veřejné správy, tzv. KIVS.
DNSSEC
Pokud se podíváme na aktuální statistiky, zjistíme, že průměr počtu zabezpečených domén .cz dosahuje 37,1%, zatímco u státní správy se to o 10 procentních bodů méně – konkrétně jen čtyři ministerstva ze čtrnácti a tři ze třinácti ústředních orgánů státní správy.
Situace je tak zde zcela opačná, než u IPv6 a z tohoto pohledu je usnesení vlády vítaným nástrojem, který – dle zkušeností s IPv6 – sice zřejmě nikdy nezaručí 100% přijetí této technologie, ale může výrazně urychlit její zavedení. V rámci podpory rozšíření obou technologií se pak Akademie CZ.NIC rozhodla všem účastníkům z veřejné správy nabídnout speciální akci: dva kurzy (IPv6 a DNSSEC) za cenu jednoho.
Hřejivé na srdci je pak i to, že u DNSSEC se Česká republika stala první zemí min. v Evropě, která nařídila veřejné správě zabezpečení svých domén, což byl možná i jeden z důvodů, proč nedávné Usnesení vlády označil renomovaný publicista Jiří Peterka jako jednu z 10 nejvýznamnějších událostí českého eGovernmentu za rok 2013.
Jiří Průša
Proč je opravdu zapotřebí DNSSEC?
Amir Herzberg a Haya Shulmanová z izraelské Bar Ilan University na konferenci IETF 87 v Berlíně představili novou variantu otrávení DNS pomocí fragmentace IP paketů. Kompletní prezentaci lze najít v IETF 87 Proceedings.
Doporučuji si pro osvěžení tématu znovu přečíst o útoku na DNS, který před pěti lety objevil Dan Kaminsky. Kromě použití technologie DNSSEC, která je jedinou opravdu funkční ochranou proti podvrhávání DNS odpovědí, se jako jedna z obran začaly používat náhodné zdrojové porty, které přidaly dalších ~16 bitů entropie.
Už v té době jsme ve studii (kratší shrnutí) upozorňovali, že ani větší počet náhodných bitů nezaručuje ochranu před podvržením a otrávením DNS, a s dostatečně velkým datovým tokem (~100Mbps) je možné otrávit DNS za dobu lehce překračující jeden den (~25 hodin).
Izraelští výzkumníci nyní přišli s novými variacemi útoku na DNS, které ukazují, že opravdu potřebujeme kryptograficky silné DNS a potřebujeme jej pokud možno ihned.
Hlavička IPv4 paketu vypadá takto:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Celá hlavička UDP datagramu vypadá takto:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Důležité je vědět, že v případě, že spojení mezi dvěma směrovači má nižší MTU (Maximum Transmission Unit) dojde k fragmentaci paketu na několik částí, které jsou identifikovány stejným číslem v poli Identification (dále IP-ID). Fragmentovaný provoz může vypadat například takto:
14:56:02.608188 IP (tos 0x0, ttl 64, id 47557, offset 0, flags [+], proto ICMP (1), length 1500)
217.31.204.249 > 12.22.58.30: ICMP echo request, id 22368, seq 1, length 1480
14:56:02.608193 IP (tos 0x0, ttl 64, id 47557, offset 1480, flags [none], proto ICMP (1), length 48)
217.31.204.249 > 12.22.58.30: ip-proto-1
14:56:02.797078 IP (tos 0x0, ttl 60, id 61513, offset 0, flags [none], proto ICMP (1), length 1528)
12.22.58.30 > 217.31.204.249: ICMP echo reply, id 22368, seq 1, length 1508
Jak lze vidět, tak odchozí ICMP zpráva typu echo request (tj. ping) byla rozdělena na dvě části s IP-ID = 47557 a rozdílnými offsety. Fragmentované části paketu pak budou v cíli spojeny do jednoho a aplikace, která přenesenou zprávu zpracovává, ji dostane v jednom bloku. A protože k defragmentaci paketů dochází až v cílové destinaci a směrovače fragmentované pakety nijak speciálně nesledují, tak je možné, že každá část fragmentovaného paketu dorazí k cíli například jinou cestou nebo v jiném pořadí, než byly fragmenty odeslány.
Toto skládání částí paketu mimo pořadí nahrává útočníkovi. Pokud ví, jaké je po cestě MTU, což nemusí být tak složité zjistit, tak může začít podvrhovat následné (tedy druhé a vyšší) části paketů. Takto podvrhnuté fragmenty můžou mít dvojí efekt – jednak je možné do druhé části paketu vložit vlastní obsah a jednak v případě rozdílné udané velikosti celého paketu je možné donutit operační systém, který je zodpovědný za defragmentaci paketu, aby (pro útočníka) nežádoucí pakety zahazoval (tj. taková trochu chytřejší varianta DDoS útoku).
Další (a poslední) část fragmentační skládačky spočívá v tom, že existuje ICMP zpráva typu fragmentation needed, kterou si počítače na cestě domlouvají maximální velikost paketu, kterou dokážou přenést. V případě IPv4 je minimální velikost MTU 68, v případě IPv6 je to 1280. Bohužel tuto zprávu lze celkem dobře podvrhnout a cílový server donutit snížit MTU na hodnotu, která je pro útočníka výhodná. Tato nová hodnota je v operačních systémech držena v dočasné paměti až několik minut.
Jaké to tedy má důsledky pro DNS? Na to se musíme podívat do hlavičky DNS zprávy:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Již jsme si řekli, že ochranu proti spoofingu nám zajišťuje ID v hlavičce zprávy (16 bit) společně se zdrojovým portem v UDP zprávě (16 bit).
Když se ale podíváme zpátky pouze na IP vrstvu, tak zjistíte, že obě informace (DNS-ID i source port) jsou vždy uloženy pouze v prvním IP fragmentu, tudíž útočníkovi stačí podvrhnout druhou část paketu, kterou nahradí vlastním obsahem. Při podvrhávání potřebuje útočník uhádnout jenom správné IP-ID, aby se podvržený fragment spojil se začátkem platné odpovědi. Kromě toho, že hádání 16-bitového IP-ID je velmi jednoduché provést pouhou hrubou silou, tak celou situaci ještě zjednodušuje fakt, že hodnoty IP-ID se většinou negenerují úplně náhodně. Na některých operačních systémech existuje globální counter IP-ID, takže hodnotu aktuálního IP-ID systém vyzrazuje s každým odeslaným paketem (a útočník tedy přibližně ví, do jakého rozsahu se má trefovat). Pokud cíl útoku běží na Linuxu, tak je to pro útočníka naštěstí trochu složitější, protože pro každou cílovou adresu má Linuxové jádro zvláštní IP-ID counter, ale i toho však lze bohužel zneužít.
Poslední komplikace, kterou útočník musí vyřešit, je kontrolní součet v UDP hlavičce. Nicméně ani to není velký problém, protože jednak útočník ví, jak bude odpověď DNS serveru vypadat, protože se sám může zeptat, a v DNS paketu je vetšinou dost místa na to, aby kromě falešné odpovědi do DNS paketu ještě nacpal další data, kterými 16-bitový kontrolní součet nastaví na požadovanou hodnotu.
Poslední zefektivnění útoku probíhá opět již na IP vrstvě a závisí na implementaci IP stacku v jednotlivých operačních systémech, nicméně je možné říci, že ve většině případů je možné tuto optimalizaci dost efektivně využít. Již jsme si výše řekli, že fragmentované pakety mohou přijít mimo pořadí, a protože je UDP nespojovaný protokol a zároveň vrstva, která dělá defragmentaci v IP stacku nemá moc ponětí o vrstvách vyšších, je možné podvržené druhé fragmenty poslat dopředu na náš cíl útoku a ony se uloží do vyrovnávací paměti operačního systému. Teprve po tomto „nahrání“ druhých fragmentů útočník vyvolá Kaminsky-style dotaz, a odpověď, kterou cílová aplikace dostane, bude složena z přednahraného části a prvního fragmentu správné odpovědi.
Celý koncept útoku dále v Laboratořích CZ.NIC zkoumáme, a mimo jiné bychom rádi v rámci ověření efektivity takového útoku vyrobili funkční PoC (Proof of Concept) implementaci celého útoku. O tom, zda-li jsme uspěli, Vás budeme dále informovat.
Na závěr bych rád řekl jednu špatnou a jednu dobrou zprávu. Ta špatná zpráva je, že v současné době není proti tomuto útoku známa žádná jiná efektivní obrana než nasazení DNSSECu. Ta dobrá zpráva je, že pokud máte doménu .CZ, tak máte skoro 40% šanci, že Vás DNSSEC chrání. Jestli chcete vědět, jak s DNSSEC pracovat, přijďte do naší akademie. Kurz se jmenuje více než prozaicky – DNSSEC – zabezpečení DNS.
Ondřej Surý
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 %).
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.
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ů.
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