Dotaz: Hacknutelný dnssec - jak klient ověřuje podpisy?

[dnssec]

Ahoj. Přečetl jsem si nějaké články o tom, jak funguje dnssec a připadá mi to, že je to děravé. Brání se tento mechanismus nějak třeba útoku man in the middle? Co když mám v klientovi nastavený dns server 1.2.3.4, ale útočník mi předhodí svůj vlastní, na kterém bude mít podvržené všechny podpisy? Nebo ještě horší možnost: co když nastane mitm útok během dotazu mého rekurzivního serveru, který se bude ptát autoritativních serverů? Nestačí v tomto případě podvržení autoritativního serveru s tím, že bych na tom podvrženém skladoval všechny potřebné podpisy (a vlastně by se nenarušil řetězec důvěry - byl by podvrhnut)? Pokud tyto útoky nejsou možné, mohl by mi prosím někdo vysvětlit proč, jak je toto zabezpečené?

---

---

Odpovědi

[Filip Jirsák]

Certifikát ke každé doméně je uložen v nadřazené doméně. Klient by měl mít bezpečně uložen certifikát kořene DNS, a ověřit celou cestu až ke kořeni. Útočníkův certifikát tak nebude sedět s tím, který je pro danou doménu uložen v nadřazené doméně, čímž se útok odhalí.

[dnssec]

Klient by měl mít bezpečně uložen certifikát kořene DNS

Aha, díky. Teď už to dává smysl.

[dnssec]

Mimochodem, kde je v linuxu ten klíč uložen?

[xkucf03]

Např. v /etc/bind/named.conf.options (pokud používáš Bind, u jiných DNS serverů to bude jinde).

[dnssec]

To je ale server. Nebo ve větě "Klient by měl mít bezpečně uložen certifikát kořene DNS" byl myšlen klientem rekurzivní dns server?

[jelen s mydlem]

Hledejte "trust anchor"

[dnssec]

Takže to vypadá, že trust anchor je umístěn v resolvujícím dns serveru. To ale nezabrání útoku mitm, protože samotná komunikace s resolvujícím dns serverem je nešifrovaná a tak se dá posloupnost paketů resp. informací odposlechnout a podvrhnout.

[Filip Jirsák]

Komunikace s resolvujícím DNS serverem by měla vést přes relativně bezpečnou síť – minimálně poskytovatel onoho resolvujícího DNS serveru tu síť nejspíš za bezpečnou považuje Pokud vím, existuje třeba taky plugin do prohlížeče, který validaci provádí – a dá se čekat, že způsoby použití DNSSEC se budou postupně rozšiřovat.

[dnssec]

Takže pro mě několik závěrů:

1. komunikace s resolvujícím dns serverem musí být v rámci sítě nějak zabezpečena (což pokud se nejedná o firemní prostředí tak nebývá, protože se použije resolver poskytovatele např. přes wifi spoj)

2. není dobré, aby byl resolvující server také autoritativní resp. nemá smysl podepisovat domény na autoritativním dns serveru, který použiji pouze jako resolvující (jednoduše řečeno pokud budu mít vlastní privátní doménu a vlastní resolvující dns server v jednom, tak nemá podpis této domény smysl)


... pokud jsem vyvodil špatné závěry, tak mě prosím opravte

[pavlix]

Pro mě to má jeden jediný závěr, a to, že validující DNS resolver má být za všech okolností na lokálním stroji, pokud se nejedná o nějaké enterprise nasazení, kde se tak jako tak špicluje traffic.

[xkucf03]

má být za všech okolností na lokálním stroji, pokud…

Tady záleží na důvěryhodnosti (lokální) sítě – jestliže je nedůvěryhodná, tak sice můžu mít DNS server s validací na localhostu a doménová jména se mi přeloží na správné IP adresy, ale ta nedůvěryhodná síť mi ty IP adresy nasměruje jinam.

A naopak když té síti věřím – věřím, že nepřesměrovává IP/porty někam jinam a zároveň věřím, že nepodvrhává DNS záznamy.

Rozdíl by byl snad leda v případě, že bych přes DNSSEC chtěl přenášet něco jiného než IP adresy (např. otisky klíčů), ale takové použití zatím není příliš časté…

[pavlix]

Tady záleží na důvěryhodnosti (lokální) sítě

A tu implicitně považuju za nedůvěryhodnou.

[xkucf03]

To je v pořádku, já většinou taky.

Jenže přesunem DNS serveru na localhost si nijak moc nepomůžeš, protože ta nedůvěryhodná síť ti může místo podvržení DNS záznamů přesměrovat IP adresy a porty. Resp. pomůžeš si jen v případě, že používáš DNSSEC k přenosu těch jiných informací, pokud jsi myslel tohle (což bych ale neřekl, že je „za všech okolností“ – je to dnes spíš výjimka a za všech okolností se DNS používá leda tak k překladu doménových jmen na IP adresy).

Navíc ona ta nedůvěryhodná síť ani nemusí nic podvrhávat nebo přesměrovávat – dost škody se dá napáchat pouhým pasivním odposloucháváním. Takže bych spíš řekl, že je za (téměř) všech okolností potřeba šifrovat komunikaci.

A otisky klíčů v DNSSEC jsou pak taková třešnička na dortu, pojistka, v podstatě paralelní hierarchie certifikačních autorit (vedle např. těch v x509).

[pavlix]

Jenže přesunem DNS serveru na localhost si nijak moc nepomůžeš, protože ta nedůvěryhodná síť ti může místo podvržení DNS záznamů přesměrovat IP adresy a porty.

Bavíme se stále ještě o DNSSECu?

Resp. pomůžeš si jen v případě, že používáš DNSSEC k přenosu těch jiných informací, pokud jsi myslel tohle (což bych ale neřekl, že je „za všech okolností“ – je to dnes spíš výjimka a za všech okolností se DNS používá leda tak k překladu doménových jmen na IP adresy).

To „za všech okolností“ jsi obrátil naruby, ale nevadí.

Pokud vím, tak ještě nedávno nebyl k DNSSEC k dispozici vůbec, takže hodnotit, co se jím přenáší a co ne je víceméně zbytečné. Nehledě na to, že třeba Openswan umí DNS chráněné DNSSECem využívat velmi dobře.

A otisky klíčů v DNSSEC jsou pak taková třešnička na dortu, pojistka, v podstatě paralelní hierarchie certifikačních autorit (vedle např. těch v x509).

Pro tebe je to třešnička na dortu, pro mě je to naprostý základ, bez kterého DNSSEC téměř nemá smysl.

[Filip Jirsák]

Tady záleží na důvěryhodnosti (lokální) sítě

A tu implicitně považuju za nedůvěryhodnou.

Takže se od ní okamžitě odpojíte. Někteří lidé ale počítačovou síť potřebují, takže se naučili alespoň trochu své lokální síti důvěřovat.

[pavlix]

Takže se od ní okamžitě odpojíte.

Tvá schopnost dedukce mě vždycky udivovala.

[Filip Jirsák]

S nedůvěryhodnou sítí se nedá dělat nic jiného. Co budete dělat třeba se sítí, která špatně směruje většinu paketů? Přitom směrování je pro důvěryhodnost sítě dost podstatná záležitost, důležitější než nějaké DNS.

Ve skutečnosti i u té nejpochybnější sítě důvěřujete spoustě věcí. Jenže pravdivě to napsat by nebylo tak efektní, jako velkohubé prohlášení o tom, že každou síť považujete za nedůvěryhodnou.

[pavlix]

S nedůvěryhodnou sítí se nedá dělat nic jiného.

Doporučuju ti podívat se na svět okolo tebe. Je v něm dostatek protipříkladů.

[Filip Jirsák]

Co tedy děláte se sítí, která 80 % paketů směruje špatně a sem tam se na datové vodiče dostane 230 V? Připojíte tam svůj počítač a zkoušíte štěstí? Nebo před každým připojením do nějaké sítě ověřujete, že se takhle nechová?

[pavlix]

A co to dívání na okolní svět, pomohlo?

Mimochodem, když už máš potřebu klást takto debilní otázky, nevidím důvod, proč bys neměl být taky první, kdo na ně odpoví.

[Filip Jirsák]

Klidně na tu otázku odpovím – já bych do takové sítě počítač nezapojoval. Nicméně pokud bych s danou sítí neměl takovou zkušenost, nebo by mne někdo nevaroval, pokládám každou síť v tomto směru implicitně za důvěryhodnou. V tom je tedy mezi námi rozdíl, takže moje odpověď je nezajímavá, protože se tady snažím zjistit, jak postupuje někdo, kdo každou síť považuje implicitně za nedůvěryhodnou (a taky by mne zajímalo, co se musí stát, aby jste nějakou síť začal považovat za důvěryhodnou).

A co to dívání na okolní svět, pomohlo?

Mně pomáhá, měl byste to někdy zkusit taky. Třeba byste pak přestal tvrdit nesmysly jako že žádné síti v ničem nedůvěřujete; nebo pokud za „nedůvěryhodnou síť“ označujete síť, které v mnoha parametrech důvěřujete, a v několika málo ne, popsal byste, čím je zrovna těch pár parametrů důležitých.

[pavlix]

já bych do takové sítě počítač nezapojoval

Já s nedůvěryhodnými sítěmi pracuju denně a počítače k nim připojuju. Stačí to jako odpověď?

nebo by mne někdo nevaroval, pokládám každou síť v tomto směru implicitně za důvěryhodnou. V tom je tedy mezi námi rozdíl

To ano, já nemám potřebu si nalhávat něco, co není pravda.

Třeba byste pak přestal tvrdit nesmysly jako že žádné síti v ničem nedůvěřujete

Zatím jsem to tvrdit ani nezačal.

[Filip Jirsák]

Takže síti, ve které důvěřujete velké spoustě věcí, říkáte nedůvěryhodná síť. Hm. Takže onu nedůvěryhodnost pro vás zřejmě způsobuje jenom pár nějakých parametrů. Zvláštní je, že to nejsou ty parametry pro fungování sítě podstatné, ale dobře – které to tedy jsou?

[pavlix]

Takže síti, ve které důvěřujete velké spoustě věcí, říkáte nedůvěryhodná síť.

Samozřejmě.

Takže onu nedůvěryhodnost pro vás zřejmě způsobuje jenom pár nějakých parametrů.

Tak to v bezpečnosti obvykle funguje.

[Filip Jirsák]

Ve vašem pojetí „bezpečnosti“ možná. Normálně se ale posuzují nejprve ty podstatné parametry a teprve pak ty okrajové. Z hlediska bezpečnosti je třeba mnohem důležitější to, jak ta síť směruje, a překlad DNS názvů je až daleko za tím. Ostatně, když bude mít ta síť vhodně cinknuté směrování paketů s DNS dotazy, tak ten váš slavný lokální DNS resolver zvaliduje leda tak velké kulové.

[pavlix]

Smysluplné možnosti naší konverzace jsou zjevně vyčerpány. Já ti nemám možnost více sdělit, protože neposloucháš z principu. Ty mi nemáš co více sdělit, protože už nějakou dobu vaříš z vody.

Nevidím jiné rozumné východisko, než vlákno ukončit.

[Filip Jirsák]

Ano, já neposlouchám. Vy už jste tu napsal stokrát ty parametry, podle kterých posuzujete důvěryhodnost sítě, a já je pokaždé ignoroval. Taky jste už stokrát vyvrátil tvrzení, že z hlediska následků prakticky není rozdíl v tom, zda vám resolvující DNS server na dotaz na example.com vrátí 5.6.7.8 místo správné 1.2.3.4, nebo zda vám na ten dotaz odpoví správně, ale následně komunikaci s 1.2.3.4 přesměruje na 5.6.7.8.

[jaroleto]

Metody bezpecneho dotazovani se jednoho serveru jsou tady mnohem dele nez DNSSEC. Treba TSIG. Takze co jste vazeny vlastne hledal, kdyz jste nenasel ani toto?

Jina vec ale samozrejme je, proc rovnou nenasadit vlastni DNSSEC server a v dobre kontrolovanem mistnim prostredi nevynechat TSIG, kdyz nepodepisuji ani prenost souboru na file server.

[Filip Jirsák]

není dobré, aby byl resolvující server také autoritativní

To nebylo dobré nikdy.

Nezabezpečená WiFi na poslední míli hlavního internetového připojení je podle mne české specifikum, ve světě to podle mne i pro domácnosti bude spíš nějaký kabel. A vzhledem k tomu, že dnes nejčastější způsob zabezpečení je přenos hesla z webového formuláře v otevřeném tvaru přes HTTP, nemá moc smysl najednou zabezpečovat DNS tak, že se validace DNSSEC bude urychleně cpát až na koncové počítače.

Ostatně jako u každé hierarchické služby je potřeba systémově zajistit hlavně ty úpravy směrem od kořene. Takže se dá očekávat, že využití DNSSEC na straně klienta se bude postupně rozvíjet, teď bylo a je důležité zajistit hlavně to, aby byly klíče a software k dispozici na serverech (bez toho navíc nikdo žádné velké úpravy klientů dělat nebude). Podpisem kořenové zóny nasazení DNSSEC nekončí, ale naopak začíná.

Vlastní privátní doménu v odděleném stromu asi nemá smysl podepisovat – musel byste přidávat její klíč všude, kde ji chcete validovat, atd. Podle mne je ale lepší použít privátní doménu jako poddoménu skutečné domény (třeba local.example.com), a k tomu bych už přistupoval jako k celé doméně, tj. nevylučovala bych ji z podepisování. Dá se předpokládat, že v budoucnosti se přes zabezpečené DNS budou kontrolovat třeba HTTPS certifikáty, což může mít smysl i pro privátní doménu – a naopak při použití odděleného stromu budete mít problém, protože klíč od té domény budete muset dostat třeba až do všech prohlížečů na koncových stanicích.

[Filip Jirsák]

Myšlen byl jakýkoli klient, ale pokud vím, předpokládá se, že validaci bude pro koncového klienta dělat rekurzivní DNS server (tj. typicky firemní DNS rekurzivní server nebo server ISP). Takovou konfiguraci předpokládají všechny návody, které jsem viděl – a nevím, zda vůbec existuje klientská DNS knihovna, která by validaci uměla. Ono by to taky nebylo moc efektivní, takže i pro ochranu jednoho počítače je asi lepší zprovoznit si lokální rekurzivní server.

[pavlix]

Ono by to taky nebylo moc efektivní, takže i pro ochranu jednoho počítače je asi lepší zprovoznit si lokální rekurzivní server.

Vždyť v první větě píšeš, že by to nebylo moc efektivní, a hned v druhé to navrhuješ!

[Filip Jirsák]

Efektivní by nebyla implementace v rámci resolvující knihovny. Ta existuje v rámci procesu, který překlad provádí. Takže pustíte třeba ping s DNS jménem, stáhnou se klíče od všech nadřazených domén až ke kořeni a ověří a po 1 sekundě ping ukončíte – takže to ověřování DNSSEC vyvolalo řádově víc síťového provozu, než ping. Za chvilku si vzpomenete, že ten ping chcete nechat běžet dýl, znovu ho spustíte a bude se to ověřovat celé znovu. Lepší by bylo mít ty údaje nakešované alespoň v rámci lokálního počítače – ať už prostřednictvím lokálního validujícího resolveru, nebo třeba přes NSS s keší.

[pavlix]

Přijde mi, že ten odstavec šel vyjádřit jednou větou tak, aby byl srozumitelný a neobsahoval vnitřní rozpor...

Ale co už, každý máme jiný styl psaní.

[Filip Jirsák]

Vnitřní rozpor tam vidí jenom ten, kdo „klientská DNS knihovna“ a „resolvující DNS server“ považuje za synonyma. Problém pak ale stejně není v té větě, ale v nerozlišení těch dvou termínů.

[pavlix]

Když myslíš.

[Adam Tkáč]

Ano, v pripade DNSSEC se muzeme bavit o klientovi jako o rekurzivnim serveru. Kazdy klient totiz musi rekurzivne validovat podpisy od korenove zony k nizsim domenam. Takze spravna cesta, jak mit opravdu secure DNS je pouzivat napr. BIND nebo unbound jako resolver a /etc/resolv.conf nastavit na 127.0.0.1.

[pavlix]

Akorát pak stejně skončíš na tom, že DNSSEC je centralizovaný :). Lepší než aktuální situace, pravda.

[lertimir]

Co je na centralizovaném přístupu špatného?

[pavlix]

Pán asi neslyšel o single point of failure?

Například to, že centrální bod, na kterém celé zabezpečení stojí, může dát koupit, ukrást, získat vydíráním, ... a zbytek se sesype jako domeček z karet.

Já jsem nikdy netvrdil, že centralizovaný systém je obecně špatný. Jen to, že má své určité vlastnosti, díky kterým je velmi zranitelný zásahem do jednoho jediného bodu.

Zranitelnost centralizovaného systému se ukazuje v mnoha oblastech lidského konání, není to jenom o počítačových sítích.

[lertimir]

Jenže právě kryptografické technologie a technologie sítí umožňují vytvořit centralizované struktury, v nichž neexistuje jedno kritické místo. DNS je nádherný příklad, neexistuje za 30 let žádný útok, který by DNS nějak vyřadil. Byly útoky, které některé z kořenových serverů dostaly do problémů, ale i kdyby některé z těch 200 systémů šlo k zemi, redundance je značná.

Stejně tak představa, že se někdo bude probourávat do trezoru v ICANNu, aby ukradl Hardware security modul (ale ten by mu v podstatě stejně na nic nebyl). Distribuované systémy pro "network of trust" mají zase tu základní nevýhodu, že důvěra je pouze pravděpodobností.

[pavlix]

centralizované struktury, v nichž neexistuje jedno kritické místo.

Jako oxymorón do básničky by to bylo hezké.

DNS je nádherný příklad, neexistuje za 30 let žádný útok, který by DNS nějak vyřadil.

Díky decentralizaci, že?

Stejně tak představa, že se někdo bude probourávat do trezoru v ICANNu, aby ukradl Hardware security modul (ale ten by mu v podstatě stejně na nic nebyl).

To je dost naivní představa. Život bývá mnohem jednodušší.

Distribuované systémy pro "network of trust" mají zase tu základní nevýhodu, že důvěra je pouze pravděpodobností.

Kteroužto základní nevýhodu už z definice sdílení s centralizovanými, tudíž to pro srovnání nemá velký význam.

[jaroleto]

Tak jako nonDNSSEC server obsahuje adresy korenovych serveru, tak i DNSSEC server obsahuje adresy i klice korenovych serveru. Takze dokud je tvuj server nekompromitovany a vsechny bez vyjimky korenove servery podepsane, mitm utok je nemozny.