You are here
Jay A - Sat, 2019/10/12 - 10:06
Can hard drive/partition/folder where the data resides be encrypted in Syncthing server? Any other ideas on how to secure data?
Jay
Forum:
Tags:
Can hard drive/partition/folder where the data resides be encrypted in Syncthing server? Any other ideas on how to secure data?
Jay
Hi Jay
If you could share the threat model you are trying to protect against and where your server is running, I could possibly provide some more nuanced opinion. But in the meantime...
AFAIK Syncthing itself can not cope with encrypted data (it's encrypts the traffic between Syncthing nodes/clients - but not on the disk). So that means to have your files encrypted on your Syncthing server, the encryption needs to be transparent to Syncthing (i.e. the files need to be unencrypted when Syncthing has access to them). There are 2 options that I can think of OTTOMH:
Encrypted disk/volume (e.g. using LUKS):
Under this model, your would have an encrypted volume that is mounted to the Syncthing data storage file location. Many other distros allow you to configure this on install, but unfortunately, TurnKey doesn't. However, it can be done after the fact. Generally how that is managed, is that the encrypted volume is mounted at boot time. This requires the user to input the password (to decrypt the volume) at boot time. So user interaction via the console is required at boot time. Thus making it unsuitable for anything but a local server where you can access the console at boot time.
Encrypted directory
A variation of the above model would be to not auto mount the encrypted volume at boot time, but at start of the syncthing service. So whilst the server itself could reboot without interaction, the Syncthing service couldn't be restarted without manual intervention. AFAIK mounting LUKS encrypted volumes requires root privileges.
Having said that, it could be argued that if doing it outside boot, an easier way to go would be to use EncFS (or similar). As opposed to LUKS, EncFS can be used by a non-root user to mount an encrypted directory. But it still needs either a password, or a keypair to decrypt the data.
"Proper way"
Really, the "proper way" for this to be done would be if Syncthing always stored the data encrypted (and decrypted it client side; on the fly). That way the data on the server would always be encrypted, without ever any need for user intervention on the server. It's worth noting that there is a related Syncthing GH issue, with associated discussion in a Syncthing forum thread.
Round up
The first 2 are not directly related to Syncthing at all and are relatively generic Linux things. If you keep in mind that TurnKey is Debian under the hood (v15.x = Debian 9/Stretch) you should find plenty of info for how to implement either of those via google. If you choose to go one of those ways, then it'd be great if you could document as you go and share with others as I'm sure it would be useful! :)
Re the last one, whilst that's beyond the scope of a "normal" TurnKey user, if you wish to investigate that further and/or share your use case with other Syncthing users, then I'm sure that you'll find more discussion online. FWIW I found the related Syncthing issue and Syncthing forum thread via a google for "syncthing data encryption" - there are plenty of other hits.
So I hope that helps at least a bit. As I noted in my opening paragraph, if you wish to share the threat model you are trying to protect against and the circumstance you are delaing with, perhaps I can add more ideas?
thread model
The threat model is the Syncthing server is running remotely on a physical server or remote vm environment but want the data to be inaccessable in the event that the physical server/hard drive is stolen.
From what you provided so far regarding encrypted storage, there is no way to securely decrypt the volume at boot time in the event that the server restart and a manual input of password is required. I'm thinking of a bitlocker scenario where the decryption and encryption is transparent.
I get the pre-encryption of data prior to syncthing the data to the remote server but I would like to avoid it as more set-up is required to each syncthing clients.
What if the Syncthing server is installed in a VM environment?
AFAIK bitlocker depends on TPM hardware module
Any encryption (including bitlocker) requires a private key and/or a password. There isn't really any way around that... So as per most things security, any compromise towards ease of use, is generally a compromise on security.
How bitlocker makes that a bit more "user friendly" (and avoids the need for the user to enter a password or provide a key at boot) is that it stores the private key in a TPM hardware module (which most modern hardware is equipped with). Essentially it is a separate chip on the motherboard which stores private keys and under specific predefined circumstance (e.g. "secure boot") the key on the local machine is used to decrypt the encrypted filesystem(s). AFAIK if you have access to a TPM module and have "secure boot" enabled, you can set up the same "transparent" decryption mechanism for Linux with LUKS encryption.
FWIW that's also how finger-print readers work too; finger prints are not deterministic (they are probabilistic, unlike a password or key file) so to work around that, a key is stored on the TPM and the fingerprint "unlocks" the key.
For bitlocker to be secure, it also requires "secure boot" UEFI (so you can't hack on the bootloader). It also should be noted that there is PoC code of how to "extract" the keys from TPM, so whilst it's user friendly, as noted above, that's a trade off on security. If someone has physical access and enough time, knowledge and/or incentive to hack your machine; game over...
Short of using some sort of virtualised TPM (which would either provide it via software, or passthrough from the physical host), I can't really think of a way that you'd be able to secure an encrypted filesystem (bitlocker included) on a remote VM. And doing that would just change the nature of the security (if an attacker has physical access to the host, it could still be compromised). , without . Anything that works around the need to log in and provide a key or password to decrypt the files/filesystem, would be something that an attacker could also use (or reverse engineer) if they have access to the host (if VM) and/or hardware.
So like I say, the way to do this "properly" would be if Syncthing stored the data encrypted. Then you could have a "dumb relay" server which only served/synced the encrypted files and decryption happened on the client end (where a password and/or key file would be required to decrypt).
Add new comment