wiki:doc/UsingTorWithVservers

Version 7 (modified by karsten, 6 years ago) (diff)

Name changed from UsingTorWithVservers to doc/UsingTorWithVservers

Overview

People use Tor to hide their identity. Unfortunately, lot of web pages are using active content (JavaScript, Flash, ...) which might compromise things like:

  • local IP address
  • local hostname
  • username
  • scanning local IPs (e.g. 'telnet mail 25' tells often the hostname of local mailer)

either by normal functionality or by exploiting leaks. Program bugs might compromise anonymity too e.g. by doing DNS queries.

An obvious way for fixing this problem might be a separate machine used only for anonymous browsing. A physical machine is overkill in most cases but virtualisation technologies opens another way. Popular ones are:

  • VMWare, Qemu
  • XEN
  • VServer, Virtuozo, SUN-Zones, BSD-Jails

This page describes how to setup VServers used for anonymous browsing and chatting:

Definitions

When having a VServer we have to differ between:

Host
that's the physical machine which provides storage, network and CPU power
Guest
that's the environment were your applications are running.
Applications
that are programs which are connecting the internet; usually they are full of bugs and features which are compromising your identity
User
that's the person who wants to hide his/her identity. The user interacts with the host usually through X11.

Creating the Guest

  1. Create the VServer: {{{

# vserver <some-name> build ...}}} Please see the VServer documentation about the possible options

  1. Randomize the information about your system by changing/creating the following entries in /etc/vservers/.../uts:
    • domainname: the information set there will be given out in the Guest by the hostname -y command; you can set something random like nsa.gov there
    • nodename: the information set there will be given out by the hostname command; use something like workplace-25326.nsa.gov there
    • release: when using custom kernels, they contain often an identifier leading back to you. Set something like 2.6.15.4 there. Number should not be too low or too because some programs might refuse to work then.
  2. Information about the interface set up in /etc/vservers/.../interfaces/0/ip might get compromised; you should assign a common local ip like 192.168.0.5 and ensure that it is working in your network
  3. Hashify the vserver to save space and memory; that is especially important when you have multiple Guest systems (with the same distribution). See XXXXX for details
  4. Temporary space (/tmp, /var/tmp) should be either on encrypted partitions or in a tmpfs. Do this e.g. by adding something like {{{

none /var/tmp tmpfs size=128m,mode=1777}}} to /etc/vservers/.../fstab. NOTE: when tmpfs is used, content will vanish at Guest restart.

See below for comments about encrypted swap and additional, encrypted fileystems for user's home.

NEVER:

  • use domain/hostnames which can point back to you (e.g. no subdomains or hosts within domains registered by you)
  • use public visible IPs

Setting up the Guest

  1. install your favorite applications and a window manager e.g. with {{{

# vyum <some-name> install firefox seamonkey}}} on the host.

  1. as User on the Host, create an ssh keypair used only for this Guest.
  2. enter the Guest with {{{

# vserver <some-name> enter}}}

  1. create an user with a random name there; this name should not point back to you; see below for comments about encrypted home partitions
  2. put the public ssh key into $HOME/.authorized_keys with $HOME being the homedirectory of the newly created user

NEVER:

  • setup DNS (/etc/resolv.conf) in the Guest; we will use only IPs and the Tor proxy
  • share SSH keys; when $HOME/.authorizedkeys has same content on a public machine and on the Guest, your identity might get revealed
  • choose a username in the Guest which is in some relation to you
  • use configuration management systems like cfengine to maintain Guest