Tor: A Powerful Tool for Sysadmins
Tor, short for The Onion Router, stands as a remarkable testament to the realms of networking and privacy technology. It renders private and anonymous browsing accessible to countless individuals worldwide. Regrettably, however, some still perceive Tor as nothing more than a tool catering exclusively to the clandestine activities of an illicit underground.
Yet, if we adopt a more literal perspective, Tor reveals itself as a versatile networking tool, capable of serving diverse purposes. The very features that empower privacy and anonymity also prove exceptionally valuable for the daily endeavors of Network Engineers and Systems Administrators. Consider the following scenarios:
- Scrutinizing IP address-based access regulations.
- Assessing internally-hosted services from an external vantage point.
- Conducting dependable external DNS inquiries while navigating the intricacies of a split-horizon DNS setup.
- Circumventing obstructed outbound ports.
- Exposing services ensconced behind NAT or CGNAT.
In this article, we embark on a journey to explore how Tor can be harnessed to undertake these tasks. Additionally, we delve into the reasons why Tor might offer distinct advantages over alternative methods.
Warning:
Using Tor to expose local services on your machine can be dangerous if not done properly, and should be only done in safe environments where you are permitted to do so.
Also note that requests to your local service via your Hidden Service will appear to originate from localhost, so make sure to consider this when it comes to things like access rules, virtual hosts, IP address bindings, etc.
Navigating the Labyrinth of IP Address-Based Access Rules
Within certain network landscapes, access to services is governed by IP address-based rules, designed either to curtail or facilitate access. They may even play a pivotal role in shaping conditional access policies. A quintessential example involves the relaxation of two-factor authentication requirements when logging in from a trusted IP address, or the imposition of supplementary verification steps for novel connections emanating from uncharted locations.
The predicament, however, lies in the daunting task of meticulously validating these policies sans the luxury of multiple distinct devices or VPNs. This is where Tor, coupled with the Tor Browser, steps into the spotlight, offering an elegant solution.
Imagine the ability to scrutinize your access rules from myriad external IP addresses, all without breaking a sweat. You can seamlessly reset your browser profile or forge an entirely new Tor circuit at will, all the while preserving the integrity of your ongoing tests.
Even if you find yourself grappling with non-web-based services, the torsocks wrapper emerges as your trusty ally, compelling any program's network connections to gracefully traverse the Tor network. Picture this: you're yearning to test an IP address-based SSH access rule; Tor lets you route your SSH connection through unfamiliar territory, originating it from a fresh, uncharted IP address:
$ torsocks ssh jamieweb.net
It's worth noting a couple of caveats—torsocks, alas, isn't amenable to setuid programs like ping, nor can it accommodate applications exclusively reliant on UDP.
Gaining External Perspectives on Internally-Hosted Services
For sysadmins entrusted with the stewardship of internally-hosted network services, such as web servers or mail servers, a recurring challenge looms large—evaluating these services from an external, public-facing standpoint.
This imperative testing arises because network services frequently sport configurations and policies contingent on the source of incoming connections. Unfortunately, conducting these evaluations internally often precipitates crude workarounds involving personal devices or makeshift mobile data tethering setups, both far from the epitome of convenience and reliability.
Fortunately, Tor emerges as a versatile instrument yet again. It empowers you to scrutinize your internally-hosted services from the cozy confines of your standard device. How, you ask? The answer lies in torsocks, your faithful companion, which can seamlessly integrate with cURL:
$ torsocks curl https://www.jamieweb.net
Alternatively, if you prefer circumventing the torsocks wrapper, you can instruct cURL to interface directly with the local SOCKS5 proxy stationed at 127.0.0.1:9050:
$ curl --socks5-hostname 127.0.0.1:9050 https://www.jamieweb.net
Ensuring Reliable External DNS Lookups Amidst Split-Horizon DNS Landscapes
In the intricate tapestry of corporate networks, a phenomenon known as 'split-horizon' or 'split-brain' DNS reigns supreme. This setup calls upon a dedicated internally-hosted DNS server, accompanied by an associated zone, to fulfill DNS requests originating within the organization. Alas, this internal DNS server tends to respond with 'internal' addresses—those private or RFC1918 addresses—rather than the 'external' public-facing counterparts.
This internal DNS infrastructure frequently dovetails with a preconfigured search domain or DNS scope, simplifying the access of internal services via their direct hostnames, obviating the need for fully-qualified domain names (FQDNs).
However, these split-horizon DNS architectures occasionally present a conundrum when you yearn for a request to traverse beyond the confines of your organization to an external DNS server. Some networks, in their zeal, channel all DNS traffic through the internal DNS server. Others go a step further, intercepting and reshaping DNS responses at the network's edge, courtesy of mechanisms like DNS doctoring or DNS NAT rewriting, commonly integrated into commercial edge firewall products.
You might contend with this situation by compelling your external DNS inquiries to waltz down the TCP route, employing the +tcp flag in DiG, also known as 'virtual circuit' mode. However, this option isn't always a panacea, as it might not be universally supported or available.
Enter Tor, the knight in shining armor for your DNS-related predicaments. By routing your external DNS lookups through Tor, you can rest assured that the responses remain unadulterated during their final lap through the network's edge:
$ torsocks dig +tcp @1.1.1.1 jamieweb.net
A couple of prerequisites: ensure you activate the +tcp mode and verify that your request takes a direct route to the external DNS server, circumventing any local caching resolvers like dnsmasq. The Tor daemon, as a safety measure, quashes requests targeting local addresses such as 127.0.0.1. Should you inadvertently venture into the realm of local addresses, Tor shall not hesitate to display its stern admonishment:
WARNING torsocks[]: [connect] Connection to a local address is 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)
Outflanking Obstinate Outbound Port Restrictions
In the labyrinthine corridors of corporate network environments, a regimented regime governs the gamut of outbound ports. This regimentation is the linchpin of Data Loss Prevention (DLP) efforts, ushering in tight control over all outgoing traffic. Yet, technical roles often find themselves ensnared in this web, their legitimate services inadvertently ensnared in the dragnet of port restrictions. Implementing exceptions tailored to individual users can be a Sisyphean task.
A classic case in point—one that frequently escapes the spotlight—is the WHOIS protocol, diligently operating in the precincts of TCP port 43.
Behold the torsocks wrapper, your deliverance from these paralyzing port restrictions. With Tor's grace, you can navigate these port barricades with consummate ease:
$ torsocks whois jamieweb.net
In certain scenarios, firewalls armed with Deep Packet Inspection (DPI) capabilities may thwart connections to otherwise permissible ports. Imagine a beleaguered sysadmin, endeavoring to procure a certificate from a web server via openssl s_client, only to encounter an impregnable barrier. Their endeavor falls short, for they fail to establish a full-fledged HTTPS connection.
Yet, salvation is at hand. By ushering their request through the hallowed halls of Tor, this vexing connection blockade crumbles to dust:
$ torsocks openssl s_client -connect jamieweb.net:443
Unveiling Services Concealed Behind NAT or CGNAT
There exist scenarios demanding the exposure of a locally-operating service to the boundless realm of the internet—think SSH or a web server. Alas, this is no trifling matter, courtesy of the formidable hurdles posed by NAT and the formidable colossus known as CGNAT (Carrier-Grade NAT).
Consider the predicament of a diligent soul striving to access a 4G-connected device remotely through SSH. Conventional wisdom crumbles in the face of consumer data plans tethered to the vagaries of CGNAT. Simply binding the service to your perceived public address spells naught but frustration. You share that IP address with scores of others, engaged in a similar quixotic quest. Layer upon layer of NAT further entangles this web, compounding the complexity.
Enter Tor, the vanguard of a novel solution—introducing your service to the world via a Hidden Service, a.k.a., a .onion site. This ingenious stratagem ensures your service's accessibility over Tor, irrespective of the convoluted layers of NAT or the labyrinthine web of filters obstructing your path.
To put this plan into action, you need but a few lines of incantation within your /etc/tor/torrc configuration file:
HiddenServiceDir /var/lib/tor/my_service
HiddenServicePort 22 127.0.0.1:22
The HiddenServiceDir directive specifies the repository for your Hidden Service's public and private keys. Designate an arbitrary directory within /var/lib/tor/ for this purpose. Resist the urge to create it yourself, for the Tor daemon shall craft it on your behalf, imbued with the requisite permissions.
The HiddenServicePort directive orchestrates the forwarding of incoming requests to a designated port. In our case, requests arriving at the Hidden Service on port 22 wend their way, unaltered, to the bastion of 127.0.0.1:22.
Optionally, you can fine-tune your Hidden Service for single-hop mode, allowing it to interface with the Tor network via a solitary hop, eschewing the customary triumvirate of hops. This move can potentially enhance performance, yet it comes at the cost of sacrificing your Hidden Service's anonymity. Exercise caution—resort to single-hop mode only when your anonymity isn't paramount. In most legitimate sysadmin scenarios, it remains a viable and secure choice.
To activate single-hop mode, integrate the following directives into your Hidden Service configuration:
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
A word of caution: selecting single-hop mode will effectively transform your Tor daemon into a non-anonymous entity, precluding its use as a client on the Tor network. Should your torrc file sport a configured SOCKS port, remember to disable it:
SocksPort 0
With your Hidden Service configuration finalized, safeguard your changes in the torrc file and beckon the Tor daemon to embrace its new configuration:
sudo service tor restart
The final piece of this puzzle is the /var/lib/tor/my_service/hostname file, where your Hidden Service's .onion address resides. Armed with this address, any Tor-capable device across the globe can rendezvous with your locally-hosted service.
A final cautionary note: Exposing local services through Tor is not a task to be undertaken lightly. Ensure your endeavors unfold within safe, sanctioned environs where such actions are explicitly permitted. Also, bear in mind that requests to your local service via your Hidden Service will seemingly emanate from localhost. This peculiarity merits due consideration when configuring access rules, virtual hosts, IP address bindings, and other pertinent aspects.
Conclusion
This article merely scratches the surface of Tor's multifaceted utility. Over the years, I've encountered myriad applications for Tor, and the potential for innovation appears boundless. I harbor a fervent wish to witness Tor's ascendancy as an indispensable tool in the arsenal of systems administration, enabling the seamless execution of diverse networking tasks.