Je už to nějaká doba, co jsme naposledy na tomto blogu psali o novinkách v projektu Knot DNS. Proto bychom Vám rádi představili, co je nového v poslední verzi Knot DNS 2.2.0.
Bind 9: Nerušte mi moje kruhy
Ač již Česká republika nedrží primát v absolutním počtu DNSSEC podepsaných domén, tak stále je necelých 410 tisíc podepsaných domén úctyhodné číslo. S tím, jak narůstá počet zabezpečených domén, ale také vzrůstá počet poskytovatelů připojení, kteří na svých DNS resolverech ověřují DNSSEC. Je tedy normální, že se také občas přijde na nějaký implementační zádrhel. Jelikož jsme na jedno takové škobrtnutí narazili již podruhé, tak jej na následujících řádkách popíšu, společně s dobrou zprávou, že oprava je již na cestě.
Představte si docela běžnou situaci, kdy máte na DNS serveru nějaké podepsané domény, a z nenadání vám vaši zákazníci hlásí, že se v síti poskytovatele ABCXYZ, který používá na svých resolverech Bind 9, jejich (nebo vaši) uživatelé nemohou dostat na stránky. Pečlivě prozkoumáte DNSSEC a bohužel neobjevíte žádnou závadu. A ani nemůžete, protože celý problém tkví v tom, že Bind 9 obsahuje kontrolní mechanismus, který za specifických podmínek označí autoritativní DNS server jako neschopný komunikovat pomocí rozšíření EDNS0. Naneštěstí je EDNS0 nutnou podmínkou pro fungování DNSSECu a výsledkem celé této akce je, že takový resolver najednou není schopen ověřovat DNSSEC podepsané domény běžící na tomto DNS serveru.
Zrada ovšem spočívá v tom, že k nastavení příznaku není-schopen-EDNS0 stačí, aby v úplně libovolné doméně, kterou máte na serveru, někdo vytvořil úplně jednoduchou CNAME smyčku (circular CNAME).
Záznam pak bude vypadat takto:
maly.kasuar.cz. IN CNAME maly.kasuar.cz.
Pokud pak koncový uživatel položí neopravenému resolveru dotaz na maly.kasuar.cz, tak je problém na světě.
Postfix dostal podporu pro DANE protokol
Podporu pro protokol DANE již nějakou dobu můžete v prohlížeči používat pomocí rozšíření DNSSEC Validator dostupné pro prohlížeče Firefox, Chrome/Chromium a Internet Explorer. A hned na začátku tohoto roku bych rád přivítal prvního zástupce serverové aplikace s podporou protokolu DANE, jelikož 15. ledna vyšla nová stabilní verze poštovního démona Postfix, která mimo jiné přináší podporu pro protokol DANE. Autoři Postfixu se rozhodli, že pro poštovní servery, které ve valné většině používají self-signed certifikáty, nemá moc smysl podporovat duální kontrolu CA + DANE a tudíž implementace v Postfixu podporuje pouze Certifikate Usage 2 – „Vlastní kořen důvěry (CA)“ a 3 – „Vlastní self-signed certifikát“. Certificate Usage 0 – „Omezení na konkrétní CA“ a 1 „Omezení na konkrétní certifikát od CA“ se mapují na typy 2 a 3.
Pojďme si nyní rychle ukázat, jak takovou podporu na Vašem serveru zapnout.
Na straně přijímající je potřeba mít vygenerovaný certifikát a zapnuté TLS. A jelikož toto není nic nového a dokonce možná toto za Vás udělal rovnou instalační balíček Vaší distribuce, odkázal bych Vás jen na dokumentaci.
Ta zajímavější část přichází ve chvíli, kdy do DNS chceme umístit TLSA záznam, kterým dáme světu vědět, že s námi může komunikovat zabezpečeně, a náš certifikát má odpovídat tomu, který jsme vygenerovali na serveru. Na generování mohu s klidným srdcem doporučit utilitu swede, případně utilitu hash-slinger.
TLSA záznam pomocí utility swede vygenerujeme následujícím způsobem:
swede create --port 25 --protocol tcp --output rfc --usage 3 --selector 1 --mtype 1 --certificate
Vygenerovaný záznam, který bude vypadat například takto:
_25._tcp.mail.rfc1925.org. IN TLSA 3 1 1 5afe6a99c7d658a5cee951da6ebe7a21e0d7604f831248177f4283ecf639fad6
vložíte do příslušného zónového souboru a DNS server reloadnete. Pokud Váš DNS server nepodporuje TLSA záznamy, máte dvě možnosti: buď server vyměníte za nějaký modernější (např. Knot DNS) nebo místo volby --output rfc použijete volbu --output generic, která vygeneruje TLSA záznam v obecném formátu, který by měly podporovat i DNS servery bez přímé podpory pro TLSA záznamy.
Tímto jsme zapnuli podporu pro DANE protokol na straně serveru, který poštu přijímá. Jak tedy nastavit ověřování TLSA záznamů na straně odesílajícího serveru?
Předně musíte mít nainstalovaný postfix 2.11.0 a vyšší. Balíčky pro Ubuntu jsou k dispozici například v tomto PPA. Konfigurace je pak velmi jednoduchá, do konfiguračního souboru přidáte tři řádky:
postconf -e "smtp_dns_support_level = dnssec"
postconf -e "smtp_tls_security_level = dane"
postconf -e "smtp_tls_loglevel = 1"
a restartujete Postfix.
Následně se stačí podívat do mail.logu, kde by se měl objevovat pro servery s podporou DANE protokolu následující záznam:
Aug 2 10:35:49 jedi postfix/smtp[24161]: ***Verified*** TLS connection established to mail.nic.cz[217.31.204.67]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
a pro servery bez podpory:
Aug 2 10:46:54 jedi postfix/smtp[24300]: ***Untrusted*** TLS connection established to aspmx.l.google.com[2a00:1450:4001:c02::1b]:25: TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
Na závěr bych chtěl poděkovat Viktoru Dukhovnimu, za jeho práci na implementaci protokolu DANE v Postfixu a Vám popřát šťastné a veselé šifrování v novém roce :).
Ondřej Surý
Generace Y? Ne! Generace DNS!
Generace Y je termín, který používají sociologové pro populaci, která se narodila na začátku 80. let a tedy vyrůstala převážně v době, kdy už byly dostupné mnohé moderní technologie včetně Internetu. A jelikož úplně první standardy, definující protokol DNS, RFC 882 a RFC 883 vznikly v listopadu 1983, tedy akorát před třiceti lety, dala by se Generace Y s trochou nadsázky označit také termínem Generace DNS.
Ať už patříte ke Generaci X, Y nebo Z, tak v každém případě si s námi můžete tuto sobotu DNS připomenout a to na konferenci Internet a Technologie 13.2, kde mu bude patřit celý jeden blok. Kapacita v sále je už delší dobu vyčerpána, ale pokud byste měli zájem, živý přenos z akce začne přibližně v 9:20.
Ondřej Surý
Proč je opravdu zapotřebí DNSSEC?
Amir Herzberg a Haya Shulmanová z izraelské Bar Ilan University na konferenci IETF 87 v Berlíně představili novou variantu otrávení DNS pomocí fragmentace IP paketů. Kompletní prezentaci lze najít v IETF 87 Proceedings.
Doporučuji si pro osvěžení tématu znovu přečíst o útoku na DNS, který před pěti lety objevil Dan Kaminsky. Kromě použití technologie DNSSEC, která je jedinou opravdu funkční ochranou proti podvrhávání DNS odpovědí, se jako jedna z obran začaly používat náhodné zdrojové porty, které přidaly dalších ~16 bitů entropie.
Už v té době jsme ve studii (kratší shrnutí) upozorňovali, že ani větší počet náhodných bitů nezaručuje ochranu před podvržením a otrávením DNS, a s dostatečně velkým datovým tokem (~100Mbps) je možné otrávit DNS za dobu lehce překračující jeden den (~25 hodin).
Izraelští výzkumníci nyní přišli s novými variacemi útoku na DNS, které ukazují, že opravdu potřebujeme kryptograficky silné DNS a potřebujeme jej pokud možno ihned.
Hlavička IPv4 paketu vypadá takto:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Celá hlavička UDP datagramu vypadá takto:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Důležité je vědět, že v případě, že spojení mezi dvěma směrovači má nižší MTU (Maximum Transmission Unit) dojde k fragmentaci paketu na několik částí, které jsou identifikovány stejným číslem v poli Identification (dále IP-ID). Fragmentovaný provoz může vypadat například takto:
14:56:02.608188 IP (tos 0x0, ttl 64, id 47557, offset 0, flags [+], proto ICMP (1), length 1500)
217.31.204.249 > 12.22.58.30: ICMP echo request, id 22368, seq 1, length 1480
14:56:02.608193 IP (tos 0x0, ttl 64, id 47557, offset 1480, flags [none], proto ICMP (1), length 48)
217.31.204.249 > 12.22.58.30: ip-proto-1
14:56:02.797078 IP (tos 0x0, ttl 60, id 61513, offset 0, flags [none], proto ICMP (1), length 1528)
12.22.58.30 > 217.31.204.249: ICMP echo reply, id 22368, seq 1, length 1508
Jak lze vidět, tak odchozí ICMP zpráva typu echo request (tj. ping) byla rozdělena na dvě části s IP-ID = 47557 a rozdílnými offsety. Fragmentované části paketu pak budou v cíli spojeny do jednoho a aplikace, která přenesenou zprávu zpracovává, ji dostane v jednom bloku. A protože k defragmentaci paketů dochází až v cílové destinaci a směrovače fragmentované pakety nijak speciálně nesledují, tak je možné, že každá část fragmentovaného paketu dorazí k cíli například jinou cestou nebo v jiném pořadí, než byly fragmenty odeslány.
Toto skládání částí paketu mimo pořadí nahrává útočníkovi. Pokud ví, jaké je po cestě MTU, což nemusí být tak složité zjistit, tak může začít podvrhovat následné (tedy druhé a vyšší) části paketů. Takto podvrhnuté fragmenty můžou mít dvojí efekt – jednak je možné do druhé části paketu vložit vlastní obsah a jednak v případě rozdílné udané velikosti celého paketu je možné donutit operační systém, který je zodpovědný za defragmentaci paketu, aby (pro útočníka) nežádoucí pakety zahazoval (tj. taková trochu chytřejší varianta DDoS útoku).
Další (a poslední) část fragmentační skládačky spočívá v tom, že existuje ICMP zpráva typu fragmentation needed, kterou si počítače na cestě domlouvají maximální velikost paketu, kterou dokážou přenést. V případě IPv4 je minimální velikost MTU 68, v případě IPv6 je to 1280. Bohužel tuto zprávu lze celkem dobře podvrhnout a cílový server donutit snížit MTU na hodnotu, která je pro útočníka výhodná. Tato nová hodnota je v operačních systémech držena v dočasné paměti až několik minut.
Jaké to tedy má důsledky pro DNS? Na to se musíme podívat do hlavičky DNS zprávy:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Již jsme si řekli, že ochranu proti spoofingu nám zajišťuje ID v hlavičce zprávy (16 bit) společně se zdrojovým portem v UDP zprávě (16 bit).
Když se ale podíváme zpátky pouze na IP vrstvu, tak zjistíte, že obě informace (DNS-ID i source port) jsou vždy uloženy pouze v prvním IP fragmentu, tudíž útočníkovi stačí podvrhnout druhou část paketu, kterou nahradí vlastním obsahem. Při podvrhávání potřebuje útočník uhádnout jenom správné IP-ID, aby se podvržený fragment spojil se začátkem platné odpovědi. Kromě toho, že hádání 16-bitového IP-ID je velmi jednoduché provést pouhou hrubou silou, tak celou situaci ještě zjednodušuje fakt, že hodnoty IP-ID se většinou negenerují úplně náhodně. Na některých operačních systémech existuje globální counter IP-ID, takže hodnotu aktuálního IP-ID systém vyzrazuje s každým odeslaným paketem (a útočník tedy přibližně ví, do jakého rozsahu se má trefovat). Pokud cíl útoku běží na Linuxu, tak je to pro útočníka naštěstí trochu složitější, protože pro každou cílovou adresu má Linuxové jádro zvláštní IP-ID counter, ale i toho však lze bohužel zneužít.
Poslední komplikace, kterou útočník musí vyřešit, je kontrolní součet v UDP hlavičce. Nicméně ani to není velký problém, protože jednak útočník ví, jak bude odpověď DNS serveru vypadat, protože se sám může zeptat, a v DNS paketu je vetšinou dost místa na to, aby kromě falešné odpovědi do DNS paketu ještě nacpal další data, kterými 16-bitový kontrolní součet nastaví na požadovanou hodnotu.
Poslední zefektivnění útoku probíhá opět již na IP vrstvě a závisí na implementaci IP stacku v jednotlivých operačních systémech, nicméně je možné říci, že ve většině případů je možné tuto optimalizaci dost efektivně využít. Již jsme si výše řekli, že fragmentované pakety mohou přijít mimo pořadí, a protože je UDP nespojovaný protokol a zároveň vrstva, která dělá defragmentaci v IP stacku nemá moc ponětí o vrstvách vyšších, je možné podvržené druhé fragmenty poslat dopředu na náš cíl útoku a ony se uloží do vyrovnávací paměti operačního systému. Teprve po tomto „nahrání“ druhých fragmentů útočník vyvolá Kaminsky-style dotaz, a odpověď, kterou cílová aplikace dostane, bude složena z přednahraného části a prvního fragmentu správné odpovědi.
Celý koncept útoku dále v Laboratořích CZ.NIC zkoumáme, a mimo jiné bychom rádi v rámci ověření efektivity takového útoku vyrobili funkční PoC (Proof of Concept) implementaci celého útoku. O tom, zda-li jsme uspěli, Vás budeme dále informovat.
Na závěr bych rád řekl jednu špatnou a jednu dobrou zprávu. Ta špatná zpráva je, že v současné době není proti tomuto útoku známa žádná jiná efektivní obrana než nasazení DNSSECu. Ta dobrá zpráva je, že pokud máte doménu .CZ, tak máte skoro 40% šanci, že Vás DNSSEC chrání. Jestli chcete vědět, jak s DNSSEC pracovat, přijďte do naší akademie. Kurz se jmenuje více než prozaicky – DNSSEC – zabezpečení DNS.
Ondřej Surý
Smějeme se s DNS
Možná by se mohlo zdát, že svět kolem DNS je suchý a plný pouze jedniček a nul. Naštěstí i DNS komunita má svůj specifický humor a cílem tohoto krátkého příspěvku je upozornit na dva zdroje vtipů spojených s DNS.
První studnice humoru je účet @DNS_BORAT na Twitteru; za velký úspěch považujeme to, že se Knot DNS dostal i do hledáčku DNS_Borata:
Was been wonderful day compare djbdns source code with Knot core dumps; very little differences
— DNS Borat (@DNS_BORAT) July 10, 2013
Mimochodem *_Borat účtů je více: @DEVOPS_BORAT, @Sysadm_Borat nebo @X509_Borat.
Další výborný (obrázkový) blog je DNS Reactions, kde (také neznámý) autor z DNS komunity komentuje DNS pomocí animovaných gifů.
I zde jsme se zjevně stali již součástí popkultury – resp. ten fakt, že ve sdružení pracuje příliš mnoho Ondřejů a velmi často se stává, že si nás cizinci pletou (někdy dostávám pozvánky na schůzky za pět minut, které jsou na druhé straně zeměkoule).
Autor blogu to okomentoval v příspěvku Asking for „Ondrej“ in CZ.NIC, který doplnil tímto obrázkem:
Nakonec bych opět upozornil na sesterský blog DevOps reactions ze života adminů a programátorů.
Ondřej Surý
Ochrana obětí před DNS amplification útoky
Posledních pár měsíců jsme byli svědky DNS útoků, které k amplifikaci používaly ANY dotazy na autoritativní servery s dostatečnou kapacitou. Jako reakce na tento druh útoků přišla DNS komunita s technikou Response Rate Limiting, takže kromě rate-limiting pravidel ve firewallu můžete dnes najít podporu RRL ve všech důležitých autoritativních serverech: BIND 9 (ve formě patche), NSD (od verze 3.2.15) a Knot DNS (od verze 1.2.0-rc3). Knot DNS navíc od verze 1.1.0 podporuje blokování dotazů na ANY; v případě, že DNS server dostane DNS dotaz na typ ANY, vrátí se pouze malá odpověď s nastaveným truncate (TC) bitem, která resolveru říká, že se má zeptat znovu přes TCP. Velcí operátoři DNS serverů tedy zareagovali poměrně rychle a nasadili buď novější nebo opatchované verze DNS serverů, nebo případně pravidla ve firewallech.
Dnes se zdá, že sezóna útoků založených na ANY dotazech je za námi a útočníci se v případě masivního DDoS útoku na Spamhaus vrátili k osvědčené technice zneužívání otevřených resolverů a TXT záznamů.
Důležité je zdůraznit, že jediná spolehlivá ochrana proti těmto útokům je buď omezení přístupu na otevřené resolvery pouze ze sítě, kde mají být dostupné, nebo v případě, že je takový resolver otevřený cíleně, tak přísný rate-limiting, který neomezí legitimní uživatele, ale útočníkům znemožní využívat DNS amplifikaci ve velké míře. Osobně se ovšem domnívám, že případů, kdy je otevřený resolver opravdu zapotřebí, by se dalo napočítat na prstech jedné ruky.
Pokud se budeme bavit o ochraně na trochu vyšší úrovni, tak finálním cílem bude donutit (nejlépe všechny) operátory k ingress filteringu (tedy BCP38), který by zabránil možnosti masově podvrhávat zdrojové IP adresy. Zde by byla zapotřebí spolupráce všech operátorů, aby při uzavírání smluv se zákazníky toto filtrování vyžadovali a vynucovali. Bude to ze začátku bolestivé, ale domnívám se, že se pomalu blížíme do situace, kdy liberální přístup nepomáhá vůbec nikomu kromě útočníků.
A protože lov na všechny otevřené resolvery, což si například klade za cíl Open DNS Resolver Project, je běh na dlouhou trať (skeptik by dodal, že je to spíše boj s větrnými mlýny), tak si pojďme rychle ukázat, jak se dá pomoci obětem DNS DDoS útoků pokud máte v síti otevřené resolvery zapojené do útoku.
Samozřejmě nejjednodušší řešení je na odchozím firewallu nastavit blokování veškerého UDP provozu na IP adresy cíle. Ale to bychom tak říkajíc s vaničkou vylili i dítě a zaDoSovali cílový server ještě lépe než útočník, protože na postižené DNS servery občas také chodí legitimní dotazy, které je zapotřebí zodpovědět.
Pro blokování pouze takových DNS zpráv, které jsou součástí útoku, se dá využít jednoduchý příznak dotazy (QUERY) v hlavičce DNS zprávy. Legitimní DNS zprávy od klientů, které opravdu zajímá odpověď a nejsou jen součástí útoku, budou mít tento příznak nastavený na 0. Odražené DNS zprávy budou mít tento příznak nastavený na 1, což znamená odpověď. Na firewallu pak můžeme jednoduše spárovat cílovou IP adresu s tímto příznakem v DNS zprávě (v iptables například pomocí modulu u32), a odražené DNS zprávy blokovat.
Pomocí iptables bude tedy konfigurace na firewallu vypadat nějak takto:
iptables -A FORWARD -s <vase_sit/maska> -d <victim_ip>
-p udp --sport 53 \! -f
-m u32 --u32 "0>>22&0x3C@8>>15&0x01=1" -j LOGDROP
Toto pravidlo loguje a blokuje (v případě, že máte nadefinovaný chain LOGDROP) všechny UDP odpovědi na portu 53 (-p udp --dport 53), které nejsou fragmentované (\! -f) a na nejvyšší pozici dvou bajtu DNS hlavičky je nastavená 1. (Mimochodem se zdá, že v příkladu z manuálu netfilteru, který jsem použil je chyba, a autora příkladu zmátlo to, že DNS dotaz je specifikován bitem QR=0.)
Pokud jste si jistí, že síť, kterou firewallujete nemá obsahovat žádné DNS servery, které by měly dávat odpovědi ven, tak můžete vyhodit část pravidlo s ‚-d
V případě jiných firewallů je zapotřebí se začíst do dokumentace, v komentářích pak uvítám, pokud se podělíte s tím, jak dosáhnout podobné kontroly v BSD ipf, na Ciscu nebo Juniperu.
Ondřej Surý
DNSSEC validace na Google Public DNS. Jak to vlastně je?
Když před dvěma dny Google ohlásil, že na svém veřejném DNS podporuje DNSSEC validaci, tak mnohá srdce zaplesala. O to pak bylo větší zklamání, když se ukázalo, že tato služba v současné době validuje pouze na vyžádání. DNSSEC validace na vyžádání pak v podání Google Public DNS validuje DNSSEC pouze v případě, že byl dotaz zaslán s příznakem DO (DNSSEC OK) nebo AD (Authenticated Data).
Co to tedy přesně znamená, a proč je to vlastně jeden velký test?
První důvod je velmi jednoduchý. Takové chování je v rozporu se standardem RFC, které definuje chování validujícího resolveru (RFC 4033). Dle DNSSEC standardu tedy nelze nazývat Google Public DNS jako validující resolvery. Možná si řeknete, že nějaké dodržování standardů není důležité, ale pak si zkuste vzpomenout, jak jsme dopadli s prohlížeči a HTML, a jak dlouho se z toho už dostáváme.
Druhý důvod je techničtější a poněkud více komplikovaný. Aby systém používající Google Public DNS mohl využívat všechny výhody validace, musel by stub resolver v systémové knihovně podporovat zasílání DNS dotazů s příznakem DO nebo AD. Přiznám se, že jsem žádný takový stub resolver ještě neviděl. Druhá varianta je pak instalace lokálního resolveru, který takové dotazy posílat již umí. Jenže pak už asi neexistuje žádný rozumný důvod, proč nedělat validaci přímo na tomto resolveru, protože tím dosáhnete výrazného zvýšení bezpečnosti DNS ve vaší síti.
Naštěstí to není tak černé, jak to vypadá. Google po počáteční smršti jednak aktualizoval FAQ a jednak Ben Laurie z Google ohlásil, že toto je pouze počáteční testovací fáze, po které bude následovat zapnutí DNSSEC validace pro všechny uživatele této služby.
Takže i přes počáteční nevoli dávám Google palec nahoru za odvážný krok správným směrem. A teď už jenom potichu, ale třeba i nahlas, doufejme, aby také udělali krok na druhé straně a postupně začali podepisovat své domény. V České republice nás to tolik netrápí, protože co se týče validace i podepisování patříme mezi špičku, ale oba dva budoucí kroky na straně Google mají hlavně na mezinárodní úrovni velkou šanci rozseknout vejco-slepičí problém, kdy nikdo nevaliduje, protože nikdo nepodepisuje, a nikdo nepodepisuje, protože nikdo nevaliduje.
Ondřej Surý
Závažná vzdálená zranitelnost v DNS serveru NSD
Kolegové z vývojového týmu Knot DNS se kromě vývoje také velmi pečlivě věnují testování, kterým se snažíme odhalit jednak chyby v samotném kódu našeho serveru, ale také odchylky od „standardu“ s důrazem na interoperabilitu jednotlivých serverů. Píši „standard“ DNS s uvozovkami, jelikož se jedná o souhrn dokumentů, které jsou někdy velmi nejasné, a jejich výklad záleží spíš na dohodě celého DNS ekosystému.
V rámci tohoto testování kolegové z Laboratoří CZ.NIC připravují také sadu DNS dotazů, které jsou nestandardní a zjišťují chování vybraných open-source DNS serverů (Bind 9, NSD 3,…). Jeden z uměle vytvořených testů, které připravili mí kolegové Marek Vavruša a Ľuboš Slovák, za TSIG podpis DNS zprávy připojoval další prázdný RR záznam (konkrétně prázdný TXT záznam). Při testování se ukázalo, že NSD ve všech verzích 3.x (i vývojové verzi 4.x) obsahuje zranitelnost, která je zneužitelná pro pád DNS serveru z libovolného místa v Internetu. Při přijmutí takové DNS zprávy dojde k dereferenci NULL pointru a NSD spadne s chybou SIGSEGV.
Tento problém jsme kolegům z NLnet Labs nahlásili v pondělí krátce po poledni a hned další den ráno jsme měli v poště opravný patch, který přikládám na konec tohoto blogpostu. V době vydání tohoto blogpostu by také na stránkách NSD měla být k dispozici verze 3.2.12, která tento bezpečnostní problém opravuje.
Jelikož se jedná o vzdálenou zranitelnost, na kterou neexistuje žádný workaround, důrazně doporučujeme v případě, že používáte NSD 3, okamžitě záplatovat vaše DNS servery.
Patch:
--- query.c (revision 3609)
+++ query.c (working copy)
@@ -1379,6 +1379,9 @@
edns = &nsd->edns_ipv6;
}
#endif
+ if (RCODE(q->packet) == RCODE_FORMAT) {
+ return;
+ }
switch (q->edns.status) {
case EDNS_NOT_PRESENT:
break;
Ondřej Surý
„Autonomní“ Internet alá Čína
O tom, že Internet jako otevřená platforma, která překračuje prostor i čas, se úplně nepotkává s oficiální politikou autoritativních režimů (a nejen jich), netřeba dlouze diskutovat. O velkém čínském firewallu, blokování Twitteru v čase íránské zelené revoluce, vypnutí Internetu v Egyptě po protestech po volbách v roce 2011 a dalších toho bylo napsáno dost mimo náš blog, ale vždy se jedná či jednalo o jednotlivosti, které z technického pohledu narušují normální chování sítě.
Internetový draft DNS Extension for Autonomous Internet(AIP), který jako individuální podání poslali do IETF pánové Diao, Diao a Liao, ovšem tento systém „výpadků“ chce změnit. Nový návrh by počítal s tím, že by vedle stávajícího DNS stromu „zasadili“ další „autonomní“ DNS strom (či stromy), který by dle zvážení jeho správce obsahoval pouze některé top-level domény. Takových nezávislých stromů by mohlo být v Internetu více a přístup mezi nimi by byl zajištěn pomocí translačních bodů, které by odpovídaly dotazy ležící v uměle vytvořeném podstromu. Na stránky CZ.NIC by se z takové země pak dalo přistupovat jen pouze dotazem například na „www.nic.cz.资本主义的怪物“. Takový dotaz by byl předán příslušnému (pravděpodobně vládnímu) DNS serveru obsluhující doménu .资本主义的怪物, který by z dotazu odstranil příponu, předal jej například do DNS stromu, který je spravovaný ICANNem, a zpátky přeposlal odpověď (nebo také ne).
Osobně vnímám takovou iniciativu za velmi škodlivou otevřenému Internetu a domnívám se, že by IETF v žádném případě nemělo legitimizovat cenzuru tohoto druhu a zasadíme se o to, aby tento návrh v IETF neprošel.
Ondřej Surý