search

riseupnet / riseup_help

riseup.net help documentation
205 stars 250 forks source link

onion service best practices #323

Closed epidemics-scepticism closed 6 years ago

epidemics-scepticism commented 8 years ago

There are some concerns I'd raise with the best practices recommended on this page: https://help.riseup.net/en/security/network-security/tor/onionservices-best-practices

First of all, the localhost exposure is almost unique to apache (nginx has a status page and I saw some time ago a lighttpd which provided such an interface but they'd need to be explicitly enabled, there are few default configs like debians apache which enabled mod_status on /server_status). (p.s. I twice had to tell you to disable this "quirk" ;)

Second of all binding to a public IP is a bad method to follow to stop this kind of problem, 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 I have also seen attempts 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.

Thirdly binding to a port that is different from the "true" port is a source of a potential leak on apache (lol apache again). 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.

May also be worth mentioning using some kind of tails-like tor-or-fail packet filter if they don't opt to use a network namespace to isolate? unix sockets++ though

I was going to submit a pull request but what the heck is that formatting scheme? Sorry :( just raising an issue instead

kradan commented 8 years ago

thanks for your thoughts! do you like to improve the text directly?