DDoS Mitigation for Tor Hidden Services: Self-Hosted Defense Strategies

Tor hidden services face several specific attack types. Introduction point flooding: overwhelming the Tor hidden service's introduction points with fake introduction requests (attackers send many connection attempts). Tor's Proof of Work mechanism specifically addresses this. Application-layer DDoS: legitimate-looking Tor circuits making many requests to expensive endpoints (search, file upload, database-heavy operations). Bandwidth exhaustion: high-volume traffic through Tor circuits intended to overwhelm server bandwidth or network interface. Slow HTTP attacks: Slowloris-style attacks opening many connections and sending requests very slowly, exhausting connection limits. Each attack type requires different mitigation.

Enable HiddenServicePoWDefensesEnabled 1 in torrc. This requires clients to solve computational puzzles before introduction requests are processed. Protects specifically against introduction point flooding. Configuration: HiddenServicePoWQueueRate 250 (requests per second), HiddenServicePoWQueueBurst 2500. When under attack, Tor automatically increases difficulty, making flooding computationally expensive for attackers while adding only milliseconds of delay for legitimate users running Tor 0.4.8+. Verify Tor version before enabling: PoW requires Tor 0.4.8.0+ on the hidden service server.

Nginx rate limiting for application-layer DDoS. Note: IP-based limiting is ineffective for hidden services (all connections appear from 127.0.0.1). Effective alternatives: connection-per-server limits (limit_conn server_limit 1000 limits total server connections), server-level rate limiting (limit_req zone=server based on server name rather than IP), application endpoint rate limiting (apply strict limits to expensive endpoints: search, file upload, registration), and resource-based limits (client_body_timeout 10; client_header_timeout 10 disconnect slow clients).

Application-layer defenses complementing network-level measures: circuit-breaking for expensive operations (if a search query takes more than 5 seconds, return a service-degraded response rather than consuming more resources), queue-based request handling (offload expensive requests to a queue, return immediately with a job ID, deliver results when complete), resource scaling (automatically provision more backend capacity during high-load periods if the architecture supports it), and CAPTCHA on high-value endpoints (registration, search, file upload) to require human interaction for expensive operations.

OnionBalance distributes traffic across multiple backend servers behind a single .onion address. Under DDoS: the attack load is distributed across multiple backends. If one backend is overwhelmed, OnionBalance routes traffic to others. Adding backends during an attack increases total capacity. For sustained high-volume attacks that exceed single-server capacity, horizontal scaling is the primary mitigation. Each backend server applies its own Nginx and application-layer defenses, multiplying total defense capacity. Pre-provision additional backends in standby mode for rapid activation during attacks.