DNSSec: konečně bezpečné DNS

  • Článek

Miroslav Knotek – knotek@kpcs.cz – Microsoft MVP: Security, IT Senior konzultant KPCS CZ, s.r.o.

Úvod

Službu DNS dnes používáme všichni s naprostou samozřejmostí ve všech možných internetových i intranetových službách. Málokdy si ale uvědomujeme, že vedle pohodlí, které nám to přináší, je DNS ve své současné podobě také hrozbou. Když se například připojujeme na firemní Intranet na adrese intranet.nejakadomena.cz, stačí, aby nám útočník podstrčil místo správné adresy 10.1.1.1 adresu s nepravým serverem 10.10.10.10. V tuto chvíli pak možná místo přihlášení k Intranetu útočníkovi posíláme naše přihlašovací údaje, aniž bychom měli šanci toto odhalit.

Současný systém DNS totiž nepoužívá žádné mechanismy, které by uměly ověřit, zda odpověď na náš DNS dotaz přišla z toho správného DNS serveru nebo zda nebyla modifikována po cestě.

Útoky jako je spoofing, man-in-the-middle a cache poisoning nejsou bohužel jen teoretické pojmy, ale útočníci je používají jako jednu z poměrně jednoduchých technik ke kompromitaci našich systémů. Díky implementaci standardu Domain Name System Security Extensions (DNSSec) ve Windows Serveru 2008 R2 máme však již možnost jak se těmto útokům bránit.

Základní principy

DNSSec je založen na aplikaci asymetrické kryptografie na data DNS serverů. Autoritativní DNS server si pro svou zónu vygeneruje klíčový pár:

  • Privátní – tím digitálně podepíše data ve své DNS zóně
  • Veřejný – ten naopak zveřejní v nadřazené doméně

Pokud se tedy nyní zeptám na adresu intranet.nejakadomena.cz, dostanu zpět nejen odpověď v podobě IP adresy, ale také digitální podpis této odpovědi. Abych ho mohl ověřit, musím požádat nadřazenou doménu .cz o zaslání veřejného klíče pro doménu nejakadomena.cz.

Obrázek 1 A záznam včetně digitálního podpisu RRSIG
Obrázek 1 A záznam včetně digitálního podpisu RRSIG

Je ale evidentní, že jsme nyní problém jen přesunuli. Ověření jsem provedl na základě získání veřejného klíče od DNS domény .cz. Kde mám ale jistotu, že mi tuto odpověď opět nepodstrčil útočník. Jistotu mám pouze pokud i doména .cz bude posílat podepsaná data. Její veřejný klíč pak bude k dispozici v kořenové zóně. Pak ale i kořenová zóna musí být sama podepsaná. Protože ale zde už neexistuje vyšší instance, musím si zjistit veřejný klíč z důvěryhodného zdroje a ustanovit na DNS serveru v něj důvěru (tzv. trust anchor). Existuje zde pak podobný řetězec důvěry jako ve světě certifikačních autorit – i tam musím nejprve důvěřovat kořenovému certifikačnímu úřadu.

Podmínky pro nasazení

Jako každá technologie, i DNSSec má nutné podmínky pro fungování a zároveň má také svá omezení. Konkrétně pro implementaci na Windows Serveru 2008 R2 / Windows 7 se jedná se především o následující:

  • Pokud je zóna podepsána, všechny autoritativní DNS servery musí podporovat DNSSec.
  • Podepsání zóny GlobalNames není podporováno.
  • Podepsání zóny se zapnutým WINS předáváním není podporováno.
  • DNSSec je nekompatibilní s dynamickou registrací DNS. Obsah zóny musí být statický. Po každé změně je nutné celou zónu znovu podepsat.
  • RSA/SHA-1 jsou podporované algoritmy, délka klíče pak od 512 bitů do 4096 bitů.
  • Je možné použít DNSSec i pro zónu integrovanou do AD, ale je nutné ji před vlastním podpisem dočasně exportovat do souboru.
  • DNS klient ve Windows 7 a Windows Serveru 2008 R2 má podporu DNSSec v podobě tzv. neověřujícího DNS revolveru. Prakticky to znamená, že klient příznakem v DNS dotazu říká, že chce ověřit DNS odpověď, ale toto ověření požaduje po lokálnímDNS serveru, který je nastaven v konfiguraci TCP/IP. Je doporučeno tento poslední “hop” tzn. úsek mezi klientem a lokálním DNS serverem zabezpečit pomocí IPSecu.

Implementace DNSSecu

Podepsání DNS zóny na Windows Serveru 2008 R2 se provádí pomocí následujících kroků:

  1. Generování klíčového páru Key Signing Key(KSK)
    DnsCmd /OfflineSign /GenKey /Alg rsasha1 /Flags KSK /Length 2048 /Zone nejakadomena.cz /SSCert /FriendlyName KSK- nejakadomena.cz

  2. Generování klíčového páru Zone Signing Key(ZSK)
    DnsCmd /OfflineSign /GenKey /Alg rsasha1 /Length 1024 /Zone nejakadomena.cz /SSCert /FriendlyName ZSK- nejakadomena.cz

    Přestože jsme v úvodu hovořili o jednom klíčovém páru, nyní vidíme, že jsou reálně dva. ZSK se používá k podpisu zóny. Kvůli optimalizaci výkonu mívá kratší délku klíče, tím pádem je třeba ho častěji obměňovat. Protože se často mění, musel by se příliš často měnit také v nadřazené doméně a to by bylo nepraktické. Proto je zde ještě jeden mezičlánek – KSK. KSK je publikován v nadřazené doméně a je použit k podpisu ZSK. Oba certifikáty se objeví v konzole certifikáty, odkud je doporučeno je pro účely zálohy vyexportovat.

    Obrázek 2 KSK a ZSK v konzole Certifikáty
    Obrázek 2 KSK a ZSK v konzole Certifikáty

  3. Příprava souboru se zónou
    Soubor zóny se standardně nachází v umístění %windir%\System32\DNS. V případě, že je zóna AD integrated, je třeba ji nejprve vyexportovat do souboru příkazem:
    dnscmd /ZoneExport <zone name> <zone file name>

    * *

  4. Podpis zóny
    Vlastní podpis zóny provedeme příkazem:
    *DnsCmd /OfflineSign /SignZone /input nejakadomena.cz.dns /output nejakadomena.cz.dns.signed /zone nejakadomena.cz /signkey /cert /friendlyname ksk- nejakadomena.cz /signkey /cert /friendlyname zsk- nejakadomena.cz

  5. Načtení podepsané zóny
    Výstupem předchozího kroku je nový soubor s podepsanou zónou, kterým musíme nahradit soubor původní. Po načtení tohoto souboru službou DNS to vypadá takto.

    Obrázek 3 Podepsaná zóna
    Obrázek 3 Podepsaná zóna

  6. Konfigurace DNS klienta
    Pomocí novinky v GPO – Name Resolution Policy (NRP) – můžeme na klientech nastavit politiku, která jim dá pokyn k vyžadování ověření odpovědí na DNS dotazy do určitých domén pomocí technologie DNSSec. Je zde také možné vynutit IPSec spojení mezi DNS klientem a DNS serverem.

 

Obrázek 4 Konfigurace Name Resolution Policy
Obrázek 4 Konfigurace Name Resolution Policy

Závěr

V tomto článku jsme se jen velmi zevrubně seznámili s problematikou zabezpečení služby DNS pomocí technologie DNSSec a úvodními implementačními kroky. Reálně je ale celý proces mnohem komplexnější, neboť je potřeba ustavit hierarchii důvěry, naplánovat proces obnovy klíčů po jejich expiraci, nastavit IPSec mezi DNS klientem a lokálním DNS serverem atp.

Je určitě velmi dobrou zprávou, že DNSSec je ve Windows Serveru 2008 R2 plně podporován a tam, kde cítíme riziko možného útoku prostřednictvím jmenné služby DNS, máme dnes elegantní a účinnou zbraň pro její zabezpečení.

Zajímavé odkazy