Proof of concept implementation of tor2tcp.
Clone config files: $ git clone https://ghom.niij.org/eaon/tor2tcp-sample.git
Say for example you have a website that you feel comfortable having online via a public domain name, but you do not feel comfortable having it hosted on the location of its clearnet IP because $reason (for example you are The Pirate Bay). Or you want to store all your e-mail in an undisclosed location. This configuration enables the transferring machine to know as little as possible about the actual hosting machine (because it's really a .onion) while using very little resources (i.e. a VPS with 128MB RAM for little $currency/$timeframe) on the transparent proxy machine and even less time to set it up.
tor2tcp attempts to:
18.104.22.168 is the IP of our example VPS. The following bits enable us to forward incoming connections to our hidden service.
TransPort 22.214.171.124:80 MapAddress 126.96.36.199 duskgytldkxiuqc6.onion Tor2webMode 1 # when ./configure --enable-tor2web-mode
For multiple ports, in our case https and smtp related ports, we can redirect traffic via iptables:
iptables -t nat -A PREROUTING -p tcp -d 188.8.131.52 --dport 443 -j REDIRECT --to-ports 80 iptables -t nat -A PREROUTING -p tcp -d 184.108.40.206 --dport 25 -j REDIRECT --to-ports 80 iptables -t nat -A PREROUTING -p tcp -d 220.127.116.11 --dport 465 -j REDIRECT --to-ports 80 iptables -t nat -A PREROUTING -p tcp -d 18.104.22.168 --dport 587 -j REDIRECT --to-ports 80
At Aaron Swartz Hackathon NYC I successfully tested establishing a TLS encrypted connection with a hidden service from the clearnet: Web, and now also Mail. There is nothing special about that setup, it is identical to setting up a hidden service based web and mailserver.
Since we don't want to be **** SPAM ****, we need to send all our mail via the incoming transparent proxy machine. We don't want to turn our proxy into a mail relay as we want to avoid having any data on that machine (like a mail queue or logs). To do this in an anonymous fashion, we can use a torified ssh SOCKS5 tunnel, and redirect Postfix' traffic to that tunnel.
tmux new-session -d 'torsocks autossh -D 1080 firstname.lastname@example.org'
autossh helps us keep the connection to our transparent proxy open, enabling us to leave the setup unattended, while tmux is just in there because for some reason backgrounding autossh did not work properly for me.
The last issue that remains is, Postfix chokes on TCP based DNS requests, and Tor does not yet support MX record lookups, so we need a way to tunnel our DNS requests as well. dns-tcp-socks-proxy comes in handy here. My dns_proxy.conf looks like this:
socks_port = 1080 socks_addr = 127.0.0.1 listen_addr = 127.0.0.1 listen_port = 53 set_user = nobody set_group = nogroup resolv_conf = resolv.conf log_file = /dev/null
22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206
After all of that is up and running, we an finally redirect Postfix' traffic (including DNS) through our torified SOCKS5 tunnel:
iptables -t nat -A OUTPUT ! -o lo -p tcp -m owner --uid-owner postfix -m tcp -j REDIRECT --to-ports 12345 iptables -t nat -A OUTPUT ! -o lo -p udp -m owner --uid-owner postfix -m udp --dport 53 -j REDIRECT --to-ports 53 iptables -t filter -A OUTPUT -p tcp -m owner --uid-owner postfix -m tcp --dport 12345 -j ACCEPT iptables -t filter -A OUTPUT -p udp -m owner --uid-owner postfix -m udp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT ! -o lo -m owner --uid-owner postfix -j DROP
And that's it! This should work for other services like XMPP as well. That needs further testing though.