Onion Services Authentication

Patrick · December 18, 2019, 1:53pm

A post was split to a new topic: Onion Services DDOS Defense Tor 0.4.2.5

HulaHoop · December 18, 2019, 2:16pm

No dice with either or both of the permission change commands.

Output:

ls: cannot open directory '/var/lib/tor': Permission denied
user@host:~$ ls -la /var/lib/tor/hidden_service/
ls: cannot access '/var/lib/tor/hidden_service/': Permission denied

Patrick_mobile · December 18, 2019, 5:15pm

ls failing as user is actually expected. Upstream default. Needs to run with sudo.
sudo ls …

Patrick · December 18, 2019, 8:13pm

Also try:

sudo chmod --recursive g-rwx /var/lib/tor

That removes read/write/execute permissions for group members (of debian-tor) too. I don’t know which files in /var/lib/tor - if any - might require read/write access by group debian-tor members. Maybe none.

HulaHoop · December 19, 2019, 5:09pm

user@host:~$ sudo ls -la /var/lib/tor
total 5964
drwx--S---  4 debian-tor debian-tor    4096 Dec 19  .
drwxr-xr-x 35 root       root          4096 Dec  7  ..
-rw-------  1 debian-tor debian-tor   20442 Dec  7 cached-certs
-rw-------  1 debian-tor debian-tor 2053723 Dec 19 cached-microdesc-consensus
-rw-------  1 debian-tor debian-tor 3999110 Dec 19 cached-microdescs
-rw-------  1 debian-tor debian-tor       0 Dec 19 cached-microdescs.new
drwx--Sr-x  3 root       debian-tor    4096 Dec 19 hidden_service
drwx--S---  2 debian-tor debian-tor    4096 Dec  7 keys
-rw-------  1 debian-tor debian-tor       0 Dec 19 lock
-rw-------  1 debian-tor debian-tor    9681 Dec 19 state
user@host:~$ sudo ls -la /var/lib/tor/hidden_service/
total 12
drwx--Sr-x 3 root       debian-tor 4096 Dec 19 .
drwx--S--- 4 debian-tor debian-tor 4096 Dec 19 ..
drwx--Sr-x 2 root       debian-tor 4096 Dec 19 authorized_clients
user@host:~$

HulaHoop · December 19, 2019, 5:10pm

Still fails to reload

Patrick · December 20, 2019, 8:27am

Why is it still owned by root?

Did you run

sudo chown --recursive debian-tor:debian-tor /var/lib/tor

?

HulaHoop · December 20, 2019, 3:04pm

I just tried it again and now and this its not going anywhere.

checked the dir list and everything is debian-tor:debian-tor. So while something may have been overlooked last time, it isn’t the reason now.

Patrick · December 20, 2019, 3:09pm

These are only linux file permissions. Should be very much repairable.

Delete that folder.

sudo rm -r /var/lib/tor/hidden_service

At least that fixes that startup issue?

Maybe we shouldn’t write to /var/lib/tor with root ever? Prefix all actions with sudo -u debian-tor ...?

Delete whole folder /var/lib/tor. apt purge tor, reinstall tor?

HulaHoop · December 23, 2019, 7:06pm

No

Perhaps. I applied it to this step:

sudo -u debian-tor mkdir -p /var/lib/tor/hidden_service/authorized_clients/

Doesn’t work here though. Prpbably more steps need modification?

sudo cp some-client.auth /var/lib/tor/hidden_service/authorized_clients/

HulaHoop · December 23, 2019, 7:07pm

How can I reinstall when gw connection depends on Tor? Maybe convert an installed package to a .deb, but then this doesn’t solve the mystery of why it breaks

Patrick · December 24, 2019, 11:47am

The mistery can be solved. Create a snapshot or copy of that VM. And/or (very much useful anyhow), record all permissions.

sudo find /var/lib/tor | sudo xargs stat -c "%n %a %U %G"

Write permissions into file ~/old.

sudo find /var/lib/tor | sudo xargs stat -c "%n %a %U %G" > ~/old

This is what I have:

/var/lib/tor 2700 debian-tor debian-tor
/var/lib/tor/cached-microdesc-consensus 600 debian-tor debian-tor
/var/lib/tor/cached-certs 600 debian-tor debian-tor
/var/lib/tor/lock 600 debian-tor debian-tor
/var/lib/tor/keys 2700 debian-tor debian-tor
/var/lib/tor/cached-microdescs.new 600 debian-tor debian-tor
/var/lib/tor/state 600 debian-tor debian-tor

It’s a risky operation for sure. Keep a snapshot.
Might not work in Qubes-Whonix due to folder /var/lib/tor in bind-dirs.
Should work in Non-Qubes-Whonix.

apt download tor
sudo systemctl stop tor@default
sudo dpkg --purge --force-all tor
sudo dpkg -i tor*deb

Patrick · December 24, 2019, 11:56am

I don’t know how to do that without a following chown / chmod which didn’t work great.

Not sure if entirely sane / best practice but we could try this approach:

Open a shell as user debian-tor.

sudo -u debian-tor bash

Then no more sudo, chown, chmod required.

Home folder of user debian-tor is /var/lib/tor. Does not even need cd /var/lib/tor. Then all files should have correct permissions.

HulaHoop · January 2, 2020, 3:20pm

Permissions before and after applying the instructions. I couldn’t apply many of them under debian-tor bash user because sudo access is restricted for this account.

/var/lib/tor 2700 debian-tor debian-tor
/var/lib/tor/cached-microdescs.new 600 debian-tor debian-tor
/var/lib/tor/state 600 debian-tor debian-tor
/var/lib/tor/keys 2700 debian-tor debian-tor
/var/lib/tor/cached-microdescs 600 debian-tor debian-tor
/var/lib/tor/cached-certs 600 debian-tor debian-tor
/var/lib/tor/cached-microdesc-consensus 600 debian-tor debian-tor
/var/lib/tor/lock 600 debian-tor debian-tor

/var/lib/tor 2700 debian-tor debian-tor
/var/lib/tor/cached-microdescs.new 600 debian-tor debian-tor
/var/lib/tor/state 600 debian-tor debian-tor
/var/lib/tor/hidden_service 2755 debian-tor debian-tor
/var/lib/tor/hidden_service/authorized_clients 2755 debian-tor debian-tor
/var/lib/tor/hidden_service/authorized_clients/some-client.auth 644 debian-tor debian-tor
/var/lib/tor/keys 2700 debian-tor debian-tor
/var/lib/tor/cached-microdescs 600 debian-tor debian-tor
/var/lib/tor/cached-certs 600 debian-tor debian-tor
/var/lib/tor/cached-microdesc-consensus 600 debian-tor debian-tor
/var/lib/tor/lock 600 debian-tor debian-tor

Patrick_mobile · January 2, 2020, 3:56pm

The idea is once you are debian-tor you won’t need any sudo.

Patrick · January 6, 2020, 10:27am

Fixed instructions.

sudo apt-get install sudo apt install

->

sudo apt-get install basez

Patrick · January 6, 2020, 10:40am

Following instructions on Onion Services - Whonix from top to bottom will currently fail.

file_name="/var/lib/tor/hidden_service/hostname"

hostname="$(sudo cat "$file_name" | str_replace .onion "")"

cat: /var/lib/tor/hidden_service/hostname: No such file or directory

This is because Tor wasn’t restarted/reload yet which only happens in a later step using sudo service tor@default reload.

We could reload Tor earlier but then there would be a time during the onion service active on the Tor network without authentication enabled yet. Would that be a problem?

Patrick · January 6, 2020, 12:38pm

Working on automation for this.

Could you have a look at this script please?

anon-gw-anonymizer-config/usr/bin/anon-auth-autogen at master · Whonix/anon-gw-anonymizer-config · GitHub

sudoedit /usr/bin/anon-auth-autogen

For copy/paste

https://raw.githubusercontent.com/Whonix/anon-gw-anonymizer-config/master/usr/bin/anon-auth-autogen

sudo chmod +x /usr/bin/anon-auth-autogen

It has reasonable defaults.

sudo anon-auth-autogen

This uses folder /var/lib/tor/hidden_service and Tor config file /usr/local/etc/torrc.d/43_test_hs_autogen.conf.

HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 10.137.0.102:80
HiddenServiceVersion 3

Example:

INFO: Created torconffile ‘/usr/local/etc/torrc.d/43_hidden_service_hs_autogen.conf’.
INFO: Copied client_authorization_full_path ‘/var/lib/tor_autogen/hidden_service/1.auth’ to ‘/var/lib/tor_autogen/hidden_service/1.auth’.
INFO: You probably want to provide client ‘1’ with auth_private_file ‘/var/lib/tor_autogen/hidden_service/1.auth_private’ for hsname ‘hidden_service’ onion_url ‘some.onion’.

All variables are configureable.

sudo virtport=80 hsport=80 hsname=hidden_service client=1 anon-auth-autogen

For example by changing client=1 to client=2 a second visitor credential pair could be created.

sudo virtport=80 hsport=80 hsname=hidden_service client=2 anon-auth-autogen

The script is not in any Whonix repository yet. This script requires Whonix 15 with testers repository because only that has “real” support for torrc.d.

HulaHoop · January 6, 2020, 2:02pm

Shouldn’t be since nothing can connect to the service without knowing its address. No race condition there. If this was part of adding a new authenticated user then service access may be temporarily disrupted for those already enrolled?

Patrick · January 6, 2020, 3:44pm

In theory, no. (systemd) unit action reload (other than restart) keeps the (Tor) process running and only reloads the config. It should not result in service / connection interruptions.