Tips for Running an Exit Node with Minimal Harassment

mikeperry — Sun, 21 Jun 2009 03:08:08 -0700

I have noticed that a lot of new exit nodes have recently appeared on the network. This is great news, since exit nodes are typically on the scarce side. Exits usually occupy 30-33% of network by capacity, but are currently at a whopping 38.5% (156 MBytes/sec out of 404 total).

However, I want to make sure that these nodes stay up and don't end up being shut down due to easily preventable abuse complaints. I've run a number of exit nodes on a few different ISPs and not only have I lived to tell about it, I've have not had one shut down yet. Moreover, I've only received about 4 abuse complaints in as many years of running exit nodes. This is in stark contrast to other node operators following a more reactive strategy. I'm convinced this is largely because I observe the following pro-active guidelines.

1. Inform your ISP
This is the most important rule for running a long-lived exit node, especially if you have your choice of ISP. Pick an ISP you can trust, and let them know exactly what is going on. Explain Tor to them, and why it is important to the Internet, the world, and to you, their customer. Giving them links to our Tor Users, Tor Overview, Tor Legal FAQ and Tor Abuse FAQ is typically immensely helpful. Mentioning China and the current conflict in Iran are also likely to be helpful. If your ISP is your University, you may also want to peruse this set of recommendations specific to dealing with University administrators.

If your ISP does not approve, all is not lost: you can look into running a middle node, or a much less visible bridge node. It is better to learn this up front, rather than have your Internet connection shut down on you without warning. Exit bandwidth is often scarce, but any node is better than no node.

2. Get a separate IP for the node. Do not route your own traffic via this IP
While it may be tempting to mix in your traffic with your node's exit traffic for cover, this is best avoided. Having a separate IP allows your ISP to more easily recognize that abuse complaints and DMCA notices can be forwarded to you to be quickly responded to with a boilerplate response, as opposed to cutting off your Internet access or providing your personal information to the copyright cartels.

3. Get recognizable Reverse DNS for this IP
Setting a good reverse DNS name for your exit IP helps to prevent knee-jerk reactions from sysadmins and DoS kiddies alike who run into bad apples coming from your node IP. Something like tor-exit.yourdomain.org or tor-proxy-readme.yourdomain.org is the best bet.

4. Set up a Tor Exit Notice
Once you have a good reverse DNS name, you should put some content there that explains what Tor is for those who see the name and try to visit it via http. If you run your DirPort on port 80 with Tor 0.2.1.x or newer, you can use the Tor config option "DirPortFrontPage" to display a notice explaining that you are running an exit node. A sample one is provided in contrib/tor-exit-notice.html in the source distribution. This way, when someone sees tor-proxy-readme.yourdomain.org in their logs, they hopefully will get the hint and read the notice before flaming you. Be sure to update the contact info and other places marked with FIXME in the notice.

5. Get ARIN registration (if possible)
If you can get your ISP to SWIP your IP block to display a contact and abuse email that you control, this can go a long way to reducing aggravation that they may feel from dealing with the occasional abuse complaint, because the vast majority of the few complaints that are still made will go to you instead of them.

6. Rate limit and optionally QoS your node
I've recently conducted some measurements that showed that nodes that used Tor's BandwidthRate config option to set a limit slightly below their actual capacity were much more reliable than those that did not. Along these lines, it may also be useful to use this Linux-based QoS script to prioritize your Tor IP traffic below other traffic on your machine. Similar QoS can also be achieved via DDWRT, openwrt and of course via commercial routers. If you use do QoS other than that script, you should ensure that you provide Tor with a reasonable minimum bandwidth so that it does not starve when you do other things. Somewhere between 33 and 50% of your connection is a reasonable minimum value.

That's it! Happy operating!

In praise of multiple options for circumvention

phobos — Mon, 16 Feb 2009 16:31:16 -0800

I was asked the other day why we don't advocate for just Tor as the one tool to rule them all. My glib answer is "of course we do, however the larger the toolbox, the better off the world."

Expanding on that notion, the various anonymity, privacy, and circumvention tools target different people and use cases. Tor advocates for Anonymity first, circumvention second. It would be very naive of us to think that we can solve all use cases. In fact, it would be silly of us to try to dictate the needs of any user. The larger the ecosystem of privacy and anonymity tools, the more options for users, and the better off we are as a whole.

At the core, Tor is a protocol and a set of specifications. Others can take our documentation and build upon it for their own tool. The EU PRIME project did this and created a fully Java implementation of Tor with a GUI. The result was called OnionCoffee. It's woefully out of date now, but the proof of concept stands; it can be done. The purpose of specifying a protocol is to leave interpretation and implementation as open as possible. Imagine if the creators of the Internet Protocol restricted implementations to exactly as they had envisioned 40-something years ago. As for Tor, there is much more protocol work to be done, research completed, and our reference implementation polished before we can consider online anonymity solved, or even close to solved.

We are often asked, "I use tool X, what do you think about it? Should I switch to Tor?"

Instead of an answer, we ask a series of questions to find out why they use X; for the reasons of learning more about X, why people choose X, and what Tor may lack. It turns out, they use X because their friends use X, and they know the strengths and weaknesses of the software well. It may not be perfect, but they know what the software can and cannot do. They know if a tool is compromised, or access to the service is shut off, they can switch to another. If there was only one tool, once it is blocked or disappears, the users are screwed. Isn't it great to have options?

Obviously, we state that Tor is a fine solution, and perhaps they should add the concept of anonymity and our software to their list of options. Our goal is educating users to help themselves and others. Anyone who suggests otherwise is trying to sell you something.

education

Tips for Running an Exit Node with Minimal Harassment

In praise of multiple options for circumvention