Couldn't you just not allow your box to be accessed outside of the anonymous network? It's a neat trick, but how likely is it that you can trace two different services to the same server anyways?
No. Sadly, Tor doesn't work like a VPN, presenting itself as a network interface responsible for a virtual subnet you can restrict your connections to. Instead, Tor connections are plain-old IP connections from random public IPs. Which means that your hidden service needs to accept connections from random public IPs--and, therefore, to be public itself. A hidden service might not have a published IP address, but it must have one that you could, potentially, connect to over the plain internet, in order for the proximate Tor node to it (what would be called an "exit node" if it were a plain site) to be able to talk to it.
In theory, you could hack on the Tor client so that clients and servers did an SIP negotiation prior to connecting on the desired port. You'd then run something on the host which would act like a port-knocking daemon, temporarily allowing new connections on a port only in response to a request from the Tor client, and only to the SIP peer in that message.
(Or, Tor could just present itself like a network interface, giving each N-proxied-peer a virtual IP that changes whenever it regenerates its identity. "Hidden service" connections would be regular IP-to-IP communication. For "public" connections, exit nodes would need to be running SOCKS proxies, and then there could be an anycast IP address that picked a proxied-exit-node at random. Then you'd just set that as your plain-old SOCKS proxy in your browser.)
> Which means that your hidden service needs to accept connections from random public IPs--and, therefore, to be public itself. A hidden service might not have a published IP address, but it must have one that you could, potentially, connect to over the plain internet, in order for the proximate Tor node to it (what would be called an "exit node" if it were a plain site) to be able to talk to it.
This is not at all correct. The IP address of the hidden service is masked in exactly the same way that its clients' IP addresses are. That is, the client and service connect across the Tor network to an client-chosen onion router known as the 'rendezvous point', through which they set up a shared circuit.
Er. To interpret what I said the way you did, is to assume I was saying "Tor does nothing, and clients connect directly to servers", which is kind of... silly, to say the least.
The point I was making was that the proximate node to the hidden service--the last one in the onion-routing chain--connects to its destination by using its public IP to talk to the hidden service's public IP. From the perspective of the hidden service, the node proximate to it in the onion-routing chain is a regular Internet peer, which is impossible to distinguish from any other regular Internet peer.
In the end, what Tor gives you is a proxy (to a proxy, to a proxy.) And, from the server's perspective, there's no difference between a proxy and a regular client. It can't tell, by the IP, that the client it's speaking to is a proxy. And because of that, you cannot, at the server-level, block non-proxied clients from speaking to you. Because you don't know which those are.
It's not a proxy in the way you are describing. The node (onion router) most proximal to the hidden service is always connected to by the hidden service, not the other way around.
Thus it is absolutely fine to firewall off all inbound connections on the host running the hidden service, as it will only be making outbound connections - and even those are to a limited set of IP addresses as defined by the guard nodes it has chosen for entry into the Tor network.
I don't know much about the details, but the tor faq says you can host a hidden service even behind a nat. Wouldn't that protect against being exposed on a public ip?
I'm pretty sure that any competent tor hidden service operator will know not to run anything else on the same hardware. It's basic OPSEC that you want your sensitive Tor-connected machine to only make/accept connections through Tor.
Yes, this would prevent this attack as described as the 'measurer' would be unable to collect any data. Though, the author presents some interesting (albeit untested) alternatives in section 5.4 of the paper.
