Re: Yet another UDP / DNS quiestion...
Yes if you redirect DNS requests to Tor's DNSPort you should be safe against DNS leaks. Do I have to use AutomapHostsOnResolve 1 as well? Seems to be pointless without defining AutomapHostsSuffixes. I guess you are talking about a local setup without a middlebox involved. If my assumption is correct you want to refer to the following section in the document: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy#LocalRedirectionThroughTor Thanks for clarifying that! Now I need to read some more about iptables. One more question: will those rules route all UDP traffic to port 53 or just DNS requests? What will happen with UDP not relating to DNS? -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Excluding exit nodes
From the Tor Project FAQ https://www.torproject.org/docs/faq#ChooseEntryExit: We recommend you do not use these — they are intended for testing and may disappear in future versions. You get the best security that Tor can provide when you leave the route selection to Tor; overriding the entry / exit nodes can mess up your anonymity in ways we don't understand. Now, it's a little bit confusing for a novice, let me explain why. People both on this mailing list and else where on the Internet are often referring to excluding bad/evil exit nodes (I'm aware that it's a bit ambiguous concept) and yet there is this entry in Tor Project FAQ. So how someone like me, a newcomer to Tor, Linux and networking, should know which exit nodes are suspicious? I came across this website http://torstatus.blutmagie.de/index.php which flags couple of nodes as Bad Exit - should I exclude them? How reliable information on this website are? Is there any authoritative list of suspicious exit nodes? -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Excluding exit nodes
On Sun, 2011-02-13 at 15:51 +0100, tagnaq wrote: No you do not need to exclude them because your client will not use nodes with the BadExit flag as an exit node anyway. The torstatus website does not flag them, it just shows you that they have this flag because the DirectoryAuthorities flagged these nodes as badexits. Now I'm even more confused! What is DirectoryAuthorities? Quick googling yielded no results I can understand and Tor -alpha Manual is not helpful on that matter either. Could you point me somewhere I can find more informations about matters relating to exit nodes? I'm going through archives of this mailing list and documents on Tor website but there is *a lot* of informations in those places and it will take me considerable amount of time to read all of it. How someone can recognise if an exit node *might* be doing something suspicious - like sniffing traffic for passwords? As far as I can tell (with my limited knowledge that is!) it's by checking which ports the node in question is making available. And if there are not the standards one then it *could* do something nasty - which of course don't mean it does. Could you clarify this whole rouge/bad/evil nodes matter? -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Excluding exit nodes
On Sun, 2011-02-13 at 17:07 +0100, tagnaq wrote: https://www.torproject.org/docs/faq.html.en#KeyManagement (Coordination section) General Design Document: https://www.torproject.org/docs/documentation.html.en#DesignDoc https://svn.torproject.org/svn/projects/design-paper/tor-design.html (chapter 6.3) Note: This document is from 2004. Statements like new nodes must be approved by the directory server administrator before they are included are no longer valid. https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/dir-spec.txt#l142 Wow! This will keep me busy for quite a while! Thanks! Well this is currently a 'hot topic' and I refer you to the lengthy thread 'Is gatereloaded a Bad Exit?'. Short answer: you can not reliably detect passive sniffing. Yes, I'm following 'Is gatereloaded a Bad Exit?' but at times it's *very* confusing. Well, I won't worry about exit nodes until I won't have better understanding of Tor and networking in general. -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Yet another UDP / DNS quiestion...
Could you describe your use case + thread model? I'm terrible sorry for chaos I'm causing but right now I'm a very small and confused person :-) Let me start from the beginning... I'm using Privoxy + Tor combination. For Privoxy to properly handle TCP/HTTP requests and send them over Tor network I have listen-address 127.0.0.1:8118 in my /etc/privoxy/config. Then, to make sure that Privoxy will be used globally, I added those four lines to /etc/environment: http_proxy=http://127.0.0.1:8118/; https_proxy=https://127.0.0.1:8118/; HTTP_PROXY=$http_proxy HTTPS_PROXY=$https_proxy Now all TCP/HTTP traffic should go through Privoxy - Tor combination, at least in theory. As I understand Wireshark is the tool I should use to verify if that is what is happening in reality. I compiled Wireshark but don't understand yet how to use it so I will come back to verify routing of TCP/HTTP when I understand what I'm doing. Next, I tried to use torsocks to make sure UDP/DNS requests are resolved through Tor. To accomplish that I added to /etc/privoxy/config forward-socks4a / 127.0.0.1:9050 . forward-socks5 /127.0.0.1:9050 . My /etc/torsocks.conf looks like this: local = 127.0.0.0/255.128.0.0 local = 127.128.0.0/255.192.0.0 local = 169.254.0.0/255.255.0.0 local = 172.16.0.0/255.240.0.0 local = 192.168.0.0/255.255.0.0 server = 127.0.0.1 server_port = 9050 But I have two problems with using torsocks: 1. Not all applications seems to be working with it, for example when I try usewithtor empathy I'm getting Segmentation fault. Which is probably due to the problems with rejecting UDP: torsocks allows you to use most socks-friendly applications in a safe way with Tor. It ensures that DNS requests are handled safely and explicitly rejects UDP traffic from the application you're using. (from https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO) 2. I would need to usewithtor every single application on my system to make sure DNS requests are resolved through Tor. Then I came around Transparently Routing Traffic Through Tor https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy. And this is where more confusion and problems started! What I want to achieve with this wiki is to make sure all UDP/DNS request will be send through Tor. Now I intend to follow Local Redirection Through Tor from mentioned wiki to the letter and that will hopefully resolve the case of leaking DNS. # Block/reject all outgoing UDP traffic iptables -A OUTPUT -j REJECT This rule does not block UDP only, it rejects all traffic including UDP (if a packets makes its way to the last line). So if I will go ahead with set-up from Local Redirection Through Tor it will allow out just the traffic going through Tor stopping any and every kind of no-Tor traffic from leaving my machine. But if I want to allow traffic from certain applications I could do it by setting up exception in iptables, right? And furthermore, with this solution there will be no need for me to use torsocks any more, yes? iptables -A OUTPUT -p udp -m owner --uid-owner $TOR_UID -j ACCEPT Why did you add -p udp here? Tor uses TCP. My mistake! Fixed now. I'm wondering why one would want to setup DNSPort configuration without TransPort. That will be lack of knowledge on my part, I missunderstood informations from wiki. I got confused by this comment http://www.hermann-uwe.de/blog/howto-anonymous-communication-with-tor-some-hints-and-some-pitfalls#comment-80205 which doesn't mention TransPort and thus I thought it is not necessary. I wonder why your uid should be different everytime you reboot, but you can also use the name of the user instead of the numerical value. Well I can't tell you why but that how it is. To double check I rebooted twice just now and ps -A | grep -w tor each time gave me different UID for tor. -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Yet another UDP / DNS quiestion...
On Sun, 2011-02-13 at 11:04 -0800, Robert Ransom wrote: That's a process ID, not a user ID. Arrrgh! My brain is slowly melting. I think what I will do now is to give up on Tor and attempts to understand it. I will explore more how to properly and effectively use Linux. Then I shall delve some more into basic concepts behind Internet Protocols and THEN, just then, I will come back to Tor. Well, see you folks in a year or two! -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Yet another UDP / DNS quiestion...
I feel that I should explain something before I start asking any questions so here we go: I'm a fresh convert to Linux (barely few week on Ubuntu!) and as much as I'm fascinated by the matters relating to networking, security and anonymity in equal measure I'm intimidated by them. I don't posses any deep knowledge of those topics, I still barely can handle the basics. But with the wealth of knowledge out there and a healthy dose of experimentation I intend to change this. So if my questions are naive (or plainly stupid) please bear in mind that I'm new here. And now for what is bordering me... I was reading Transparently Routing Traffic Through Tor https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy and although I don't need to run Tor as transparent proxy I like the idea of routing the UDP/DNS requests to localhost. If I will reroute all those requests with iptables to the port on which Tor is listening I should have no problems with DNS leaking, right? That should do the trick then: 1. torrc DNSPort 53 DNSListenAddress 127.0.0.1 2. resolv.conf nameserver 127.0.0.1 3. iptables iptables -t nat -A OUTPUT -o lo -j RETURN iptables -t nat -A OUTPUT -m owner --uid-owner $TOR_UID -j RETURN iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53 iptables -t nat -A PREROUTING -i $INT_IF -p udp --dport 53 -j REDIRECT --to-ports 53 iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT iptables -A OUTPUT -j REJECT I'm not an expert regarding iptables and 'man iptables' is *very* frightening for someone who barely slides on the surface of all this. From steep three above I sort of understand purpose of rules three and four but rest of them... Are they needed in this example or they can be safely omitted? If in fact they are required for this set-up to work what is their purpose? I will of course replace $INT_IF and $TOR_UID with required values. -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
