search

bugfest / tor-controller

Tor toolkit for Kubernetes (Tor instances, onion services and more)
Apache License 2.0
98 stars 17 forks source link

[REQUEST] Transparent Proxy Injection #60

Closed stevefan1999-personal closed 7 months ago

stevefan1999-personal commented 10 months ago

Is your feature request related to a problem? Please describe. I want to redirect the traffic of my application to Tor, but I also need to retain some compatibility with local pod communication.

This is needed in case some threat actors got access to my container so they can curl off a specific IP reflector service (such as checkip.amazonaws.com) to expose my host IP address (fortunately, this can be mitigated by enforcing a strict network policy), or if I want to access email service hosted as onion HS (unfortunately, this cannot be mitigated by enforcing a strict network policy since it is application specific).

Describe the solution you'd like I want to route all external network traffic to a transparent proxy tapwired to a Tor CRD object, or inject the Tor daemon on the fly as well, but in the end still let my pods to connect to each other.

This is possible by injecting sidecar containers that modified the iptables of the pod's network namespace that DNAT to a specific destination, which is quite tricky and hacky, but it theoretically works.

Automatically inject the tor daemon, transparent proxy as init containers, and only rewrite the pods by a specific tor-egress-transparent-proxy: true label, just like Istio.

Describe alternatives you've considered Make and expose my own transparent port service like redsocks and squid, forward the traffic to Tor, carefully audit the container image and configuration (make sure http_proxy/https_proxy/socks_proxy) to the transparent port service. In other words, rely on ostrichism and hope that no one found and exploited an 0day of your favorite forum software in the dark web.

In a nutshell it looks like this: pod <-> redsocks/squid (internal) <-> CNI pod <-> redsocks/squid (external) <-> Tor

Additional context There is a proof-of-concept implemented: https://github.com/horodchukanton/kubernetes-tproxy

bugfest commented 10 months ago

Hi @stevefan1999-personal, The idea is cool, the implementation... might be a nightmare xD. So, if understand you well, you'd this would be like a "tor-cni" so that your pods will talk teach other via tor?

IMHO that might cause some issues when k8s API is involved due to latency and network issues.

I don't think this can be implemented by this project, but it's a idea I could explore in a separate repo/project. In this regard, tor-controller might help you by setting up per-node tor instances to expose your pod's services as onion addresses that can be reached by your others pods somehow. I guess the distribution and synchronization of those addresses would be the complex part.

Regarding outgoing traffic you can setup your own sidecars to use a local tor instance to use as a socks or http proxy, so I guess that one is easy and you could find documentation online to configure such a thing.