abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 23:33 | Nová verze

    Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.

    Ladislav Hagara | Komentářů: 0
    dnes 22:33 | IT novinky

    Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový

    … více »
    Ladislav Hagara | Komentářů: 0
    dnes 12:11 | Nová verze

    Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.

    Ladislav Hagara | Komentářů: 0
    dnes 05:22 | Nová verze

    Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.

    Ladislav Hagara | Komentářů: 0
    dnes 02:22 | Komunita

    Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.

    Ladislav Hagara | Komentářů: 4
    včera 20:11 | Nová verze

    Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.

    Ladislav Hagara | Komentářů: 0
    včera 16:11 | Nová verze

    Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.

    Ladislav Hagara | Komentářů: 3
    včera 16:00 | IT novinky

    Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.

    … více »
    Ladislav Hagara | Komentářů: 3
    včera 12:55 | Nová verze

    Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.

    Ladislav Hagara | Komentářů: 3
    včera 03:22 | IT novinky

    Společnost OpenAI představila text-to-video AI model Sora 2 pro generování realistických videí z textového popisu. Přesnější, realističtější a lépe ovladatelný než předchozí modely. Nabízí také synchronizované dialogy a zvukové efekty.

    Ladislav Hagara | Komentářů: 4
    Jaké řešení používáte k vývoji / práci?
     (41%)
     (47%)
     (15%)
     (16%)
     (18%)
     (14%)
     (17%)
     (14%)
     (14%)
    Celkem 158 hlasů
     Komentářů: 9, poslední 24.9. 17:28
    Rozcestník

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

    14.1.2012 20:15 | Přečteno: 1363× | programování | Výběrový blog

    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ý badassTM, 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:

    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?

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    14.1.2012 22:21 Mrkva | skóre: 22 | blog: urandom
    Rozbalit Rozbalit vše Re: DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS
    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
    
    We lived, we danced, we raced, we run, from the oblivion to come, Dressed for the last dance of a hundred thousand suns.
    limit_false avatar 15.1.2012 01:33 limit_false | skóre: 23 | blog: limit_false
    Rozbalit Rozbalit vše Re: DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS
    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
    When people want prime order group, give them prime order group.
    15.1.2012 01:52 Mrkva | skóre: 22 | blog: urandom
    Rozbalit Rozbalit vše Re: DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS
    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.
    We lived, we danced, we raced, we run, from the oblivion to come, Dressed for the last dance of a hundred thousand suns.
    limit_false avatar 15.1.2012 03:08 limit_false | skóre: 23 | blog: limit_false
    Rozbalit Rozbalit vše Re: DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS
    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.
    When people want prime order group, give them prime order group.
    Jendа avatar 15.1.2012 05:19 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS
    (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 avatar 15.1.2012 16:43 limit_false | skóre: 23 | blog: limit_false
    Rozbalit Rozbalit vše Re: DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS
    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.
    When people want prime order group, give them prime order group.
    15.1.2012 22:18 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS
    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.
    16.1.2012 12:13 limit_false
    Rozbalit Rozbalit vše Re: DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS
    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á).

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.