Running tor in VPS - keep away snooping eyes
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJTs+YiAAoJEIN/pSyBJlsRqwwH/1yYOsjM/7eVB4S6BjkEVbdZ cNXeYB2wyFQdKWiGXTfEyXBdTWUMiXl2YJNol1K8L0bDhv3H90lRBzhGpxUGbIjr BPZqwUYvR8FnzildmmUTRlzntq0mfbMQ9E7jXWhepS95QA5JxH2D4Bl2qCb7//uq HXlB76YIdDS3D57wKlF8r2JGFYlIbg38gEtvnY2X4755KpJrxlFUPkqVsLAl4j5c z9PQzR0qw5mdEnMGWFdkve4Qlq1FL9lYx0+UmO0VCGcpiHcHMLhtVTMX6Ieq/zGP apTJ8L5EmUaIdrCUilU4thkouBbVjnPKS3R65HXy2AjujuxtR+fuTkXyNbeAp1k= =Wk0Y -----END PGP SIGNATURE-----
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJTtCldAAoJEIN/pSyBJlsRIYEIAJ6aN9MLeDhhssA6SR8fV8JS Vmn8mJ4rbazE8JFkIqxf6sDHHPCHOyhHwc1xCe/PqIuIncNqC4G2sXNtoaFo7sMt dTLa4RvII5JJl0hk4n+F7yoj8QJLEFsdZrPaDs2vyoeK92Hrt+fSLTHmK1bkd0Bn /AKAcSNlwL4Ls3WrYrigwHFCsNKcpBIpsdukZ/mit4uDnDarPpT4j3Sy5Wm11pYI Pd3I7TXIh78kUJcjgmrVEEO5a7+SaHvFaCpZwImEb73MdCH+UhyVWnqKV8wbVWGx ZnXRJ5/d/kevnfiQLIU9/VaWut2lHpwCNgLsQzqYBa8XXPwBjmOzDx2RZrtnxZo= =VsE4 -----END PGP SIGNATURE-----
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. -- Lunar <lunar@torproject.org>
* 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... -- Mike Cardwell https://grepular.com https://emailprivacytester.com OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJTtTopAAoJEIN/pSyBJlsR9lkIAIYVigtTOYcYeihEJLx8yWs+ WRc/1p9u/YuSA62enSpqkuYYOtvMLsJiGtdRzr66kyrIqgifIStOAyTkd2un+QLq nRl2OY/jmhwg0EM0EGpdzDo9qMzEPpDOfRtoJhotnB+0Aurl8Bt6PuNhSezY3a3X VUmKaNf13SCyqyiB3cty+/gpSpTrQRoCH0lV/QtrMvHo8KqOknSbRa7LyylDz6Wv fH6C8UnIU6ueL2RxRV8h+cIla52mRJStv2LWO3+IqFBnGPrbFlZks7OjYaY74nEI r3YMg7dDgy9jT7QuL2LIBxGKsXAdDEeww+xLtbd1KRlYwt6W+JHtbVkhpO3Yfic= =3pg1 -----END PGP SIGNATURE-----
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJTtT6eAAoJEIN/pSyBJlsRT54H+wfYw2ZliTXKoL4mXyJhdzo1 wTjzjj0ONNPNOrqtdRPMLZgS7Vs0ej36rDtYdnAJSNn5XtlGkfgp5WWMzVZZuKo9 ABc7Q92YmSeWv1KCpvglA2B06Eew+8rh2j3FCRCWqb4v6BqjiohFdrB+3X5QVp6P 6LwZb4ds2PQVjqmEoEe3PHZM8jFmq8FwV978xaiAoxvvcvjLjz3rJSlGTUG60XRK mL5O1WDtx8F4OGDvFTLCsAt8+QMEBcgmu+lIOTxGIvW4Nz4L6/W7O+JG8O+zTIcS ae9k823JNBxIf9WgKrKzdO0B/t/4fcHiDCwrKpXJjzndirXAFsv+9LpEhLatkSE= =L51B -----END PGP SIGNATURE-----
participants (5)
-
grarpamp -
Kali Tor -
Lunar -
Mike Cardwell -
s7r