DNSSEC s BIND 9.9 snadno a rychle

Ondřej Caletka 23. 3. 2016

Nasazení DNSSEC na autoritativní server je asi nejsložitější částí přechodu na DNSSEC. Není to ale nic, čeho by bylo třeba se obávat. Podepíšeme si zónu na DNS serveru BIND 9.9 s minimálními zásahy do infrastruktury.

Podpora automatického DNSSEC podepisování byla v serveru BIND přitomna již dříve, bylo ale vždy nutné přepnout zónu do dynamického režimu, což s sebou mohlo nést některé problémy. Ve verzi 9.9 se ale poprvé objevila funkce zvaná inline signing, která umožňuje zapnout podepisování a přitom zachovat původní zónové soubory beze změn.

Výchozí situace

Nasazení si prakticky předvedeme na Debianu Jessie, který obsahuje balíček bind9 ve verzi 9.9.5. Přepokládejme, že server slouží jako autoritativní server pro zónu example.com, která používá obyčejný textový zónový soubor umístěný v /etc/bind/example.com. V konfiguračním souboru /etc/bind/named.conf.local je pak následující definice zóny:

zone "example.com" {
        type master;
        file "/etc/bind/example.com";
}; 

Krok 0: dostatek entropie

Ještě než začneme zónu podepisovat, je dobré se ujistit, že systém bude mít k dispozici dostatek entropie, aby mohl generovat náhodná čísla skutečně náhodně. Všechny dále zmíněné nástroje používají jako zdroj náhodných čísel zařízení /dev/random, které při nedostatku entropie proces vytváření klíčů nebo podpisů blokuje až do chvíle, kdy entropie naroste zpět. Množství dat, které zařízení /dev/random vyrábí, můžeme ověřit nástrojem pv, který vypisuje každou sekundu počet bajtů, které protekly rourou:

# pv -nb /dev/random > /dev/null
192
192
192
^C 

Opakující se hodnota značí vyčerpanou zásobu entropie. Ve většině případů si můžeme pomoci instalací démona haveged, který získává další entropii z nejrůznějších vnitřních stavů procesoru:

# apt-get install haveged
# pv -nb /dev/random > /dev/null
1586646
3219499
4800458
^C 

Krok 1: vygenerujeme klíč

Automatické podepisování v BINDu dokáže generovat a obnovovat podpisy, klíče je však třeba generovat a případně měnit ručně. Abychom snížili míru ruční práce na minimum, použijeme k podpisu zóny pouze jediný klíč s algoritmem ECDSA P-256 a hashovací funkcí SHA256. Síla tohoto algoritmu by měla být větší než síla RSA klíče o délce 2048 bitů, takže jej není nutné vyměňovat dříve než za několik let. Zároveň jsou podpisy tímto algoritmem tak krátké, že si můžeme dovolit použít jej k podepisování každého záznamu zónového souboru.

# mkdir /etc/bind/keys
# cd /etc/bind/keys
# dnssec-keygen -a ECDSAP256SHA256 -fK example.com
Generating key pair.
Kexample.com.+013+32462
# chmod g+r K*.private 

V adresáři /etc/bind/keys vzniknou soubory s veřejným i privátním klíčem. Druhý jmenovaný má nastavena práva na 0600, takže je čitelný a zapisovatelný jen pro vlastníka, což je uživatel root. Aby jej mohl použít BIND k podepisování, je třeba práva upravit tak, aby daný soubor mohl číst. Tuto úpravu je třeba opakovat po každém generování klíče.

Krok 2: aktivace inline signingu

Nyní je již vše připraveno k aktivaci podepisování. Přitom se BIND pokusí vedle zónového souboru vytvořit soubory se žurnálem a s podepsanou verzí zóny. Je-li zónový soubor v /etc, toto se nepovede kvůli nedostatečnému oprávnění. Navíc z praktických důvodů není vhodné, aby se v konfiguračním adresáři objevovaly soubory automaticky generované a spravované. Vhodným řešením je přesunutí cesty k zónovému souboru z /etc  do provozního adresáře /var/cache/bind, kam má BIND právo zapisovat. Vytvoříme tedy symbolický odkaz na zónový soubor:

# ln -s /etc/bind/example.com /var/cache/bind 

Nyní již můžeme aktivovat podepisování úpravou konfigurace:

zone "example.com" {
        type master;
        file "example.com";
        inline-signing yes;
        auto-dnssec maintain;
        key-directory "/etc/bind/keys";
}; 

Po reloadu příkazem rndc reload by mělo dojít během několika okamžiků k podepsání zóny. Průběh můžeme sledovat pomocí:

# rndc signing -list example.com
Done signing with key 32462/ECDSAP256SHA256 

Standardně je podepisováno v režimu NSEC, kdy jsou všechna jména v zónovém souboru provázána a je tedy možné postupným dotazováním zjistit všechna existující jména. Pro situace, kde je toto problém, je možné přejít na hashované záznamy NSEC3:

# rndc signing -nsec3param 1 0 10 deadbeef example.com 

Číselné parametry určují postupně hashovací algoritmus NSEC3 (jediný definovaný je 1 – SHA256), flagy (žádné), počet iterací hashování (10 je rozumná hodnota) a konečně sůl, která zabraňuje použítí tzv. rainbow tabulek. Jde o libovolné šestnáctkové číslo dlouhé až 255 bytů. Důrazně zde doporučuji odolat pokušení k použití zprofanovaných slov jako cafebabe, deadbeef nebo  faceb00c.

Podepsaná zóna je uložena v provozním adresáři v souboru s příponou .signed. Kromě toho se v daném adresáři ještě nachází žurnálový soubor sledující změny v původním nepodepsaném souboru a žurnálový soubor podepsaného souboru. Podepsaný soubor je v surovém formátu, pokud jej chceme prozkoumat, je třeba použít utilitu  named-compilezone:

# named-compilezone -f raw -j -o - example.com /var/cache/bind/example.com.signed
zone example.com/IN: loaded serial 9 (DNSSEC signed)
example.com. 60 IN SOA ns.example.com. hostmaster.example.com. 9 120 10 3600 60
…
OK 

Změny DNS dat provádíme stejně jako před zavedením DNSSECu – editací nepodepsaného zónového souboru a reloadem serveru. Důležité je při každé změně zvýšit sériové číslo zóny v SOA záznamu, jinak ji BIND odmítne načíst. Sériové číslo podepsané zóny sleduje číslo nepodepsané zóny, automaticky je ale zvyšováno při obnovování podpisů nebo manipulaci s klíči.

Krok 3: sdělení nadřazené zóně

Posledním krokem k vytvoření řetěžu důvěry je umístění otisku klíče do nadřazené zóny. K tomu slouží utilitka  dnssec-dsfromkey:

# dnssec-dsfromkey /etc/bind/keys/Kexample.com.+013+32462
example.com. IN DS 32462 13 1 5E6C8…9D20C8
example.com. IN DS 32462 13 2 AB779…8A9001875886A0FF9170A2579AC9E1AB 

Vygenerované otisky se liší pouze algoritmem hashovací funkce, která je u kratšího SHA1, u delšího SHA256. Není třeba umisťovat do nadřazené zóny oba, zcela postačuje ten druhý, bezpečnější.

Speciálním případem jsou registry domén .cz a .eu. Tyto registry nepřijímají DS záznamy, ale rovnou celé veřejné klíče. Důvod je ten, že DS záznam je otiskem jak veřejného klíče, tak i doménového jména. Registry .cz a .eu pracují s tzv. keysety, které mohou být přiřazeny k většímu množství doménových jmen. Příslušné DS záznamy si pak registr vyrobí sám. Pro nás je důležité, že do keysetu vkládáme přímo obsah souboru s veřejným klíčem.

Krok 4: výměna klíče

Ačkoli je klíč daného algoritmu dostatečně silný, může nastat časem potřeba klíč vyměnit. Ani to není příliš obtížné, byť jistá ruční práce je vyžadována. Nejprve vygenerujeme nový klíč stejně jako v kroku 1 a sdělíme BINDu, že jej má používat:

# cd /etc/bind/keys/
# dnssec-keygen -a ECDSAP256SHA256 -fK example.com
Generating key pair.
Kexample.com.+013+11957
# chmod g+r *.private
# rndc sign example.com 

V tuto chvíli jsou aktivní oba klíče a můžeme tedy změnit DS záznam v nadřazené zóně tak, aby mířil na nový klíč. Po určité době, kdy se změna projeví a starý klíč se stane nepotřebným, můžeme naplánovat jeho deaktivaci (přestane být používán k vytváření podpisů) a poté jeho odstranění ze zóny:

# cd /etc/bind/keys
# dnssec-settime -I now -D +35d Kexample.com.+013+32462
dnssec-settime: warning: Permissions on the file
./Kexample.com.+013+32462.private have changed from 0640 to 0600 as a result of this operation.
./Kexample.com.+013+32462.key
./Kexample.com.+013+32462.private
# chmod g+r *.private
# rndc sign example.com 

Tímto je starý klíč okamžitě deaktivován a zcela odstraněn po 35 dnech – v této době by už zaručeně měly být všechny podpisy přegenerovány a klíč tedy bude bezpečné odebrat. To proběhne automaticky; BIND totiž adresář s klíči pravidelně kontroluje a s klíči nakládá podle časovacích metadat.

Závěrem

Podpora automatického podepisování s inline signingem umožňuje nasadit DNSSEC všude tam, kde je používán BIND. Nedochází zde k žádnému zásahu ani na straně vstupu, kde je obsluha stejná jako dříve, stejně jako není potřeba nijak upravovat případné slave servery, tedy za předpokladu, že používají přiměřeně aktuální software. Použití algoritmu ECDSA a jediného klíče celý postup zjednodušuje tak, že prakticky není potřeba věnovat žádnou péči navíc.

Našli jste v článku chybu?
DigiZone.cz: Epson: 4K projektory s podporou HDR

Epson: 4K projektory s podporou HDR

DigiZone.cz: CZ a SK Digi TV budou spolupracovat

CZ a SK Digi TV budou spolupracovat

Vitalia.cz: Tohle je Břicháč Tom, co zhubnul 27 kg

Tohle je Břicháč Tom, co zhubnul 27 kg

120na80.cz: Jaké plavecké pomůcky vaše dítě ochrání?

Jaké plavecké pomůcky vaše dítě ochrání?

Podnikatel.cz: Účtenky v rámci EET? Klidně emailem

Účtenky v rámci EET? Klidně emailem

Lupa.cz: IT scéna po brexitu: přijde exodus vývojářů?

IT scéna po brexitu: přijde exodus vývojářů?

Vitalia.cz: Taky je nosíte? Barefoot není pro každého

Taky je nosíte? Barefoot není pro každého

Vitalia.cz: Cvičení tabata: na hubnutí i posilování?

Cvičení tabata: na hubnutí i posilování?

Měšec.cz: Investice do drahých kovů - znáte základní chyby?

Investice do drahých kovů - znáte základní chyby?

120na80.cz: I tuto vodu můžete pít

I tuto vodu můžete pít

DigiZone.cz: Skylink o půlnoci vypnul 12 525

Skylink o půlnoci vypnul 12 525

Lupa.cz: Největší torrentový web KickassTorrents padl

Největší torrentový web KickassTorrents padl

Podnikatel.cz: Profese budoucnosti? Úředník nepřežije

Profese budoucnosti? Úředník nepřežije

Podnikatel.cz: Tahle praktika stála šmejdy přes milion

Tahle praktika stála šmejdy přes milion

Lupa.cz: Největší pitominy s logem “nyní smart a připojené”

Největší pitominy s logem “nyní smart a připojené”

Podnikatel.cz: Daň z nemovitosti? Změny budou v říjnu

Daň z nemovitosti? Změny budou v říjnu

Vitalia.cz: Signál roztroušené sklerózy: brnění končetin

Signál roztroušené sklerózy: brnění končetin

Podnikatel.cz: Co vše musíte udělat, než vypukne EET?

Co vše musíte udělat, než vypukne EET?

DigiZone.cz: Test Noxon A560+: kvalitka do vaší věže

Test Noxon A560+: kvalitka do vaší věže

Vitalia.cz: Cheese&Chilli: předsudky o nudné britské kuchyni

Cheese&Chilli: předsudky o nudné britské kuchyni