[tor-relays] doc/HARDENING Draft
libertas at mykolab.com
Mon Nov 24 23:09:34 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
I thought I'd share an initial draft of doc/HARDENING. Please share
any opinions or contributions you have. This was written in a little
more than an hour, so it's still a work in progress. However, in the
spirit of prototyping before polishing, I thought I'd share early.
Here's the relevant ticket:
A specific topic of conversation is how much of the advice should be
in the document itself as opposed to linked sources.
It could also use more OS diversity. After reading it, you can
probably guess which *nix flavors I'm familiar with.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
-------------- next part --------------
This guide is currently focused on Unix-like operating systems (Linux,
*BSD, Darwin/OS X). If you have suggestions, including hardening
information for other platforms, please send them to
tor-relays at lists.torprojects.org.
Keep your software up-to-date. This includes Tor, your operating system,
and all installed packages.
Look at your Tor logs and system log frequently.
Install as little as possible. For most Unix-like OSs, Tor and its
library dependencies are the only things that must be installed,
although an SSH protection daemon is nice (described below). If
anything, focus your effort on disabling unnecessary services.
Don't run anything that accesses the network other than Tor and OpenSSH on your
relay. This includes HTTP and FTP servers, BitTorrent clients and
trackers, web browsers, Jabber/XMPP servers, and game servers. Software
updaters are probably a necessary exception.
Don't allow anyone else access to your relay.
If you made 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
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 SSH client or
server software are a security risk.
The following changes lead to a much more secure SSH server:
* disabling root login
* allowing only public-key authentication
* allowing only a specific user to log in
* allowing logins only from a specific IP or IP block
* using an SSH protection daemon like fail2ban or SSHGuard
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 guide that also covers forbidding root login:
Debian offers a more concise guide for experienced sysadmins:
SSH protection daemons:
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.
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. For details:
Be sure to stay up-to-date using apt-get, and consider using cron-apt to
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's operational security guide on its wiki (slightly dated):
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 543 bytes
Desc: not available
More information about the tor-relays