5 ms·

"The only thing I know that can thwart attacks like this is Qubes, or a well setup SELinux.. But SELinux then impedes usage. (down the rabbit hole we go)." Or

"The only thing I know that can thwart attacks like this is Qubes, or a well setup SELinux.. But SELinux then impedes usage. (down the rabbit hole we go)." Or the easier method. rdiff-bacukp + cron job. Or Duplicity. Or Tarsnap. Or CrashPlan. Or... That is to say backups with multiple stored versions, to another system where the (infected) client does not have direct write access. Ransomware can infect my home directory if it wants to. A fire can burn down my house. Zaphod Beeblebrox can cause my hard drive to experience a spontaneous existence failure. But I've got off-site automatic backups, so I'll never pay the ransom. (I will pay more over time for the off-site storage, but given that I'd pay for that anyway to guard against natural disasters / disk failure / etc it's not really an added cost).

coldtea 10y ago
>But I've got off-site automatic backups, so I'll never pay the ransom. That's irrelevant though if they can also get all your credentials, stuff in the Keychain et al -- as they apparently did with the Handbreak malware.
- ihattendorf 10y ago
  Easy way I've found that works for me: - Backup files are encrypted with gpg. - Pull from local backup server with a backup account that only has read-only access to the directories you need to backup. - Push to remote backup server with versioning (I'm using rclone with s3, if you need to backup large amounts this could potentially get too expensive). You can restrict the s3 credentials so that the user pushing from your server isn't able to permanently delete any files. There are plenty of other options out there, the key takeaway is a staging server for offsite backups and the principal of least privilege.
- cpach 10y ago
  That’s why offline backups are useful as a complement. For example, Arq can do backups to an external hard drive. Tarsnap can be configured so that a special key is needed to delete backups.
AgentME 10y ago
Backups don't stop someone from copying your data and credentials.

coldtea 10y ago

>But I've got off-site automatic backups, so I'll never pay the ransom. That's irrelevant though if they can also get all your credentials, stuff in the Keychain et al -- as they apparently did with the Handbreak malware.

ihattendorf 10y ago
Easy way I've found that works for me: - Backup files are encrypted with gpg. - Pull from local backup server with a backup account that only has read-only access to the directories you need to backup. - Push to remote backup server with versioning (I'm using rclone with s3, if you need to backup large amounts this could potentially get too expensive). You can restrict the s3 credentials so that the user pushing from your server isn't able to permanently delete any files. There are plenty of other options out there, the key takeaway is a staging server for offsite backups and the principal of least privilege.
cpach 10y ago
That’s why offline backups are useful as a complement. For example, Arq can do backups to an external hard drive. Tarsnap can be configured so that a special key is needed to delete backups.

AgentME 10y ago

Backups don't stop someone from copying your data and credentials.