[tor-talk] Tor transparent proxy leaks?
After setting up my computer (Debian Squeeze 6.0) to transparently proxy all my traffic over tor, I decided to verify it by visiting check.torproject.org with chromium. It told me that I was using tor, so I thought everything was good. After that, just to be sure, I checked my connections with lsof, and got the following results: root@black-wind:/home/magus/# lsof -i -n -P COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME rpcbind 1984 root6u IPv4 4993 0t0 UDP *:111 rpcbind 1984 root7u IPv4 4996 0t0 UDP *:887 rpcbind 1984 root8u IPv4 4997 0t0 TCP *:111 (LISTEN) rpcbind 1984 root9u IPv6 5000 0t0 UDP *:111 rpcbind 1984 root 10u IPv6 5003 0t0 UDP *:887 rpcbind 1984 root 11u IPv6 5004 0t0 TCP *:111 (LISTEN) polipo2274 proxy0u IPv4 6276 0t0 TCP 127.0.0.1:8118 (LISTEN) polipo2274 proxy1u IPv4 516635 0t0 TCP 127.0.0.1:55414-127.0.0.1:9050 (CLOSE_WAIT) polipo2274 proxy5u IPv4 202157 0t0 TCP 127.0.0.1:53717-127.0.0.1:9050 (CLOSE_WAIT) avahi-dae 2580 avahi 13u IPv4 7394 0t0 UDP *:5353 avahi-dae 2580 avahi 14u IPv6 7395 0t0 UDP *:5353 avahi-dae 2580 avahi 15u IPv4 7396 0t0 UDP *:47014 avahi-dae 2580 avahi 16u IPv6 7397 0t0 UDP *:39872 dhclient 2675 root6u IPv4 7539 0t0 UDP *:68 dhclient 2675 root 20u IPv4 7529 0t0 UDP *:24378 dhclient 2675 root 21u IPv6 7530 0t0 UDP *:56547 tor 2686 debian-tor4u IPv4 7606 0t0 TCP 192.168.1.4:38300-188.138.104.154:443 (ESTABLISHED) tor 2686 debian-tor7u IPv4 6495 0t0 TCP 127.0.0.1:9050 (LISTEN) tor 2686 debian-tor8u IPv4 6496 0t0 UDP 127.0.0.1:53 tor 2686 debian-tor9u IPv4 6497 0t0 TCP 127.0.0.1:9040 (LISTEN) tor 2686 debian-tor 10u IPv4 6498 0t0 TCP 127.0.0.1:9051 (LISTEN) tor 2686 debian-tor 14u IPv4 963741 0t0 TCP 127.0.0.1:9040-192.168.1.4:51136 (ESTABLISHED) tor 2686 debian-tor 15u IPv4 182884 0t0 TCP 127.0.0.1:9050-127.0.0.1:53591 (ESTABLISHED) tor 2686 debian-tor 16u IPv4 6571 0t0 TCP 192.168.1.4:37413-144.51.40.66:443 (ESTABLISHED) tor 2686 debian-tor 17u IPv4 6606 0t0 TCP 192.168.1.4:44714-93.185.101.76:443 (ESTABLISHED) tor 2686 debian-tor 18u IPv4 964951 0t0 TCP 127.0.0.1:9040-192.168.1.4:38331 (ESTABLISHED) tor 2686 debian-tor 19u IPv4 964213 0t0 TCP 127.0.0.1:9040-192.168.1.4:47171 (ESTABLISHED) tor 2686 debian-tor 28u IPv4 13205 0t0 TCP 127.0.0.1:9050-127.0.0.1:51685 (ESTABLISHED) tor 2686 debian-tor 29u IPv4 10504 0t0 TCP 127.0.0.1:9050-127.0.0.1:51662 (ESTABLISHED) tor 2686 debian-tor 30u IPv4 601334 0t0 TCP 127.0.0.1:9050-127.0.0.1:56632 (ESTABLISHED) tor 2686 debian-tor 31u IPv4 602532 0t0 TCP 127.0.0.1:9050-127.0.0.1:56633 (ESTABLISHED) tor 2686 debian-tor 32u IPv4 601518 0t0 TCP 127.0.0.1:9050-127.0.0.1:56634 (ESTABLISHED) tor 2686 debian-tor 36u IPv4 14604 0t0 TCP 127.0.0.1:9050-127.0.0.1:51694 (ESTABLISHED) pidgin3189 magus8u IPv4 13198 0t0 TCP 127.0.0.1:51685-127.0.0.1:9050 (ESTABLISHED) pidgin3189 magus 11u IPv4 10503 0t0 TCP 127.0.0.1:51662-127.0.0.1:9050 (ESTABLISHED) pidgin3189 magus 14u IPv4 15727 0t0 TCP 127.0.0.1:51694-127.0.0.1:9050 (ESTABLISHED) ssh 3882 magus3r IPv4 182883 0t0 TCP 127.0.0.1:53591-127.0.0.1:9050 (ESTABLISHED) ssh 4540 magus3r IPv4 602416 0t0 TCP 127.0.0.1:56632-127.0.0.1:9050 (ESTABLISHED) ssh 4541 magus3r IPv4 601423 0t0 TCP 127.0.0.1:56633-127.0.0.1:9050 (ESTABLISHED) ssh 4542 magus3r IPv4 602645 0t0 TCP 127.0.0.1:56634-127.0.0.1:9050 (ESTABLISHED) chromium 5495 magus 63u IPv4 963465 0t0 TCP 192.168.1.4:51136-173.194.71.95:443 (ESTABLISHED) chromium 5495 magus 99u IPv4 964203 0t0 TCP 192.168.1.4:38331-74.125.143.99:443 (ESTABLISHED) chromium 5495 magus 107u IPv4 965144 0t0 TCP 192.168.1.4:47171-173.194.71.120:443 (ESTABLISHED) ... Why is chromium telling me that I'm using tor, when it seems pretty clear from lsof that I'm not? Am I doing something wrong? (See below) Since I know someone is going to ask, here are my iptables rules (They're the same rules found for setting up transparent proxying for a specific user as you find on the transparent proxy wiki page (https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy) except with the username changed to my regular login): iptables -t nat -A OUTPUT ! -o lo -p tcp -m owner --uid-owner magus -m tcp -j REDIRECT --to-ports 9040 iptables -t nat -A OUTPUT ! -o lo -p udp -m owner --uid-owner magus -m udp
Re: [tor-talk] Bad Exit Node Control
Why kick of bad exits? If you identify an exit that is gathering data or manipulating data, then simply take them out of rotation and feed them false connections so that they stay on line and wast resources. Otherwise they will shut down and be back up the same day. If you can lead them on for a while it will make all tor users safer. On Mon, Apr 1, 2013 at 8:21 PM, Aaron aag...@extc.org wrote: On Sun, Mar 31, 2013 at 4:45 PM, Roc Admin onionrou...@gmail.com wrote: I took another look at the OONI project. Although it's oriented towards ISPs etc, isn't this almost exactly what's needed - or at least a start? The tests for many of the items that Mike Perry identified in the spec are already there. https://gitweb.torproject.org/ooni-probe.git/blob/16ec7a88d426b30a7bd604e97e6b5d7225b9bb91:/README.md Thoughts? This is a thought I've also had. There are some missing parts (namely, Tor circuit control) that don't yet exist, but intend to add in the future. There should be an OONI test template (see ooni/templates) for tests that need to interact with Tor. Some other things to address: * how are exits selected for testing? From an input file? Or Tor consensus? * how are the output reports formatted? What data is included? Where are they submitted? * Who runs the tool? Would it work like the current BwAuth, where a DirAuth and BwAuth operator pair up, or could anyone report BadExit? This sounds like a project needing a proposal (see tor-spec.git if you're not familiar). I'd be happy to collaborate, if anyone is interested in going this direction. --Aaron ROC On Sun, Mar 31, 2013 at 11:12 AM, Aaron aag...@extc.org wrote: On Sat, Mar 30, 2013 at 4:18 PM, Roc Admin onionrou...@gmail.com wrote: Does this mean that you're planning to expand the SoaT codebase? Write a revised version? If the project is going to be revived then it would make sense for it to take advantage of one of our newer controller libraries... Yeah the plan is to do a complete rerwrite of SoaT. That guy was a beast and almost did its job too well. I talked a little about this on the tor-dev side but I'm definitely using Stem. I didn't know about the other project though so thank you. There was also some discussion about interfacing with Onionoo but now we're talking too far down the line. 2. Even when a bad exit *is* reported our process for flagging it is pretty well broken. To be flagged at least two of the three authority operators that vote on the BadExit flag need to take manual action. All three operators are highly busy people so in practice relays don't get flagged without considerable nagging. Exactly. I think Mike Perry's proposal that Aaron linked to is still spot on in terms of what we want from a solution. In the deployment section it notes three phases where the final one is an automatic communication between the scanning engine and the Tor Network so that it alerts Directory Authorities. This interface in itself requires some thought. It's threat model includes accidentally causing a DoS on all hosts on the network if something goes wrong, or inappropriately flag a good node, or the fact that knowing how to tool works, a malicious node could change it's activities to avoid detection. The other issue that is stuck in my head is that I think exit scanning is always going to be a losing battle and this is a best-effort game. I see it in the same way that Android has tried to keep track of malware on the Play market. It will be days in even the best case scenario before we find out an exit node is malicious and properly report them. It's high effort for little return. While it may be an arms race. I don't think it's as bad as you might think. For starters, there's a lot of low hanging/high reward fruit -- just two volunteers running BadExit scans collaboratively would be a huge improvement. In an ideal - not-Tor world - there could be some kind of activation process for exit nodes that validate configurations and performs simple checks before they join the network, and contact information is confirmed (or at least attempted). This assuredly will never happen for a variety of reasons one of which is that it's a deterrent for those volunteer operators that we need lots and lots of. I wonder if this has already been discussed or if it's worth at least documenting the design decision somewhere. It's valid to say We won't do this because of X Y and Z but I would like to see how the debate would go against a realistic solution (that has yet to be proposed). This isn't likely to work either, as bad exits can wait arbitrary amount of time after passing any tests before attacking clients. I think it's preferable that tests are unpredictable, periodic, and looks as much like a real user as possible. ROC
Re: [tor-talk] Tor transparent proxy leaks?
On Mon, 01 Apr 2013 06:40:50 + James Russell jamesruss...@tormail.org wrote: After setting up my computer (Debian Squeeze 6.0) to transparently proxy all my traffic over tor, I decided to verify it by visiting check.torproject.org with chromium. Use tor browser or don't bother. Tor only supports TCP. -- Andrew http://tpo.is/contact pgp 0x6B4D6475 ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
