Akademie DNSSEC Matej Dioszegi

Organizace ● Délka školení bez přestávek cca 4 hodiny ● Dvě přestávky ● Občerstvení ● Otázky rovnou v průběhu školení

Požadavky ● Znalost Linuxového prostředí ● Znalost TCP/IP ● Znalost DNS ● (Základní) znalost konfigurace Bind 9 ● Základní znalost asymetrické kryptografie

Obsah ● DNS – základní pojmy ● Základní principy DNSSEC ● Konfigurace validujícího resolveru ● Konfigurace autoritativního serveru ● Podepsání zóny ● Výměna klíčů ● DNSSEC nástroje ● Hledáme chyby

Cíle školení ● Pochopit základní principy DNSSEC ● Umět nakonfigurovat validující resolver ● Umět nakonfigurovat autoritativní server ● Umět podepsat vlastní zónu ● Umět v podepsané zóně vyměnit klíče ● Umět najít chybu, když nefunguje validace

Obecně ● Všechny materiály kurzu jsou dostupné na ● Tato prezentace ● Ukázkové konfigurační soubory ● Konfigurační soubory můžete otestovat: ● # named-checkconf /etc/bind/named.conf ● # unbound-checkconf /etc/unbound/unbound.conf ● Znovunačtení konfigurace ● # rndc reload

Obecně ● Přístup na root uživatele ● # sudo -s ● Standardní init.d skripty ● start/stop/restart ● Bind 9: /etc/init.d/bind9 ● Unbound: /etc/init.d/unbound

DNS – základní pojmy ● Domain Name Space ● Uzel ● Label ● Resource Records ● RR záznam ● RRSet ● Name/DNS Server ● Resolver ● Stub Resolver ● Validující Resolver ● Zóna ● Komunikace ● DNS zpráva ● Dotaz ● Odpověď ● EDNS0 ● Cache

DNS dotaz

DNS paket Query Response

Problémy DNS ● Cache poisoning ● Neustálý vývoj útok/patch ● Chybí „systémové“ řešení ● Steven Bellovin – poprvé „poukázal“ na problém ● Kaminsky – 2008 – ani source port randomization nestačí

Cache poisoning zdroj: Paul Wouters, Defending your DNS in a post-Kaminsky world, Black Hat Briefings

Cache poisoning – random ports TXID – 16 bitov Microsoft DNS – 2500 portov ~2^11 2^16*2^11 = 2^27 ~ 134 mil. zdroj: Paul Wouters, Defending your DNS in a post-Kaminsky world, Black Hat Briefings

Birthday attack zdroj: Paul Wouters, Defending your DNS in a post-Kaminsky world, Black Hat Briefings

Birthday attack ● Birthday paradox – V skupině 23 lidí je pst. kolize (2 lidi narozeniny v 1 den) > 50 % t = u narozenin 365, u TXID 2^16 N = počet prvků v skupině

Cache poisoning - Kaminsky ● Předešlé útoky – když stihl správný NS odpovědět dříve než útočník uhodl TXID a port, útočník musel čekat TTL záznamu na další pokus ● Dan Kaminsky představil elegantní „řešení“ ● Není nutné při neúspěchu čekat ● Využívá odpověď s rcode NXDOMAIN a glue záznamy

Cache poisoning - Kaminsky TXID: 0x1234 Query: xyz1. Awww.banka.cz Answer: 0 Authority: 1 Additional: 1 xyz1. NS A ● Nestihl útočník uhodnout TXID/port u dotazu na xyz1. ● Nevadí ● Zkusí okamžitě na xyz2. ●......

Kaminsky attack ● ~10 hodin na vložení falešného záznamu do cache plně zapatchovaného NS – attack-analysis.pdf

DNSSEC Základní principy a pojmy

Základní principy DNSSEC ● DNSSEC umožňuje autoritativním serverům poskytovat k „standardním“ DNS datům navíc digitální podpisy RRSetů ● Resolvery ověřující DNSSEC podpisy poskytují potvrzené odpovědi ● Klienti, kteří používají validující resolvery, získávají „správná“ data ● Odpovědi, které nejsou validní, jsou klientovi vráceny z nadřazeného resolveru s chybou „SERVFAIL”

Základní principy DNSSEC

Základní pojmy DNSSEC ● Pevný bod důvěry ● Řetěz důvěry ● Důvěryhodný klíč ● Ostrov důvěry ● Validující Resolver ● Key Signing Key (KSK) ● Zone Signing Key (ZSK) ● Podepsaná vs. nepodepsaná zóna

Pevný bod důvěry (Trust Anchor) ● Nakonfigurovaný klíč (nebo jeho hash), kterému důvěřujeme ● Musíme ho získat nějakou bezpečnou cestou

Řetěz důvěry ● Sekvence DNSSEC záznamů (DNSKEY a DS) vedoucí od Pevného bodu důvěry k uzlu v DNS stromu ● V každém uzlu/úrovni máme ověřená data

Důvěryhodný klíč ● DNSSEC klíč, který je důvěryhodný ● Pevný bod důvěry ● Klíč získaný přes Řetěz důvěry

Validující Resolver ● Posílá DNS dotazy s DNSSEC OK ● Ověřuje validitu DNSSEC podpisů v DNS odpovědích ● Má nakonfigurovaný alespoň jeden Pevný bod důvěry

Ostrov důvěry ● Podepsaná důvěryhodná zóna, která není bezpečně delegována z nadřazené zóny ● Může být ověřena pomocí nakonfigurovaného Pevného bodu důvěry ● Obecněji i všechny bezpečně delegované podřazené zóny

Ostrov důvěry root org cz nl nlnetlabs.n l ww w mai l unsigned.or g.... nic.c z.... neco.c z publicoffice signed.neco.c z mai l ww w Podepsané domény

Ostrov důvěry root org cz nl nlnetlabs.n l ww w mai l unsigned.or g.... nic.c z.... neco.c z publicoffice signed.neco.c z mai l ww w Podepsané domény

Ostrov důvěry root org cz nl nlnetlabs.n l ww w mai l unsigned.or g.... nic.c z.... neco.c z publicoffice signed.neco.c z mai l ww w Podepsané domény

Ostrov důvěry root org cz nl nlnetlabs.n l ww w mai l unsigned.or g.... nic.c z.... neco.c z publicoffice signed.neco.c z mai l ww w Podepsané domény

Key Signing Key ● DNSSEC klíč používaný pro podepsání dalších klíčů ● Silnější ● Více bitů ● Výpočetně složitější ● Více dat ● Speciální bit (SEP) v příznacích DNSSEC klíče

Zone Signing Key ● DNSSEC klíč používaný pro podepsání vlastního obsahu zóny ● Slabší ● Méně bitů ● Výpočetně jednodušší ● Rychlejší podpis i ověřování ● Méně dat

Příklad: doména onde.cz

Podepsaná zóna ● Obsahuje veřejní část klíčů (DNSKEY) ● RRSety jsou podepsané ● U každého RRsetu musí existovat alespoň 1 podpis pro každý použitý algoritmus (ne u delegací) ● Ke každému DN existuje NSEC záznam ● U NSEC3 – hash DN ● Výjimkou je Opt-out ● Autentické potvrzení neexistence DN alebo typu

Nové RR záznamy

DNSKEY RR záznam ● DNSSEC klíč ● RDATA obsahují ● Příznaky (Flags) ● Protocol (vždy 3) ● Algoritmus (5 - RSASHA1) ● Veřejný klíč ● IN DNSKEY AwEAAd[...]kNB8Qc=

RRSIG RR záznam ● Digitální podpis RRSetu ● Obsahuje: ● Podepsaný RR typ ● Algoritmus ● Počet labelů v podpisovaném jméně (kvůli *) ● Původní TTL ● Datum platnosti (začátek a konec) ● Key Tag, Jméno zóny ● Digitální podpis ● INRRSIG A dnssec.cz. V0JXuw[...]

NSEC RR záznam ● Záznam vyznačující neexistenci doménového jména – pomocí vyjmenování dalšího následujícího labelu ● Zóna musí být abecedně setřízena (v každé úrovni hierarchie) ● Obsahuje: ● Další doménové jméno ● Bitová mapa existujících typů (pro vlastníka) ● INNSECudp53.cz. NS RRSIG NSEC DS

NSEC3 RR záznam ● Zone walking problém s NSEC ● NSEC3 mená hashuje ● NSEC3 RR tvoří řetěz v hashovaném pořadí ● NSEC3 RR dokáže existenci hierarchicky „nejbližšího“ mena a neexistenci přesnejší zhody ● Zvýšená zátěž jak pro nameserver, tak pro resolver ● Možnost vypustit z řetězu nepodepsané delegace

NSEC3 vs. NSEC ;; Question a.c.x.w.example. IN A ;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) ;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 b4um86eghhds6nea196smvmlo4ors995.example. NSEC aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) ;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) x.w.example. NSEC y.w.example.com ( MX NSEC RRSIG ) H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv NSEC3NSEC QUERY ZONE - Nejdelší předek: x.w.example – shoda záznamu 2 - Bližší shoda (c.x.w.example) neexistuje – pokrývá záznam 1 - Wildcard (*.x.w.example) neexistuje – pokrývá záznam 3 - Klient se dozví: v zóně existuje jméno x.w.example

DS RR záznam ● Záznam o bezpečné delegaci ● V nadřazené zóne ● RDATA obsahují hash DNSKEY klíče, kterým je zóna podepsaná ● Obsahuje: ● Key Tag ● Algoritmus ● Digest Type ● Digest ● INDS BBDDD[...]3502D

Konfigurace validujícího resolveru Bind 9.7 & Unbound

Povolte DNSSEC na resolveru options { dnssec-enable yes; dnssec-validation yes; }; Validace se provádí na rekurzivních, nikoli na autoritativních serverech.

Povolte DNSSEC na rekurzivních serverech ● BIND 9.3 pouze dnssec-enable yes; ● BIND >= 9.4 má standardně zapnutý DNSSEC ● BIND >= 9.5 má standardně zapnutou i validaci ● Unbound má validaci standardně zapnutou (module-config: „validator iterator“ vs. „iterator“) ● Nutno přidat Pevné body důvěry

Úkol: Zapněte DNSSEC validaci Soubor /etc/bind/named.conf nahraďte souborem named.conf.rec z materiálů Explicitně zapněte DNSSEC validaci Bind 9: /etc/bind/named.conf options { dnssec-enable yes; dnssec-validation yes; }; Unbound: /etc/unbound/unbound.conf module-config: "validator iterator"

Pevné body důvěry (Trust Anchors)

Pevné body důvěry ● Aby validace mohla někde začít, musíte do konfigurace validující resolveru vložit Pevný bod důvěry pro každý Ostrov důvěry, který budete chtít ověřovat ● Nejvyšší pevný bod důvěry bude pocházet od podepsané root zóny (".")

Pevné body důvěry ● Root zóna (".") je podepsána ● Vhodný začátek – ● Pevné body důvěry musíte získat bezpečným způsobem ● DNS nepatří mezi zabezpečené kanály, AVŠAK...

Pevné body důvěry dig udp53.cz udp53.cz INDNSKEY BE[...]/V1 udp53.cz INDNSKEY BE[...]1ylot7 Pomocí digu získáme DNSSEC klíče, které mohou být ověřeny pomocí dalších prostředků (web, telefon, tištěná média, atd.)

Pevné body důvěry ● Pro.cz používat root-anchor ● ● Poštovní konference – informace o změnách: ● ●

Pevné body důvěry (Bind 9) Bude zapotřebí, aby named.conf. obsahoval: trusted-keys { “udp53.cz.” “BE[...]1ylot7”; “cz.” “AwEAAdo9[...]MnitkuM=”; “se.” “AwEAAdKc[...]UkNB8Qc=”; }; Klíč pro KAŽDOU zónu, kterou chcete ověřovat Použijeme soubor named.conf.keys z materiálů

Úkol: Nakonfigurujte Bind9 Nakonfigurujte Bind 9 jako validující resolver Vemte soubor named.conf.keys trusted-keys { "se." "AwEAAdo9[...]MnitkuM=";.... }; Pomocí direktivy include připojte soubor named.conf.keys do named.conf include "/etc/bind/named.conf.keys"; Načtěte novou konfiguraci # rndc reload

Úkol: Nakonfigurujte Bind9 ● V named.conf.keys zakomentujte všechny TA mimo root ● „se.“ a „dlv.isc.org“ neaktivní trusted-keys { # „se.“ "." "AwEAAagAIKl[...]RlZigUCp8=";.... };

Úkol: Nakonfigurujte Bind9 Ověřte si, že vám funguje validace Dotazem na „špatnou“ doménu: # dig Musí vrátit RCODE=SERVFAIL Dotazem s DNSSEC OK bitem # dig +dnssec # dig +dnssec Musí vrátit nastavený bit AD v hlavičce

Úkol: Nakonfigurujte Bind9 dig +dnssec ; > DiG 9.6.1b1 > +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;nic.cz.INA ;; ANSWER SECTION: nic.cz.1800INA

Úkol: Nakonfigurujte Bind9 ● V named.conf.keys zakomentujte všechny TA mimo „se.“ ● „.“ (root) a „dlv.isc.org“ neaktivní trusted-keys { „se.“ #"." "AwEAAagAIKl[...]RlZigUCp8=";.... };

Úkol: Nakonfigurujte Bind9 # dig Vrací odpověď bez AD (už není SERVFAIL!!!) Dotazem s DNSSEC OK bitem # dig +dnssec Nevrací AD – neexistuje reťez důvěry do cz. # dig +dnssec Vrací AD – klíč pro „se.“ je mezi TA

Pevné body důvěry (Unbound) Unbound umí použít formát trusted-keys, který používá Bind 9 Direktiva: trusted-keys-file: Další možnosti: trusted-anchor-file: Obsahuje DNSKEY nebo DS v DNS formátu trusted-anchor: "RR záznam"

Úkol: Validující resolver Unbound ● Zastavte Bind ● Použijeme již vytvořený soubor named.conf.keys ● Pomocí direktivy trusted-keys-file nakonfigurujte Pevné body důvěry v /etc/unbound/unbound.conf ● trusted-keys-file: "/etc/bind/named.conf.keys" ● Nastartujte Unbound ● Ověřte si, že vám validace funguje

Root zóna ● ● DS formát – Unbound – ok – Bind – umí pracovat jenom s DNSKEY – dig +dnssec. DNSKEY – dnssec-dsfromkey / ldns-key2ds

Root zóna ● ● Ověřit! – gpg –verify root-anchors.asc root-anchors.xml – (--search-key, --recv-key)

Pevné body důvěry ● Správa jednotlivých pevných bodů důvěry je složitá ● Existuje registr DNSSEC klíčů – mechanismus DLV „Domain Lookaside Validation“

Domain Lookaside Validation & ITAR

DLV ● Při ověřování hledá resolver v nadřazené zóně záznam DS pro zónu, která je ověřována ● Pokud neexistuje, je vytvořen dotaz na záznam DLV v zóně registru DLV ● Pokud je úspěšná, je DLV RR použito jako DS pro danou zónu

DLV

Příklad DLV ● webpanel.sk je podepsaná a v DLV registru ● Je vytvořen DNSSEC dotaz na A RR jména ulib.sk ●.sk není podepsaná ● Resolver se zapnutým DLV bude hledat webpanel.sk.dlv.isc.org. DLV RR záznam ● Tento DLV RR pak bude použit jako DS pro zónu webpanel.sk.

Povolení DLV ● Použití DLV pro ověření je provedeno na validujícím resolveru ● Konfigurace DLV v Bind default: managed-keys { ● dlv.isc.org. initial-key "BEAA...WrBNh"; ● }; ● options { ● dnssec-lookaside auto; #dnssec-lookaside "." trust-anchor dlv.isc.org.; ● };

ISC registr DLV

Úkol: Nakonfigurujte DLV registr ● Nakonfigurujte BIND 9 jako validující resolver, který používá DLV registr dlv.isc.org ● Doplňte direktivu dnssec-lookaside s hodnotou auto ● Odkomentujte v named.conf.keys klíč pro dlv.isc.org ● dig +dnssec –.sk nepodepsaná, webpanel.sk v DLV

ITAR ● Interim Trust Anchor Repository ● ● Offline registr ● DS RR pro podepsané TLD ● Po podepsaní root zóny se zmenšuje ● Konec v 1/11

Konfigurace autoritativního serveru

Připravte si adresářovou strukturu ● Umístěte všechny soubory zóny do jediného adresáře ● Bude jich mnoho ● Lepší orientace ● Podpora dalších nádstavbových nástrojů

Příprava na další úkoly ● Připravte si adresářovou strukturu # mkdir /var/cache/bind/zone ● Vytvořte adresář pro zónu udp53.cz # mkdir /var/cache/bind/zone/udp53.cz/ ● Skopírujte zónu udp53.cz z materiálů do vytvořeného adresáře

Příprava na úkoly ● Soubor /etc/bind/named.conf nahraďte souborem named.conf.auth z materiálů ● Nakonfigurujte named.conf, aby poskytoval zónu udp53.cz zone "udp53.cz." { type master; file "zone/udp53.cz/udp53.cz"; }; v options je „directory /var/cache/bind“;

Příprava na úkoly Obnovte konfiguraci # rndc reload Otestujte # dig +norec IN SOA

Povolení DNSSEC na autoritativních serverech BIND >= 9.3 podpora DNSSECbis BIND >= 9.4 má DNSSEC standardně zapnutý options { dnssec-enable yes; }; NSD3 má DNSSEC standardně zapnutý pro všechny podepsané zóny

Zabezpečení zóny ● Pro každou zónu jsou vytvořeny dva typy klíčů ● Klíč podepisující zóny (ZSK) – používá se k podpisu dat v zóně ● Klíč podepisující klíče (KSK) – používá se k podpisu klíče podepisujícího zóny a k vytvoření „důvěryhodného vstupního bodu (SEP)“ pro zónu

Podepsání zóny

Vytvoření klíčů Vytvoření ZSK dnssec-keygen -a RSASHA1 -b 512 -n ZONE zonename Využívá algoritmus RSA SHA1 Délka 512 bitů DNSSEC klíč pro zónu (-n ZONE)

Vytvoření klíčů Vytvoření ZSK dnssec-keygen -a RSASHA1 -b n ZONE zonename Vytvoří 2 soubory Kzonename+ +.key Kzonename+ +.private.key je veřejnou částí klíče,.private je soukromou částí klíče

Vytvoření klíčů Vytvoření KSK dnssec-keygen -a RSASHA1 -b n ZONE -f KSK zonename Využívá algoritmus RSA SHA1 Délka 1024 bitů Větší klíč potřebuje více entropie! DNSSEC klíč pro zónu (-n ZONE) Má nastavení bitu Secure Entry Point (SEP)

Úkol: Vytvořte DNSSEC klíče Vytvořte dva DNSSEC klíče pro doménu udp53.cz v adresáři se zónou Použijte: -r /dev/urandom Jeden KSK (-f KSK) # dnssec-keygen -a RSASHA1 -b n ZONE -f KSK -r /dev/urandom udp53.cz Jeden ZSK # dnssec-keygen -a RSASHA1 -b 512 -n ZONE -r /dev/urandom udp53.cz

Připravte zónu ● Přidejte veřejné části obou KSK a ZSK k zóně, která má být podepsána ● Direktiva $INCLUDE v souboru se zónou ● $INCLUDE Kzonename+005+.key ● Nebo přímo vložit do souboru ● # cat Kzonename+005+*.key >> zonefile

Úkol: Přidejte do zóny klíče Přidejte do zóny vygenerované klíče # cat Kudp53.cz*.key >> udp53.cz Nebo $INCLUDE Kudp53.cz+005+.key

Podepsání zóny Přidejte RRSIG, NSEC a přiřazené záznamy k zóně dnssec-signzone [-o zonename] [-N KEEP/INCREMENT/UNIXTIME] [-k KSKfile] zonefile [ZSKfile] Název zóny (zonename) je implicitně název souboru (zonefile) Pojmenujte soubor podle zóny!

Podepsání zóny dnssec-signzone [-o zonename] [-N KEEP/INCREMENT/UNIXTIME] [-k KSKfile] zonefile [ZSKfile] Automatické přečíslování sériového čísla -N INCREMENT automaticky inkrementuje sériové číslo během podepisování -N UNIXTIME automaticky nastaví sériové číslo na aktuální unixový čas

Podepsání zóny dnssec-signzone [-o zonename] [-N UNIXTIME] [-k KSKfile] zonefile [ZSKfile] Implicitně se hledají takové klíče, které jsou obsaženy v zónovém souboru KSKfile je implicitně Kzonefile+005+ s nastavením bitu SEP ZSKfile je implicitně Kzonefile+005+ bez nastavení bitu SEP

Podepsání zóny dnssec-signzone [-o zonename] [-N UNIXTIME] [-k KSKfile] zonefile [ZSKfile] Výstupní soubor je zonefile.signed Seřazený podle abecedy Včetně RRSIG, NSEC a DNSKEY RR záznamů Mnohem větší než předtím!

Úkol: Podepište zónu udp53.cz ● Podepište zónu udp53.cz ● # dnssec-signzone -N UNIXTIME udp53.cz ● Vznikne: ● /var/cache/bind/zone/udp53.cz/udp53.cz.signed

dnssec-signzone - výstup # dnssec-signzone -k Kudp53.cz... udp53.cz Kudp53... dnssec-signzone: warning: udp53.cz:10: using RFC1035 TTL semantics Verifying the zone using the following algorithms: RSASHA1. Zone signing complete: Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked udp53.cz.signed

Aktualizujte named.conf Nahraďte zone "udp53.cz" { type master; file "zone/udp53.cz/udp53.cz"; }; Za zone "udp53.cz" { type master; file "zone/udp53.cz/udp53.cz.signed"; };

Úkol: Začněte poskytovat podepsanou zónu Aktualizujte named.conf, aby poskytoval podepsanou zónu, kterou jste vytvořili Znovunačtěte konfiguraci Bind 9 # rndc reload Ověřte zda-li se podepsaná zóna správně načetla # dig IN SOA # dig IN RRSIG # dig +dnssec IN A

Oznamte nadřazené zóně DNSSEC ● Pro vytvoření řetězu důvěry nyní musíte vložit DS RR záznam do nadřazené zóny ● Postupy se budou lišit podle organizací, ale musí být provedeny bezpečně ● Bude vyžadovat použití dsset- a/nebo keyset- soubor, který se vytvořil při podepsání zóny ● Pro.cz kontaktujte svého registrátora ● Registrátoři vloží DNSKEY přes EPP rozhraní

Nadřazená zóna bez podpory DNSSECu ● Ne všechny TLD podporují DNSSEC ● Ve skutečnosti podporuje v současnosti DNSSEC málo TLD (.cz,.se,.br,.bg,.pt,.ch,.li,.na,.nu,.org,.gov,.com...) ● Poskytněte váš DNSKEY těm stranám, u kterých chcete, aby ověřovaly vaši zónu.

Generování DLV RR záznamů Při podepisování zóny pro registrátora DLV přidejte přepínač “ ‑ l” (malé L) Pro DLV registr ISC: dnssec-signzone -N INCREMENT -l dlv.isc.org. udp53.cz V tomto bodě bude vytvořen soubor dlvset-udp53.cz, který je rovnou připraven k odeslání správci ISC DLV

Registrace v DLV ● Kontaktujte správce DLV registru pro instrukce jak prokázat vlastnictví zóny a platnost DLV RR záznamu ● Vložení vašeho DLV RR záznamu do registru DLV musí být provedeno důvěryhodným způsobem

Úkol: Podepište změny s DLV Přidejte do zónového souboru udp53.cz mail.udp53.cz. 600 IN A udp53.cz. 600 IN MX 10 mail.udp53.cz. Musíme zónu znovu podepsat!

Úkol: Podepište změny s DLV Uvedťe název zóny (origin) -o udp53.cz Uvedťe cílový podepsaný soubor -f udp53.cz.signed Explicitně uveďte DNSSEC klíče KSK: -k Kudp53.cz ZSK: Kudp53.cz Vygenerujte DLV záznamy pro DLV registr dlv.isc.org -l dlv.isc.org

Úkol: Podepište změny s DLV Podepište zónu udp53.cz

Úkol: Podepište změny s DLV Podepište zónu udp53.cz # dnssec-signzone -o udp53.cz -f udp53.cz.signed -k Kudp53.cz N UNIXTIME -l dlv.isc.org. udp53.cz Kudp53.cz Znovunačtěte zónu # rndc reload udp53.cz

BIND 9.7 ● „DNSSEC for Humans“ ● Plně automatické podepisování zóny – allow-update+ key-directory + auto-dnssec parametry zóny – named sám detekuje ZSK/KSK, podepíše a sleduje metadata použitých KSK/ZSK – Možnost vyvolat přepodepsání – rndc sign ● Metadata klíče – Publish, Active, Revoke, Delete

BIND 9.7 ● Vylepšený dnssec-signzone – -S – „smart signing“ – Využívá metadata klíčů k podpisu – Klíč není nutno includovat do zóny ● Relativní čas – now+2y ● Hlídání pevných bodů důvěry – RFC5011

Problematika pravidelné údržby

Pravidelná údržba zóny ● Podpisy mají životnost ● Datum „vzniku“ – 1 hodina před spuštěním ● dnssec-signzone ● Datum expirace – 30 dní po spuštění ● dnssec-signzone ● Expirované podpisy způsobí, že zóna nepůjde ověřit a pro validující resolver „zmizí“ ● Přepodepsat pokaždé, když upravíte zónu – nebo minimálně každých 30 dnů (mínus TTL) musíte znovu spustit dnssec-signzone

Pravidelná údržba klíče ● Klíče je zapotřebí střídat ● Nemají „datum expirace“ ● Čím déle je klíč veřejně viditelný, tím větší je pravděpodobnost, že bude prolomen ● Prolomení (zcizení) klíče může vést k potřebě „výměny“ klíče

Pravidelná údržba klíčů ● RFC 4641 – DNSSEC Operational Practices ● Klíč o síle 1024b stačí měnit jednou ročně ● Jsou dostupné automatické nástroje ● RIPE DISI tools ( ● DNSSEC Tools ( ● ZKT ( ● OpenDNSSEC

Výměna (rollover) klíčů

Dva způsoby výměny klíčů ● Předčasné publikování (pre-publish) ● Dvojitý podpis (double signature)

Předčasné publikování ● Používá se pro výměnu ZSK ● Do zóny se vloží další klíč ● Nutné explicitně specifikovat ZSK klíč používaný k podpisu ● Po uplynutí TTL se může začít podepisovat novým klíčem ● Po uplynutí TTL můžeme starý ZSK odstranit

Předčasné publikování (výměna ZSK) initial new DNSKEY new RRSIGs DNSKEY removal SOA0 SOA1 SOA2 SOA3 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY11 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) DNSKEY TTLMAX ZONE TTL 1 – KSK 10 – starý ZSK 11 – nový ZSK

Úkol: Vyměňte ZSK – fáze 1 Vygenerujte nový ZSK Přidejte nový ZSK do zóny Podepište zónu udp53.cz.signed starým klíčem (explicitně uveďte kterými klíči podepisujete) Musíte uvést i používaný KSK

Úkol: Vyměňte ZSK – fáze 1 Vygenerujte nový ZSK # dnssec-keygen -a RSASHA1 -b 512 -n ZONE -r /dev/urandom udp53.cz. Přidejte nový ZSK do zóny Podepište zónu udp53.cz starým klíčem (explicitně uveďte kterými klíči podepisujete) # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz udp53.cz Kudp53.cz.+005+

Úkol: Vyměňte ZSK – fáze 1 Ke každému RRsetu by měl existovat pouze jeden podpis s keytagem starého ZSK, DNSKEY bude mít podpisy dva – starý ZSK a KSK Znovunačtěte zónu # rndc reload udp53.cz

Úkol: Vyměňte ZSK – fáze 2 (Virtuálně) počkejte až se zóna zpropaguje na nové nameservery plus TTL DNSKEY záznamů Podepište zónu novým klíčem, starý zůstává v zóně

Úkol: Vyměňte ZSK – fáze 2 (Virtuálně) počkejte až se zóna zpropaguje na slave nameservery plus TTL DNSKEY záznamů Podepište zónu novým klíčem, starý zůstává v zóně: # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz udp53.cz Kudp53.cz.+005+

Úkol: Vyměňte ZSK – fáze 2 Ke každému RRsetu by měl existovat pouze jeden podpis s keytagem nového ZSK, DNSKEY bude mít podpisy dva – nový ZSK a KSK Znovunačtěte zónu # rndc reload udp53.cz

Úkol: Vyměňte ZSK – finále Opět (virtuálně) počkejte až se zóna zpropaguje Odstraňte starý klíč ze zóny Přepodepište!

Úkol: Vyměňte ZSK – finále Opět (virtuálně) počkejte až se zóna zpropaguje Odstraňte starý klíč ze zóny Přepodepište! # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz udp53.cz Kudp53.cz Znovunačtěte zónu # rndc reload udp53.cz

Dvojitý podpis ● Používá se u KSK ● Všechny klíče jsou podepsány dvěma (a více) KSK klíči ● Nadřazená zóna dostane oba dva (a více) klíče

Dvojitý podpis (změna KSK) initial new DNSKEY DNSKEY removal SOA0 SOA1 SOA2 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY2 DNSKEY2 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG2(DNSKEY) RRSIG2(DNSKEY) DNSKEY/MAX ZONE TTL 1 – starý KSK 10 – ZSK 2 – nový KSK

Dvojitý podpis (změna KSK) – spolupráce s nadřazeným initial new DNSKEY DS change DNSKEY removal Parent: SOA > SOA > RRSIGpar(SOA0) > RRSIGpar(SOA1) > DS > DS > RRSIGpar(DS) > RRSIGpar(DS) > Child: SOA0 SOA > SOA2 RRSIG10(SOA0) RRSIG10(SOA1) > RRSIG10(SOA2) > DNSKEY1 DNSKEY > DNSKEY2 DNSKEY > DNSKEY10 DNSKEY > DNSKEY10 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) > RRSIG2 (DNSKEY) RRSIG2 (DNSKEY) > RRSIG10(DNSKEY) RRSIG10(DNSKEY) > RRSIG10(DNSKEY) – starý KSK 10 – ZSK 2 – nový KSK DNSKEY TTL

Úkol: Vyměňte KSK Vygenerujte nový KSK Vložte nový KSK do zóny Podepište zónu udp53.cz pomocí obou KSK a nového ZSK

Úkol: Vyměňte KSK Vygenerujte nový KSK # dnssec-keygen -a RSASHA1 -b n ZONE -f KSK -r /dev/urandom udp53.cz Vložte nový KSK do zóny Podepište zónu udp53.cz pomocí obou KSK a nového ZSK # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz udp53.cz Kudp53.cz.+005+

Úkol: Vyměňte KSK Ke každému RRsetu by měl existovat pouze jeden podpis s keytagem ZSK, DNSKEY bude mít podpisy tři – ZSK, starý KSK a nový KSK Znovunačtěte zónu # rndc reload udp53.cz

Úkol: Vyměňte KSK „Pošlete“ nový klíč do nadřazené zóny „Počkejte“ až se nový klíč zpropaguje Odstraňte starý KSK Podepište zónu udp53.cz pomocí nového KSK

Úkol: Vyměňte KSK „Pošlete“ nový klíč do nadřazené zóny „Počkejte“ až se nový klíč zpropaguje Odstraňte starý KSK Podepište zónu udp53.cz pomocí nového KSK # dnssec-signzone -o udp53.cz -f udp53.cz.signed -N UNIXTIME -k Kudp53.cz udp53.cz Kudp53.cz.+005+

Bind 9.7 – automatizace ● Zatím neumí vygenerovat nové klíče – auto-dnssec: allow | maintain | create ● Allow – povolí zónu podepsat – rndc sign zonename – nsupdate update add zone DNSKEY ● Maintain – Nečeká na sign command – Obnovuje podpisy, mění klíče na základě metadat ● Create – Rezervováno – Bude umět vygenerovat nové klíče a provést key roll

BIND klíče ● Nové atributy, uchované v textové podobě – Nesouvisí s protokolem, pouze pro potřeby BINDu – Publish, Activate, Revoke, Inactivate, Delete

Bind automatizace ● Pozor na: – práva ke klíčům – Privátní část musí byt čitelná pro uživatele pod kterým beží BIND – Zápis do adřesárů – BIND bude vytvářet update journal

OpenDNSSEC ● ● Signing + key-rolling + audit ● Konfigurováno v 3 (4) xml ● Potřeba HSM – SoftHSM – SW emulace HSM

OpenDNSSEC -postup ● Init HSM – Závisí na HSM ● ODS Setup – ods-ksmutil setup – Připraví DB pro OpenDNSSEC metdata ● Nastavení v xml – conf.xml – obecná nastavení OpenDNSSEC, cest a HSM – kasp.xml – Key And Signature Policy – klíče, podpisy – zonelist.xml – nastavení zón, vstupní/výstupní soubory – zonefetch.xml – pro AXFR ● ods-control start

OpenDNSSEC - postup ● Podrobné video návody/školení: –

Testování a ladění DNSSECu

Testování DNSSECu ● Nyní, když distribuujete podepsané DNSSEC RR záznamy, funguje to? ● DNSSEC může být laděn pouze pomocí příkazů dig nebo drill a date ● Vizualizace (

Dotazování na DNSSEC ● DNS odpověď, na dotaz koncového klienta, který je podepsán a zvalidován, obsahuje požadovaný RRset ● DNS odpověď, na dotaz koncového klienta, který není podepsán a zvalidován, obsahuje požadovaný RRset

Dotazování na DNSSEC ● DNS odpověď, na dotaz koncového klienta, který je podepsán a není validní (tj. data byla změnana, nebo podpis nesedí), vrátí RCODE=SERVFAIL ● Pro aplikace (a uživatele) se bude doména jevit jako „neexistující“ ● Příznak CD v hlavičce umožní, aby koncový klient dostal v DNS odpovědi i špatně zvalidovaná data

Případy SERVFAIL ● Chybí podpis pro některý použitý alg. ● Podpis je mimo životnost ● DS/DNSKEY mismatch ● Insecure odpověď od zóny kde se očekává DNSSEC – tj. nadřazená má pro ni DS záznam – Úkol: Jak resolver zjistí, že delegovaná zóna není podepsaná?

výstup dig – bez DNSSECu dig ;; [..] status: NOERROR ;; flags: qr rd ra; Správná odpověď; odpověď (qr), požadovaná rekurze (rd), rekurze k dispozici (ra)

výstup dig – bez DNSSECu dig A ;; [..] status: NOERROR ;; flags: qr rd ra; Z validujícího resolveru – tohle jsou garantovaná správná data

výstup dig – bez DNSSECu dig A ;; [..] status: NOERROR ;; flags: qr rd ra; Ale jak víte, že váš resolver provádí validaci?

výstup dig – s DNSSECem dig +dnssec A ;; [..] status: NOERROR ;; flags: qr rd ra ad Jako předtím, ale tentokrát autentizované!

Dotazování na DNSSEC ● Pro vrácení příznaku AD musí mít resolver provádějící ověření pevný bod důvěry, který může být zpětně vystopován (pomocí DS RR záznamů) ● Pokud řetěz důvěry nevede k pevnému bodu důvěry, nebude příznak AD nastaven, ale RRSIG záznamy budou i tak vráceny

výstup dig – DNSSEC dig +dnssec A IN A IN RRSIGA dnssec.cz. V0JXuwsLAEjwXnigUMiqIRUzNVEGy4OzrjA48XJfzfXBti5UftB7kLcA jVZOl5CsobucSm5jFNfo4FSh8jhgD0CLEPnxiqfCeZ/TvHdlr3OnlecP IqJDTqBuvA8e4z3GO8bM3Yff+DBOQgORZ2cC7xGnfEMWWrCHnyRjmV6t 678= Pokud je AD nastaveno, validující resolver má pevný bod důvěry, pokud ne, pořád máme data, která můžeme ověřit sami

Dotazování na DNSSEC ● Pokud víme, že komunikujeme s validujícím resolverem a dostaneme zpět SERVFAIL, může se jednat o nevalidní podepsaná data ● Pokud je to tak, nastavení bitu CD v dotazu způsobí, že resolver i tak zašle nevalidní data

výstup dig – DNSSEC dig +dnssec +cd A IN A IN RRSIGA rhybar.cz. XXXXXXXXXX XXXXXXXXXX Neplatný záznam RRSIG (XXXXXXXXXX), ale s příznakem +cd, proto dostaneme odpověď

výstup dig – DNSSEC dig +dnssec +cd A IN A IN RRSIGA rhybar.cz. XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw7 9jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6 lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2Ftw NOc=

výstup dig – DNSSEC dig +dnssec +cd A IN A IN RRSIGA rhybar.cz. XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw7 9jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6 lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2Ftw Noc= Data v podpisu ukazují, že podpis je expirovaný Porovnejte s aktuálním datem

Dotazování na DNSSEC ● Všimněte si, že je snadné zkontrolovat datum na podpisech ● Je mnohem těžší (není v lidských silách?) najít chybu v klíči samotném ● Předchozí příklad je krajně nepřirozený (XXX?)‏

Dotazování na DNSSEC ● Další problém, který může nastat je chybějící nebo jiný hash nebo klíč ● Chybí DS nadřazené zóně ● Chybí DNSKEY v aktuální zóně ● DS v nadřazené zóně není stejný jako DNSKEY v podřazené zóně ● Není těžké určit ani tuto chybu

výstup dig – DNSSEC dig +dnssec +cd IN A IN RRSIGA udp53.cz. XEkXkv9MCRiGbxO9T0dkNY+3y5EZRB6s6YOk0pFAVUL/y8VDeJphc8yb K6E/YLvraItdGvIvpy4P1OuIY09BGQ== Podpis byl vytvořen s klíčem 46704

výstup dig – DNSSEC dig +cd +multi udp53.cz DNSKEY udp53.cz IN DNSKEY ( BEAAAAO2oQi7U9m9i495S/XoAk+j8QxxnBHon6fa7nlN 7xoqrSr/xzy3+IerFS1KgJz1gJGbTsGV0WI1/bvAzIEK Uh+p ) ; key id = DNSKEY v zóně existuje Pokud ne, nepůjde ověřit!

výstup dig – DNSSEC dig +cd +multi udp53.cz DNSKEY udp53.cz IN DNSKEY ( B[...]p ) ; key id = udp53.cz IN DNSKEY ( B[...]J ) ; key id = ZSK DNSKEY v zóně existuje Připojený KSK je 64249

výstup dig – DNSSEC dig udp53.cz DS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 DS v nadřazené zóně neexistuje

výstup dig – DNSSEC dig udp53.cz DS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 Server bude vracet odpovědi, ale bez příznaku „AD“ Neexistuje řetěz důvěry až k pevnému bodu důvěry Není zaregistrovaný DS záznam v doméně.cz

Další možné problémy DNSSEC ● „Chytrý“ firewall/home gateway ● Neumí EDNS0 ● Zahazuje UDP větší než 512 byte ● Zahazuje neznámé RR typy ● Modifikuje obsah RR záznamů ● Zahazuje neznámé příznaky DNS paketu

DNSSEC plugin ●

Cíle školení ● Pochopit základní principy DNSSEC ● Umět nakonfigurovat validující resolver ● Umět nakonfigurovat autoritativní server ● Umět podepsat vlastní zónu ● Umět v podepsané zóně vyměnit klíče ● Umět najít chybu, když nefunguje validace

Reference ● ● ● ● RFC1034, 1035 (DNS) ● RFC2181 (DNS Clarification) ● RFC2671 (EDNS0) ● RFC4033, RFC4034, RFC4035 (DNSSEC) ● RFC5011 (Trust Anchor Update) ● RFC5155 (NSEC3)

160 Děkuji za pozornost Matej Dioszegi Kde získat informace o dalších aktivitách sdružení CZ.NIC? Web Blog Konference blog.nic.cz