5 ms·

I've recently learned that OpenZFS has effective counter-measures for ransomware and data corruption in general. Quote from here [0]: > As a copy-on-write file

by dmos62 8y ago

I've recently learned that OpenZFS has effective counter-measures for ransomware and data corruption in general. Quote from here [0]: > As a copy-on-write file system, OpenZFS provides efficient and consistent snapshots of your data at any given point in time. Each snapshot only includes the precise delta of changes between any two points in time and can be cloned to provide writable copies of any previous state without losing the original copy. Snapshots also provide the basis of OpenZFS replication or backing up of your data to local and remote systems. Because an OpenZFS snapshot takes place at the block level of the file system, it is immune to any file-level encryption by ransomware that occurs over it. A carefully-planned snapshot, replication, retention, and restoration strategy can provide the low-level isolation you need to enable your storage infrastructure to quickly recover from ransomware attacks. [0] https://www.ixsystems.com/blog/combating-ransomware/ https://www.ixsystems.com/blog/combating-ransomware/

mnw21cam 8y ago
Yes, or just taking decent backups of your data.
- NullPrefix 8y ago
  Backups are active measure, that you have to do on purpose. Changelog fs just works
  - mnw21cam 8y ago
    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.
    - gcb0 8y ago
      well, if you automate backups too much, the Ransonware would eventually have reached your backup storage and screwed things there too...
      - namibj 8y ago
        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.
- jwatt 8y ago
  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.
  - mnw21cam 8y ago
    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.
amelius 8y ago
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?
- doublerebel 8y ago
  That's not at all how ZFS snapshotting works. ZFS snapshots are manually managed. And totally awesome.
  - alkonaut 8y ago
    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?)
    - ncheek 8y ago
      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.
      - AnIdiotOnTheNet 8y ago
        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.
        Wowfunhappy 8y ago
gruez 8y ago
the malware can't delete your snapshots?
- kchoudhu 8y ago
  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.
  - barrkel 8y ago
    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.
    - kchoudhu 8y ago
      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.
xoa 8y ago
>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).

by dmos62 8y ago

mnw21cam 8y ago

Yes, or just taking decent backups of your data.

NullPrefix 8y ago
Backups are active measure, that you have to do on purpose. Changelog fs just works
- mnw21cam 8y ago
  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.
  - gcb0 8y ago
    well, if you automate backups too much, the Ransonware would eventually have reached your backup storage and screwed things there too...
    - namibj 8y ago
      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.
jwatt 8y ago
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.
- mnw21cam 8y ago
  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.

amelius 8y ago

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?

doublerebel 8y ago
That's not at all how ZFS snapshotting works. ZFS snapshots are manually managed. And totally awesome.
- alkonaut 8y ago
  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?)
  - ncheek 8y ago
    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.
    - AnIdiotOnTheNet 8y ago
      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.
      - Wowfunhappy 8y ago

gruez 8y ago

the malware can't delete your snapshots?

kchoudhu 8y ago
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.
- barrkel 8y ago
  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.
  - kchoudhu 8y ago
    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.

xoa 8y ago

>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).