SOLVED [How to] Access your TrueNAS server from outside your local area network, without exposing any ports, using the TOR network

[juanman80]

Hi!

this is a post with the steps I needed to be able to access my TrueNAS interface from outside of my local area network without exposing any ports through the firewall, using the TOR network. The service will only expose the TrueNAS interface to those with the onion address and will not act as a tor relay.

Exposing a service to the internet is not secure: All sorts of hackers and bots move around looking for vulnerable services to grow their attack networks. Because of this, and thanks to the feedback provided, I've edited this runbook to include a second step to require client authentication to access the server.

This steps can be used to expose any kind of service through onion, not just the TrueNAS interface. For example, you could expose your media gallery or a backup service.

First Step: Set up the onion service​

What do you need to follow this instructions?​

1. To be comfortable with the command line
2. SSH access to your TrueNAS server.
3. Smart phone with 4g access and a TOR browser, to do the testing.

Instructions​

Install the service:

1. Create a jail with the usual defaults.
2. Open an SSH session to the TrueNAS server.
3. jexec into the new jail
4. Install the editor of choice (mine is vim) and tor pkg install vim tor
5. Edit the tor config file /usr/local/etc/tor/torrc. I recomend reviewing the whole file, it's quite interesting and well written, but if you want to go to the point, here's what I changed:
   1. Change logs to save to file: remove # before Log notice syslog
   2. Run as daemon: remove # before RunAsDaemon 1
   3. Save certificates and addresses under /var/db/tor. This can allow us to save that information in our main pools if you mount that folder using the TrueNAS interface. remove # before DataDirectory /var/db/tor
   4. in the section for location-hidden services, leave the default values and add the following lines. Replace <IP_ADDR> with the IP of the TrueNAS web interface inside of the local area network
      
      Code:

      HiddenServiceDir /var/db/tor/hidden_truenas/
      HiddenServicePort 80 <IP_ADDR>:80

   5. save
6. Manually start the service service tor onestart
7. Now, search the onion address automatically generated:
   Code:

   cat /var/db/tor/hidden_truenas/hostname
   ONION_SERVICE_URL

Test the service:

1. Open the tor browser inside the phone. It's important that you disable the wifi so I really test that I can access from outside the local network.
2. Go to ONION_SERVICE_URL
3. Get the home or login page
4. Voilà!

Disable the service:

1. Now, go back to the terminal and stop the service until it's secured: service tor onestop

Second Step: Secure the onion service with Client Authorization​

What do you need to follow this instructions?​

1. Smart phone with 4g access and a TOR browser that support client authentication. I have android, and unfortunately the default Tor Browser doesn't implement client authentication yet, so I use Orbot and DuckDucGo browser (I tested with Firefox and couldn't manage to make it work with Orbot in VPN mode).
2. A python installation to generate the client authentication. I opted to run the commands in my local machine instead of the container, but you could probably do it as well, I just haven't tested that.

Instructions​

Generate the client authentication. This steps will generate a public and a private tokens for one customer. The public token will be saved in the server, the private token will be used by the client to authenticate and shouldn't be shared by any other client. You'll need to repeat this steps for every client you want to connect to the service:

1. In a system with python, download the python snippet https://github.com/pastly/python-snippits/blob/master/src/tor/x25519-gen.py provided in the tor documentation regarding client authorization
2. Install the required library PyNaCl: pip install PyNaCl
3. Run the script, it will print a public and a private tokens
   Code:

   $ python3 x25519-gen.py
   public:  PUBLIC_TOKEN
   private: PRIVATE_TOKEN

4. Save these values for later

Add client authorization to the onion service:

1. In the jail with tor, go to HiddenServiceDir: cd /var/db/tor/hidden_truenas/
2. There should be a folder called authorized_clients. If it doesn't exist, create it and assign it to the _tor user and group. Go to that folder cd authorized_clients/
3. Create a text file with the auth line of the first customer.
   1. The auth line is built from 3 fields separated by :.
   2. The first two fields are fixed: descriptor and x25519.
   3. The third one is the public token.
   4. It should look like descriptor:x25519:PUBLIC_TOKEN
   5. Save the file with a name that identifies the client that it identifies and the auth extension. In my case, juanman80.auth
4. Manually start the service service tor onestart

Test the service:

1. In the android smartphone, open Orbot
2. In the three dot menu, go to Onion services -> Client Authorization -> Add
   1. .onion Domain: ONION_SERVICE_URL
   2. x25519 Private Key in Base32: PRIVATE_TOKEN
   3. Save
3. Now, Orbot prompts to restart the application, but that wasn't enough for me, or I didn't manage to do it properly. It worked after restarting the whole phone.
4. Connect Orbot to the Tor network and enable VPN mode (it should work also in SOCKS mode, I didn't try that)
5. Set the browser as a tor-enabled app and open the browser
6. Go to ONION_SERVICE_URL
7. Get the home or login page
8. Voilà!

As an additional test, I repeated the test with the Tor browser (from the first part) and it shouldn't be able to access anymore.

Finally, enable the service:

1. Set the tor service to start when the jail starts: sysrc tor_enable="YES"

 

[Nick2253]

This is a quick howto, though I think it would benefit from expanding some of the steps a little more, and providing a bit more context for the specific settings you are changing or the commands that you are running.

I do want to raise a couple security points that I do not feel are adequately addressed in the writeup:

• Exposing the TrueNAS web interface to any public network is outside of the design scope of TrueNAS. That isn't to say that the TrueNAS web interface is inherently insecure, it's that the web interface was not designed to be hardened or tested against the kinds of attacks that would be possible if publicly facing.
• While a TOR .onion address is cryptographically generated, it is not otherwise secure. Anyone with the .onion address may access the resource on the other end. As such, it's appropriate to treat resources at a .onion address as publicly accessible. At least some relays on the TOR network will know about your address, and it is at least theoretically possible to learn about your address from the DHT (https://donncha.is/2013/05/trawling-tor-hidden-services/).
• As such, using a .onion address is more a form of security through obscurity than any actual kind of security.

 

[juanman80]

Thanks for the feedback, @Nick2253!

As you comments exposing TrueNAS interface to the outside is a security risk, just like exposing it via opening ports in the home router. This document was intended as a proof of concept to expose services from the network when the telecommunications provider blocks that option, like my case.

To add more security, in case anyone intends to follow it, I'll add the steps to require customer token for authentication.

 

[Nick2253]

As you comments exposing TrueNAS interface to the outside is a security risk, just like exposing it via opening ports in the home router. This document was intended as a proof of concept to expose services from the network when the telecommunications provider blocks that option, like my case.

Ahh, I think I understand my misconception. I know many people who falsely presume that everything on TOR is "safe", largely because they conflate the anonymity provided via TOR with some kind of security. Obviously, those two are different things. As such, I presumed that you were providing this guide as a "secure" alternative to directly sharing ports.

Instead, you are providing this guide as an alternative way to directly sharing ports, recognizing that there are roughly equal security risks using either method.

In this vein, I would definitely suggest that you clarify that aspect, since it wasn't clear to me. I would also expand on what alternative services you might share using this method. For example, you might clarify how you would share a service running on a jail (like NextCloud or Mediawiki), and what would be different for those situations. Then, this guide just uses the example of sharing the web interface for illustration purposes, and I would hope you would add the relevant security disclaimers to that.