Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

"Joy is wealth and love is the legal tender of the soul." -- Robert G. Ingersoll


rocksolid / Tor / Nice opsec guide for hidden server admins

SubjectAuthor
o Nice opsec guide for hidden server adminsgugaroo

1
Subject: Nice opsec guide for hidden server admins
From: gugaroo
Newsgroups: rocksolid.shared.tor
Organization: def5
Date: Thu, 14 Mar 2019 00:11 UTC
References: 1
Path: i2pn2.org!rocksolid2!def5!POSTED.localhost!not-for-mail
From: guga...@anon.com (gugaroo)
Newsgroups: rocksolid.shared.tor
Message-ID: <e0f101b8483eb8382ce34074dd6610db@def4>
Subject: Nice opsec guide for hidden server admins
Date: Thu, 14 Mar 2019 00:11:22+0000
Organization: def5
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
View all headers

https://riseup.net/en/security/network-security/tor/onionservices-best-practices#leaking-the-real-server


Best Practices for Hosting Onion Services
The Onion Router

    How to use this guide.
    Installing and configuring Onion Services
        Make sure your Tor software is updated
        Many things can be made into onion services
        Don’t run a relay at the same time
        Monitor your onion service(s) availability
        Multiple ports for one onion service
        SSL/TLS isn’t necessary
        Onion services and Rails 4
    Onion services can be found
        Leaking the real server
        OnionScan
        Onion services don’t need to be hidden!
        Make your onion services easy to find
        Ask your favorite online service to provide an onion service!
        Moving onion services
    Protecting your services
        Protect your private keys
        Backup your private keys
        Be careful of localhost bypasses!
        You can make onion services require authentication to use.
        Protect your onion services from advanced attacks

How to use this guide.

Here you can find information about running Onion Services based on our experiences running them and helpful tips from people like you. If you have a helpful tip, or can translate this into another language, please contribute!

“Onion Services” were previously known as “Tor Hidden Services”, but have been renamed since “Hidden Service” didn’t accurately describe what was possibile. This guide uses the new name.
Installing and configuring Onion Services

For information on configuring onion services, please read the Tor Project’s guide
Make sure your Tor software is updated

It is not enough to simply install Tor and configure your onion service and then forget about it. You must keep it up to date so that critical security flaws are fixed. All software has bugs, and Tor is no exception. Make sure you are keeping your software up-to-date.
Many things can be made into onion services

You can do a lot of things over onion services, not just make a website available! You can also provide IMAP, or SMTP, or deliver mail between MTAs, among many other possibilities. Spread the onions far and wide! But be careful, if the service makes DNS request for whatever reason (like resolving where that SMTP server is to send the email), then you leak information. One way to work around this is to have the machine running your service fully iptabled to go through Tor all the time.
Don’t run a relay at the same time

Do not run a relay and an onion service on the same instance. Having a relay and an onion service on same IP and/or machine helps traffic correlation and fingerprinting. However, Tor is smart enough to not choose itself as a node for the circuit so it’s not a disaster but ideally you want to avoid it.
Monitor your onion service(s) availability

Although their stability has improved greatly, onion services can still fail for a number of reasons. Set up some monitoring to regularly connect to your onion service(s) to make sure that they are still functioning.
Multiple ports for one onion service

You don’t need to create a different onion service for every service you want to make available, just add more HiddenServicePort lines, for example:

HiddenServiceDir /usr/local/etc/tor/other_hidden_service/
HiddenServicePort 6667 127.0.0.1:6667
HiddenServicePort 22 127.0.0.1:22

If you want to run multiple onion services from the same Tor client, just add another HiddenServiceDir line to the config file.
SSL/TLS isn’t necessary

You don’t really need SSL/TLS in an onion address (ie. https) since it’s a complete encrypted tunnel + PFS (perfect forward secrecy), but it does not hurt having extra layers in that onion!

Although it is true that extra layers are good beware that usually redirecting to SSL/TLS will mean that the certificate will not validate (because the hostname will be *.onion, instead of the certificate that you have for your public service). If you can get a .onion certificate, that works!

If your onion service does use TLS, make sure that it does not send a certificate for an external website.
Onion services and Rails 4

NOTE: the “secure cookie” bug in the Tor browser has been fixed for newer versions. This means that cookies with the secure flag will be correctly sent back to .onion addresses. You should still follow this tutorial to turn off HTTPS for .onion addresses, but you can now globally turn on the cookie secure flag for both the .onion and https versions of your website.

In order to get a .onion site to play nice with rails, and have the site also work over HTTPS when not using the .onion, you need change a few defaults.

The first thing that must be changed is to not use the config.force_ssl = true option. This option is the default for rails apps in production. This setting forces secure cookies and forces HSTS. Change my_rails_app/config/environments/production.rb to be:

config.force_ssl = false

Once we set force_ssl = false, we want to add back the ability to enforce secure cookies and HSTS when using normal HTTPS. So, to do this, we make sure the web server is setting the HSTS headers for the HTTPS virtualhost, and we add the secureheaders gem to enforce secure cookies. The secureheaders gem will set the Secure cookie flag only for HTTPS connections, unlike the rails force_ssl flag. This allows use to have secure cookies for the regular HTTPS site and insecure cookies for the .onion site, which is what we want.

Install the secureheaders gem for your application, in my_rails_app/Gemfile:

gem 'secure_headers', '~> 3.5'

(replace 3.5 with whatever the current version of secureheaders is available)

Add a secureheaders configuration, in config/initializers/secureheaders.rb:


    SecureHeaders::Configuration.default do |config|
      config.cookies = {
        secure: true,
        httponly: true,
        samesite: {
          strict: true
        }
      }
    end

NOTE: When configuring apache or nginx in this setup, do not set the X_FORWARDED_PROTO environment variable to be https on the port 80 onion virtual host. You should set it on the port :443 non-onion virtual hosts.
Onion services can be found

If you are not very careful and keep your server from revealing identifying information about you, your computer, or your location, then the onion service will no longer be hidden!
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.
OnionScan

Use the [OnionScan→onionscan.org] tool to scan HTTP onion services to look for leaks. It will look for IP addresses, EXIF metadata in images, and things like enabled mod_status that can leak the real IP address of the server.
Onion services don’t need to be hidden!

Click here to read the complete article
1
rocksolid light 0.7.2
clearneti2ptor