No newer entries | Menu | The 1+N problem

Hosting Tor Hidden Services

The simplest way of hosting a tor hidden service is to have tor and the service on the same machine. This is not very safe, because a compromise in tor or the hidden service will potentially allow you to access the other. For example a bad actor somehow breaking out of the web server might read your private hidden service key.

The solution to this is to host the tor client on one machine, and the hidden service on another. For this documentation, we will call the tor machine the frontend and the hidden service machine the backend.

This guide assumes that these two devices are virtual machines running on the same host, but you can use physical machines and network, and run them accross the internet if you want to. This guilde will not go into the details of how to keep that type of setup safe.

The commands to do the tasks requested in this guide vary between operating systems. Because of this, you will find general instructions, but not exact commands you can copy as-is.

This guide assumes that you know your operating system well enough to deal with network and firewall configurations

Anonymous Browsing

If you landed here because you want to anonymously browse the internet, stop. This guide is for providing services, not for consuming them.

For regular users, use Whonix instead.

Architecture

graph LR
  Backend<--Internal-->Frontend
  Frontend<--Public-->Internet

Frontend

The frontend is the more complex server as it provides more services. It needs to be set up first.

Network

This machine has two network adapters, one connected to the public internet, and one connected to the virtual "internal" network.

The public facing adapter is configured in a way to grant your machine internet access. At home this is likely DHCP, in a commercial setting this is likely static.

The private facing adapter needs to be manually configured. In our demo, we assume the network 10.0.0.0/8 is available. If you already have a 10.x.y.z IP address on the public interface, pick a different network.

See here for a list. You can pick any network in the "PrivateUse" category, but 192.168.0.0/16 is the most common for this purpose.

In this guide, we will assign the following parameters:

If you pick different values, don't forget to replace them below in the instructions too

Tor

Next you want to install tor for your operating system. The tor project has a guide for this.

If you are using Windows, you can download the precompiled expert bundle from the download page. Unlike the linux version, this is not an installer, but the raw package. You must install it as a service manually. You can install it as a service by calling the tor executable with --service install parameter.

Tor Config

Tor works without a configuration. It will open a SOCKS5 listener on the loopback interface on 9150 by itself if no configuration exists. While this is enough to use tor as a client, you need some extra settings to use it as a hidden service.

Look up where the tor config for your operating system goes, then replace it with the one below.

# SOCKS proxy config
SOCKSPort 9150
SOCKSPort 10.0.0.1:9150
SocksPolicy accept *

# HTTP server on backend
HiddenServiceDir /var/lib/tor/backend_HTTP
HiddenServicePort 80 10.0.0.2:80

# Maintenance access to backend
HiddenServiceDir /var/lib/tor/backend_Maintenance
HiddenServicePort 3389 10.0.0.2:3389
HiddenServicePort   22 10.0.0.2:22

This configuration does the following:

  1. Create a loopback proxy listener (unlike many other software, not specifying an IP in tor means to use loopback)
  2. Create a proxy listener on the internal network
  3. Set up a hidden service that forwards data on port 80 (HTTP) to your backend
  4. Set up a different hidden service that forwards data on port 22 (SSH) and 3389 (RDP) to your backend

You will only need one of the ports for the maintenance connection (22 for Linux, 3389 for Windows), and you can delete the unused one. On Windows, you will need to change the HiddenServiceDir paths by replacing the /var/lib/tor part with the path to a local, empty directory.

After changing the configuration, restart the tor service. If you did it correctly, you should find a file named "hostname" in each of the configured directories. This file can be opened in any text editor to get your .onion domain name.

Client Authorization

In general, it's impossible to detect onion names because the information about them is encrypted with their own name, therefore to know if a name exists, one must already know the name. Onion names are long enough so that guessing them is infeasible.

However, you can still add some extra protection. By making use of the client authorization feature, you can restrict access to an onion domain to a set of private keys. This feature is useful if you want to expose your web server to only a select few people, or to further lock down your management hidden service.

DNS

You should install a Tor compatible DNS service on your frontend. An example is technitium DNS. It comes with an easy-to-use web interface. After installation you want to configure the server as follows:

  1. Use the Cloudflare tor DNS forwarder (DNS over tor). This should also set the proxy values above the drop down correctly, but make sure they are set to 127.0.0.1 and port 9150 afterwards
  2. Change the web interface listener to only listen on 127.0.0.1
  3. Change the DNS interface listener to only listen on 127.0.0.1 and 10.0.0.1

Finally, change the configuration of the public network interface to use 127.0.0.1 as DNS server.

Note: With the web interface set to loopback only, you can obviously no longer access it remotely. On Windows, this is less of a problem because you can RDP into the machine and just use a local web browser on it. For Linux where you're likely connected with SSH, add -L 5380:localhost:5380 to your ssh command line in order to create a tunnel on port 5380 from your local machine to the remote host. You can then access http://localhost:5380 on your local machine while the SSH connection is open. 5380 is the default technitium web UI port. You can change it if you want to, but there is usually no need to do so.

You can also make the DNS web interface available via an additional hidden service in your tor config like so:

# DNS web admin console on frontend
HiddenServiceDir /var/lib/tor/frontend_DNS
HiddenServicePort 5380 127.0.0.1:5380

HTTP proxy

Tor only provides a socks proxy, which not all applications deal with correctly. If you find socks configuration on the backend to be cumbersome, you can look online for a http proxy wrapper. Usually they come with names such as http2socks.

Extra security

After you have set up every service it's time to harden your machine.

Passwords

Make sure your passwords differ. The user password should not be the same as the DNS web interface password for example.

SSH

If you use SSH, you should upload your public key to the frontend server and disable password based authentication.

It may be tempting to create an extra hidden service for SSH on the frontend, and make the SSH server listen on 127.0.0.1 only, but be aware that you lock yourself out of the machine if its tor client fails to run for some reason. You can safely do this if you have means to access the console of the VM.

Firewall

You should set up a firewall, preferrably one that can deal with rules based on applications rather than just ports.

Create rules as follows:

  1. Deny all outgoing connections
  2. Deny all incoming connections
  3. Add incoming exception for the tor service and dns service on the internal network
  4. Add outgoing exception for the tor service and dns service on the public network
  5. Add outgoing exception for tor on the internal network
  6. Add incoming exception for SSH or RDP on the public network (if not using a hidden service for it)
  7. If using a http to socks bridge, add incoming exception for it on the internal network

If you have a static IP address where you are, the SSH/RDP exception can be improved by restricting it to your public IP address. Downside is that a malicious entity that gets access to this machine can see this IP address in the config and make the assumption that this is your virtual machine.

Note: These rules will prevent you from updating your system. Be sure to configure tor or the http2socks adapter as a proxy for your update mechanism (apt, windows update, etc.).

Backend

The backend is conceptually much easier to install. It only has one network connection, which is hooked up to the virtual "internal" network.

Network

Proxy

Your machine is basically set up at this point. All you have to do for networking applications is to configure 10.0.0.1:9150 as socks5 proxy server. For applications that only support HTTP proxies (for example apt) you need to specify the port of the http to socks bridge you installed on the frontend.

Web server

The example tor config above will create a hidden service for your web server. Simply install a webserver like apache2 or nginx, and it should work out of the box because they all create a public port 80 listener by default.

Security

In general, it's best to have one virtual machine for one hidden service. You also should not have multiple backend machines on the same virtual network, because otherwise they could communicate with each other.

Only add multiple machines if your network stack supports client isolation. You can achieve this by restricting each backend VM to its own VLAN id, and only allow the frontend to use them all.

Information Disclosure

Many software discloses unnecessary information via its protocols. Most web servers for example add a "Server" http header that contains the name of the web server software, and sometimes the version. This information is also occasionally found on server generated error pages.

Check the manual for the services you expose as a hidden service and disable as many identifying options as you can.