Re: [tor-onions] Privacy Audits for Onion Services
On Fri, Aug 31, 2018, 19:59 Micah Lee wrote: > On 08/30/18 08:33, Jason S. Evans wrote: > > Hi all, > > > > How can I best audit an onion service to make sure that my IP can not > > easily be compromised? Is there a list of things to do to try to hack my > > own site to try to find the IP? > > In addition to what everyone else said, there's also a pretty awesome > tool called OnionScan which will scan http onion services looking for > leaks -- IP address, but also things like exif metadata in jpegs it finds. > > I used this on the onion site version of https://onionshare.org and it > discovered that I had apache2's mod_status enabled which was leaking the > real IP address of the server. > > Here's the website: > https://onionscan.org/ > > Here's the code, along with build instructions (it's written in golang): > https://github.com/s-rah/onionscan sweet! I just finished to port OnionScan for FreeBSD, and should be in the tree soon; https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231508 ___ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Re: [tor-onions] Privacy Audits for Onion Services
"J. S. Evans" writes: > Once there is a page, I would love to volunteer to add input. There is this best practices guide: https://riseup.net/en/security/network-security/tor/onionservices-best-practices which anyone is welcome to submit pull requests to change (https://github.com/riseupnet/riseup_help). I've added a few of the suggestions here to there, keep them coming! -- micah signature.asc Description: PGP signature ___ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Re: [tor-onions] Privacy Audits for Onion Services
On 31 August 2018 at 08:58, wrote: >>ensure that your external website(s)are only listening on external ip >>addresses" > I believe you mean that the website host (Apache/nginx) listen only on > localhost, and NOT on external at all. Otherwise, shodan will find it, and > your code will leak the IP. No, I meant that. I'm assuming one is running a webserver that is hosting both clearnet websites and onion websites through vhosts. For example, my own tomritterbassljd.onion and ritter.vg (obviously this is not trying to be a hidden service, just an onion service so I'm using it as my example.) There are two attack vectors there: Sending a Host: ritter.vg to my onion site (over tor of course) and retrieving the website for ritter.vg. Sending a Host: tomritterbassljd.onion to my clearnet site (not through Tor) and retrieving the Hidden Service. So to mitigate this you need to make sure that your onionsites are listening only on local addresses and your clearnet sites are listening only on external addresses. Alternately (and this is what I do) you can set up your onionsite on a local address and non-standard port (e.g. 88), and ensure that only the onionsite is accessible on that port and the clearnet sites are not. Then you can have your clearnet sites listen on both the external IP(s) and 127.0.0.1:80/443 like normal. -tom ___ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Re: [tor-onions] Privacy Audits for Onion Services
On 08/30/18 08:33, Jason S. Evans wrote: > Hi all, > > How can I best audit an onion service to make sure that my IP can not > easily be compromised? Is there a list of things to do to try to hack my > own site to try to find the IP? In addition to what everyone else said, there's also a pretty awesome tool called OnionScan which will scan http onion services looking for leaks -- IP address, but also things like exif metadata in jpegs it finds. I used this on the onion site version of https://onionshare.org and it discovered that I had apache2's mod_status enabled which was leaking the real IP address of the server. Here's the website: https://onionscan.org/ Here's the code, along with build instructions (it's written in golang): https://github.com/s-rah/onionscan ___ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Re: [tor-onions] Privacy Audits for Onion Services
>ensure that your external website(s)are only listening on external ip >addresses" I believe you mean that the website host (Apache/nginx) listen only on localhost, and NOT on external at all. Otherwise, shodan will find it, and your code will leak the IP. -Original Message- From: tor-onions On Behalf Of J. S. Evans Sent: Friday, August 31, 2018 9:40 AM To: tor-onions@lists.torproject.org Subject: Re: [tor-onions] Privacy Audits for Onion Services Hi Tom, Thanks for the input! On Thu, 2018-08-30 at 17:51 +0200, Tom Ritter wrote: > That's an excellent question. I think we should make a wiki page on > trac about this, if we don't have one already... > Once there is a page, I would love to volunteer to add input. > Off the top of my head, I'd suggest the following (specific to > HTTP(S) servers): > - Ensure your clock is correct and is corrected automatically once or > twice a day to reduce time skews > - If your server is exposed to the internet, ensure that one cannot > hit your onionsite by specifying it in the host header on the > clearnet. Ensure the onionsite is only listening on the internal IP. > - Similarly, ensure that your external website(s)are only listening on > external ip addresses, and one cannot hit them over the onionsite by > specifying them in the Host header > - Best case: run your service on a machine that _has_ no external IP > address and only internal IP addresses I usually run onion services on vms in containers. The VM has an internal 192.168... ip and no external (to the internet) facing IP. All real tcp ports are closed. Port 80 is listening on the web server but not actually open on any firewall. > - Check your SSL configuration and ensure your onionsite isnt sending > a cert for external websites Until let's encrypt starts providing certs for .onion sites, I will not run https because it's redundant. > - Don't run a relay and a hidden service on the same tor instance > > Then there are a ton of advice items for individual > languages/frameworks. For example for PHP, don't expose phpinfo() or > $_SERVER. Don't expose error messages. > Duly noted. It would be great to have a list of suggestions about for different languages on the wiki. > There is a class of web attack called 'SSRF' or Server Side Request > Forgery. The toehold of this attack is that you can induce the > _server_ to perform a connection. This could be through a DNS lookup, > a XML DTD fetch, or other types of vulnerabilities. If an attacker can > do this on your onionsite, they can trigger you to connect to their > server and learn your server address. You can mitigate this by strict > egress firewalling. I know how to do this with Docker. I could research this and write up a guide for some of the more well known firewall apps. firewalld, ufw, plain iptables, etc. > > -tom > > On 30 August 2018 at 10:33, Jason S. Evans < > jason.s.ev...@protonmail.com> wrote: > > Hi all, > > > > How can I best audit an onion service to make sure that my IP can > > not easily be compromised? Is there a list of things to do to try to > > hack my own site to try to find the IP? > > > > Thanks! > > Jason > > > > > > > > > > ___ > > tor-onions mailing list > > tor-onions@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions > > ___ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions ___ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Re: [tor-onions] Privacy Audits for Onion Services
Not to put too fine a point on it: I would start by running an onion server on a dedicated machine in a network enclave behind NAT and with intentionally invalid hostnames, so that any/all metadata that might leak in (say) Apache headers, is mostly useless; the NAT-internal network would be 10.0.0.0/24, the hostname "invalid.invalid", etc... It was thinking like this which led me to draft this (now slightly dated) document; but overall it still is useful: https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md The other benefit of putting your onion servers in a NAT enclave is that you can lock down your guards to a limited set and drill holes in your firewall specifically for those, and then ban all other outgoing traffic from your machine; this will help prevent identification via DNS lookups, package update checks, pingbacks in your CMS stack, etc. Then: work out for yourself how to do software updates via (say) a HTTP proxy + VPN. -a ___ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Re: [tor-onions] Privacy Audits for Onion Services
That's an excellent question. I think we should make a wiki page on trac about this, if we don't have one already... Off the top of my head, I'd suggest the following (specific to HTTP(S) servers): - Ensure your clock is correct and is corrected automatically once or twice a day to reduce time skews - If your server is exposed to the internet, ensure that one cannot hit your onionsite by specifying it in the host header on the clearnet. Ensure the onionsite is only listening on the internal IP. - Similarly, ensure that your external website(s)are only listening on external ip addresses, and one cannot hit them over the onionsite by specifying them in the Host header - Best case: run your service on a machine that _has_ no external IP address and only internal IP addresses - Check your SSL configuration and ensure your onionsite isnt sending a cert for external websites - Don't run a relay and a hidden service on the same tor instance Then there are a ton of advice items for individual languages/frameworks. For example for PHP, don't expose phpinfo() or $_SERVER. Don't expose error messages. There is a class of web attack called 'SSRF' or Server Side Request Forgery. The toehold of this attack is that you can induce the _server_ to perform a connection. This could be through a DNS lookup, a XML DTD fetch, or other types of vulnerabilities. If an attacker can do this on your onionsite, they can trigger you to connect to their server and learn your server address. You can mitigate this by strict egress firewalling. -tom On 30 August 2018 at 10:33, Jason S. Evans wrote: > Hi all, > > How can I best audit an onion service to make sure that my IP can not easily > be compromised? Is there a list of things to do to try to hack my own site > to try to find the IP? > > Thanks! > Jason > > > > > ___ > tor-onions mailing list > tor-onions@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions > ___ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
