LPS:DNSSEC - Provozní dokumentace

Z HelpDesk
Verze z 2. 10. 2017, 18:11, kterou vytvořil Valtri (diskuse | příspěvky) (→‎Rotace klíčů: - duplicitní info)

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 použ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 enormě narostl objem dat).

KSK+ZSK

Není běžně potřeba. Metoda dvojího podpisu pro KSK a metoda předpublikace pro ZSK.

KSK+ZSK+algoritmus

Není běžně potřeba. Změna šifrovacího algoritmu je náročnější - dvojice KSK i ZSK musí používat stejný algoritmus, a tak je třeba vyměnit oba klíče a kontrolní nástroje varují před použitím šifrovacího algoritmu pouze mimo RRSIG. Při podepisování nástrojem dnssec-signzone přeskočit kontroly volbou -P, případně zvolit bezpečnější metodu dvojího podpisu pro oba dva klíče.

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

Konfigurační tipy

Logování DNSSEC záležitostí

logging {
       channel dnssec_syslog {             // a DNSSEC log channel
               syslog daemon;
               print-time yes;        // timestamp the entries
               print-category yes;    // add category name to entries
               print-severity yes;    // add severity level to entries
               severity debug 3;      // print debug message <= 3 t
        }; 
  category dnssec  {dnssec_syslog;};
}

Trust-anchors

Ostrov důvěry (pouze pro rekurzivně vyhodnocované zóny - forwardeři, klienti, ...; není potřeba na DNS slavu zóny).

Do named.conf.options (nebo named.conf.keys, ...):

trusted-keys {
        "1.0.1.0.1.0.f.f.8.1.7.0.1.0.0.2.ip6.arpa." 257 3 10 "AwEAAbot1Db+UKP69a+JjKBH2U9JIU+jQpp5stBRCStLH+Ez3r81Vjkq lWb6ob79Ubh9k9jQPEqywoMCUP3SrtmOFwgQt8WTOUuPQhBQ4Ed91hla MgTrBkmHzias7hNYXvjtjYjkcCw6oW54pIcsM6oxcNWBaOiC+Opr8bv+ +iAoXlPMVpYvudLgePfjkxGAwT1o3UsEoQrOaM31kfbVqbEz6Z+4ygqA pTyugw7Zer+SaGu43lgCTtf70cXFTdfbVkOBM/M4dEHFt4Gwk0bM5+TH at5TyNSD6SEXqsBvNt6sxlGAB5EbbWReYQ5YiehDnIU861/HLGmGmDGB Z0GlC6wYyc0=";
        "1.0.8.1.8.1.7.0.1.0.0.2.ip6.arpa." 257 3 10 "AwEAAbBc9tNPIqDUqfr8NUtXIOMbkVBJ42EJgm7XfdIyhPYukigFV62I m6byxj6b3VVHIIQ4Vr7FJcCKg8bFs3ap9xdJcw0QliuHmnJV0EhGqhut zoIXnYNU8rELFUv3+T41L/du0F3ilLpLvjAFhfxzA4tLDoYKvhsaETT3 eLnIQQdkVasMmXd3v9pwweOd++fwFLXxf7+Z6nPuDgz4zVRBrcU3Sk8K 3JP+Z4jv0faxwNgHS1DoaCUqTRwaWQ9KXJxKhCi20dqU0h+yUiERHWnj sjIetbaRsckCJ+BWsChP8cYdzWOJ9jV1l0N1aZMX19LebZAn4VBJpQST LUq38qICgQM=";
        "228.147.in-addr.arpa." 257 3 10 "AwEAAaNLt237ui+3udocdxL+11AVpmGyx6Sx8Wrdssk8f8XN+NMUROGs jYie7AUMA8nFSBJfTFLMXy3cgVP+uklerHqILBI9zDTcIh7lMZ/EvhcY hZckj2JlVv/gcnhW7s7a7kJLINuVfgdk8Mo7rN4/8QyB2E49rfJRw2P5 hxSPLqBpG7FzTBtZOxSaxd0HkJ8R5CB419uEbnEgdqdXouKF6gbLG/MT 468Ttn75vA/WLeh7A2ekRIxalPRHUSYVSxZdA2EognFcztJV7EnFlg1u yOhXnxCsDpP+tZxosZBFz3taYopkkHuWwX/J1nZdL314WVHWcF71MisI UXG2ELRIn4c=";
        "zcu.cz." 257 3 10 "AwEAAbTw3jwU0kRFEKFzlsczlE8QJ4oqVcLBsi9UAgevejqBkrRsR0nPoJebGvR7IStQ/ytzQEnEDAsYJXBZmNhiesWqDeSSiRJHoTHrLcbVYGTIdPwFQWdm89yB8/QvEfTqnQ/bqO0md1MN/GweA+vLyyenonp45u5wtVxk6uOCRj/TztIDG5Dr3DJ1JDM/b4Gc30rJTVPySFJZME3Xtq8DYyYPBR54JrWQZzN09/xU15M0BrW3HKq+Dh3U45/DBiflvD6wtYR62ZC+XyUIfVRDNhTosG3RYvgkdTHwBoph7xqOa3Vgkd1dSeiTeW8nLNCFsK9cHkx0xak0dMiFv9NH2mM=";
};

Poznámka: zřejmě by se nemělo dávat do /etc/bind/bind.keys - ISC bind si a tohoto souboru vyzobne pouze sekci managed-keys, ale jinak se to neincluduje.

Poznámka 2: Utilita delv hledá trust-anchors v /etc/bind.keys.

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. DNSSEC si však může ověřovat i sám klient (včetně zón na ZČU) - lokální forwarder, doplňky 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