If you run a Tor hidden service for an Apache server, make sure you disable mod_status
A word for the wise... https://wireflaw.net/blog/apache-hidden-service-vuln.html Tor hidden service operators: your default Apache install is probably vulnerable TL;DR If you run a Tor hidden service for an Apache server, make sure you disable mod_status with: $ a2dismod status On most distributions, Apache ships with a handy feature called mod_status enabled. It's a page located at /server-status that displays some statistics, like uptime, resource usage, total traffic, enabled virtual hosts, and active HTTP requests. For security reasons, it's only accessible from localhost by default. This seems fairly reasonable, until you realize the Tor daemon runs on localhost. Consequently, any hidden service using Apache's default config has /server-status exposed to the world. What could a malicious actor do in that case? They could spy on potentially sensitive requests. They could deduce the server's approximate longitude if the timezone is set. They could even determine its IP address if a clearnet Virtual Host is present. But this shouldn't be too much of a problem. Surely people who have taken the time to install an advanced web server and configure a hidden service for it have thoroughly read the documentation and disabled the offending module. Or not. [continues...] -- http://dropsafe.crypticide.com/aboutalecm
Hello all, alec you raised an important point. I think the problem is the example config a tor hiddenservices which suggests to use 127.0.0.1:80. Apache is not the only software out there which may leaks metadata due to this "misconfiguration". Those folks of riseup did a good write up: https://help.riseup.net/en/security/network-security/tor/onionservices-best-... For some monitoring tools, for example munin, mod_status is essential. To fix this problem in an apache setup and keep mod_status enabled, I did the following
I did the following:
1. Only allow 127.0.0.1 to request server-status in mod_status 2. Map the HiddenService on another IP (here: the internal IP of the machine) 3. Force Apache to Listen on the internal IP and port 4. setup a virtual host for IP and port
1. #/etc/apache2/mods-enabled/status.conf
Require ip 127.0.0.1
2. # /etc/tor/torrc HiddenServiceDir /var/lib/tor/hidden_service/ HiddenServicePort 80 192.168.2.4:8888
3. # /etc/apache2/ports.conf #ListenOnHsPorts Listen 192.168.2.4:8888
4. <VirtualHost 192.168.2.4:8888>
ServerName fooou4vhdb26iks.onion DocumentRoot /var/www/mysite.org/www snip --- 8< ---- </VirtualHost>
On 30.01.2016 08:46, Alec Muffett wrote:
A word for the wise...
https://wireflaw.net/blog/apache-hidden-service-vuln.html
Tor hidden service operators: your default Apache install is probably vulnerable
TL;DR If you run a Tor hidden service for an Apache server, make sure you disable mod_status with: $ a2dismod status
On most distributions, Apache ships with a handy feature called mod_status enabled. It's a page located at /server-status that displays some statistics, like uptime, resource usage, total traffic, enabled virtual hosts, and active HTTP requests. For security reasons, it's only accessible from localhost by default.
This seems fairly reasonable, until you realize the Tor daemon runs on localhost. Consequently, any hidden service using Apache's default config has /server-status exposed to the world. What could a malicious actor do in that case? They could spy on potentially sensitive requests. They could deduce the server's approximate longitude if the timezone is set. They could even determine its IP address if a clearnet Virtual Host is present.
But this shouldn't be too much of a problem. Surely people who have taken the time to install an advanced web server and configure a hidden service for it have thoroughly read the documentation and disabled the offending module.
Or not.
[continues...]
-- http://dropsafe.crypticide.com/aboutalecm
_______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
-- best regards | viele Gruesse, shadow@systemli.org receive my key: gpg --keyserver zimmermann.mayfirst.org --recv-keys 0x5C6B6ED4248C1F32
Good advice for many cases, certainly! I would hesitate to say that it is mandatory to do this for all installations, however it is **almost exactly** what we did internally with the big onions, albeit at scale. The rest of the site is configured (via our Loadbalancer setup) to see our onion endpoint as 169.254.0.1 - on the DHCP subnet - because we use parts of the RFC1918 space internally (as do most other organisations) and this (using 169.254/whatever) seemed the easiest way to ensure there would never be a clash. :-) -a
Hi shadow, On Sat, Jan 30, 2016 at 12:00:57PM +0100, shadow wrote:
To fix this problem in an apache setup and keep mod_status enabled, I did the following
I did the following:
1. Only allow 127.0.0.1 to request server-status in mod_status 2. Map the HiddenService on another IP (here: the internal IP of the machine) 3. Force Apache to Listen on the internal IP and port 4. setup a virtual host for IP and port
1. #/etc/apache2/mods-enabled/status.conf
Require ip 127.0.0.1
2. # /etc/tor/torrc HiddenServiceDir /var/lib/tor/hidden_service/ HiddenServicePort 80 192.168.2.4:8888
3. # /etc/apache2/ports.conf #ListenOnHsPorts Listen 192.168.2.4:8888
4. <VirtualHost 192.168.2.4:8888>
ServerName fooou4vhdb26iks.onion DocumentRoot /var/www/mysite.org/www snip --- 8< ---- </VirtualHost>
perhaps 127.0.0.X where X [2-254] ? e.g. # ip addr add 127.0.0.27 dev lo HiddenServicePort 80 127.0.0.27:8888 Listen 127.0.0.27:8888 VirtualHost 127.0.0.27:8888 192.168.Y.Z is routable on local networks, leaving you one configuration mistake away from revealing your hidden service locally. As a second layer of defense against mis-configuration, set your iptables to restrict processes running as the tor user/group to tcp:127.0.0.27:8888 [1]. Then, drop anything else with that destination. You can really lock down the box via iptables default DROP policies (-P) and explicitly allowing narrowly acceptable traffic. It takes a bit to set up, but for single-purpose boxes, it's doable. hth, Jason. [1] caveat: The tor process also needs Internet access in order to be effective. ;-)
On 31 Jan 2016 12:44 a.m., "Jason Cooper" <tor@lakedaemon.net> wrote:
perhaps 127.0.0.X where X [2-254] ? e.g.
# ip addr add 127.0.0.27 dev lo
I will speculate that that would not achieve what we want to achieve, viz: separation between an Apache listener on 127.0.0.1 and a Tor HTTP/S interface on 127.0.0.27. Maybe I'm wrong, but I am pretty sure that even if it did work on some operating systems, it might not work / might leave vulnerabilities on some other operating systems. My rationale comes from past experience that even if one configured a localhost loopback on 127.0.0.1, one could telnet/ssh to the same machine as any of 127.0.0.2-200+ (etc) because the afflicted kernel treated any network interface marked "loopback" as a huge, unified bucket, delivering anything that arrived into it (being a /8) to any port-listener, irrespective of address details. This was particularly fun to combine with a failure to deploy strict destination multihoming, my favourite feature to enable when hardening a host. So... this _may_ work, but I would test it, or in general recommend use of proper network interfaces. In an impacted system, Apache would have to be checking the IP address of the inbound connection and I am not certain that it would receive the truth, and/or perform the check for itself. The NSA publish a quite decent set of Linux hardening guidelines. They make a good start. Also, another possibly-good thing to do for security is to run your Tor daemons on an enclave network. In such a configuration the kernel/services do not know how to get to / do not have a route to the internet, and possibly are actually firewalled to prevent them from doing so. Then any specific apps (e.g. platform software updates, tor daemon) have to use an (authenticated?) web or SOCKS proxy to reach the internet. This helps reduce your attacker's ability to "pivot". -a
On 31 Jan 2016 9:39 a.m., "Alec Muffett" <alec.muffett@gmail.com> wrote:
Also, another possibly-good thing to do for security is to run your Tor
daemons on an enclave network. ...oh, and better: run your webserver in a separate box / container / VM from your Tor daemon. That makes irrelevant the localhost-loopback issue, and aids scaling/performance. -a
participants (4)
-
Alec Muffett -
Alec Muffett -
Jason Cooper -
shadow