wiki:doc/TorBOX/OptionalConfigurations

Version 95 (modified by proper, 8 years ago) (diff)

Transparent Proxying

TorBOX Homepage

These are all OPTIONAL configurations. If you would like to use any of these features, go ahead and follow the instructions. However, you do not have to add any of those additional functions if you see no need for them.

Autologin into the Tor-Gateway

This feature is already implemented on Tor-Gateway 0.1.3 or in tor-gateway.sh with -vm command line switch. To install it manually follow the instructions below.

If it bugs you to manually login into the Tor-Gateway after reach reboot you can use rungetty.

apt-get install rungetty

'nano /etc/init/tty1.conf'

exec /sbin/getty 38400 tty1

with

exec /sbin/rungetty --autologin USERNAME tty1

Disable power save (black display)

This feature is activated on Tor-Gateway 0.2.0 and above, for the download version and using the tor-gateway.sh with -vm command line switch.

If it bugs you that the screen in the Tor-Gateways goes black after a while type

nano /home/user/.bashrc

and insert

setterm -blank 0 -powersave off -powerdown 0

Logout 'logout' and login again. Power saving features should now be disabled.

Using socksproxy in Tor-Workstation

Moved to Identity correlation through circuit sharing

More than one Tor-Workstation

Moved to Recommendations to use multiple Tor-Workstation VM's and Snapshots.

Tunneling Tor through proxy, VPN or SSH

user -> proxy/VPN/SSH -> Tor

Read first: Tor Plus VPN and TorBOX VPN disclaimer.

This section is not fully tested/complete. Please give feedback if it worked for you.

Sometimes you are forced to use a proxy or VPN to make outgoing connections, some ISP's force you, or you are in a LAN with a proxy (router), or in a cooperate environment.

A proxy, VPN or SSH can also be possibly used to circumvent Tor blocks or to hide the fact you are using Tor. VPN and SSH are preferred choice, as they support secure encryption between you and them. It's a question, how much you can trust the server, they'll see, that you are using Tor, but thanks to Tor, they won't see what you are doing. If you use your own server in a safe country, while you are in a dangerous country, that's probable your best bet. Anyway, not so many people seam to do use a tunnel before they connect to Tor, therefore it's not so well tested, do not rely on it too much.

If nothing above applies for you, skip this section.

Tunnel Tor through proxy

user -> proxy -> Tor

Depending on your proxy configuration, add the settings you'll need to your /etc/torrc. For more information on these settings, have a look in the Tor manual and read the FAQ. 'nano /etc/tor/torrc'

HTTPProxy host[:port]
HTTPProxyAuthenticator username:password
HTTPSProxy host[:port]
HTTPSProxyAuthenticator username:password
Socks4Proxy host[:port]
Socks5Proxy host[:port]
Socks5ProxyUsername username
Socks5ProxyPassword password

Tunnel Tor through SSH

user -> SSH -> Tor

First we have to install the ssh client.

apt-get install ssh

Then be sure that your SSH connection itself is working well. SSH to your ssh server using 'ssh yourusername@…'. It's recommend to set up public key authentication. (TODO: how to create a private and public key) 'cd /home/yourusername', 'mkdir .ssh', 'nano authorized_keys', paste line beginning with 'ssh-rsa ...' (your public key) (TODO: how to create that line).

'exit' (terminate SSH connection) and login again using public key authentication. (TODO: how to do that) When that is working install your favorite text mode browser, for example 'apt-get install lynx' and test if the shell's external internet connection is working. 'lynx check.torproject.org' You're done with the pre-requriements. Exit your shell. 'exit'

Now we will tell the SSH client to start a socks5 proxy server listening on localhost 127.0.0.1 port 1080. The following command has to be run in background (TODO: add line how to do that) on each start up, before Tor starts (TODO: to which file, to do that). It would be wise to activate public key authentication (TODO: how to add private key to use public key authentication).

ssh -C -D 1080 your.ssh.server

Now we have to tell Tor to use the new local ssh server. 'nano /etc/torrc' and add

Socks5Proxy 127.0.0.1:1080

We are done, from now Tor will connect through the SSH server.

(TODO: any new firewall rules needed?)

Tunnel Tor through VPN

user -> VPN -> Tor

There are too many different VPN protocols. To many to add all of them to this guide. If you are forced to use a VPN server or if you are already using a VPN server, you most likely know how you can connect to it. You must know how to connect to your VPN server from the linux command line. Use the following order, start the firewall, connect to your VPN and start Tor afterwards.

If you are using VPN not because you are forced to use VPN by your ISP, but to hide the fact that you are using Tor or want to add an additional layer of protection, then be sure, that your VPN software is secure (ex: OpenVPN, not pptp). When your VPN is properly set up, all your connections are forced through the VPN. If you start Tor at the top of that, tunneling Tor through VPN will work.

TODO: protection on linux needed. Do not to send something in clear,

  • when VPN connection breaks down
  • when VPN client crashes or gets terminated

Tunneling Proxy/SSH/VPN through Tor

user -> Tor -> Proxy/SSH/VPN

Read first: Tor Plus VPN and TorBOX VPN disclaimer.

You can tunnel through Tor first and add an additional proxy, SSH or VPN hop at the very end of that chain as your "exit node". The services you connect to, will not know, that you are using Tor (unless it's a "transparent proxy" in sense of sending http forwarded for, covered in the article linked above). This can be useful to evade Tor bans, for example, to visit websites or IRC networks who blacklisted Tor. Beware of the risks, this adds a "permanent exit node", read the related wiki article.

To do that, go to your Tor-Workstation and add the proxy, SSH or VPN normally, like you would have to do, if you wouldn't use the Tor-Gateway.

Protocol leaks still apply, thought to a lesser extend. Leaks would 'only' leak through Tor and you have best possible Protocol-Leak-Protection and Fingerprinting-Protection.

Tunneling proxy through Tor

user -> Tor -> proxy

Note, that the connection, between the Tor exit node and the proxy, is in most cases, not encrypted.

Proxy Settings Method

Very simply to set up. Simply add a proxy to your application's proxy settings or use a socksifier.

Transparent Proxying

Introduction

You always have to keep in mind, which kind of data and which kind of proxy you are using. There are CGIproxies, http(s) proxies and socks4/4a/5 proxies. (https proxy is misleading, as the connection to the proxy is not encrypted. The proxy additionally supports the connect method, which is required to access SSL websites and other services.) In case you redirect the network layer directly with iptables, you need a TransPort. Unfortunately very few applications, support a TransPort. For example, Tor supports as TransPort. In most other cases, you need to translate the different kinds of data.

Due to the nature of Transparent Proxying, we need to redirect with iptables and end up with a "Trans data stream". Because most proxies are either http or socks we need to translate this.

Tor is a socks proxy and also has a TransPort. Unfortunately, Tor can not be directly used as a http proxy.

Privoxy is a http proxy and can also accept "Trans data streams", when accept-intercepted-requests is set to 1 in /etc/privoxy/config. Rather Privoxy is also able to forward traffic to parent proxies, http or socks.

Polipo is lighter, simpler and faster then Privoxy. Unfortunately, it can not handle "Trans data streams". It is a http proxy and can forward either to http or socks proxies.

HowTo

Not finished yet. Not fully tested.

Everything on Tor-Workstation.

Instal privoxy.

sudo apt-get install privoxy

Open /etc/privoxy/config and change the following setting.

accept-intercepted-requests 1

Add the following to /etc/privoxy/config as well.

# change IP and port to your http proxy
# example for JonDonym, works also with free cascades
# note that JonDonym free cascades allow only outgoing ports 80 and 443
#
# TODO: not sure about a dot at the end or not.
forward / 127.0.0.1:4001

Tunneling SSH through Tor

user -> Tor -> SSH Note, that even though SSH supports socks5, SSH is still not able to forward UDP on its own. Have a look the the source of that information. To summarize: to tunnel UDP over SSH client and shell admin need a special setup, which is for most shells not going to happen.

Tunneling VPN through Tor

user -> Tor -> VPN

Note, that you have to choose TCP transport, because Tor does not support UDP.

Warning:
For users who configured applications to use SocksPort, instant of TransPort. (TorBOX's Tor-Gateway default setting for some applications, Tor Browser, ...!)

SocksPort is used to prevent Identity correlation through circuit sharing. As Tor Plus VPN explains, you have to keep in mind, a VPN behind Tor adds a permanent exit node.

Rather, all applications, which are configured to use SocksPort, will not be tunneled through the VPN. They will be "only" tunneled through Tor. This is because, the VPN will not touch connections to 192.168.0.1, which is the Tor-Gateway. For example, if you wish to tunnel through Tor -> VPN, you have to remove all proxy settings from Tor Browser. check.torproject.org will tell you then "You are not using Tor." and you'll see your VPN's IP. In fact your VPN was tunneled through Tor first. (Because Tor-Workstation can not make any non-Tor connections by design, everything is tunneled over Tor.) When you stop your VPN for test reasons ('sudo /etc/init.d/openvpn stop'), it will show "You are using Tor." again.

While you are using a VPN behind Tor, you probable also may not be able to make use of the upcoming stream isolation feature, which is planed Tor Browser. (#3455) This is because Tor Browser would not talk to Tor directly anymore. Tor Browser would connect to the VPN instant.

VPN servers and VPN software can occasionally break down without announcement. Tor-Workstation will seamlessly continue to make "direct" connections through Tor once the VPN breaks down. This is not a TorBOX specific problem. Most users are simply not aware of it. This happens also with the common setup, where the VPN simply runs on a host. If you want to enforce, that the VPN is always tunneled over Tor, have a look at the modified routing table here.

Also note, that once Tor-Workstation gets rooted by malware, the VPN can be easily circumvented by the attacker and you are left to the protections by TorBOX and Tor.

By design, a VPN routes all your applications (those without any proxy settings, as explained above) through the VPN. You may not want this, as explained above (Identity correlation through circuit sharing). To circumvent that, you should use this Tor-Workstation only for the particular application you want to route through the VPN, read Recommendation to use multiple Tor-Workstations.

A Free example VPN working with TorBOX for testing purposes

Read first TorBOX VPN disclaimer.

Can be either:

The purpose of this chapter is mainly to demonstrate, how easy it is, to add a VPN to TorBOX. Unfortunately securityKISS.com drops many TCP and UDP ports beside ports 80 and 443. That limits it's usefulness for testing purposes, such as Tunneling UDP over Tor. If you know a less restrictive free VPN provider, we'd be thankful for a comment.

Install openvpn.

apt-get install openvpn

Register at securitykiss.com and leaf no personal information. Use an extra e-mail address for registration, which you will never use for anything else. Login and download their OpenVPN package to /home/user. Unpack. The folder contains contains ca.cert, client.cert, client.key, README.txt (with list of their servers and ports). Rename the folder to securitykiss. Structure should be like /home/user/ca.cert etc.

'nano /etc/openvpn/client.conf', edit server IP and port and past it. (It's almost only the default openvpn client.conf with minor changes.)

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
proto tcp
;proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote 91.121.208.218 443
;remote my-server-2 1194

# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca /home/user/securitykiss/ca.crt
cert /home/user/securitykiss/client.crt
key /home/user/securitykiss/client.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an
# important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server
# script in the easy-rsa folder will do this.
ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20

To initially start the VPN type:

sudo /etc/init.d/openvpn start
sudo openvpn /etc/openvpn/client.conf

After rebooting the VPN will be automatically started.

If you do not wish to start the VPN automatically for some reason: 'nano /etc/default/openvpn'

AUTOSTART=="none"

Connect to a Tor Gateway on your local network using PPTP VPN

For what this is useful: PPTP is used because it's very easy to configure and well supported by all kind of devices. Compared to a proper set up with a hardware gateway between the internet and the devices you want to torify it's less secure but doesn't require any kind of hardware or network layout changes.

Description

VPN (Virtual private network) is a method for users to connect to another network and access resources that can be seen from that network.

In this case, VPN is used to allow other users on your local LAN to connect and use your TorBox to connect to Tor with minimal configuration. Unlike Tor-VM where all network connections are forced through Tor or rejected workstations connected over PPTP are NOT automatically protected against network level leaks and application layer exploits.

We use PPTP here due to its wide install base (every installation of Windows since Windows 95 includes a client) and ease of installation. Be aware of the enormous security issues with PPTP.

Warning, PPTP should NOT be used with TorBox over the Internet, only for local trusted sources. See below for an OpenVPN implementation that allows use of Tor with minimal client configuration and should be secure enough to allow Internet connections (coming soon).

VPN: Bypassing Censorship & Enabling Free Speech

Ref: (How to Bypass Internet Censorship @ Flossmanuals.net)

Because VPN services [http://en.wikipedia.org/wiki/IP_tunnel tunnel] all Internet traffic, they can be used for e-mail, instant messaging,
Voice over IP (VoIP) and any other Internet service in addition to Web browsing, making everything that travels through the tunnel
unreadable to anyone along the way.

If the tunnel ends outside the area where the Internet is being restricted, this can be an effective method of circumvention,
since the filtering entity/server sees only encrypted data, and has no way of knowing what data is passing through the tunnel.
It has the additional effect of making all your different kinds of traffic look similar to an eavesdropper.

We use VPN here for its “tunnel” capabilities, so that others that you allow access, can take advantage of Tor via TorBox with a single connection.

Install PPTPd

(Tor-Gateway)

From your Tor-Gateway:

apt-get install pptpd

This will install and start the pptpd daemon on your Tor-Gateway. Verify its running:

ps aux | grep pptpd

Should show something similar to:

root      8357  0.0  0.5  10512   696 ?        Ss   17:26   0:00 /usr/sbin/pptpd

Stop it for the time being, while we configure it.

/etc/init.d/pptpd stop
Configure PPTP

(Tor-Gateway)

Configure PPTP settings:

nano /etc/pptpd.conf

Setup your localip and remoteip settings:

localip 192.168.0.1 #your eth1 address
remoteip 192.168.0.200-250 #a range of unassigned IP's

See the official documentation here.

Discussion:

This can be potentially confusing, as the documentation in the configuration files are not the best.
When you setup a PPTP connection, your Tor-Gateway will setup a virtual adapter (e.g. ppp0) which will output traffic sent from your client computer (those that connect to your server from your local LAN) to the Tor-Gateway and allow it to be routed through Tor. So if we want to use this virtual adapter just like a real adapter (e.g. eth0), we need to give it an IP address. That's what the localip option is.

remoteip is a bit simpler. It's the IP address (or addresses) that are assigned to the client's computer when they connect. They get their own virtual adapter, which needs its own IP address.

See the FAQ here for information.
For a simple overview of the VPN process see VPNClient @ Ubuntu Community Documentation.

localip, for simplicity should be the IP of your eth1, as Tor is already configured to listen here and we don't actually do any routing creating an IP address conflict.
remoteip, should be several IP's on your internal network (you should have as many IP's as potential clients, for example the “192.168.0.200-250” range above defines IP's for 50 clients)

(Advanced: localip and remoteip can be set to other networks, other subnets, etc. With our approach it doesn't matter what their IP's are, simply that they exist. It is in fact encouraged that such clients be assigned to a “quarantine” network. Since we don't have routing enabled, other subnets would prevent your client's from seeing each other and your already established “safe” LAN; where your Tor-Workstation lives. But! The torrc would need to be updated to listen on said addresses as well. Subneting in this fashion is beyond the scope of this document.)

Configure PPTP Options

(Tor-Gateway)

nano /etc/ppp/pptpd-options

Verify the following settings are configured as shown:

refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns <eth1 address>

Discussion:
See official documentation here.

refuse-pap: PAP style authentication, insecure, so we don't want to use it if we can help it.
refuse-chap: CHAP authentication, insecure.
refuse-mschap: MS-CHAP, insecure
require-mschap-v2: MS-CHAPv2, make sure that any connecting client must use this. It's as secure a we can get for a supported authentication method for PPTP.
require-mppe-128: Microsoft Point-to-Point Encryption, as secure encryption as we can get over PPTP, 128 bit is the maximum supported.
ms-dns: Use this address as the DNS server for connecting (Windows) clients.

Configure IPtables rules for client connect and disconnect

(Tor-Gateway)

The ip-up script is called on each connection by a PPTP client, so we can put special firewall rules here to help with Torifying the traffic through this interface.

nano /etc/ppp/ip-up

Add to the end:

#Firewall rules to add to route PPTP through TOR
#Tor's TransPort
TRANS_PORT="9040"

iptables -t nat -A PREROUTING -i $PPP_IFACE -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A PREROUTING -i $PPP_IFACE -p tcp --syn -j REDIRECT --to-ports $TRANS_PORT

The variable “$PPP_IFACE” is defined in the script (see the documentation at the beginning of the ip-up script) and resolves to the name of the interface established after a PPTP connection (e.g. ppp0).

Similarly the ip-down script is called when tearing down the connection. To prevent your iptables from getting polluted with redundant rules, we remove the previously configured rules here:

nano /etc/ppp/ip-down

Add to the end:

#Firewall rules to add to route PPTP through TOR
#Tor's TransPort
TRANS_PORT="9040"

iptables -t nat -D PREROUTING -i $PPP_IFACE -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -D PREROUTING -i $PPP_IFACE -p tcp --syn -j REDIRECT --to-ports $TRANS_PORT

Notice the addition of the -D instead of -A to the rule definitions. This tells iptables to Delete a rule with those parameters rather than Add one.

(See IPTables documentation)

Testing

(Tor-Gateway)

Start up your PPTP server:

/etc/init.d/pptpd start

(Client)

From a client on your network (preferably one outside of your Tor network, e.g. not your Tor-Workstation) connect to your VPN server.

Instructions for a variety of clients:

Linux (many flavors, direct from the pptp-client site)
How to configure a connection to a virtual private network (VPN) in Windows XP
VPNClient @ Ubuntu Community Documentation
Windows 7 VPN step by step guide

Now verify the connection on the gateway, after successfully connecting:
(Tor-Gateway)

ifconfig

Should show something like:

ppp0      Link encap:Point-to-Point Protocol
	inet addr:192.168.0.1  P-t-P:192.168.0.200  Mask:255.255.255.255
	UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1496  Metric:1
	RX packets:91 errors:0 dropped:0 overruns:0 frame:0
	TX packets:71 errors:0 dropped:0 overruns:0 carrier:0
	collisions:0 txqueuelen:3
	RX bytes:10080 (10.0 KB)  TX bytes:3622 (3.6 KB)
iptables -vnL -t nat

Should show:

Chain PREROUTING (policy ACCEPT 103 packets, 14589 bytes)
pkts bytes target     prot opt in     out     source               destination                                          
    0     0 REDIRECT   udp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0 udp dpt:53 redir ports 53
   22  1320 REDIRECT   tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0 tcp flags:0x17/0x02 redir ports 9040

(You may have more information displayed here depending on configuration, but the lines above should at least appear in your PREROUTING chain)

(Client)

On the client you should then be able to connect via Tor.

  • Browse to check.torproject.org and verify the “congratulations” message

Next disconnect from the VPN. On the server you should see several changes:
(Tor-Gateway)

  • ifconfig should no longer show any ppp interfaces
  • iptables -vnL -t nat should show no rules that involve any ppp interfaces

You can in fact test several client connections in this way. Each should get a new IP address (192.168.0.201, 192.168.0.202, etc), create a new virtual adapter (ppp1, ppp2, etc) and route through Tor via the Iptables commands (as above).

You can also attempt Leak Testing to verify that no packets are leaking through your VPN connection.

Hosting hidden services

Read first: TorBOX/SecurityAndHardening.

Hidden webserver

At your Tor-Gateway become root 'sudo su', edit your torrc 'nano /etc/tor/torrc' and add

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 192.168.0.2:5222

Check if your torrc is valid. '/etc/init.d/tor --verify-config'. Reload Tor '/etc/init.d/tor reload'. To find out your hidden service domain type 'less /var/lib/tor/hidden_service/hostname' and copy it to a safe place.

Now go to your Tor-Workstation. First we test if the Tor internet connection is working, for example start your Tor Browser and look if https://check.torproject.org/ shows "Congratulations. Your browser is configured to use Tor.". If that is working, test if you can also visit hidden services in general, for test you might use DuckDuckGo search engine's hidden service. Proceed only if that is working.

We'd recommend thttpd, a light http server. Do not use Apache, because it is not recommend on torproject.org and does leak critical information. As root 'sudo su', 'apt-get install httpd'. You have to edit the thttpd default configuration files.

Then 'nano /etc/default/thttpd' and change it.

# source: https://trac.torproject.org/projects/tor/wiki/doc/TorBOX

ENABLED=yes

See if the following configuration suits your needs. 'nano /etc/thttpd/thttpd.conf'

# source: https://trac.torproject.org/projects/tor/wiki/doc/TorBOX

# /etc/thttpd/thttpd.conf

port=5222
dir=/var/www
chroot
#data_dir=
symlinks
novhost
globalpasswd
user=www-data
cgipat=/cgi-bin/*
throttles=/etc/thttpd/throttle.conf
#host=
logfile=/dev/null
#charset=iso-8859-1
#p3p=
#max_age=

Inside /var/www you can create your index.html. 'nano /var/www/index.html'

<html>
<h1>Under Construction!</h1>
</html>

To start the server type '/etc/init.d/thttpd start'. On http://127.0.0.1 (default port 80) nothing should answer. Go to your browser and test if your webserver is locally reachable http://127.0.0.1:5222. If that is so, you should be also able to reach your hidden service url.

Congratulation, you've set up a hidden webserver.

Possible help: Nikto Web Scanner

Vidalia for TorBOX

You have two possibility to get Vidalia. 1. Vidalia on the Host and 2. Vidalia on the Tor-Gateway. Each option has it's pros and cons, we'll discuss here.

An alternative could be Arm.

1. Vidalia on the Host

Ok, this is an ugly hack, but it works. Vidalia can be installed on the host, in this example on a Windows host but you can most likely do it also on a Linux host. We have to 'trick' Vidalia because Vidalia really wants to start Tor.

You will be able to stop Tor using Vidalia, but not be able to start it again. Restarting Tor has to be done manually in console or ssh. "Start proxy application when Tor starts" will probable work (untested) but it will start it on the host and not on the Tor-Gateway. What also won't work are all settings which modify torrc, because our torrc will be just a dummy one and the real torrc is inside the Tor-Gateway. All settings in the settings, network tab won't work. Neither the "Sharing/Setup Relaying" tab will work (there will be instructions how to do it manually in torrc for the Tor-Gateway). Services tab will also not work, this is covered above under Hosting Hidden Services. The "Start Tor" button will actually not start Tor, but connect to the Control Port inside the Tor-Gateway. "View the network", "Use a New Identity" and "Message Log" should be functional.

  1. You need to ensure yourself, that port 9051 is firewalled on your host. It must not be accessible from the internet.
  2. Create a folder Vidalia somewhere you like it. Ensure that your current user account has the neccessary rights read, create, modify.
  3. Grab some dummy exe, for example cmd.exe from C:\Windows\System32\cmd.exe and copy it to your new Vidalia folder.
  4. Login as root 'sudo su'. Go to your Tor-Gateway and type in console.
    tor --hash-password password
    

This will result in something like

16:E61CFDC2FF3FDCDE605D8EDC3631F268B554612B0721E99F95588282B5

copy it into the clipboard.

  1. 'nano /etc/tor/torrc' and add
    ControlPort 9051
    ControlListenAddress 10.0.2.15:9051
    HashedControlPassword 16:E61CFDC2FF3FDCDE605D8EDC3631F268B554612B0721E99F95588282B5
    
  1. 'nano /etc/firewall.sh' and look out for the following
    # Allow incoming SSH connections on the external interface
    iptables -A INPUT -i $EXT_IF -p tcp --dport 22 -j ACCEPT
    

and add additionally the following below

# Allow incomming Tor ControlPort connections on the external interface
iptables -A INPUT -i $EXT_IF -p tcp --dport 9051 -j ACCEPT
  1. Then go to your host and create a file named 'control_auth_cookie' inside your Vidalia folder. Insert the password only, this example we used "password". Choose your secure password. control_auth_cookie has no file extension, be sure that Windows will normally show you file extensions (like .exe, .pdf...), otherwise you will be probable unable to create a file without extension.
  1. We need a start file, otherwise Vidalia will use the default documents and settings folder. Call it 'vidalia.bat' and create it inside your Vidalia folder. The content of vidalia.bat must be
    start do_not_start.exe --datadir .\\
    
  1. And of course you will be needing the Vidalia binaries. Download the Tor Browser Bundle for your platform. Go to '\Tor Browser\App\' and copy the following files into your Vidalia directory.
    libeay32.dll
    libgcc_s_dw2-1.dll
    libgnurx-0.dll
    mingwm10.dll
    QtCore4.dll
    QtGui4.dll
    QtNetwork4.dll
    QtXml4.dll
    ssleay32.dll
    vidalia.exe
    

tor.exe and tor-resolv.exe will not be needed (we have our own dummy tor.exe).

  1. Rename vidalia.exe to do_not_start.exe.
  1. Create a file called 'vidalia.conf' inside your Vidalia directory. The content must be
    [Tor]
    TorExecutable=.\\tor.exe
    Torrc=.\\torrc
    DataDirectory=.\\
    UseRandomPassword=false
    ControlPassword=password
    Changed=true
    ControlPort=9052
    ControlAddr=127.0.0.1
    
  1. Create a file torrc inside your Vidalia directory, leave it empty, it's just another dummy file for Vidalia's fate.
  1. In the Tor-Gateway VM network settings. Set up Port Forwarding: within the "Adapter 1" tab click "Advanced", then Port Forwarding. Insert a new rule as follows: Name: Vidalia; Protocol: TCP; Host IP: 127.0.0.1; Host Port: 9052; Guest IP: leave blank; Guest Port: 9051
  1. That's it. From now you can vidalia.bat. For your convinience create a shortcut of vidalia.bat on your desktop.

((Optional, for debugging if you have problems.
We test if the IP/Port is reachable from the host. 'telnet 192.168.1.5 9051', press enter should say "514 Authenication required."))

((Vidalia FAQ))

((I hope in near future, we will have a binary distribution of this.))

2. Vidalia on the Tor-Gateway

Install a "minimal" desktop environment on the Tor-Gateway:

sudo apt-get install xinit xterm openbox vidalia

You'll be asked to add your user to the debian-tor group. Do so! To apply this change you need to log out (type 'exit') and log in again. Then use 'startx' from the console to launch the graphical desktop. Right-click on the desktop to open the menu, open a terminal and from that launch vidalia. A more user-friendly graphical environment would drastically increase RAM requirements and attack surface.

Do not be tempted to use Tor-Gateway as a client OS! Also remember that anything you do on the gateway is NOT routed through Tor.

Arm - "anonymizing relay monitor"

This feature is activated on Tor-Gateway 0.2.0 and above.

Instead of Vidalia you could also try arm which is a console program. Install with:

sudo apt-get install tor-arm 

Footnote: It may complain about torrc valuse differing, this is a bug in arm.

How to safely transfer files between host, gateway and tor-workstation

Using filesharing built into the VM isn't very secure. Between the gateway and the host you can use ssh and scp but the tor-gateway is firewalled tightly (and you should leave it that way). A secure and quick way to transfer files to the client vm is to use iso files: On the host install genisoimage:
sudo apt-get install genisoimage
To create an iso "files.iso" containing the content of "folder":
mkisofs -o files.iso /path/to/folder
Now attach the iso to the VM. Mount it with
sudo mount /dev/sr0 /media/cdrom

This is intentionally one-way as the Tor-Workstation is inherently untrusted and should remain isolated to prevent side-channel attacks and covert channel leaks.

TorBOX implementation with just a single VM (Tor runs on host)

More info on TorBOX/OneVM

Using (private) (obfuscated) bridges

More info on TorBOX/bridges

Hosting a (private) (obfuscated) bridge or (exit) relay

You can still volunteer to Tor and host a bridge, private bridge, obfuscated bridge, private obfuscated bridge, middle node or exit relay when you are using TorBOX. Either inside the Tor-Gateway or directly on the host.

Inside the Tor-Gateway

Simply follow all the usual instructions given on torproject.org inside the Tor-Gateway just as you would, if Tor wouldn't run inside a virtual machine. The only additional thing to do is to set up a port forwarding from the host to the virtual machine. That is simple. For a similar example see Step 3 – How To Install - Install and Configure Tor-Gateway, under 'Set up Port Forwarding'. Just exchange the name and the ports, the rest is the same.

What's left are the firewall rules. On the Tor-Gateway 'sudo nano /etc/firewall.sh' and look out for

# Allow incoming SSH connections on the external interface
iptables -A INPUT -i $EXT_IF -p tcp --dport 22 -j ACCEPT

below that simply add similar

# Tor
iptables -A INPUT -i $EXT_IF -p tcp --dport YOURPORT -j ACCEPT

On the host

And if you do not like using the Tor-Gateway for this purpose, you can still host it directly on the host, simply follow the usual instructions on torproject.org.

Hide the fact that you are using Tor/TorBOX

Depending on how restricted your area is and how paranoid you are, you may want to hide the fact from your provider, that you are a Tor user. That's very tricky to archive. Be very careful. Here are some tips:

TorBOX users are most likely Tor power users. They are more paranoid then normal Tor users. And adversaries might ask themselves why. TorBOX users most likely host hidden services or do other fancy stuff over Tor.

Use either private and obfuscated bridges or a VPN/SSH proxy. It's most secure if you combine both ways.

Warnings

  • Download Tor through a trusted internet service provider (in your [home] country) or through SSH or VPN (or before entering a hostile environment).
  • Setup the SSH/VPN tunnel or the private obfuscated bridges first. (Depending on what you want to use, read below.)
  • Remove your internet connection while installing. (Tor starts and connects automatically after installing the .deb.)
  • If you run apt-get update/upgrade on the Tor-Gateway this will leak that you are using the torproject repository! Activate #OptionalFeatureNr.1# in ~/tor-gateway.sh to download all updates over Tor and to prevent any non-Tor emissions. If you keep care, to tunnel Tor through SSH or VPN, there will be no other traffic, except traffic to SSH or VPN.

Using a Proxy

Impossible! (The connection between you and your proxy is unencrypted. That goes for all proxies, http, socks4, socks4a, socks5.) Your ISP could still see, that you are connecting to the Tor network.

Using a SSH or VPN

See warnings above first. Tunnel all Tor related traffic first through a VPN or SSH server, this will hide the fact that you use Tor from your ISP. If the server is outside a national firewall this is also a way to circumvent Tor censorship.

If you do not trust any SSH or VPN providers, then anonymously host your own in a safe place.

Using private and obfuscated bridges

See warnings above first. Set up Tor to use private and obfuscated bridges. This makes it harder for ISPs and national firewalls to detect and block Tor but it does not prevent a dedicated adversary to find out that you are using Tor (research is ongoing, see obfsproxy).

TorBOX on Bare Metal

Using hardware instant of virtual machines. More secure. See Bare Metal Hints.

Anonymous 3G modem

Improves anonymity. See anonymous 3G modem.

Anonymous wifi adapter

Improves anonymity. See anonymous wifi adapter.

Other Anonymizing Networks

It's possible to use other anonymizing networks in together with TorBOX. Either in addition (tunneled through Tor) or as a replacement for Tor. See Other Anonymizing Networks.

Tunneling UDP over Tor

The Tor software does not support UDP itself yet. TorBOX provides a limited workaround for using UDP anyway, in the best possible secure manner.

VPN method

Read first: Tor Plus VPN and TorBOX VPN disclaimer.

Install rdate for UDP and TCP testing.

sudo apt-get install rdate

Install lynx (console browser).

sudo apt-get install lynx-curl

Test if your TorBOX setup is working in general.

lynx check.torproject.org

Which should show "Congratulations. Your browser is configured to use Tor.".

Before we setup the VPN, you should make yourself with rdate familiar. The command line switch -p results in just showing the date and time, without setting it. -u uses UDP instant of TCP (default)

Commands for UDP testing are.

rdate -u -p time.u.washington.edu
rdate -u -p time.nist.gov
rdate -u -p ptbtime1.ptb.de

Your tests should reveal, that without a VPN, you can run TCP over Tor (drop the -u command line switch), but not UDP.

Install OpenVPN.

sudo apt-get install openvpn

Obviously a VPN provider is required. For testing purposes usaip.eu was used. They have been chosen, because they were free and didn't block the tested outgoing UDP port. The free version of usaip.eu can probable only be used for testing purposes, as it's only a test version, which force disconnects every 7 minutes. For longer use you'll probable need an other VPN account. At the moment we are not aware of any free VPN accounts fulfilling the requirements. (1. Possible to connect to the VPN over TCP, because Tor does not support UDP. 2. Not blocking outgoing UDP, as this is, what we want to tunnel.)

Download the usaip.zip. It contains the OpenVPN configuration files. Unpack. Open a shell and get into the folder 'cd usaip'. List all files 'dir'. Connect to a VPN, for example:

sudo openvpn /home/user/eu-luxemburg.ovpn

The page stated, the password was 'demo', password also 'demo'. Wait until it's connected. (Will show "Initialization Sequence Completed")

Open a new shell and check if you can still connect to check.torpoject.org. 'lynx check.torproject.org' This time it should answer "Sorry. You are not using Tor." (Because you are now connected to the VPN.)

Test rdate again, first in TCP mode, then in UDP mode. Both should work.

SSH method

In theory we can also use SSH servers to tunnel UDP over Tor. Unfortunately we can't provide instructions here. Free SSH services are rarely available, that makes developing such as solution impossible. The existing free SSH services are blocking certain ports, which does not make this easier as well. Even though SSH can provide a socks5 proxy, it is not capable of providing support for tunneling UDP itself. Extra software installed on the client, and even worse on the server is required (needs root). Most admins will not do this. The link in the instructions are most likely only useful for you, if you have your own server. But even then, you are probable better off, using the VPN method.

socks5 proxy method [defunct / in development / needs help]

Not finished/working/tested yet. Status: TCP working. UDP not working.

Using redsocks as socksifier. Currently testing using 'JonDo – the IP changer' premium, with socks5 proxy support. (Get a free testcode). This example configuration will be migrated to a free service, as soon we have found one.

Installation

Open a terminal on your Tor-Workstation...
We need to install git. (To download the source. Unfortunately there is no Ubuntu package yet.)

apt-get install git

Install dependencies for compiling.

apt-get install libevent-dev build-essential

Go into your home folder.

cd /home/user

Get the source code.

git clone https://github.com/darkk/redsocks/

Join the source folder.

cd redsocks

Compile.

make

Add a new user 'luser'.

adduser luser

'nano fw.sh' and insert

# You can also control that in more precise way using `gid-owner` from
# iptables.
groupadd socksified
usermod --append --groups socksified luser
iptables -t nat -A OUTPUT -p tcp -m owner --gid-owner socksified -j REDSOCKS

# Create new chain
iptables -t nat -N REDSOCKS

# Ignore LANs and some other reserved addresses.
# See http://en.wikipedia.org/wiki/Reserved_IP_addresses#Reserved_IPv4_addresses
# and http://tools.ietf.org/html/rfc5735 for full list of reserved networks.
iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN

# Anything else should be redirected to port 12345
iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345

# UDP rule
iptables -t nat -A REDSOCKS -p udp -j REDIRECT --to-ports 10053

# Any tcp connection made by `luser' should be redirected.
iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner luser -j REDSOCKS

# Now you can launch your specific application with GID `socksified` and it
# will be... socksified. See following commands (numbers may vary).
# Note: you may have to relogin to apply `usermod` changes.
#luser$ id
#uid=1000(luser) gid=1000(luser) groups=1000(luser),1001(socksified)
#luser$ sg socksified -c id
#uid=1000(luser) gid=1001(socksified) groups=1000(luser),1001(socksified)
#luser$ sg socksified -c "firefox"

# If you want to configure socksifying router, you should look at
# doc/iptables-packet-flow.png and doc/iptables-packet-flow-ng.png
# Note, you should have proper `local_ip' value to get external packets with
# redsocks, default 127.0.0.1 will not go. See iptables(8) manpage regarding
# REDIRECT target for details.
# Depending on your network configuration iptables conf. may be as easy as:
### iptables -t nat -A PREROUTING --in-interface eth_int -p tcp -j REDSOCKS

Make executable.

chmod +x fw.sh

nano 'redsocks.conf' and insert

base {
	// debug: connection progress & client list on SIGUSR1
	log_debug = on;

	// info: start and end of client session
	log_info = on;

	/* possible `log' values are:
	 *   stderr
	 *   "file:/path/to/file"
	 *   syslog:FACILITY  facility is any of "daemon", "local0"..."local7"
	 */
	log = stderr;
	// log = "file:/path/to/file";
	// log = "syslog:local7";

	// detach from console
	daemon = off;

	/* Change uid, gid and root directory, these options require root
	 * privilegies on startup.
	 * Note, your chroot may requre /etc/localtime if you write log to syslog.
	 * Log is opened before chroot & uid changing.
	 */
	// user = nobody;
	// group = nobody;
	// chroot = "/var/chroot";

	/* possible `redirector' values are:
	 *   iptables   - for Linux
	 *   ipf        - for FreeBSD
	 *   pf         - for OpenBSD
	 *   generic    - some generic redirector that MAY work
	 */
	redirector = iptables;
}

redsocks {
	/* `local_ip' defaults to 127.0.0.1 for security reasons,
	 * use 0.0.0.0 if you want to listen on every interface.
	 * `local_*' are used as port to redirect to.
	 */
	local_ip = 127.0.0.1;
	local_port = 12345;

	// listen() queue length. Default value is SOMAXCONN and it should be
	// good enough for most of us.
	// listenq = 128; // SOMAXCONN equals 128 on my Linux box.

	// `max_accept_backoff` is a delay to retry `accept()` after accept
	// failure (e.g. due to lack of file descriptors). It's measured in
	// milliseconds and maximal value is 65535. `min_accept_backoff` is
	// used as initial backoff value and as a damper for `accept() after
	// close()` logic.
	// min_accept_backoff = 100;
	// max_accept_backoff = 60000;

	// `ip' and `port' are IP and tcp-port of proxy-server
	// You can also use hostname instead of IP, only one (random)
	// address of multihomed host will be used.
	ip = 127.0.0.1;
	port = 4001;


	// known types: socks4, socks5, http-connect, http-relay
	type = socks5;

	// login = "foobar";
	// password = "baz";
}

redudp {
	// `local_ip' should not be 0.0.0.0 as it's also used for outgoing
	// packets that are sent as replies - and it should be fixed
	// if we want NAT to work properly.
	local_ip = 127.0.0.1;
	local_port = 10053;

	// `ip' and `port' of socks5 proxy server.
	ip = 127.0.0.1;
	port = 4001;
	//login = username;
	//password = pazzw0rd;

	// kernel does not give us this information, so we have to duplicate it
	// in both iptables rules and configuration file.  By the way, you can
	// set `local_ip' to 127.45.67.89 if you need more than 65535 ports to
	// forward ;-)
	// This limitation may be relaxed in future versions using contrack-tools.
	dest_ip = 8.8.8.8;
	dest_port = 53;

	udp_timeout = 30;
	udp_timeout_stream = 180;
}

dnstc {
	// fake and really dumb DNS server that returns "truncated answer" to
	// every query via UDP, RFC-compliant resolver should repeat same query
	// via TCP in this case.
	local_ip = 127.0.0.1;
	local_port = 5300;
}

// you can add more `redsocks' and `redudp' sections if you need.

Starting

Start redsocks.

./redsocks

Enable the firewall.

sudo ./fw.sh

Using

Switch to user 'luser' and use your UDP dependent applications.

Secondary DNS resolver

Normally Tor is used for DNS resolution. If you suspect a Tor exit node to tamper with DNS, you can get a second opinion from another non-Tor DNS server.

You shouldn't other DNS resolvers than Tor over an extended amount of time. Although it's technically possible to replace DNS resolution completely (not using Tor for DNS resolution anymore), that is not recommend. That would add too much power to a single DNS server. Using a permanent DNS server is not recommend as not using a permanent Tor exit node.

DNSCrypt by OpenDNS

DNSCrypt is not yet available as a Linux version.

httpsdnsd by JonDos

Source: anonymous-proxy-servers.net and also use it as a more verbose tutorial, but keep in mind that their tutorial is JonDonym specific, while this tutorial is Tor specific.

Everything inside your Tor-Workstation.

Installation

Install dependencies.

sudo apt-get install libnet-ssleay-perl libnet-server-perl libnet-dns-perl libxml-simple-perl liblog-log4perl-perl

Download httpsdnsd. (See source above in case download link changed.)

wget https://anonymous-proxy-servers.net/downloads/httpsdnsd.tar.bz2

Unpack.

Go into the httpsdnsd folder.

cd httpsdnsd

Install httpsdnsd. 1

1 (It contains also a uninstall.sh, if you want to uninstall it later.)

sudo install.sh

Add a new user for httpsdnsd.

sudo adduser --system --disabled-password --group httpsdns_daemon

Create a firewall script.

nano dns-fw.sh

Insert these firewall rules.

# Flush old rules
iptables -F
iptables -t nat -F
iptables -X
# Redirect DNS traffic.
iptables -t nat -A OUTPUT -p udp -m owner --uid-owner anonuser --dport 53 -j REDIRECT --to-ports 4053
# Accept connections to the local proxy.
iptables -t filter -A OUTPUT -p udp -m owner --uid-owner anonuser --dport 4053 -j ACCEPT
# Drop all other traffic for anonuser.
iptables -t filter -A OUTPUT ! -o lo -m owner --uid-owner anonuser -j REJECT

Install polipo.

sudo apt-get install polipo

Open the polipo configuration file.

nano /etc/polipo/config

Add the following to your polipo configuration file. Note Identity correlation through circuit sharing and change the port from 9100 to something else.

# change...
socksParentProxy = 192.168.0.1:9100
diskCacheRoot=""
disableLocalInterface=true

Restart polipo to enable the changes.

sudo /etc/init.d/polipo restart

Polipo is now listening on 127.0.0.1:8123. 2

2 For debugging you can enter this IP/port into Tor Browser as http proxy and try if you can still reach check.torproject.org. Deactivate after testing.

Starting

Run httpsdnsd. 1 2 3

1 For debugging, kill httpsdnsd and drop the --runasdaemon.
2 Run 'httpsdnsd --help' or 'man httpsdnsd' for help.
3 --https_proxy_port=8123 will redirect queries to port 8123, where polipo is listening. This is necessary because Tor offers a socks proxy and httpsdnsd requires a http proxy. Polipo translates from http to socks.

sudo httpsdnsd --https_proxy_port=8123 --runasdaemon

Activate the firewall. Shouldn't show any errors.

sudo ./dns-fw.sh

Using

Open a console and switch to anonuser.

su anonuser

Resolve DNS.

nslookup check.torproject.org