As a Tor relay operator, you have a responsibility to your users to maintain a secure system. Consider yourself something like a small ISP - people rely on you for their safety and privacy. This guide gives suggestions on how to secure (harden) a relay. Its goal is to give general suggestions and refer to outside resources for specifics.
This document is currently focused on Unix-like operating systems (Linux, *BSD, Darwin/OS X, etc.). If you have suggestions, including hardening information for other platforms, please share. Other questions can be asked on tor-relays@lists.torprojects.org.
Keep your software up-to-date. This includes Tor, your operating system, and all installed packages. Remember also to restart your machine after major updates to ensure that they are fully applied.
Check your Tor and system logs frequently, and configure aliases so that you receive important system events by email. See ‘man aliases’ on most Unix-like OSs for details.
Install as little as possible. For most Unix-like OSs, Tor and its dependencies are the only things that must be installed. If anything, focus your effort on disabling unnecessary services.
Don’t run anything that accesses the network other than Tor, OpenSSH, and NTP on your relay. This includes HTTP and FTP servers, BitTorrent clients and trackers, web browsers, Jabber/XMPP servers, and game servers. Software updates are probably a necessary exception.
Don’t allow anyone else access to your relay.
If you make a dangerous lapse of judgement (e.g. uploading your password in a shell script to a pastebin) or notice any suspicious activity, reinstall your operating system and use new passwords and private keys.
Do not back up your relay’s Tor identity key or SSH key. They should live and die on the server. If they’re lost, you can always start with new ones. It’ll only cost you a week or two of low bandwidth. Having your relay’s identity compromised is much more serious.
Most Unix-like operating systems use OpenSSH for remote access. A misconfigured SSH server is easily exploitable, and many botnets attempt to bruteforce SSH servers.
Non-SSH remote access protocols (telnet et al.) and odd or out-of-date SSH software are security risks.
The following changes lead to a much more secure SSH server:
SSH protection daemons like SSHGuard and fail2ban can cause problems. You’re likely to see bruteforce attacks from Tor exit nodes, and you don’t want those to be blocked.
Be sure you understand what you’re doing before you do it! Careless SSH configuration can lock you out of your own server.
Ubuntu offers a good guide on OpenSSH configuration. DigitalOcean has a similar tutorial that also covers forbidding root login. Debian offers a more concise guide for experienced sysadmins.
Non-exit relays should only have incoming and outgoing connections on their ORPort, DirPort, and SSH port. Exit relays should only have incoming connections on their ORPort, DirPort, and SSH port, but can have outgoing connections to any port allowed by their exit policy.
Firewalls can easily restrict access to these conditions. They can also clean up poorly formatted packets and drop senseless or potentially dangerous ones.
For Linux, IPTables is the default firewall:
For OS X and most BSD variants, PF is included or available.
Firewall configurations or features suggested online often contain automatic blacklist generators. These can be a problem for Tor relays because the Tor network is sometimes used for bruteforce attacks. If someone tries to bruteforce your relay through an exit node and you block it, you can no longer relay traffic to or from the exit node. Therefore, if you’re going to use a blacklist, make sure that it only blocks incoming connections to your SSH port.
If possible, encrypt your hard drive.
If your system has swap space, make sure it’s encrypted. It can leave cryptographic keys or sensitive user data on your hard disk for an indeterminate amount of time.
If you’re running an exit relay, use a local recusive DNS resolver rather than a remote DNS server like OpenDNS. Using a remote server shares too much information about your users’ activity. Most people prefer Unbound for this.
In this case, make sure that 127.0.0.1 is the only nameserver listed
in /etc/resolv.conf.
BIND will also work.
Carefully consider the security implications of your choice of operating system. Some are designed to be secure by default, while others demand a lot of hardening and may be fundamentally exploitable.
Debian offers a very thorough security guide.
A simple and effective method described in this guide is to simply run:
sudo apt-get install harden
This will install security software, uninstall risky packages, and warn you when you try to install insecure software. However, many people often feel that it pulls in too much cruft. For details, see the manual.
Be sure to stay up-to-date using apt-get, and consider using cron-apt or unattended-upgrades to automatically update.
Ubuntu is built upon Debian, so most Debian hardening techniques also apply to Ubuntu.
A core goal of the OpenBSD project is to publish very stable releases that need few or no security updates. About ten patches per six-month release are published - most have possible security implications, so you should stay up-to-date with them. Subscribe to the security-announce mailing list to be notified of new patches.
Be sure to use the -stable branch, not -current. Never use an OpenBSD release more than one behind the latest release (e.g. if 5.6 is the latest release, don’t use anything older than 5.5).
Tor hosts an operational security guide on its wiki (slightly dated).