Soukromí v DNS a jeho nastupující bezpečnostní prvky v blízké budoucnosti. O tomto tématu bylo za poslední rok slyšet mnoho, pojďme si však ukázat, jak některé z těchto novinek nasadit v TurrisOS, případně OpenWRT s Unboundem.
Už to budou více než 2 roky co jsem začal používat DNSCrypt a více než rok co mě Ondřej Caletka upozornil na DNS-over-TLS. Tehdy jsem tomu moc nevěnoval pozornost a slepě nasadil DNSCrypt na Turris. V té době, však Frank Denis @jedisct1(vývojář dnscrypt-proxy) napsal pár reddit komentářů o tom, že DNSCrypt není toliko šifrovaným protokolem, nýbrž spíše alternativou k (v té době ještě málo rozšířenému) DNSSEC a slouží tedy pouze k autentizaci. Proč tomu tak je, si ukážeme níže. Nicméně to podnítilo mou zvědavost a začal jsem pátrat po tom, jak co nejlépe zabezpečit DNS.
Ti z vás co měli možnost vidět přednášku Ondřeje Surého, jistě už vědí kam mířím. V následujících odstavcích je nastíněno, jak si tato vylepšení vyzkoušet.
1. V první řadě jde o QName minimizaci, která byla uvedena v březnu 2016, bohužel je ve výchozím stavu Unboundu vypnuta. Její zavedení provedeme vložením následujících parametrů do konfiguračního souboru unboundu:
server: qname-minimisation: yes harden-below-nxdomain: yes
Poté otestujeme pomocí příkazu:
dig -t txt qnamemintest.internet.nl
A výsledná ANSWER sekce by měla vypadat takto:
;; ANSWER SECTION: qnamemintest.internet.nl. 10 IN CNAME a.b.qnamemin-test.internet.nl. a.b.qnamemin-test.internet.nl. 10 IN TXT "HOORAY - QNAME minimisation is enabled on your resolver :)!"
Výhodou QNAME minimizace je mimo jiné, zvýšení rychlosti a soukromí takto vyřízeného dotazu. Pro bližší informace koukněte opět na snímky prezentace Ondřeje Surého, případně do příslušného RFC.
2. Dalším novinkou je EDNS0 Padding, která v jednoduchosti umožňuje vyplnit DNS pakety proměnným počtem nulových bitů. Z takto nadstavených paketů již není jednoduché odhadnout původní délku dotazu (případně odpovědi), a tudíž odposlouchávaná, šifrovaná komunikace (např. pomocí DNSCrypt) ztrácí pro útočníka smysl.
Bohužel je tato funkce momentálně implementována pouze v Knot resolveru, takže v případě Unboundu si budeme muset ještě chvíli počkat. Pokud však máte doma Turris Omnii, neváhejte se podívat do manuálu na:
net.tls_padding([padding])
3. Následující a nejzajímavější funkcí je zabezpečené DNS-over-TLS. Na webu portal.sinodun.com je uvedeno několik rekurzivních DNS serverů, ke kterým je možné navázat šifrované spojení. Nastavíme:
forward-zone: name: "." forward-first: yes forward-addr: 185.49.141.38@853
Sám jsem přibližně týden využíval getdnsapi.net, avšak rychlost odpovědí byla občas dosti pomalá. Test správné konfigurace provedeme např. na adrese dnsleaktest.com.
Z vlastní zkušenosti mohu dále doporučit hide-identity: yes i hide-version: yes. A nakonec ještě můžeme provést obecný DNS test na grc.com, kde mimo jiné doporučují také vypnout externí ping na router. Což zvládneme jednoduchou změnou již zavedeného iptables pravidla (IPv4-ICMP echo request).
Výsledek testu z grc.com
Turris 1.x --------> ISP ----------> Internet --------> verejny DNS resolver |------------------ Zabezpeceno pomoci DNS-over-TLS --------------------| |--- Zabezpeceno pomoci DNSSEC ---| |--- Nejnachylnejsi na logovani (pasivni DNS apod.) ---|
Tímto bych zakončil toto skromné nahlédnutí pod pokličku dění kolem soukromí v DNS. Do budoucna se můžeme těšit na DNS-over-DTLS a pro ty z vás, které dané téma zaujalo, silně doporučuji prezentaci z IETF97.
A jaké zkušenosti s DNSCrypt, případně DNS-over-TLS máte vy? Plánujete do budoucna jeho nasazení? Vidíte nějaký přínos v založení otevřeného, šifrovaného, rekurzivního DNS serveru? Tedy kromě obcházení MFCR blacklistu. :)
EDIT: Děkuji Ondřeji Caletkovi za věcnou připomínku ohledně ENDS(0) paddingu. Opraveno, viz komentáře.
Díky za text. Mám jednu technickou poznámku:
Volba edns-buffer-size:
nenastavuje edns padding, ale pouze anoncovanou velikost edns0 bufferu, tedy velikost paketu, kterou je server maximálně schopen přijmout prostřednictvím UDP, bez přepínání na TCP.
Dekuji Ondreji za komentar!
Samozrejme mate pravdu a ihned to opravim. Prestoze jsem dokumentaci k Unboundu nekolikrat cetl, tohle byla hodne mylna domnenka. Taktez po kontrole nekolika zdroju, vidim, ze podporu na serverove strane ma stale a pouze Knot Resolver.
Proč vypnout ping na server? Je v tom nějaké bezpečnostní riziko?
( nerejpu, zajímá mě to)
Riziko v zapnutem "ICMP echo request" nijak prevratne rozhodne neni. Nicmene, jak uz sama kolonka v obr. vysledku napovida: It's preferable for it to be less visible. Vsechna tato nastaveni kolem DNS byla demonstrovana na domacim routeru a nikdy jsem na nej nepotreboval pingovat z prostredi internetu. Osobne preferuji pristup - zakaz vse a nasledne povol jen nezbytne sluzby/aplikace pro chod systemu.
Z pohledu utocnika, je to dalsi moznost, jak si overit, zdali na uvedene adrese bezi nejake zarizeni a az pote zacit utocit. Vice napr. na http://superuser.com/a/572187
Diky za clanek. Mam par dotazu jako noob v DNS, presto se zajimam o bezpecnost a anonymitu.
1/ mel jsem za to, ze Unbound bezi jako muj vlastni "recursive DNS server", tj az na obcasne stazeni/aktualizaci z ARPA serveru nepotrebuji DNS resolver (od ISP, googli, ..)?
2/ dnscrypt tedy nema smysl? (pokud mam nastaveno pouziti DNSSEC)
3/ co openDNS? https://blog.opendns.com/2010/02/23/opendns-dnscurve/
Zdravim,
ad 1/ Bavime-li se stale o Unboundu na Turrisu s vypnutym forwardovanim dotazu, pak mate pravdu a v tu chvili je Unbound v roli recursive DNS. V pripade zapnuteho forwardingu (viz administrace Foris), coz je mimochodem doporuceno CZ.NICem (kvuli rychlosti odezvy apod.), pote jsou DNS dotazy rekurzivne vyrizovany DNSkem ISP.
ad 2/ Dokud nebude mit Unbound implementovany EDNS0 Padding (dosud tomu tak neni, omlouvam se za chybu ve clanku), pote zde existuje moznost odhadnuti odeslanych DNS dotazu/odpovedi. DNSCrypt i DNS-over-TLS jsou sifrovaci protokoly, kdezto DNSSEC je zde pro validaci. Tedy jednotlive implementace se vzajemne doplnuji a obe budou mit stale smysl i pri nasazeni sifrovani.
ad 3/ Diky za odkaz, bohuzel o DNSCurve toho zatim moc nevim.
"ad3/ ...o DNSCurve toho zatim moc nevim.."
V tom pripade vrele doporucuju brilantne vedenou prednasku navic prokladanou vtipem od uznavaneho kryptografa jmenem Daniel Bernstein (autor napr EC25519)
High-speed high-security cryptography: encrypting and authenticating the whole Internet
https://www.youtube.com/watch?v=ljt1cxUcZMM
slides ktery tam pouziva jsou k sosnuti zde:
https://events.ccc.de/congress/2010/Fahrplan/attachments/1773_slides.pdf
Prvni polovinu venuje rozboru slabin DNSSEC protokolu a moznych scenaru jeho zneuziti k amplification DDOS utoku, potom navrhuje reseni =prave DNSCurve + novy komunikacni protokol CurveCP.
Ten jeho napad vyeliminovat CA a verejny klic webu rovnou napalit natvrdo do URL je genialni, trochu se to podoba napadu od Bruce Schneiera kde pri pouziti dostatecne dlouheho URL s dobrou entropii je mozne vyeliminovat heslo, protoze obtiznost uhodnuti hesla je srovnatelna s obtiznosti uhodnuti jedinecne URL :o)
"ad1/ ....o Unboundu na Turrisu s vypnutym forwardovanim dotazu, pak mate pravdu a v tu chvili je Unbound v roli recursive DNS. V pripade zapnuteho forwardingu (viz administrace Foris), coz je mimochodem doporuceno CZ.NICem (kvuli rychlosti odezvy apod.), pote jsou DNS dotazy rekurzivne vyrizovany DNSkem ISP."
Nevim teda jak je Unbound implementovan na Turrisu, ale duvodem proc si lid instalujou doma Unbound DNS server je prave to aby se vyhnuli "profilovani a zlovuli ci ruznym black-listum" od sveho ISP ci nejakeho chytraka po ceste. Neni mi jasne proc by forwardovani-a tim degradace Unboundu na preposilace dotazu" melo byt "doporucene reseni" a uz vubec mi neni jasne jakou vyhodu by to melo ohledne "rychlosti odezvy" pred vybudovanim VLASTNI CACHE na vlastnim LANu....?
Ja kdyz si udelam DNSbenchmark tak je vzdycky jasne nejrychlejsi muj vlastni lokalni Unbound, kdy napr. domeny ktere jsou nacachovane serviruje rychlosti 1ms az nemeritelno....
Navic Unbound ma funkci "pre-fetching" takze si klice a zaznamy SAM updatuje tesne predtim nez vyprsi TTL, cimz je cache ze ktere serviruje vzdy aktualni a OKAMZITE ready.