I learned that modern ransomware tactics are starting to target backup drives in addition to normal drives. This has me very nervous. In addition to the usual backup work that I do for myself and my parents, I host a backup server in the basement of my home that receives backups from my office through a VPN connection to the offsite location. I am currently updating our backup strategy to only connect to the VPN when the backups aren’t occurring, but now I am nervous about all the other potential pathways.
For example, the basement server is connected via a mapped drive to my main personal computer so I can check the status of backups and make sure everything looks right. I assume a ransomware attack would be able to transfer from my personal computer to the server via this connection? Also, I share files back and forth with my parents via resilio sync, so I assume an attack to transfer from my parents’ machine to mine, then to the server?
I started to just delete the mapped drive connection and only connect manually when needed, but I noticed that the server shows up in my network connections, even though I have the server’s network discovery turned off. I assume the attack could still bridge the gap to the server even if the drive isn’t mapped, since it can see it as part of the network?
I realize that the safest option is to backup to an external hard drive and then physically disconnect that drive, but the more automated I can make things (and still be safe), the easier it will be to carry out.
It’s something to think about. Ransomware can try to mess with data on your mapped drives. It can also scan your local network for writable shares, so unmapping the drive isn’t foolproof protection.
Some other ideas:
Require different credentials to write to the backup data. Ransomware will run under the victim’s user context, so it’s a risk if your backup data is writable by the logged in user. You could change it so the current user has read-only access (or no access), but grant write access to a special backup account. The backup account user/pw is stored in the job configuration within Duplicati.
Use a different protocol. SMB is convenient but Ransomware uses it to scan and encrypt network resources. If you use S3, SFTP, WebDAV, etc., it is highly unlikely that ransomware will try to utilize such protocols. Combine that with requiring a special backup user/pw and you should be well-protected.
If your backup target supports filesystem snapshots, enabling it may help protect you if your backup data gets fouled up. You can roll back to a previous snapshot.
I’ve been thinking about this problem. I’ve concluded that I can prevent backup file loss by ransomware by blocking all inbound network access to the backup server except for a custom port number running a hardened WebDav server (WsgiDav written in python is my current favorite). I have further modified that WebDav server to never allow file rewrites nor file deletes. Instead, the original copy of targeted files are shunted to other directories which are not visible to the WebDav file directory. It is a kind of copy on write protection.
I am experimenting with this architecture because everything runs in user mode and I have the source code.
I have noticed that sometimes Duplicati does not complete its backup. I have not conclude if Duplicati or the WebDav server is causing the troubles.