site/content/docs/Advanced/Ransomware Protection/_index.md
Some cloud storage providers provide capabilities targeted at protecting against ransomware attacks. Kopia can be configured to take advantage of those capabilities to provide additional protection for your data.
For the context of Kopia protection, ransomware refers to viruses, trojans or other malware that infects a system, and blocks user access to it (often by overwriting files with an encrypted version of themselves), usually requiring to pay for the decryption key to restore access. Because ransomware often targets 'high-value' user data, and often overwrites files in place, an automated backup solution (for instance running Kopia on a nightly cron-job) can cause the overwritten files to be propagated to cloud storage. For the case just described, having multiple snapshots would appear to be sufficient to restore your data from the cloud, however ransomware attacks are getting more sophisticated. A ransomware application may look for your cloud provider access keys while examining your files and use that to permanently delete your snapshots on the cloud! We need to better protect our cloud storage to ensure our snapshots are safe.
Some cloud storage solutions provide the ability to generate restricted access keys. These keys can be configured to only allow access to specific data (a specific bucket or path within a bucket), as well as to restrict what capabilities that key has access to. The easiest solution is to generate a key without any delete permissions, and to configure Kopia to use that key. Now if a ransomware application finds your key, it can no longer permanently delete any data from the cloud! This might imply that now Kopia can no longer delete old snapshots as part of its maintenance cycle, but that is not the case. When Kopia deletes data from a compatible provider, it is replacing the data with a special file that has a hidden marker. This makes the file appear to be deleted, but it can still be accessed by using an older version of the file). Typically, the cloud provider offers 'Lifecycle-Management' to apply a true-deletion of hidden data after a certain period of time. Since this is an automated process executed by the cloud provider, no 'true delete' is ever executed by Kopia. As long as the hidden-to-delete time delay is long enough for you to notice the ransomware, you can still restore the old versions of your data. Enabling restricted keys does not require any changes in your Kopia workflow, since Kopia does not need to change its behavior at all. The cost of this is that data will remain on the cloud provider for extra time before being deleted, potentially incurring additional storage charges.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1480692207000",
"Effect": "Deny",
"Action": [
"s3:DeleteBucket",
"s3:DeleteBucketPolicy",
"s3:DeleteBucketWebsite",
"s3:DeleteObjectVersion"
],
"Resource": [
"arn:aws:s3:::*"
]
}
]
}
b2 create-key --bucket <bucket-name> <key-name> listBuckets,readBuckets,listFiles,readFiles,writeFiles,readBucketEncryption,readBucketReplications,readBucketRetentions,readFileRetentions,writeFileRetentions,readFileLegalHoldsSo far, we have secured your access such that even if a bad actor gets access to your Kopia configuration, they can't do irreparable harm to your cloud backup. However, what if they get access to your login credentials? Your login credentials provide the ability to delete your data and even your entire buckets for all the buckets in your account. But the cloud providers have protection from that too.
Multi-factor-authentication (MFA) is one option. With MFA enabled, an attacker would need access to your password as well as your security device to be able to manipulate your account. All major providers support MFA, and it is recommended to use it to secure your account. Note that it is important to eliminate and root/global access keys as well, since they can generally be used to execute nearly any task you can do when logged in (effectively bypassing MFA).
An additional layer of protection is `Object Locking' that can be enabled in AWS (and S3 compatible providers). An Object Lock is applied when a file is created (or on an existing file), and it provides a specific retention date. Until that retention date occurs, there is no way to delete the locked file. Even using your login credentials, the file is protected from deletion. It can still be overwritten with a new version or hidden such that it doesn't appear in a file list. But it will always be accessible until its retention date occurs. While Kopia supports applying Object Locks, there are some caveats:
b2 update bucket). Once a bucket has Object Lock enabled, it cannot be disabled.full-maintenance options. You must ensure that you run full maintenance at least as frequently as your Object Lock period to ensure Object Locks do not expire, otherwise the Retention date will pass, and your data will no longer be protected by an Object Locks.b2 update bucket to enable Object Locks on an existing bucketkopia repo create s3 --bucket <bucket name> --access-key=<access key> --secret-access-key=<secret access key> --retention-mode COMPLIANCE --retention-period <retention time>
retention-period can be specified in days (for instance 30d)kopia maintenance set --extend-object-locks true
full-interval must be at least 1 day shorter than the retention-period or Kopia will not allow you to enable Object Lock extension--point-in-time option (ex: --point-in-time=2021-11-29T01:10:00.000Z)
Ransomware can be very sophisticated software. It may run on your system for weeks, slowly encrypting data that is not frequently used, and only hitting actively used data last (to avoid detection for as long as possible). This means that you should ensure your data retention period is long enough that you will be able to recover your data. It also means that recovery may not be easy. You may have many snapshots after the ransomware has started modifying your system, and you may have made changes throughout that time such that there is no single snapshot that represents a good state of all your files. Restoration is likely to be a time-consuming task, and your best bet is to protect your system from these threats, so they don't occur in the first place. But if they do, Kopia can provide some additional security to protect your data.
Additionally note that ransomware could theoretically weaponize object-locks to cost you a lot of money. Because object-locks cannot be reduced or removed, sufficiently malicious ransomware could upload large amounts of data and set a very long object lock that would make it impossible to delete. It is strongly recommended to ensure you have appropriate quotas/limits on your buckets to limit potential storage costs.
At first glance, Lifecycle Management and retention-time may seem to serve similar purposes. However, if only using Lifecycle Management, an attacker could still log into your account and delete the entire bucket, or otherwise force-delete a file. Using 'Object Lock' with retention-time provides an additional guarantee that the only way for data to be lost before the retention-time expires would be to delete your account altogether. The S3 provider may allow enabling Object Lock without enabling Lifecycle Management. When retention-time is applied to a file, and that file is deleted, the S3 service will set a DELETE marker instead of actually deleting the file. If Lifecycle Management is not enabled, then files may remain in the repository with the DELETED tag indefinitely. Thus, it is recommended to enable Lifecycle Management whenever using a retention-time in Kopia to balance protective measures against escalating storage costs.
For simplicity, the recommendation is to use the same time period for Lifecycle Management and for retention-time, however, this is not a hard requirement. It is possible to set a very short Lifecycle Management period and a long retention-time (in which case files will be permanently deleted soon after the retention-time expires. Alternatively, the Lifecycle Management could be set to be significantly longer than the retention time. This would provide additional restore capabilities while allowing for manual cleanup of deleted files should it be necessary (with the understanding that once the retention-time expires, the ransomware protention is reduced). For simplicity, the recommendation is to use the same time period for Lifecycle Management and for retention-time.
Kopia supports ransomware protection for Azure in a similar manner to S3. The container must have version-level immutability support enabled and the related storage account must have versioning enabled. When this is configured, the retention mode can be set to either compliance or governance mode. In both cases the blobs will be in Locked mode.
Follow these steps to enable versioning on the storage account and these steps to enable version-level immutability support on the container or related storage account.
On Kopia side --retention-mode COMPLIANCE --retention-period <retention time> should be set like above.
To have continuous protection it is also necessary to run: kopia maintenance set --extend-object-locks true
full-interval must be at least 1 day shorter than the retention-period or Kopia will not allow you to enable Object Lock extensionKopia supports ransomware protection for Google in a similar manner to S3. The bucket must have both versioning and object retention enabled. When this is configured, the retention mode can be set to either compliance or governance mode. In both cases the blobs will be in Locked mode.
On Kopia side --retention-mode COMPLIANCE --retention-period <retention time> should be set like above.
To have continuous protection it is also necessary to run: kopia maintenance set --extend-object-locks true
full-interval must be at least 1 day shorter than the retention-period or Kopia will not allow you to enable Object Lock extensionIf using minimal permissions with the credentials,
storage.objects.setRetention permission is also required.