Linux Ransomware: Xây dựng Máy chủ 'Bất khả Xâm phạm' trước Mã hóa

Table of Contents

Cảnh báo lúc 2 giờ sáng: Khi các file của bạn bắt đầu thay đổi

2 giờ sáng thứ Ba. Điện thoại của tôi rung lên với cảnh báo PagerDuty: Grafana cho thấy I/O đĩa cứng bị treo ở mức 98% và mức sử dụng CPU chạm ngưỡng 100%. Tôi SSH vào máy chủ production, và độ trễ là không thể chịu nổi. Chạy lệnh ls -la trong thư mục gốc của web làm lộ ra cơn ác mộng: index.php.locked và config.php.crypt. Một file văn bản có tiêu đề README_FOR_DECRYPT.txt nằm ngay trên cùng.

Quay lại năm 2018, tôi đã chứng kiến một máy chủ bị phá nát bởi một cuộc tấn công brute-force vào lúc nửa đêm. Kể từ đó, tôi đã trở nên ám ảnh về bảo mật. Tôi đã có tường lửa, khóa SSH và CrowdSec trên Linux. Nhưng ransomware hiện đại thông minh hơn. Nó không chỉ muốn một chỗ ngồi trong hệ thống; nó muốn bắt toàn bộ ngôi nhà làm con tin. Nếu bạn thấy những phần mở rộng file đã bị mã hóa đó, kẻ tấn công đã vượt qua lớp phòng thủ vòng ngoài và leo thang đặc quyền. Chúng đã ở bên trong rồi.

Nguyên nhân gốc rễ: Tại sao máy chủ Linux dễ bị tấn công

Linux ransomware hiếm khi dựa vào các lỗ hổng zero-day phức tạp. Thay vào đó, nó đi theo một lộ trình dễ đoán đến mức nhàm chán. Nó bắt đầu with một plugin WordPress có lỗ hổng hoặc một thông tin xác thực API bị rò rỉ. Từ đó, kẻ tấn công sử dụng thứ gì đó như lỗ hổng **PwnKit (CVE-2021-4034)** để có quyền truy cập root. Một khi chúng có sudo (thường do không thắt chặt bảo mật Linux Sudoers), chúng sẽ kích hoạt một script lặp qua các điểm mount (mount points), mã hóa mọi cơ sở dữ liệu, file cấu hình và file phương tiện trong tầm mắt.

Thảm họa thực sự xảy ra khi ransomware tìm thấy các bản sao lưu (backups) của bạn. Nếu ổ đĩa sao lưu là một phân vùng cục bộ hoặc một chia sẻ NFS đơn giản với quyền ghi, nó sẽ biến mất. Script sẽ tìm thấy nó trong vài phần nghìn giây. Điều này khiến bạn không còn cơ hội khôi phục và phải đối mặt với một hóa đơn khổng lồ từ những kẻ tấn công.

Chiến lược phòng thủ: Từ sao lưu cơ bản đến lớp giáp Immutable

Hầu hết các đội ngũ xử lý bảo mật Linux theo một trong ba cách sau. Không phải cách nào cũng sống sót sau một cuộc tấn công có mục tiêu.

Sao lưu cục bộ tiêu chuẩn (Cảm giác an toàn giả tạo)

Nhiều admin sử dụng rsync để sao chép dữ liệu sang ổ đĩa nội bộ thứ hai. Điều này bảo vệ bạn nếu một ổ đĩa bị hỏng, nhưng nó vô dụng trước ransomware. Nếu hệ điều hành có thể ghi vào đĩa, ransomware cũng có thể làm điều tương tự. Đơn giản là vậy.

Cloud Snapshots (Khoảng cách 24 giờ)

AWS EBS snapshots hoặc DigitalOcean backups là một bước tiến vì chúng nằm ngoài hệ điều hành. Tuy nhiên, hầu hết các đội ngũ chỉ snapshot 24 giờ một lần. Trong môi trường có lưu lượng truy cập cao, việc mất 23 giờ dữ liệu khách hàng là một sự kiện có thể khiến doanh nghiệp phá sản. Thêm vào đó, nếu bảng điều khiển đám mây (cloud console) của bạn bị xâm nhập, kẻ tấn công sẽ xóa sạch các snapshot trước khi chúng bắt đầu mã hóa.

Cách tiếp cận Immutable (Nền tảng tuyệt đối)

Đây là chiến lược duy nhất thực sự hiệu quả. Chúng ta sử dụng việc thắt chặt bảo mật ở cấp độ hệ thống để đóng băng các file quan trọng và sử dụng lưu trữ offsite có khả năng từ chối lệnh ‘Delete’ (Xóa) hoặc ‘Modify’ (Chỉnh sửa) về mặt vật lý trong một khoảng thời gian nhất định. Ngay cả khi kẻ tấn công có quyền root, chúng cũng không thể chiến thắng.

Bản thiết kế phòng thủ Ransomware tối thượng

Để có thể ngủ ngon hằng đêm, bạn cần một môi trường chủ động chống lại các nỗ lực mã hóa.

1. Thắt chặt hệ thống file với các thuộc tính Immutable

Trên Linux, bạn thực sự có thể hạn chế người dùng root. Sử dụng lệnh chattr (change attribute), bạn có thể thiết lập bit “immutable” (bất biến) trên các file cốt lõi. Điều này ngăn chặn bất kỳ sự sửa đổi, xóa hoặc đổi tên nào — ngay cả bởi superuser.

# Đóng băng các file hệ thống quan trọng
sudo chattr +i /etc/passwd
sudo chattr +i /etc/shadow
sudo chattr +i /etc/fstab

# Để cập nhật các file này, bạn phải bỏ bit immutable thủ công trước
# sudo chattr -i /etc/passwd

Sau khi triển khai (deployment), tôi thiết lập toàn bộ mã nguồn ứng dụng thành immutable. Nếu một lỗ hổng PHP cho phép kẻ tấn công thực thi mã, chúng cũng không thể ghi đè file index.php của bạn bằng phiên bản đã mã hóa. Script của chúng đơn giản là sẽ thất bại with lỗi “Operation not permitted.”

2. Giám sát thời gian thực với Auditd

Ransomware cực kỳ ồn ào. Nó chạm vào hàng nghìn file chỉ trong vài giây. Chúng ta có thể sử dụng Auditd để ứng phó sự cố trên Linux và theo dõi hành vi này. Nếu đạt đến một ngưỡng nhất định, chúng ta sẽ kích hoạt một công tắc ngắt mạng (network kill-switch).

# Cài đặt auditd
sudo apt install auditd -y

# Theo dõi thư mục web để phát hiện bất kỳ thay đổi ghi hoặc thuộc tính nào
sudo auditctl -w /var/www/html -p wa -k web_integrity

Tôi sử dụng một script Python đơn giản để theo dõi (tail) file /var/log/audit/audit.log. Nếu nó phát hiện hơn 50 thay đổi file mỗi giây trong một thư mục nhạy cảm, nó sẽ tự động hạ giao diện mạng xuống (ip link set eth0 down). Bạn có thể mất một chút thời gian hoạt động (uptime), nhưng bạn cứu được dữ liệu của mình nhờ việc giám sát tính toàn vẹn tệp tin.

3. Triển khai sao lưu Offsite Immutable

Đây là mạng lưới an toàn của bạn. Sử dụng **Restic** hoặc **BorgBackup** with một backend tương thích S3 như Wasabi hoặc Backblaze B2 có hỗ trợ “Object Lock.” Một khi bản sao lưu được tải lên ở Chế độ Tuân thủ (Compliance Mode), việc xóa nó là bất khả thi về mặt vật lý cho đến khi thời gian lưu trữ (ví dụ: 30 ngày) hết hạn.

# Ví dụ Restic với backend tương thích S3
export AWS_ACCESS_KEY_ID="access-key"
export AWS_SECRET_ACCESS_KEY="secret-key"
export RESTIC_REPOSITORY="s3:s3.wasabisys.com/my-locked-backups"
export RESTIC_PASSWORD="vault-password"

# Chạy sao lưu
restic backup /var/www/html /etc

# Ngay cả khi kẻ tấn công đánh cắp những khóa này, chúng cũng không thể xóa dữ liệu.
# S3 bucket sẽ từ chối yêu cầu xóa cho đến khi khóa hết hạn.

Khôi phục: Trở lại hoạt động trong vài phút

Nếu điều tồi tệ nhất xảy ra, áp dụng chiến thuật ứng phó sự cố Linux là cách tốt nhất thay vì cố gắng sửa chữa máy chủ đã bị nhiễm mã độc. Nếu bạn có các bản sao lưu immutable, lộ trình rất rõ ràng:

Isolate (Cách ly): Ngắt nguồn điện của VM bị ảnh hưởng ngay lập tức.
Re-provision (Cấp phát lại): Khởi tạo một instance hệ điều hành mới từ một image sạch. Đừng bao giờ tin tưởng một kernel đã bị nhiễm độc.
Restore (Khôi phục): Kéo dữ liệu của bạn từ kho lưu trữ immutable.

# Kéo bản snapshot sạch mới nhất
restic restore latest --target /

Hãy coi máy chủ của bạn là tạm thời (ephemeral) và dữ liệu của bạn là bất biến (immutable). Ransomware chỉ thắng khi bạn không có cách nào để nói “không”. Với việc thắt chặt bảo mật cấp độ file và các S3 bucket được khóa, bạn luôn giữ được chìa khóa vương quốc của mình, bất kể ai có quyền root.