3 ms·

Yes, or just taking decent backups of your data.

by mnw21cam 8y ago

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.

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.