3 ms·
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 lo
by 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 agoThis 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.