Tor netvm leak?

I see connections to a Tor exit node from my sys-net qube…?
I thought I was going VPN -> Tor -> Internet
My routing looks like this:
whonix-ws -> sys-whonix -> vpn -> sys-firewall -> sys-net

Help please and thank you.

If that is your configuration then you should be creating Tor traffic and
the first hop will occur from your VPN provider. You trust the VPN
provider completely.
Unless you have taken steps to stop this, vpn, sys-firewall and sys-net
may all be generating traffic. (Hint - take steps to stop it.)
Another possibility is that the VPN provider itself uses a Tor exit
node.
You could test these: if you connect clear net to VPN, shutting down
whonix*, do you see any connection to exit node then?
If you connect clear to sys-firewall do you see connection to Tor exit
node then?

I will do some testing, but first can you tell me how to stop as much traffic as possible from my qubes? I run minimal templates, so not a lot of stuff should be generating noise.

Just block at firewall level -
depends on what you have, but something like :

iptables OUTPUT -P DROP
iptables -I OUTPUT -o lo -j ACCEPT

That blocks all OUTPUT traffic except local interface.
This will break some features, but will do for testing.

Alternate approach would be to identify Tor exit node (I assume you
have already done this and it’s just one), and log traffic to that IP

Consider making your sys-firewall or equivalent a disposable. It is just a tick in the Advanced settings with disposable none. You need some tools like iptraf-ng, etherape etc… to check for leaks. Have each VM connect through a different firewall VM.
Most likely there are not going to be any leaks since most attacks are on the internal VM at the hardware level specifically the display.
Idealy you’ll go through a server to check any leaks…

This is a test using a Tails USB to check your hardware for leaks that works sometimes. Create a HVM 2GB Ram and 2 cores. Plug your Tails USB and start (add bridges and proxies). There is a tutorial in the Documentation Section on how to connect. If your display freezes you have a problem…

^ discourse confuses me

but my post says you probaly have a leak from your vpn vm. this would mean your vpn qube is a passthrough for sys-whonix. you should configure the firewall for the vpn vm to only allow the vpns ip as a backup.

I changed all my sys-* Qubes to disposable but they still launch as normal appVMs if I don’t explicitly launch them from the appmenu.

I noticed that my sys-net Qube generates a lot of Tor circuits on boot but I only saw activity when I used apt as I only use .onion repos.
Of course I only use sys-net for local network stuff normally.
I tried to fix it by forcing it to use the UpdatesProxy, but I had some problems with that.
Related link: https://web.archive.org/web/20200904091907/https://old.reddit.com/r/Qubes/comments/agyune/how_to_use_update_proxy_on_standalonevm/

@unman not a pro with iptables, but at least that first command doesn’t work

@qubesnewb I followed tasket’s VPN Qube guide on GitHub, and I’m pretty sure the VPN Qube is leak-proof

Use the Debian templates instead of Fedora. I caught 2 entities able 2 poison Fedora. One from Virgina, US that used a Java install tool and one from the Carolina (red head research center ip witheld). I know this sucks but eventually you are going to get taken so bad that is time to wipe everything and make some changes. They even got me through a Samsung Smart TV (hdmi) because it was connected to Digital Cable. “The battle rages on” to quote Deep Purple.

I understand what you mean. I’ve had similar thoughts about wiping everything many times.
Are you saying that your Fedora non-sys-VMs got poisoned? Or sys-net?
I’ve been using Debian 10 minimal templates for everything for a while now.

how are you making the observations?

do you have tor installed in your sys-net template?

Set up a sys-corridor VM, somewhere between sys-whonix and sys-net (or sys-vpn, in your case). Corridor is a daemon that whitelists known Tor entry node addresses and blocks traffic to everything else, and is intended to prevent leaks.

http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Corridor#sys-corridor_Setup

http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/please-help-me-with-corridor-setup/10071#!

It’s even better if you can set it up on an external machine, such as a Raspberry Pi, ideally from the machine’s physical TTY (not SSH). Depending on your level of paranoia, you may want to buy a Raspberry Pi starter kit that includes an SD card with Raspbian preinstalled, to prevent any possibility of your local machine compromising the image.

PS: If you haven’t I recommend starting a thread on the Whonix forum too, since they’re probably more specialized in this sort of stuff.

With respect, that isn’t helpful in this case.
OP is concerned about a possible leak - telling him how to stop non Tor
traffic is good, but does not address the problem.
It’s like telling someone who has many small fires breaking out at
home that the solution is to install a sprinkler system. It’s treating
the effect and not the cause.

@unman … uhh, * hesitantly points at the quote again*

Well, I hate to say it, but welcome to computer security in 2020. When a hole is discovered in one patch, we just put another patch on over top of it. I digress.

Well, you’re right, but at the same time it’s like saying you don’t need a sprinkler system as long as you don’t catch the place on fire. Or you don’t need a hypervisor as long as there aren’t any bugs in the kernel. It’s partly a matter of personal philosophy, I guess.

I do take your point though, and yes, the root cause needs to be identified. Unfortunately I don’t really have any ideas to offer right now, hence why I didn’t address that.

@unman … uhh, * hesitantly points at the quote again*

Indeed, and in the context of the thread, @mother is responding to my
hint: " Hint - take steps to stop extra traffic"

Well, I hate to say it, but welcome to computer security in 2020. When a hole is discovered in one patch, we just put another patch on over top of it. I digress.

:frowning:

Well, you’re right, but at the same time it’s like saying you don’t need a sprinkler system as long as you don’t catch the place on fire. Or you don’t need a hypervisor as long as there aren’t any bugs in the kernel. It’s partly a matter of personal philosophy, I guess.

I do take your point though, and yes, the root cause needs to be identified. Unfortunately I don’t really have any ideas to offer right now, hence why I didn’t address that.

Let’s see what @mother comes up with from her testing.

Torsocks needs to be installed, and therefore also tor for using .onion repositories. I used Nethogs and iftop, but by default they only show open connections. Should look into collecting a log file. Or use other tools, like @i2p suggested. Nethogs show this info currently:

? root 192.168.x.x:47118-5.9.158.75:9001 0.011 0.021 KB/sec
? root 10.137.x.x:47118-5.9.158.75:9001 0.000 0.021 KB/sec

After killing and restarting sys-net:

192.168.x.x => customer.worldstream.nl 0b 212Kb 176Kb
<= 0b 1.22Mb 1.01Mb

192.168.x.x => ns395839.ip-176-31-103.eu 0b 24.6Kb 20.5Kb
<= 0b 483Kb 402Kb

192.168.x.x => condor2711.startdedicated.com 0b 76.6Kb 63.8Kb
<= 0b 392Kb 327Kb

192.168.x.x => static.158.121.47.78.clients.your-server.de 9.62Kb 60.6Kb 50.5Kb
<= 11.9Kb 312Kb 260Kb

192.168.x.x => [VPN.IP] 7.00Kb 5.55Kb 4.62Kb
<= 2.23Kb 10.6Kb 8.85Kb

192.168.x.x => [VPN.IP] 0b 1.78Kb 1.48Kb
<= 0b 5.58Kb 4.65Kb

192.168.x.x => tor.noreply.org 0b 1.51Kb 1.26Kb
<= 0b 3.31Kb 2.76Kb

192.168.x.x => [NetworkManager.DNS] 0b 993b 827b
<= 0b 1.63Kb 1.36Kb

192.168.x.x => 192.168.x.1 0b 0b 0b
<= 0b 0b 441b

0.0.0.0 => 255.255.255.255 0b 0b 437b
<= 0b 0b 0b

:: => ff02::16 0b 0b 51b
<= 0b 0b 0b

:: => ff02::16 0b 0b 48b
<= 0b 0b 0b

I also saw some connections to 243-65-15-51.instances.scw.cloud

And my router shows my sys-net connecting to these strange domains that are closed within approx. 1 minute. Pasting some of them here in case any of you can make sense of it.
Some of them HTTPS, some of them over Tor.

00:01:06 www.pyqj7ea.com 9001/tcp 5.35 KiB 63.37 KiB
00:01:00 www.oxn2pstlw.com 9001/tcp 5.96 KiB 64.27 KiB
00:01:00 www.ktmthe46xvmhcb6fnz2qneej.com https 4.18 KiB 44.81 KiB
00:01:00 www.rywhmxemfaebprzp6262.com https 4.12 KiB 43.34 KiB
00:01:10 www.6vmd25u4nr6biunzohjv.com 9001/tcp 4.39 KiB 44.92 KiB

It appears all VMs that have Tor installed like to connect to exit nodes.
sys-net is the most damaging though.
Will set up sys-corridor when I get the time.

I’m even more ocnfused by what you say.
Why do you have Tor installed in sys-net? If you do, why do you think it
is “damaging”? If you really have Tor traffic generated from sys-net I
would say you are doing something wrong. (No reason why you shouldn’t be
restricting traffic to Tor , like a Tor box, but in that case there’s
obviously nothing to worry about.)
corridor restricts output to Tor addresses - I cant see that it will
help you with whatever is troubling you here.

As always, can you step back and explain what the problem is -
originally you talked about Tor “leaks”. Can you be explicit about what
you think the security issue is or what the effect might be on your
privacy.

On the basis of what you say in this post, the solution would be : don’t
have Tor installed in any qube where you do not want to access Tor
nodes, entry or exit.
One solution I gave you is not to generate outbound traffic
from sys-net or sys-firewall.

Sounds like some VM’s are taken on some level. Just in general apt and synaptic are very poor choices for updates.

Not related to Qubes:
I see with Parrot which is under continuous attack. Do not use apt full-upgrade. Outside Qubes use gnome-software and update.
sudo apt install gnome-software
reboot
start gnome-software and use the update tab and reboot (it does not matter if the interface works well or not)

agree with unman…you failed to mention sys-net (or the template) has tor installed

…so what is the issue???

I have used a separate template for sys-net with tor removed and seems to work fine. It tried to initiate a connection with a Tor node after I tried to update once, but it got closed pretty quick.
I will do some more testing.

I want to hide my Tor usage from my ISP among others, that is why I’m worried about connections directly from sys-net.
Also looks like a widened attack surface.

I installed torsocks in my template to allow me to update or install packages via .onion repos from any StandaloneVMs/AppVMs based on it. I was not aware when I set out that connections to Tor would be made directly from VMs with it installed, in stark contrast to the UpdatesProxy which templates use.

Looks like I will leave it installed in most of my VMs since I cannot use apt remotely with .onion repos without it, forcing me to install it in the template and restart AppVMs or forcing me to switch to HTTPS repos till I install torsocks .

Forcing StandaloneVMs/AppVMs to use the UpdatesProxy would likely help here.

@i2p any way to make sys-firewall or any other sys-VM start as a disposable by default? And perhaps change the name conventions of generated sys-dispVMs?