## Creating a netvm (sys-tor) in Qubes OS that routes all traffic of connected VMs through the Tor network.

:::danger
**Known issues**
* Do not use this guide if you seriously rely on anonymity!
* Only Fedora 29 is tested as a template, but it should be possible to apply this guide to other Linux distributions such as Debian with reasonable effort.
:::

#### Make sure that required packages are installed in the Fedora 29 template:

sudo dnf install tor iptables nyx
sudo systemctl disable tor.service

#### Append the following line to */etc/tor/torrc* in the Fedora 29 template:
`%include /rw/config/torrc`

#### Create the *sys-tor* netvm (in dom0) that is based on a Fedora 29 template:

qvm-shutdown --wait fedora-29
qvm-create --template fedora-29 --class AppVM --property maxmem=0 --property memory=512 --property netvm=sys-firewall --property provides_network=True --property vcpus=1 -l black sys-tor
qvm-start sys-tor

#### Create the file */rw/config/torrc* (in sys-tor) with the following content:

AutomapHostsOnResolve 1
SOCKSPort 0
VirtualAddrNetwork 10.192.0.0/10
TransPort 0.0.0.0:1080
DNSPort 0.0.0.0:1053
ControlPort 9051
CookieAuthentication 1

#### Modify the file */rw/config/rc.local* (in sys-tor) such that it reads as follows:

#!/bin/sh
iptables-restore < /rw/config/iptables.conf
ip6tables-restore < /rw/config/ip6tables.conf
systemctl start tor

#### Create the file */rw/config/iptables.conf* (in sys-tor) with the following content:

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [4:218]
:OUTPUT ACCEPT [1:52]
-A PREROUTING -i vif+ -p tcp -j REDIRECT --to-ports 1080
-A PREROUTING -i vif+ -p udp -m udp --dport 53 -j REDIRECT --to-ports 1053
-A OUTPUT -p udp -m udp --dport 53 -j REDIRECT --to-ports 1053
-A OUTPUT -o lo -j RETURN
-A OUTPUT -m owner --uid-owner toranon -j RETURN
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 1080
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i vif+ -p tcp -m tcp --dport 1080 -j ACCEPT
-A INPUT -i vif+ -p udp -m udp --dport 1053 -j ACCEPT
-A OUTPUT -m conntrack --ctstate INVALID -j DROP
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m owner --uid-owner toranon -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -d 127.0.0.1/32 -j ACCEPT
COMMIT

#### Create the file /rw/config/ip6tables.conf with the following content (in sys-tor):

*nat
:PREROUTING DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT DROP [0:0]
:POSTROUTING DROP [0:0]
COMMIT
*raw
:PREROUTING DROP [2:112]
:OUTPUT DROP [33:1944]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j DROP
COMMIT

#### Restart sys-tor (in dom0)

qvm-shutdown --wait sys-tor
qvm-start sys-tor

:::success
That's it! Now all traffic of VMs is routed through the Tor network as soon as their netvm is set to sys-tor.
:::

### Further information

#### Fix clock synchronization issue after suspend/resume cycle (in dom0)
tor depends on a somewhat accurately synchronized clock. If you use suspend/resume, the clock in sys-tor may not be synchronized accurately enough for tor to work. To work around that issue, create a file */lib/systemd/system-sleep/99_settorclock.sh* in dom0 with the following content:

#!/bin/sh
if [ "${1}" == "post" ]; then
  systemd-run qvm-run -q -n -u root sys-tor "/bin/date -s \"`/bin/date`\""
fi

And make that file executable:

chown 0:0 /lib/systemd/system-sleep/99_settorclock.sh
chmod 700 /lib/systemd/system-sleep/99_settorclock.sh

#### Monitoring and interacting with tor (on sys-tor)
Run *nyx* to monitor the state of tor and to interact with the tor process:
`sudo -u toranon nyx`

#### Mitigate traffic correlation attacks
Multiple *sys-tor*-like netvms can be used to mitigate traffic correlation attacks. I.e., it should be harder for an adversary, who monitors traffic exiting the Tor network, to correlate that particular applications run on the same host. To this end, clone the sys-tor netvm (in dom0):
`qvm-clone sys-tor sys-tor2`

Remove tor's state information in sys-tor2:

sudo systemctl stop tor
sudo rm -f /var/lib/tor/*
sudo systemctl start tor

Now, it is harder for an adversary, who monitors traffic exiting the Tor network, to correlate that particular applications (connected to *sys-tor* and to *sys-tor2*) actually run on the same host. Just make sure that you add *sys-tor2* to */lib/systemd/system-sleep/99_settorclock.sh* so that its clock is set as well after a suspend/resume cycle (see above).