The Security Model

This page is the honest version: what HiddenForge protects, how, and where the protection stops. If you're relying on this for something that matters, read the limits at the bottom as carefully as the features at the top.

What it's protecting against

The core promise is network-layer location privacy: nobody who watches the connection, and nobody who connects to your service, should be able to learn where your server is. Everything below serves that goal, plus keeping the container itself hard to break out of if your app is compromised.

The layers

Your backend is unreachable

Your app runs on an internal-only network. It has no route to the internet and publishes no ports, so it can't be scanned or connected to from outside. The only thing that can reach it is Tor, running alongside it. Even if someone knew your app existed, they'd have nowhere to knock.

Tor runs unprivileged and sandboxed

The container starts as root only long enough to write the config and fix permissions, then drops to an unprivileged tor user. Tor's own seccomp sandbox (Sandbox 1) filters the system calls it's allowed to make, so a Tor exploit has far less room to move. Docker's default seccomp is turned off on purpose here so it doesn't collide with Tor's own sandbox; Tor does the filtering.

The container is locked down

• Read-only filesystem. The container can't write anywhere except a few small in-memory scratch areas, and those are marked no-execute, no-setuid, no-device.
• All Linux capabilities dropped, then only the few genuinely needed are added back (to fix key-folder ownership and to drop privileges). Nothing else.
• No new privileges. A setuid binary inside the container can't be used to escalate.
• No swap. Memory and swap limits are set equal, so the process can't be paged to disk. Your keys never touch storage as swap.
• Resource caps. Memory, CPU, process count, and open-file limits are bounded, so a fork bomb or memory blowup is contained.
• No host logs. Docker is told to write no log file for the container, matching Tor's own "avoid disk writes" setting.

Tor is configured for a service, not a client

• It will never become a relay or exit node (ClientOnly, plus an exit policy that rejects everything). It won't carry other people's traffic.
• The SOCKS proxy is off. This is a publisher, not a way to route your own browsing.
• Logs are scrubbed of IPs and addresses, debugger attachment is blocked, and heartbeat log spam is off.

Flood defenses are on

Onion services are a target for denial-of-service floods. HiddenForge enables two independent defenses per service:

• Proof-of-work, which makes attackers burn CPU to reach the rendezvous stage under load.
• Intro-point rate limiting, which throttles the flood of introduction requests at a different choke point.

It also caps streams per circuit and drops circuits that overrun.

Vanguards guards the guards

Every Tor circuit starts at a small set of guard relays. An attacker who can figure out which guards your long-lived service uses has taken a step toward locating the server. The Vanguards addon defends against this. In HiddenForge it runs two of its modules fully, bandguards (which watches for bandwidth side-channel attacks) and rendguard (which watches for rendezvous-point abuse), alongside Tor's own built-in "vanguards-lite" guard rotation.

The limits (read these)

Being honest about what this does not do is part of the security model.

• Guard protection is L2-level, not full L2+L3. Vanguards has a third module that pins the deeper guard layers, but it needs a Tor command that Tor's sandbox blocks, so HiddenForge leaves it off and relies on Tor's built-in vanguards-lite for that layer. Vanguards-lite is aimed at shorter-lived services and doesn't save its guard choices to disk, so the deeper topology resets when Tor restarts. If you run a long-lived, high-risk service that needs full L2+L3 guard protection, the right answer is to run the full Vanguards addon with Tor's sandbox turned off, on a dedicated hardened host. That's a deliberate tradeoff HiddenForge does not make for you.
• Vanguards can be absent. If it fails to start or crashes for good, your service keeps running on vanguards-lite alone. That's degraded protection, not none, but know that it can happen.
• It does not protect your application. A bug in your web app that leaks an internal IP, a real name, or an EXIF-tagged photo will deanonymize you no matter how good the network layer is. See OPSEC: Mistakes That Deanonymize You.
• It does not protect a compromised host. If the machine running the container is owned, the game is over. HiddenForge hardens the container, not the box under it.
• It does not beat a global passive adversary. An attacker who can watch traffic entering and leaving the whole Tor network at once can, in principle, correlate timing end to end. That's a limit of Tor itself, not of HiddenForge.

The trust anchor

You don't have to take any of this on faith. The image is signed, and the build is reproducible, so you can confirm the thing you're running is the thing described here. See Verifying the Image.