My old mod: https://github.com/nyxnor/raspiblitz/blob/tor-patch/home.admin/config.scripts/tor.onion-service.sh
New mod: https://github.com/nyxnor/CLI-onion-services/blob/main/tor.onion-service.sh
Currently, the script CREATES, DELETES (optionally purge to delete the onion address), ADD and REMOVE auth, see CREDENTIALS.
My script configure client auth server side, but the client side needs to be configure manually. I explained the commands deeply when running the script with echo, but it should be shortened to only display the string necessary and a guide in torbox page or text/ folder explaining how to do so.
This post was edited for reference.
This is informational material of things to be implemented and reviewed if were. This is more a long term goal than a complete todo list. The texts were extracted from each link mentioned above them, only the most useful information.
Instructions
-
Matt Traudt HS Setup
-
TPO setup onion service
- Tip: A good practice to avoid leaking an onion service to a local network is to run onion services over Unix sockets instead of a TCP socket. You will need to edit and put the following two lines in your torrc file:
HiddenServiceDir /var/lib/tor/my-website/
HiddenServicePort 80 unix:/var/run/tor-my-website.sock
(Optional) Step 5: Running multiple onion services
If you want to forward multiple virtual ports for a single onion service, just add more HiddenServicePort lines. If you want to run multiple onion services from the same Tor client, just add another HiddenServiceDir line. All the following HiddenServicePort lines refer to this HiddenServiceDir line, until you add another HiddenServiceDir line:
HiddenServiceDir /var/lib/tor/onion_service/
HiddenServicePort 80 127.0.0.1:80
HiddenServiceDir /var/lib/tor/other_onion_service/
HiddenServicePort 6667 127.0.0.1:6667
HiddenServicePort 22 127.0.0.1:22
- If you're running multiple onion sites on the same web server, remember to edit your web server virtual host file and add the onion address for each website. For example, in Nginx and using Tor with Unix sockets, the configuration would look like this:
server {
listen unix:/var/run/tor-my-website.sock;
server_name <your-onion-address>.onion;
access_log /var/log/nginx/my-website.log;
index index.html;
root /path/to/htdocs;
}
Or in Apache with Tor service listening on port 80:
<VirtualHost *:80>
ServerName <your-onion-address.onion>
DocumentRoot /path/to/htdocs
ErrorLog ${APACHE_LOG_DIR}/my-website.log
</VirtualHost>
# /etc/tor/torrc
# Try to run Tor more securely via a syscall sandbox.
# https://www.torproject.org/docs/tor-manual.html.en#Sandbox
Sandbox 1
# Disable the SOCKS port. Not like anything else on this box is using tor.
SocksPort 0
# Set up the hidden service. propub3r6espa33w.onion -> www.propublica.org
# We're using unix sockets instead of "127.0.0.1:xxxxx". see nginx conf.
# Docs: https://www.torproject.org/docs/tor-manual.html.en#HiddenServicePort
HiddenServiceDir /var/run/tor/pp_www_hidserv
HiddenServicePort 80 unix:/var/run/nginx-pponion-80.sock
HiddenServicePort 443 unix:/var/run/nginx-pponion-443.sock
# /etc/nginx/sites-enabled/propubonion.conf
#
# Note that all of our hostnames listen to a unix socket instead
# of "127.0.0.1:xxxxx".
# Docs: http://nginx.org/en/docs/http/ngx_http_core_module.html#listen
map $http_upgrade $connection_upgrade {
default "upgrade";
"" "";
}
# HTTP BARE ONION
server {
listen unix:/var/run/nginx-pponion-80.sock;
server_name propub3r6espa33w.onion;
#allow 127.0.0.1;
allow "unix:";
deny all;
server_tokens off;
rewrite ^/(.*) http://www.propub3r6espa33w.onion/$1 permanent;
}
# HTTPS BARE ONION
server {
listen unix:/var/run/nginx-pponion-443.sock ssl spdy;
server_name propub3r6espa33w.onion;
#allow 127.0.0.1;
allow "unix:";
deny all;
server_tokens off;
ssl_certificate www.propub3r6espa33w.onion.pem;
ssl_certificate_key www.propub3r6espa33w.onion.key;
rewrite ^/(.*) https://www.propub3r6espa33w.onion/$1 permanent;
}
Nginx
To configure an Onion-Location header, the service operator should first configure an Onion service.
Step 1. Create an Onion service by setting the following in torrc:
HiddenServiceDir /var/lib/tor/hs-my-website/
HiddenServiceVersion 3
HiddenServicePort 80 unix:/var/run/tor-hs-my-website.sock
Step 2. Edit website configuration file
In /etc/nginx/conf.d/.conf add the Onion-Location header and the onion service address. For example:
add_header Onion-Location http://<your-onion-address>.onion$request_uri;
The configuration file with the Onion-Location should look like this:
server {
listen 80;
listen [::]:80;
server_name <your-website.tld>;
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name <your-website.tld>;
# managed by Certbot - https://certbot.eff.org/
ssl_certificate /etc/letsencrypt/live/<hostname>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<hostname>/privkey.pem;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header Onion-Location http://<your-onion-address>.onion$request_uri;
# managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
access_log /var/log/nginx/<hostname>-access.log;
index index.html;
root /path/to/htdocs;
location / {
try_files $uri $uri/ =404;
}
}
server {
listen unix:/var/run/tor-hs-my-website.sock;
server_name <your-onion-address>.onion;
access_log /var/log/nginx/hs-my-website.log;
index index.html;
root /path/to/htdocs;
}
Step 3. Test website configuration
The web server should confirm that the new syntax is working:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Step 4. Restart nginx
If you get an error message, something has gone wrong and you cannot continue until you've figured out why this didn't work.
Step 5. Testing your Onion-Location
To test if the Onion-Location is working, fetch the web site HTTP headers, for example:
wget --server-response --spider your-website.tld
Look for onion-location entry and the onion service address. Or, open the web site in Tor Browser and a purple pill will appear in the address bar.
-
The identical behaviour of Onion-Location includes the option of defining it as a HTML http-equiv attribute. This may be used by websites that prefer (or need) to define an Onion-Location by modifying the served HTML content instead of adding a new HTTP header. The Onion-Location header would be equivalent to a added in the HTML head element of the webpage. Replace <your-onion-service-address.onion> with the onion service that you want to redirect.
-
TPO community OpSec
- TPO Gitlab OpSec
- As mentioned here, be careful of letting your web server reveal identifying information about you, your computer, or your location. For example, readers can probably determine whether it's thttpd or Apache, and learn something about your operating system.
- If your computer isn't online all the time, your onion service won't be either. This leaks information to an observant adversary.
- It is generally a better idea to host onion services on a Tor client rather than a Tor relay, since relay uptime and other properties are publicly visible.
- The longer an onion service is online, the higher the risk that its location is discovered. The most prominent attacks are building a profile of the onion service's availability and matching induced traffic patterns.
- Another common issue is whether to use HTTPS on your onionsite or not. Have a look at this post on the Tor Blog to learn more about these issues.
- To protect your onion service from advanced attacks you should use Vanguards addon, read Tor blog about Vanguards and Vanguards' Security README.
-
Riseup OpSec - Leaking the real server
- A common misstep here is server signatures, for example it is easy to determine if a webserver is thttpd or Apache, or learn about your operating system because the banner tells the version of the running service and operating system.
- Another way that your onion address will get out is via the referrer header in browsers when a client browses a hidden service website and then clicks on a clearnet/hidden service link. The Tor browser has taken care of many of these tiny leaks, so be sure to encourage your users to use an up-to-date tor browser instead of using their own browser with Tor.
- If the server running the onion service is also exposed to the clearnet, make sure that when you connect to either the clearnet service or the onion service, you cannot specify in the host header the other service and get a response. You should ensure the onion service is only listening on the internal IP and your external service is only listening on the external IP address. The easiest way to ensure there are no failures here is this is to run your service on a machine that has no external IP address.
- Make sure the time on your server is correct, and is corrected automatically by NTP, so that time skews do not help identify your server.
- Make sure you are not inadvertently exposing information, for example with PHP you may disclose the server’s real name/address if you leak phpinfo() or $_SERVER, or expose error messages!
- Look into protecting yourself against Server Side Request Forgery (SSRF). This attack works by getting the server to perform an external connection (DNS lookup, etc.) which can expose your machine’s real location. Strict egress firewalling is one way to mitigate against this problem.
- The longer an onion service is online, the higher the risk that its location is discovered. The most prominent attacks are building a profile of the onion service’s availability and matching induced traffic patterns.
- There are currently ways in the protocol that a bad relay can learn about your onion address, even if you don’t tell anybody. Follow the discussion on the subject if you want to stay on top of how the Tor project is working on fixing these issues.
-
Riseup OpSec - Be careful of localhost bypasses!
- You should take very careful care to not accidentally expose things on your server that are restricted to the local machine. For example, if you provide /server-status in apache (from mod_status which is enabled per default in debian’s apache) to monitor the health of your apache webserver, that will typically be restricted to only allow access from 127.0.0.1, or you may have .htaccess rules that only allow localhost, etc.
- There are a few ways you can solve this problem:
- different machine: consider running the onion service on a different machine (real or virtual) than the actual service. This has the advantage that you can isolate the service from the onion service (a compromise of one doesn’t compromise the other) and helps with isolating potential information leaks
- isolation: similarly to the above, you can also isolate Tor and the service so it will run on a different network namespace than the service. Tails uses a Tor-or-fail packet filter.
- public ip: configure the onion service to connect to the public IP address of the service instead of localhost/127.0.0.1, this should make Tor not pick 127.0.0.1 as the source address and avoid most misconfigurations. For example like this:
HiddenServiceDir /var/lib/tor/hidden/ftp/
HiddenServicePort 80 192.168.1.1:81
- Note: This makes your server and vhost potentially reachable to an external entity. There has been a growing number of attempts to discover the true location of sites behind cloudflare that are badly configured because they still expose their true httpd on a public IP address. People regularly use masscan and zmap to scan the entire ipv4 address space and try to connect to a publicly exposed httpd and request “high-value” onion addresses from the httpd to see if they send a Host header and make the site serve their probed vhosts content.
- Binding to a port that is different from the “true” port is a source of a potential leak on Apache. If there is a directory, e.g. foo.onion/css/ then a request to foo.onion/css will cause apache to emit a 301 redirect, but when it does issue it, it will include the port that it thinks the service is listening on. Instead of sending a 301 to foo.onion/css/ it would send a 301 for foo.onion:81/css/ this both breaks the website and reveals the port the httpd is really running on.
- unix socket: consider using unix socket support instead of a TCP socket (requires 0.26 or later Tor) – if you do this, then the onion service will be running on the same server as the service itself. With a socket approach, you should be able to run with privatenetwork=yes in systemd unit which gets you some really great isolation, for example:
HiddenServicePort 80 unix:/etc/lighttpd/unix.sock
-
But then the service itself needs to support unix sockets, otherwise you have to setup some socat redirection from tcp <→ unix (nginx, twisted, lighttpd all support this).
-
audit carefully: carefully audit, and regularly re-audit your system for configurations that allow localhost/127.0.0.1, but prohibit everywhere else and configure those to work around the problem (for example make /server-status operate on a different IP; make the webserver listen on a different port for /server-status; make it password protected, etc.).
-
DoS Guidelines - Vanguards done, HiddenServiceExportCircuitID
seems to be the only other plausible solution.
-
Onionscan - Search for vulnerabilities in the HS
- We want to help operators of hidden services find and fix operational security issues with their services. We want to help them detect misconfigurations and we want to inspire a new generation of anonymity engineering projects to help make the world a more private place.
- Secondly we want to help researchers and investigators monitor and track Dark Web sites. In fact we want to make this as easy as possible. Not because we agree with the goals and motives of every investigation force out there - most often we don't. But by making these kinds of investigations easy, we hope to create a powerful incentive for new anonymity technology (see goal 1)
Special note for TorBox as it acts as a relay
It is generally a better idea to host onion services on a Tor client rather than a Tor relay, since relay uptime and other properties are publicly visible.