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