LPS:DNSSEC - Provozní dokumentace

Z HelpDesk
Verze z 18. 9. 2017, 14:50, kterou vytvořil Valtri (diskuse | příspěvky) (→‎Rotace klíčů: - zmínka o trust-anchors)

V tomto dokumentu jsou technické informace týkající se DNSSEC.

Informace

Testovací DNSSEC servery:

  1. erosek.zcu.cz: primární + rekurzivní DNS (autoritativní DNS)
  2. orisek.zcu.cz: validující DNS forwarder (lze použít na testování DNSSEC i na ZČU)

Rozdíly oproti produkčnímu DNS:

  • povolené DNSSEC
  • modifikovaná data zón - NS záznamy nahrazené za erosek.zcu.cz
  • podepsané zóny
  • lokální "ostrov důvery" se všemy KSK klíči v zónách ZČU na erosek.zcu.cz

Předběžný plán:

1. krok: oddělený rekurzivní resolver pro 1. segment s povoleným DNSSEC

2. krok: nasazení DNSSEC v zónách ZČU (bez delegace a pak s delegací klíčů)

3. krok: povolit DNSSEC postupně na všech lokálních rekurzivních resolverech

Teorie

Čas

Ověřování DNSSEC závisí na správně nastaveném čase.

V případě použití NTP je potřeba použít IP adresy místo DNS jména, aby se zamezilo problému "slepice-vejce". Na DNS serverech ZČU to není potřeba - pro domény clock1.zcu.cz a clock2.zcu.cz jsou univerzitní DNS servery (vč. slavů) autoritativní.

Typy záznamů

DNSKEY

Zónové klíče (ZSK - Zone Singing Key) a "klíčové" klíče (KSK - Key Signing Key).

  1. zónový klíč (ZSK):
    • bývá menší, aby byly kratší podpisy (v případě RSA je default 1024 bitů, oproti 2048 u KSK)
    • podpis jednotlivých RR
  2. klíčový klíč (KSK):
    • podpis ZSK
    • vstupní bod důvěry pro zónu (SEP) - otisk patří do nadřazené zóny

Klíč může být jeden a poskytovat obě role: ZSK (podepisování zón) i KSK (podepisování klíčů - vstupní bod důvěry.

KSK i ZSK může být několik (kvuli rotacím). Na funkci DNSSEC musí být alespoň jeden platný řetěz.

Formát:

DOMAIN. IN DNSKEY FLAGS PROTOCOL ALG DATA

FLAGS:

  • 256 - zone (ZSK)
  • 257 - zone + SEP (KSK)

PROTOCOL:

  • 3 - vžycky, jinak je DNSKEY invalid

ALG DNS Security Algorithm Numbers:

  • 5 - RSASHA1 (default) - abclinuxu.cz ibesip.cz isc.org o2.cz pilsfree.cz root.cz t-mobile.cz
  • 7 - NSEC3RSASHA1 - aktualne.cz muni.cz
  • 8 - RSASHA256 - . debian.org freebsd.org iana.org
  • 10 - RSASHA512 - cz cesnet.cz metacentrum.cz
  • 13 - ECDSAP256SHA256 - 4chan.org auto.cz cloudflare.com cvut.cz dnssec.cz e15.cz
  • 14 - ECDSAP384SHA384

(SHA1 obsolete, RSASHA1 jen NSEC)

DS

Otisk klíče. Používá se v delegaci - zabezpečená informace v nadřazené zóně o "klíčovém" klíči (KSK) vnořené zóny.

Formát:

DOMAIN. IN DS KEY_ID ALG DIGEST DATA

ALG DNS Security Algorithm Numbers:

  • 10 - RSASHA512
  • 13 - ECDSAP256SHA256
  • 14 - ECDSAP384SHA384

DIGEST Digest Algorithms:

  • (0 - rezerovováno)
  • 1 - SHA-1
  • 2 - SHA-256

NSEC

Negativní informace - důkaz neexistence záznamu. Dělá se přes odkaz na další RR.

Je např. potřeba mít zabezpečenou informaci v nadřazené zóně typu "u téhle zóny nemám DS".

NSEC3

Kvuli odkazům mezi RR lze pomocí NSEC projít celou zónu. NSEC3 je bezpečnější varianta NSEC, kde se použitím hashování skryje informace o skutečném záznamu, co následuje.

Formát:

DOMAIN_HASH.ZONE. TTL_RR IN NSEC3 HASH_ALG FLAGS ITERATIONS SALT ( DATA RR_TYPE )

HASH_ALG DNSSEC NSEC3 Hash Algorithms

  • (0 - reserved)
  • 1 - SHA-1

FLAGS DNSSEC NSEC3 Flags

  • 1 - opt-out (něco s delegacemi a záznamy bez podpisů)

ITERATIONS - počet iterací hashovacího algoritmu (typicky 10)

SALT - sůl pro hashování

NSEC3PARAM

Jeden záznam pro zónu. Parametry obsažené v každém NSEC3 záznamu jsou vyzobnuté do tohoto extra záznamu.

Formát:

ZONE. 0 IN NSEC3PARAM HASH_ALG FLAGS ITERATIONS SALT

Význam jako u #NSEC3, TTL je vždy 0.

RRSIG

Podpis DNS záznamu (RR).

Formát (příklad "A" záznam):

TTL_RR RRSIG A ALG LABELS TTL_RRSIG ( VALID_TO VALID_FROM ZSK_ID ZONE. DATA )

ALG DNS Security Algorithm Numbers

  • 10 - RSASHA512
  • 13 - ECDSAP256SHA256
  • 14 - ECDSAP384SHA384

LABELS - počet domén (labelů) ve jméně

Všechny RR jsou podepsané (SOA, A, PTR, ... a také NSEC3, DNSKEY, DS, ...).

Rotace klíčů

Dva způsoby rotace:

  • předem vystavit nový klíč (pro ZSK)
  • používat starý i nový paralelně (pro KSK)

Pokud zóny, pro které jste konfigurovali trust-anchors, změní své klíče, budete muset znovu nakonfigurovat také trust-anchors.

Pozor na KSK - nutná i změna v delegaci. Viz #KSK.

ZSK

Metoda předpublikace:

  1. vystavíme nový klíč
  2. počkáme, až se rozšíří
  3. začneme podepisovat novým klíčem
  4. počkáme až zmizí staré podpisy
  5. vymažeme starý klíč

Máme vždy jednu sadu podpisů. Používá se u ZSK (pokud bychom ppoužili u KSK, vyžadovalo by dvojí změnu v nadřazené zóně).

KSK

Metoda dvojího podpisu:

  1. vystavíme nový klíč, podepíšeme oběma
  2. počkáme, až se rozšíří
  3. vyměníme DS záznam v nadřazené zóně
  4. počkáme, až se změna DS rozšíří
  5. odstraníme starý klíč a staré podpisy

Jediná komunikace s nadřazenou zónou. Používá se u KSK (u ZSK by enorm2 narostl objem dat).

Postupy

Test doménového záznamu

Pro analýzu lepší používat delv místo dig. delv je doporučovaný pro dělání plné validace DDNSSEC (tu lze vypnout volbami +noroot a +novld).

1) delv 

delv +multi -t DS cesnet.cz

delv +multi -t NS zcu.cz

(+multi je na hezčejší výstup u klíčů do více řádek)

(+noroot vypne DNSSEC validaci za použití root anchors)

(+novld vypne DNSSEC validaci za použití dosluhujícího VLD)

2) dig

V případě použití dig koukat na flagy:

  • AD = Authenticated Data (for DNSSEC only; indicates that the data was authenticated)
  • AA = Authoritative Answer

Při AA nemá ověřování smysl, flag AD může vrátit pouze rekurzivní resolver.

V dotazu lze serveru poslat flag CD = Checking Disabled. 

dig +multi +dnssec -t NS zcu.cz

(+multi je na hezčejší výstup u klíčů do více řádek)

(+dnssec ukáže i záznamy specifické pro DNSSEC, u delv je to default)

Ruční ověření delegace

Získání DS z DNSKEY (příklad s KSK z root zóny): 

cat << EOF > root1.key
.			90378	IN	DNSKEY	257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=
EOF
dnssec-dsfromkey -2 root1.key

Pak porovnat získaný DS se záznamem v nadřazené zóně (v případě root zóny s trust anchors na iana.org/dnssec).

Vyrobení klíčů

Z algoritmů bych volil buď ten použitý v CZ NIC (RSA512, v ČR 4. nejpoužívanější) nebo eliptickou šifru (ECDSAP256SHA256, v ČR 3. nejpoužívanější). První dva nejpoužívanější algoritmy využívají dosluhující hashovací algoritmus SHA-1 (i když v ISC bind je to stále default ;-)). Default algoritmus navíc neumí NSEC3.

Rychlotest na zóně 228.147.in-addr.arpa:

time size
RSASHA512 0m6.164s 1,3M -> 16M
ECDSAP256SHA256 0m57.554s 1,3M -> 12M

Best-practices:

  • klíče se vyrábí vždy pár pro každou zónu (zónový se vymění snadněji, může být menší, ...)
  • jiný pár pro každou zónu (teoreticky jde o jen kosmetickou věc - rotace klíšů pak lze dělat postupně apod., prakticky jde i o omezení utilitek bindu, které lze řešit ručním poeditováním klíčů)
  • KSK i ZSK musí mít stejný algoritmus

Postup (nahradit zcu.cz za správnou zónu):

1. Zónový (ZSK): 

dnssec-keygen -3 -r/dev/random -a RSASHA512 -b 1024 -n ZONE zcu.cz
#dnssec-keygen -3 -r/dev/random -a ECDSAP256SHA256 -n ZONE zcu.cz

2. Klíčový (KSK): 

dnssec-keygen -3 -r/dev/random -f KSK -a RSASHA512 -b 2048 -n ZONE zcu.cz
#dnssec-keygen -3 -r/dev/random -f KSK -a ECDSAP256SHA256 -n ZONE zcu.cz

Aktualizace bind.keys

Návrh postupu na výměnu root klíčů:

  1. vzít soubor /etc/bind/bind.keys z podepsaného balíku aktuálního OS
  2. ověřit klíče na základě postupu #Ruční ověření delegace s root anchors na https://iana.org/dnssec
  3. (doplnit vlastní klíče, pokud jsou)

Cesty

Výběr důležitých souborů a adresářů pro správu DNSSEC, vše na volupta.zcu.cz.

/var/sauron/keys

Adresář s klíči pro DNSSEC. Používá se pro podepisování (privátní části) a pro vkládání do podepisovaných zón (veřejné části).

Změny: ručně administrátory

/var/sauron/sign.sh

Hlavní podepisovací skript. Identifikátory používaných klíčů jsou přímo v něm.

Změny: ručně administrátory

/var/sauron/dns9-additive/zcu/zones/db.dnssec.*

Soubor s aktuálně používanými klíči (aktivními i pasivními). Udržováno poloautomaticky podepisovacím skriptem.

Změny: (jen kosmetická věc) zkopírovat z dns9-copy při změně klíčů

/var/sauron/dns9-*/*/dsset-ZONA.

Automaticky generované soubory s DS záznamy pro použití v nadřazených zónách (dsset-fek.zcu.cz. a dsset-fpe.zcu.cz. se používají při podepisování zóny zcu.cz).

Změny: automaticky podepisovacím skriptem

Uživatelská dokumentace (návrh)

Na rekurzivních serverech DNS na ZČU je povoleno ověřování pomocí DNSSEC. V případě, že podle hierarchie DNS má být daná zóna ověřena pomocí DNSSEC a ověření selhalo, DNS dotaz selže na SERVFAIL.

Příklad (v univerzitní síti se zapnutým ověřováním DNSSEC musí selhat na SERVFAIL): 

host rhybar.cz

Detaily lze analyzovat pokročilejšími nástroji, např. dig.

Poznámka: DNSSEC se na univerzitních resolverech neuplatňuje pro doménová jména ZČU - tam se jedná o autorizovaná data.

Poznámka 2: DNSSEC si může ověřovat i sám klient, včetně zón na ZČU (lokální forwarder, doplněk prohlížeče, ...).

Pokročilejší příklady: 

#autorizovaná data na ZČU (AA flag):
dig www.zcu.cz

#zóna podepsaná DNSSEC a úspěšná validace (AD flag):
dig 4chan.org

#zóna podepsaná DNSSEC, ale podvržená nebo chybná data (stav SERVFAIL)
dig rhybar.cz

#získání odpovědi i přes nevalidující DNSSEC (nastavení flagu CD v dotazu - check disabled):
dig +cd rhybar.cz

Odkazy

Citováno z „https://helpdesk.zcu.cz/index.php?title=LPS:DNSSEC_-_Provozní_dokumentace&oldid=52080“