Stop Ransomware with Immutable Backups: Combining Rclone and S3 Object Lock – ITFROMZERO

Table of Contents

When backups get encrypted too: A 2 AM horror story

The alarm bells rang incessantly. I jumped up and opened my laptop, hoping it was just a routine network glitch. But when I typed ls -la on the production server, my heart sank. All database dumps and configuration files had been renamed with a .locked extension. A cold ransom note appeared in a README.txt file.

My first instinct was to check the backup directory. That’s when I realized my fatal mistake. The backups were stored on an NFS drive mounted directly to the server. After gaining root access, the hacker ran rm -rf, wiping out all backups before encrypting the primary data. 500GB of customer data vanished in an instant.

The lesson is simple: If a backup is accessible (Mutable), it can definitely be deleted. To survive Ransomware, you need Immutable Backups — copies that cannot be changed or deleted.

Why traditional backup methods often fail

Many IT pros still stick to the habit of using rsync scripts or rclone to push data to a secondary server. This approach has two major vulnerabilities:

Excessive Permissions: Scripts often hold Access Keys with Delete permissions. A hacker who gets this key can wipe your Cloud storage with a few simple commands.
Overwrite Mechanism: Ransomware encrypts the original file, and your backup script diligently pushes that corrupted file, overwriting the last clean version.

We need a mechanism where even a root admin or the Access Key owner cannot delete data for a specific period. That’s where S3 Object Lock comes in.

The Solution: Rclone and S3 Object Lock (Compliance Mode)

S3 Object Lock is a feature on platforms like AWS, Wasabi, or MinIO, operating on the WORM (Write Once, Read Many) model. There are two modes you need to distinguish:

Governance Mode: Users with special permissions (bypass) can still delete files. Sophisticated hackers can still exploit this.
Compliance Mode: Absolutely no one can delete them, not even the Cloud provider’s root account, until the retention period expires. This is the strongest “shield.”

Step 1: Initialize an S3 Bucket with Object Lock support

You must enable Object Lock when creating the Bucket. Note that most providers do not allow enabling this feature on buckets that already contain data.

Regarding account security, use tools like a password generator to create an ultra-strong console password. When assigning IAM permissions for the backup script, grant only the specific permissions s3:PutObject, s3:GetObject and most importantly s3:PutObjectRetention. Never grant s3:DeleteObject.

Step 2: Install Rclone

Rclone is the most powerful Cloud storage management tool on Linux today. Installation takes only 10 seconds:

curl https://rclone.org/install.sh | sudo bash

Run rclone config to create a new remote (e.g., s3-storage). Paste the Access Key and Secret Key created in the previous step here.

Step 3: Perform Immutable Backup

Instead of using the sync command, we will use the copy command with data locking parameters. Suppose you want to back up the /data/db_dumps directory and lock them for 30 days:

rclone copy /data/db_dumps s3-storage:my-backup-bucket \
    --s3-object-lock-mode COMPLIANCE \
    --s3-object-lock-retention-days 30 \
    -P

The parameter --s3-object-lock-mode COMPLIANCE activates the strictest locking mode. For 30 days, this file is “untouchable.”

Step 4: Testing by playing the Hacker

Try deleting the uploaded file to test the system:

rclone delete s3-storage:my-backup-bucket/backup_file.sql

If the screen displays an Access Denied or Object is under active retention error, you have succeeded. Your data is now safe from any external deletion attempts.

Real-world experience to avoid wasting money

Immutable Backup is very powerful, but if misconfigured, you will pay for it in cash:

Consider the Retention period: Don’t set a lock for too long (e.g., 1 year) if not truly necessary. Once locked in Compliance Mode, you cannot reduce the time and must pay storage fees until the final day.
Versioning is Mandatory: Object Lock requires the Bucket to have Versioning enabled. Every time you overwrite an old file, a new version is created, and both are charged. Use filenames with timestamps (e.g., db-2023-11-01.sql) for easier management.
Storage Costs: Since old data cannot be deleted, the bucket size will grow continuously. Calculate your budget carefully if your dataset is larger than 1TB.

Fighting Ransomware isn’t just about installing software and forgetting it. It’s a combination of strict processes and the right technology. With Immutable Backup, you can sleep soundly, knowing that at least you still have a way back if your server is ever attacked.