Enfant terrible DNS scény opět zasahuje. Daniel J. Bernstein přichází z vlastním návrhem řešení kryptografické autentizace DNS záznamů. Tento návrh si můžete v originále přečíst na stránkách projektu DNSCurve.
Ve stručnosti se jeho návrh dá shrnout do několika bodů:
- Všechny NS záznamy budou speciálně pojmenované
- Speciální pojmenování bude obsahovat šifrovací klíč
- Rekurzivní DNS bude komunikovat s autoritativním pomocí tohoto šifrovacího klíče
- Šifrovaná komunikace bude obalená a schovaná do TXT RDATA
Návrh obsahuje pár zajímavých myšlenek (použítí Elliptic Curve Kryptografie), v zásadě ale vidím několik nedostatků tohoto návrhu:
- Informace o tom, že se má začít šifrovat k rekurzivnímu DNS, jde nešifrovaně. Návrh neobsahuje Pevné body důvěry (Trust Anchors).
- V případě, že bychom DNSCurve použili i na root servery a všichni začali DNSCurve používat, tak by došlo k paradoxní situaci, kdy by veškeré DNS pakety chodily obalené do DNS TXT. Což mi lehce připomíná IP over DNS protokol.
- Bernstein píše o tom, jak je Elliptic Curve algoritmus milionkrát složitější na rozlousknutí a zjevně z tohoto důvodu nedefinuje mechanismy, jak měnit klíče. Bude to však pravda i za dalších několik let?
- Nevím jestli název nameserveru uz51gmc1jjicekrm676rorncvjpale915vhd94bj2fddj1be1ntbg5.nic.cz bude patřit mezi něco, co je srozumitelné pro pouhého smrtelníka a zda administrátoři budou s nadšením hledat problémy, když se něco pokazí.
Můj názor je takový, že vzhledem k výše uvedeným faktům a kontroverznosti autora návrhu, který naštval snad úplně všechny, se návrh nikterak nerozšíří. Příjemnou věcí je ovšem to, že DNSCurve nikterak nekoliduje s DNSSECem a administrátor serveru bude mít na výběr.
Ondřej Surý
Aktualizace:
Z diskuze na namedroppers a dnsop se objevilo pár dalších problémů.
- Zdá se, že Elliptic Curve algoritmy jsou problémové z hlediska amerických patentů.
- Protože DNSCurve šifruje, tak je velmi pravděpodobné, že se na něj budou vztahovat americká exportní omezení.
DNSSEC v .gov
Kancelář pro plánování a rozpočet Bílého domu vydala nařízení, podle kterého musí správce domény .gov do ledna roku 2009 nasadit technologii DNSSEC a dále připravit plány na nasazení DNSSECu pro všechny systémy, kterých se týká doménový prostor pod TLD doménou .gov. Originální článek vyšel například zde.
Na tomto faktu by nebylo v zásadě nic tak zajímavého, kdyby:
a) se nejednalo o vládní doménu – administrativa Spojených Států se zajímá o ochranu DNS prostoru
b) nebylo nasazení povinné – zatímco všechny ostatní TLD domény, k nimž se brzy připojí i naše česká doména .cz, fungují na principu dobrovolnosti; všechny poddomény v doméně .gov budou muset implementovat DNSSEC povinně.
V každém případě bude zajímavé sledovat, jak se jim nasazení zdaří, za jak dlouho budou schopni začít podepisovat všechny poddomény a kdy budou mít nasazeny rekurzivní DNS, které si rozumí s DNSSECem.
Ondřej Surý
DNS útok podle Kaminského
Útoky typu DNS Cache Poisoning fungují na principu podvržení odpovědi DNS serveru. DNS server, který se ptá na určité doménové jméno, pak dostane falešné informace např. o IP adrese webového serveru. Způsob, jak podvrhnout DNS odpověď, spoléhá na několik vlastností DNS protokolu:
1. DNS dotazy a odpovědi v sobě mají uloženo 2-bytové Transaction ID, tedy počet kombinací je přibližně 65 tisíc.
2. Nezáplatované DNS servery používají pro všechny dotazy stejný zdrojový port.
3. Většina DNS dotazů a odpovědí používá UDP. UDP je bezstavové a v současných sítích je relativně jednoduché podvrhnout zdrojovou IP adresu.
Útočník musí uhodnout správné Transaction ID (nebo vygenerovat všechny možné kombinace) a poslat je ve velmi rychlém sledu za sebou s podvrženou zdrojovou adresou na adresu DNS serveru, na který útočí. Odpověď od útočníka musí přijít v časovém okně na jedné straně vymezeným DNS dotazem a na druhé straně DNS odpovědí od legitimního autoritativního DNS serveru.
Typický útok tohoto typu musel „čekat“ na chvíli, kdy dotazující server nemá záznam uložený ve vyrovnávací paměti server a musí se zeptat autoritativního serveru. Takový záznam je pak uložen po dobu uvedenou v TTL záznamu ve vyrovnávací paměti serveru a útočník musí čekat než tato doba vyprší. Časové okno, kdy lze zaútočit na DNS serveru, tohoto útoku je tak díky TTL velmi malé a se vzrůstajícím TTL se pravděpodobnost takového útoku snižuje. Šance podvrhnout správné Transaction ID je 1 ku 65 tisícům a i v případě, že se útočník vygeneruje DNS odpovědi se všemi Transaction ID, tak je vzhledem k faktu, že lze útočit pouze ve chvíli, kdy záznam není ve vyrovnávací paměti server, šance na úspěch takového útoku malá.
Podvržená odpověď bude vypadat nějak takto (Transaction ID je vyznačeno tučně):
; <<>> DiG 9.4.2-P1 <<>> www.dnssec.cz
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47457
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2;; QUESTION SECTION:
;www.dnssec.cz. IN A;; ANSWER SECTION:
www.dnssec.cz. 86400 IN A 192.168.1.1;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 8 14:17:41 2008
;; MSG SIZE rcvd: 139
Dan Kaminsky odhalil způsob jak obejít data uložena ve vyrovnávací paměti a falešnou IP adresu podvrhnout v libovolnou chvíli bez ohledu na TTL. Útočník se při útoku neptá přímo na IP adresu webového serveru, ale na libovolný náhodně zvolený neexistující záznam a IP adresu webového serveru podvrhne pomocí sekce AUTHORITATIVE a ADDITIONAL pomocí mechanismu tzv. GLUE záznamu.
Příklad:
Útočník se zeptá DNS serveru, na který útočí, na 007.dnssec.cz
a podvrhne odpověď: Odpověď 007.dnssec.cz neznám, ale zná ho
server www.dnssec.cz s IP adresou 192.168.1.1.
; <<>> DiG 9.4.2-P1 <<>> 007.dnssec.cz
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55309
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 11;; QUESTION SECTION:
;007.dnssec.cz. IN A;; AUTHORITY SECTION:
dnssec.cz. 86400 IN NS www.dnssec.cz.;; ADDITIONAL SECTION:
www.dnssec.cz. 86400 IN A 192.168.1.1;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 8 14:20:58 2008
;; MSG SIZE rcvd: 139
V tu chvíli dojde k přepsání A záznamu pro www.dnssec.cz ve vyrovnávací paměti serveru a další dotazy na www.dnssec.cz, na které bude odpovídat tento DNS serveru, budou obsahovat podvrženou IP adresu.
Šance na uhodnutí správného Transaction ID zůstává stále stejná, ale útočník může volbou dotazů na různé neexistující domény zkoušet podvrhnout IP adresu stokrát až tisíckrát za sekundu. Navíc je schopen lépe řídit čas dotazu (vždy se ptá útočník) a tím pádem lépe načasovat i generování podvržených odpovědí.
Výrobci a autoři DNS serverů vydali aktualizace, které do dotazu vkládají další prvek náhody – náhodný zdrojový port. Před aktualizací byl zdrojový port dotazu zvolen náhodně při startu serveru a po celou dobu běhu serveru byl používaný stejný port. Po aktualizaci se pro každý dotaz používá nové
náhodně zvolené číslo zdrojového portu (pokud budeme počítat, že se využije celý rozsah, což většinou nebývá pravdou) a šance na uhodnutí kombinace Transaction ID a čísla zdrojového portu je 1 ku 4 milardám. Útočník se může pokoušet vygenerovat i takovýto počet podvržených DNS odpovědí, ale šance, že se mu povede trefit se se správnou odpovědí je výrazně menší a provoz, který tímto vygeneruje jen těžko zůstane bez povšimnutí.
Útok, který předvedl Dan Kaminsky, na vyrovnávací pamět DNS serveru je po instalaci opravných aktualizací nepravděpodobný, ale stále možný. Podle kalkulací, které proběhly poštovní konferencí namedroppers, je pravděpodobnost takového útoku po 24 hodinách cca 64%. Takový útok by si ovšem vyžádal generování obrovského množství podvržených DNS odpovědí a u méně výkonných instalací by spíše způsobil zahlcení a přerušení provozu. Tak než jsem stihl napsat tento příspěvek do blogu, tak se objevil první úspěšný útok v laboratorních podmínkách na DNS server s náhodnými zdrojovými porty, který byl schopný vložit do DNS falešnou adresu během 10 hodin.
Jediné řešení, které DNS servery ochrání před tímto stylem DNS útoků je v současné době technologie DNSSEC.
Prezentaci Dana Kaminského z konference BlackHat USA 2008 naleznete na jeho stránkách DoxPara.
Malé (a nevýznamné) IPv6 překvapení
Jak už bylo mnohokrát řečeno (třeba zde), pomalu docházejí volné bloky IPv4 adres. Přechod na IPv6 rozhodně neprobíhá zrovna „nadzvukovou“ rychlostí a tak je poměrně překvapující následující statistika, která popisuje strukturu DNS dotazů přicházející na name servery CZ.NIC.
Jak je vidět dotazy týkající se IPv6 (AAAA a A6), tvoří už dnes skoro 20 % celkového provozu nebo pokud porovnáme s odpovídajícím IPv4 dotazem, je to dokonce 25 %. To není málo. Abychom se ale nedívali na svět příliš růžovými brýlemi, podíváme-li se za stejné období minulého týdne na návštěvníky www.nic.cz, tak situace už vypadá zcela (a bohužel i očekávaně) jinak. Zatímco přes IPv4 přišlo 8041 unikátních uživatelů, přes IPv6 jen 32, tedy 0,3 %. A to už není žádná sláva :(
Pavel Tůma (PT)
Jak bude fungovat DNSSEC v .CZ?
Na začátku března jsme ohlásili záměr a „cestovní plán“ na zavedení technologie DNSSEC v doménách .CZ a ENUM. Dokument Implementace DNSSEC v CZ.NIC obsahuje návrh, jak bude implementace do registru domén vypadat a jakým způsobem bude provedena. Tímto jej dáváme všem otevřeně k dispozici. Budeme velice rádi, když nám napíšete své komentáře či připomínky k jeho obsahu a přispějete tak k tomu, aby se DNSSEC stal užitečným nástrojem pro všechny uživatele internetu v České republice. Své reakce vkládejte přímo sem pod článek do komentářů nebo e-mailem na adresu kontakt@nic.cz.
Ondřej Filip
IPv6 v kořenové zóně
O IPv6 se diskutuje už dlouhá léta. Někdy okolo roku 1992 začalo být IETF jasné, že IPv4 adresy dochází a byla nastartována iniciativa IPng (první RFC na toto téma bylo RFC 1550). Přibližně o tři roky později byl vybrán návrh IPv6 (základní specifikace IPv6 se nachází v dokumentu RFC 2460). Proces, který následoval v běžném světě, bych označil jako: „Jak se vyhnout nasazení IPv6.“ Masivní nasazení technologie překladu adres (NAT/PAT) postupné ubývání IPv4 adres zpomalil, ale nezastavil. Velmi pěkné pojednání o tom, kdy IPv4 adresy dojdou má na svých stránkách Geoff Huston. Podle jeho posledního modelu nám dojdou adresy někdy v roce 2011-2012.
Nicméně rozhodně nelze sedět a čekat, až IPv4 adresy dojdou. Přechod na IPv6 nejde udělat přepnutím jednoho přepínače a internetová infrastruktura na tento přechod musí být připravena. Všechny systémy provozované sdružením CZ.NIC jsou v tuto chvíli provozovány na IPv4 i IPv6 adresách, včetně našich DNS serverů.
Z pohledu IPv6 došlo minulý týden k důležitému kroku na straně serverů obsluhující kořenovou (root) zóny. IANA přidala do této zóny IPv6 záznamy pro polovinu (přesněji šest ze třinácti) DNS serverů – A,F,H,J,K a M.
Běžného uživatele se tato změna nejspíš nedotkne, i když vím o minimálně jedné komunitní síti, která má (a možná, že už to opravili) IPv6 routing natolik rozbitý, že by to mohlo dělat problémy. Nicméně z pohledu další budoucnosti je to výrazný signál, že je potřeba začít IPv6 brát vážně.
Krátká poznámka na závěr. Pokud provozujete BIND jako resolver a zároveň používáte IPv6, budete asi chtít zaktualizovat named.root soubor. Stáhnout si jej můžete z Internicu.
Ondřej Surý
Co mě štve na diskusích o IDN
Nedávno jsem na jednom blogu četl příspěvek o IDN a jako obvykle jsem se trochu rozčílil. Rád bych se v tomto článečku pokusil vyvrátit několik mýtů, které v Čechách kolem IDN panují. První nepravda je, že CZ.NIC se na IDN třese, chce na něm vydělat a proto pořád opakuje průzkumy veřejného mínění. To je pochopitelně nesmysl. Sdružení se IDN spíše brání, stačí povolit registraci domén začínající xn-- a IDN je na světě. Pro současný registrační systém (FRED) není IDN překážkou, na registrační nápor je připraven. CZ.NIC je neziskové sdružení a pokud zaregistruje nějak zásadně více domén, musí zlevnit. Myslím, že jasným důkazem bylo razantní snížení velkoobchodní ceny v říjnu loňského roku; podařilo se nám snížit náklady a proto jsme šli dolů i s cenou.
Druhý nápad, který se v takové diskusi často objeví, je, že by nameservery CZ.NIC na dotaz na doménu s háčky a čárkami odpověděl stejně, jako na stejnou doménu bez diakritiky. Tato myšlenka zní na první pohled rozumně, ale mám dva důvody, proč se mi nelíbí. První je poměrně jednoduchý. Nevidím proč by měli držitelé běžných domén mít práva na všechny varianty. Při vší úctě k úřadu vlády, není asi nutné, aby kromě vláda.cz vlastnila tato instituce také doménu vláďa.cz. Druhý důvod je výrazně silnější. Ono to totiž ani technicky není možné provést. Jsou dva způsoby:
- předgeneruje se zóna pro všechny povolené IDN kombinace. Zkoušel jsem si počítat velikost takové zóny pro české znaky (od IDN bych osobně očekával i znakové sady našich sousedů) z aktuálního stavu a vyšlo mi číslo 50 biliónů domén. A to se rozhodně nevejde do pamětí současných DNS serverů.
- upraví se software DNS serverů tak, aby odpověď počítal za běhu. CZ.NIC používá v současné době bind a nsd, tyto SW by bylo nutné upravovat. Oprosťme se teď na chvíli od nákladů na udržování paralelních větví takového SW; mimochodem, ve dřívějších dobách, před mým příchodem do CZ.NIC, by to ani nebylo možné, protože tehdy neměl CZ.NIC všechny DNS servery pod svou správou. Protože plánujeme zavedení technologie DNSSEC, musel by mít u sebe DNS server nainstalovaný podpisový klíč zóny, což je značné bezpečnostní riziko, kterým by současně za běhu podepisoval odpovědi. To je při exponovanosti DNS serverů opět technicky nemožné.
Po zvážení těchto skutečnosti už nemá cenu komentovat fakt, že by si každý správce domény musel na takové řešení připravit své webové a mailové servery. Jako mnohem důležitější vidím otázky jako jsou:
- zavést nebo nezavést IDN?
- nezavádět je i v případě, že budou jiné TLD už české IDN podporovat?
- jaké znakové sady podporovat?
- startovat se sunrise nebo přímo
- mají mít v sunrise přednost současné neIDN domény?
- mají mít v sunrise přednost držitelé ochranných známek, státní správa a samospráva.
Váš xn--ondej-kcb filip