Rate Limiting and Abuse Prevention for Tor Hidden Services

Standard abuse prevention relies on IP blocking and rate limiting by source IP. On Tor hidden services, all traffic arrives via Tor's internal onion routing - the origin IP from the server's perspective is always a local Tor circuit ID, not the client's real IP. IP-based blocking bans Tor circuit IDs that are ephemeral and frequently rotated, making IP blocking useless against persistent abusers. Rate limiting by IP would rate-limit ALL users sharing the same circuit connection, which from the server's perspective may appear as a single source. Alternative strategies must work without IP attribution.

Tor's newer versions support Proof of Work (PoW) requirements for accessing hidden services. When PoW is enabled (HiddenServicePoW 1 in torrc), clients must solve a computational puzzle before being granted introduction circuit access. This is transparent to users (Tor Browser handles it automatically) but creates friction for automated attack tools. The PoW difficulty auto-scales based on network load - when the service is under DDoS, difficulty increases, requiring more computation per connection attempt. Configure in torrc: HiddenServicePoWQueueRate and HiddenServicePoWQueueBurst parameters control the queue rate for PoW-validated connections. Requires Tor 0.4.8+ and matching Tor Browser support.

Rate limit by application-level identifiers rather than IP. Session tokens: issue cryptographic session tokens on first connection, rate limit by session token rather than IP. CAPTCHA gates: require CAPTCHA completion to obtain a session token. Sliding window rate limits based on endpoint (path): limit requests per time window to a specific endpoint (e.g., maximum 10 login attempts per 10 minutes to /login, measured globally across all clients). Token buckets for API endpoints limit total throughput. These approaches do not prevent determined attackers from creating new sessions but raise the cost of abuse for automated tools.

Nginx's limit_req_zone and limit_conn_zone can limit by remote address but this is ineffective for Tor (all connections appear from one address). Instead, apply rate limiting by URI pattern to limit total requests to specific paths. Example: limit_req_zone $uri zone=per_uri:10m rate=100r/s; - this limits global request rate to 100/s for each distinct URI regardless of client identity. Combined with small burst allowances, this prevents any single endpoint from being overwhelmed. For authenticated endpoints, pass a session identifier to rate limit by and use Nginx's $cookie_session or $http_x_session_id as the rate limiting key.

Protect high-value endpoints (registration, login, password reset) with CAPTCHA that works within Tor. Standard CAPTCHAs (Google reCAPTCHA, hCaptcha) often block Tor exit IPs. Alternatives: text-based CAPTCHA generated server-side (no external service), proof-of-work CAPTCHA using hashcash-style computations (client computes a hash meeting a difficulty target), knowledge-based challenge (human-evaluable questions requiring common knowledge), and audio CAPTCHA for accessibility. For hidden services expecting legitimate users who accept the privacy model, proof-of-work CAPTCHA is the most user-friendly alternative that also resists automated abuse.