How to Protect a Tor Hidden Service IP Address

Operating a Tor onion service requires strict security practices to ensure the hosting server’s real IP address is never exposed to the public. Because Tor is designed to obscure routing, IP leaks almost always originate from misconfigurations within the operating system, web server software, or backend applications. This guide details the essential technical measures needed to prevent identity leaks, harden server architecture, and keep your Tor hidden service entirely anonymous.

1. Bind Services Exclusively to Localhost

Web servers and backend applications must never listen on public IP addresses (0.0.0.0). Configure your server software (such as Nginx or Apache) to listen exclusively on 127.0.0.1 or, preferably, a UNIX domain socket.

For Nginx, configure your site configuration file to use local sockets:

listen unix:/var/run/tor-service.sock;

For Apache, specify the loopback interface:

Listen 127.0.0.1:8080

The Tor daemon can then forward incoming onion traffic directly to this local interface, preventing any direct clearnet connections to the application.

2. Block All Inbound Clearnet Traffic

A Tor hidden service does not require any inbound ports open on the public network interface. Tor establishes outbound connections to the Tor network to build rendezvous circuits.

Use iptables or nftables to drop all inbound traffic on external interfaces: * Set default incoming policy to DROP. * Allow loopback traffic on lo. * Allow established and related outbound connections. * Restrict direct management access (such as SSH) strictly through a dedicated Tor onion service or an encrypted, IP-whitelisted VPN.

3. Implement Network Isolation with Whonix or Multi-VM Architecture

The most effective way to eliminate IP leaks is architectural isolation. Running the Tor daemon and the application server on the same operating system creates a single point of failure.

• Split Gateway and Workstation: Use a two-tiered system such as Whonix or Qubes-Whonix. The Workstation VM hosts the web server and has no direct network access; it can only communicate through an internal virtual network to the Gateway VM.
• Leak Prevention: Even if the web application is fully compromised via a Remote Code Execution (RCE) exploit, the attacker cannot read the real IP address from the operating system network interfaces, as the Workstation only sees internal private IP addresses.

4. Sanitize Application Responses and Server Headers

Web applications and server software often leak system details that allow attackers to correlate an onion service with a public clearnet server.

• Disable Server Signatures: Remove headers like Server, X-Powered-By, and X-AspNet-Version.
• Disable Diagnostic Modules: Turn off server status pages, such as Apache’s mod_status, which can expose the public IP and active connection metadata.
• Remove Absolute Clearnet Links: Ensure no content (scripts, stylesheets, fonts, or images) is loaded from public clearnet CDNs or IP addresses. All assets must be served locally over the .onion domain.
• Standardize Error Pages: Custom error pages or standard default web server landing pages can reveal specific software versions and unique fingerprintable hashes.

5. Prevent Outbound Information Leaks (SSRF)

Server-Side Request Forgery (SSRF) vulnerabilities allow attackers to force your server to make external requests to attacker-controlled clearnet endpoints, instantly exposing the server’s public IP address.

• Block all clearnet outbound traffic from the application layer using strict firewall rules.
• If outbound internet access is required, route all outbound traffic through the Tor SOCKS proxy (127.0.0.1:9050) or use a dedicated network namespace.
• Disable application-level functions that fetch remote URLs, such as webhook triggers, image proxying, or automated link previews.

6. Eliminate Clearnet DNS Requests

Standard DNS resolution bypasses Tor by default and communicates with clearnet DNS resolvers configured in /etc/resolv.conf, which leaks queries and reveals the host server’s location.

• Direct all system DNS queries through Tor’s built-in DNSPort or disable system-wide clearnet DNS lookups entirely.
• In /etc/tor/torrc, configure:

DNSPort 5353
AutomapHostsOnResolve 1

• Ensure no backend components or database drivers attempt clearnet domain resolutions.