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 své přihlašovací údaje, aniž bychom měli šanci to 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 server, nebo zda byla po cestě modifikována.
Ú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.
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 také 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 však zde už neexistuje vyšší instance, musím si zjistit veřejný klíč z důvěryhodného zdroje a na DNS serveru mu důvěřovat (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 má i DNSSec 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á 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 je pak od 512 bitů do 4096 bitů.
• Je možné použít DNSSec také 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ím DNS 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.
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
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:
Podepsaná zóna
6. Konfigurace DNS klienta
Pomocí novinky v GPO – Name Resolution Policy (NRP) – můžeme na klientech použít nastavení, 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.
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 tř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 že 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í.
http://technet.microsoft.com/cs-cz/default.aspx
Autor: Miroslav Knotek
PŘEDPLATNÉ
ČLÁNKY DO MAILU