NSEC3 – DNSSEC, který nic nevyzradí

Jedním z problémů zabezpečeného DNS (DNSSEC) je jeho záznam NSEC, který umožňuje postupně zjistit kompletní obsah domény. Některé subjekty odmítají podepisovat své domény především kvůli němu. Tyto problémy má vyřešit NSEC3, jenž zajistí stejné služby jako NSEC, ovšem bez možnosti zneužití.

Cílem těchto záznamů je poskytnout důvěryhodnou informaci o tom, že požadovaný údaj v DNS není. Jestliže totiž útočník nebude schopen podepsaná DNS data falšovat, mohl by zkoušet alespoň popírat jejich existenci. Jako ochranu vkládá DNSSEC ke každému existujícímu jménu do domény záznam typu NSEC. Ten obsahuje seznam existujících typů záznamů pro dané jméno a další existující jméno v doméně (v abecedním pořadí).

Pokud se dotážete na neexistující jméno beata, dostanete NSEC záznam pro jméno anna, v němž se dočtete, že za ním následuje až dana. Tento záznam je podepsaný, takže máte potvrzeno, že hledaný záznam skutečně neexistuje.

Problém je, že tímto způsobem lze celkem snadno získat kompletní obsah domény. Stačí jen postupně následovat další existující jména podle NSEC záznamů. Následníkem posledního je první, takže vás provedou celou doménou. Přitom možnost získat obsah domény je z bezpečnostního hlediska považována za problém, protože poskytne komukoli zvenčí přehled o existujících strojích a ten se pak může cíleně zaměřit s útokem.

Autoři DNSSEC nějakou dobu zaujímali stanovisko, že se s těmito problémy dá žít a že výhody DNSSEC převažují nad nedostatky. Nicméně soustavné brblání komunity a radikální stanovisko některých institucí, jež kvůli NSEC odmítly DNSSEC nasadit, nakonec vedly k lepšímu návrhu, nazvanému NSEC3.

Základní princip v něm zůstává zachován, ale místo otevřených jmen používá jejich hashe, podle nichž jsou také NSEC3 záznamy v doméně uspořádány. Když tazatel shání neexistující údaj, dostane jako odpověď NSEC3 záznam, z nějž se dozví:

  • hash jména tohoto záznamu
  • existující typy záznamů pro toto jméno
  • hash jména následujícího záznamu
  • parametry hashovací funkce – jaká funkce byla použita, kolikrát byla opakována a jaký náhodný řetězec (salt) byl ke jménu přidán

V záznamu nikde nefigurují žádná jména a díky jednosměrnosti hashovacích funkcí je ani nelze rychle vypočítat. Tazatel si ale údaje snadno může zkontrolovat. Dostal parametry hashovací funkce, takže provede s dotazovaným jménem příslušný výpočet a ověří si, že buď výsledný hash odpovídá hashi jména záznamu a požadovaný typ chybí mezi existujícími typy, nebo že výsledný hash leží v intervalu mezi hashem jména záznamu a následujícího jména (čili požadované jméno v doméně není). NSEC3 záznam samozřejmě musí být podepsán, aby byl důvěryhodný.

Vzhledem k tomu, že tazatel se nedozví žádná jména, nelze z NSEC3 záznamů sestavit obsah domény. Teoreticky by bylo možné získat alespoň počet existujících jmen postupným procházením následujících hashů. Specifikace NSEC3 ovšem nepřipouští ani to. Server se musí chovat, jako by „jméno“ přiřazené NSEC3 záznamu (tedy hash původního jména) neexistovalo. O záznam proto nelze požádat, klient jej může získat jen jako reakci na neúspěšný dotaz. A vzhledem k dost divokému chování hashovacích funkcí není snadné sestavit dotaz, který by cíleně vedl k určitému záznamu.

Cenou za bezpečí je větší výpočetní náročnost, a to jak na straně klienta, tak především na straně serveru. Při použití NSEC může na neúspěšný dotaz reagovat hned. Pro NSEC3 musí nejprve spočítat hash dotazovaného jména (s parametry odpovídajícími záznamům v doméně) a teprve poté může vybrat správný záznam pro odpověď. Zde se otevírá určitý prostor pro DoS útoky zahlcením serveru hromadou požadavků na náhodně generovaná jména. Ovšem neměl by být problém ošetřit tyto snahy v implementaci – například přiřadit vyřizování neúspěšných dotazů nízkou prioritu a řešit je, jen pokud zatížení serveru nepřekročilo určitou mez.

NSEC3 je definováno v RFC 5155. Specifikace je poměrně mladá, pochází z března letošního roku, nicméně první implementace jsou již na světě. V případě BINDu ji najdete ve verzi 9.6, která je zatím ve stádiu betatestování. NSD je napřed. Experimentálně podporoval NSEC3 již ve verzi 3.0 (září 2007), počínaje verzí 3.1 z le­tošního června je má implicitně zapnuto. Slabší je to s podporou na straně klientů, která je v současnosti v podstatě zanedbatelná.

EBF16

Pokud po zavedení DNSSEC v doméně cz uvažujete o podepsání svých údajů v DNS, vyplatí se zvážit, zda nasadit NSEC nebo NSEC3. První z nich je dnes zavedenější a z hlediska reálného nasazení méně náročný. Druhý netrpí bezpečnostní slabinou a vypadá perspektivněji.

Jako vhodnější se mi jeví sáhnout rovnou po NSEC3. Důsledkem sice bude, že většina klientů dnes nebude schopna negativní odpovědi ověřit, nicméně to jen znamená, že se nic nezmění proti stavu bez DNSSEC. Nemožnost získat snadno kompletní obsah domény mi připadá jako podstatnější. A do budoucna předpokládám, že je jen otázkou času, kdy NSEC3 převládne.

Anketa

Dali byste vy osobně přednost nasazení NSEC nebo NSEC3?

5 názorů Vstoupit do diskuse
poslední názor přidán 19. 11. 2008 9:35

Školení e-mail marketingu – pokročilé techniky

  •  
    Jak připravit šablonu moderního e-mailu
  • Jak spustit automatizované kampaně
  • Jak dynamizovat běžnou rozesílku

Detailní informace o školení e-mail marketingu - pokročilé techniky »