DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS

14.1.2012 20:15 | Přečteno: 1415× | programování |

Trochu jsem se začal vrtat v tunelování DNSSEC dotazů přes Tor, když jeden uživatel DNSSEC Validatoru zmínil, že při použití s Torem Validator leakuje DNS (což je známé). Po vyzkoušení několika validovacích a tunelovacích metod jsem vybral jednu dostatečne funkční. Nicméně pořád je trocha problém s Firefoxem, protože DNS překlad samotný nelze udělat přes SOCKS5 a Firefox tudíž leakuje DNS requesty mimo Tor. Aneb jak udělat DNS resolving ještě pomalejší.

ttdnsd

Pro tunelování DNS přes Tor byl původně založen projekt ttdnsd. Jacob Appelbaum udržoval projekt asi do srpna 2011. Přibyly i experimentální patche pro podporu DNSSEC. Soudě podle některých mailinglistů se ukázalo, že použití unbound-u s tunelováním je mnohem robustnější řešení než psaní nového resolveru from-scratch.

Já jsem taky zkoušel ttdnsd jako tunelovátko, na které bych směroval unbound, který by prováděl validaci. Nicméně unbound nemá rád ttdnsd, zahazoval mnoho paketů jako chybných. Iterováním přes jiné tunelovátka jsem narazil na socat, který funguje asi nejlépe. ttdnsd je pořád používán třeba v Tails live CD distribuci (na druhé straně bez validace je rychlejší než tunelovaný unbound).

Mimochodem, Appelbaum je fakt krutopřísný megahustý badass^TM, pokud jste ještě neviděli jeho a Dingledinovu přednášku How governments have tried to block Tor, tak doporučuji podívat se hned. Asi nejlepší talk z 28c3 (i jiné jeho přednášky jsou vynikající) a rozhodně jedna z nejlépe strávených hodin v životě. BTW jak mluví o čínskych automatických scannerech Tor bridgů, momentálně někdo přišel na to, že stačí počkat 10 sec a čínsky scanner timeoutuje (ale to odbíháme, je to dlouhá hra na kočku a myš).

FAQ - DNSSEC over Tor

Q: Is it slow?
A: Yes, very slow.

Pokud vás napadne nějaká optimalizace na zrychlení round-tripu, neváhejte se podělit. Nejvíce asi zdržuje neustálé navazování TCP spojení pro každou část dotazu pro validaci jednoho záznamu, ale nevím zda to jde nějak ohackovat. Rychlost závisí od nacachovaných položek a kudy vede tunel. Při testech se pohybovala mezi 3-15 sekund.

Řetězení DNSSEC dotazů přes Tor

Nainstalujeme unbound a socat. Nainstalování z balíčkovacího systému distribuce je asi nejjednodušší způsob. V tomto HOWTO předpokládáme, že Tor SOCKS proxy běží na localhostu, port 9050 (defaultní nastavení). Pro testování budeme ještě potřebovat nástroj "dig", obyčejně se nachází v balíčku s názvem "bind-tools", "bind-utils" nebo "dns-utils".

Nalezení validujícího rekurzivního resolveru naslouchajícího na TCP

Budeme potřebovat IPv4 adresu validujícího rekurzivního resolveru, kam se budou tunelovat dotazy přes Tor. Pokud žádný neznáte, lze použít jeden z následujících:

• 217.31.204.130 (CZ.NIC)
• 149.20.64.20 (DNS-OARC)
• 8.8.8.8 (Google; nicméně při jednom testu jsem narazil na to, že nevaliduje, možná že dočasná miskonfigurace)

Otestujeme, jestli resolver validuje a jestli odpoví přes TCP (vložte IP adresu resolveru za znak @):

dig +tcp +dnssec labs.nic.cz @217.31.204.130  | grep -C 1 ';; flags'

Výstup příkazu by měl vypadat podobně jako následující řádky. Důležitá část je status noerror, 'ad' flag ve flags a nenulový počet odpovědí (answers):

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35707
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 13

Tunelujeme DNS socat-em přes Tor

Socat zavoláme příkazem (adresa za 'SOCKS4A:localhost:' je adresa cílového resolveru, kam se bude tunelovat):

socat TCP4-LISTEN:5353,bind=localhost,reuseaddr,fork SOCKS4A:localhost:217.31.204.130:53,socksport=9050

Otestujeme tunel (několik sekund to potrvá), ověříme odpověď (opět status, ad flag, atd. jako předtím):

dig -p 5353 +tcp +dnssec labs.nic.cz @localhost

Konfigurace unbound

Nejprve vyzkoušíme, jestli unbound funguje a validuje. Spustíme unbound a zeptáme se ho:

/etc/init.d/unbound start
dig +dnssec labs.nic.cz @localhost

Ověříme výstup příkazu "dig". Jestli chybí 'ad' flag, bude nutné nastavit trust anchor. Teď řekneme unboundu, aby se dotazoval přes socat proxy přidáním následujících řádků do /etc/unbound/unbound.conf:

#tcp-upstream půjde pod "server:" sekci
    tcp-upstream: yes

#direktivu "forward-zone" umístíme někam na konec souboru
forward-zone:
    name: "."
    forward-addr: 0.0.0.0@5353

Adresu "0.0.0.0" dáváme unboundu, protože "127.0.0.1" by ignoroval. Restartujeme unbound a podíváme se, jestli funguje (bude to ještě pomalejší a může timeoutovat, takže uděláme vícero pokusů):

/etc/init.d/unbound restart
dig +dnssec labs.nic.cz @localhost

Ladění nástrojů unbound a socat

Když něco selže, můžeme se podívat na unbound a socat v debug módu. Socat přidáním jednoho nebo dvou "-d" optionů začne vypisovat více ladících informací. Unbound lze spustit s unbound -d místo /etc/init.d/unbound start. V konfiguraci unboundu jsou parametry verbosity a logfile. Před spuštěním debug módu nastavíme verbosity: 5 a logfile: "" abychom detailně viděli na standardním chybovém výstupu, co dělá unbound. Unbound má taky utilitu unbound-checkconf, která se podívá, jestli nejsou v configu chyby.

DNSSEC Validator add-on přes Tor

Bohužel i když Firefoxímu doplňku DNSSEC Validator nastavíte "torifikovaný" unbound jako resolver kam se má dotazovat, pořád posílá některé dotazy mimo Tor. Důvodem je Firefoxí kompomenta @mozilla.org/network/dns-service;1, která se vždy dotazuje přes resolver nastaven v systému. Validator vyžaduje dns-service aby zjistil jestli Firefox vidí stejné IP adresy jako ty v podepsané a validované odpovědi (jinak znalost, že doména je podepsána, není příliš užitečná).

Problém je pokud vím v tom, že SOCKS5 sice umožňuje uvést FQDN stroje kam se připojit, nemá ale příkaz pro "obyčejný DNS resolving". Zaručeně funkční řešení je nastavit torifikovaný unbound v /etc/resolv.conf, ale to může taky být overkill (pak naopak je vhodné v about:config nastavit network.proxy.socks_remote_dns na false, aby se použil torifikovaný unbound místo SOCKS resolvingu na straně exit nodu). Druhá možnost je nějaký hack s LD_PRELOAD (protože Firefoxu nelze nastavi DNS resolver), nebo dopsat resolving přes ldns nebo libunbound.

I když musíte věřit exit nodu, že vás připojí na vámi specifikovanou IP/hostname, pořád by ověření IP adresy viděné exit nodem pomohlo proti externím útokům. Jiným řešením by bylo unbound bundlovat s Tor-em, unbound byl by dostupný na exit-enclave, ale je to další věc na udržování (plus unbound by se musel přidat do Tor Browser Bundle).

Navíc některé sítě zahazují DNS extensions - buď vinou zmateného resolveru nebo záměrného firewallu. (Druhou variantu jsem viděl na jedné síti v Itálii; kromě DNS byl filtrován provoz kromě portů 80 a 443, ale s DPI, takže SSH na portu 443 neprošlo. Blokovány byly i OCSP requesty, takže kdo měl nastaven vyžadování OCSP, nedostal se ani na HTTPS stránku captive portalu, kde měl zadat username/pass. První přednášku všichni nastavovali tunely. Praktické cvičení pro security konferenci.)

Druhá věc je, že unbound žere taky trocha paměti, na slabších VPS to s Torem a jinými službami už může být znát. Zde je výhoda pokud poskytovatel VPS provozuje validující resolver (naštěstí případ mého bridge).

Napadá vás ješte nějaký jiný zkousnutelný workaround/hack pro Firefoxí dns-service?

       

Komentáře

[Mrkva]

Hmm, DNS leaky nejen z Firefoxu, ono ve výsledku to pak může leaknout třeba Flash (i když ten už jsem odinstaloval) nebo Java řeším:

iptables -A OUTPUT -m owner --uid-owner 1002 -j toronly_out
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 6668 -j ACCEPT
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 4444 -j ACCEPT
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 6010:6020 -j ACCEPT
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 8118 -j ACCEPT
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 9050 -j ACCEPT
iptables -A toronly_out -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A toronly_out -j REJECT --reject-with icmp-port-unreachable

[limit_false]

Jj, binární pluginy můžou dělat co chtějí. Byl jsem alespoň příjemně překvapen, že poslední verze Flashe použijou SOCKS proxy nastavenou ve FF.

Jinak, máš nastaveno v about:config "network.proxy.socks_remote_dns" na true? Ono je to by default false, tudíž i FF by default leakuje DNS. Kromě firewallu lze ještě použít Torsocks, ten via LD_PRELOAD blokuje např. UDP úplně (ale momentálně to mají mírně rozbitý).

V Tor Browser Bundle (TBB) to vyhackovali až na level že se vůbec nespustí plugin-container. Tím pádem nepoběží žádné pluginy ani addony s binárními komponenty. Ani když to člověk povolí v nastavení TorButtonu.

TBB má jednou velmi speciální vlastnost: všichni uživatelé TBB vypadají "téměř stejně". Nelze pak profilovat podle UA, screen resolution, fontů a podobných informací. Což je velmi dobrý důvod proč používat specificky TBB a nedělat to "po staru".

Vůbec build skripty pro TBB s úpravou nastavení jsou celkem zajímavé, ale neměl jsem čas se na ně podívat podrobně: git://git.torproject.org/torbrowser.git

[Mrkva]

Jinak, máš nastaveno v about:config "network.proxy.socks_remote_dns" na true? Ono je to by default false, tudíž i FF by default leakuje DNS.

Nemám, ale stejně to resolvuje (podle mě FF zjistí že neroslvne protože to firewall rejectne, tak to pošle přes proxy).

TBB má jednou velmi speciální vlastnost: všichni uživatelé TBB vypadají "téměř stejně". Nelze pak profilovat podle UA, screen resolution, fontů a podobných informací. Což je velmi dobrý důvod proč používat specificky TBB a nedělat to "po staru".

Jo, to jo, já se snažil nastavit co nejvíc nenápadně podle tohohle a taky to není tak zlý.

A k tomu omezení - osobně bych se (i přes použití TBB) vážně přimlouval za použití firewallu, přece jen se dá pouštět víceméně cokoliv bez obav. OK, vím o tom, že by si aplikace mohla získat nějaký obraz o počítači (použitý HW, systém, fingerprinty pár konfiguráků) a pak to klidně přes TOR poslat do světa. Ale fakt je, že kdybych dělal něco co by někomu stálo za to na mě nasazovat takovéhle prostředky, budu mít na tuhle "tajnou" práci separátní počítač se separátní a maximálně anonymní konektivitou.

[limit_false]

Podle Panopticlicku nejspíš nastavili v TBB ty UA parametry apod. Podobně se teď válčí o to, jak udělat Tor-ové certifikáty a TLS handshake, aby vypadaly "normálně". Viz proposal 179.

Původně jsem chtěl navrhnout nějaké zlepšení na prop 179, ale všechny trumfy se nesmí vysypat naráz. Prop 179 vypadá jako dost dobrý následující krok. Obdobně jako v případe fingerprintingu UA a Panopticlicku se pro certifikáty a handshake používá SSL Observatory jako referenční bod. (A když jsem si už nakódil vlastní observatoř skenující denně "ty SSL internety" a strávil hrabáním se ve výsledích dni a hodiny, tak aby se to i využilo!)

Firewall věci nepokazí (modulo v článku zmíněný italský operátor, pořád se úspěšně protunelovali všichni, nad některými metodami jsem kroutil hlavou ), ale je to zacpávání cedníku. Mnohem lepší přístup je nepovolit náhodný binární kód pluginů (nelze je efektivně ohlídat ani sandboxovat). Je mnohem jednodušší ukázat, že browser s implementací javascriptu může todle a tamto (i vrátaně potenciálních chyb), než chytat kam všude může sahat binární plugin. Takový "model-checking light", ale funguje.

Zajímavou přednášku týkající se klasifikace softwarových děr z hlediska vyčíslitelnosti/lingvistiky měla na 28c3 Meredith Patterson: The science of insecurity. Je to mírně "sušší" - teoretická informatika - minutové shrnutí začíná o 3:30.

Nejdůležitější tvrzení přednášky je: navrhujte protoly, aby byly rozeznatelné deterministickým zásobníkovým automatem. Tím pádem vás nerozháže halting problem. S gramatikou protokolu je pak jednoduché zjistit, jestli je správa formována správně nebo nikoli. To ovšem znamená konec "length-fields".

Nicméně existují části protokolů, které to splňují, a pořád tam programátoři dělají chyby. Příklad: OID encoding v X.509 ASN.1 BER a Kaminskeho 0x80 bug. Ale je pravda, že kdyby byl k protokolu vydána gramatika v nějakém rozumném formátu (př. bison), šlo by to zmrvit mnohem hůře.

[Jendа]

(A když jsem si už nakódil vlastní observatoř skenující denně "ty SSL internety" a strávil hrabáním se ve výsledích dni a hodiny, tak aby se to i využilo!)

Hele, když už skenuješ SSL, nechtěl bys tahat i SSH fingerprinty? Podle těch pár sítí, co jsem zatím zkusil oťuknout, by to mohla být docela sranda.

[limit_false]

Zdá se mi, že to už nekdo dělal, ale teď to neumím vygooglit.

Pro scanování SSH bych potřeboval dalšího stroj (nebo alespoň IP z úplně jiného /24 rozsahu), aby pak blokování na straně scanovaných strojů kvůli SSH scanu neblokovalo SSL scan. Taky bych asi musel řešit více abuse complaintů než při SSL scanu.

Jinak kód pro scanování SSH je téměř kompletní, v threaded_scanner.py se musí jenom vyměnit jeden řádek v ScanThreadu, v StorageThread pak ukládání (git://git.nic.cz/perspectives-observatory). SSH scanovací kód jsem zmazal, ale je v historii.

[petr_p]

Nerozumím, proč vyžadujete validující rekurzivní server a vzápětí nabízíte cizí servery. K čemu je dobrý příznak validity v odpovědi apriori nedůvěryhodné třetí strany.

[limit_false]

Rekurzivní: unbound vyžaduje rekurzivní server při upstreamingu

Validující: je to hlavně kvůli testování tunelu. Skutečnou validaci dělá unbound, abychom se v "ostrém" provozu nespoléhali na 'ad' flag co přijde z tunelu (proto je unbound na konci řetězu). Přesnější by bylo požadovat resolver, který není "DNSSEC-oblivious" (pak může být ladění složitější).

Cizí: Tor nepomůže, pokud se budete ptát vlastního resolveru a budete jeden z mála dotazujících klientů (odposloucháním na straně serveru by bylo snadné zjistit kdo se na co ptá).