1

I've configured something usually advised against, but so far I have evaluated it seems perfectly safe to me. I'd like some opinions since playing with non-encrypted connections for my very sensitive data can be disastrous.

Here's my configuration:

  1. I've set up an rsyncd daemon on my backup server and defined a single backup target in /etc/rsyncd.conf; I don't want to use rsync over SSH since the backup server disallows SSH password logins
  2. The destination for the backup module is /home//.directory used exclusively for this purpose
  3. I've setup a /etc/rsyncd.secrets with plaintext username:password pair used exclusively for this purpose and not matching any local username; Owner: root, permissions 600
  4. I've opened up the configured non-standard rsyncd port with iptables but with a source (-s) restriction of just my NAS

The way I'm using this is:

  1. In my Synology NAS, I've defined an unencrypted remote rsync target in my the Hyper Backup service to connect to the respective remote rsyncd port
  2. I've enabled "client-side encryption" when defining the backup details. As far as I've read up on the way it works, it means the .hbk file it creates and transfers can only be unlocked either using the password, or the private key of specifically the Synology NAS that created it.
  3. I've used a very strong passphrase when defining that backup's encryption
  4. Since I'm using a daily local backup as another Hyper Backup task, I've configured this to happen just once per week as an off-site reassurance

Can you please consider the above and let me know if I'm right in my thoughts that it's safe to use this non-encrypted connection in this manner?

I have so far enabled it for just a small portion of my data, but I'm planning to extend it to all my sensitive personal data as soon as I get your advice :-) Thanks in advance.

  • "Safe" is not very informative. What risks are you planning against? – LSerni Jun 15 '18 at 19:03
  • Since I described the context, I considered "safe" to suffice just on its implications, and almost synonymous to "Would you do it/is it a good idea". The risks I'd worry about are of course primarily somebody being able to read the data. As outlined in my other answer, malicious corruption is a consideration, but not nearly as impactful. – insideClaw Jun 15 '18 at 23:38
1

Assuming all data to be transferred is encrypted client-side, it should be completely safe in terms of data privacy to use the regular, unencrypted rsync:// protocol. If the credentials used for authentication are also sent in the clear, then an attacker on the wire may be able to use them to modify or delete existing encrypted files. While proper client-side encryption will detect that files have been modified, files that get deleted by a malicious user will be gone.

| improve this answer | |
  • 1
    Thank you for the answer. While I have not verified that myself, I saw some mentions even unencrypted rsync doesn't transmit the credentials in plain text. However, if if they got captured, the risk you outlined is indeed the worst that should be able to happen. Considering that it's regenerated each week, of no value to the attacker, integrity verified occassionally, and that overall the backup being maliciously deleted just before it is needed, probably that's a risk not to worry about. Thanks for confirming my thought process wasn't flawed and having missed something terribly obvious :) – insideClaw Jun 15 '18 at 23:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.