DNSSEC a BIND 9.9

25.10.2014

Vzhledem k neuspokojivé situaci v oblasti bezpečnosti DNS a X.509 infrastruktury je rozumné, když administrátoři serverů nespoléhají pouze na holé DNS ani pouze na X.509 certifikáty a “důvěryhodné” certifikační autority.

Prvním prostředkem, jak zvýšit zabezpečení je DNSSEC (DNS Security) a návaznými jsou DANE (DNS-based Authentication of Named Entities) a DKIM (Domain Keys Identified Mail).

V tomto článku se budu zatím zabývat DNSSECem, později přibudou postupně ostatní. Pro porozumění předpokládám základní znalost DNS a konfigurace BIND sw. Pro ty, kdo tuto znalost nemají, doporučuji http://www.root.cz/serialy/dnssec-a-bezpecne-dns/ - článek na rootu, kde jsou vysvětleny základy DNS a navazuje hezký seriál o DNSSECu.

Zabývám se zde pouze úvodem do DNSSECu a konfigurací na CentOS 7 se software BIND 9.9 a vyšší, konkrétně konfigurací autoritativního serveru. Článek tedy může být užitečným pro ty, kteří provozují svůj autoritativní DNS server. Všechny konfigurační kroky jsou zde ověřeny v praxi. Postupy zde uvedené jsou vázány především na BIND, nikoliv na distribuci, tedy měly by analogicky platit i pro jiné distribuce (kde se bude lišit například umístění některých souborů a podobně).

Článek je koncipován tak, aby provedl pojmy, které jiné články, které jsou dostupné na Internetu buď neobsahují nebo jsou uváděny zavádějícím nebo neúplným způsobem. Stejně tak software BIND v popisované verzi zjednodušuje některé operace a činnosti, které vedou k podpisu domény, jsou tedy odlišné od starších verzí tohoto sw.

Poznámka: Uvedený postup je vhodný pro zavádění DNSSECu pro jednu doménu. Pokud spravujete domén více, poznáte, že je vhodné provést v uvedeném postupu jisté změny. Například vyhradit klíčům pro podpis a vlastním zónovým souborům vlastní adresáře, případně nasadit opendnssec, který najdeme na: https://www.opendnssec.org/.

Úvod do DNSSEC

DNSSEC je prostředek, který rozšiřuje DNS a zajišťuje podepisování jednotlivých RR (a tím celé zóny). Tím je zajištěna důvěryhodnost a nemodifikovatelnost RR pro resolvery, které DNSSEC používají.

Pro zajištění důvěryhodnosti je nutné vycházet z kořenových DNS serverů, které v DNS fungují jako nejvyšší autorita a které podepisují DS záznamy podřízené domény (v našem případě autoritativní server pro .cz zónu) a ty podepisují dále DS záznamy domény druhého řádu, atd.

Z tohoto pohledu je důležitý pojem RRset, což je sada RR, které mají stejný název, třídu, typ a TTL (tedy všechny položky RR kromě RDATA). DNSSEC totiž nepodepisuje jednotlivé RR, nýbrž RRsety.

Pro podpis jsou zaváděny nové RR, konkrétně:

  • RSSIG, což je záznam obsahující podpis konkrétního RRsetu a jeho parametry
  • DNSKEY, což je záznam obsahující mimo jiné veřejný klíč, který patří k privátnímu klíči sloužícímu pro podepisování RRsetů.
  • NSEC, což je záznam, který slouží pro zabezpečení negativní odpovědi. NSEC bylo možné zneužít pro zone-walking, a proto bylo zavedeno NSEC3, což budeme používat i v našem případě.
  • DS, což je záznam v nadřazené zóně, který je nadřazenou zónou podepsán a obsahuje zejména hash vytvořený z názvu podepisované domény a části RDATA z DNSKEY RR (tato část se nazývá KeySet).

Pokud hovoříme o DNSKEY , pak úzus (kterého se ovšem nemusíme držet) je používat dva typy klíče:

  • ZSK (Zone Signing Key) - slouží pro podepisování zóny (běžných DNS RR) a
  • KSK (Key Signing Key) - slouží pro podepisování DNSKEY RR (tedy klíčů a je silnější (co do délky) a má delší platnost).

V zónovém souboru se tyto dva typy klíče rozliší příznakem klíče v RR DNSKEY. Tento příznak má pro ZSK hodnotu 256 a pro KSK hodnotu 257.

Tato architektura je zvolena proto, že nadřazená doména musí zavést data z DNSKEY podřízené zóny do svého zónového souboru a podepsat jej (viz výše uvedený zaváděný RR DS). To je přece jen náročnější operace, poněvadž zahrnuje komunikaci s cizím subjektem a nezávisí pouze na nás jako administrátorech serveru. Proto se do nadřazené zóny propaguje pouze data z DNSKEY, který obsahuje KSK, který má delší dobu platnosti. To má za důsledek to, že změny běžných RR ve vlastní zóně můžeme provést bez nutnosti kontaktovat nadřazenou doménu - tedy tyto operace mohou být častější a platnost ZSK může být nižší.

Tyto pojmy by měly postačovat k tomu, abychom si popsali podepsání vlastní zóny, propagaci KeySetu nadřízené doméně a údržbu klíčů a vlastní zóny (to je velmi důležitá část, protože vlastní podepsání zóny je v zásadě triviální operace, ale údržba zóny se liší podle toho, jaký systém se rozhodneme použít - tuto činnost můžeme provádět ručně nebo nějakým nástrojem).

Praktická konfigurace DNSSEC

Generování rndc.key

rndc-confgen -a -r /dev/urandom
chown root.named /etc/rndc.key
chmod 640 /etc/rndc.key

Zapnutí podpory DNSSEC v /etc/named.conf

options {
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
managed-keys-directory "/var/named/dynamic";
allow-query-cache { none; };
recursion no;
}

Poslední dvě volby by měl mít zapnutý každý BIND server, který slouží pouze jako autoritativní, takže je velká pravděpodobnost, že vaše konfigurace tyto volby již obsahuje. Zde je připomínám pro úplnost.

Ostatní řádky by měl obsahovat named.conf již z distribuce, tudíž je pouze zkontrolujeme a případně doplníme.

V named.conf dále nastavíme zónu analogicky k následujícímu příkladu:

zone "podepisovana.cz" IN {
        type master;
        file "podepisovana.cz";
        allow-update { none; };
        auto-dnssec maintain;
        inline-signing yes;
        key-directory "keys";
};

Všimněte si voleb auto-dnssec a inline-signing. Toto jsou dvě volby, které ve zmíněné verzi sw BIND usnadňují podepisování zóny. Ruční způsob, ke kterému je používán nástroj dnssec-signzone, najdete ve výše zmíněném článku na rootu.

První volba je zodpovědná za periodické prohledávání adresáře uvedeného ve volbě key-directory a v případě změny za podepsání příslušné zóny.

Druhá volba umožňuje přímou editaci původního souboru s definicí zóny bez negativních dopadů. V případě detekce manuální editace zóny zajistí jejjí podepsání.

Vytvoříme adresář /var/named/keys a nastavíme práva:

mkdir /var/named/keys
chown -R named.named /var/named/
chmod 770 /var/named/keys

V tuto chvíli můžeme restartovat named a zkontrolovat, co se stalo:

systemctl restart named.service
rndc status
rndc signing -list  podepisovana.cz

Z výstupu i logů ve /var/log/messages vidíme, že démon korektně nastartoval, ale že zatím nemáme podepsáno.

K tomu je potřeba naplánovat správu klíčů a klíče vygenerovat.

Generování párů ZSK a KSK klíčů

Poprvé vygenerujeme oba páry klíčů s podporou NSEC3 v adresáři /var/named/keys. První budeme generovat ZSK, druhý KSK:

cd /var/named/keys
dnssec-keygen -a RSASHA256 -b 2048 -3 -r /dev/urandom podepisovana.cz
dnssec-keygen -a RSASHA256 -b 4096 -3 -r /dev/urandom -fk podepisovana.cz

Tyto operace by bez použití /dev/urandom díky nedostatku entropie trvaly delší dobu v závislosti na výkonnosti serveru.

Výstupem jsou dva páry klíčů: soubor s veřejným klíčem má příponu .key, soubor s privátním klíčem má příponu .private. Soubory s vyšším číslem obsahují KSK klíč.

Kpodepisovana.cz.+008+32340.key  
Kpodepisovana.cz.+008+32340.private  
Kpodepisovana.cz.+008+62755.key  
Kpodepisovana.cz.+008+62755.private

dnssec-keygen při vytváření klíčů zároveň nastaví souborům správná oprávnění. Je jen potřeba změnit vlastníka.

chown -R named.named /var/named

V tuto chvíli máme zatím pouze vygenerovány klíče, nemáme však podepsanou zónu.

Podepsání zóny se děje jednoduše pomocí příkazu:

rndc loadkeys podepisovana.cz
rndc reload

Zkontrolovat můžeme pomocí příkazu:

dig +multiline +dnssec podepisovana.cz @127.0.0.1

V tuto chvíli již dostaneme na výstupu podepsanou zónu.

Vložení NSEC3PARAM RR

Následuje vložení a podepsání NSEC3PARAM RR, který provedeme příkazem:

rndc signing -nsec3param 1 0 10 DA658911 podepisovana.cz.

Hexadecimální číslo je zvoleno náhodně a musí dodržet nibble notaci (tedy 8 půlbytových číslic) a musí být mezi 0 a 232 -1.

Zóna je teď definitivně kompletně podepsána. Lze si opět ověřit příkazem dig jako výše.

Lze se podívat, jak vypadá podepsaná zóna na disku: Pokud si necháme vypsat adresář /var/named, který obsahuje původní definici zóny, kterou můžeme dále upravovat, zjistíme, že obsahuje ještě další soubory, jako jsou podepisovana.cz.jbk, podepisovana.cz.signed a podepisovana.cz.signed.jnl. Tyto soubory obsahují podepsanou zónu a její žurnál v raw formátu, který je použit pro zrychlení odbavování dotazů.

Pokud chceme vidět obsah podepsané zóny přímo z disku, můžeme použít příkaz:

named-compilezone -D -f raw -o - podepisovana.cz podepisovana.cz.signed

Tím však naše práce nekončí. Jediný, kdo o podpisu zóny ví, je primární a sekundární nameserver. Potřebujeme však ještě zajistit vytvoření DS RR v nadřazené zóně a jeho podepsání nadřazenou zónou, aby byl vytvořen řetěz důvěry od kořenové zóny až k naší zóně.

DS RR by bylo technicky možné vytvořit z DNSKEY podepisované zóny, ale to není cesta, kde je zaručena integrita a tedy bezpečnost. Proto je třeba, aby tato informace byla předána spolehlivou cestou. Touto cestou je vytvoření objektu KEYSET v centrálním registru (nikoliv v DNS), což je prováděno za podobných okolností jako vytváření samotné domény (tedy přes důvěryhodné kanály registrátora domény).

Vytvoření objektu KEYSET a podepsání zóny nadřazenou zónou:

Objekt KEYSET má obdobnou strukturu, jako objekt NSSET (můžete vidět ve whois dané domény), který uchovává seznam nameserverů naší domény. Ovšem s tím, že KEYSET slouží k uchování RDATA části DNSKEY RR vytvořeném z veřejného klíče KSK a informací o něm a technickém kontaktu, který smí tento objekt měnit.

Váš vlastní KEYSET vám umožní vytvořit váš registrátor domény. Někteří pro jeho vytvoření mají specifické postupy, rozumný je však takový, kdy má registrátor pro tento účel webové administrační rozhraní (musel jsem otravovat na několikrat administrátory mého registrátora, neb jsem stále přehlížel jejich tool na vytvoření KEYSETu :)

Jako předávané informace budou vyžadovány: Jméno KEYSETu, DNSKEY (po položkách, tedy příznaky, algoritmus a vlastní veřejný klíč KSK, případně pro sebevrahy i možnost zvolit ZSK) a technický kontakt (např. stejný jako technický kontakt domény nebo držitel domény).

Pokud máme již KEYSET vytvořený, můžeme registrátora naší domény požádat o zprostředkování vytvoření DS záznamu v nadřazené zóně a jeho podepsání. Opět se nejspíše setkáte v input boxem webového rozhraní registrátora, který bude tentokrát chtít pouze jméno KEYSETu v administraci konkrétní domény a to je vše. DS záznam vznikne tak, že se vypočítá hash z veřejného KSK klíče (k tomu se právě použije zaregistrovaný KEYSET) a přidají se další informace z KEYSETu. DS RR potom nadřazená zóna podepíše svým privátním klíčem jako ostatní své položky.

Počkáte nějakou dobu, než v našem případě CZ.NIC vytvoří a podepíše DS záznam a jakmile je hotovo, máte vaší zónu konečně zabezpečenou pomocí systému DNSSEC.

DS RR si můžete pro kontrolu vytvořit i sami pomocí jednoho z následujících příkazů, které se liší pouze zdrojem dat. První je z DNSKEY RR v DNS a druhé dva přímo z veřejného klíče KSK (liší se pouze volbou algoritmu hashe):

dig @127.0.0.1 dnskey podepisovana.cz | dnssec-dsfromkey -f - podepisovana.cz
dnssec-dsfromkey -a SHA256 Kpodepisovana.cz.+008+62755.key
dnssec-dsfromkey -a SHA1 Kpodepisovana.cz.+008+62755.key

Výstup bude z prvního a druhých dvou příkazů stejný:

podepisovana.cz. IN DS 62755 8 1 13415BAD786447A72A994697A43BBA71A35F1786
podepisovana.cz. IN DS 62755 8 2 DABCC5076782BAB1749C21680EA6E23896FEC4C72D1D068B219361312A27F370

Výstup můžete porovnat s výstupem z příkazu (jakmile dostanete pozitivní výstup, máte jasno, že je podepsáno):

host -t DS podepisovana.cz

a výsledek musí být:

podepisovana.cz has DS record 62755 8 1 13415BAD786447A72A994697A43BBA71A35F1786

Výsledek musí být stejný s prvním řádkem předchozího výstupu (vlastní data a jméno domény byly v tomto článku změněny (i když k tomu kromě donucení k vlastní snaze není důvod, poněvadž informace jsou to veřejné), proto zkoušejte na vlastní doméně).

Údržba klíčů

V tuto chvíli máme zónu podepsanou a nadřazená zóna uložila a podepsala ve svém zónovém souboru náš DS RR vzniklý z KSK.

Protože je však podobně jako u X.509 certifikátů rozumné mít stanovenu dobu živnotnosti klíčů, je potřeba tyto klíče spravovat.

Na rozdíl od X.509 certifikátů však není doba platnosti klíčů uložena v nadřazené zóně v DS RR ani v DNSKEY RR ve vlastní zóně (doba platnosti je uvedena pouze u ostatních podepsaných RR a vidíme, že v naší konfiguraci je měsíc) a je naším zájmem, aby klíče byly po uplynutí doby platnosti, kterou si stanovíme, obnoveny. To se dělá několika různými způsoby a o této problematice bude další článek.

  • obsah/bezpecnost/linux_dnssec_bind.txt
  • Last modified: 2018/10/22 17:35
  • by profors