Soukromí v DNS prakticky

31. 1. 2017 20:49 (aktualizováno) Ondrej Kolek

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: yeshide-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.

Sdílet