Chặn Ransomware Trên Ubuntu: Phân Quyền, Snapshot, Backup Immutability

Secure Ubuntu server trước ransomware: phân quyền, snapshot, immutable backup

Ransomware không còn chỉ nhắm Windows desktop. Ubuntu server cũng có thể bị mã hóa dữ liệu nếu attacker chiếm được SSH, web app, CI/CD token, panel quản trị, hoặc tài khoản có quyền ghi vào storage. Điểm nguy hiểm: nhiều hệ thống Linux “ổn định” nhiều năm nhưng backup lại mount sẵn, user dùng sudo rộng, snapshot chưa test restore. Khi ransomware chạy với quyền đủ cao, nó không cần exploit kernel; chỉ cần quyền ghi.

Mục tiêu phòng thủ thực tế: giảm quyền ghi, giới hạn vùng thiệt hại, khôi phục nhanh, và giữ ít nhất một bản backup không thể sửa/xóa.

1. Tư duy phòng thủ: ransomware cần quyền ghi

Ransomware thành công khi có 3 điều kiện:

– Có điểm vào: SSH yếu, app lỗi, key lộ, mật khẩu tái sử dụng. – Có quyền ghi: user app ghi nhầm toàn hệ thống, sudo quá rộng, share mount RW. – Có khả năng phá backup: backup nằm cùng server, mount thường trực, token backup có quyền delete.

Vì vậy, chiến lược nên xoay quanh:

– Least privilege: service chỉ có quyền tối thiểu. – Isolation: app, DB, backup, secrets tách quyền. – Versioning/snapshot: quay lại trạng thái trước mã hóa. – Immutable/offline backup: attacker không thể xóa bản cứu hộ. – Restore drill: backup chưa test = giả định vô dụng.

2. Phân quyền Ubuntu: giảm bán kính phá hoại

Tách user theo service

Không chạy app bằng root. Mỗi ứng dụng nên có user riêng:

sudo adduser --system --group --home /var/lib/myapp myapp

Thư mục app nên tách rõ:

sudo mkdir -p /opt/myapp /var/lib/myapp /var/log/myapp
sudo chown -R root:root /opt/myapp
sudo chown -R myapp:myapp /var/lib/myapp /var/log/myapp

Ý nghĩa:

– /opt/myapp: code, root sở hữu, app chỉ đọc. – /var/lib/myapp: dữ liệu runtime, app được ghi. – /var/log/myapp: log, app được ghi. – /etc/myapp: config, root sở hữu, app chỉ đọc.

Ví dụ:

sudo mkdir -p /etc/myapp
sudo chown root:myapp /etc/myapp
sudo chmod 750 /etc/myapp
sudo chmod 640 /etc/myapp/config.yml

Nếu ransomware chạy dưới user myapp, nó chỉ mã hóa được vùng myapp có quyền ghi, không lan sang code, config hệ thống, app khác.

Siết sudo

Kiểm tra ai có quyền sudo:

getent group sudo

Quy tắc:

– Không cấp sudo cho user app. – Không dùng tài khoản cá nhân chạy cron production. – Không dùng NOPASSWD tràn lan. – Tách admin account khỏi deploy account.

File sudoers nên dùng:

sudo visudo

Ví dụ giới hạn deploy chỉ restart service:

deploy ALL=(root) /bin/systemctl restart myapp.service, /bin/systemctl status myapp.service

Tránh:

deploy ALL=(ALL) NOPASSWD:ALL

Dòng trên biến key deploy bị lộ thành root compromise.

Quyền file: mặc định chặt hơn

Thiết lập umask cho service để file mới không quá mở:

[Service]
User=myapp
Group=myapp
UMask=0027

Trong systemd service:

[Service]
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
ReadWritePaths=/var/lib/myapp /var/log/myapp
ReadOnlyPaths=/opt/myapp /etc/myapp
PrivateTmp=true
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true

Các option quan trọng:

– ProtectSystem=strict: filesystem gần như read-only. – ReadWritePaths: chỉ định nơi được ghi. – NoNewPrivileges=true: chặn leo quyền qua cơ chế phụ. – PrivateTmp=true: tách /tmp. – ProtectHome=true: chặn truy cập home user.

Đây là lớp phòng thủ cực hữu ích: app bị RCE vẫn bị systemd “nhốt” quyền ghi.

3. SSH hardening: giảm cửa vào

Cấu hình SSH:

sudo nano /etc/ssh/sshd_config

Khuyến nghị:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers admin deploy

Restart:

sudo systemctl restart ssh

Thêm rate limit bằng UFW:

sudo ufw allow OpenSSH
sudo ufw enable

Dùng fail2ban:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Điểm cần nhớ:

– Root SSH trực tiếp → rủi ro cao. – Password login → dễ brute force/credential stuffing. – Key không passphrase → lộ laptop = lộ server. – Admin nên dùng MFA qua VPN/bastion nếu hệ thống quan trọng.

4. Snapshot: quay lại nhanh nhưng không phải backup hoàn chỉnh

Snapshot giúp rollback nhanh khi ransomware mã hóa dữ liệu. Nhưng snapshot trên cùng storage có thể bị xóa nếu attacker có quyền admin/cloud API.

LVM snapshot

Nếu dùng LVM:

sudo lvcreate --size 10G --snapshot --name data_snap /dev/vg0/data

Mount read-only để kiểm tra:

sudo mkdir /mnt/data_snap
sudo mount -o ro /dev/vg0/data_snap /mnt/data_snap

Rollback cần cẩn thận, thường phải unmount volume và merge snapshot:

sudo lvconvert --merge /dev/vg0/data_snap

LVM snapshot phù hợp rollback ngắn hạn, không nên giữ lâu vì performance và dung lượng snapshot có thể đầy.

ZFS snapshot

Nếu dùng ZFS:

sudo zfs snapshot tank/data@pre-update

Liệt kê:

sudo zfs list -t snapshot

Rollback:

sudo zfs rollback tank/data@pre-update

ZFS mạnh vì snapshot rẻ, nhanh, có thể gửi sang máy khác:

sudo zfs send tank/data@snap1 | ssh backup-server sudo zfs receive backup/data

Btrfs snapshot

Nếu dùng Btrfs:

sudo btrfs subvolume snapshot -r /data /snapshots/data-$(date +%F)

5. Immutable backup: lớp sống còn

Backup cùng server không đủ. Backup mount sẵn RW cũng không đủ. Ransomware thường tìm:

– /backup – NFS/SMB mount – S3 credentials – Restic/Borg repo keys – Cloud API token

Nguyên tắc 3-2-1-1-0:

– 3 bản dữ liệu. – 2 loại media/storage. – 1 bản offsite. – 1 bản immutable/offline. – 0 lỗi restore sau kiểm tra.

Cách triển khai immutable

Các lựa chọn thực tế:

– Object storage có Object Lock/WORM. – S3-compatible storage bật versioning + retention. – Backup server chỉ nhận push qua user hạn chế. – Offline disk định kỳ rút khỏi server. – Tape hoặc cold archive cho dữ liệu quan trọng.

Với S3 Object Lock, cần bật lúc tạo bucket. Sau đó set retention, ví dụ 30 ngày. Khi đã khóa đúng, kể cả credential bị lộ cũng không xóa được object trước hạn retention, tùy policy.

Cảnh báo: bật immutable retention có thể gây chi phí lưu trữ tăng; dữ liệu không xóa được trước hạn. Test kỹ policy, lifecycle, legal hold.

6. Backup bằng restic/borg: mã hóa, kiểm tra, tách quyền

Restic

Khởi tạo repo:

restic -r s3:s3.amazonaws.com/bucket-name init

Backup:

restic -r s3:s3.amazonaws.com/bucket-name backup /etc /var/lib/myapp

Kiểm tra:

restic -r s3:s3.amazonaws.com/bucket-name check

Restore test:

restic -r s3:s3.amazonaws.com/bucket-name restore latest --target /tmp/restore-test

Lưu ý:

– Repo password phải nằm ngoài app. – IAM key chỉ nên có quyền cần thiết. – Nếu dùng Object Lock, không cấp quyền bypass retention. – Không lưu credential backup trong thư mục web/app.

Borg

Borg phù hợp backup qua SSH:

borg init --encryption=repokey-blake2 backupuser@backup-server:/repo/myserver

Backup:

borg create backupuser@backup-server:/repo/myserver::'{now:%Y-%m-%d}' /etc /var/lib/myapp

Trên backup server, dùng borg serve với forced command để giới hạn quyền SSH key. Không cho user backup shell tự do nếu không cần.

7. Backup DB: đừng chỉ snapshot file

Database cần backup nhất quán. Với PostgreSQL:

pg_dump -Fc mydb > /backup/mydb.dump

Hoặc dùng pg_basebackup cho backup vật lý.

Với MySQL/MariaDB:

mysqldump --single-transaction --routines --triggers mydb > /backup/mydb.sql

Tốt nhất:

– Dump DB ra thư mục staging. – Backup staging bằng restic/borg. – Xóa staging sau khi backup. – Test restore vào DB tạm.

Snapshot filesystem khi DB đang ghi có thể không nhất quán nếu không phối hợp freeze/flush hoặc dùng cơ chế backup DB chuẩn.

8. Giám sát dấu hiệu mã hóa

Một số tín hiệu đáng báo động:

– Nhiều file đổi đuôi bất thường. – Tăng đột biến write I/O. – CPU cao bởi process lạ. – Nhiều file bị xóa/sửa trong thời gian ngắn. – Backup job fail liên tiếp. – Login SSH từ IP lạ.

Công cụ hữu ích:

sudo apt install auditd

Theo dõi thư mục quan trọng:

sudo auditctl -w /var/lib/myapp -p wa -k myapp_changes

Xem log:

sudo ausearch -k myapp_changes

Có thể kết hợp Prometheus, Grafana, Loki, Wazuh, Falco. Quan trọng nhất: alert phải đến được người trực, không chỉ nằm trong dashboard.

9. Kịch bản ứng phó khi nghi ransomware

Nếu nghi server bị mã hóa:

1. Cô lập mạng: chặn outbound/inbound, không vội reboot nếu cần forensic. 2. Thu thập bằng chứng: process, connection, auth log, file lạ. 3. Ngắt credential: rotate SSH key, API token, DB password, backup key. 4. Không restore đè lên hệ thống nhiễm. 5. Dựng máy sạch từ image tin cậy. 6. Restore từ snapshot/backup trước thời điểm nhiễm. 7. Vá điểm vào trước khi mở lại dịch vụ. 8. Kiểm tra backup immutable còn nguyên.

Lệnh tham khảo:

ss -tunap
ps auxf
last
journalctl -xe
sudo less /var/log/auth.log

10. Checklist triển khai nhanh

Phân quyền

– User riêng cho từng service. – App không chạy root. – Sudo tối thiểu. – ProtectSystem=strict, NoNewPrivileges=true. – Thư mục code read-only với app. – Secrets không nằm trong web root.

Snapshot

– Snapshot trước deploy/update. – Tự động snapshot theo lịch. – Giữ snapshot ngắn hạn. – Test rollback định kỳ. – Snapshot gửi sang host khác nếu có thể.

Immutable backup

– Backup offsite. – Versioning + retention. – Không mount backup RW thường trực. – Credential backup tách khỏi app. – Restore test hàng tháng. – Có bản offline/immutable tối thiểu 14–30 ngày.

Kết luận: mục tiêu không phải “không bao giờ bị”, mà là “bị vẫn sống”

Không có cấu hình nào đảm bảo Ubuntu server miễn nhiễm ransomware. Nhưng bạn có thể khiến attacker khó lan rộng, khó phá backup, và khó buộc bạn trả tiền. Ba trụ cột quan trọng nhất là: phân quyền chặt, snapshot có kiểm soát, immutable backup đã test restore.

Bắt đầu từ việc đơn giản: bỏ root login, tách user app, siết sudo, bật systemd sandbox, tạo snapshot trước thay đổi lớn, đưa backup ra storage immutable. Sau đó lập lịch restore test. Khi sự cố xảy ra, thứ cứu bạn không phải niềm tin vào backup, mà là bằng chứng rằng backup đã từng restore thành công.