Given the recent topic on the government's forming of a taskforce to manage investigations into ransomware attacks - I wonder how much of a big deal ransomware would be in a world where linux used ZFS by default. I have read reports of users running ZFS who were easily able to shrug off a ransomware attack but I don't know how that would play out in general. Could widespread adoption of ZFS significantly blunt ransomware attacks?
> The whole point is that if malware gets root access
Strictly true, in that if it does get root access, and is aware of zfs snapshots and deletes them, then yes. Nothing you can do.
More typically, the malware runs as the user id and has no awareness of zfs, so it just overwrites files the user owns. Which can be trivially undone with snapshots.
As with everything related to security there is no absolute, but every layer helps.
Even if the backup system isn't hacked, you can hack the original system in such a way that the pulled snapshots look like they work, but in fact did not work (ex: hack the rsync data requests to be encrypted with the ransomware key).
You gotta stop them from having root access to begin with. Hard in this day of zero-days, but a lot of these ransomware attacks don't seem very hard to pull off these days...
Well, if you take snapshots every hour then you can always roll back to the latest snapshot if you need to. It would be a nice defence against the traditional "encrypt all writable files" attacks. As long as the root user isn't compromised, using ZFS (or other filesystems with snapshots) should prevent a lot of problems, and not just ones related to ransom-ware attacks.
In the scenario where a client computer with access to files via a network share becomes infected and encrypts files, but the server is snapshotting the file system that those files are stored on.
Also, OpenZFS can export ZVOLs over iSCSI so you can have formatted block storage for other devices that can be rolled back by snapshot on the OpenZFS.
In a virtualized environment all of the VMs' storage could be protected with snapshots.
There's a number of reasons I feel this assumption is valid in most cases:
1) Unless it's a targeted attack it's highly unlikely that a ransomware strain will be designed to target a specific filesystem. Snapshot deletion requires filesystem specific APIs, whereas reading/writing files is just standard libc fare. You would need to maintain different strains of a virus to target an organization running Btrfs vs ZFS vs ReFS, for example. - If the attacker has deep knowledge of your storage stack, and has gained privileged access to it, you've already lost: go to step 4.
2) Separation of privileges. Deleting a snapshot is a privileged command. A ransomware infection that doesn't successfully elevate privileges might be able to encrypt my home directory, which would suck, but it wouldn't have permissions to delete snapshots of my home directory.
3) Virtualization / network storage: snapshots are transparent to virtual guests, a virus inside a guest can't delete snapshots if it's not aware they exist. With network shares and ZFS: you can choose whether or not you want to expose snapshots. If you do expose them: don't grant network clients privileges to delete them.
4) Replication: with any ransomware infection the only real defense is off-site backups. Snapshots makes backups trivial. You can incrementally replicate and restore from them easily (e.g: zfs send/recv.) This alone makes using a CoW filesystem worthwhile in the defense against ransomware. Ransomware will have a hard time deleting snapshots on an air-gapped disk.
"Why would ransomware that can encrypt all your files not be able to delete your snapshots?"
If you keep your backups on a third party cloud storage provider that runs on ZFS then those snapshots are taken by their root, not yours.
You send your backups to this cloud storage provider and they take the snapshots on your behalf.
You have an unprivileged login and have the ability to read the snapshots, but not destroy them.
In this scenario, Mallory can destroy your data and gain access to all of your cloud credentials and destroy the primary dataset ... but cannot destroy the snapshots.
I'm sure there must be some cloud provider, somewhere that offers this ... right ?
Your service does so and does so well but I would go further and say that any service that does not is not suitable as a backup solution. No matter if the service runs tapes the customer can't decide to overwrite, snapshots they can’t remove or whatever solution they use, the customer should not be able to delete old versions prematurely.
If there was ever a use case for certain operations to require a privilege level higher than or separate from root, snapshot deletion is it. I’m generally a bit skeptical of such measures, but the purpose here is obvious.
I don't see how that is anything more than adding an additional hurdle that the attackers would overcome. If they can already jump through the hoops to get root access then what's to stop them from doing the same for this other theoretical access level?
The user may have granted root access to do something relatively normal and unrelated to ZFS. You probably only want one or two programs to ever be able to delete snapshots.
This is a permission which can be delegated to users on a per-dataset basis. See "zfs allow". It didn't used to work on Linux, but has been possible since Ubuntu 20.04.
Often ransomware runs with user or local admin access since all they want to do is encrypt your work files. Hopefully deleting snapshots would requite a different level of access.
Any snapshot-capable storage setup should be a decent remedy against ransomware, just roll back to the latest snapshot (unless of course the ransomware manages to kill your snapshots), unless there's another specific ZFS functionality you're hinting at?
ZFS, btrfs, even LVM does snapshots, and it seems silly to use anything else for critical data/configuration.
