Hlavní navigace

Soukromí v DNS: krátké dotazy a šifrovaná komunikace

Pavel Satrapa

Otázky ochrany soukromí se poslední dobou probírají všude. DNS je typickým představitelem staré gardy a nenabízí v tomto směru prakticky nic. Proč to vadí a co se děje ke zlepšení?

Proč?

Nabízí se otázka, proč vlastně má smysl se problematikou soukromí v DNS zabývat. Informace jsou v principu veřejné, takže proč by člověku mělo vadit, když někdo zjistí, které konkrétní veřejné informace v DNS hledá? Dá se to samozřejmě rozebírat do detailů (viz RFC 7626), nicméně základní oblasti jsou dvě: osobní a bezpečnostní.

Osobní spočívá v tom, že člověk některé své aktivity prostě považuje za soukromé a nepřeje si, aby se o nich vědělo. Hranici máme každý jinde, obvykle do soukromé sféry patří záležitosti finanční a sexuální. Ale za určitých okolností můžeme udržovat v soukromí i informace, které jiný člověk bez váhání zveřejní. Pokud třeba horník bude mít za koníčka háčkování, pravděpodobně to bude před svým okolím tajit, protože se bude obávat výsměchu, zatímco jeho babička bude na své háčkování hrdá.

Z bezpečnostního pohledu lze znalosti o DNS provozu zneužít k různým útokům. Buď k útoku přímo na DNS, nejčastěji s cílem podvrhnout falešné údaje. Znáte-li dotaz, podstrčit odpověď je triviální. Nebo se lze setkat i s obecnějšími útoky, kdy se útočník snaží ze složení a frekvence DNS dotazů odvodit, jaké programy a služby na svém zařízení používáte, a využít tyto informace k cílenému útoku na jejich slabá místa.

Shrnuto a podtrženo: absence soukromí přináší určitá rizika a stojí za to usilovat o její zmenšení. Jednou z reakcí IETF je i založení pracovní skupiny DNS PRIVate Exchange (dprive), jejímž cílem je ochrana DNS před monitorováním. Konkrétně se zaměřuje na komunikaci mezi koncovým klientem a rekurzivním serverem, který pro něj řeší DNS dotazy.

Současné DNS: na soukromí zapomeňte

Tím se dostáváme k základům fungování DNS, které ve stručnosti připomeneme. V koncovém zařízení je jednoduchý klient, na který se obracejí zdejší aplikace se svými požadavky. On sám toho moc neumí, v podstatě jen dovede sestavit DNS dotaz a rozluštit příchozí odpověď.

Má ovšem k dispozici adresu (případně několik málo adres) rekurzivního DNS serveru, který dokáže plnohodnotně řešit dotazy a zpravidla disponuje vyrovnávací pamětí pro dočasné ukládání zjištěných údajů. Bývá umístěn v lokální síti, aby komunikace mezi ním a klienty byla rychlá. Tento server hledá odpovědi na dotazy místních klientů.

Čili pokud se pokusím otevřít stránku www.univie.ac.at, můj webový prohlížeč zavolá systémovou funkci, že potřebuje najít v DNS adresu pro toto jméno. Jednoduchý klient v mém počítači pošle lokálnímu serveru DNS dotaz, že hledá záznamy typu A nebo AAAA pro dané jméno. Lokální rekurzivní server postupně odešle sérii dotazů – nejprve kořenovému serveru, pak postupně serverům nižších a nižších domén, které dostane v odpovědích – a jejich pomocí najde příslušné záznamy. Ty pak odešle v odpovědi mému klientu.

Ochrana soukromí není v tomto postupu prakticky žádná. Lokální server opakuje můj dotaz, takže všechny oslovené servery (a s nimi kdokoli, kdo je schopen odposlouchávat kteroukoli z použitých komunikačních tras) se dozvědí zcela konkrétně, co hledám. Pakety nejsou nijak šifrovány a opakuje se v nich původní dotaz, všichni se dozvědí vše. Jaké jsou možnosti pro zlepšení?

Rekurzivní server ví všechno

V první řadě je dobré si uvědomit, že rekurzivní server zná přesně veškeré vaše dotazy, protože je to on, kdo na ně hledá odpovědi. Není žádnou výjimkou, že si vede protokol o své činnosti, ve kterém lze dohledat, kdy se kdo na co ptal.

S tím, že rekurzivní server ví o vašem DNS hledání vše, se musíte smířit. Můžete si ovšem vybírat, kdo tím serverem bude. Jeho adresu zařízení obvykle dostane protokolem DHCP jako součást síťové konfigurace. V domácí síti jím typicky bývá krabička, která řeší vše kolem internetového připojení. V podnikové nebo školní síti obvykle tuto roli hraje skutečný DNS server. Zpravidla obsluhuje všechny klienty z dané lokální sítě a mimo ni figuruje v DNS zprávách on jako její jediný zástupce.

Pokud vám výchozí nastavení nevyhovuje, můžete je samozřejmě ruční konfigurací změnit. V úvahu připadají především dvě extrémní varianty – ryzí individualismus nebo skrývání v davu.

V prvním případě si rekurzivní server budete dělat sami. Prostě si nainstalujete BIND, Unbound, Knot DNS Resolver nebo jiný podobný program a vytvoříte si svůj vlastní rekurzivní server. Kompletní informace o vašem DNS hledání tedy neopustí váš počítač. Zaplatíte těmito nevýhodami:

  • Vaše DNS komunikace bude méně efektivní, protože nesdílíte vyrovnávací paměť s ostatními uživateli.

  • Můžete narazit na firewall, provozovatel sítě může DNS provoz koncových stanic blokovat a povolovat jej jen ze svých serverů.

  • Autoritativních serverů se bude ptát přímo váš počítač. Zvenčí tedy bude vidět, kdo se ptá.

Opačným extrémem je použít veřejný server využívaný velkým množstvím uživatelů. Například Google nabízí veřejný rekurzivní DNS server na adrese 8.8.8.8 a je hojně využíván, jeho podíl na DNS dotazech v současnosti překračuje 10 %. Čili vaše dotazy se stanou součástí obrovské nepřehledné masy. Navíc často budou zodpovězeny z vyrovnávací paměti, kterou plní spousta uživatelů, takže se nikam dál ani nedostanou.

Paranoik začátečník by mohl namítnout, že tím ale dává Googlu (nebo jinému provozovateli podobného serveru) k dispozici informace o svém hledání. Pokročilý paranoik samozřejmě ví, že Google už to stejně dávno ví a není před ním úniku.

Ale vážně: Ano, vaše dotazy jsou pravděpodobně službami tohoto typu zaznamenávány a v případě, že byste se zapojili do kriminálních aktivit, mohou být dohledány. A ne, nemá cenu si s tím dělat příliš těžkou hlavu, protože pro běžné činnosti choulostivé na soukromí je pravděpodobnost jejich zneužití blízká nule. Nicméně, jak už bylo řečeno výše, hranice máme každý jinde a tato varianta jistě nebude pro každého.

Minimalizace dotazů

Zatím byla řeč jen o organizačních záležitostech. Teď se pojďme podívat na nějaká technická řešení. Prvním je minimalizace dotazů, kterou standardizovalo nedávno vydané RFC 7816. Stručně řečeno: rekurzivní server se bude ptát jen na informace nezbytně nutné k nalezení odpovědi.

Nemá valný smysl ptát se v horních patrech doménové hierarchie na konkrétní typ záznamu pro přesně dané jméno. Stejně se dozví jen jména a adresy serverů, které leží vždy o jednu úroveň blíže k řešení. Proto se při minimalizaci dotazů bude ptát rovnou na tyto servery.

V našem příkladu se kořenového serveru zeptá na autoritativní servery domény at. Některého z nich se zeptá na servery domény ac.at a některého z nich na servery domény univie.ac.at. Tyto servery již znají odpověď, takže je na čase jednomu z nich zopakovat původní dotaz – že se hledá záznam typu A (AAAA) pro www.univivie.ac.at. Celý postup bude vypadat takto:

Obecně řečeno se autoritativních serverů jednotlivých domén ptá vždy na záznamy typu NS pro jméno o jednu jmenovku delší. Teprve když už chybí jen poslední jmenovka, pošle danému serveru konkrétní dotaz. Servery ve vyšších patrech doménové hierarchie (a všichni, kteří dovedou odposlouchávat komunikaci vašeho rekurzivního serveru s nimi) se tedy dozví jen to, že hledáte cosi v jedné jejich poddoméně, ale žádné podrobnosti.

Hlavní výhodou minimalizace dotazů je snadné nasazení. Nepředstavuje žádnou změnu protokolu, jen se rekurzivní server ptá na něco trochu jiného než obvykle. Pokud ji váš rekurzivní server umí (například Unbound), prostě ji zapnete a je hotovo.

Drobnou nevýhodou je, že řešení může být o něco méně efektivní. Konkrétně v našem příkladu je server d.ns.at autoritativní pro domény atac.at. Kdyby si rekurzivní server pro dotaz do domény at vybral jej, dostal by při standardním postupu rovnou odkaz na servery domény univie.ac.at. Čili řešení by bylo o jednu dvojici dotaz–odpověď kratší. Minimalizace dotazů tuto úsporu znemožní, protože po serveru domény at bude chtít jen servery pro ac.at a neprozradí mu, že cesta dále pokračuje do univie.ac.at. Ovšem úspory tohoto typu budou spíše marginální a nepředstavují vážný argument proti minimalizaci dotazů.

Závažnějším nedostatkem je, že minimalizace dotazů příliš nechrání. Dotazy i odpovědi se nadále přenášejí v otevřeném tvaru a z jejich odposlechu se zjistí vše. Navíc obvykle již doména druhé úrovně prozradí dost o vašich záměrech. Z osobního hlediska jste de facto chráněni jen před kořenovými servery, které se z vašeho dotazu dozvědí jen doménu 1. úrovně. Ovšem když server domény com uvidí, že sháníte něco v doméně pornhub.com, je celkem jasné, co by to tak asi mohlo být.

O něco lepší je ochrana proti bezpečnostním problémům. Ke kompletnímu dotazu se dostane jen ten, kdo je schopen odposlouchávat komunikaci mezi klientem a rekurzivním serverem nebo mezi rekurzivním serverem a finálním autoritativním serverem. Bohužel právě odposlech klienta v lokální síti z místního napadeného zařízení bude asi nejčastějším případem.

Šifrované DNS

Chcete-li opravdové soukromí, budete muset šifrovat. Základním přenosovým protokolem DNS je UDP, jako první kandidát se tedy nabízí DTLS. Ovšem poněkud překvapivě je dále standardizace šifrování pomocí TLS nad protokolem TCP, která již byla standardizována v RFC 7858. Naproti tomu na využití DTLS se stále ještě pracuje (draft-ietf-dprive-dnsodtls). Základní principy obou jsou ovšem podobné.

Zabývají se komunikací mezi koncovým klientem a jeho rekurzivním serverem. Autoři připouštějí, že tyto principy by mohly být použitelné i pro komunikaci mezi servery, ale ponechávají tuto možnost pro případný budoucí vývoj. Zejména v případě TLS je to rozumné omezení – klient obvykle využívá jeden rekurzivní server, takže jednou navázané TCP+TLS spojení může udržovat otevřené pro řadu dotazů a minimalizovat tak dopady počáteční režie. Také lze sáhnout po mechanismech rychlého navázání spojení, pokud se vrací ke stejnému serveru.

Původní myšlenka použití standardního portu a dohoda obou stran o přechodu na šifrovanou komunikaci byla opuštěna. Raději byl pro šifrované DNS vyhrazen samostatný port 853, a to jak pro TCP, tak pro UDP. Na tomto portu se komunikuje pouze šifrovaně, otevřený DNS provoz specifikace vysloveně zakazují.

Klientův přístup závisí na jeho bezpečnostním profilu. RFC 7858 stručně popisuje dva základní – příležitostný a přísný. Připouští budoucí vznik dalších a skupina dprive vyvíjí v tomto směru aktivitu (draft-ietf-dprive-dtls-and-tls-profiles). Stručně řečeno: podle příležitostného profilu klient dává přednost šifrované komunikaci, ale pokud není k dispozici, smíří se i s otevřeným DNS. Může, ale nemusí ověřovat autentičnost serveru. Naproti tomu klient s přísným profilem trvá na šifrování i ověření serveru pomocí klíče, který získal jinou cestou. Při neúspěchu skončí fatální chybou a není schopen řešit DNS dotazy. Buď soukromí, nebo nic.

Jelikož k prolomení šifry lze využívat i informace o délce zprávy, byla v RFC 7830 definována volba pro EDNS(0), která umožňuje ji uměle zvětšit. Smí se používat jen pro šifrované zprávy a příjemce ji samozřejmě ignoruje. Slouží jen pro zmatení případného útočníka. Pokud server dostane takto přifouknutý dotaz, musí svou odpověď také přifouknout. V opačném případě se může – stejně jako klient – svobodně rozhodnout, zda zprávu uměle zvětší nebo ne.

Zdůrazněme, že oba zmíněné mechanismy se vzájemně doplňují. Dá se šifrovat komunikace mezi klientem a rekurzivním serverem a chránit ji tak před lokálním odposlechem. Rekurzivní server pak může nasadit minimalizaci dotazů, aby venkovnímu světu o svých klientech prozrazoval co nejméně.

Přestože je tato problematika je celkem čerstvá, přehled implementací naznačuje, že, už dnes se šifrované DNS dá provozovat. Problém je především s klientskou stranou, kde je zatím víceméně jedinou možností použití getdns. Uvidíme, jak rychle nové možnosti proniknou do standardních DNS klientů v operačních systémech.

Našli jste v článku chybu?

4. 7. 2016 21:05

Každá zóna rozhodně nemusí mít svůj server. Krásně je to vidět třeba na reverzních IPv6 záznamech, kde rozhodně není samostatný server co každá tečka ve jméně. Pokud se zeptáte na neúplné jméno, dostanete takzvaný Empty Non-Terminal, tedy návratový kód NOERROR a žádná data:

$ dig 0.0.0.8.6.0.0.c.7.6.0.1.0.0.2.ip6.arpa ns @ns.iinfo.cz
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2452
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
…
;; QUEST…

4. 7. 2016 12:51

Dá se jen předpokládat, že to je dáno tím, že první verze DNS byla vytvořena v roce 1983, ještě v ARPANETu, dávno před internetem. A jak to tak bývá, nároky se časem změnily, ale základ zůstal. Původně prostě neběžel DNS server na každé kravině a bylo pravděpodobné, že se ke správné hodnotě dostaneš dříve, než se prokoušeš celým názvem. Ušetřilo to značnou část režie a v době, kdy se rychlosti počítaly v jednotkách, maximálně desítkách kilobitů a to ještě za dobrého větru, to bylo výhodnější, ne…

Podnikatel.cz: 1. den EET? Problémy s pokladnami

1. den EET? Problémy s pokladnami

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

DigiZone.cz: „Black Friday 2016“: závěrečné zhodnocení

„Black Friday 2016“: závěrečné zhodnocení

Lupa.cz: Kdo pochopí vtip, může jít do ČT vyvíjet weby

Kdo pochopí vtip, může jít do ČT vyvíjet weby

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

120na80.cz: Co všechno ovlivňuje ženskou plodnost?

Co všechno ovlivňuje ženskou plodnost?

Podnikatel.cz: Udávání a účtenková loterie, hloupá komedie

Udávání a účtenková loterie, hloupá komedie

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

Měšec.cz: mBank cenzuruje, zrušila mFórum

mBank cenzuruje, zrušila mFórum

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

Vitalia.cz: 9 největších mýtů o mase

9 největších mýtů o mase

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Podnikatel.cz: Zavře krám u #EET Malá pokladna a Teeta?

Zavře krám u #EET Malá pokladna a Teeta?

Vitalia.cz: Jmenuje se Janina a žije bez cukru

Jmenuje se Janina a žije bez cukru

Lupa.cz: Propustili je z Avastu, už po nich sahá ESET

Propustili je z Avastu, už po nich sahá ESET

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Podnikatel.cz: Snížení DPH na 15 % se netýká všech

Snížení DPH na 15 % se netýká všech