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?
Vitalia.cz: „Sjíždět“ porno není bez rizika

„Sjíždět“ porno není bez rizika

Lupa.cz: Olympiáda zakázala GIFy. Moc to nepomáhá

Olympiáda zakázala GIFy. Moc to nepomáhá

Vitalia.cz: Očkování je nutné, říká homeopatka

Očkování je nutné, říká homeopatka

Vitalia.cz: Za její cukrovkou stojí rodiče

Za její cukrovkou stojí rodiče

Měšec.cz: Platíme NFC mobilem. Konečně to funguje!

Platíme NFC mobilem. Konečně to funguje!

Lupa.cz: Nechcete datacentrum? Jsou na prodej

Nechcete datacentrum? Jsou na prodej

Měšec.cz: Co když na dovolené přijdete o kartu?

Co když na dovolené přijdete o kartu?

Lupa.cz: Měřičům síly hesla se nedá věřit. Víte proč?

Měřičům síly hesla se nedá věřit. Víte proč?

Měšec.cz: Ceny PHM v Evropě. Finty na úspory

Ceny PHM v Evropě. Finty na úspory

Lupa.cz: Elektronika tajemství zbavená. Jak s ní začít?

Elektronika tajemství zbavená. Jak s ní začít?

Vitalia.cz: Vakcína Cervarix je oficiálně i pro chlapce

Vakcína Cervarix je oficiálně i pro chlapce

Lupa.cz: Kdo vykrádá LinkedIn? Zjistit to má soud

Kdo vykrádá LinkedIn? Zjistit to má soud

DigiZone.cz: Jetelín končí. Prima ho vyřadila

Jetelín končí. Prima ho vyřadila

120na80.cz: Kam umístit silikony?

Kam umístit silikony?

DigiZone.cz: Hodlá Markíza skončit v DVB-T?

Hodlá Markíza skončit v DVB-T?

DigiZone.cz: ČTÚ červenec: rušení trochu vzrostlo

ČTÚ červenec: rušení trochu vzrostlo

Měšec.cz: TEST: Vyzkoušeli jsme pražské taxikáře

TEST: Vyzkoušeli jsme pražské taxikáře

Root.cz: Xiaomi má vlastní notebook podobný Macu

Xiaomi má vlastní notebook podobný Macu

120na80.cz: Lepší poporodní sexuální život? Žádný problém

Lepší poporodní sexuální život? Žádný problém

Měšec.cz: Na návštěvě na exekutorském úřadě

Na návštěvě na exekutorském úřadě