Tor and Monero Series - Part 1 - A Secure Tor Client Setup on Artix Linux (runit)

· linux, unix, security, tor, monero · 4 min read

Introduction

Tor is often installed with the expectation of “anonymity by default”, but in practice most anonymity failures come from unclear scope and misconfiguration, not from Tor itself.

This post describes a correct, explicit Tor client setup on Artix Linux using runit. It is designed to provide anonymous network traffic for:

  • Tor Browser
  • Applications explicitly configured to use Tor via SOCKS
  • Access to Tor v3 hidden services (including client authorization)

Traffic that is routed through Tor is anonymised at the network level. Traffic that is not routed through Tor is not anonymised.

This is intentional: anonymity should be explicit, auditable, and application-scoped, not implicit and fragile.

Threat Model and Scope

This setup assumes:

  • You are running Tor as a client only
  • You do not operate a Tor relay or exit
  • All Tor usage is explicit via SOCKS
  • Applications must opt in to Tor
  • You may want application-level traffic isolation
  • You may want to use Tor Browser and controller tools

This setup does provide anonymous Tor traffic for:

  • Tor Browser
  • Any application correctly configured to use the Tor SOCKS proxy

This setup does not:

  • Force all system traffic through Tor
  • Protect against a compromised OS or kernel
  • Automatically anonymise misconfigured applications

Installing Tor on Artix Linux (runit)

Install Tor from the official repositories:

sudo pacman -S tor

Enable the service under runit:

sudo ln -s /etc/runit/sv/tor /run/runit/service/

Verify that Tor is running:

sudo sv status tor

Minimal, Secure Tor Client Configuration

Below is a clean and auditable torrc suitable for a laptop or workstation acting as a Tor client.

User tor
DataDirectory /var/lib/tor

###############
# SOCKS Proxy #
###############

# Default SOCKS proxy (Tor Browser, general use)
SOCKSPort 127.0.0.1:9050

# Isolated SOCKS proxy for sensitive applications (e.g. Monero)
SOCKSPort 127.0.0.1:9062 IsolateClientAddr IsolateDestAddr

###############
# Controller  #
###############

# Required for Tor Browser / Nyx
ControlPort 127.0.0.1:9051

# Secure controller authentication
CookieAuthentication 1
CookieAuthFile /var/lib/tor/control_auth_cookie
CookieAuthFileGroupReadable 1

# Optional Unix control socket (also cookie-protected)
ControlSocket /var/lib/tor/control_socket
ControlSocketsGroupWritable 1

###############
# Client Auth #
###############

# Required for Tor v3 client authorization
ClientOnionAuthDir /var/lib/tor/onion_auth

###############
# Logging     #
###############

Log notice syslog

###############
# Safety      #
###############

# Client only (not a relay or exit)
ORPort 0
ExitRelay 0

# Explicitly disable transparent proxying
TransPort 0
DNSPort 0

What This Configuration Achieves

Anonymous Traffic (When Used Correctly)

  • Tor Browser traffic is anonymised by default
  • Applications configured to use 127.0.0.1:9050 are anonymised
  • Applications configured to use the isolated port 127.0.0.1:9062 are anonymised and separated from other Tor traffic

Tor provides network-level anonymity:

  • Your IP address is hidden from destinations
  • Traffic is routed through the Tor network
  • Exit nodes see traffic, not your identity

SOCKS Isolation Explained

Multiple SOCKS ports only provide isolation when isolation flags are used.

This configuration:

SOCKSPort 127.0.0.1:9062 IsolateClientAddr IsolateDestAddr

ensures:

  • A dedicated Tor circuit
  • No shared state with other applications
  • Reduced risk of cross-application correlation

Without isolation flags, multiple SOCKS ports do not guarantee separation.

ControlPort and Security

The Tor ControlPort is required for:

  • Tor Browser
  • Nyx
  • Controller-based tooling

The risk associated with the ControlPort is local, not network-level. If an attacker gains local control access, they may influence Tor behaviour.

This configuration mitigates that risk by:

  • Binding the ControlPort to localhost
  • Using cookie authentication
  • Restricting file permissions

If you do not use Tor Browser or controller tools, the entire controller section may be omitted.

Firewall Considerations

For a Tor client:

  • No inbound firewall rules are required
  • Loopback traffic must be allowed
  • Outbound TCP connections must be permitted

Tor initiates all network connections itself. No ports need to be opened.

Verifying the Setup

Validate the configuration before restarting Tor:

sudo tor --verify-config -f /etc/tor/torrc

Restart Tor:

sudo sv restart tor

Confirm listening ports:

ss -ltnp | egrep '9050|9051|9062'

Test Tor connectivity:

curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

What This Setup Does Not Do

This configuration does not:

  • Automatically anonymise all system traffic
  • Protect against a compromised system
  • Prevent application-layer fingerprinting
  • Guarantee anonymity if applications bypass Tor

It provides a correct, explicit Tor client foundation:

  • Anonymous traffic when routed through Tor
  • Clear boundaries between Tor and non-Tor traffic
  • Minimal attack surface

Summary

  • Traffic sent through Tor is anonymised
  • Applications must explicitly opt in
  • Isolation is available when needed
  • No unnecessary features are enabled
  • The configuration is minimal and auditable

This setup is intended to be understood, not blindly copied.

In the next post, this Tor client foundation is used to run a private Monero remote node over Tor, secured with Tor v3 client authorization.