Backup over Tor with BackupPC //at 04:37 //by abe

I have a Raspberry Pi at my parents home. They have internet access via some ISP using Carrier Grade NAT (CGN). Hence their home router is not reachable via IPv4 from the outside, they do have IPv6 and the devices can also be made accessible via IPv6 via the local router.

Did that, was able to access my Raspberry Pi over IPv6 and SSH from the outside. So doing backup of that Raspberry Pi with BackupPC from the outside was a walk in the park.

Unfortunately the IPv6 prefix seems to change occasionally and the router only allows to configure explicit IPv6 addresses in firewall rules — so after a prefix change the configured rules no more match the devices IPv6 addresses. Meh.

So there were multiple possibilities to work around these restrictions and access a devices behind the router:

• Using a permanent VPN connection, e.g. OpenVPN.
• Using a software defined network (SDN), e.g. ZeroTier.
• Enabling a Tor Hidden Service to access the device via SSH and Tor.

Enabling a Tor Hidden Service for port 22 is a no-brainer and was done most quickly (actually it already was in place as I already suspected that an IPv6 prefix change might happen) and I so far was too lazy to replace it with something more proper.

But my backup was relying on direct SSH access via IPv6. So I needed to get that working over Tor, too.

Here’s what was needed for the host named “sherpa” (named after the Fiberfab Sherpa) to be backed up via Tor:

• Make sure the folloing packages are installed on the BackupPC server:
  • netcat-openbsd (netcat-traditional might work, too, but then needs different commandline options)
  • ssh-tools for ssh-ping
  • tor (of course :-)
• Add these lines to ~backuppc/.ssh/config:

  Host sherpa_via_tor
          Hostname abcdefghijklmnop.onion
          ProxyCommand /bin/nc.openbsd -X 5 -x localhost:9050 %h %p
  

  These lines basically configure an alias hostname for ssh which then connects via SOCKS5 to the Tor daemon instead of doing DNS lookup and connection itself. It also configures the actual hostname (a Tor “.onion” hostname) to connect to.
• Add the following lines to /etc/backuppc/sherpa.pl:

  $Conf{ClientNameAlias} = 'sherpa_via_tor';
  $Conf{PingCmd} = '/usr/bin/ssh-ping -c 1 $host';
  $Conf{NmbLookupFindHostCmd} = "";
  

  These lines configure a few things in BackupPC:
  • Use the hostname alias declared in .ssh/config.
  • Use ssh-ping instead of standard ping as command to test connectivity. (ICMP neither works over SOCKS5 nor over Tor. And we configured the connection only for SSH anyways.)
  • Don’t try to do any DNS lookups on the given hostnames. (Otherwise you’ll get error messages like “Can’t find host sherpa_via_tor via netbios” in BackupPC’s per-host log files.)

That’s it basically.

Of course you also need to have the SSH public host key in the .ssh/known_hosts file also for the .onion hostname. And the Tor Hidden Service needs to be configured on the target device.

But that’s left as exercise for the reader. There’s a lot of documentation about that on the internet, including slides and video recordings of talks and live demos I gave about this topic in German.

Ah, and in case you might think that’s unfair and misuse of the resources of the Tor Project: No, I explicitly asked and they said more or less any additional traffic helps to make it more difficult to analyse Tor traffic or to track Tor users — and is hence welcome.

Addendum: The last direct full backup of that Raspberry Pi (5.5 GB) took around 32 minutes. The first full backup over Tor (8.7 GB) took 341 minutes. Seems much slower, but there might be other factors as well: Most backups which ran last night were running at only 0.85 MB/s to 1 MB/s, probably because too many backups were running in parallel after a recent backup server downtime with file system check — the backup server was probably the bottleneck. The backup of the Raspberry Pi over Tor ran at 0.42 MB/s, so about half the speed of the other backups. (Will probably add some more notes if I have more statistics over time.)

Tools for CLI Road Warriors: Tunnels //at 19:49 //by abe

Sometime the network you’re connected to is either untrusted (e.g. wireless) or castrated in some way. In both cases you want a tunnel to your trusted home base.

Following I’ll show you three completely different tunneling tools which may helpful while travelling.

sshuttle

sshuttle is a tool somewhere in between of automatic port forward and VPN. It tunnels arbitrary TCP connections and DNS through an SSH tunnel without requiring root access on the remote end of the SSH connection.

So it’s perfect for redirecting most of your traffic through an SSH tunnel to your favourite SSH server, e.g. to ensure your local privacy when you are online via a public, unencrypted WLAN (i.e. easy to sniff for everyone).

It runs on Linux and MacOS X and only needs a Python interpreter on the remote side. Requires root access (usually via sudo) on the client side, though.

It’s currently available at least in Debian Unstable and Testing (Wheezy) as well as in Ubuntu since 11.04 Natty.

Miredo

Miredo is an free and open-source implementation of Microsoft’s NAT-traversing Teredo IPv6 tunneling protocol for at least Linux, FreeBSD, NetBSD and MacOS X.

Miredo includes not only a Teredo client but also a Teredo server implementation. The developer of Miredo also runs a public Miredo server, so you don’t even need to install a server somewhere. If you run Debian or Ubuntu you just need to do apt-get install miredo as root and you have IPv6 connectivity. It’s that easy.

So it’s perfect to get a dynamic IPv6 tunnel for your laptop or mobile phone independently where you are and without the need to register any IPv6 tunnel or configure the Miredo client.

I usually use Miredo on my netbooks to be able to access my boxes at home (which are behind an IPv4 NAT router which is also an SixXS IPv6 tunnel endpoint) from whereever I am.

iodine

iodine is likely the most undermining tool in this set. It tunnels IPv4 over DNS, allowing you to make arbitrary network connections if you are on a network where nothing but DNS requests is allowed (i.e. only DNS packets reach the internet).

This is often the case on wireless LANs with landing page. They redirect all web traffic to the landing page. But the network’s routers try to avoid poisoning the client’s DNS cache with different DNS replies as they would get after the user is logged in. So DNS packets usually pass even the local network’s DNS servers unchanged, just TCP and other UDP packets are redirected until logging in.

With an iodine tunnel, it is possible get a network connection to the outside on such a network anyway. On startup iodine tries to automatically find the best parameters (MTU, request type, etc.) for the current environmenent. However that may fail if any DNS server in between imposes DNS request rate limits.

To be able to start such a tunnel you need to set up an iodine daemon somewhere on the internet. Choose a server which is not already a DNS server.

iodine is available in many distributions, e.g. in Debian and in Ubuntu.