|
|
[[PageOutline]]
|
|
|
|
|
|
= Tor Relay Security and Best Practices =
|
|
|
# Tor Relay Security and Best Practices
|
|
|
|
|
|
This document aims to motivate and describe some best practices for Tor Relay security, grounded in a realistic threat model.
|
|
|
|
|
|
This document is written only from the point of view of protecting your Tor Relay from that threat model. It assumes that Tor is the most important process on the machine, and that protecting other things from Tor is therefore out of scope. For general information on securing your machine against attacks through the Tor daemon itself, see the [wiki:doc/OperationalSecurity Operational Security] page.
|
|
|
This document is written only from the point of view of protecting your Tor Relay from that threat model. It assumes that Tor is the most important process on the machine, and that protecting other things from Tor is therefore out of scope. For general information on securing your machine against attacks through the Tor daemon itself, see the [Operational Security](./doc/OperationalSecurity) page.
|
|
|
|
|
|
For information on running an exit relay, see [https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment Tips for Running an Exit Node with Minimal Harassment] as well as the set of [wiki:doc/TorAbuseTemplates Tor Abuse Templates].
|
|
|
For information on running an exit relay, see [Tips for Running an Exit Node with Minimal Harassment](https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment) as well as the set of [Tor Abuse Templates](./doc/TorAbuseTemplates).
|
|
|
|
|
|
As of Tor 0.2.7 we use ed25519 identities for relays with an optional feature to generate and keep the ed25519 master identity secret key offline. The relay will use a temporary signing key with limited lifetime, so it will require periodic renewals for the temporary signing key. This will ensure the relay keeps the same identity regardless what happens to the temporary signing keys. [https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineKeys Read this guide to learn more about offline relay identity keys].
|
|
|
As of Tor 0.2.7 we use ed25519 identities for relays with an optional feature to generate and keep the ed25519 master identity secret key offline. The relay will use a temporary signing key with limited lifetime, so it will require periodic renewals for the temporary signing key. This will ensure the relay keeps the same identity regardless what happens to the temporary signing keys. [Read this guide to learn more about offline relay identity keys](https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineKeys).
|
|
|
|
|
|
= Adversary Goals and Threat Model =
|
|
|
|
... | ... | @@ -17,18 +17,18 @@ capability distinction governs the adversary goals in terms of compromising rela |
|
|
|
|
|
Adversaries that can unwrap router TLS can perform every attack that an actual node can perform, at any location between the user and the node, and/or between the node and other nodes.
|
|
|
|
|
|
In particular, adversaries that can see inside router TLS can perform [https://lists.torproject.org/pipermail/tor-dev/2012-March/003361.html tagging attacks] as well as perform circuit-specific active and passive timing analysis.
|
|
|
In particular, adversaries that can see inside router TLS can perform [tagging attacks](https://lists.torproject.org/pipermail/tor-dev/2012-March/003361.html) as well as perform circuit-specific active and passive timing analysis.
|
|
|
|
|
|
These attacks can be quite severe. An adversary that is able to obtain Guard identity keys is free to perform a tagging attack anywhere on the Internet. In other words, if the adversary is interested in monitoring a particular user, the adversary need only obtain the identity keys for that user's 3 guard nodes, and from that point on, the adversary will be able to transparently monitor everything that user does by way of using tagging to bias the users paths to connect only to surveilled exit nodes who also have had their identity keys compromised.
|
|
|
|
|
|
= Attack Vectors =
|
|
|
# Attack Vectors
|
|
|
|
|
|
There are two high-level vectors towards seeing inside node-to-node TLS
|
|
|
(which uses ephemeral keys that are rotated daily and authenticated via
|
|
|
the node's identity key). Both high-level vectors therefore revolve
|
|
|
around node identity key theft.
|
|
|
|
|
|
== Attack Vector !#1: One-Time Key Theft ==
|
|
|
## Attack Vector !#1: One-Time Key Theft
|
|
|
|
|
|
The one-time adversary is interested in performing a grab of keys and
|
|
|
then operating transparently upstream afterwords. This adversary will
|
... | ... | @@ -40,7 +40,7 @@ this adversary will likely see it in the form of unexplained |
|
|
reboots/mysterious downtime, which are inevitable in the lifespan of any
|
|
|
Tor node.
|
|
|
|
|
|
== Attack Vector !#2: Persistent Key Theft ==
|
|
|
## Attack Vector !#2: Persistent Key Theft
|
|
|
|
|
|
If one-time methods fail or are beyond reach, the adversary has to
|
|
|
resort to persistent machine compromise to retain access to node key
|
... | ... | @@ -62,7 +62,7 @@ Unfortunately, it is also a more expensive attack to defend against, |
|
|
because it requires extensive auditing and assurance mechanisms on the
|
|
|
part of the relay operator.
|
|
|
|
|
|
= Defenses =
|
|
|
# Defenses
|
|
|
|
|
|
It seems clear that the above indicates that at minimum relays should
|
|
|
protect against one-time key compromise. Some further thought shows that
|
... | ... | @@ -71,14 +71,14 @@ with significantly more effort. |
|
|
|
|
|
Let's deal with defending against each vector in turn.
|
|
|
|
|
|
== Vector !#1: Deploy Ephemeral Identity Keys ==
|
|
|
## Vector !#1: Deploy Ephemeral Identity Keys
|
|
|
|
|
|
The simplest way to defend against the adversary who attempts to extract
|
|
|
relay keys through a reboot is to take advantage of the fact that even
|
|
|
node identity keys can be ephemeral, and do not need to persist long
|
|
|
term (certainly not past a reboot). This can be achieved with a boot
|
|
|
script that wipes your keys (they live in /var/lib/tor/keys) at startup,
|
|
|
or by [http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/ using a ramdisk].
|
|
|
or by [using a ramdisk](http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/).
|
|
|
|
|
|
Periodically (on the order of every 12 to 18 months), you should completely
|
|
|
wipe your node identity keys as a best practice and restart fresh even in the absence
|
... | ... | @@ -88,13 +88,13 @@ It only takes 2 weeks for your node to regain the Guard flag, for example. |
|
|
Additionally, ssh server key theft is another one-time vector that can
|
|
|
be used to quickly bootstrap into node key theft. For this reason, node
|
|
|
admins should always use ssh key auth for tor node administration
|
|
|
accounts, since it [http://www.gremwell.com/ssh-mitm-public-key-authentication prevents ssh server key theft from allowing continuous server compromise].
|
|
|
accounts, since it [prevents ssh server key theft from allowing continuous server compromise](http://www.gremwell.com/ssh-mitm-public-key-authentication).
|
|
|
|
|
|
== Vector !#1: Offline Master Keys ==
|
|
|
## Vector !#1: Offline Master Keys
|
|
|
|
|
|
Even stronger than ephemeral identity keys are [https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineKeys offline master keys] that are never exposed to the relay at all. This makes regular reputation resets (due to key resets) unnecessary and provides stronger assurances to the identity key when compared to keys that are deleted on reboot or every 12 to 18 months.
|
|
|
Even stronger than ephemeral identity keys are [offline master keys](https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineKeys) that are never exposed to the relay at all. This makes regular reputation resets (due to key resets) unnecessary and provides stronger assurances to the identity key when compared to keys that are deleted on reboot or every 12 to 18 months.
|
|
|
|
|
|
== Vector !#2: Isolation Hardening and Readonly Runtime ==
|
|
|
## Vector !#2: Isolation Hardening and Readonly Runtime
|
|
|
|
|
|
Once one-time key theft has been dealt with, you can begin to consider
|
|
|
how to deal with the Persistent threat.
|
... | ... | @@ -104,12 +104,12 @@ and it is not expected that all operators will devote the effort to do |
|
|
so.
|
|
|
|
|
|
To limit scope, we are not going to deal with the daemon compromise
|
|
|
vector; for that see your [wiki:doc/OperationalSecurity Operating System's least-privilege mechanisms]
|
|
|
vector; for that see your [Operating System's least-privilege mechanisms](./doc/OperationalSecurity)
|
|
|
(such as SElinux, AppArmor, Grsec RBAC, Seatbelt, etc).
|
|
|
Instead, we will deal with how you can attempt to protect your identity keys once an adversary
|
|
|
already has root access.
|
|
|
|
|
|
=== Disabling the ptrace syscall ===
|
|
|
### Disabling the ptrace syscall
|
|
|
|
|
|
If you are serious about defending against this adversary, the first
|
|
|
thing you will want to do is disable access to the 'ptrace' system call
|
... | ... | @@ -117,7 +117,7 @@ from userland, which allows easy Tor key theft using debugging tools such |
|
|
as gdb. Note that all currently deployed mechanisms to do this still allow root
|
|
|
users to use ptrace on arbitrary processes. In order to disable ptrace
|
|
|
for root users, you need to load a
|
|
|
[https://gist.github.com/1216637 kernel module to delete the ptrace call from the syscall table].
|
|
|
[kernel module to delete the ptrace call from the syscall table](https://gist.github.com/1216637).
|
|
|
|
|
|
Once access to the ptrace system call is removed, you need to disable
|
|
|
module loading to prevent it from being restored. On Linux, this is
|
... | ... | @@ -129,7 +129,7 @@ ptrace module, and then issue the sysctl to disable further module |
|
|
loading. Redhat-derivatives launch /etc/rc.modules first thing at the
|
|
|
top of /etc/rc.sysinit.
|
|
|
|
|
|
=== Ensuring Runtime Integrity ===
|
|
|
### Ensuring Runtime Integrity
|
|
|
|
|
|
After that comes ensuring runtime integrity. There are several ways to
|
|
|
achieve this, but most are easily subverted by an attacker with direct
|
... | ... | @@ -147,19 +147,19 @@ encrypted, since node keys are stored in var. |
|
|
|
|
|
Here are the commands for creating the root loopback filesystem:
|
|
|
|
|
|
{{{
|
|
|
```
|
|
|
dd if=/dev/urandom of=./tor-root.img bs=1k count=25k
|
|
|
losetup /dev/loop1 ./tor-root.img
|
|
|
cryptsetup luksFormat /dev/loop1
|
|
|
cryptsetup luksOpen /dev/loop1 tor-root
|
|
|
mkfs.ext4 /dev/mapper/tor-root
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
When you use this loopback, you will mount it readonly, and mount an
|
|
|
unencrypted var directory inside of it, and a ramdisk for your keys
|
|
|
inside of that. For now, you'll leave it readwrite for setup.
|
|
|
|
|
|
{{{
|
|
|
```
|
|
|
dd if=/dev/urandom of=./tor-var.img bs=1k count=200k
|
|
|
losetup /dev/loop2 ./tor-var.img
|
|
|
cryptsetup luksFormat /dev/loop2
|
... | ... | @@ -170,16 +170,16 @@ inside of that. For now, you'll leave it readwrite for setup. |
|
|
mount /dev/mapper/tor-root /mnt/tor-root
|
|
|
mkdir /mnt/tor-root/var
|
|
|
mount /dev/mapper/tor-var /mnt/tor-root/var
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
=== Volume Setup and Authentication ===
|
|
|
### Volume Setup and Authentication
|
|
|
|
|
|
Once you've got your volumes set up, you can then run the scripts attached
|
|
|
to this wiki page to copy your known-good Tor runtime into the volume.
|
|
|
|
|
|
{{{
|
|
|
```
|
|
|
XXX: demo script use
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
The attached scripts have been tested to work on RHEL/CentOS and Ubuntu
|
|
|
systems, and may work on Fedora and Debian systems as well.
|
... | ... | @@ -188,10 +188,10 @@ Don't forget to periodically update the libraries stored on your |
|
|
loopback root using a trusted offsite source, as they won't receive
|
|
|
security updates from your distribution. You want to avoid using static
|
|
|
tor binaries, as they also suffer from the update problem, and additionally
|
|
|
do not recieve the benefit of per-library [https://en.wikipedia.org/wiki/Address_space_layout_randomization ASLR].
|
|
|
do not recieve the benefit of per-library [ASLR](https://en.wikipedia.org/wiki/Address_space_layout_randomization).
|
|
|
|
|
|
|
|
|
=== Identity Key Management ===
|
|
|
### Identity Key Management
|
|
|
|
|
|
Once you start your tor process(es), you will want to copy your identity
|
|
|
key offsite, and then remove it. Tor does not need it to remain on disk
|
... | ... | @@ -200,10 +200,10 @@ kernel exploit to obtain it from memory. While you should not re-use the |
|
|
identity key after unexplained reboots, you may want to retain a copy
|
|
|
for planned reboots and tor maintenance.
|
|
|
|
|
|
{{{
|
|
|
```
|
|
|
scp /mnt/tor-root/var/lib/tor/keys/secret_id_key offsite_backup:/mnt/usb/tor_key
|
|
|
rm /mnt/tor-root/var/lib/tor/keys/secret_id_key
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
Upon suspicious reboots, you can verify the integrity of your tor image
|
|
|
by simply calculating the sha1sum (perhaps copying the image offsite
|
... | ... | @@ -214,7 +214,7 @@ account on your system (by rebooting it, for example) from obtaining |
|
|
your identity keys directly, forcing them to resort to kernel exploits
|
|
|
and memory gymnastics in order to do so.
|
|
|
|
|
|
=== Auditing the Kernel and Boot Scripts ===
|
|
|
### Auditing the Kernel and Boot Scripts
|
|
|
|
|
|
After suspicious reboots, you should audit your initrd, kernel image, modules, and init scripts
|
|
|
as best you can. |
|
|
\ No newline at end of file |