Can fail2ban be used to protect a .onion service?

fail2ban monitors log files and blocks IPs using iptables. Since all Tor client connections appear from 127.0.0.1, fail2ban would block localhost traffic if triggered - blocking ALL clients. fail2ban is not useful for protecting against attacks from Tor clients. It can still be used to protect the SSH admin access (blocking external IPs attempting SSH brute force) and any clearnet-accessible ports. For .onion-specific protection: rely on Tor PoW defense, application rate limiting, and CAPTCHA challenges rather than fail2ban.

Does Tor PoW defense break Tor Browser functionality?

Tor PoW defense is transparent to users: it is implemented in the Tor protocol layer before HTTP. Tor Browser's built-in Tor client automatically handles the PoW computation. Users see slightly longer connection establishment times when PoW difficulty is elevated (seconds of delay rather than the normal sub-second circuit setup). The delay is proportional to the PoW difficulty. Under normal load (no active attack): PoW difficulty is minimal and unnoticeable. Under heavy DoS: legitimate users experience 1-10 seconds of extra connection time, which is acceptable. Automated bot floods experience the same delay but must compute PoW at massive scale, limiting their effective attack rate.

What is the maximum request rate a .onion service can handle?

Server capacity depends on: the application's response time per request, server CPU/RAM, and Tor daemon capacity. A well-optimized nginx+app stack on Iceland VPS II can handle 1,000-10,000 requests per second if all requests come from 127.0.0.1 (no network latency for the server itself). The practical bottleneck is Tor circuit capacity: each Tor circuit (from client to the hidden service's introduction points) has limited throughput. The hidden service rendezvous circuit handles multiple clients. Under heavy load, Tor's introduction circuit queue fills before the server's CPU is saturated. Tor PoW defense and circuit queue management are the primary tools for high-load .onion services.

How do I differentiate legitimate users from bots on a .onion service?

Bot characteristics on .onion services: no session cookie (bots often ignore cookies), user-agent strings not matching Tor Browser (bots use custom user-agents), very high request rates with consistent timing patterns, and requests for non-existent paths (scanning behavior). Mitigation: check User-Agent for Tor Browser patterns (though bots can fake this), require session cookies for resource-intensive operations, monitor request timing patterns for suspicious regularity, and implement CAPTCHA for actions with high abuse potential (registration, search, file upload).

Should I notify users when my .onion service is under DoS attack?

Yes. If an attack causes noticeable degradation: post a status update via an alternative channel (social media via Tor, a secondary .onion status page, or a Telegram community channel). Users experiencing slow connections or timeouts will otherwise assume the service is down or their Tor is misconfigured. A status page (.onion address for a simple HTML status indicator) that updates independently from the main service provides users with accurate information during incidents.

Rate Limiting for Tor Hidden Services

Tor hidden services face unique DoS and abuse challenges: all client IPs appear as 127.0.0.1 (delivered via localhost by Tor), making traditional IP-based rate limiting ineffective. Effective protection requires a combination of Tor's built-in PoW defense, application-level rate limiting, and nginx-level throttling that works within Tor's unique networking model.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

The Unique Challenge of Rate Limiting Tor Clients

Standard rate limiting operates on client IP addresses: if an IP sends too many requests, limit or block it. With Tor hidden services, all connections arrive from the Tor process on 127.0.0.1 (or via Unix socket). From nginx's perspective, every client connection comes from 127.0.0.1 regardless of the actual client. IP-based rate limiting would rate-limit ALL clients simultaneously (since they all share 127.0.0.1). This is why Tor's Proof of Work (PoW) defense exists: it operates at the Tor protocol layer, before the HTTP layer, and can differentiate clients by their cryptographic session. At the nginx/application layer: rate limiting must be based on non-IP identifiers. Options: session-based rate limiting (rate limit per authenticated session or cookie), API key-based rate limiting, rate limiting per Tor client introduction point (advanced, requires stem library integration), and coarse time-window limiting on overall traffic volume.

Enabling Tor PoW Defense for Hidden Services

Tor's Proof of Work (PoW) defense requires connecting clients to compute a hashcash-style puzzle before the hidden service processes their connection. This is implemented in Tor 0.4.8+ and defends against DoS floods. Enable in torrc: HiddenServicePoWDefensesEnabled 1. Optional parameter: HiddenServicePoWQueueRate (connections per second with PoW verification allowed), HiddenServicePoWQueueBurst (burst allowance). The PoW difficulty adjusts dynamically based on introduction circuit queue depth - when the service is not under load, PoW difficulty is minimal (0-1ms computation). Under heavy load, difficulty increases to 10-100ms computation, significantly reducing the rate of DoS connections. Legitimate users experience slightly slower connection setup under load but eventually connect. Bot floods face exponentially higher computational costs to maintain the same connection rate.

Nginx Rate Limiting for .onion Services

nginx's limit_req module implements rate limiting. For .onion services where all traffic appears from 127.0.0.1, configure rate limiting based on the X-Real-IP header (if set by Tor, which it typically is not) or use binary_remote_addr (which is 127.0.0.1 for all clients - same problem). Alternative: use the $cookie_session_id variable for per-session rate limiting. Define a zone: limit_req_zone $cookie_session_id zone=session_limit:10m rate=30r/m (30 requests per minute per session cookie). Apply to location blocks: limit_req zone=session_limit burst=5 nodelay;. For unauthenticated endpoints: use overall connection rate limiting per server: limit_conn_zone $server_name zone=server:10m; limit_conn server 1000; (limit total concurrent connections to the server to 1000 regardless of source). This prevents resource exhaustion but does not discriminate between legitimate and abusive clients.

Application-Level Rate Limiting Strategies

Application frameworks provide rate limiting based on application identifiers: (1) API key rate limiting: enforce per-API-key rate limits (e.g., 100 requests per minute per key). Implemented in middleware. (2) Session rate limiting: after authentication, apply per-session limits tracked in Redis. (3) CAPTCHA for anonymous access: for unauthenticated endpoints that serve high value (search, registration), require a CAPTCHA challenge for repeated access without authentication. Self-hosted CAPTCHA (altcha.org, mCaptcha) avoids clearnet dependency. (4) Proof-of-work CAPTCHA in application: JavaScript-based PoW challenge that the browser must solve before certain actions (anti-spam registration). Works even without IP information. (5) Content addressing: if the service allows uploading content, hash-based deduplication prevents the same content from being uploaded repeatedly (spam content addresses are identical hashes).

Monitoring and Alerting for DoS Attacks on .onion Services

Detecting DoS attacks on .onion services from logs: monitor nginx access log rate per time window. A sudden spike in request rate (even all from 127.0.0.1) indicates an attack. Log analysis: awk '{print $4}' access.log | sort | uniq -c | sort -rn | head -20 shows request rate by time. Prometheus + alert rule: if request rate exceeds 10x the normal baseline for more than 30 seconds, fire an alert. Systemd journal monitoring: track Tor daemon log messages about introduction circuit queue depth (indication of PoW defense activation). Configure alert via Telegram bot (Tor-proxied) when: Tor PoW defense activates (log message), nginx returns 503 Service Unavailable at elevated rate (from nginx error log), or server CPU/RAM exceeds 80% (from node_exporter Prometheus alert).

Related Services

Offshore VPS from $17.90/mo Dedicated Servers DevOps Services

Why Anubiz Host

100% async — no calls, no meetings

Delivered in days, not weeks

Full documentation included

Production-grade from day one

Security-first approach

Post-delivery support included

Bulletproof Hosting Providers

DMCA-Ignored Servers

Offshore VPS Hosting

Anonymous Hosting Solutions

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Start a Brief Iceland VPS II