<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: implementing-immutable-backup-strategies
description: >-
  Design and implement immutable backup architectures that survive ransomware
  attacks. Covers WORM storage, S3 Object Lock, air-gapped backups, tape
  rotation, immutable repository design for Veeam/Restic/BorgBackup,
  backup account isolation, and 3-2-1-1-0 strategy implementation.
domain: cybersecurity
subdomain: ransomware-defense
tags:
  - immutable-backups
  - worm-storage
  - s3-object-lock
  - air-gap
  - backup-isolation
  - 3-2-1-1-0
  - veeam
  - restic
  - borgbackup
version: '1.0'
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: ["T1490"]
---

# Implementing Immutable Backup Strategies

## Overview

Immutable backups cannot be modified, encrypted, or deleted by ransomware
— even if the attacker has domain admin credentials. This is the single
most important ransomware defense control. Without verified immutable
backups, organizations face a binary choice: pay or lose data.

3-2-1-1-0: 3 copies, 2 media types, 1 offsite, 1 immutable/offline, 0 errors.

## Prerequisites

| Tool | Purpose | Install |
|------|---------|---------|
| AWS CLI | S3 Object Lock management | `pip install awscli` |
| Restic | Immutable backup repo | `apt install restic` |
| BorgBackup | Append-only backup repo | `apt install borgbackup` |
| Veeam B&R | Hardened repository | Licensed install |
| MinIO | S3-compatible immutable storage | Docker/binary |

## Key Concepts

### Immutability Methods

| Method | Protection Level | Cost | Complexity |
|--------|-----------------|------|------------|
| S3 Object Lock (Compliance) | Highest — no one can delete | Medium | Low |
| S3 Object Lock (Governance) | High — root can override | Medium | Low |
| Air-gapped tape | Highest — physically disconnected | High | Medium |
| Veeam Hardened Repository | High — Linux immutable flag | Medium | Medium |
| BorgBackup append-only | Medium — server-side control | Low | Low |
| WORM storage appliance | Highest — hardware enforced | High | Low |
| Offline rotated disk | High — disconnected between backups | Low | Medium |

### 3-2-1-1-0 Architecture

```
Production Data
  ├── Copy 1: Local backup (Veeam/Restic to NAS)
  │   └── Media: Disk (fast RTO)
  ├── Copy 2: Offsite backup (S3 with Object Lock)
  │   └── Media: Cloud object storage (WORM)
  ├── Copy 3: Offline backup (tape or disconnected disk)
  │   └── Media: Tape/removable (air-gapped)
  │
  └── Immutable copy: S3 Compliance Mode Object Lock
      └── Retention: 30 days minimum (cannot be shortened)
      └── 0 errors: automated restore testing weekly
```

## Workflow

### Step 1 — S3 Object Lock Configuration

```bash
# Create bucket with Object Lock enabled (must be at creation time)
aws s3api create-bucket \
  --bucket backup-immutable-prod \
  --region us-east-1 \
  --object-lock-enabled-for-bucket

# Set default retention (Compliance mode — cannot be overridden)
aws s3api put-object-lock-configuration \
  --bucket backup-immutable-prod \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 30
      }
    }
  }'

# Verify configuration
aws s3api get-object-lock-configuration \
  --bucket backup-immutable-prod

# Upload with explicit retention
aws s3api put-object \
  --bucket backup-immutable-prod \
  --key "backups/2026-03-17/full.tar.gz" \
  --body /backup/full.tar.gz \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date "2026-04-16T00:00:00Z"
```

### Step 2 — Restic with S3 Immutable Backend

```bash
# Initialize Restic repo with S3 Object Lock backend
export AWS_ACCESS_KEY_ID="backup-user-key"
export AWS_SECRET_ACCESS_KEY="backup-user-secret"
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/backup-immutable-prod/restic"
export RESTIC_PASSWORD="strong-encryption-passphrase"

restic init

# Backup with S3 immutability
restic backup /data /etc /home \
  --tag daily --tag production

# Verify repository integrity
restic check --read-data-subset=10%

# Retention policy (Restic forget + S3 Object Lock = belt and suspenders)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
```

### Step 3 — BorgBackup Append-Only Mode

```bash
# Server-side: configure append-only repository
# In ~/.ssh/authorized_keys on backup server:
# command="borg serve --restrict-to-path /backup/borg --append-only"
#   ssh-rsa AAAA... backup-client

# Client-side: backup as normal
borg create --stats --progress \
  ssh://backup@backup-server/backup/borg::daily-{now} \
  /data /etc /home

# Server-side: only admin can prune (separate credentials)
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 \
  /backup/borg
```

### Step 4 — Veeam Hardened Repository (Linux)

```bash
# Configure Linux server as immutable backup target
# Uses Linux immutable flag (chattr +i) on backup files

# 1. Deploy fresh Linux (Ubuntu/RHEL) — NOT domain-joined
# 2. Create dedicated backup user (no SSH after setup)
# 3. Disable root SSH login
# 4. Enable single-user mode password

# Veeam sets immutable flag on backup files
# Files cannot be modified/deleted until retention expires
# Even root cannot override without remounting filesystem

# Verify immutability
lsattr /backup/veeam/
# Output should show 'i' flag: ----i--------e-- file.vbk
```

### Step 5 — Air-Gapped Tape Rotation

```bash
# Tape rotation schedule (Grandfather-Father-Son)
# Daily (Son): Mon-Thu to tape, reused weekly
# Weekly (Father): Friday full backup, retained 4 weeks
# Monthly (Grandfather): First Friday, retained 12 months

# LTO tape backup with tar
tar cvf /dev/st0 --multi-volume /data/

# Verify tape contents
tar tvf /dev/st0

# CRITICAL: Store tapes offsite in fireproof safe
# Rotate courier weekly — never keep all tapes on-site
```

### Step 6 — Backup Account Isolation

```bash
# Backup infrastructure must be isolated from domain
# Separate credentials — NOT Active Directory accounts

# 1. Backup servers NOT domain-joined
# 2. Unique local accounts for backup administration
# 3. MFA on backup console access
# 4. Network segmentation (backup VLAN, firewall rules)
# 5. No inbound SMB/RDP from production network

# Firewall rules for backup network
iptables -A INPUT -s 10.100.0.0/24 -p tcp --dport 22 -j ACCEPT  # Backup mgmt
iptables -A INPUT -s 10.0.0.0/16 -p tcp --dport 22 -j DROP       # Block prod
iptables -A INPUT -s 10.0.0.0/16 -p tcp --dport 445 -j DROP      # Block SMB
```

## Detection

```yaml
title: Immutable Backup Strategies Detection
id: 4996ce15-fcf8-46cf-a0cb-621d59bcf755
status: experimental
description: Detects suspicious activity related to implementing immutable backup strategies techniques in ransomware defense context
logsource:
  category: file_change
  product: windows
detection:
  selection:
    TargetFilename: "*suspicious*"
  condition: selection
level: critical
tags:
  - attack.t1490
  - attack.impact
falsepositives:
  - Backup software performing scheduled file encryption operations
```

## Verification

- [ ] S3 Object Lock (Compliance mode) enabled on backup bucket
- [ ] Object retention period set ≥ 30 days
- [ ] Restic/Borg backup uses immutable backend
- [ ] Air-gapped backup rotation operational (weekly minimum)
- [ ] Backup infrastructure NOT domain-joined
- [ ] Backup admin accounts separate from domain accounts
- [ ] Weekly automated restore test passes
- [ ] 3-2-1-1-0 rule fully implemented

## References

- CISA Ransomware Guide: Backup Best Practices
- AWS S3 Object Lock Documentation
- NIST SP 800-209: Security Guidelines for Storage Infrastructure
- CIS Control 11: Data Recovery
- Veeam Hardened Repository Guide
