Vlákno názorů k článku DNS resolvery opravují chybu KeyTrap: příliš mnoho klíčů, resolverova smrt od Danny - S temi NSEC3 iteracemi je to podobne jako...

S temi NSEC3 iteracemi je to podobne jako s cimrmanovskou hospodou, do ktery ale chodili lidi :-) Aneb do standardu strcili iterace, ale divili se, ze je zacli lidi misty pouzivat, zvlast kdyz jim do RFC primo napsali ze to zvysuje bezpecnost...

Ze ale jsou vypocetne iterace narocnejsi se pise uz v kapitole 3.1.3 RFC5155, samozrejme ze v mezni situace ty zminene zvysene naroky muzou prinest i odepreni sluzby - to prece nemuze nikoho prekvapit. Proto uz to puvodni RFC si soucasne v kapitole 10.3 samo nastavilo (byt pomerne vysoko) limity, kam az muze uzivatel zajit.

Ono jen tak mimochodem cele RFC9276 je tak trochu o zarazovani zpatecky i z pohledu bezpecnosti - kdy se honi jen ten vykon, QPS... a nic vic. Uz jen samotne jeho doporuceni drzet se pokud mozno NSEC, kdy bez dodatecnych ohaku typu online podepisovani ala RFC4470 neni nikterak vypocetne narocne zjistit obsah cele zony pusobi proste divne. NSEC3 tu enumeraci obsahu minimalne zkomplikuje, vyzaduje vic zdroju - to je neoddiskutovatelny fakt. Akorat ze na funkcni online podepisovani a tedy odolnejsi implementaci s NSEC je treba mit privatni klice na vsech autoritativnich nameserverech, nejen na (nedejboze hidden) masteru - coz samo o sobe rizika jinde zase trosku zvysuje...

Jeste zajimavejsi je srovnani textace vysledneho RFC s uvodnim draftem, kdy se v kapitole 4 oproti prvotnimu navrhu uz neobjevuji pevne limity k iteracim, ale vagne mluvi se o particular value... aneb jak v praxi vznika ta slozitost RFC ;-) A samozrejme cele pojeti RFC5155 versus RFC9276 je tak trochu o litani ode zdi ke zdi, od spousty iteraci se skokove doslo k nule...

Predstava, ze lidi vice jak patnact let navykli neco nejak delat za rok a pul zmeni sve chovani je take vtipna :-) Ne, lidi bezne nectou RFCcka u ranni kavy. A samozrejme pomerne zasadni zmenu standardu tezko postrehnou, kdyz i nastroje k podepisovani zon se tvari, ze vic iteraci vlastne zadny problem neni - tady maji opet maslo na hlave i sami autori DNS software, kdy si ten draft a pozdeji RFC do sveho kodu v tomto smeru fakticky nijak nezaclenili - alespon ve forme nejakeho warningu, co se uzivateli zobrazi, kdyz tam zada tech iteraci vic, nez si RFC9276 zada...

16. 2. 2024, 08:53 editováno autorem komentáře

tohle je asi jen špička ledovce. Na popud těhle posledních CVE a DoS jsme začali testovat DNS resolvery na nevalidných záznamech v zóně a po prvních iteracích to vypadá, že těch validací tam musí přibýt víc.

Problém je, že útočník má/může mít NS pod svoji kontrolou a dokáže tím odstavit i poměrně silné DNS resolvery je pěkně nebezpečné.

Vždycky mě baví, když někdo vytáhne, že mít privátní klíče na autoritativních serverech zvyšuje riziko. To je samozřejmě pravda, ale pokud se dá do kontextu, že DNS používáme nikoli jako cíl, ale jako prostředníka pro přístup k aplikačním protokolům jako HTTPS, SSH, nebo třeba SMTPS, které nic jiného než online podepisování neumí a přítomnost privátního klíče na serveru vyžadují, pak hned ten přehnaný strach o bezpečnost DNS vypadá jako v tom meme s bezpečnou brankou kolem které není žádný plot.

Offline podepisování má smysl vlastně jen pro hodně velké instalace typu kořenová zóna nebo TLD. Naprostá většina ostatních by si bez problému vystačila s online podepisováním. Největší problém tady je podle mě v tom, že online podepisování je nezajímavé pro horní patra DNS infrastruktury, odkud ale teče většina prostředků pro vývoj open-source řešení pro DNSSEC. Takže je offline podepisování jednodušší nastavit a provozovat.

Tak ono tam jsou i dalsi problemy, treba to ze tu distribuci privatniho klice musis taky nejak vyresit. Coz muze byt netrivialni uloha v pripade, kdy cast infrastruktury nemas plne pod svoji spravou, pak muzes mit i problem to zautomatizovat...

Offline podepisovani ma prave smysl mj. i u drobnych instalaci typu sekundar si strcim ke kamaradovi. A ze takovych instalaci kolem sebe najdes, ze? ;-) A kdyby drobnych, tenhle model pouzivaji i nektere instituce ve statni sprave - kdy sekundarni DNS jim provozuje nejaky 3rd party dodavatel v ramci sve infrastruktury a u sebe na urade maji jen primar.

Zase si ovědomte, co se s tím uteklým klíčem udělat. SSL privátní klíč je Vám bez dalšího (aktivního) útoku naprosto k ničenu, komunikaci stejně nerozluštíte díky PFS, na Váš server lidi také nepřijdou.

Zatímco děravý DNS s privátním klíčem? Můžete record změnit (takže přesměrovat lidi k sobě), samozřejmě si můžete říct o SSL certy, takže lidi to nepoznají, i ten SSHFP spolu s IPčkem změníte - to už nejsou vrátka, ale pětiproudá dálnice pro útočníka.

Je zajímavé, že v diskuzích pravidelně šermujete RFCčky a teď tu reagujete v opačném duchu. Pro zajímavost uvedu, že jsou lidé v komunitě DNS, kteří intenzivně monitorují jak se ve světe používá DNS a snaží se významné případy řešit. V .cz je něco přes 100 domén s vysokým počtem iterací a drtivou většinu spravuje jedna firma, možná znáte. Přes kolegu jsem vzkazoval, že by bylo rozumné to snížit.

Kontrolu na počet nastavených iterací nad 20 jsme třeba implementovali již v Knot DNS 3.0.6 (2021-05-12).

Mimochodem některé resolvery odpovědi s počtem iterací nad 50 již dnes nevalidují!

V KnotDNS predpokladam mate na mysli toto - to ale zahlasi tech vice jak 20 iteraci jen v pripade, ze to mate takto nastavene v policy na masteru. Na sekundaru to uz bohuzel ani nepipne a zonu spokojene prechroupe :-) A v roli sekundaru s temi 150 iteracemi v zone je naprosto spokojene treba i NSD, at nejsem zly jen na vase ditko :-) Command-linovy signzone v provedeni od ISC v aktualni stabilni verzi vubec nepipne, pokud mu v parametru podstrcite az 150 iteraci (pouze odmitne podepsat zonu, pokud je to cislo vetsi). Zalogovat i na sekundaru ten nesloulad NSEC3 parametru s aktualnimi standardy tezky IMHO byt nemuze, precist to je stejne "tezke" jako precist SOA. Berte to jako drobny namet na zlepseni ;-)

A jinak, kdyz uz si tak hezky povidame - doporucenim z RFC 9276 s tou nulou se z letmeho pohledu neridi krom jinych treba i nas stat a samozrejme i par registratoru :-) Ale aspon se vejdou do tech mantinelu definovanych v priloze A... je toho v souctu pomerne dost.

Takže v komentáři kritizujete nástroje na podepisováni zóny, já oponuji, že při našem podepisování takovou situaci hlásíme. Tak vy vyndáte situaci na sekundárech. Ano to (zatím?) nekontrolujeme, protože velmi často nemá provozovatel sekundárního serveru podepisování zóny ve svojí kompetenci, takže by taková hláška akorát překážela. Podstatné je řešit problém u zdroje. Ostatně k čemu taková hláška je dobrá, když někteří o problematice vědí a stejně s tím nic nedělají.

Opakuji, firma, pro kterou pracujete, figuruje na předních příčkách (v rámci .cz) s počtem dodatečných iterací 100 a více. (Při vytěžování seznamu domén v zóně těch několik desítek SHA-1 iterací navíc až takový rozdíl není, ale resolvery zbytečně zatěžujete)

V další nekonečné diskuzi už nebudu pokračovat.

Ano, treba podepisujici nastroje od ISC, kde autor clanku a vas exkolega tvori zadne podobne varovani necini. Do 150 iteraci podepise cokoliv bez mrknuti oka a nema s tim vubec zadny problem.

Udajne prekazejici hlasku jde samozrejme vypnout/zapnout konfiguracne, to take nemuze byt tezke napsat. A dodavatel sekundaru muze byt rovnez kanal pro to, aby svemu primaru rekl, ze je treba neco opravit. No, krasne tu predvadite ty vyvojarsky vymluvy, proc neco nedelat ;-)

Kdyz uz se snizujeme k ad-hominem argumentum, tak zajiste take moc dobre vite co spada do me kompetence a co uz ne. Kolegove z vyvoje to nahlasene maji. Ale vite kulove o internich systemech, co je treba kde udelat, ale cekate opravu za deset minut a rovnou mate jasno. Vase tvrzeni "nedelaji nic" ale muzu zrovnatak aplikovat i na vas - ani v Knotu nektera RFC vztazena k DNS proste neimplementuje (co treba RFC 7858 z roku 2016, ze?) - taky bych mohl rict, ze delate jen veci, na ktere mate naladu a kdyz se vam do nich chce. Aneb tady vidite, jak je to s vyvojari nekdy tezke, kdyz neco chcete nekam posunout...

Porad ale take plati, ze to je v limitech dle kapitoly 4 a i prilohy A odkazovaneho RFC 9276, ktere se oproti RFC 5155 vyrazne posunuly smerem dolu. A porad je to pod cislem, ktere bezne dovoli nastroje (nejen) od ISC. A to RFC se zmenilo celkem nedavno - jina RFC se v zivot uvadi podstatne dele, ve vasem dokonce nektera vubec, viz vyse... i po osmi letech... krasny RFCckovy cherry-picking tu predvadite ;-) A soucasne tu vyhrozujete "nekym", kdo si RFC vylozil restriktivneji a limity si vlastne posunul niz - coz je jeho pravo, ale z druhe strany take umele vytvareny problem. Ty cisla tam nejsou pro srandu kralikum...