All,
Are there anything special that needs to be done to make sure that Tor nodes running inside VMs (VPS) is protected from snooping eyes? Since there is hardly any data at rest I am assuming not, but then, what do I know!:)
-kali-
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/2/2014 9:50 AM, Kali Tor wrote:
All,
Are there anything special that needs to be done to make sure that Tor nodes running inside VMs (VPS) is protected from snooping eyes? Since there is hardly any data at rest I am assuming not, but then, what do I know!:)
-kali-
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Kali
I don't understand what exactly you mean, snooping eyes.Anyone can see at anytime that the VPS in questions is a Tor relay. 1 method is by seeing the traffic it generates and second is the consensus data in the Tor network, where all relays IP addresses are listed. This should not be a problem whatsoever, Tor is not designed to hide the fact that you use it or that you run a Tor relay. It is designed to offer anonymity and privacy in activity, not if you use it or not.
If you are asking how to secure your box better, indeed the public IP address list of relays is often scanned and brute forced. That is why I recommend:
- - if you run only Tor on that box is best, if not make sure your apps are properly secured (mysql not listening on public IP if it's not a remote mysql server, strong passwords for mysql, ftp, etc.). - - make sure only ports used by Tor are open. There is no need for anything else. - - if you use ssh for administration that is fine, just change the port from 22 in /etc/ssh/sshd_config to some custom port, anything, like 2988 or whatever. - - permanently disabled plain password authentication or rhost authentication in sshd_config and only allow key-based authentication for better security and protection against weak password probing. - - do not allow any other users for SSH access.
Let me know if you have any other questions.
- -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
Hi,
If you are asking how to secure your box better, indeed the public IP address list of relays is often scanned and brute forced. That is why I recommend:
- if you run only Tor on that box is best, if not make sure your apps
are properly secured (mysql not listening on public IP if it's not a remote mysql server, strong passwords for mysql, ftp, etc.).
- make sure only ports used by Tor are open. There is no need for
anything else.
- if you use ssh for administration that is fine, just change the port
from 22 in /etc/ssh/sshd_config to some custom port, anything, like 2988 or whatever.
- permanently disabled plain password authentication or rhost
authentication in sshd_config and only allow key-based authentication for better security and protection against weak password probing.
- do not allow any other users for SSH access.
Let me know if you have any other questions.
I have done all that, so covered on that aspect. Was wondering if disk encryption and use of something like TRESOR would be useful?
-kali-
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/2/2014 2:46 PM, Kali Tor wrote:
Hi,
If you are asking how to secure your box better, indeed the public IP address list of relays is often scanned and brute forced. That is why I recommend:
- if you run only Tor on that box is best, if not make sure
your apps are properly secured (mysql not listening on public IP if it's not a remote mysql server, strong passwords for mysql, ftp, etc.). - - make sure only ports used by Tor are open. There is no need for anything else. - - if you use ssh for administration that is fine, just change the port from 22 in /etc/ssh/sshd_config to some custom port, anything, like 2988 or whatever. - - permanently disabled plain password authentication or rhost authentication in sshd_config and only allow key-based authentication for better security and protection against weak password probing. - - do not allow any other users for SSH access.
Let me know if you have any other questions.
I have done all that, so covered on that aspect. Was wondering if disk encryption and use of something like TRESOR would be useful?
-kali- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Full disk encryption on a Tor relay, if it's just a Tor relay it's overkill. It will just increase the HDD I/O rate and resource consumption.
Also, most important, if you use full disk encryption and your vm gets somehow rebooted (migrated to another cluster by your provider, update to the host OS or hardware, etc.) and you are not around to enter the passphrase for full disk encryption your operating system will not boot and cause you long downtime, until you are available to manually enter the passphrase. this can cause you to lose flags in the consensus, because of extended downtime.
Important to say that Tor does not have any files which need to encrypted. Tor, by design protects each relay by not knowing both the original source and the final destination of the traffic. It just has some cache of the consensus data, which anyone can publicly get from the Tor network without needing to break your box or hack your full disk encryption.
Only things which are secret are your onion keys, which give your relay's fingerprint. Make sure you back those up, in case you need to re-install this relay.
If you use that vm for something else too and you have some sensitive data there, it is always a good idea to encrypt everything... but in your scenario full disk encryption will not help since you are exposed to physical attacks (e.g. someone caching your files while your virtual machine is RUNNING, making full disk encryption useless).
- -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
On Wed, Jul 2, 2014 at 7:46 AM, Kali Tor kalitor42@yahoo.com wrote:
I have done all that, so covered on that aspect. Was wondering if disk encryption and use of something like TRESOR would be useful?
The private keys for the node are sensitive, and even the .tor/state file for the guard nodes could be if the attacker does not already have that info, same for any non default node selection stuff in torrc. Tor presumably validates the disk consensus files against its static keys on startup so that's probably ok yet all easily under .tor anyway.
There was a thread on this some time ago you can find.
grarpamp:
On Wed, Jul 2, 2014 at 7:46 AM, Kali Tor kalitor42@yahoo.com wrote:
I have done all that, so covered on that aspect. Was wondering if disk encryption and use of something like TRESOR would be useful?
The private keys for the node are sensitive, and even the .tor/state file for the guard nodes could be if the attacker does not already have that info, same for any non default node selection stuff in torrc. Tor presumably validates the disk consensus files against its static keys on startup so that's probably ok yet all easily under .tor anyway.
Some says that it's better to leave the disk unencrypted because in case of seizure by the police, they can easily attest that the system was only running Tor and nothing else.
Some disagrees and says that we should always encrypt to make tampering and (extra-)legal backdoor installation more difficult.
I believe the best strategy has never been really determined so far.
* on the Thu, Jul 03, 2014 at 10:02:06AM +0200, Lunar wrote:
I have done all that, so covered on that aspect. Was wondering if disk encryption and use of something like TRESOR would be useful?
The private keys for the node are sensitive, and even the .tor/state file for the guard nodes could be if the attacker does not already have that info, same for any non default node selection stuff in torrc. Tor presumably validates the disk consensus files against its static keys on startup so that's probably ok yet all easily under .tor anyway.
Some says that it's better to leave the disk unencrypted because in case of seizure by the police, they can easily attest that the system was only running Tor and nothing else.
Even if it's encrypted, you can easily attest the exact same thing by handing over your password... If you choose to do so.
Some disagrees and says that we should always encrypt to make tampering and (extra-)legal backdoor installation more difficult.
I believe the best strategy has never been really determined so far.
I know of only two benefits to not encrypting.
1.) On some systems, for some workloads, you might have some level of improved performance. For a Tor node, I doubt there is any noticable difference.
2.) You can reboot without having to enter a password.
Encryption gives you choice. The choice to hand over your password/key or not. As far as I'm concerned, "the best strategy" *has* been determined and it's to encrypt...
On Thursday, July 3, 2014 9:11 AM, Mike Cardwell tor@lists.grepular.com wrote:
- on the Thu, Jul 03, 2014 at 10:02:06AM +0200, Lunar wrote:
I have done all that, so covered on that aspect. Was wondering if
disk encryption and use of something like TRESOR would be useful?
The private keys for the node are sensitive, and even the .tor/state file for the guard nodes could be if the attacker does not already have that info, same for any non default node selection stuff in torrc. Tor presumably validates the disk consensus files against its static keys on startup so that's probably ok yet all easily under .tor anyway.
Some says that it's better to leave the disk unencrypted because in
case
of seizure by the police, they can easily attest that the system was only running Tor and nothing else.
Even if it's encrypted, you can easily attest the exact same thing by handing over your password... If you choose to do so.
Some disagrees and says that we should always encrypt to make tampering and (extra-)legal backdoor installation more difficult.
I believe the best strategy has never been really determined so far.
I know of only two benefits to not encrypting.
1.) On some systems, for some workloads, you might have some level of improved performance. For a Tor node, I doubt there is any noticable difference.
2.) You can reboot without having to enter a password.
Encryption gives you choice. The choice to hand over your password/key or not. As far as I'm concerned, "the best strategy" *has* been determined and it's to encrypt...
Thanks for the discussion on this.
If disk encryption is indeed the way to go, how many of the node operators do actually encrypt the disk? Has there been any performance issues? I ask specifically because I run in a VPS where resources are limited (compared to a proper machine).
- kali-
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/3/2014 1:40 PM, Kali Tor wrote:
On Thursday, July 3, 2014 9:11 AM, Mike Cardwell tor@lists.grepular.com wrote:
- on the Thu, Jul 03, 2014 at 10:02:06AM +0200, Lunar wrote:
I have done all that, so covered on that aspect. Was wondering if
disk encryption and use of something like TRESOR would be useful?
The private keys for the node are sensitive, and even the .tor/state file for the guard nodes could be if the attacker does not already have that info, same for any non default node selection stuff in torrc. Tor presumably validates the disk consensus files against its static keys on startup so that's probably ok yet all easily under .tor anyway.
Some says that it's better to leave the disk unencrypted because in
case
of seizure by the police, they can easily attest that the system was only running Tor and nothing else.
Even if it's encrypted, you can easily attest the exact same thing by handing over your password... If you choose to do so.
Some disagrees and says that we should always encrypt to make tampering and (extra-)legal backdoor installation more difficult.
I believe the best strategy has never been really determined so far.
I know of only two benefits to not encrypting.
1.) On some systems, for some workloads, you might have some level of improved performance. For a Tor node, I doubt there is any noticable difference.
2.) You can reboot without having to enter a password.
Encryption gives you choice. The choice to hand over your password/key or not. As far as I'm concerned, "the best strategy" *has* been determined and it's to encrypt...
Thanks for the discussion on this.
If disk encryption is indeed the way to go, how many of the node operators do actually encrypt the disk? Has there been any performance issues? I ask specifically because I run in a VPS where resources are limited (compared to a proper machine).
- kali-
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Depends, what configuration will that virtual machine have? You shouldn't notice too big of a difference, full disk encryption is not a resource killer on any configuration.
- -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
If disk encryption is indeed the way to go, how many of the node operators do actually encrypt the disk? Has there been any performance issues? I ask specifically because I run in a VPS where resources are limited (compared to a proper machine).
- kali-
Depends, what configuration will that virtual machine have? You shouldn't notice too big of a difference, full disk encryption is not a resource killer on any configuration.
s7r
1GB RAM, 1CPU Core, 20GB SSD. Currently being used just for Tor.
-kali-
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/3/2014 2:18 PM, Kali Tor wrote:
If disk encryption is indeed the way to go, how many of the node operators do actually encrypt the disk? Has there been any performance issues? I ask specifically because I run in a VPS where resources are limited (compared to a proper machine).
- kali-
Depends, what configuration will that virtual machine have? You shouldn't notice too big of a difference, full disk encryption is not a resource killer on any configuration.
- -- s7r
1GB RAM, 1CPU Core, 20GB SSD. Currently being used just for Tor.
-kali-
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Yeah, as i thought you won't notice any penalty over performance if you enable full disk encryption, just keep in mind you have to be around and enter the passphrase at each and every reboot otherwise the operating system will not boot.
And on a virtual machine, full disk encryption will not protect you against physical access to the host machine while the VM is running, keep that in mind (the decryption key is stored in the RAM memory otherwise the machine cannot run, they can pause, capture files, resume or unlimited of other things to break your encryption). - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
tor-relays@lists.torproject.org
-
grarpamp -
Kali Tor -
Lunar -
Mike Cardwell -
s7r