Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

Akademie DNSSEC Matej Dioszegi 30.11.2011.

Podobné prezentace


Prezentace na téma: "Akademie DNSSEC Matej Dioszegi 30.11.2011."— Transkript prezentace:

1 Akademie DNSSEC Matej Dioszegi

2 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í

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

4 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

5 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

6 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

7 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

8 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

9 DNS dotaz

10 DNS paket Query Response

11 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čí

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

13 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

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

15 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ě

16 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

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

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

19 DNSSEC Základní principy a pojmy

20 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”

21 Základní principy DNSSEC

22 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

23 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

24 Ř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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 Příklad: doména onde.cz

35 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

36 Nové RR záznamy

37 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=

38 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[...]

39 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

40 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

41 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

42 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

43 Konfigurace validujícího resolveru Bind 9.7 & Unbound

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

45 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

46 Ú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"

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

48 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 (".")

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

50 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.)

51 Pevné body důvěry ● Pro.cz používat root-anchor ● ● Poštovní konference – informace o změnách: ● ● https://lists.nic.cz/mailman/listinfo/dnssec-announce https://lists.nic.cz/mailman/listinfo/dnssec-announce

52 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ů

53 Ú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

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

55 Ú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

56 Ú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

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

58 Ú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

59 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"

60 Ú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

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

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

63 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“

64 Domain Lookaside Validation & ITAR

65 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

66 DLV

67 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.

68 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.; ● };

69 ISC registr DLV https://dlv.isc.org/about/using

70 Ú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

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

72 Konfigurace autoritativního serveru

73 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ů

74 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

75 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“;

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

77 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

78 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

79 Podepsání zóny

80 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)

81 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

82 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)

83 Ú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

84 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

85 Ú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

86 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!

87 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

88 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

89 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!

90 Ú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

91 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

92 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"; };

93 Ú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

94 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í

95 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.

96 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

97 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

98 Ú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!

99 Ú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

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

101 Ú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

102 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

103 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

104 Problematika pravidelné údržby

105 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

106 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

107 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 (www.ripe.net/disi/)www.ripe.net/disi/ ● DNSSEC Tools (www.dnssec-tools.org)www.dnssec-tools.org ● ZKT (www.hznet.de/dns/zkt/)www.hznet.de/dns/zkt/ ● OpenDNSSEC

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

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

110 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

111 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

112 Ú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

113 Ú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+

114 Ú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

115 Ú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ě

116 Ú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+

117 Ú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

118 Ú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!

119 Ú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

120 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

121 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

122 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

123 Ú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

124 Ú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+

125 Ú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

126 Ú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

127 Ú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+

128 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

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

130 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

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

132 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

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

134 Testování a ladění DNSSECu

135 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 (http://dnsviz.net/)

136 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

137 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

138 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á?

139 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)

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

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

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

143 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

144 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

145 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

146 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ěď

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

148 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

149 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?)‏

150 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

151 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

152 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!

153 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

154 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

155 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

156 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

157 DNSSEC plugin ●

158 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

159 Reference ● https://www.nic.cz/dnssec/ https://www.nic.cz/dnssec/ ● ● ● RFC1034, 1035 (DNS) ● RFC2181 (DNS Clarification) ● RFC2671 (EDNS0) ● RFC4033, RFC4034, RFC4035 (DNSSEC) ● RFC5011 (Trust Anchor Update) ● RFC5155 (NSEC3)

160 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


Stáhnout ppt "Akademie DNSSEC Matej Dioszegi 30.11.2011."

Podobné prezentace


Reklamy Google