DNSSEC a zabezpečení DNS ve vaší lokální síti

Informatec Digital » Zdroje » DNSSEC a zabezpečení DNS ve vaší lokální síti

Internet je postaven na několika klíčových komponentách, které téměř nikdy nevidíme, ale které máme k dispozici pokaždé, když otevřeme prohlížeč. Jednou z nejdůležitějších je systém doménových jmen (DNS) a když mluvíme o DNSSEC a zabezpečení v lokální síti , ve skutečnosti mluvíme o posílení těchto základů, abychom zabránili podvodným přesměrováním, spoofingu a dalším závažným útokům.

Dříve bylo prioritou jednoduše zajistit, aby vše fungovalo; dnes víme, že to nestačí. DNS se zrodilo v 80. letech 20. století bez ohledu na masivní kybernetické útoky, ale nyní ho potřebujeme nejen k rozpoznávání jmen, ale také k ověřování pravosti a integrity každé odpovědi . A zde přichází na řadu DNSSEC a v poslední době i návrhy jako E-DNSSEC, jejichž cílem je také zvýšit důvěrnost – klíčový faktor, pokud máte obavy o bezpečnost své lokální nebo firemní sítě.

Co je DNS a proč je tak důležité pro bezpečnost?

Systém doménových jmen (DNS ) je telefonní seznam internetu: překládá snadno zapamatovatelná jména (například www.example.com) na číselné IP adresy, kterým počítače rozumí (například 192.168.2.15 nebo adresa IPv6). Bez tohoto mechanismu bychom si museli pamatovat čísla místo jmen, což je zcela nepraktické.

Tato infrastruktura je organizována jako distribuovaná databáze ve stromové struktuře s kořenovou zónou na vrcholu, následovanou doménami nejvyšší úrovně (TLD jako .es, .com, .org) a pod ní doménami a subdoménami. Každá část této databáze se nazývá „ zóna “ a je hostována na jednom nebo více autoritativních jmenných serverech, které zveřejňují „oficiální“ informace pro každou doménu.

Když váš počítač, mobilní telefon nebo jakékoli jiné zařízení chce přistupovat k webové stránce, začne dotazováním na stub resolver , který je součástí operačního systému. Tento resolver odešle dotaz na rekurzivní DNS server (obvykle server vašeho poskytovatele internetových služeb, vaší společnosti nebo veřejný DNS server, jako je Google Public DNS , OpenDNS nebo Quad9). Tento rekurzivní server poté vyhledá odpověď dotazováním několika autoritativních serverů, dokud nenajde správnou IP adresu.

Rekurzivní resolvery ukládají přijaté odpovědi do mezipaměti, aby urychlily následné dotazy. To je velmi efektivní, ale také to otevírá dveře útočníkovi k „otrávení mezipaměti DNS“ a vkládání falešných dat , takže mnoho následných požadavků je vyřešeno s těmito zmanipulovanými informacemi, aniž by si toho uživatel všiml.

Hlavním problémem je, že DNS ve svém původním návrhu nemá žádný robustní způsob, jak ověřovat pravost odpovědí . Resolver v podstatě kontroluje, zda odpověď zřejmě pochází ze stejné IP adresy, na kterou se dotazoval, ale tato zdrojová IP adresa může být relativně snadno zfalšována. To umožňuje útoky s tichým přesměrováním na podvodné stránky, které napodobují například webové stránky vaší banky.

Bezpečnostní omezení tradičního DNS

Protokol DNS byl vytvořen v době, kdy bezpečnost nebyla primárním zájmem. Proto nyní víme, že dotazy a odpovědi DNS se přenášejí v prostém textu bez šifrování a že záznamová data lze bez dodatečné ochrany zfalšovat.

To otevírá dveře několika typům útoků, zejména útokům typu DNS cache poisoning a man-in-the-middle. V obou případech útočník vkládá falešné odpovědi, což způsobuje, že se uživatelé ocitnou na webových stránkách, které ovládají, aniž by si všimli čehokoli neobvyklého, protože název domény zobrazený v prohlížeči zůstává legitimní.

Představte si, že přistupujete na webové stránky vaší banky: váš počítač požaduje od rekurzivního serveru IP adresu domény banky, ale útočník server oklamal, aby přijal falešnou odpověď s IP adresou identického webu, který ovládá . Uživatel zadá své přihlašovací údaje v domnění, že je vše v pořádku, a kyberzločinec je obdrží v prostém textu, aby je později použil na skutečných stránkách.

Mechanismy jako Transaction Signatures (TSIG) , definované v RFC 2845, slouží k ochraně určitých operací mezi DNS servery (například přenosy zón mezi hlavním a podřízeným serverem a dynamické aktualizace). TSIG umožňuje dvěma počítačům sdílet tajný klíč k ověření identity druhé strany a integrity přenášených zpráv.

TSIG má však velmi omezený rozsah: neověřuje „skutečný“ původ dat DNS ; pouze zajišťuje, aby výměna mezi dvěma konkrétními servery nebyla pozměněna. Pokud byly původní informace v zóně již ohroženy nebo zmanipulovány před dosažením těchto serverů, TSIG je nezjistí. Proto, ačkoli se běžně používá pro přenosy zón, neřeší základní problém pravosti publikovaných dat DNS.

Co je DNSSEC a jak přispívá k bezpečnosti?

V reakci na všechny tyto slabiny byla vyvinuta rozšíření zabezpečení systému doménových jmen (DNSSEC) . DNSSEC nenahrazuje klasický DNS, ale spíše jej rozšiřuje o vrstvu zabezpečení, která umožňuje ověřit, zda jsou přijatá data legitimní a nebyla pozměněna.

DNSSEC je založen na kryptografii s veřejným klíčem (asymetrická kryptografie) . Každá zóna DNS má pár klíčů: soukromý klíč, který je uchováván v tajnosti, a veřejný klíč, který je zveřejněn na samotném serveru DNS. Vlastník zóny používá soukromý klíč k digitálnímu podepisování záznamů v dané zóně; veřejný klíč se používá k ověření těchto podpisů.

Když rekurzivní server dotazuje doménu pomocí DNSSEC, obdrží kromě obvyklých informací (například IP adresu spojenou se jménem) také digitální podpisy a veřejné klíče potřebné pro ověření . Rekurzivní server ověřuje podpisy oproti zveřejněným veřejným klíčům; pokud je ověření úspěšné, data jsou považována za autentická a nezměněná od doby, kdy byla podepsána.

Pokud ověření selže, resolver rozpozná, že je něco v nepořádku (například pokus o falšování nebo manipulaci během přenosu) a klientovi odpoví chybovým kódem, obvykle SERVFAIL . Uživatel tak neobdrží potenciálně škodlivá data, i když z jeho pohledu uvidí pouze to, že se stránka „nenačte“ nebo zobrazí chybu.

DNSSEC také zavádí koncept řetězce důvěry , který využívá stávající hierarchii DNS. Kořenová zóna podepisuje klíče domén nejvyšší úrovně (například .es, .com), ty zase podepisují klíče svých podřízených domén atd., takže jakoukoli doménu lze ověřit pomocí jediného bodu důvěry: veřejného klíče kořenové zóny.

Klíče, záznamy a řetězec důvěryhodnosti KSK a ZSK

Pro lepší organizaci zabezpečení používá DNSSEC dva různé typy klíčů: klíč pro podpis klíče (KSK) a klíč pro podpis zóny (ZSK) . Ačkoli jsou technicky vzato stejné (kryptograficky řečeno), jejich funkce se v rámci systému liší.

Klíč ZSK se používá k podepisování všech záznamů o zdrojích v zóně (A, AAAA, MX atd.). Obvykle se často rotuje, aby se minimalizovalo riziko, protože jakýkoli kompromitace tohoto klíče by ovlivnila všechny záznamy v zóně. KSK se naopak primárně používá k podepisování samotného klíče zóny (ZSK) a jeho hash se publikuje jako záznam DS (Delegation Signer) v nadřazené zóně.

Díky tomuto oddělení rolí je změna ZSK jednodušší: stačí vygenerovat nový ZSK, podepsat ho pomocí KSK, publikovat ho v záznamech DNSKEY zóny a nechat resolvery aktualizovat své informace. Není třeba se dotýkat nadřazené zóny, protože DS nadále ukazuje na stejný KSK, který zůstává déle stabilní.

DNSSEC přidává do protokolu DNS několik typů specifických záznamů, které jsou navrženy pro podporu podepisování a ověřování dat. Mezi nejdůležitější patří DNSKEY, RRSIG, DS, NSEC/NSEC3 a NSEC3PARAM . Všechny tyto záznamy umožňují vytvářet autentizační logiku beze změny základních operací dotazů.

Záznam DNSKEY uchovává veřejný klíč zóny , který je nezbytný k ověření podpisů. Záznam RRSIG obsahuje digitální podpis přidružený ke specifické sadě záznamů („sada záznamů zdrojů“). Záznam DS je hash DNSKEY podřízené zóny, který je publikován v nadřazené zóně a slouží jako článek v řetězci důvěryhodnosti.

Záznamy NSEC a NSEC3 se používají k ověřenému popření existence , tj. k kryptografickému prokázání, že doménové jméno nebo záznam neexistuje, a tím k prevenci útoků, které se pokoušejí vložit falešné odpovědi naznačující, že něco neexistuje, když ve skutečnosti existuje (nebo naopak).

Ověření řetězce důvěryhodnosti a odpovědi DNSSEC

Takzvaný řetězec důvěry v DNSSEC se buduje propojením záznamů DNSKEY a DS z kořene do domény, kterou chceme ověřit . Výchozím bodem je veřejný klíč kořenové zóny, který funguje jako kotva důvěryhodnosti a obvykle se konfiguruje přímo v rekurzivních resolverech.

Například pokud chcete ověřit doménu jako mywebsite.es, logický postup by byl následující: resolver důvěřuje veřejnému klíči kořenového serveru, který podepisuje klíč .es; zóna .es publikuje záznam DS odpovídající klíči KSK mywebsite.es; ověřením tohoto DS klíčem .es resolver důvěřuje klíči DNSKEY mywebsite.es a odtud může ověřit RRSIG ve všech svých záznamech.

Pokud v jakémkoli bodě řetězce chybí platný podpis nebo pokud DS (Data Signature) není přítomen tam, kde by měl být, je řetězec důvěryhodnosti přerušen. V takovém případě rekurzivní server provádějící validaci nepovažuje data za bezpečná a v závislosti na své konfiguraci buď neodpoví požadovanými záznamy, nebo označí odpověď jako neplatnou.

Tento hierarchický vztah také znamená, že aby byl DNSSEC skutečně efektivní, nestačí podepsat pouze vaši zónu : podepsána musí být i nadřazená zóna (například .es) a kořenová zóna a jejich záznamy DNS musí být správně publikovány. V současné době je již podepsána kořenová zóna DNS a prakticky všechny generické domény nejvyšší úrovně (gTLD) a mnoho domén nejvyšší úrovně s národním kódem (ccTLD).

Když rekurzivní server s povoleným ověřováním DNSSEC zjistí, že podpis se neshoduje nebo že chybí odkaz, odpověď, kterou vrátí klientovi, je obvykle doprovázena chybovým kódem RCODE SERVFAIL. To může být pro koncového uživatele matoucí („webová stránka nefunguje“), ale z bezpečnostního hlediska se jedná o ochranné opatření proti potenciálně manipulovaným datům.

DNSSEC také zavádí dvě klíčové funkce: ověřování původu dat , které umožňuje ověřit, zda záznamy skutečně pocházejí z očekávané zóny, a ochranu integrity , která zajišťuje, že informace nebyly od doby, kdy je vlastník zóny podepsal svým soukromým klíčem, změněny.

Útoky zmírněné pomocí DNSSEC a jejich vztah k TLS/HTTPS

Implementace DNSSEC pomáhá chránit před několika běžnými hrozbami. Zaprvé extrémně ztěžuje falšování odpovědí DNS , protože útočník by musel generovat platné podpisy bez znalosti soukromého klíče zóny, což je kryptograficky nemožné, pokud jsou klíče spravovány správně.

DNSSEC dále snižuje riziko otravy mezipaměti na rekurzivních serverech tím, že brání přijímání manipulovaných odpovědí, které neprojdou ověřením podpisu. Také komplikuje útoky typu „man-in-the-middle“ (MITM) na provoz DNS, při kterých útočník upravuje odpovědi během přenosu: pokud odpověď neprojde ověřením, resolver ji zahodí.

Je však důležité pochopit, co DNSSEC nedělá. Tato rozšíření nejsou navržena k šifrování obsahu dotazů nebo odpovědí . Veškerý provoz DNS, a to i s DNSSEC, stále putuje v prostém textu, pokud nepoužíváte jiné doplňkové technologie (jako jsou řešení typu DoT, DoH nebo E-DNSSEC). DNSSEC se zaměřuje na zajištění toho, aby to, co obdržíte, bylo autentické a nebylo pozměněno, nikoli na skrytí toho, co požadujete.

Tím se jasně odlišuje od protokolů jako TLS a HTTPS . Zatímco HTTPS šifruje provoz mezi prohlížečem a webovým serverem, aby zabránil třetím stranám ve špehování nebo úpravě komunikace, DNSSEC jednoduše podepisuje data DNS za účelem detekce spoofingu. Web může mít HTTPS bez DNSSEC nebo DNSSEC bez HTTPS, ale kombinace obou nabízí mnohem komplexnější ochranu před spoofingem a špehováním.

Organizace jako ICANN a IETF již léta propagují široké přijetí DNSSEC registry, registrátory, poskytovateli internetových služeb a provozovateli sítí. Cílem je, aby bylo podepsáno stále více zón a aby je více resolverů aktivně ověřovalo, aby průměrný uživatel mohl těžit z těchto kryptografických záruk, aniž by musel podnikat jakékoli zvláštní kroky.

DNSSEC v doménách .es a povinnosti vlastníků

V konkrétním případě Španělska jednotka domén „.es“ spravovaná společností Red.es již dlouho zavádí další technologie a postupy ke zlepšení kvality a zabezpečení služby DNS pod kódem země .es. Mezi tato opatření patří implementace bezpečnostního protokolu DNSSEC v souladu se specifikacemi IETF.

Domény .es jsou zodpovědné za podepsání zóny nejvyšší úrovně .ES a získání autorizace od kořenového serveru DNS, čímž se integrují do globálního řetězce důvěry. To znamená, že pokud vlastníte doménu .es, můžete tuto infrastrukturu využít k zabezpečení své vlastní domény pomocí DNSSEC.

Pro vlastníka domény zahrnuje obecný postup pro povolení DNSSEC zajištění toho, aby vaše autoritativní DNS servery zveřejnily podepsanou zónu. Obvykle to zahrnuje vygenerování veřejného klíče pro vaši zónu, podepsání záznamů, zveřejnění DNS klíče a následné odeslání materiálu klíče (nebo samotného DS záznamu) registru nebo vašemu registrátorovi, aby mohli vytvořit odpovídající DS záznam v nadřazené zóně.

V praxi mnoho poskytovatelů DNS hostingu a registrátorů již nabízí poměrně jednoduchou možnost aktivace DNSSEC, někdy stačí zaškrtnout políčko v ovládacím panelu. S touto funkcí však mohou být spojeny malé roční náklady, v závislosti na poskytovateli a úrovni služeb.

Jakmile je zóna podepsána a systém doménových jmen (DNS) byl úspěšně publikován, vaše doména se stane součástí řetězce důvěryhodnosti DNSSEC. Od tohoto okamžiku mohou být DNS překlady pro vaši doménu kryptograficky ověřovány překladači, kteří mají povoleno ověřování DNSSEC, což zvyšuje důvěru uživatelů a snižuje riziko útoků spoofingem.

DNSSEC v lokální síti: validace na straně uživatele

Z pohledu koncového uživatele nebo společnosti, která se zajímá o bezpečnost své lokální sítě, je klíčovou otázkou: co je potřeba k tomu, abyste mohli využívat výhody DNSSEC? Dobrou zprávou je, že nemusíte nic konfigurovat na každém počítači zvlášť , pokud váš rekurzivní DNS server (ten, který vaše počítače používají) ověřuje DNSSEC.

K tomu stačí, aby váš poskytovatel DNS (váš poskytovatel internetových služeb, veřejný resolver nebo interní DNS vaší organizace) měl rekurzivní server s povoleným a správně nakonfigurovaným ověřováním DNSSEC . Prakticky všechny moderní resolvery podporují DNSSEC již léta; jeho povolení obvykle zahrnuje jen několik změn v jejich konfiguračním souboru a přidání kořenové kotvy důvěryhodnosti.

Jakmile je ověřování povoleno a jeden z vašich počítačů v místní síti se dotáže na podepsanou doménu, rekurzivní resolver ověří všechny podpisy a řetězec důvěryhodnosti před vrácením odpovědi. Pokud se něco neshoduje, nevrátí žádné záznamy a uživatel uvidí chybu, což mu efektivně zabrání v připojení k potenciálně podvodnému webu.

Chcete-li zkontrolovat, zda je vaše doména chráněna technologií DNSSEC, existuje několik online nástrojů, například DNSSEC Analyzer a další ověřovací nástroje . Po zadání vaší domény byste měli vidět záznamy jako RRSIG (kryptografické podpisy), DNSKEY (veřejné klíče) a DS (hash DNSKEY v nadřazené zóně). Pokud nástroj indikuje, že k záznamům není přidružen žádný digitální podpis, bude vaše doména považována za „nepodepsanou“ nebo „nezabezpečenou“.

Pokud po této kontrole zjistíte, že vaše doména nebo DNS servery, které používáte ve vaší lokální síti, nevyužívají DNSSEC, je vhodné kontaktovat svého poskytovatele služeb nebo poskytovatele internetových služeb a požádat o jeho aktivaci. Pokud tuto možnost nenabízejí, může být vhodná doba zvážit přechod k poskytovateli , který ověření DNSSEC podporuje, a tím zvýšit úroveň zabezpečení pro vaši společnost i vaše zákazníky.

Omezení DNSSEC: soukromí a další aspekty

Navzdory všem svým výhodám není DNSSEC zázračným řešením pro všechny problémy se zabezpečením DNS. Klíčovým problémem je, že neposkytuje důvěrnost dotazů . DNS pakety, i s DNSSEC, stále putují v prostém textu, takže kdokoli s přístupem k provozu (například v nezabezpečené veřejné síti Wi-Fi ) může vidět, které domény jsou dotazovány.

Také nenabízí žádnou kontrolu přístupu ani specifickou obranu proti útokům typu denial-of-service (DoS nebo DDoS) . Ve skutečnosti přidáním dalších dat (podpisů, klíčů, dalších záznamů) zvětšuje velikost odpovědí DNS, což lze zneužít při amplifikačních útocích, pokud není infrastruktura správně nakonfigurována a chráněna.

Na druhou stranu DNSSEC s sebou nese určitou provozní složitost: je nutné spravovat páry klíčů , střídat ZSK a KSK, koordinovat publikaci DS v nadřazené zóně a zajistit, aby nedocházelo k neshodám, které by narušily řetězec důvěry. Chyba v těchto postupech může způsobit, že doména přestane správně probíhat ověřování, což vede k zdánlivým výpadkům služeb.

V samotném procesu DNSSEC se ve zprávách nacházejí řídicí bity (například bit CD v dotazech a bit AD v odpovědích), které ovlivňují způsob provádění a hlášení ověření. Útočník, který by mohl s těmito bity manipulovat v nezabezpečeném prostředí, by se mohl pokusit o degradaci ochrany nabízené rekurzivním resolverem. Proto se doporučuje, aby komunikace mezi resolvery a klienty používajícími DNSSEC probíhala přes zabezpečené kanály.

Navzdory těmto omezením zůstává DNSSEC nezbytnou součástí pro posílení autenticity a integrity DNS. Abychom však mohli jít ještě o krok dál a zároveň zaručit důvěrnost dotazů, je nutné jej kombinovat s dalšími technologiemi nebo se vyvíjet směrem k pokročilejším řešením.

E-DNSSEC: Směrem k ověřenému a šifrovanému DNS

Aby se řešila mezera v soukromí způsobená DNSSEC, byl navržen koncept E-DNSSEC (DNSSEC encrypted) . Myšlenkou tohoto přístupu je přidat šifrování k dotazům DNSSEC, aby byly kromě ověřování a podepisování také chráněny před kontrolou třetích stran při přenosu přes internet nebo lokální síť.

Cílem E-DNSSEC je kombinovat vlastnosti DNSSEC (autentičnost a integrita) se šifrovacími mechanismy, které zajišťují důvěrnost dotazů mezi klientem DNSSEC a serverem DNSSEC . To zvyšuje celkovou bezpečnost služby DNS a brání externím pozorovatelům v tom, aby viděli, která doménová jména jsou rozpoznávána.

Koncepční proces by zahrnoval analýzu dotazu na rekurzivním serveru, jeho šifrování před odesláním na autoritativní server a následné dešifrování a zpracování běžným způsobem pomocí DNSSEC . Odpověď by pak mohla být vrácena podepsaná a zašifrovaná zpět na rekurzivní server nebo klienta, čímž by byla zachována důvěrnost v průběhu celého procesu.

Tato kombinace by zajistila zabezpečení DNS zprávy od začátku do konce procesu rozpoznávání: ověřená a integrovaná díky DNSSEC a chráněná před zvědavými pohledy díky dodatečnému šifrování. V kontextu lokální nebo podnikové sítě by se takový přístup dal integrovat s dalšími řešeními perimetrického zabezpečení.

Návrhy jako E-DNSSEC jsou dnes součástí širšího úsilí o posílení soukromí DNS , spolu s technologiemi, jako je DNS přes TLS (DoT) a DNS přes HTTPS (DoH). Základní směr je jasný: DNS budoucnosti musí být autentické i důvěrné a nestačí jen rychle překládat jména; musí to být také provedeno bezpečně.

V prostředí, kde dochází k stále sofistikovanějším kybernetickým útokům, vydávání se za jinou osobu a hrozbám zaměřeným na základní infrastrukturu, je DNSSEC již důležitým bezpečnostním požadavkem pro jakoukoli seriózní doménu a přechod na šifrovaná řešení, jako je E-DNSSEC nebo podobná, se jeví jako logický další krok k dalšímu posílení ochrany sítí, včetně lokálních sítí.

Celý tento ekosystém – od klasického DNS přes DNSSEC až po šifrovaná řešení, jako je E-DNSSEC – ukazuje, že zabezpečení DNS není volitelným doplňkem, ale klíčovou součástí internetové architektury a jakékoli moderní lokální sítě. Mít resolvery, které ověřují platnost, podepsané zóny, dobře udržované řetězce důvěryhodnosti a v budoucnu i šifrované kanály pro dotazy, představuje zásadní rozdíl mezi exponovanou sítí a infrastrukturou připravenou na současné i budoucí výzvy.