Secure Database Access Over Tor Hidden Services

Configure Tor to forward PostgreSQL's port through a hidden service, then restrict access with Tor client authorization:

# /etc/tor/torrc — PostgreSQL hidden service
HiddenServiceDir /var/lib/tor/db_service/
HiddenServicePort 5432 127.0.0.1:5432
HiddenServiceVersion 3
# Require client auth — only authorized keys can connect
HiddenServiceAuthorizeClient stealth db-admin

# /etc/postgresql/16/main/postgresql.conf
listen_addresses = '127.0.0.1'
port = 5432
ssl = on
ssl_cert_file = '/etc/ssl/certs/pg.crt'
ssl_key_file = '/etc/ssl/private/pg.key'

# /etc/postgresql/16/main/pg_hba.conf
# Only allow SSL connections from localhost (Tor)
hostssl all db_user 127.0.0.1/32 scram-sha-256

With this configuration, PostgreSQL only listens on localhost and requires SSL even for local connections. The Tor hidden service provides network-level access control, while PostgreSQL's own authentication provides application-level security. This defense-in-depth approach means an attacker needs both a valid Tor auth key and valid database credentials.

From the client side, use torsocks to route database connections through Tor to the hidden service:

# Connect to PostgreSQL over Tor
torsocks psql -h your56charaddress.onion -U db_user -d mydb

# Connect to MySQL over Tor
torsocks mysql -h your56charaddress.onion -u db_user -p

# Application connection string via Tor SOCKS proxy
# Python example with psycopg2
import socks
import socket

# Route through Tor SOCKS proxy
socks.set_default_proxy(socks.SOCKS5, "127.0.0.1", 9050)
socket.socket = socks.socksocket

import psycopg2
conn = psycopg2.connect(
    host="your56charaddress.onion",
    port=5432,
    user="db_user",
    password="strong_password",
    dbname="mydb",
    sslmode="require"
)

For application servers that need persistent database connections, configure your connection pool to handle the higher latency of Tor circuits. Set connection timeout to 60 seconds and increase pool size to compensate for the slower connection establishment. Keep-alive packets should be enabled to prevent idle connections from being dropped by Tor.

Running a database as a Tor hidden service requires strict security measures beyond what you would apply to a local-only database:

• Always use client authorization — Never expose a database hidden service without Tor-level client auth. Without it, anyone who discovers your .onion address can attempt to connect.
• Enable SSL/TLS — Even though Tor encrypts traffic, SSL adds authentication of the database server and protects against potential attacks at the rendezvous point.
• Use strong authentication — Use scram-sha-256 for PostgreSQL, caching_sha2_password for MySQL. Never use trust or password-based auth without SSL.
• Limit database user privileges — Create specific users for each application with only the permissions they need. Never expose the root/superuser account over Tor.
• Monitor connection attempts — Log failed authentication attempts (to a local-only log) and set up alerts for brute-force patterns.
• Rate limit connections — Configure maximum connection limits in the database to prevent resource exhaustion from connection floods.

Consider whether you truly need database access over Tor. If your application and database are on the same server, use Unix sockets instead. Reserve Tor-based database access for genuinely distributed architectures.

AnubizHost VPS plans support running databases as Tor hidden services with full root access and pre-configured Tor. We offer PostgreSQL, MySQL, and MongoDB-ready servers with client authorization pre-configured for secure remote database access.

Our offshore servers in Iceland, Romania, and Finland provide privacy-friendly jurisdictions with NVMe SSD storage for fast database I/O. Pay with Bitcoin, Monero, or other cryptocurrencies — no KYC, no identity verification. Our support team can assist with database-specific Tor configurations, SSL setup, and access control policies.