DEV Community

Cover image for Building a Stateless, RAM-Only Transparent Tor Proxy for Linux (TTP v0.3.0)
onyks
onyks

Posted on

Building a Stateless, RAM-Only Transparent Tor Proxy for Linux (TTP v0.3.0)

Transparent Tor Proxy (TTP) is a Linux CLI tool designed to intercept all outgoing network traffic and force it through the Tor network using nftables. Version 0.3.0 introduces a major architectural shift focused on system integrity and forensic invisibility, transitioning the application to a fully volatile runtime.

The Challenge

Classic transparent proxy implementations often suffer from severe state management issues. System configurations, such as /etc/resolv.conf, are typically overwritten directly. Furthermore, the default system Tor daemon (tor.service) is usually hijacked, leading to permission conflicts and disrupting any pre-existing background Tor relays.

The v0.3.0 Solution: Amnesia Core

The application core has been redesigned to operate almost entirely in volatile memory.

  • Volatile Standard Core: All runtime metadata, lock files, and logs are now stored in /run/ttp, which utilizes a tmpfs mount. This ensures zero physical traces are left on the host's physical disk after a power cycle.
  • Native Service Management: Tor is executed as a dedicated ttp-tor.service systemd unit. The volatile unit file is dynamically generated in /run/systemd/system/, avoiding interference with the system's own tor.service and bypassing its sandboxing restrictions.
  • Conflict Resolution: Daemon management is handled via a private Unix ControlSocket located at /run/tor/ttp/control.sock. SocksPort is set to 0 by default, allowing TTP to coexist alongside other Tor instances without triggering "Address already in use" errors.
  • Stateless DNS Overlay: Physical overwrites of /etc/resolv.conf have been replaced with a kernel-level mount --bind strategy. This achieves non-destructive redirection of DNS queries. Stale DNS mount overlays are automatically cleared to ensure absolute idempotency, and a lazy unmount fallback (umount -l) ensures successful removal during teardown even if the resource is busy.

Network Safety and Memory Trade-offs

Operating exclusively in RAM introduces specific constraints that require careful resource and state management.

  • Graceful Teardown: A cryptographic SHUTDOWN signal is sent to the Tor daemon before nftables firewall rules are removed. This guarantees all circuits close cleanly and strictly prevents cleartext RST packet leaks on the physical interface.
  • Persistent Entry Guards: Bootstrapping Tor entirely from scratch on every execution introduces severe latency. To mitigate this, DataDirectory /var/lib/tor/ttp/ is utilized to preserve Entry Guards across runs, maintaining a fast bootstrap time of approximately 3 seconds.
  • Resource Management: Logs have been moved to /run/ttp/ttp.log and are capped at a 1MB limit to prevent memory exhaustion in the RAM disk. Additionally, a pre-flight safety check is performed to verify sufficient tmpfs space is available before execution, preventing out-of-memory crashes mid-setup.

The networking logic utilizes a dedicated inet ttp table for nftables, ensuring all firewall modifications are isolated and cleanup is executed atomically via an nft destroy command.

Disclaimer: Entry guards are maintained in a persistent cache to facilitate rapid initialization. Although a setting to modify this behavior is currently absent, its introduction is expected in a subsequent version. It must be noted that standard OS-level logging, including systemd journals, remains active, meaning the tool is not forensically invisible or reliable for high-stakes anonymity. For scenarios necessitating absolute forensic protection, the use of TailsOS and the TOR Browser is advised.

Repository: TransparentTorProxy on GitHub

Top comments (0)