This post began as a follow up to my previous post where I was going to describe how to install Mastodon as a hidden service (HS), but it quickly became more about system config and how to properly host a Tor hidden service, so this post is that, and I will follow it up with a guide on the specifics of Mastodon as a hidden service.

The Guide

⚠️ Spinning up a hidden service is easy enough, however avoiding leaking the IP of your server is much harder. This guide will aim for a sufficient level of paranoia, but may fall short in some ways. If you are trying to deploy this in prod, double and triple check my work, or maybe just DIY.

This guide is written for admins with an existing bare Debian 12 installation. You can likely translate this to your OS of choice by finding the equivalent package names, system paths, apt-repos, and so-on.

Threat Model

In the afternoon I spent writing this post, I wasn’t able to find any specific details on how historical cases of Tor hidden service shutdown, seizure, or hacks have gone down. But that’s alright, since we can guess.
There are two broad ways in.

1. They identify the server through active scanning of the internet, or from some vantage point within the network topology (Possibly even from within the Tor network topology), and upon locating it, kick in some doors and rip out some Ram sticks.

2. They pop a shell through some web app/web server exploit and get root.

In all honesty this guide doesn’t prevent either of these things from happening. There are surely ways for determined enough adversaries to get their hands on our little Debian box, but this is a start, and for those running a static site on Nginx or something equally reliable (And you aren’t hosting something evil. Evil things gets 0-days. Anyways, if you are hosting something evil, fuck you), you’ll probably be fine.

A more paranoid design could be as follows:

• Running on a dedicated server in some free speech jurisdiction (I know this is mostly marketing, but it can’t hurt) with a new enough CPU to support memory encryption like AMD SME or Intel TME.
• LUKS! Don’t even think about using anything else.
• Running Debian or maybe Proxmox.
• Two VMs, your hidden service host and your router host.
• • The router host is connected to the internet, and provides NATed internet over a VXLAN to the HS host.¹
• • The HS host does all the Tor things.

That design has several advantages and hardening measures that would significantly reduce blast radius and would keep your HS from being directly connected to the internet. I would recommend it for the truly paranoid.

Some Precautions Before We Begin

You are a surgeon, and identifiable information is the blood and viscera that could lead to infection or even death. Maintain perfect sanitization or you will uhhhh… metaphor simile

Here’s some things you should do to make sure the service is difficult to trace back to you:

• Use Tor or some other kind of VPN when connecting to your server.
• Use a unique SSH key file for accessing the server.
• Pay for your server using Monero and fake info.

1. Apt Through Tor

❓ To prevent leaking your servers clearnet IP, we will proxy everything through Tor. This will make things slooooooooow, so consider running the rest of these commands in a tmux/screen session so you can resume if disconnected.

Start by installing apt-transport-tor:

apt update && apt install apt-transport-tor

Then manually replace domains in /etc/apt/sources.list with .onions retrieved from https://onion.debian.org, or run these commands:

sed -i 's/http:\/\/deb.debian.org/tor+http:\/\/2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/' /etc/apt/sources.list
sed -i 's/http:\/\/security.debian.org/tor+http:\/\/5ajw6aqf3ep7sijnscdzw77t7xq4xjpsy335yb2wiwgouo7yfxtjlmid.onion/' /etc/apt/sources.list

This will get the Debian repositories working, however may throw some errors for other clearnet repos, so we will add an Apt config to proxy the rest of our raffic. In theory this should all have been handled by apt-transport-tor but in my testing that was not the case:

cat << EOT > /etc/apt/apt.conf.d/50proxy
Acquire::https::proxy "socks5h://127.0.0.1:9050";
Acquire::http::proxy "socks5h://127.0.0.1:9050";
EOT

2. Tor Hidden Service for SSH

⚠️ Do not use the same Hidden Service as your eventual service. SSH host keys are the same across listen addresses, and mass internet scanners record these host keys, so could be used to correlate a clearnet IP with a hidden service.

As step 3 will prevent any access to the server via clearnet we need to preserve SSH access to the box. Create a new hidden service for SSH in /etc/tor/torrc by adding, for example, the following lines:

HiddenServiceDir /var/lib/tor/ssh-access/
HiddenServicePort 22 127.0.0.1:22

Restart the Tor service (systemctl restart tor), and retrieve the hostname from /var/lib/tor/ssh-access/hostname.

Now you should be able to access the server by running torify ssh USER@HOSTNAME. Ensure this is working and persists a reboot before proceeding to the next step.

3. Drop all non-Tor Traffic ²

⚠️ This section does NOT describe a way to ensure all system traffic is routed through Tor. What this does is drop all traffic from system users that aren’t debian-tor. The user debian-tor can still make clearnet requests, but shouldn’t unless something fishy is going on. You could set up some kind of monitoring of debian-tor to get early warnings of compromise.

⚠️ Since we’re working with firewalls it’s smart to double check your out-of-band access is working, otherwise you could lock yourself out of the system.

In this section we will block all non-Tor network traffic from leaving the system, including SSH. You may wish to continue to access the system via clearnet SSH. If so you could add an additional skuid line with your system user to the nftables rules. Just keep in mind that this will store your SSH client IP in several places on the system.

Option a) nftables

cat << EOT > /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
        chain output {
            # Drop all traffic
            type filter hook output priority filter; policy drop;
            # Allow traffic from user debian-tor
            skuid debian-tor counter accept;
            # Allow traffic on "lo" interface
            oifname "lo" counter accept;
        }
}
EOT

# Start nftables at boot
systemctl enable --now nftables.service

Option b) iptables

iptables -F OUTPUT
iptables -A OUTPUT -j ACCEPT -m owner --uid-owner debian-tor
iptables -A OUTPUT -j ACCEPT -o lo
iptables -P OUTPUT DROP
iptables -L -v
iptables-save -f /etc/iptables/rules.v4

4. Getting Shit Done (Configuring your shell)

To continue with setting up and operating your hidden service you will presumably need access to internet resources, but since we just turned off the internet for all users except debian-tor, that may pose a challenge. What follows is some basic proxy config.

Let’s start by routing DNS through Tor:

cat << EOT >> /etc/tor/torrc

## Torified DNS
DNSPort 127.0.0.1:53
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion
EOT

# This will drop your Tor SSH connection
systemctl restart tor

echo "nameserver 127.0.0.1" >> /etc/resolv.conf

And test it by running:

dig torproject.org

If it returns an IP then it’s working!

Next we need to set up proxying for command line tools. We could do this with IPTables, but it’s simpler to use the http_proxy and other env variables. These variables are honored by tools that use libcurl and some others, but some tools may not work. For those you can use torsocks.

cat << EOT >> /etc/environment

http_proxy=socks5://127.0.0.1:9050
HTTP_PROXY=socks5://127.0.0.1:9050
https_proxy=socks5://127.0.0.1:9050
HTTPS_PROXY=socks5://127.0.0.1:9050
ALL_PROXY=socks5://127.0.0.1:9050

EOT
# Load the new environment variables
source /etc/environment

And verify it is working with:

curl -s https://check.torproject.org | grep "Congratulations."

5. Conclusion

Your system is now ready to install whatever software you wish to host as a hidden service.

At this point the server will be somewhat protected against easy and immediate de-anonymization, but this is not hardened beyond that. When deploying your software, ensure you are following sysadmin best practices to reduce blast radius.

Enjoy!