DDoS Protection Strategies for Tor Hidden Services

Unlike clearnet DDoS that primarily targets network bandwidth or server CPU, hidden service DDoS specifically targets the Tor circuit establishment process. An attacker who wants to take down a hidden service creates many Tor circuits to the service's introduction points. Each circuit establishment requires cryptographic operations from the hidden service's Tor process, and the Tor process has a maximum rate at which it can handle circuit establishment requests.

When circuit establishment requests exceed the Tor process's capacity, the introduction points queue up and eventually reject connection attempts. Legitimate users trying to connect see "circuit build failed" errors or extremely long connection times. The attack does not require the attacker to have high bandwidth; it only requires the ability to create many circuits quickly, which any Tor user can do with a modified Tor client.

This attack was historically a serious problem for high-profile hidden services. The Tor Project responded by implementing proof-of-work (PoW) challenges in Tor 0.4.8, released in 2023. PoW requires clients to solve a computationally difficult puzzle before an introduction point will forward their connection request to the service. The difficulty scales automatically when the service detects it is under attack.

Proof-of-work defense is available in Tor 0.4.8 and later. Ensure your server runs a current Tor version: tor --version. Enable PoW defense in torrc:

HiddenServicePoWDefensesEnabled 1
HiddenServicePoWQueueRate 10
HiddenServicePoWQueueBurst 50

HiddenServicePoWDefensesEnabled 1 enables the PoW challenge system. When attack conditions are detected (introduction point queue growing rapidly), Tor automatically starts requiring clients to solve hashcash-style puzzles before their connections are processed. The difficulty adjusts dynamically based on the attack intensity.

HiddenServicePoWQueueRate and HiddenServicePoWQueueBurst control the introduction point processing rate. Lower values reduce the service's vulnerability to circuit flooding but also reduce legitimate connection throughput. Start with the values above and adjust based on your service's normal connection patterns.

nginx rate limiting operates at the application layer, above the Tor circuit level. While it cannot prevent circuit-level attacks, it prevents attackers who have established circuits from making excessive application requests. Configure rate limiting in nginx:

limit_req_zone $binary_remote_addr zone=onion:10m rate=10r/m;

server {
    limit_req zone=onion burst=20 nodelay;
    limit_req_status 429;
}

For hidden services, the remote address is always 127.0.0.1 (all connections come from the local Tor process). Standard IP-based rate limiting is therefore ineffective - all clients appear to have the same IP. Rate limit by session token or by behavioral patterns (request frequency, path patterns) rather than by IP address for hidden service deployments.

The most effective application-level rate limiting for hidden services uses application session rate limiting. Users receive a session token at login or first visit. Rate limits apply per token, which the application controls. Tokens that exceed limits can be throttled or revoked without affecting other users. Implement this in the application code, not at the nginx layer.

No DDoS protection eliminates all attack risk; defense-in-depth combined with sufficient capacity to absorb attacks provides the best resilience. Size the hidden service infrastructure with enough headroom to continue serving legitimate users during a moderate attack that consumes 50 to 70% of circuit establishment capacity.

Scale the tor process horizontally by running multiple tor instances each with separate HiddenServiceDir directories and combined with OnionBalance to publish a single onion address. An attacker must attack all Tor instances simultaneously to take down the service. Each additional tor instance increases attack cost proportionally.

Prepare a DDoS incident response runbook before attacks occur. The runbook should include: how to verify you are under attack vs a performance issue, steps to enable PoW defense if not already enabled, how to contact your hosting provider, and pre-written status update text for any public communication channels. Executing a practiced runbook during an attack is much faster than improvising responses under pressure.