On Wed, Nov 07, 2007 at 08:20:37AM -0800, Martin Fick wrote: > My home router offers an http administration console > on port 80 which for obvious security reasons is > normally only accessible from the internal facing side > of the router. While many of these home routers > typically have an internal private IP such as > 192.168.1.1 and an external public IP, they sometimes > respond to both IPs from the inside and sometimes they > even allow access to the administration console on the > external IP if it is accessed from the internal side > of the router (mine does). This would not normally be > a problem, but add a tor exit server to the inside of > a home network serviced by such a router and ...you > can probably guess where I am going with this.
Yep. That's why Tor has a notion of exit policies: http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#RunARelayBut If you really want to restrict connections to sensitive local resources, you should reject connections to them in your exit policy. The default exit policy rejects internal addresses like 10.*, 192.168.*, etc, but as you say there may be other sensitive resources depending on your situation. The other half of the answer is that you shouldn't be relying on network location for authorization. You should, for example, use a password. The third half of the answer is that running a web browser and interacting with strange websites creates an excellent opportunity already for dns rebinding attacks, cross-site foo attacks, etc. See for example the "drive-by pharming" report from some folks I've been working with at IU, summarized by Bruce Schneier here: http://www.schneier.com/blog/archives/2007/02/driveby_pharmin.html It's pretty darn scary what bad guys can do to access local resources by tricking your browser. In short, you'd better think harder if you want to both a) run complex programs that can act as proxies, such as a web browser and such as Tor, and b) do any sort of trust-by-network-location. > This, of course, should only happen if Alice's tor > client chooses Bob's tor server as the exit node. > But, if I understand the tor documentation correctly, > this would in fact be the preferred way for tor > client's to access Bob's website since they should be > able to detect that Bob's website and his tor exit > server are in fact both (NATed to) the same public > IP!!!! Yes. If you're visiting Bob's website, Tor can provide end-to-end authentication and end-to-end encryption without the need for SSL. This is a great potential feature. But you're right, Bob had better not allow additional access to sensitive resources for people connecting from his Tor relay. > If I am correct about this possibility, and without > arguing the virtues of whether these routers are doing > the right thing by providing access to the admin > console from the external IP from their inward facing > interface, I think that tor relay providers should be > strongly warned about this possibility in the tor > documentation! I am not sure that there is a good > default (out of the box) way to prevent this from > happening with tor, but I suspect that if Bob sets an > exit policy explicitly rejecting his own IP that he > would be safe from this sort of compromise? Yes, except in cases where a) he doesn't know the extent to which local services trust his IP address, and b) he is on a dynamic IP address. Unfortunately, I suspect these are exactly the contexts where it's most important for users to understand what's going on, *and* exactly the contexts where the users will be most ignorant about the issues. Where do you suggest we put the warnings, and can you suggest some sample phrasings? We could e.g. add a note to step 9 on https://www.torproject.org/docs/tor-doc-relay#after but I fear that most users can't (won't) count to 9. Another option is to assume that most home users will be configuring relaying via Vidalia, so we should concentrate on explaining all the various issues there. (In fact, Vidalia doesn't currently have a good interface for letting people tweak their exit policy by *addresses* as well as ports.) Another thought is that Tor relays already know their public IP address, since after all they have to advertise it. Perhaps the default exit policy should reject connections to that IP address, unless the operator explicitly allows them? See also the "ExitPolicyRejectPrivate" entry in the man page. This would be a shame to set up by default, but maybe secure-by-default-for-end-users is a trend we should embrace. And lastly, just to cover all bases: is there any point to this additional complexity given that the attacks can already be done just fine via a web browser? I guess it depends what assumptions we want to make about the users. My instinct would be 'yes'. > All this leads to another question I have about tor > which will probably really show how ignorant I am. > What prevents tor exit nodes from spoofing any IP that > they want and easily setting up phishing attacks?? The same thing that prevents bad people from doing it in airports, local coffeeshop wifi, and so on: users should use SSL if they want to be sure they're talking to the right destination. See e.g. point #4 at https://www.torproject.org/download#Warning > A new excited but confused/concerned tor user, ;) Welcome. Hope that helps to explain a bit. --Roger
