Keamanan

Ransomware Defense: Strategi Backup 3-2-1 untuk Server Linux Production

Syafriadi 2026-07-04 15 menit
Ransomware Defense: Strategi Backup 3-2-1 untuk Server Linux Production

Desember tahun lalu, client gw yang operating food delivery service kena ransomware. Semua server di-lock, database di-encrypt, dan attacker minta 5 Bitcoin (~$200K saat itu). Mereka gak punya backup strategy yang proper — backup terakhir 3 minggu sebelumnya, dan itu pun di server yang sama dengan production data.

Gw spend 2 minggu bantu recovery. Hasilnya: mereka kehilangan 12 hari transaksi, data 8,000 customer hilang permanent, dan total kerugian mendekati $500K (termasuk ransom yang gak dibayar, downtime, dan rebuild). Kalau mereka punya backup strategy 3-2-1 yang proper, recovery time bisa kurang dari 4 jam.

Artikel ini bakal jelasin gimana membangun backup strategy yang benar-benar resistant terhadap ransomware — bukan cuma "backup ke external drive" yang naive. Gw bakal share exact configuration yang pake di production, lengkap dengan commands yang bisa lo copy-paste.

Apa Itu Rule 3-2-1?

Rule 3-2-1 adalah fondasi backup strategy yang diakui industri:

  • 3 copies dari data: production + 2 backups
  • 2 different media: contoh SSD + cloud storage
  • 1 offsite: minimal 1 copy di lokasi berbeda (geographic separation)

Tapi untuk ransomware defense, kita perlu upgrade rule ini jadi 3-2-1-1-0:

  • 3 copies: data + backup lokal + backup offsite
  • 2 media types: SSD + object storage (S3/Backblaze)
  • 1 offsite: cloud backup di region berbeda
  • 1 immutable: backup yang TIDAK BISA dihapus atau di-modify (ini kunci anti-ransomware)
  • 0 errors: verified backup — setiap backup harus di-test restore-nya

Kenapa immutability penting? Karena ransomware modern gak cuma encrypt — dia juga cari dan hapus semua backup yang bisa diakses. Kalau backup lo di S3 tanpa Object Lock, attacker yang udah dapet AWS credentials bisa hapus semua backup lo dalam hitungan menit.

Kenapa Backup Biasa Gak Cukup?

Ransomware modern gak cuma encrypt files — dia juga:

  • Cari dan hapus backup: Banyak ransomware scan untuk file backup (.bak, .sql, .dump) dan hapus sebelum encrypt. Beberapa bahkan scan untuk nama file yang mengandung "backup", "restore", atau "archive".
  • Disable VSS: Windows Volume Shadow Copy dihapus. Di Linux, cron jobs untuk backup bisa di-disable atau dihapus.
  • Encrypt shared drives: Kalau backup lo mount sebagai network drive, ransomware bisa encrypt juga. Pernah lihat kasus di mana backup NAS di-mount via SMB, dan ransomware encrypt semua file di NAS.
  • Target cloud credentials: Kalau AWS keys tersimpan di server (environment variables, config files), attacker bisa hapus S3 backups juga. Makanya dedicated backup credentials yang terpisah dari production credentials.

Makanya kita butuh immutability — backup yang secara teknis tidak bisa dihapus atau di-modify oleh siapapun, termasuk root di production server. Ini bukan over-engineering — ini defense in depth.

Tool: Restic + S3 dengan Object Lock

Gw pake Restic sebagai backup tool karena:

  • Encryption by default — data terenkripsi sebelum keluar server. Kalau attacker intercept traffic, mereka gak bisa baca data.
  • Incremental — cuma backup yang berubah, hemat storage dan bandwidth. Restic pakai content-defined chunking, jadi file yang sedikit berubah cuma store diff-nya.
  • Deduplication — file yang sama di berbagai lokasi cuma disimpan sekali. Hemat storage 30-50% di typical workloads.
  • Cross-platform — backup ke S3, B2, local, SFTP. Kalau lo mau multi-cloud, Restic support semua major providers.
# Install Restic
wget https://github.com/restic/restic/releases/download/v0.16.5/restic_0.16.5_linux_amd64.bz2
bunzip2 restic_0.16.5_linux_amd64.bz2
chmod +x restic_0.16.5_linux_amd64
mv restic_0.16.5_linux_amd64 /usr/local/bin/restic

# Initialize backup repository (S3 + encryption)
export RESTIC_REPOSITORY=s3:s3.ap-southeast-1.amazonaws.com/my-backup-bucket
export RESTIC_PASSWORD_FILE=/etc/restic/password
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...

# Generate password untuk encryption
openssl rand -base64 32 > /etc/restic/password
chmod 600 /etc/restic/password

restic init

Setup: Backup yang Resistant terhadap Ransomware

Step 1: Buat dedicated backup user (bukan root)

# Buat backup user dengan limited privileges
sudo useradd -r -s /bin/bash -d /home/backup backup
sudo mkdir -p /home/backup/.ssh
sudo cp /root/.ssh/authorized_keys /home/backup/.ssh/

# Backup user TIDAK boleh akses production data langsung
# Kita pakai dump/extract mechanism

Kenapa dedicated user? Karena kalau production server compromise, attacker biasanya dapet root access. Dengan dedicated backup user, credentials terpisah. Dan backup user cuma punya akses ke backup repository, bukan ke production data.

Step 2: Backup script dengan verification

#!/bin/bash
# /usr/local/bin/backup-restic.sh
set -euo pipefail

export RESTIC_REPOSITORY="s3:s3.ap-southeast-1.amazonaws.com/my-backup"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
export AWS_ACCESS_KEY_ID="$(cat /etc/restic/aws-key-id)"
export AWS_SECRET_ACCESS_KEY="$(cat /etc/restic/aws-secret)"

LOG="/var/log/backup-$(date +%Y%m%d).log"
exec > >(tee -a "$LOG") 2>&1

echo "=== Backup started at $(date) ==="

# 1. Dump database
echo "[1/4] Dumping PostgreSQL..."
sudo -u postgres pg_dumpall | gzip > /tmp/db-dump.sql.gz

# 2. Backup config files
echo "[2/4] Backing up configs..."
tar czf /tmp/configs.tar.gz /etc/nginx /etc/caddy   /opt/docker/astro-sites/rina-my-id/src/data/

# 3. Run restic backup
echo "[3/4] Running restic..."
restic backup   --verbose   /tmp/db-dump.sql.gz   /tmp/configs.tar.gz   /opt/docker/astro-sites/rina-my-id/public/images/   --tag "daily"   --tag "$(hostname)"

# 4. Verify backup (CRITICAL!)
echo "[4/4] Verifying backup..."
restic check --read-data-subset=5%

# 5. Cleanup old backups (keep: 7 daily, 4 weekly, 12 monthly)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# 6. Cleanup temp files
rm -f /tmp/db-dump.sql.gz /tmp/configs.tar.gz

echo "=== Backup completed at $(date) ==="

Beberapa hal penting di script ini:

  • set -euo pipefail: Script berhenti di error pertama. Gak ada "partial backup" yang silently fail.
  • Credentials dari files: Bukan environment variables yang bisa di-log. Files dengan permission 600.
  • Verification step: restic check --read-data-subset=5% verify 5% random data. Cukup untuk detect corruption tanpa download semua data.
  • Retention policy: 7 daily, 4 weekly, 12 monthly. Total ~60 restore points. Storage cost rendah karena Restic deduplication.

Step 3: S3 Object Lock untuk Immutability

Ini adalah kunci anti-ransomware. AWS S3 Object Lock memastikan backup TIDAK BISA dihapus selama retention period — bahkan oleh root, bahkan oleh AWS support:

# Enable Object Lock saat bucket creation
aws s3api create-bucket   --bucket my-backup-bucket   --region ap-southeast-1   --object-lock-enabled-for-bucket

# Set default retention (30 hari — gak bisa dihapus/di-modify)
aws s3api put-object-lock-configuration   --bucket my-backup-bucket   --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "GOVERNANCE",
        "Days": 30
      }
    }
  }'

Dengan GOVERNANCE mode, object gak bisa dihapus tanpa special permission (s3:BypassGovernanceRetention). Kalau lo mau lebih ketat, pakai COMPLIANCE mode — bahkan AWS sendiri gak bisa override. Tapi COMPLIANCE mode lebih rigid (gak bisa di-bypass untuk legal holds).

Automated Verification (Rule 0 errors)

Backup yang gak di-test = backup yang mungkin corrupt. Pernah nemu kasus di mana backup udah jalan 6 bulan, tapi pas di-test restore, file-nya corrupt. Ternyata ada bug di Restic version yang dipake.

#!/bin/bash
# /usr/local/bin/verify-backup.sh — jalan seminggu sekali
export RESTIC_REPOSITORY="s3:s3.ap-southeast-1.amazonaws.com/my-backup"
export RESTIC_PASSWORD_FILE="/etc/restic/password"

# 1. Check repository integrity
restic check 2>&1 | tee /tmp/verify.log

# 2. Test restore ke /tmp (tanpa overwriting production)
LATEST=$(restic snapshots --latest 1 --json |   python3 -c "import sys,json; print(json.load(sys.stdin)[0]['id'])")
mkdir -p /tmp/restore-test
restic restore "$LATEST" --target /tmp/restore-test 2>&1 | tee -a /tmp/verify.log

# 3. Verify restore data
if [ -f /tmp/restore-test/tmp/db-dump.sql.gz ]; then
    echo "PASS: Database dump restoreable" | tee -a /tmp/verify.log
    gzip -t /tmp/restore-test/tmp/db-dump.sql.gz &&       echo "PASS: Gzip integrity OK" | tee -a /tmp/verify.log
else
    echo "FAIL: Database dump missing!" | tee -a /tmp/verify.log
    curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage"       -d "chat_id=$CHAT_ID&text=BACKUP VERIFICATION FAILED!"
fi

rm -rf /tmp/restore-test

Verification ini test 3 hal: (1) repository integrity, (2) restore-ability, dan (3) file integrity. Kalau ada yang gagal, alert langsung ke Telegram.

Multi-Region Backup: Jangan Taruh Semua di Satu Tempat

Satu lesson yang mahal dari beberapa incident: single region S3 bukan offsite backup. AWS region bisa down (us-east-1 outage 2021 bikin separuh internet mati). Kalau backup lo cuma di satu region, lo punya single point of failure.

# Sync backup ke region kedua (setiap backup run)
aws s3 sync   s3://my-backup-bucket   s3://my-backup-bucket-secondary   --source-region ap-southeast-1   --region ap-east-1   --storage-class STANDARD_IA   --exclude "*"   --include "restic/*"

Pakai STANDARD_IA (Infrequent Access) untuk region kedua — cost 40% lebih murah dari STANDARD. Lo cuma bayar kalau perlu restore dari region kedua, yang rare. Tapi kalau region utama down, lo punya full backup yang bisa di-access dalam hitungan menit.

Tambahkan juga local backup ke NAS atau external drive yang di-mount read-only. Ini defense terakhir kalau internet down atau cloud provider bermasalah:

# Local backup ke NAS (read-only mount)
mount -o ro //nas.local/backup /mnt/nas-backup
restic backup --verbose /opt/docker/astro-sites/ --target /mnt/nas-backup
umount /mnt/nas-backup

Dengan 3 layer ini (S3 primary + S3 secondary + local NAS), lo covered untuk semua scenario: ransomware, region outage, hardware failure, dan bahkan cloud provider bankruptcy.

Recovery Time: Berapa Cepat Bisa Restore?

ScenarioTanpa 3-2-1-1-0Dengan 3-2-1-1-0
Server hackedDays (rebuilt from scratch)2-4 hours (full restore)
Ransomware encryptPotential data loss (weeks)1-2 hours (restore from immutable)
Hardware failureHours (if backup exists)30 min (quick restore)
Human error (rm -rf)Panic + potential loss10 min (restic restore)
S3 region outageTotal loss2 hours (restore from secondary region)
Cloud provider bankruptcyTotal loss30 min (restore from local NAS)

Backup strategy yang proper bukan cuma soal technical implementation — ini soal peace of mind. Setiap server production WAJIB punya backup strategy yang verified dan tested. Jangan tunggu sampai kena ransomware baru sadar backup-nya corrupt. Investasi 2-3 jam setup backup strategy hari ini bisa save lo dari kerugian ratusan ribu dolar besok. Seriusan — ini bukan hyperbole, ini data dari client yang udah gw handle recovery-nya.

Untuk security hardening lebih lanjut, baca juga artikel tentang zero trust dengan mTLS dan analisis privilege escalation.

#ransomware#backup#security#linux#restic#disaster-recovery

💬 Komentar (0)

Belum ada komentar. Jadilah yang pertama! 💬

Komentar akan muncul setelah moderasi.