Issue Setting up hidden services on Qubes

igijo · March 7, 2015, 4:33am

Steps taken so far:

Clone gateway template.
sudo nano /etc/tor/torrc
2a. HiddenServiceDir /var/lib/tor/hidden_service
2b. HiddenServicePort 80 WS-VM-IP**:80
sudo service tor reload.
sudo cat /var/lib/tor/hidden_service/hostname
4-error. cat: /var/lib/tor/hidden_service/hostname: No such file or directory.
4-debug-a: ls -la /var/lib/tor/hidden_service/
error: ls: cannot access /var/lib/tor/hidden_service/: Permission denied
4-debug-b: sudo chown debian-tor:debian-tor /var/lib/tor/hidden_service/
error: chown cannot access `/var/lib/tor/hidden_service/’: No such file or directory

**workstation appvm ip address

WhonixQubes · March 7, 2015, 8:51am

Here is how to setup a hidden service in Qubes + Whonix…

The VirtualBox instructions here just need a couple changes:

Swap the Whonix-Workstation AppVM 10.137.X.X IP in for the 10.152.152.11 IP.
Open Firewall between Whonix-Gateway and Whonix-Workstation using iptables.

[b]Onion Services - Whonix

Will use a web server as an example on port 80, but one can change the port for their service application.

Also, you can (probably should) create clones of the Whonix-Gateway TemplateVM and Whonix-Workstation TemplateVM to establish your hidden service in. Then create a separate Whonix-Gateway ProxyVM and Whonix-Workstation AppVM for the live hidden service implementation.

Whonix-Gateway:

Open /etc/tor/torrc.

sudo nano /etc/tor/torrc

Read the comments. These explain where to find your .onion URL and to backup your hidden service keys. Comment in the following two lines.

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 WHONIX-WORKSTATION-APPVM-IP:80

WHONIX-WORKSTATION-APPVM-IP = the 10.137.X.X IP address given to the Whonix-Workstation AppVM in Qubes. You can look this IP up in the Settings of the Qubes Manager or use “sudo ifconfig” to see the eth0 IP in the AppVM terminal.

If not setting up a web server, change the port number from 80 to whatever your app requires.

Restart Tor.

sudo service tor reload

Reminder: To get your hidden service url.

sudo cat /var/lib/tor/hidden_service/hostname

Reminder: Backup your hidden service key, in case you want to be able to restore it, on another machine, on a newer Whonix-Gateway, after hdd failure, etc. You can find it here and you require root to access it.

/var/lib/tor/hidden_service/private_key

Whonix-Workstation:

Run the following commands to install lighttpd web server. Alternatively, you would replace a web server with a different hidden service application.

sudo apt-get update
sudo apt-get install lighttpd

Open firewall port access for your app between Whonix-Gateway and Whonix-Workstation.

sudo iptables -I INPUT 5 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT

If not setting up a web server, change the port number from 80 to whatever your app requires.

To make the firewall rule persistent, add the rule to the rc.local file and make it executable.

Open /rw/config/rc.local:

sudo nano /rw/config/rc.local

Add the following in the rc.local file:

#!/bin/sh

sudo iptables -I INPUT 5 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT

Make the rc.local file executable:

sudo chmod +x /rw/config/rc.local

All Done.

Note, that it may take up to 30 minutes (or so?) until a fresh .onion domain gets reachable.

igijo · March 7, 2015, 6:02pm

Thanks for the breakout! Im still getting stuck at getting the hostname. I don’t think the hidden service is getting created at all.

WhonixQubes · March 8, 2015, 12:00am

It looks like it is a permissions issue with the TemplateVM that the ProxyVM doesn’t have.

I’ll have to look into it further later.

As a quick fix, you could set this up in a Whonix-Gateway ProxyVM initially, then manually create or copy the files over into a cloned TemplateVM afterwards.

Then run a ProxyVM based on that TemplateVM.

You may have to retroactively go back and change the AppVM IP once you know the final one.

Patrick · March 8, 2015, 3:16pm

Seems to me the Hidden Services wiki page should be updated accordingly? I was wondering how we handle documentation when those are slightly different for various platforms.

We could use the [Expand] button. Example use of expand button can be seen here:

Then we could write something like this…

If you are using VirtualBox […], press [Expand].

If you are using Qubes […], press [Expand].

[quote=“WhonixQubes, post:2, topic:901”]sudo iptables -I INPUT 5 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT[/quote]
Why is this required? Is Whonix-Workstation in Qubes firewalled by default?

WhonixQubes · March 8, 2015, 8:42pm

[quote=“Patrick, post:5, topic:901”]Seems to me the Hidden Services wiki page should be updated accordingly? I was wondering how we handle documentation when those are slightly different for various platforms.

We could use the [Expand] button. Example use of expand button can be seen here:

Then we could write something like this…

If you are using VirtualBox […], press [Expand].

If you are using Qubes […], press [Expand].[/quote]

Great timing, as I am working on new documentation stuff right now.

I will create a new topic later to discuss this further.

[quote=“Patrick, post:5, topic:901”][quote author=WhonixQubes link=topic=1004.msg7238#msg7238 date=1425718293]

sudo iptables -I INPUT 5 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT

[/quote]
Why is this required? Is Whonix-Workstation in Qubes firewalled by default?[/quote]

Yes, it seems to be firewalled by default for new unsolicited incoming packets.

Whonix-Workstation:

sudo iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       udp  --  anywhere             anywhere             udp dpt:bootpc
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

WhonixQubes · March 8, 2015, 8:48pm

@igijo

Another easier option for you could be to use StandaloneVMs, instead of cloning TemplateVMs.

The loss here is that your root partition does not reset to a clean state with each VM restart.

The added convenience is that persistent configurations that don’t affect your other VMs is straightforward.

You can base it off of your normal Whonix TemplateVMs and check the “Standalone” box in Qubes Manager when creating a new ProxyVM / AppVM for your hidden service implementation.

igijo · March 10, 2015, 5:32pm

[quote=“WhonixQubes, post:4, topic:901”][quote author=igijo link=topic=1004.msg7241#msg7241 date=1425751326]
Thanks for the breakout! Im still getting stuck at getting the hostname. I don’t think the hidden service is getting created at all.
[/quote]

It looks like it is a permissions issue with the TemplateVM that the ProxyVM doesn’t have.

I’ll have to look into it further later.

As a quick fix, you could set this up in a Whonix-Gateway ProxyVM initially, then manually create or copy the files over into a cloned TemplateVM afterwards.

Then run a ProxyVM based on that TemplateVM.

You may have to retroactively go back and change the AppVM IP once you know the final one.[/quote]

I managed to get the hostname/private keys in.

Steps:

Created tempproxyvm.
sudo nano /etc/tor/torrc
-HiddenServiceDir /var/lib/tor/hidden_service/
-HiddenServicePort 80 randomIP:80
exit
sudo service tor reload
i couldn’t navigate to the tor folder using the regular file browser, permissions issue I guess
sudo dolphin
navigate to /var/lib/tor/
copy/cut hidden_service folder
navigate to the 2gb drive (someone correct me here I cant remember what the folder path is) /usr/home?
paste hidden_service folder
sudo qvm-copy-to-vm gateway-clone-templatevm hidden_service
in gateway-clone-templatevm
sudo dolphin
copy hidden_service directory from /QubesIncoming/tempproxyvm/ to /var/lib/tor/

stman · May 23, 2022, 11:15am

Hello.

I used to host a perfectly operational Mumble Server configured with a Tor Onion address in a dedicated Whonix Workstation VM, connected to my sys-whonix VM (Configured with Tor Entry node NOT persistent by commenting the relevant line in the /usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf in the corresponding template VM) thanks to /rw/config/rc.local containing :


rm -rf /var/lib/tor/mumble_service

ln -s /rw/config/var-lib-tor-mumble_service/mumble_service /var/lib/tor/mumble_service

With all necessary file correctly placed into /rw/config/var-lib-tor-mumble_service with correct access rights.

Everything was working perfectly until a few month ago, probably when after a whonix-16 update.

It is now not working.

There is an error in the rc.local script : It fails on the first line. The rm command on the symlink doesn’t work anymore. There is a persistent error : “Device or ressource busy” …

As it is no longer possible to install the symlink ensuring the peristence of the hidden service parameters, the onion address of my mumble server is no longer persistent to the value I wanted.

There is something weird that appeared on the tor folder access rights in /var/lib/ : it’s like “drwx…S…”
And this is what is causing the “rm” command to fail, and the impossibility to install the symlink at every sys-whonix reboot.

Any help welcome.

Kind regards,

Frederic.

Patrick · May 24, 2022, 7:55am

https://www.whonix.org/wiki/Tor#Permissions_Fix

This might not work. I am not sure when rc.local is executed. But it might be bad timing.

Should be done by using bind-dirs, not manually.

This is unsupported by Whonix.

But if you want to do this anyhow, consider this:

stman · May 24, 2022, 9:52am

Hello.

Thank you for your answer.

Ok then I am going to try to make the hidden service directory persistent using bind-dirs and I will let you know if it works, but please note that the way I did it is the way it is recommended on Whonix documentation to setup a mumble server hosted through Tor.

The documentation shall be updated then.

Please note again that this configg used to work perfectly in the past. It stopped working a few month ago after I upgraded to version 16 of whonix.

Patrick · May 24, 2022, 12:58pm

I am not aware of any changes by Whonix which would change anything related to Qubes bind-dirs / mumble / onion services.

Whonix documentation on mumble says nothing about bind-dirs. By removing default bind-dirs configuration entries, issues are quite likely to happen.

Qubes bind-dirs generally:
I am not sure a sub folder can be persistent while the parent folder is non-persistent.

Qubes bind-dirs more specifically:
I am not sure /var/lib/tor can be non-persistent while /var/lib/tor/mumble_service is persistent.

bind-dirs is a Qubes feature. Not a Whonix feature. Whonix is only using this. bind-dirs is probably imperfect.

bind-dirs works for /var/lib/tor since the postinst maintainer script by tor Debian package creates the folder during package installation with the correct linux user account owner as well as linux access rights. By the time bind-dirs is running, access rights are already correct. Doing this for a different folder is certainly possible however owner / access rights need to be correct.

It’s certainly to use different folders but rather complex and you’d likely run into other issues when trying to use folders other than /var/lib/tor. The following skills you’d have to master:

Qubes bind-dirs
linux access rights (read/write; owner)
apparmor (adds restrictions on which folders are readable / writeable)
systemd hardening (same as above)

stman · May 24, 2022, 4:15pm

Using bind-dirs did not work better. The “mumble_service” files access rights are correct. So the issue is coming from something else.

By the way, I don"t see why it would be impossible to have a folder persistant while the parent folder is not : This is what is happening for most folders/files that are made persistent with bind dirs.

I suspect apparmor.

Still, it was working before.

It’s really a pain.

I hope the documentation can get updated.

Patrick · May 24, 2022, 5:38pm

AppArmor indeed might interact with mount binds as well as symlinks.

No wiki updates for mumble planned. Mumble instructions or any onion service instructions should work as is. See also Wiki User Expectations.

I think the only issue here is the non-default use of bind-dirs. Users aren’t required/recommended/instructions to change bind-dirs settings. If bind-dirs is left alone, instructions should work as is.

When messing with bind-dirs, then, this applies:

stman · May 26, 2022, 11:01am

It’s back operational, but I had to do it “the ugly way” using the /rw/config/rc.local script another way :


#!/bin/sh
sudo service tor stop

sudo cp -r /home/user/QubesIncoming/vault/var-lib-tor-mumble_service/mumble_service /var/lib/tor

sudo service tor reload

sudo service tor start

Those dinb dirs suck. Really.