Ransomware protection without special backend support

Getting Help
1

Hi all!

I am using a onedrive rclone remote included in a basic O365 subscription for my backups. As you know, this does not offer any option of immutability or append-only.

As I was worried about ransomware or an attacker also killing my cloud backups, and the other threads I found were more about special backends supporting object locks etc, I would like to create a topic to to discuss this use case, share my simple strategy, and would be happy to read about your opinions, strategies, comments, improvements etc.

Here is what I am currently doing, and it works really great:

  • The rclone.conf on my NAS is encrypted with openssl AES256.
  • I have a USB key lying next to the NAS, not connected. This key contains the secret to decode the rclone.conf file.
  • If the system detects the connection of the USB key, rclone.conf is decrypted to ramdisk, and the cloud backup process is started. Stick can be disconnected immediately after start.
  • After the backup, the ramdisk is destroyed.

My data does not change too much (mostly old photos of the kids etc.), and my NAS is mirrored, so my cloud backup is really just a ransomware insurance, and does not need to run that often. So my workflow is that every few weeks, I check a few random files to see if they are OK, and once that is done I briefly insert the stick in the NAS, just long enough to start the backup and get a notification on my phone confirming that it started.

This way, for an attacker who has access to the NAS, the rclone config is useless because it is encrypted. Regarding the USB stick, it contains a key that is also useless without the rclone config on the system, so someone stealing the stick (evil maid attack) can’t do anything with that. Oh and the NAS storage itself is encrypted too and requires me to enter a password on the initial mount after reboot, so if someone steals both NAS+Key - also useless.

Here is the outline of the concept:

# create ramdisk
/sbin/mount -t tmpfs -o size=100k tmpfs /mnt/rclone-config.decrypted

# decrypt rclone.conf
cat /path/to/encrypted/rclone.conf | openssl aes-256-cbc -d -pbkdf2 -a -pass file:/path/to/usb/stick/passfile > /mnt/rclone-config.decrypted/rclone.conf
export RCLONE_CONFIG=/mnt/rclone-config.decrypted/rclone.conf

# do backup operation here

# destroy ramdisk
/sbin/umount /mnt/user/appdata/rclone-config.decrypted

Possible improvements:

  • Ensuring key gets overwritten in RAM before the ramdisk is destroyed
  • maybe you could even destroy the ramdisk as soon as restic spawns rclone?
  • use mktemp to enable multiple instances running at the same time (I dont need this)

Another (maybe easier and even more secure) option would be to use the rclone built-in encryption, and read+set RCLONE_CONFIG_PASS before the backup, something like:

export RCLONE_CONFIG_PASS=$(cat /path/to/usb/key)

…but I only found out about rclone config encryption after I wrote my solution… :see_no_evil: :joy:

Thoughts?

1 Like
2

The first thing ransomware does is delete your backups.
They don’t care if it’s encrypted or not, they just delete/wipe the storage media they’re on.

What in your steps above stop an attacker from just wiping the data on your OneDrive? Not decrypting it, just deleting it outright?

Certainly it seems very secure against decryption but I (probably naively) don’t understand how Access to the OneDrive is being extremely tightly controlled against a “Delete all Data on this OneDrive” API call or two.

Is all and any access to OneDrive data only accessible via the rclone config?

1 Like
3

What I have described above is not about encrypting the backup (this is done by restic anyway), it’s about encrypting the rclone config file, which holds your access tokens to your Onedrive. Think of it as the key that unlocks the Onedrive-Door.

Without this key, you cannot delete anything, as you cannot access the drive.

Ah yes, this is a good and very important point! You should not have the onedrive accesible in your day-to-day business by any other means, or have it mounted etc.

Hope this makes sense!

1 Like
4

Whether an encrypted rclone config that is only accessible at specific points in time prevents an attacker from deleting your data depends on a central assumption on the attacker behavior.

  • Lazy Attacker A: manages to hack the NAS, fails to decrypt the rclone config and just proceeds to delete everything on the NAS. In this case your data on Onedrive is safe.
  • Patient Attacker B: hacks the NAS, takes the time to analyze your custom scripts and waits until you start the next backup. At that point the attacker has a copy of the decrypted rclone configuration and also the backup encryption key. Without further safeguards at the backend, this allows the attacker to make arbitrary modifications or simply delete the backup.

The only possible defense against Attacker B is to ensure that the NAS itself has no permission to delete the backup (aka. append-only). That fundamentally depends on support for that feature by the backend.

2 Likes
5

@MichaelEischer Yes, you are right - I would also consider a backend which restricts the client to be the “gold standard”.

Unfortunately I do not have one available at this point, so trying to do the next best thing. And you are right, if someone achieves root, remains undetected until the next backup, and has the time and dedication to analyze my setup manually, it would be game over.

1 Like
6

I guess the main question for which you have to find an answer is whether there’s an incentive for someone using ransomware to behave like Attacker B in your case or not. If an attacker could only expect a small payout, then it’s not economical to spend a lot of effort… That is, targeted attacks are more likely towards companies than on the average individual (exceptions notwithstanding).

1 Like
7

True for sure. Honestly I think I have already left the realm of reasonability - I am doing this mostly because I think the tinkering is fun and I want to learn something, not because I’m paranoid (I swear!!! :grin:)

That being said, you have nevertheless inspired me to evolve my approach, I think I will now move to something like:

  • Create USB-stick containing an encrypted rclone.conf and a shell script (let’s call it do.sh) to decrypt to RAM and perform the backup, containing all the restic calls needed
  • USB Stick with correct UUID detected by system → mount
  • Check hash of the shell script on stick, if it matches → execute the script and pass decryption key as argument

This way, there would be no evidence of this specific backup destination on the system, just some strange script doing some stuff with USB (even restic and rclone could live only on the stick). Still not perfect against attacker B, but would increase chances of backup staying undetected, costs 10 minutes of scripting, and probably the best I can do without the proper backend. Let me know what you think :slight_smile:

1 Like
8

I guess both scenarios still apply. But that setup is probably unusual enough that nobody will notice what’s going on, unless they’re looking at the NAS just at the moment when the backup run.

Just make sure that your backup still works properly with all that complicated setup :slight_smile: .

2 Likes
9

Would it be normal for a hacker to be so dedicated to harming an individual user? What sense would it have?

I just read Michael’s response and I agree.

1 Like
10

Depends on the value of your data and the hacker. As for my motivation, I have already responded above :slight_smile:

1 Like
11

Your solution looks like “security by obscurity”. It is not secure at all really but complicated setup creates false illusion that it is better protected.

You hope that your adversary won’t be motivated enough. But instead you should rely on rock solid design - then even if your setup is publicly available it does not make easier for attacker to damage your “high value” backup.

You won’t achieve much without proper backend support. For cloud the answer is S3 with compliance level data lock. Such solution can be built around restic and S3 storage like iDrive e2 nowadays costs $30 per TB per year - no need for AWS enterprise features and pricing.

Data protected with S3 compliance lock is effectively indestructible (during lock period duration). Only way to delete such backup is terminate S3 account contract - and it is much easier to secure completely. Anything else - leaked credentials, full access to your computer or some novel backdoors do not give any advantage to a bad actor.

12

Not at all. The method described allows for cloud backups to have the same level of protection as a backup stored on a local, physically disconnected external USB device (which is accepted as one of the best practices in ransomware protection), and even better where the “availability” part of the security triad is concerned. It’s a definite improvement against the backup mechanism, the rclone config, and the access tokens being available in the live system.

In pricinple that’s true in an ideal world, in practice there are often limitations which call for the best possible method given the circumstances, and I think it’s a good challenge to try and achieve the best level of hardening in the given scenario.

As I wrote in my initial post, this is specifically out of scope of this thread. This discussion is about “dumb” backends which do not offer immutable objects, append-only mode etc.

1 Like
13

Right! They are very good reasons.

2 Likes
14

Backup your onedrive using a system thats unreachable to your local setup. A scheduled task on an ECS cluster at AWS running rclone can backup your repo to another storage. Just dont stre access info for this cloud back of the backup anywhere near your daily system.

1 Like