Backup mã hóa: Cứu Ubuntu server bị hack trong phút chốc

dpkg --get-selections > packages.txt

sudo apt update
sudo apt install restic

sudo mkdir -p /root/backup
sudo nano /root/backup/restic-password
sudo chmod 600 /root/backup/restic-password

Password này cực quan trọng. Mất password → không restore được. Nên lưu thêm trong password manager/offline vault.

Khai báo repo S3

Ví dụ:

export RESTIC_REPOSITORY="s3:https://s3.example.com/bucket-name"
export AWS_ACCESS_KEY_ID="ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="SECRET_KEY"
export RESTIC_PASSWORD_FILE="/root/backup/restic-password"

Nên tạo IAM key riêng, chỉ quyền ghi/đọc cần thiết. Tốt hơn: bật Object Lock/Versioning để chống xóa.

Init repo:

restic init

Script backup

Tạo file:

sudo nano /usr/local/sbin/secure-backup.sh
sudo chmod 700 /usr/local/sbin/secure-backup.sh

Nội dung mẫu:

#!/usr/bin/env bash
set -euo pipefail

export RESTIC_REPOSITORY="s3:https://s3.example.com/bucket-name"
export AWS_ACCESS_KEY_ID="ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="SECRET_KEY"
export RESTIC_PASSWORD_FILE="/root/backup/restic-password"

DATE=$(date +%F-%H%M)
WORKDIR="/root/backup/tmp-$DATE"
mkdir -p "$WORKDIR"

dpkg --get-selections > "$WORKDIR/packages.txt"

sudo -u postgres pg_dumpall > "$WORKDIR/postgres.sql"

tar -czf "$WORKDIR/etc-critical.tar.gz" 
  /etc/nginx 
  /etc/systemd 
  /etc/ufw 
  /etc/ssh/sshd_config 
  /etc/letsencrypt 2>/dev/null || true

restic backup 
  "$WORKDIR" 
  /var/www 
  /srv/app 
  --exclude node_modules 
  --exclude vendor 
  --exclude '*.log'

restic forget 
  --keep-daily 7 
  --keep-weekly 4 
  --keep-monthly 6 
  --prune

restic check --read-data-subset=5%

rm -rf "$WORKDIR"

Điểm chính:

– DB dump riêng → restore nhanh.
– Config gom lại → dựng server mới nhanh.
– Exclude thư mục tái tạo được.
– Retention rõ.
– check định kỳ → phát hiện lỗi sớm.

Tự động hóa bằng systemd timer

Cron ổn, nhưng systemd timer dễ quản lý hơn.

Service:

sudo nano /etc/systemd/system/secure-backup.service

[Unit]
Description=Encrypted Restic Backup

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/secure-backup.sh

Timer:

sudo nano /etc/systemd/system/secure-backup.timer

[Unit]
Description=Run encrypted backup daily

[Timer]
OnCalendar=--* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

Bật timer:

sudo systemctl daemon-reload
sudo systemctl enable --now secure-backup.timer
systemctl list-timers

Log:

journalctl -u secure-backup.service

Bảo vệ backup khỏi attacker

Backup mã hóa chưa đủ. Nếu attacker có quyền xóa repo → vẫn nguy.

Tách quyền

– Key backup production chỉ nên ghi thêm, hạn chế xóa nếu storage hỗ trợ.
– Tài khoản quản trị storage không lưu trên server.
– Không dùng chung SSH key deploy và backup.
– Không lưu root cloud token trên server.

Immutable storage

Bật:

– S3 Object Lock.
– Versioning.
– Retention policy.
– MFA delete nếu có.
– Bucket policy chặn delete từ key backup.

Kết quả: server bị chiếm → attacker vẫn khó xóa lịch sử backup.

Offline backup

Định kỳ copy backup sang disk offline/NAS tắt mạng. Đơn giản nhưng hiệu quả. Ransomware không chạm được thứ không online.

Khôi phục nhanh sau khi Ubuntu server bị tấn công

Khi phát hiện compromise, đừng restore ngay trên máy cũ. Máy cũ có thể còn rootkit/backdoor.

Quy trình ứng cứu

1. Cô lập server: chặn inbound/outbound hoặc snapshot forensic.
2. Không xóa vội: giữ log, disk snapshot nếu cần điều tra.
3. Xác định thời điểm xâm nhập gần đúng.
4. Dựng server Ubuntu mới từ image sạch.
5. Patch đầy đủ.
6. Restore từ snapshot backup trước thời điểm nhiễm.
7. Rotate toàn bộ secret.
8. Kiểm tra app/log/network.
9. Chuyển traffic.

Không tin máy cũ. Không reuse key cũ.

Restore bằng Restic

Liệt kê snapshot:

restic snapshots

Mount để xem nhanh:

mkdir /mnt/restic
restic mount /mnt/restic

Restore snapshot cụ thể:

restic restore SNAPSHOT_ID --target /restore

Khôi phục DB PostgreSQL:

sudo -u postgres psql < /restore/root/backup/tmp-*/postgres.sql

Khôi phục app data:

rsync -a /restore/var/www/ /var/www/
rsync -a /restore/srv/app/ /srv/app/

Khôi phục config có chọn lọc. Không copy đè /etc toàn bộ nếu chưa kiểm tra:

tar -xzf /restore/root/backup/tmp-*/etc-critical.tar.gz -C /

Sau đó:

sudo nginx -t
sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo systemctl restart app.service

Rotate secret sau restore

Bắt buộc đổi:

– SSH keys.
– DB password.
– API keys.
– JWT secret.
– OAuth secret.
– S3/backup credentials.
– CI/CD tokens.
– Admin password.
– TLS private key nếu nghi lộ.
– User session/cookie signing key.

Nếu không rotate → attacker có thể quay lại dù restore sạch.

Kiểm tra bản restore có sạch không?

Không có gì tuyệt đối, nhưng cần làm:

– So sánh file lạ trong app dir.
– Kiểm tra user mới trong /etc/passwd.
– Kiểm tra SSH authorized_keys.
– Kiểm tra crontab:

crontab -l
sudo ls -la /etc/cron.*

– Kiểm tra systemd service lạ:

systemctl list-unit-files

– Kiểm tra port listening:

ss -tulpn

– Kiểm tra process:

ps auxf

– Scan malware cơ bản:

sudo apt install rkhunter chkrootkit
sudo rkhunter --check
sudo chkrootkit

Cẩn trọng: tool scan không đảm bảo sạch. Server mới + restore chọn lọc vẫn là chuẩn hơn.

RTO, RPO: đo trước khi sự cố

Hai chỉ số cần có:

– RPO: mất tối đa bao nhiêu dữ liệu? Ví dụ backup mỗi 1 giờ → mất tối đa ~1 giờ.
– RTO: mất bao lâu để chạy lại? Ví dụ 30 phút dựng server + restore.

Nếu DB thay đổi liên tục, backup ngày/lần là thiếu. Cần:

– WAL archiving PostgreSQL.
– Binlog MySQL.
– Snapshot volume.
– Replication sang standby.
– Backup mỗi giờ hoặc 15 phút.

Đừng đo bằng cảm giác. Hãy chạy diễn tập.

Diễn tập restore định kỳ

Mỗi tháng/quý:

1. Tạo VM mới.
2. Restore snapshot bất kỳ.
3. Chạy migration nếu cần.
4. Start service.
5. Test login, upload, checkout, API.
6. Ghi lại thời gian restore.
7. Cập nhật runbook.

Kết quả mong muốn: người trực ca không cần hỏi ai vẫn restore được.

Checklist thực tế

– Backup mã hóa: Restic/Borg.
– Repo offsite: S3/B2/SFTP khác hạ tầng.
– Immutable/versioning: bật.
– Password backup: lưu an toàn ngoài server.
– DB dump/physical backup: có.
– Config quan trọng: có.
– Secret rotation plan: có.
– Restore test: định kỳ.
– Runbook sự cố: rõ lệnh, rõ người chịu trách nhiệm.
– Monitoring backup fail: có alert qua email/Slack/Telegram.

Kết luận

Secure Ubuntu server không phải “không thể bị hack”, mà là bị hack vẫn kiểm soát thiệt hại. Backup mã hóa bảo vệ dữ liệu khi file backup rơi vào tay sai. Immutable/offline backup bảo vệ khỏi xóa/mã hóa. Restore test bảo vệ khỏi ảo tưởng an toàn.

Chiến lược đúng: backup sạch, mã hóa, tách quyền, lưu offsite, có bản immutable, test restore thường xuyên. Khi sự cố xảy ra, dựng server mới, restore chọn lọc, rotate toàn bộ secret, kiểm tra kỹ, rồi mới đưa traffic trở lại. Downtime ngắn hay dài phụ thuộc vào chuẩn bị trước đó. Backup tốt → bình tĩnh. Restore nhanh → sống sót.