Sunday 9th August 2020
Tor is a fantastic networking and privacy technology that makes private and anonymous browsing available to millions. Despite this, it is unfortunately seen by some people as a system that solely exists to facilitate an illegal criminal underground,
However, to take a literal view, Tor is just a networking tool, and it can be used in any way that you want. The features that enable privacy and anonymity are also extremely useful for many of the tasks carried out by Network Engineers and Systems Administrators on a daily basis. For example:
In this article, I will demonstrate how Tor can be used to carry out some of these tasks, and why using Tor may be advantageous to other methods.
In some network environments, IP address based access rules are used to either restrict or allow access to a service, or are used as a decision factor in a conditional access policy. For example, a common use-case is removing the requirement for two-factor authentication upon login if you are connecting from a trusted IP address, or requiring additional verification steps when connecting for the first time from a new location.
However, it is usually quite difficult to fully test such policies without access to multiple unique devices and/or VPNs.
Using Tor and the Tor Browser, you can test your access rules from multiple arbitrary external IP addresses. You can also very easily reset your browser profile or establish a new Tor circuit at any time, allowing you to very easily create a new 'identity' for testing, without the risk of previous tests impacting the results.
If you want to test something that isn't a web-based service, you can use the
torsocks wrapper to force the network connections of any program to be routed over Tor. For example, to test an IP address based SSH access rule, you could route an SSH connection over Tor to make it originate from a new/unknown IP address:
$ torsocks ssh jamieweb.net
torsocks cannot be used with setuid programs such as
ping, nor can it be used with programs that exclusively use UDP.
If you are hosting certain network services internally/on-site, e.g. web servers or mail servers, it can often be a challenge to properly test these from an external/public-facing perspective.
It's very important that this testing is carried out, as network services will often have differing configurations or policies depending on where you are connecting from. The lack of an easy way to perform this testing internally often leads to crude solutions involving personal devices or mobile data tethering, which are neither convenient or reliable.
However, similarly to how IP address based access rules can be tested with Tor, you can also use Tor to access your internally-hosted services from an external perspective. This will allow you to carry out all required testing from your standard device.
For example, you can use
torsocks with cURL:
$ torsocks curl https://www.jamieweb.net
Alternatively, if you don't want to use the
torsocks wrapper, you can point cURL to the local SOCKS5 proxy directly, which runs on
$ curl --socks5-hostname 127.0.0.1:9050 https://www.jamieweb.net
Most corporate networks operate a 'split-horizon' or 'split-brain' DNS setup, which is where a separate internally-hosted DNS server and associated zone is used to serve DNS requests that originate internally. The internal DNS server will often respond with 'internal' addresses, i.e. private or RFC1918 addresses, rather than 'external' public-facing addresses.
This is usually used in combination with a configured search domain or DNS scope, in order to allow internal services to be accessed via their direct hostname, without requiring the fully-qualified domain name (FQDN).
However, these split-horizon DNS setups can often pose a problem when you explicitly need a request to go to an external DNS server. Some networks will forcefully route all DNS traffic to the internal DNS server, and others will even intercept and rewrite DNS responses at the network edge, e.g. using the DNS doctoring or DNS NAT rewriting features that are present in many commercial edge firewall products.
You can usually get around these issues by forcing your external DNS lookups to take place over TCP, i.e. using the
+tcp option in DiG (also known as 'virtual circuit' mode), but this isn't always supported or available.
By routing your external DNS lookup over Tor, you can know for certain that the response hasn't been tampered with during the 'last mile' as it passes through your network edge:
$ torsocks dig +tcp @188.8.131.52 jamieweb.net
You'll need to use
+tcp mode, as well as ensure that the request will be routed directly to the external DNS server, and not through a local caching resolver such as
dnsmasq. This is because the Tor daemon will block requests to access local addresses such as
127.0.0.1. If you do accidentally attempt to access a local address, Tor will display the following error:
WARNING torsocks: [connect] Connection to a local address are denied since it might be a TCP DNS query to a local DNS server. Rejecting it for safety reasons. (in tsocks_connect() at connect.c:192)
In many corporate network environments, permitted outbound ports are limited in order to help ensure that all outbound traffic is tightly controlled, e.g. for the purposes of Data Loss Prevention (DLP).
However, for people in technical roles, this can pose quite a challenge, as various legitimate services will inadvertently be blocked too, and exceptions can be difficult to implement on a per-user basis.
A common one that is often overlooked is the WHOIS protocol, which operates on TCP port 43.
torsocks wrapper, you can route these requests through Tor in order to get around the blocked outbound port:
$ torsocks whois jamieweb.net
In some cases, firewalls performing Deep Packet Inspection (DPI) can also prevent certain connections to otherwise allowed ports. For example, a sysadmin using
openssl s_client to retrieve a certificate from a web server may have their request blocked, as they aren't establishing a full HTTPS connection.
However, by routing the request through Tor, the connection can be made successfully:
$ torsocks openssl s_client -connect jamieweb.net:443
There may be cases where you need to expose a locally running service to the internet, e.g. SSH or a web server. Unfortunately, this is often non-trivial due to NAT, and especially CGNAT (carrier-grade NAT).
One particular use case that I've worked on is accessing a 4G-connected device remotely using SSH. Because the majority of consumer data plans operate using CGNAT, you cannot just bind the service to your perceived public address and have it work, as there will potentially be hundreds of other customers sharing that same IP address. Multiple layers of NAT are often used too, which of course complicates things.
However, you can use Tor to expose your service via a Hidden Service, also known as a
.onion site. This way, your service will be easily accessible over Tor no matter how many layers of NAT or filtering you are behind.
This can be achieved by adding a few lines to your
/etc/tor/torrc configuration file:
HiddenServiceDir /var/lib/tor/my_service HiddenServicePort 22 127.0.0.1:22
HiddenServiceDir configuration specifies where your Hidden Service public/private keys will be stored. This should be an arbitrary directory in
/var/lib/tor/. You should not create this yourself, as the Tor daemon will create it for you using the correct permissions.
HiddenServicePort option is used to specify where incoming requests to a specific port will be forwarded to. In this case, requests to the Hidden Service on port
22 will be forwarded verbatim to
You can also optionally configure your Hidden Service in single-hop mode, which will allow it to connect to the Tor network using a single hop, rather than the usual three, potentially improving performance. This will completely de-anonymise your Hidden Service, so DO NOT use single-hop mode if your own anonymity is important. In most legitimate sysadmin use cases, single-hop mode is perfectly safe and acceptable.
You can enable single-hop mode by adding the following to your Hidden Service configuration:
HiddenServiceNonAnonymousMode 1 HiddenServiceSingleHopMode 1
However, running in single-hop mode will prevent your Tor daemon being used as a client, as your connection to the Tor network is not anonymised. If a SOCKS port is configured in your
torrc file, you'll also need to disable this:
Once you've finalised your Hidden Service configuration, save the
torrc file and restart the Tor daemon:
sudo service tor restart
You can now view the
/var/lib/tor/my_service/hostname file in order to identify the
.onion address for your Hidden Service. This can be used from any other Tor-capable device anywhere in the world in order to directly access your locally-hosted service.
This article covered just a few of the uses for Tor that I've come across over the years, but there is definitely a lot of further potential. I'd really love to see Tor take off as a systems administration tool, as it allows for some really unique and quirky networking tasks to be carried out with ease.
I'm definitely interested to hear about your own uses of Tor, so please feel free to contact me!