Názory k článku
Dan Kaminsky a jeho útok na DNS servery

Nie je mi jasná táto časť: "navíc dotaz může vyvolat i samotný útočník". Ako? A prečo predtým nemohol?

Protože v případě větších rDNS a často dotazovaných domén (tedy těch zajímavých) to:

a) buď už bylo ve vyrovnávací paměti
b) ve chvíli, kdy nebylo, tak se na to obratem někdo zeptá

Navíc se bavíme v řádech milisekund a tam se dost hodí, aby útočník hned po odeslání dotazu mohl začít do sítě cpát i odpovědi.

Mohl i dříve, ale musel se zeptat na server, který chtěl podvrhnout. Spojíteli si to s podmínkou, že ten záznam není v cache (čili se na to nikdo od vypršení platnosti nezeptal), vyvstává otázka, proč by kdo takový server kdo "unášel". Pokud je to naopak server, kde je tisícovka uživatelů denně, je časové okno pro vaši diverzi malé.

Oproti tomu pan Kaminsky poukázal na to, že není vůbec nutné použít na dotaz na napadaný server (a tedy čekat na časové okno), ale dá se zaútočit dotazem na kterýkoliv jiný server, klidně i neexistující (což je pro útočníka výhodné, protože nemusí s nikým soutěžit, kdo doručí správnou odpověď dříve).

Ne, to se pletete.

Útok spočívá v tom, že se ptáte na neexistující DNS záznam a nikoli na neexistující server.

Nejlepsi je mit na brane/routeru svuj vlastni DNS server, nepouzivat forwardy na servery ISP a zakazat cizim pristup nebo v pripade verejneho DNS serveru urcite vypnout rekurzi pro cizi.

Nevidim duvod k "podekovani." Tech par schopnych lidi, kteri si to takto nastavi se na celkovem baliku provozu vubec neprojevi.

A k čemu to těm pár schopným lidem bude? Je zapotřebí ochránit ty masy uživatelů, kteří internet jenom používají a tvoří většinu zákazníků ISP.

Co je zarážejícího na tom, že je potřeba mít řešení, které ochrání všechny a nikoli jen pár "vyvolených"?

Urážky jsou většinou znakem toho, že diskutující straně došly argumenty.

Nehledě na to, že vaše reakce nějak úplně nedává smysl.

Já celou dobu mluvím o tom, že pokud má přijít nějaké řešení, tak to má být řešení, které ochrání všechny. A reagoval jsem na větu, kdy pisatel píše o tom, že to root a tld servery nezatíží, protože si to nastaví jenom pár lidí.

Jo tak! Vy potrebujete mit pravdu at to stoji, co to stoji. Tak to jo.
At uz tak ci jinak, zkuste se nekdy v prestavkach mezi ukojovanimi vasich vasni pro pravdu podivat na vyznam slov: logika, urazka, argument, smysl apod.

hod se do klidu

A máte váš názor podložený i nějakými technickými znalostmi nebo jenom opakujete, co jste našel v doporučení CERTu, ale jinak podstatě problému vůbec nerozumíte? Ale oceňuji, že jste konečně zvládl naformulovat, o co vám jde.

Lokální DNS cache vás může ochránit před dvěmi věcmi:

a) útokem na stub resolver, který nemá implementovanou randomizaci DNS portů (viz. ona advisory od CERTu, kterou se oháníte)
b) útokem na vašeho lenivého ISP, který neaktualizoval svoje rDNS (v ČR momentálně nevím o žádných velkých, ale pár malých jsem v querylogu viděl)

Lokální DNS cache je v zásadě jenom řešením, které vám umožní kontrolovat, zda-li máte DNS, který používá náhodné zdrojové porty.

Ale i kdybychom se podívali na to, jestli by se za pomoci lokální DNS cache dala zvýšit ochrana proti Kaminsky-style útokům, tak závěr je, že použití lokální DNS cache není systémovým řešení a problém pouze odsouvá. Aby se útočníkovi nevyplatilo napadnout rDNS, tak by dopad takového útoku musel být velmi malý - jinými slovy museli by na model - co počítač, to rDNS, přejít všichni. Předem upozorňuji, že segmentace na rDNS per organizace nestačí - i útok na nějakou firmu může být dostatečně zajímavý (průmyslová špionáž, atp.). V tu chvíli se ale dostáváme zpátky k první reakci - to by pravděpodobně znamenalo výrazně zvýšenou zátěž na všechny autoritativní DNS servery a speciálně root servery a servery TLD.

Naštěstí se i tady na rootu v diskuzi dají najít lidé, kteří podstatě problému porozuměli, a navrhují věci, které mají hlavu a patu.

Evidentně tomu rozumí víc než vy, tak se nečilte.

Omlouvám se, že se tak blbě ptám ;), ale komu byla tahle poznámka určena?

Útok na rDNS snad ale musí být veden ze sítě, pro kterou má rDNS server vyřizovat, ne? Tzn. útok na firemní rDNS by musel být veden z firemní sítě, např. zaměstnancem. Navíc lokální rDNS server se nemusí spoléhat na rDNS ISP, ale může sám kompletně vyřizovat dotazy (dotazem na kořenové DNS atd.), čímž se docílí toho, že bezpečnost DNS má daná firma zcela ve svých rukou. Není to řešení obecně použitelné (kdyby každá firmička o pěti lidech měla vlastní rDNS, který vše bude vyřizovat od kořenových DNS serverů, asi by to kořenové servery neustály), ale pro firmy na DNS závislé (třeba CA) je to možná cesta.

např. zaměstnancem

To už ne. Není až tak velký problém vyprovokovat DNS dotaz z vnitřní sítě. Např. pokud spamfilter ověřuje existenci domény z smtp helo.

Máte pravdu. Ale v tom případě dobře mu (správci) tak ;-) Ale ono stačí někomu poslat e-mail s nějakým odkazem, do nějaké stránky přidat stažení neviditelného obrázku ze správné adresy atd. Jenom už by se v tomhle případě asi hůř koordinoval ten útok, aby útočník ty falešné odpovědi začal posílat ve správném okamžiku.

Ale v tom případě dobře mu (správci) tak

Tak na takovýhle prohlášení jsem alergický. Ono nejde říct "když to nezapadá do mé představy, tak dobře mu tak/kdo by to chtěl.." Jednak to prostě lidi dělaj, za druhý na tom není nic špatného.

Ale ono stačí někomu poslat e-mail s nějakým odkazem, do nějaké stránky přidat stažení neviditelného obrázku ze správné adresy atd. Jenom už by se v tomhle případě asi hůř koordinoval ten útok, aby útočník ty falešné odpovědi začal posílat ve správném okamžiku

Ono je těch možností nepočítaně, když se do toho zamíchá ještě Javascript, tak už je to skoro, jako by měl útočník v intranetu té firmy zombie. Jinak to koordinování není až takový problém - stačí současně s tím obrázkem z domény kterou budeme chtít otrávit, dát obrázek z útočníkovy domény. Extra body útočník dostane, když tam bude jen jeden obrázek (z domény kontrolované útočníkem), který redirectem přesměruje na kýženou doménu. A jestli chceme tomuto zamezit, tak už se bavíme o bezpečnosti webových aplikací, fór atd.

Obecně, zakládat obranu proti čemukoli na (nedokonalém) zamezení útoků na tu věc, považuji za pošetilé.

:)))
Vazeny pane, vubec tomu nerozumite. Vasi nadrizeni by meli zvazit, zda jste clovek na svem miste vzhledem k vasi urovni pochopeni problematiky. Na tomto foru jste lidem vymlouval doporuceni CERTu a nasledne misto abyste uznal chybu, schovavate se za smes trivialnich a zbytecnych tvrzeni ve snaze odvest pozornost od vaseho katastrofalniho selhani. Zamyslete se nad sebou.

Já jsem vám předložil argumenty, vy se opět vyjadřujete nikoli k předloženým argumentům, ale k mé osobě a lacině mě pod rouškou anonymity napadáte. Pokud máte pocit, že jsem tak katastroficky selhal, máte možnost předložit své argumenty buď zde, nebo mi poslat email, nebo mi zatelefonovat a vysvětlit mi v čem se mýlím. Do té doby s vámi diskuzi končím.

Jsi chudak?

Nerozumím úplně přesně, jak vám zrovna tohle pomůže. Budete jen menší cíl.

Smyslem je minimalizovat riziko. Ostatne ani DNSSEC neni samospasitelne.

Já tomu až tak nerozumím, ale jednak je mi divné, že si DNS cache jen tak něco přepisuje v paměti údaji o které nežádala a jednak, že DNS poskytovatele je napadnutelné z venku jeho sítě, která, jak známo je nebezpečná.

Proč při tomto druhu odpovědi DNS cache prostě jen nevyužije IP adresu a proč musí provést přepis v cache? Jaký to má význam? Snižuje to nějak výrazně množství dotazů tím, že si DNS cache zapíše jméno serveru, které prý ví o nějaké exotické adrese? Význam snad má jen ta vlastní adresa, na tu se někdo ptal, na adresu serveru, který o ní ví se přece nikdo neptal.

Když tomu nerozumíte, tak si přečtěte tu Kaminského prezentaci. :-(

Na otázku jedna je odpověd: Protože se neví, co všechno by to rozbilo, kdyby se to nedělalo, a předpoklad je, že by toho přestala fungovat spousta. Rozdíly mezi glue, které vrací nadřazený server, a které vrací autoritativní server, nejsou zase tak neobvyklé (například jedno legitimní využití, které mě napadá je, když přesunujete IP adresu autoritativního DNS serveru).

Co se týče napadení zvenku:
a) pořídím si hosting
b) pořídím si zombie
c) dá se to udělat i jinak (viz. prezentace od Kaminského) - např. tak, že se připojím na mailserver a on ten lookup udělá za mne

a to je to ze okrem transaction id a portu musi odpoved prist aj s tej istej ip adresy aka bola dotazovana. Otazka je kolko routerov na internete zahazuje pakety zo zdrojovou IP ktory by nemali routovat.

V laboratornych podmienkach samozrejme tento problem neexistuje.

A to poznáte jak? Maximálně na edgi, ale sítí, které implementují bcp38 je strašně málo.

Jen tak pro zajímavost. Má smysl si kontrolovat svou bezpečnost z podvrženého serveru?
Co když je můj DNS server nakažen, a při dotazu na http://www.doxpara.com/ mě pošle pirátskou IP adresu, na které všechny testy vypadají, jako že jsem v bezpečí? :-))
Třeba jsem se vůbec nedostal na ten správný server:-(

Puvodne jsem chtel dat link na Lupu kde v patek take vysel clanek o Kaminskeho DNS cache poisoningu. Je tam link na testovaci stranku primo s IP adresou. Je ale zrejme ze zaznam pro Lupu na vasem DNS je take podvrzeny a precetl byste si clanek se spatnou ip adresou. Tady je tedy primo ten link - http://149.20.3.33/test/ Doufam ze necteme podvrzenou verzi Roota - to uz by zavanelo globalnim spiknutim :-)

:-DD

Nestačilo by náhodou, aby DNS servery mezi sebou používali IPSec s podpisem?

reseni je DNSSEC, ale je to dost pracne... (tip na IPSec byl dost mimo :)

mimojine Unbound (unbound.net) je pokud vim jeden z mala, jeste s MaraDNS (ale ten ma probles s IPv6), ktery timto utokem nebyly postihnutelny. Unbound je by default v chrootu, podporuje IPv6 (bind to socket i query)...

IMO pevne zaznamy do host suboru :) a DNS sa pitat az ked uz bude zaznam v hosts neaktualny.

To jste myslel jako vtip, že jo?

Můžu se zeptat proč je IPsec mimo?

DNSSEC má zajistit integritu dat a původ dat - ipsec funguje
DNSSEC potřebuje úpravu softwaru na straně klienta i serveru, tady je ipsec napřed, stačí nastavit
oba systémy potřebují klíč, šířený např. certifikátem
ipsec by navíc mohl hodně paranoidním uživatelů zajistit i šifrování komunikace :D

takže opravdu nevidím problém... pokud Vy ano, rád se přiučím

Hmm, takže máte pocit, že by si DNS server měl udržovat klíč od všech serverů, které bude kontaktovat? To je jistě báječné řešení. Hlavně teda pro certifikační autority.

Kdežto s DNSSEC to dělat nebude... všechny DNS servery budou používat jeden celosvětový všeobecně známý klíč...

OMG... tak si o tom, jak to funguje v DNSSECu něco přečtěte... není to tak složité (číst)...

Ano, v ideálním případě bude všem resolverům stačit klíč jeden - a to klíč root zóny.

djbdns má randomizaci portů už od začátku. unbound taky... powerdns to mělo taky, ale to zase trpělo jinou "pěknou" chybkou.

A nic z toho proti tomuto útoku nečiní DNS server "postihnutelný" nebo "nepostihnutelný". Randomizace source portů problém pouze odkládá.

Ja bych vsechny ty DNS servery zrusil, nechal lidi pamatovat si IP adresy a bylo by po problemu:)

Možná hloupý dotaz ale... Když si budu pamatovat IP adresu serveru s internetovým bankovnictvím a budu se tam lézt jen pomocí ip tak bych měl být na 99% v bezpečí, ne?

A co když:
* Banka změní IP adresu (změna poskytovatele) a na její původní přijde někdo škaredý...
* Mezi vámi a bankou je někdo škaredý...

Prostě pokud jde o banku je třeba mít https a věnovat pozornost tomu zda certifikát o kterém je tvrzeno, že je její, je opravdu její...

Ještě bych dodal, že ještě důležitější je přistupovat k bance z důvěryhodného stroje.

No a na závěr snad ještě - mít banku, které se dá důvěřovat.

Podtrženo sečteno: internetové bankovnictví je prostě hazard:-)
No a přece jen ještě něco: mít peníze v bance je hazard:-)
No a málem bych zapomenul: mít peníze je hazard:-)

:D no jo no. Možná bych měl věnovat peníze nějakému ústavu. Třeba ústavu pro léčbu poruchy osobnosti :)

Ja si klidne jakykoliv penize vezmu, kdyby nekdo nevedel, co s nima. :)

a nakonec jste zapomnel na: penize jsou hazard

Vidite to moc cerne. Penize stejne ve skutecnosti neexistuji:
http://video.google.com/videoplay?docid=-446781510928242771&hl=en

Ano,

ste v bezpeci ked vam browser otvori tu stranku. Druha vec je ci vam to otvorenie stranky staci :)
To ze uz hocikde kliknete na tej stranke alebo samotne prihlasovanie bude zas a znova pouzivat FQDN -> resolvovane DNS.

To zni nebezpecne. :) Lze tohle nejak ze strany uzivatele obejit? Aby to DNSko proste obchazel porad?

To by byl spolehlivy konec tehletech Internetu. 9 z deseti duchodkyn by bylo spokojenych.

Proc by nestacilo, aby se obratilo poradi protokolu? Dnes se DNS pta pres UDP, a pokud je odpoved > 512 bytu, tak zkusi znovu pres TCP. Kdyby se ptal pres TCP rovnou (za cenu nekolikrat vic packetu, ale co uz), ziskal by lepsi duveryhodnost. Dalsi moznost by byla nucene zkraceni TTL u vseho, co DNS server dostal jen jako additional section.

-Yenya, http://www.fi.muni.cz/~kas/

Používat TCP místo UDP navrhovalo hodně lidí, ale vzhledem k značnému nárůstu režie by to nameservery které jsou už dnes hodně zatížené (tedy ty, které mají hodně klientů a na které právě kvůli tomu má velký smysl útočit) nezvládly. Korektně navázat a ukončit TCP spojení je dost velká režie, v porovnání s odesláním a přijetím UDP paketu. Už teď se některým správcům nelíbí, že jejich BINDu najednou nestačí pro příjem odpovědí jen jeden UDP port (je třeba zvedat ulimit -n).

Už jsem na to samé odpovídal na lupě ;), tak přidávám link:
http://www.lupa.cz/clanky/nejvetsi-bezpecnostni-hrozba-posledniho-desetileti/nazory/230819/

A ještě jeden komentář... DNS přes UDP už dávno (resp. od EDNS0) není omezeno velikostí 512 bytů. Pro DNSSEC je například EDNS0 nutné.

"Tak nikdo asi nepochybuje o tom, že tu nečteme podvrženého ROOTa"

Chtěl bych mít vaší jistotu:-)

Myslím si, že pokud jde o weby situace by měla směřovat k https - zejména pokud příslušné weby umožňují nějaké registrace (tohle například tady na root.cz chybí - pokud se nepletu). Částečně by to řešilo i tento aktuální DNS problém.

Souhlasím i s https. Ale to u banky většinou nechybí. Pokud jde o Roota, bohužel jsem neuspěl, přiznávám, .. jde o podvrh a všichni čtou mého roota. Podrobnosti vyjdou brzy na mnou podvržených Novinkách (nestíhám ten internet celý psát tak rychle) ... ;-)

Podvrh webu nemusí být tak složitý co do získávání obsahu. S originálního prostě bude dle požadavků brát vše a jen si občas něco doplní či změní či zaznamená (hesla) - prostě podvržení typu "muž/žena uprostřed".

Každopádně to co nyní čtete jsem možná nenapsal:-)

Ha. Muz/zena uprostred. Pecko na Rootu? Kam to s tim linuxem speje. ;-) ... ale tak zatim jste mi nevyvratil, ze kdyby takova banka (obdobna instituce) misto "zapamatovatelne" adresy obvykle uvadene, davala odkaz na ip adresu serveru, kde sluzby bezi, lecos by to v tomhle ohledu resilo. Ci se pletu?

Ano pletete. U banky váš nemusí zajímat ani FQDN ani IP. Jediné co by váš u inet-banky mělo hodně zajímat je SSL certifikát.

„Ale to u bany většinou nechybí“

Nedávno jsem četl nějakou „studii“, která tvrdila, že uživatelé jsou tak navyklí odklepávat různé chybové hlášky (např. co se týče certifikátů), že ani https u naprosté majority populace nepomůže...

S téměř bezmyšlenkovitým odklepávání varovných hlášek kolem certifikátů https to asi nyní bude špatné, ale věřím, že se to bude zlepšovat.

Osobně mám problém s tím dát nějaké autoritě v prohlížeči důvěru na vše co podepsala. Proto třeba volím souhlas jen s daným konkrétním certifikátem. Ovšem za rok na mne vyskočí bubu, že již je certifikát jiný a a co teď? Jde o podvrh nebo prostě starý certifikát už měl časově skončit a tak si organizace vygenerovala a nechala podepsat nový? Přivítal bych asi možnost dát důvěru nějaké certifikační autoritě jen na konkrétní weby či domény - umí to nějaký prohlížeč?

To ovšem řešíte Vy, já a většina čtenářů Roota (snad). Běžný uživatel netuší nic o HTTPS, fingerprintech a o šifrování má jen velmi mlhavé znalosti. Všichni běžní uživatelé dotaz na certifikát automaticky potvrzují. Kdysi mi někdo vyprávěl, že zkoušel na routeru podvrhovat uživatelům falešné certifikáty. Měl na to nějaký automat, který jednou podvrhl a pokud uživatel nesouhlasil, napodruhé už nechal spojení bez změny. Úspěšnost byla 40 000:12. Jen 12 uživatelů podvržený certifikát nepřijalo. Ostatní souhlasili. HTTPS je bez správného užívání naprosto k ničemu.

U nepoucenych a zmatenych laiku to budi jenom des, kdyz na ne takove bubu vyskoci. Videl jsem, ze to nektere lidi dokaze pomerne nadlouho odradit, aby tu sluzbu vubec pouzivali, protoze se boji zavirovani. Staci, ze vidi v IE stranku, ktera je zrazuje od pokracovani dal. Ze si maji nekde stahnout nejaky certifikat, je nenapadne a zkoumat, coze to je vlastne za "technicky problem" taky ne. Od toho je prece administrator. :D V tom lepsim pripade to konci takhle, v horsim je jim to jedno a odklikaji vse.

Budte radi.... aspon mame pracu....

OT: Vy jste psychiatr nebo hrobník? :)

http://blog.nic.cz/2008/08/08/dns-utok-podle-kaminskeho/
uznavam, ze trocha omacky tu navic je, ale za plnohodnotny clanek bych jej nepovazoval - patri spise do sekce zprav, kde se ostatne jiz na tomto serveru vyskytuje...

Struktura je stejná, ale jak jinak byste to chtěl napsat. A popravdě řečeno jsem jenom rád za to, že to vyšlo i jako plnohodnotný článek, protože je to nakolik důležité, že si to tu trochu pozornosti zaslouží.

Na http://www.doxpara.com/?p=1215#comments jsem zkoušel navrhnout co mě napadlo pro zvýšení zabezpečení nameserveru, zatím mi připadá že by to mohlo fungovat. V podstatě jde o to, že pokud se nameserveru v odpovědi na jeho dotaz vrátí něco, co je v rozporu s údaji, které má v cache, prostě se zeptá znovu. To, že by útočník dokázal podvrhnout dvě odpovědi za sebou, má už značně nižší pravděpodobnost.

Bohužel to by nefungovalo. Různé cache a CDN můžou vracet na každý dotaz jinou IP adresu. (Úplně nejjednodušší případ je překročení velikosti paketu bez použití EDNS0) A co pak? Čemu důvěřovat?

Jinak na diskuzi nad dns protokolem je mnohem lepší diskutovat to konferenci namedroppers @ ietf (pracovní skupina dnsext). A dobré je si přečíst archív než člověk něco napíše.

Pak by se dalo preventivně více důvěřovat své cache než obsahu první či druhé odpovědi. Když už se mi ta data do cache dostala, tak jsou dvě možnosti: buď je někdo chce často měnit, tak jim dá malé TTL. Pak by nemělo vadit že si je chvilku podržím (do konce TTL) a nenechám přepsat. Nebo je nechce často měnit, pak jim dá velké TTL, a zase by nemělo vadit pokud si je podržím v cache až do konce. Prostě připadá mi že přepisování záznamů v cache před koncem jejich TTL je příliš nebezpečné - dává zbytečně vyšší šanci útočníkům. namedroppers @ ietf neznám, a číst preventivně všechny archivy nezvládám. :-)

Tak ještě jeden příklad:

od TLD serveru dostanu v AUTHORITATIVE/ADDITIONAL nějakou IP adresu autoritativního serveru. Ale autoritativní server vrací IP adresu jinou (nebo více třeba kromě A vrací i AAAA záznam). Co je pak správně?

Jistě přepisování nebezpečné je. Ale tak nějak to reflektuje současný stav DNS dat...

Není potřeba číst všechny archívy... stačí tak posledních čtrnáct dní... ale jestli budu mít dobrou náladu a trochu času tak do CZ.NICového blogu zkusím udělat takový výcuc návrhů, které jsem za ten poslední měsíc viděl, a jejich výhody a nevýhody.

To co teď píšeš mému řešení vůbec nevadí. Já jsem navrhoval poslat znovu ten samý dotaz (pouze s jiným TRXID a případně z jiného čísla portu) tomu samému serveru. Pokud mi ten samý server na druhý stejný dotaz vrátí jinou odpověď, pak teprve bych to považoval za útok. Pokud vrátí podruhé stejnou odpověď jako poprvé, už bych jí věřil - nepředpokládám že se v součanosti publikovanými informacemi se podaří útočníkovi trefit dvě odpovědi (jak bylo prezentováno např. na http://tservice.net.ru/~s0mbre/blog/devel/networking/dns/2008_08_08.html jednu odpověď trefit může).

Pokud dojde k té nekonzistenci kterou zmiňuješ, může se stávat, že budu duplikovat dotazy - pokud se budu střídavě ptát TLD nameserveru a autoritativního nameserveru. Ale proč bych se takhle hloupě ptal střídavě TLD nameserveru a autoritativního nameserveru, když už mám data v cache? Takže zase tak moc často moje navrhované řešení duplikované dotazy posílat nebude.

Já myslím, že jako odpověď můžu použít:

http://www.root.cz/clanky/dan-kaminsky-a-jeho-utok-na-dns-servery/nazory/220161/

Hlavně teda tu část, co psal Vixie - tj. že se nutně nemusí jednat o přepisování cache.

Co se týče dvojitých dotazů, tak otázka je, zda-li by se stejného efektu nedosáhlo jenom tím, že ve variantě b) by se prostě počkalo až vyprší TTL toho, co má server uložené v cache. Tvůj návrh má pouze tu přidanou hodnotu, že by v některých případech cache zaktualizovala a v některých ne, což se, jak správně píšeš v předchozím postu, dá mnohem lépe řídit pomocí TTL u takovýchto záznamů.

Naprosto sdílím obavu Paula Vixieho, že pouhé spoléhání na TTL by mohlo vést k problémům. Nakombinovat totiž část dat (answer section) z odpovědi nameserveru a část dat (additional section) ze své cache je evidentně netransakční, a kdoví co všechno by se tím mohlo rozbít - viz "there are plenty of kaminsky message patterns that rely only on insertion of new data". Ale já přeci navrhuji něco jiného! Můj přístup je takový, že v případě potenciálního útoku (kdy by v případě klasické implementace došlo k přepisu cache) se hodlám ujistit, že k přepisu cache (který by možná mohl být skutečně užitečný) skutečně má dojít. Ujištění hodlám provést opakováním dotazu, neboť zabezpečení z prostoru necelých 2^32 (2^16 TRXID + necelých 2^16 číslo UDP portu) nepovažuji za dostatečné - naopak zabezpečení z prostoru necelých 2^64 už mi bezpečné připadá.

Takže bych to shrnul: pokud cache a 1. odpověď obsahuji stejná data, pouze podle odpovědi upravím TTL (nejen prodloužím, jak píšeš, ale klidně i zkrátím). K druhému dotazu nedojde. Pouze pokud cache a 1. odpověď obsahují různá data, dojde k opakování dotazu. Pak pokud 1. a 2. odpověď obsahují stejná data, dojde k použití dat z 2. odpovědi (přeci jen je čerstvější). Pokud cache a 2. odpověď obsahují stejná data, dojde k použití dat z 2. odpovědi (a tím k potenciálnímu odvrácení útoku).

Jediné, u čeho si ve svém přístupu nejsem úplně jistý, je jak se zachovat v případě, že cache, 1. odpověď a 2. odpověď budou obsahovat tři různé údaje. Preventivně žádný z údajů nepoužít (jako kdyby nepřišla žádá odpověď)? Nebo použít údaje z 1. odpovědi? Nebo použít údaje z 2. odpovědi? Použít mix dat z jedné z odpovědí a cache se obávám že by mohlo vést k potížím.

Jediné, u čeho si ve svém přístupu nejsem úplně jistý, je jak se zachovat v případě, že cache, 1. odpověď a 2. odpověď budou obsahovat tři různé údaje. Preventivně žádný z údajů nepoužít (jako kdyby nepřišla žádá odpověď)? Nebo použít údaje z 1. odpovědi? Nebo použít údaje z 2. odpovědi? Použít mix dat z jedné z odpovědí a cache se obávám že by mohlo vést k potížím.

Tak se zeptat ještě jednou. Pokud bude 2. a 3. odpověď nebo 1. a 3. odpověď stejná, použít data ze 3. odpovědi. Pokud se to nadále bude lišit, považovat to za útok a ponechat data v cache tak, jak jsou a počkat X hodin.

Třetí dotaz už podle mě nic neřeší, jen komplikuje. Případná neshoda se bude muset řešit tak jako tak. A s dnes známými informacemi to vypadá, že se útočníkovi zfalšovat dvě odpovědi za sebou téměř nemá šanci povést a to ani při mnohonásobném opakování. Na rozdíl od zfalšování jedné odpovědi, což při mnohonásobném opakování má reálnou šanci na úspěch.

imho řeší. Buď ukáže, že jedna z odpovědí byla útokem či chybou a lze tedy tudo odpověď zahodit, nebo ukáže, že se v dané chvíli nedá na odpovědi spolehnout, protože jsou pokaždé jiné (nebo je snad normální, aby byly pokaždé jiné odpovědi na stejný dotaz opakovaný třikrát v řádu maximálně sekund, spíše ale desítek milisekund?), a tak se prostě ponechají data v cache a dotaz se zopakuje později.

(nebo je snad normální, aby byly pokaždé jiné odpovědi na stejný dotaz opakovaný třikrát v řádu maximálně sekund, spíše ale desítek milisekund?)

Ano, já myslím, že to může být zcela normální. Třeba v případě toho, že je adresa, kterou to vrací, vybírána nějakým round robinem nebo zcela náhodně.

jj, dočetl jsem se to těsně po odeslání svého komentáře. Nicméně takové odpovědi asi mají typicky velmi krátké TTL, ne? Tedy by se to dalo snadno ošetřit. Navíc to asi nebudou příliš běžné cíle útoku...

Každopádně to řešení s opakovaným dotazem při pokusu o přepis před koncem expirace by pomohlo řešit část útoků bez nějakých větších zásahů do systému DNS i jeho funkčnosti (netřeba měnit protokol ani způsob komunikace, stačí malý update DNS serveru).

Není to však řešení úplné. Je to jako NAT na IPv4. Jen by to oddálilo, resp. zmenšilo aktuální problém. Bohužel stejný "pocit" mám i z DNSSEC, pro které je už nutná změna způsobu komunikace. Chce to změnit a zabezpečit celé DNS.

Jenže protože nejsem z oboru a prd tomu rozumím, tak se jdu radši věnovat své práci. ;)

Nene, to jsi podle mě Vixieho špatně pochopil. On říká, že tvůj druh obrany chrání jenom proti části těchto útoků. Tj. jsou Kaminsky-style útoky, které nepotřebují přepisovat cache. Alespoň tak já chápu, to co napsal.

Vzhledem k tomu, co píšeš ve třetím odstavci, je podle mě jediné konzistentní chování nepřepisovat cache vůbec. Ale stále jsme i tak tam, kde jsme pořád byli - pokud existuje útok, o kterém píše Vixie (dle prvního odstavce mé zprávy), tak si tímto řešením nijak zvlášť nepomůžeme.

To, co navrhuji, skutečně slouží pouze k ochraně proti přepsání cache. Je pravda, že Dan Kaminsky ukazuje i jak do cache dostat informaci o DNS záznamu, jehož jméno si ale nemůže útočník vybrat. Prostě se bude ptát nameserveru na náhodná jména, a zároveň ho zaplavovat podvrženými odpověďmi. Toto se spoustou náhodných jmen. Útočník ovšem v tomto případě nemá kontrolu nad tím, kterého náhodné jméno se mu povede do cache nameserveru dostat. I toto se dá zneužít, za předpokladu že nějaký jiný protokol (např. HTTP) pokládá přítomnost nějakého jména v doméně za dostatečnou autorizaci (např. cookie). Toto neřeším a připadá mi že je to problém těch jiných protokolů, které autorizují na základě DNS jména - to je prostě jejich chyba. "tak si tímto řešením nijak zvlášť nepomůžeme" mi tedy nepřipadá jako pravda - zabránit přepisu existujícího záznamu v cache mi připadá jako velmi cenná pomoc.

Základem mé obrany je druhý odstavec který jsem popsal. Tam se podle mne vyřeší drtivá většina běžných situací. Ve třetím odstavci se řeší pouze poslední možnost, která podle mne nebude v praxi často nastávat, a je na zvážení případných implementátorů aby si nějaké chování vybrali. Ale opakuji, ten třetí odstavec už není to podstatné, základem je druhý odstavec!

Podle mě dostání neexistujících záznamů do DNS cache může být stejný problém jako přepsání údajů v ní.

Představ si například podvrhnutou odpověď:

;; QUESTION SECTION:
006a.klient5.ebanka.cz. 86400 IN A 1.2.3.4

;; AUTHORITY SECTION:
klient5.ebanka.cz. 86400 IN NS 006a.klient5.ebanka.cz.

;; ADDITIONAL SECTION:
006a.klient5.ebanka.cz. 86400 IN A 1.2.3.4

(Tj. útočník má kontrolu nad tím, co do cache dostane.)

V tu chvíli jediné, co potřebuju, je uživatele nějak nasměrovat na "nové" stránky bankovnictví.

Nebo můžu zkusit něco jako wvw.původnístránky.cz... nebo nechvalně známé .cy vs. .cz. - tj. podvrhnout www.internetovabanka.cy - jasně, že si toho spousta lidí všimne, ale určitě se najdou i takoví, co překlep přehlédnou.

***

Chápu, že základem je druhý odstavec. Mě se na tvém návrhu v podstatě nelíbí dvě věci:

a) řeší to jenom část problému (viz. výše)
b) podle mě ty validní nekonzistence budou nastávat právě u nejvíce exponovaných adres (například www.l.google.com). Přiznám se, že mám pouze obecnou představu, jaké algoritmy používají CDN (typu Akamai) na přidělování IP adres, ale mám takové tušení, že zrovna tady by to mohlo narážet nejčastěji. Různé load-balancery od Cisca a dalších fungují v jednom módu například tak, že přidělí záznamu nízké TTL a vyberou IP adresu stroje, který má požadavek obsloužit. Pokud je výběr IP adresy řízený aktuálním zatížením (nebo round robinem) strojů v clusteru, tak se opravdu může stát, že na každý dotaz bude vrácena jiná IP adresa.

Ale v zásadě pokud tvůj návrh bude obsahovat i řešení konfliktních situací, tak bych navrhoval, abys jej hodil do angličtiny a poslal do namedroppers. Nicméně osobně si myslím, že na něj bude stejná reakce, jako jsem posílal citaci od Vixieho (nebo žádná).

Mimochodem, našel jsem ještě jeden příklad toho, jak může vypadat legitimní rozdíl mezi odpověďmi:

authority foo.org NS ns1.a.foo.org
additional ns1.a.foo.org A 10.0.0.51

authority a.foo.org NS ns1.a.foo.org
additional ns1.a.foo.org A 10.0.0.71

(Vixie navrhuje používat vždy ten nejhlubší záznam; Matasaka udržovat kontext.)

Mozna byste mohl misto vycucu navrhu se zabyvat timto svym iracionalnim konstatovanim:
"Jistě přepisování nebezpečné je. Ale tak nějak to reflektuje současný stav DNS dat..."

Predstavte si, ze vam nejaky dodavatel rekne: "Jiste, v nasem softu je chyba, ktera s docela velkou pravdepodobnosti umozni nejakemu zlodeji behem pristich par let pustit zilou vasemu bankovnimu uctu, ale tak nejak to reflektuje soucasny stav naseho softwaru, takze to opravovat nebudem"
Netreba byt expertem, aby bylo jasne, ze zakaz prepisovani existujiciho (stale platneho) zaznamu nezpusobi vubec nic. Existuje snad nejaky vesmirny ukaz, ktery by nastal, kdyby onen paket s prepisujici informaci neprisel ?

Motáte dohromady dvě věci. Já o software nic netvrdil. Mluvím o DNS datech - tedy obsahu všech těch zónových souborů, které v DNS stromu momentálně jsou.

Současné implementace fungují tak, že odpověď, které jsou na stejné úrovni podle RFC 2181 sekce 5.4.1., je přijmuta do cache následujícím způsobem:

a) pokud jsou data stejná - prodloužíme TTL
b) pokud jsou data rozdílná - použij novější data

Obecně panuje názor, že by to nemuselo ničemu ublížit, a mohlo by se vyzkoušet experimentálně nasimulovat, co by se stalo, kdyby se chování v tomto případě změnilo.

Každopádně to v zásadě nic neřeší, budu citovat Paula Vixieho:

"nonreplacement of rrsets is not a general fix. there are plenty of kaminsky
message patterns that rely only on insertion of new data. so while i'm having
great fun with just reducing the TTL when a replacement is attempted,
especially with NS RRsets, it doesn't make me safe."


Mimochodem opatrnost je opravdu na místě. Každá změna může potencionálně zasáhnout milióny uživatelů. Pořád se bavíme o protokolu DNS.

A to používání IP číselné adresy a ne názvového aliasu. Podle mého soudu stačí aby měl každý uživatel své "secure" adresy v číselné podobě a pokud něco nebude znát, tak na dotyčné číslo pronikne přes vyhledávač.

Nevím zda to autor nemyslel tak, že DNS nebude. A vyhledávač bude odkazovat také jen na IP adresy. Zároveň by asi pak vyhledávač měl zřejmě hrát jakousi roli autority, že tohle číslo opravdu přísluší této nějaké konkrétní organizaci. Ale možná se pletu.

Nicméně ani neprůstřelné DNS, tedy jistota, že k tomuto jménu přísluší tato IP adresa obecně nezajišťuje, že pak komunikuji s tím s kým si myslím...

Tj. místo decentralizovaného DNSka bude jedno místo (vyhledávač), které bude cílem útočníků.

Nehledě na to, že IPv4 už na takové srandičky nemá dost adres. A další technické perličky - jako webserver, který má tolik IP adres, co hostovaných webů apod...

Lepsi nezli DNSSEC a navic nepotrebuje centralni autoritu :-)

http://cr.yp.to/djbdns/forgery.html

Samozrejme, clovek musi prijmout Bernsteinovo videni sveta (coz je nekdy dost tezke). Ale myslenka je to velice elegantni. A resila by *zejmena* takove ty DNS-based utoky proti bankovnim strankam, protoze tam se clovek vetsinou prihlasuje pres bookmarky.

Víte, ono přijmout djb vidění světa může taky znamenat, že budete mimo realitu. Ten návrh je podobně pitomý jako návrh ve zdejší diskuzi začít používat jenom IP adresy.

Možná by stálo za to místo papouškovaní mnoho let staré stránky začít přemýšlet nad tím, jestli se návrhy od djb stále ještě setkávají s realitou a praxí v ní. (Poradím vám - u většiny věcí je odpověď ne.)

Nejak nerozumim, cim vas muj prispevek nasral, ale kazdopadne se vam za to omlouvam.

A kde je teda to funkcni DNSSEC, kdyz je ta djb stranka uz pet let stara a tedy zjevne nespravna?

Jenom upřesňuji, že jako pitomý jsem označil návrh od djb, nikoli ten váš začít to používat. Zkuste si představit, jak by vypadaly všechny adresy, a jak by se to "perfektně" používalo... Vidím ten telefonický rozhovor, kdy druhé straně dáváte URL na své stránky. Nemluvě o tom, že by bylo potřeba přejmenovat všechny počítače při změně klíče (což je potřeba dělat). Ten návrh je naprosto mimo realitu.

A asi jsem odkaz na tu stránku v posledních dnech viděl příliš mnohokrát a vždy to bylo bez rozmyslu reálných konsekvencí tohoto návrhu. A už to na mě působí jako červený hadr. Omlouvám se za to papouškování, mohl jsem to napsat mírněji.

DNSSEC pokročil do verze DNSSECbis, námitky proti NSEC byly vyřešeny v NSEC3. Tj. je to něco na čem se pracuje. Zónu má podepsanou Švédsko, Bulharsko, Portoriko, je podepsaná reverzní zóna na RIPE. Česká doména se připojí během krátké chvíle. IANA testuje podepisování root zóny (a ostatních, které spravuje).

Bohužel podepsání root zóny není problém technický, ale politický. Snad se to povede v dohledné době vyřešit. Nicméně ani to není překážkou nasazení.

Ano, problem nymu je problem srovnatelny s problemem distribuce klicu v jakekoliv jinem public key systemu. DNSSEC na tom nakonec nebude lepe.

Podepsana jmena (nymy) mohu nakonec dostat z tehoz mista, jako dneska dostavam certifikaty, ne? :-)

A ano, klice pro DNSSEC a podepisovani a sprava klicu, to je problem politicky. A z toho duvodu k tomu nakonec nedojde. Pokud se to za nejakych deset let nepovedlo, nepovede se to nikdy.

Bohužel se toho o nym base security v podání djb dá zjistit ještě méně než o genocidě Arménů v Turecku... takže mě kdyžtak opravte... nicméně nepředpoklám, že by google měl speciální filtr na djb a jeho nym based security, takže hádám, že oba vycházíme z té jediné stránky s názvem forgery.html a případně občasných drobných zmínkách.

Pokud jsem djb správně pochopil, tak by se jednalo o to, že by doménové jméno nevypadalo 'www.root.cz', ale např. www.128309ADCA12A.root.cz (nebo jinak poskládané, ale pro ilustraci to doufám stačí). Tzn. když by bylo potřeba vyměnit klíč a doménové jméno znovu podepsat, tak by došlo k tomu, že by ta adresa najednou nebyla www.128309ADCA12A.root.cz ale www.9876AD9BEF.root.cz (opět jen příklad). Důsledky doufám vysvětlovat nemusím. To byla první námitka.

Druhá námitka je doufám očividná - bylo by to stejné jako návrh výše v diskuzi, aby se používaly IP adresy. Stejně nesrozumitelné. A to jak pro www, tak pro emailové adresy...

Ale možná vycházím ze špatného předpokladu. Pokud ano, tak by mě zajímalo, kde to djb popisuje detailněji.

Ad první odstavec) V DNSSECu je distribuce klíčů hierarchická stejně jako DNS. Na DNSSECu je pěkné právě to, že nemění model důvěry.

Ad druhý odstavec) Věřím, že certifikačním autoritám by se váš návrh moc líbil.

Ad třetí odstavec) Bohužel vaše věta o tom, že se to nepovedlo za deset let, je blábol pramenící pouze z vaší neznalosti problematiky.

Mé doporučení zní - vyřaďte djb z vašeho soukromého panteonu a nad jeho návrhy zkuste přemýšlet.

"Soukromy panteon"? Hm... Myslim, ze dalsi diskuse je fakt zbytecna.

Preji prijemny vikend.

Ten doxpara test ma mensi mouchu. Netestuje DNS server, ktere mam nastaven, ale DNS server, ktery pouziva muj ISP, coz neni vzdy to same. DNSstuff test se chova korektne a testuje spravny server.

Test testuje DNS ze kterého mu chodí dotazy... tj. testuje to DNSko, které je důležité. Podle mě se to chová korektně.