Security Architecture of a Tor Relay: Least Privilege, Firewalls, and Service Isolation

A secure Tor relay does not depend on exotic hardening.

The strongest baseline is a conventional Linux security model applied carefully:

least privilege
+
minimal exposed ports
+
restricted identity keys
+
local administrative interfaces
+
regular updates

A non-exit relay is especially suitable for this approach because it does not need to originate arbitrary Internet traffic on behalf of users.

Dedicated service accounts are essential

A Tor daemon should not run permanently as root.

Modern Debian-derived packages normally execute Tor under a dedicated system service account created specifically for the package.

This account differs from a human login account.

It typically has:

• no interactive shell;
• no usable password;
• no home directory under /home;
• ownership of the Tor state directory;
• access only to files required by Tor.

This creates an important security boundary.

If the Tor process were ever compromised, the attacker would initially inherit the privileges of the restricted service identity rather than full administrative privileges.

Protect relay identity keys

The Tor state directory contains long-term relay identity material.

Typical structure:

/var/lib/tor/
└── keys/

Permissions should be restrictive.

Conceptually:

owner: dedicated Tor service user
group: dedicated Tor service group
world access: none

Configuration files may be readable by other local users, but private identity keys should not be.

Relay fingerprints and public descriptors are intentionally public. Private identity keys are not.

Only expose the ORPort

A well-designed relay has a very small Tor-specific network surface.

A port scan should show something conceptually similar to:

LISTEN 0.0.0.0:<RELAY_PORT>

while ports associated with local SOCKS or control access remain absent.

The intended design is:

Internet
   ↓
ORPort only

not:

Internet
   ├─ ORPort
   ├─ SOCKS proxy
   ├─ ControlPort
   └─ miscellaneous administrative ports

Keeping management interfaces off the public network reduces risk significantly.

Unix control sockets are preferable for local monitoring

Tools such as Nyx or custom monitoring scripts can communicate with Tor over a local Unix socket.

Example:

/run/tor/control

This avoids opening an additional TCP control service.

Permissions can then be handled using normal filesystem ownership:

srw-rw----

Only the Tor service identity and authorized local processes should be able to access the socket.

Host firewall and router firewall serve different roles

A typical home or small-office relay may sit behind NAT.

The router performs:

public TCP connection
        ↓
DNAT / port forward
        ↓
internal relay server

The host firewall then decides whether the relay server itself accepts the packet.

Using both layers provides defense in depth.

The external router should forward only the ORPort, while the host firewall should permit exactly the service that Tor is listening on.

IPv4-only configurations should remain explicit

If a relay is configured with:

ORPort <RELAY_PORT> IPv4Only

then opening an equivalent IPv6 firewall rule does not automatically expose Tor over IPv6 if Tor itself is not listening there.

Nevertheless, matching firewall policy to actual application behavior keeps configuration easier to audit.

Unused rules can eventually be removed for clarity.

Understanding systemd security scores

Commands such as:

systemd-analyze security <service>

are useful but frequently misunderstood.

The resulting score is a sandboxing exposure score, not a vulnerability scanner.

A service might receive a “medium” rating because the unit lacks directives such as:

ProtectKernelModules=
ProtectControlGroups=
RestrictNamespaces=

without having any known security flaw.

Some packages also perform privilege dropping internally rather than through User= directly in the systemd unit.

Therefore:

systemd exposure score
≠
CVE severity
≠
evidence of compromise

Blindly adding every possible sandbox directive merely to improve the score can break package assumptions or interfere with upgrades.

Hardening should be based on actual threat models.

Useful protection mechanisms

Commonly valuable systemd protections include:

NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
PrivateDevices=true

Capability restrictions are also useful.

A Tor relay generally does not need privileges such as:

CAP_SYS_ADMIN
CAP_SYS_MODULE
CAP_NET_ADMIN
CAP_SYS_PTRACE

Removing unnecessary capabilities limits what a compromised service could do.

Keep package sources trustworthy

Tor should be installed from a well-maintained distribution repository or the official Tor Project package repository.

The package source should be periodically checked:

apt-cache policy tor

This makes it possible to confirm:

• installed version;
• candidate version;
• repository origin.

Security updates to the operating system are equally important.

A perfectly configured Tor daemon still depends on OpenSSL, libc, the Linux kernel, SSH, and other system components.

Avoid unnecessary complexity

Security architecture often improves when components are removed rather than added.

A sensible non-exit relay security model can remain extremely simple:

dedicated service user
+
restricted key directory
+
single public relay port
+
Unix control socket
+
host firewall
+
NAT firewall
+
automatic security updates

This is usually more robust than a heavily customized configuration whose behavior becomes difficult to understand after several years of upgrades.