OnionBalance and the hard truth about DDoS protection for hidden services
When waves of denial-of-service traffic battered the Tor network from mid-2022 well into 2023, many onion operators reached for OnionBalance as their first line of defense. The tool helped some sites stay reachable. It also gave others a false sense of security that cost them uptime when attackers simply shifted targets.
How frontend and backend balancing actually works
OnionBalance is a load balancer for onion services, maintained under the Tor Project umbrella. Instead of one hidden service, operators run several independent backend instances, each with its own onion address and its own introduction points. A separate management server holds the master key and publishes a single combined descriptor for the public address. That descriptor merges the introduction points of all healthy backends, so clients connecting to the public .onion are effectively routed to whichever instance they reach first. If a backend drops offline, its introductions fall out of the descriptor on the next refresh cycle. The project's own documentation describes this as distributing "introduction and rendezvous requests across multiple hosts" (OnionBalance tutorial). A useful side effect is key hygiene: the long-term identity key lives on the isolated management server, never on the machines serving traffic. Backend keys can be rotated freely without changing the public address. That is resilience by design, not by accident.What it does against DDoS - and what it cannot do
During the attack waves documented on the Tor Project status page, which stretched from June 2022 through spring 2023, spread-out architectures clearly fared better than single-instance services (Tor status). Flooding one backend no longer kills the site, because remaining instances keep publishing descriptors and accepting rendezvous traffic. Redundancy raises the attacker's cost. But here is the catch. OnionBalance balances connections; it does not filter them. Every junk request still reaches a real backend, and application-layer floods can exhaust CPU, memory, or database pools on all instances simultaneously. As Tor developer Mike Perry noted in mid-2023, the bulk of observed attacks were onion-service related, meaning traffic arrived through Tor itself, where IP-based rate limiting is useless (tor-project mailing list).Redundancy buys availability under partial failure. It does not buy capacity against a determined flood.
The missing layer: PoW defenses in Tor 0.4.8
The real shift came in August 2023, when the Tor Project shipped a proof-of-work defense for onion services in Tor 0.4.8. When a service is under stress, incoming clients must solve a small EquiX puzzle before their introduction request is queued, and connections are prioritized by demonstrated effort (Tor Project blog). Legitimate users typically wait milliseconds; attackers scaling to millions of requests face compounding compute costs. Crucially, this mechanism operates at the introduction layer, which is exactly where OnionBalance aggregates backends. The two stack well: balancing spreads whatever gets through, while proof-of-work throttles what gets in. Operators running current Tor versions on every backend get both benefits per instance.Common misconfigurations that undo the protection
The Tor Project's DoS guidelines stress that no single measure fits every attack, and combinations need tailoring (community documentation). In practice, most OnionBalance failures trace back to avoidable setup errors:- All backends behind one guard relay or one host, creating a bottleneck an attacker can saturate.
- A stale REFRESH_INTERVAL leaving dead introduction points published for ten minutes or longer after a backend dies.
- Sessions stored locally on each backend instead of shared storage, so users bounce between instances and log in repeatedly.
- PoW defaults left untouched on backends while operators assume the frontend handles filtering.