(disposable) sys-tor: Tor in Qubes (plain & simple)

I finally found some time and motivation to put together some salt scripts I’m using for many years now. I was actually just waiting for Qubes to bring back good old sys-tor, but here it is.

So, what is this exactly?
The tar file contains some salt scripts + configuration to create a disposable VM (sys-tor) that routes all network traffic through Tor. That’s it. Nothing fancy, no snakeoil, just routing traffic through Tor. This way, any other VM’s traffic (like from your favorite browser, your mail client, your torrent client, your VPN qube, ..) can easily go through Tor.

How set it up?

  • extract the tar archive and copy it to dom0 under /srv/salt
  • adjust config/torrc.user to your liking - do adjust the EntryNodes setting at least!
  • run three commands in dom0 to set up and configure sys-tor:
qubesctl state.apply sys-tor.create
qubesctl --skip-dom0 --targets=sys-tor-template state.apply sys-tor.install
qubesctl --skip-dom0 --targets=sys-tor-dvm state.apply sys-tor.config
  • start sys-tor and set it as netvm for some other VM.

Will this bring magic, bulletproof, 100% anonymity to your application? No, it just routes traffic through Tor. And it’s so simple that it can be inspected with minimal effort, which makes it harder for stupid mistakes to hide in complexity.

EDIT: this salt formula is now part of a larger set of formulas: see ra-qubes-salt-formulas/sys-tor at main · ra--/ra-qubes-salt-formulas · GitHub

1 Like

" Using a Disposable for the Whonix-Gateway results in non-persistent entry guards to the Tor network; behavior unlike the default configurations for Whonix, Tor, and the Tor Browser Bundle. Mathematically speaking, end-to-end correlation attacks are more likely to succeed when a user chooses many random entry and exit points in the Tor network, rather than semi-permanent entry guards which are only rotated every few months. [21] [22]"

Could you elaborate ?

Not sure on what exactly, but I’ll try.
The goal of disposable VMs is to increase security. An infiltrated VM is bad obviously, but even more so when the attack is persistent. A disposable VM reduces the persistence of a potential attack until the next reboot of the VM.
Guard nodes in the Tor network are the only nodes that can observe the real IP addresses of users, which makes them special. Keeping a (trustworthy) guard node for a long time reduces the probability for (various types of) attackers to gather the real IP addresses of users.
So, it’s good to have both, a disposable sys-tor VM and long-living guard nodes.

1 Like

@rabla

Does this support qubes firewall?

Also, in the other thread you wrote:

Whonix is such a crap

Could you elaborate? (repeating my question)

1 Like

I haven’t tried it and I’m not using sys-tor for firewalling purposes. Generally speaking, I think it’s good to separate concerns and have a dedicated firewall VM, like sys-torfw for example, which uses sys-tor as netvm and implements firewalling (and nothing else). But maybe using sys-tor as firewall too just works out of the box. I’d be curious to know if you test it.

answered here: Guide for disposable sys-whonix replacement? - #10 by rabla

If any one wants a packaged version I’ve published for a long time
now. Debian only, available from 3isec,
3isec-tor.

There’s a README on GitHub - GitHub - unman/3isec-tor: Tor proxy service for Qubes · GitHub

It runs in fairly small memory, supports qubes firewall, and uses tor
from TorProject.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

4 Likes

@unman

Could you make that an official Qubes package?

Isn’t sys-whonix already disposable?

user@dom0:~ > qvm-prefs sys-whonix klass
AppVM

Can confirm. Mine runs on 200MB / 1cpu and mostly sits at 0-2 percent, despite a small peak to about 30% on start it so far runs great. Can also add, and I can’t for the life of me explain why, that it is faster. If I do an update or upgrade over Whonix-GW and then at the same time update another (identical ie debian) VM. The TOR-VM does the update in usually half the time. This could be explained by random speeds of nodes etc. But this happens again and again, and never the other way around (whonix-gw faster than tor-vm).
I would like to see if anybody else experiences this? If it can be reproducible, explainable or is it just me? Perhaps I am missing some torrc config on whonix-gw? I don’t know.

Unfortunately, I can’t, although I am willing to.

Perhaps you would like to join the dedicated thread about TorVM and explain there how you made it work as it still doesn’t work for me.