Immutability and ransomware

Ransomware that reaches a device, or an attacker who steals storage credentials, will try to delete or encrypt the backups as well. MSP Backups defends against this in three ways: object locks on S3 storage, canary files on the device, and change-rate alerts on the server.

S3 Object Lock

When a device has a retention period, the agent writes every chunk and manifest to S3 with Object Lock in compliance mode and a retain-until date. Until that date, the storage service refuses to delete or overwrite the object. This holds for everyone, including the agent, your server and anyone holding the bucket's access keys. Compliance-mode locks cannot be shortened or removed early.

How long the lock lasts:

• At least the device's retention in days, so a restore point cannot be deleted while it is meant to be kept.
• Longer, if the agent's own lock setting (wormDays in agent.json) is larger.
• When a backup reuses an existing chunk, the agent extends that chunk's lock to the new date. A chunk shared by old and new restore points stays locked as long as the newest one needs it.

A device with no retention in days and no wormDays writes objects without a lock.

Set up the bucket

1. Create the bucket with Object Lock turned on. Most S3 providers only allow this at creation time.
2. Add the bucket as a storage target. See Storage targets and replication.
3. Set a retention in days for the tenant's devices. See Retention.

If the agent creates the bucket itself on its first backup, it turns Object Lock on.

SMB and NFS targets

Network shares have no equivalent of Object Lock. On SMB and NFS targets the agent marks written objects read-only and refuses to overwrite them, but anyone with write access to the share can still change those permissions. For backups that must survive a compromised network, use an S3 target with Object Lock.

Canary files

The agent plants a small canary file in each folder it backs up. Before every backup it checks them.

• If a canary's contents have changed, the agent treats it as a sign that files are being encrypted. It stops the backup, so damaged files do not become a new restore point, and sends a security alert to the server. The server records it in the audit log, sends it to your notification channels as critical and fires your security.alert webhooks.
• If a canary is missing, the agent plants it again and carries on. Users delete files from folders like Downloads all the time, and treating that as an attack would block every future backup.

Change-rate alerts

The server compares each new backup with the device's recent history. When a device has at least three earlier backups and a new one rewrote more than half of its data and more than three times its usual change rate, the restore point is flagged as a possible ransomware event and an alert goes to your notification channels. The backup itself is kept: a false alarm costs a review, a missed one could hide an encrypted backup.

When an alert fires

1. Treat the device as compromised. Disconnect it from the network.
2. In Time Machine, find the last restore point from before the alert.
3. Restore from that point onto a clean machine, or rebuild the device and restore. See Restoring files and folders and Bare-metal and VM recovery.