DDoS Protection for .onion Services

Starting with Tor 0.4.8, hidden services support a proof-of-work (PoW) mechanism that requires clients to solve a computational puzzle before connecting. During normal operation, the puzzle is trivial. Under DDoS conditions, the difficulty automatically increases, forcing attackers to expend significant CPU resources for each connection attempt:

# /etc/tor/torrc — Enable proof-of-work defense
HiddenServiceDir /var/lib/tor/my_hidden_service/
HiddenServicePort 80 127.0.0.1:8080
HiddenServiceVersion 3
HiddenServicePoWDefensesEnabled 1
HiddenServicePoWQueueRate 200
HiddenServicePoWQueueBurst 2500

HiddenServicePoWDefensesEnabled 1 activates the EquiX proof-of-work scheme. The queue rate and burst parameters control how many connections per second are served and the maximum queue size. During a flood, clients that solve harder puzzles get priority, while the attacker must burn CPU cycles for every connection.

This defense requires Tor Browser 13.0 or later on the client side. Older clients will still connect but will not benefit from prioritization during attacks.

Since all Tor connections arrive from 127.0.0.1, standard IP-based rate limiting is ineffective. Instead, implement rate limiting at the application layer using session tokens, CAPTCHAs, or connection-based limits in Nginx:

# Nginx rate limiting by connection (not IP)
limit_conn_zone $binary_remote_addr zone=tor_conn:10m;
limit_req_zone $binary_remote_addr zone=tor_req:10m rate=10r/s;

server {
    listen 127.0.0.1:8080;

    limit_conn tor_conn 50;
    limit_req zone=tor_req burst=20 nodelay;

    # Custom error page for rate-limited requests
    error_page 429 /rate-limited.html;
    error_page 503 /overloaded.html;
}

For more granular control, implement application-level challenges. Serve a JavaScript-based proof-of-work or a CAPTCHA on the first visit, issuing a session cookie to legitimate users. This lets human visitors browse normally while automated flood traffic is blocked at the application layer.

Beyond software defenses, infrastructure design plays a key role in surviving DDoS attacks on your hidden service. Use OnionBalance to distribute traffic across multiple backend servers — if one server is overwhelmed, others continue serving requests. Each backend runs its own Tor instance, making it harder for attackers to target all of them simultaneously.

Allocate generous resources to your Tor daemon process. DDoS attacks on hidden services often exhaust CPU and memory on the Tor process itself, not the web server. Ensure your server has at least 2 dedicated CPU cores and 2GB RAM available for Tor during attack conditions. Configure Tor connection limits and use circuit-level rate limiting where available.

Monitor your hidden service actively using Tor-based health checks. Configure alerts for connection queue growth, descriptor publishing failures, and abnormal CPU usage on the Tor process. Early detection allows you to enable higher PoW difficulty or spin up additional OnionBalance backends before the attack overwhelms your service.

AnubizHost deploys Tor hidden services on infrastructure designed to withstand DDoS attacks. Our servers feature multi-core processors, generous RAM, and NVMe storage that keeps Tor responsive under load. We pre-configure proof-of-work defenses, rate limiting, and monitoring for every managed Tor hosting plan.

Hosted in Iceland, Romania, and Finland on hardware with DDoS-resistant network connectivity, your .onion service benefits from both application-layer and network-layer protections. Pay with Bitcoin, Monero, or other cryptocurrencies — no KYC required. Our team monitors your hidden service and responds to attacks proactively.