Hacker News Reader

>I've recently learned that OpenZFS has effective counter-measures for ransomware and data corruption in general.

Sort of. The data corruption part yes, that's a core transparent part of the filesystem as it should be. But for ransomware ZFS only provides helpful tools for doing so, it's not designed around that specifically (though it could provide the foundation for something that was). Very low cost atomic snapshots and ease of replication definitely can help if they're used, particularly combined with ZFS permission delegation system. You can set a user to have snapshotting permissions separately from permission to destroy snapshots, as well as rollbacks, sends, etc. Of course that won't help if ransomware gets root (unless in turn the storage has hardware separation, loaded over a NAS say), but it's still quite handy.

It would be interesting actually if ZFS had some limited active content monitoring capabilities, such as detecting changes in entropy or a sudden massive spike in snapshot delta size (indicating everything in the file system had been touched). At any rate though note the "a carefully planned" bit there, ZFS is a fantastic foundation for a better data protection system and makes it easier to do well. But it's not install-and-forget by itself either right now, though someone could build something on top if they wanted to (or maybe already has? it has been a while since I surveyed ZnapZend and the like).

I suppose that snapshotting will cause old versions of the data to be thrown away, once the old versions start taking up too much disk space. Then I suppose the ransomware can take advantage of this and simply perform so many writes that the unencrypted versions of the data are thrown away. And isn't this what happens anyway when a disk is nearly full and you start encrypting its contents?

That's not at all how ZFS snapshotting works. ZFS snapshots are manually managed. And totally awesome.

If there are no automatic snapshots by default then the snapshots are just like backups - i.e. an active measure the user has to take? Then it doesn't really protect against ransomware (Assume that we are talking about users who don't have backup - they wouldn't have zfs snapshot either?)

ZFS snapshots can be automated. I have ZFS periodic snapshots enabled on my FreeNAS system, where I can select when snapshots will occur (frequency and time) as well as how long the snapshots will be kept.

Backups can also be automated. I think that parent's point is that, like backup, if it isn't the default then users are probably not doing it. It is my experience that most people, even people who should know better like you or me, think of data loss risks as theoretical until they've experienced it first hand once or twice.

For better or worse, ZFS isn't really targeted at "average users" as of right now.

See also: There is no stable ZFS implementation for Windows as of right now, and the implementation for macOS (while surprisingly painless in general) requires at least some command line use to set up.

If anyone actually develops a ZFS implementation designed for average users, I would agree that it should include automated backups by default.

It would be weird for a system to throw away its backups automatically at arbitrary times.

Apple's Time Machine does.

What would you have the software do when it runs out of space? IMO, not making new backups would be worse than deleting old ones.

It's actually not allowing you to write new data at all. So it prevents the user from assuming there is more space to store his data, as there is not sufficient space with his indicated/configured data retention wishes.

Typically these systems are set up to automatically snapshot on a periodic basis (say nightly) and automatically pruned after another period (say monthly) - if there was massive activity due to ransomware causing a full disk in most such systems it'd have to be manually investigated, it wouldn't just decide to delete snapshots to free space.

It certainly should help against ransomware in that an admin who was investigating an unexpectedly full disk, who's hopefully aware of such things, would probably notice that all the files on the drive were no longer readable and all had recent modification timestamps. And that's if a user doesn't happen to notice it first and report issues with their files to IT.

As long as those snapshots last more than a few days as to provide sufficient time to catch and investigate the issue, ransomware damage is usually revertable much faster than backups with simple snapshots.

> so many writes that the unencrypted versions of the data are thrown away

I don't know about this specific system, but typical behaviour of NILFS (a continuously shapshotting log file system) is to report the filesystem as full, requiring manual intervention or waiting until the data ages-out and gets garbage collected.

Yes, or just taking decent backups of your data.

Backups are active measure, that you have to do on purpose. Changelog fs just works

They're pretty automatic on any system I get my grubby hands on. The added advantage is that backups done properly will protect you against the machine going up in smoke, where CoW won't.

well, if you automate backups too much, the Ransonware would eventually have reached your backup storage and screwed things there too...

That's why proper backups are done in a pull-configuration and not the easy way of push. I.e., the backup system has access to the production system, and grabs the data itself. The production system can at worst serve bad data to the backup system, against which the protections are not that hard. Basically just a protocol client that can handle malicious servers, like a HTTP(S) server/client or such.

Many (most?) backup systems seem to mount the backup filesystem locally, allowing ransomware to access and encrypt the backup files too. For example, not too long ago I set up a networked drive that can be accessed only with a password over Apple File Protocol. I gave that password ONLY to Time Machine hoping it might do something smart and mount the drive in a way that only it could access. Of course it mounts it under /Volumes, allowing it to be accessed via Terminal without having to enter the password...

I guess because of this you see "protect yourself from ransomware attack" guides recommending keeping your backup drive/filesystem attached for as short a period as possible. But even then you're left hoping that the ransomware doesn't encrypt your backups first - perhaps because it's smart enough to - or that it doesn't get too many of them before you notice the infection.

I wish all backup software would avoid making the remote filesystem available system-wide and raise the bar by requiring ransomware to know how to extract access to the remote filesystem from the particular backup software you're using before it could encrypt your backups. Unfortunately, as far as I could tell last time I looked this issue seems to be ignored by backup software vendors.

This is a completely valid point. Why would you give access to the backup storage area to the production system?

Where I have implemented it, the only access the production system has to the backup system is to connect to an ssh server with a private key, and shove a tar down the pipe, which the backup system then squirrels away somewhere safe. This is a push configuration, but it's a safe one - the backup system doesn't have access to the production system either, and the production system cannot overwrite/delete any data on the backup system.

the malware can't delete your snapshots?

Export zvols from a central fileserver via iscsi, and install the exposed operating system on it. Snap the zvols on the fileserver. Unless your fileserver is compromised, there's no way the ransomeware can persist in your network.

Zvols on zfs exhibit poor disk utilisation unless your block size, stripe size and file size line up just right. They work, but I've found major space savings sticking with zfs directly, if possible.

In my cases, disk is cheap and I don't particularly care about utilization. The ability to wipe away errors whenever the need arises is priceless.