Tor on R7000

From DD-WRT Wiki

Jump to: navigation, search

Contents

[edit] Install Tor binaries

The binaries in the imx6 repository produce segfaults; you will need to be using magick's devel repo for binaries with statically linked openssl, libevent and zlib. Once you've set up the repository, install these with

opkg install tor-geoip

which will pull in the main Tor package and the GeoIP file. That will get you v0.2.4.20, the latest stable. If you prefer the -alpha release, you can instead use tor-alpha-geoip, which will get you v0.2.5.2, but for most purposes the stable version is fine.

[edit] Start Tor

First, just try typing "tor". It should complain that it failed to read its configuration file from /etc/tor/torrc, and die, but at least if that happens, you verified Tor itself is installed. Now, take a quick look at /opt/etc/tor/torrc (hint: you can "opkg install nano" if you don't like editing files in vi); you shouldn't need to make many changes in order to persuade Tor to start, but do make sure that the line saying

RunAsDaemon 1

is commented out or set to 0, so as to run Tor in the foreground. Now try again with

tor -f /opt/etc/tor/torrc

and you should see it spit out some notices about the bootstrapping process. Once that reaches 100%, Tor is successfully connected to the network and offering its default configuration of a SOCKS5 proxy on localhost:9050. Now you can enable RunAsDaemon 1 in the config file to have Tor run in the background and restart Tor.

[edit] Configure a Tor client

[edit] Configure Tor for client connections

[edit] SOCKS5 proxy

This is configured on localhost by default, which is fine for use with Privoxy. If you want to offer a SOCKS5 route into Tor, for use with SOCKS5-aware client applications (browsers, IRC clients, whatever) then you can enable an additional SocksPort on 192.168.1.1:9050, and an access policy to suit. Note that this only works with SOCKS-enabled client software and is therefore good for elective use of Tor.

[edit] Transparent proxy

If we want to forward traffic forcibly through Tor, without choice on the part of the client or reliance on SOCKS5, we need to use transparent proxying with iptables. Have a read of the Tor project docs on the subject, specifically the section on 'Local Redirection and Anonymising Middlebox', but be aware that we won't use quite the same iptables rules. Configure your torrc to provide a TransPort and a DNS port with

VirtualAddrNetwork 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 9040
TransListenAddress 127.0.0.1
TransListenAddress 192.168.1.1 
DNSPort 5300
DNSListenAddress 127.0.0.1
DNSListenAddress 192.168.1.1 

Take note that we've used port 5300 for DNS; this is so that we can co-exist with dnsmasq, and we can have DNS queries sent to our Tor DNS proxy either by dnsmasq (for elective use) or by iptables (for enforced use).

You can issue a

killall -HUP tor 

to have Tor re-read the configuration file without disconnecting and reconnecting, and use netstat -l to verify that Tor is listening on the ports you want. You can also test that the DNS proxy is working and reachable using something like

nslookup -port=5300 news.bbc.co.uk 192.168.1.1

[edit] Route client traffic through Tor

Now we've got Tor configured to provide a TransPort and a DNSPort, we can have iptables send the traffic of our choice through Tor's transparent proxy.

[edit] All LAN traffic

Note: this is very probably not what you want. If you do this, all DNS enquiries are resolved via Tor, and all TCP connections are made via Tor; you should expect a huge performance hit.

[edit] Route all DNS queries through Tor

Before you do this, you should have tested that your Tor DNS proxy is functioning, as above. You might also look up a geographically sensitive site such as Google before you add this rule and see whether you get a different answer afterwards.

iptables -t nat -I PREROUTING -i br0 -p udp --dport 53 -j DNAT --to 192.168.1.1:5300
[edit] Route all TCP traffic through Tor

Please be aware of what you are doing; this WILL break any site that doesn't like connections from Tor, it may well break your e-mail connections, it WILL break incoming connections and it WILL route all your traffic through anywhere-but-here. That usually isn't what you want. Still, if it is, try

iptables -t nat -I PREROUTING -i br0 -p tcp --syn -j DNAT --to 192.168.1.1:9040
[edit] Block all non TCP traffic

Tor only supports correctly formed TCP streams; you cannot proxy UDP or ICMP traffic through Tor. We should therefore block it at the router, so it cannot be sent directly without using Tor. Assuming that the above are now the first two rules in your prerouting chain, we want to drop all non-TCP protocols only after we have permitted the above, so

iptables -t nat -I PREROUTING 3 -i br0 -p ! tcp -j DROP

after which the start of your prerouting chain should look like

Chain PREROUTING (policy ACCEPT 47566 packets, 3002K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   52  3120 DNAT       tcp  --  br0    any     anywhere             anywhere            tcp flags:FIN,SYN,RST,ACK/SYN  to:192.168.1.1:9040  
  195 12311 DNAT       udp  --  br0    any     anywhere             anywhere            udp dpt:domain to:192.168.1.1:5300 
    4   328 DROP      !tcp  --  br0    any     anywhere             anywhere            

Now test it. A client machine should be able to resolve DNS, load a webpage (try whatsmyip.org), make an SSH connection, whatever. It shouldn't be able to ping anything outside the network, or send UDP or any other non-TCP protocols. If so, congratulations, you just routed your whole network downstream of the LAN bridge through Tor. Take note that we are using "-i br0" to match regular LAN clients both wired and wireless, if you needed to match packets coming in on a tunX or oetX or pppX interface then adjust accordingly.

[edit] All traffic per machine / per network

[edit] By source IP address

As explained above, we generally don't want to apply this to our entire network. So, instead, let's apply the same rules to a single IP address:

iptables -t nat -I PREROUTING -i br0 -s 192.168.1.140 -p ! tcp -j DROP
iptables -t nat -I PREROUTING -i br0 -s 192.168.1.140 -p tcp --syn -j DNAT --to 192.168.1.1:9040
iptables -t nat -I PREROUTING -i br0 -s 192.168.1.140 -p udp --dport 53 -j DNAT --to 192.168.1.1:5300

and your prerouting chain should then begin:

Chain PREROUTING (policy ACCEPT 48080 packets, 3035K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       udp  --  br0    *       192.168.1.140        0.0.0.0/0           udp dpt:53 to:192.168.1.1:5300 
    0     0 DNAT       tcp  --  br0    *       192.168.1.140        0.0.0.0/0           tcp flags:0x17/0x02 to:192.168.1.1:9040 
    0     0 DROP      !tcp  --  br0    *       192.168.1.140        0.0.0.0/0    

You can, of course, do this for an entire IP range or just about anything else that you can match with iptables, including negative matches (everything but <ip>, everything but <mac>, etc). We shall not descend into an iptables tutorial here, but if you can describe it, you can probably match it.

[edit] Selective LAN traffic by port/protocol

Note that when selectively routing connections through Tor, Tor cannot protect you from what you do not route through it. In particular, in order for a client to e.g. connect to a web server on port 80, it first needs to look up the IP address of that web server through DNS. Transparent proxying of individual TCP ports/protocols does not proxy the DNS requests used to look them up, so whilst Tor still provides a degree of abstraction from the web server you are visiting, it cannot offer "browsing without trace" when used with selective ports in transparent mode.

If you are using Tor to circumvent website blocking or simply to hide your IP address, this is probably good enough, but if you intend on using Tor for serious anonymity then you should consider using SOCKS5 between your client and Tor (which includes DNS proxying), or non-selectively routing the whole machine via Tor.

[edit] TCP connections by port

You can choose to route connections to specified ports through Tor. For instance, to have IRC server connections routed through Tor, try

iptables -t nat -I PREROUTING -i br0 -s 192.168.1.140 -p tcp --dport 6667 --syn -j DNAT --to 192.168.1.1:9040

Note that this will route connections to non-hidden IRC servers through a Tor transparent proxy, but it won't enable you to connect to a hidden IRC server with a .onion address; for that, see the next section.

[edit] Selective LAN traffic by destination

[edit] Circumventing blocked HTTP URLs

Selectively using Tor for certain HTTP URLs and not for others requires filtering of the HTTP connection, i.e. a filtering of protocol as well as of TCP/IP destination; this is best achieved by using Privoxy in transparent mode and redirecting the desired URLs to Tor over the SOCKS5 proxy. See Privoxy_Custom_Config for how to do that.

In theory, this is also possible using iptables with the --string match, but that's not included in DD-WRT by default and we're not yet able to add it via Optware, so if you need a filtering proxy, run a filtering proxy and chain it with Tor where required.

[edit] Tor hidden sites

Assume we want machines that are NOT generally routed through Tor to have seamless access to .onion addresses. We're not routing their DNS requests through Tor by default, so they're using dnsmasq on DD-WRT as their local DNS resolver - which can't resolve .onion addresses, obviously.

But we can add a line to the Additional dnsmasq options (in DD-WRT GUI) as follows

server=/onion/127.0.0.1#5300

which tells dnsmasq to forward requests for .onion to our Tor DNS proxy. It will respond with a (spoof) RFC1918 address, giving our client an IP address (in a predetermined netblock, as per the torrc) to connect to for <whatever>.onion, for instance 10.192.1.100.

We can then tell iptables to intercept traffic destined for 10.192.x.x and redirect it into tor's TransPort, with the commands:

iptables -t nat -A OUTPUT -p tcp -d 10.192.0.0/11 -j REDIRECT --to-port 9040
iptables -t nat -A PREROUTING -p tcp -d 10.192.0.0/11 -j DNAT --to 192.168.1.1:9040

The first line works for e.g. connections routed through Privoxy, i.e. where DD-WRT already sends the connection to Privoxy and Privoxy makes a SOCKS5 connection to Tor. The second line is for connections not routed through Privoxy, where the connection is coming from a client on the LAN to a 10.192.x.x address, in which case we reroute it to Tor, and let Tor take care of connecting us with the .onion site.The iptables approach works for a number of TCP protocols, so you can also connect to IRC, FTP or whatever else using Tor.

Be warned: this is a fine example of how the selective use of Tor can compromise your anonymity and possibly create a false sense of security. It's perfect for convenient access to .onion sites, but a site only has to download an image from a non-.onion address and you'll make that connection without using Tor and using your real IP address.

If you're just using it to unblock torrent sites, no big deal, but if you are relying on Tor to provide real anonymity on the dark web, or doing something I'd rather not know about, then best you route all traffic from a given machine through Tor, and/or use the regulation Tor browser bundle, rather than browse with a false sense of security. You should also disable scripting, and/or use a browser with the appropriate security settings, if strict anonymity matters to you.

[edit] Remote WAN or VPN clients [WIP]

If you wish to have access to Tor for clients from outside your network, then you have a couple of options (besides running Tor on that client, obviously). You can connect to the router via VPN, and then arrange to route connections transparently through Tor (by IP address or by interface). You can connect to the router using SSH tunnelling, tunnel your client's localhost port 9050 to the Tor SOCKS5 proxy on the router, and point your SOCKS5-aware application at localhost:9050.

[edit] Configure a Tor relay [optional]

Yes, you can run a Tor relay on an R7000, so if you have the bandwidth then please give something back to the Tor network. It's not much different to running a relay on any other instance of Tor, so please refer to the Tor documentation for fine details. However, there are a few specific observations.

[edit] How much bandwidth?

Running a Tor relay can be as simple as opening an ORPort in the Tor config file and specifying suitable bandwidth restrictions. The Tor relay documentation suggests 50 Kbyte/sec as a working minimum; the author is running with a RelayBandwidth of 256KB, or 2Mbit, and a 4Mbit burst. Three issues are at play here: upstream bandwidth, CPU time and memory footprint.

With ~1.5Mbit of sustained throughput, Tor is using a fair bit of CPU time and memory; the more connections it handles, the more resources it will require. I have not yet tested letting it have higher amounts of bandwidth, but I suspect that a couple of Mbit is the point of diminishing returns. Users are recommended to start with 64KB and increase from there, and also to run tor using "nice". At some point I'll test with larger amounts of bandwidth, but the general advice is better small and sustainable than overgenerous and resource-heavy. A figure of 0.5Mbit to 2Mbit is useful to the Tor network without placing undue demands on the router; if you go further than that on an R7000 then please document it here.

[edit] Configure a Tor directory server

[edit] Bandwidth accounting

If AccountingMax is enabled, the relay will go into hibernation to avoid consuming too much bandwidth, which is incompatible with running a directory server. Therefore, Tor will refuse to advertise the DirPort if AccountingMax is enabled. You can still restrict bandwidth use through rate-limiting, but not through per-day or per-month bandwidth accounting. If you need to limit overall bandwidth consumption per day or per month, rather than by simple rate-limiting, then by all means run a relay but don't be a directory server.

[edit] Dynamic IP address

Having a dynamic IP address makes no difference to your ability to run a Tor client or relay, but if you intend to run as a Directory Server (and therefore to publish a DirPort), tor needs to know a reachable IP address or URL at which that DirPort can be reached.

You can either set "address" in the config file to a dynamic DNS hostname, or you can omit it but run tor with --address `nvram get wan_ipaddr` so as to set the address on startup. Alternatively, you can update the config file prior to startup, with

sed -i "s/^Address\ .*$/Address `nvram get wan_ipaddr`/" /opt/etc/tor/torrc

which will update an active, uncommented address line to contain the current WAN IP address. If you want to do that, add the above to your startup scripts right before you launch Tor.

[edit] Do I really want to do this?

Certainly running a Tor client can be extremely useful, particularly in circumventing URL blocking. Running a Tor relay is a useful way to give back to the network, but the jury is still out on whether the R7000 is the ideal place to do that. It does work, but you should consider whether you are happy with the load on your router and connection.

[edit] Impact on router

The author of this page (magick777) has been successfully running a Tor relay (set for 3Mbit/sec average, 6Mbit/sec burst, DirPort enabled) and generally the router copes with this adequately. Typically I'm seeing a total of ~400-500 connections to and from Tor when the relay is in serious use. CPU usage on startup and during re-processing of Tor's consensus files can be fairly hefty; it doesn't make the router totally unresponsive but it puts it under a degree of strain, and I would not be particularly comfortable about the router performance with higher bandwidth levels and higher connection counts. It's also using ~100MB of memory, and I think this has led to some out-of-memory kills. You really need a swap file if you plan to run a Tor relay. I don't think using JFFS2 for the Tor runtime files helps any, so a fast USB key is also strongly recommended if this is what you want to do.

[edit] Impact on connection

The level of impact on your Internet connection and bandwidth usage is entirely configurable, but you should expect some negative impact on connection latency if you are constantly relaying traffic, and of course the use of some of your available bandwidth. My 3Mbit relay is currently downloading ~9.5GB/day and uploading ~10.8GB/day, the difference accounted for by running a directory server.

If your ISP has a traffic management policy, running a Tor relay can cause you to fall foul of it. In the author's case this kicks in at an upload rate of ~1.5GB / hour during peak times, so the 3Mbit relay stays well within acceptable limits, but a constant 10Mbit relay would be likely to incur enforced traffic management (and rightly so, I have to say). The author does not run Tor on networks where it is expressly forbidden to do so, and he would expect to get booted off them if he did.

[edit] Impact on anonymity

Whilst running Tor on your router is a great way of providing convenient access to the Tor network, what it does not hide is the fact that your IP address is connecting to the Tor network in the first place, and/or is a part of the Tor network if you run a relay. In most of the world this is not illegal, but the simple fact that you are using Tor is detectable and it could potentially cause you to fall foul of your ISP / college / employer / government / local law enforcement. If you live in a jurisdiction where the use of such software is an offence, either don't do it, or don't do it so detectably on a connection in your home jurisdiction.

Similarly, if you're thinking of connecting from your school / college / university / employer, read their IT policy first. Your use of Tor is detectable, and the consequences can be dire even if they cannot prove what you were using it for. If you can't take that risk - please don't, there are free Unix shell accounts that will connect you to Tor, and/or you can set up a VPN and run it somewhere else.

[edit] Known issues

[edit] Crashes / out-of-memory kills

The author has had Tor crash or get killed on two occasions (not sure which), both times after 3-4 days of uptime and under heavy load (several hundred connections, a few Mbit of throughput, substantial memory usage). No evidence in the log file as to why, but running out of memory is a prime suspect. The author has yet to enable swap space, which may or may not help.

[edit] Clock drift

Tor complains that the system clock has jumped by several hundred seconds per day, probably the result of running ntpclient infrequently. It is suggested either to run ntpclient more frequently from cron, or to install and configure an ntp server. The times of these warnings coincide exactly with the recreation of the cached-descriptors file (30MB) and my suspicion is that the heavy use of JFFS2 is hanging things up for 5 minutes at a time. The next step will be to move to a decent USB key and add a swap file; this is probably neither Tor's fault nor the router's fault, but mine.

[edit] CPU thrash on startup

In the course of performing a firmware upgrade, I shut Tor down gracefully with a kill -INT, did the firmware upgrade, rebooted the router (and restarted Tor with it), having been running a relay with several hundred connections. Bootstrapping Tor and dealing with the incoming connections took about four or five minutes, during which time Tor was using all the CPU it could get. Once running, it behaves relatively nicely, but be aware of the potential for CPU thrashing on startup, especially when running a relay.


[edit] Monitoring Tor with arm [optional]

This section is optional; you can perfectly well run a Tor client (or relay) without it. However, it can be useful to see what's going on.

[edit] Install arm

opkg install arm

[edit] Configure your ControlPort and password

Back in the torrc, you've a line for a local ControlPort on port 9051. This is what arm uses in order to connect to Tor, but you will need a hashed password in the torrc for authentication. To generate that, run

tor --hash-password <yourpassword>

and paste the output into the relevant line in torrc. Then run a killall -HUP tor to have the new torrc take effect.

[edit] Run arm

arm

will start the arm binary with no default configuration, it will ask for your password and connect to the local copy of Tor. Note that it is largely useful for monitoring and I have not used it to edit or change the torrc; you can do that manually and you probably should. What it is useful for is seeing bandwidth use, circuit use, what's working and what isn't.

[edit] Add an armrc

Completely optional, but if you want arm to "just work", then you can create an rc file for it. Don't do so under its default choice of /tmp/root; that's in memory and lost on startup. If you want to do this, go and find armrc.sample (plenty of copies on Google / Github) and put a copy of it in /opt/etc/armrc, editing it to your requirements and specifying the control password therein. Then you can use

arm -c /opt/etc/armrc

and up it comes.

[edit] Configure DD-WRT startup & firewall scripts

[edit] Start Tor on startup

When you are happy that Tor is running OK manually, you can add

tor -f /opt/etc/tor/torrc 

to the Startup Commands (via the DD-WRT GUI under Administration, Commands) to have Tor started automatically on startup. Tor can get quite CPU-heavy, so it's not a bad idea to run it with

nice -n10 tor -f /opt/etc/tor/torrc

which will minimise any impact on the router. The author is happily running a relay with 2Mbit throughput, typical load average of 0.80 and temperatures of 64-65C at 1200MHz.

[edit] Configure iptables

If you are using transparent proxying as described above, then you are reliant on the iptables rules to redirect your traffic to Tor, so you need them to be recreated on startup. You should add the necessary iptables commands for your situation to the DD-WRT firewall script, also under Administration, Commands. When that is done, reboot the router and verify that Tor starts and that the appropriate iptables rules are in place, and that everything works as expected.

[edit] Move datadir to /jffs [optional]

Tor stores state files and runtime data in /var/lib/tor, which under DD-WRT is stored in memory and lost on reboot. The data can be recreated, but for a smoother and speedier startup let's keep the data under /opt. This is particularly recommended if you intend to run a relay, since otherwise your key and fingerprint will be lost on a reboot and you'll end up creating a new relay every time you restart.

mkdir -p /jffs/var/lib/
cp -av /var/lib/tor /jffs/var/lib/

Edit the torrc to point to the new location /jffs/var/lib/tor and restart Tor.