Rsync Encryption

[Kristeen Cheek]

Irun a small modest CentOS server at my house for misc backups, etc. My friend on the other side of town also runs a small modest server at his house for similar purposes. We have been toying with the idea of using eachothers servers to do remote/offsite backups.

Basically, we'd each buy an external hdd to store at eachothers homes, hooked up to eachothers servers. Then, we'd each setup scheduled rsync's to push the appropriate data from one server to the external hdd on the other server. Pretty straightforward for the most part.

However, one thing that is important (at least for me) is data encrpytion. I want to store my data on the external hdd on my friends server. But I don't want my friend (or anyone who accesses my friend's server) to be able to read whats on the external hdd.

WarningThere are some security concerns regarding encfs raised by this security review. Cryfs or ecryptfs should be considered instead## sync local unencrypted data to remote encrypted backups via rsync ..

Here is my backup script based on Thor's answer (still valid several years later!). It adds copying of file .encfs6.xml as needed for later decryption (not needed on 2011?), creation of temporary folder for encrypted mount and reading of encryption password from file (for automated scripting):

In my case, I am setting up a daily backup of my laptop and small servers to a external USB drive connected locally. I want to encrypt the backup just in case the drive disappears one day, together with some sensitive data.

A solution like the one you describe above requires sending your encryption key to your friend's machine. If we consider your friend an "untrusted site" you've just blown your security (he can capture the key and read your data).

If you want to be sure your friend can't read your backups you must encrypt the files before you send them (e.g. make a tarball, encrypt it with gpg or similar, then rsync it over), and never give him the key (or enough plaintext to reverse-engineer the key).

Note that doing this negates the delta benefits (bandwidth savings) of using rsync: The encrypted file will change substantially each time you make a backup, so you'll probably be copying the whole thing every time.

I understand that a secure connection (i.e. ssh) is needed to authorize a connection to the remote server. But after that is authorized can the data be transmitted without encryption and compression as well?

I am transferring files in the local network and could do without the overhead of compression and encryption, or even the attempt to compress then if they are suitable. Compression may be fine if it speeds things up, but encryption is not. I know of alternatives like FTP, NFS and Samba are available, but I prefer rsync, as the channel is closed once the transfer is complete

Rsync isn't the fastest thing in the world, but for long links I prefer to use it over HPN SSH. This is normal OpenSSH, but with some patches that offer a few benefits. Relevant to what you want, it allows the "none" encryption option for the transfer.

I find it especially valuable at a company where we have WAN accelerators. I can't change their behavior, but because they try to do their own compression/duplicate removal, it works much better if I can feed them an unencrypted data stream.

Use rsyncrypto to encrypt files from your plaintext directory to your encrypted directory, and decrypt files from your encrypted directory and your plaintext directory, using keys that you keep locally.

In that case, you'll want to use the --name-encrypt=map option.That makes each encrypted file name is a random string of characters,and by default all mangled file names are stored in a single directory.The true file names and folder names are stored in the (encrypted) file named "filemap".

In recent years, Rclone has been developed. Its motto is "rsync for cloud storage" but beyond things like S3/Azure/Google/etc. cloud storage providers, it also supports syncing between local and SSH/SFTP targets.

Any "remote" you configure, you can also add a crypt wrapper around it. This acts as the original remote, but the contents of all your files (and optionally the file names themselves) get encrypted on the client side. The algorithm is documented, and its been a generally seamless process in my experience so far.

then use encfs to create a folder on it, linking your local drive folder to that remote folder. Note that the idle=30 disconnects the link if idle for more than 30 minutes. A good security measure IMHO.

Modern enterprise data centers are a complex mix of different technologies geared towards accomplishing business goals. Some of these technologies are pricy, big-name business solutions, but some are simple tools and utilities, facilitating processes. Linux sysadmins have been using rsync (remote synchronization) to move and mirror files for two decades, though versions of it now run on nearly every platform. Its lightweight build, small footprint, and usability make it a good choice for simple file copy operations. But this same asset is also a liability for many utilities: designed purely for functionality, they may not automatically account for potential risks to enterprise data. To successfully use rsync in the enterprise means protecting the data being transferred through it from accidental exposure.

One of the great advantages of rsync over other similar utilities is that it is able to easily transfer only the delta between systems. For example, if you set up rsync on a file server and connect a backup server as the mirror, the initial sync will move every file in the specified path. After that first sync, rsync will only move the changes, keeping the mirror identical to the primary server and minimizing network traffic. This type of file copy procedure is extremely common for most organizations, and without process guidelines, techniques and utilities vary widely among individual admins.

Despite its compact build, rsync does have security options that can protect the data it transfers. But like many pared-down tools, it does not invoke them by default, and the burden therefore rests on the person setting it up to configure it securely.

Data exposure has become a prominent business risk, and organizations that have experienced such a leak have also had to endure the associated financial and reputational damage. Rsync can be a powerful utility for simple file mirroring or transfer, but the level of care taken to configure it should be commensurate to the sensitivity of the data being transmitted.

Other global options exist, such as specifying the IP address to listen on, advanced socket options, and the ability to send a message of the day (MOTD), essentially a service banner, to users of the rsync service.

The most basic way to protect rsync modules from accidental exposure is to restrict which external machines can talk to it. By using the hosts allow and hosts deny directives, rsync can build a policy of least privilege by permitting only those clients necessary for business goals. With hosts allow, all unspecified source IPs will be disallowed automatically. This drastically narrows the attack surface of the rsync server and should always be established for even somewhat sensitive information. Hosts deny can block specific IP addresses, offering further access granularity to an allowed IP range.

When used in conjunction, the hosts allow directive is read first. If the client is allowed there, the hosts deny directive is then read. If a client matches there, they are denied access-- even if specified in the allow list.

IP and hostname restrictions narrow the attack surface by device, but any user on those allowed devices will be able to access the rsync module. The auth users directive narrows the attack surface by user, limiting access to only specified accounts, regardless of device. When auth users is enabled and given a list of usernames, only those users can connect to the rsync daemon.

If the auth users directive is absent, the default is to allow all users. And just like that, if your rsync server is available from the internet, you have a data leak. The most important takeaway to remember when building a secure rsync setup is that by default, anyone can access the path. Failure to correctly configure the auth users and hosts allow/deny settings turns whatever data is being synchronized into a public facing webpage. Anybody who finds the rsync server can pull the contents anonymously, without needing a password. Incidentally, finding internet exposed rsync hosts is trivial when the default port is being used. It is always recommended to limit access to rsync by user and device. Every layer reduces the risk of data exposure.

That said, most enterprise class technology would never store passwords unencrypted in a text file. This is a qualitative difference between tools geared towards maximum functionality and platforms designed with business risks in mind. However, with the proper care, even rsync can be fairly well protected against accidental and malicious access.

Encryption is one area where rsync and rsyncd differ greatly. When rsync is used on the command line, a separate protocol, usually SSH, must be specified for the transfer. However, the rsync daemon does not encrypt traffic. This means that an rsync process can potentially be sniffed in transit by a third party, granting them access to whatever information is being transferred. Therefore, rsync operations happening openly across the internet are extremely vulnerable to data exposure.

All rsyncd traffic should occur within a protected intranet or inside of an encrypted tunnel or VPN. At the enterprise level, there is no excuse for passing unencrypted data across the net. Alternative simple file copy solutions such as SCP and SFTP also support built-in encryption.

If rsync is open to the net, anyone who scans the server will find an open port. Changing the port from 873 in the rsyncd.conf file can help obfuscate this, but ultimately if the rsync port is exposed, someone will eventually find it and see what they can do. Like any enterprise service, access to the rsync port should be limited in scope. Firewall ACLs can block unauthorized source IPs, much like the hosts allow and hosts deny directives in rsync itself.

3a8082e126