Preventing non-Tor connections

rex52 · November 7, 2022, 6:07am

Until document how to route all traffic over Tor / how to disable Qubes default clearnet traffic · Issue #7586 · QubesOS/qubes-issues · GitHub is resolved Qubes users require a way of ensuring no non-Tor connections are made when they are working over Tor.

My current solution is to only have open the following qubes
anon-whonix → sys-whonix → sys-firewall → sys-net

And have the following firewall rules in sys-firewall and sys-net

sudo nft add chain ip filter OUTPUT ‘{ policy drop; }’
sudo nft add rule ip filter OUTPUT counter drop

sudo nft add chain ip6 filter OUTPUT ‘{ policy drop; }’
sudo nft add rule ip6 filter OUTPUT counter drop

These rules are added before sys-net is connected to any network.

Can anyone identify any issues with this?

I should add that this is done in addition to disabling update checking and making sure sys-net is not used as UpdatesProxy.

adw · November 7, 2022, 6:12am

Why is this part necessary?

rex52 · November 7, 2022, 6:42am

As it says in the linked GitHub issue nobody has documented what clearnet traffic is generated by the various VMs, at least not extensively.

When you are connecting to Tor, especially when moving between different networks, you do not want any clearnet connections to be made.

The firewall rules prevent any clearnet traffic other than DHCP which uses raw sockets so bypasses netfilter.

BEBF738VD · November 7, 2022, 9:16am

Read more about corridor here: Using corridor, a Tor traffic whitelisting gateway with Whonix ™

enmus · November 7, 2022, 8:57pm

Well, it doesn’t look like what is said in the original link

It is possible to configure Whonix-Gateway ™ ( sys-whonix ) to use corridor as a local proxy to establish the following tunnel:
User → corridor → Tor → Internet

BEBF738VD · November 7, 2022, 9:03pm

You should read the entire page:

Configure sys-whonix
To set Networking of sys-whonix to sys-corridor :

Qube Manager → left-click sys-whonix → right-click → Qube settings → Networking → sys-corridor → OK

The procedure is now complete.

enmus · November 7, 2022, 9:07pm

Thanks! I Started to read and trying to install corridor, so didn’t reach the point. Anyway, there is inconsistency on that page anyway right?

BEBF738VD · November 7, 2022, 9:10pm

The bit you quoted could be explained better, I agree.

Also, it may be useful to know that you don’t have to create it as a standalone. I got it working as a non-persistent qube (just create a template instead of a standalone, then a dispvm template and finally an appvm based on that).

enmus · November 7, 2022, 9:31pm

Well, I wouldn’t say “better”, but correct. Anyway…

Yes, it looked odd to me to create a standalone for anything that is service… And I couldn’t install it based on minimal (standalone based on minimal)

So, if I’m not using tor bridges, it should work immediately after install?

BEBF738VD · November 7, 2022, 9:34pm

Probably just missing a few packages

Yes, most likely

enmus · November 7, 2022, 9:46pm

Thanks. I’m not sure what’s with other prefs and features. like provides_network, etc…
What’s netVM of corridor? sys-firewall?

enmus · November 7, 2022, 10:02pm

Nope. Forwarding and snat not working

forwarding

user@sys-corridor:~$ sudo systemctl --no-pager status corridor-init-forwarding
��� corridor-init-forwarding.service - corridor's forwarding
     Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enabled; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/system/corridor-init-forwarding.service.d
             ������qubes-service.conf, qubes.conf
     Active: failed (Result: exit-code) since Mon 2022-11-07 16:52:36 EST; 1min 32s ago
       Docs: man:corridor(8)
    Process: 321 ExecStart=/usr/sbin/corridor-init-forwarding (code=exited, status=127)
   Main PID: 321 (code=exited, status=127)
        CPU: 0

Nov 07 16:52:36 localhost systemd[1]: Starting corridor's forwarding...
Nov 07 16:52:36 localhost corridor-init-forwarding[321]: /usr/sbin/corridor-i���nd
Nov 07 16:52:36 localhost systemd[1]: corridor-init-forwarding.service: Mai���/n/a
Nov 07 16:52:36 localhost systemd[1]: corridor-init-forwarding.service: Fai���de'.
Nov 07 16:52:36 localhost systemd[1]: Failed to start corridor's forwarding.

snat

user@sys-corridor:~$ sudo systemctl --no-pager status corridor-init-snat
��� corridor-init-snat.service - corridor's source NAT
     Loaded: loaded (/lib/systemd/system/corridor-init-snat.service; enabled; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/system/corridor-init-snat.service.d
             ������qubes-service.conf, qubes.conf
     Active: failed (Result: exit-code) since Mon 2022-11-07 16:52:37 EST; 3min 24s ago
       Docs: man:corridor(8)
    Process: 450 ExecStart=/usr/sbin/corridor-init-snat (code=exited, status=127)
   Main PID: 450 (code=exited, status=127)
        CPU: 0

Nov 07 16:52:37 sys-corridor systemd[1]: Starting corridor's source NAT...
Nov 07 16:52:37 sys-corridor corridor-init-snat[450]: /usr/sbin/corridor-init���nd
Nov 07 16:52:37 sys-corridor systemd[1]: corridor-init-snat.service: Main p���/n/a
Nov 07 16:52:37 sys-corridor systemd[1]: corridor-init-snat.service: Failed���de'.
Nov 07 16:52:37 sys-corridor systemd[1]: Failed to start corridor's source NAT.
Hint: Some lines were ellipsized, use -l to show in full.

As expected, neither disp-tor-browser can connect to tor when corridor is its netVM

enmus · November 7, 2022, 10:51pm

And, it works. iptables didn’t exist in minimal template. After installing it in template, everything OK.

rex52 · November 7, 2022, 11:27pm

Looks good. I wonder why it wouldn’t be mentioned as a temporary solution in the GitHub issue that I linked?

rex52 · November 8, 2022, 12:18am

Actually, I won’t be running Corridor. A second Tor running is very identifiable to a network observer.

unman · November 8, 2022, 4:00pm

Because it is not in any way a solution to that problem.
Blocking all output from sys-net and sys-firewall is a solution.
But, you should make sure that no other qubes are connected to
sys-firewall, and that services that run on sys-net/sys-firewall have
been moved below the Tor Proxy.
And - the iptables rules are inadequate - fine to block OUTPUT using
external interface(s) but you should still allow lo.
And - don’t use iptables - use nftables instead. (You’re using
nftables anyway, so use it properly.)

I never presume to speak for the Qubes team.

When I comment in the Forum or in the mailing lists I speak for myself.

BEBF738VD · November 8, 2022, 5:21pm

No need for a second tor instance running at the same time. You can either connect sys-whonix to it or if you know you’ll want to switch between a corridor instance and one unfiltered, create a sys-whonix-2 to connect to corridor and shut the main sys-whonix down when running. Possibilities are endless

rex52 · November 9, 2022, 4:39am

Corridor prevents all non-Tor traffic, that’s a pretty good solution in my eyes.

I’m not sure what you mean here? If they’re running in sys-net or sys-firewall then they are not going through the Tor proxy but that’s fine because they won’t have any outgoing traffic due to the firewall. Or are you saying move the services to VMs that do go through the Tor proxy? The main services are qubes-update-check and clocksync but you can get away without them when using this anonymous configuration.

Thanks.

Looks like nftables to me.

rex52 · November 9, 2022, 5:02am

Updated rules

sudo nft add chain ip filter OUTPUT ‘{ policy drop; }’
sudo nft add rule ip filter OUTPUT oifname “lo” counter accept
sudo nft add rule ip filter OUTPUT counter drop

sudo nft add chain ip6 filter OUTPUT ‘{ policy drop; }’
sudo nft add rule ip6 filter OUTPUT oifname “lo” counter accept
sudo nft add rule ip6 filter OUTPUT counter drop