Server bị mã hoá ransomware: quy trình khôi phục từng bước

Khi server bị mã hoá ransomware, việc khôi phục gồm sáu bước: cô lập server mà không phá huỷ bằng chứng, xác định những gì bị ảnh hưởng, tìm ra kẻ tấn công vào bằng đường nào, dựng lại trên server sạch, khôi phục từ backup ngoài server được tạo trước thời điểm bị xâm nhập, và đổi mọi mật khẩu, mọi khoá. Đừng trả tiền chuộc: No More Ransom, dự án có Europol và cảnh sát Hà Lan đứng sau, khuyên không trả vì tiền chuộc nuôi tội phạm và không đảm bảo bạn nhận được khoá giải mã dùng được. Và đừng chỉ xoá file bị mã hoá rồi khôi phục trên chính máy đó, vì kẻ tấn công có thể vẫn đang ở bên trong.

Quy trình này dành cho VPS hoặc server riêng chạy website trên Linux, có hoặc không có control panel. Nếu bạn chưa chắc server có bị xâm nhập hay không, hãy bắt đầu với bài kiểm tra VPS có bị hack không.

Ransomware trên web server trông như thế nào?

Trên web server Linux, ransomware thường là một script hoặc file chạy được thả vào sau khi kẻ tấn công đã có quyền root, không phải file đính kèm email. Dấu hiệu thường gặp:

• file website bị đổi tên với đuôi mới (.psaux, .locked và tương tự), trang web báo lỗi;
• file văn bản hoặc HTML đòi tiền chuộc nằm trong mọi thư mục hoặc thư mục gốc của web;
• database bị dump rồi xoá, đôi khi thay bằng một bảng duy nhất chứa lời nhắn đòi tiền;
• thư mục backup tại chỗ bị mã hoá hoặc bị xoá;
• CPU và ổ đĩa hoạt động rất mạnh, sau đó im lặng.

Ví dụ thật: tháng 10/2024, kẻ tấn công khai thác hai lỗi chèn lệnh nghiêm trọng trong CyberPanel 2.3.6 và bản 2.3.7 chưa vá (CVE-2024-51378 và CVE-2024-51567). Help Net Security đưa tin khoảng 22.000 server lộ ra internet bị tấn công, file bị mã hoá bằng PSAUX và các loại ransomware khác, và LeakIX đã phát hành công cụ giải mã cho biến thể .psaux. Bài các sự cố bảo mật control panel có thêm nhiều trường hợp tương tự.

Tóm tắt các mốc khôi phục

Thời điểm	Mục tiêu	Việc chính
Giờ đầu tiên	Cô lập	Snapshot ở nhà cung cấp, cắt truy cập mạng, giữ server chạy
Giờ 1 đến 4	Hiểu sự cố	Xác định loại ransomware, tìm công cụ giải mã, liệt kê thứ bị mã hoá
Ngày 1	Tìm lối vào	Log, phiên bản panel, CVE đã biết, user mới, SSH key, cron job
Ngày 1 đến 2	Dựng lại	Server mới, phần mềm đã vá, khôi phục từ backup sạch
Ngày 2 đến 3	Đổi khoá và mở lại	Mật khẩu, khoá mới ở mọi nơi, đổi DNS, theo dõi
Tuần sau đó	Rút kinh nghiệm	Ghi lại diễn biến, lấp lỗ hổng về backup và quyền truy cập

Bước 1: cô lập server nhưng giữ lại bằng chứng

Phản xạ đầu tiên sẽ là cài lại hệ điều hành. Hãy kiềm chế trong một giờ.

1. Chụp snapshot ở nhà cung cấp VPS (snapshot ổ đĩa hoặc image). Snapshot giữ lại file bị mã hoá, công cụ của kẻ tấn công và log, những thứ bạn cần để tìm lối vào và có thể để giải mã.
2. Ngắt server khỏi mạng, chỉ chừa IP của bạn. Ở tường lửa cloud của nhà cung cấp, chỉ cho SSH từ địa chỉ của bạn, hoặc dùng console cứu hộ (rescue) của nhà cung cấp. Checklist ứng phó ransomware của CISA đặt việc cô lập hệ thống bị ảnh hưởng lên đầu, và chỉ khuyên tắt máy khi không thể ngắt nó khỏi mạng.
3. Giữ server chạy nếu có thể. Máy đang chạy vẫn còn tiến trình, kết nối mạng và có thể cả khoá trong bộ nhớ. Khởi động lại là mất hết.
4. Chặn thiệt hại ở nơi khác. Nếu kẻ tấn công đã có root, hãy coi như họ có mọi thông tin đăng nhập trên server: khoá S3, mật khẩu database, mật khẩu SMTP relay, API token. Từ một máy tính sạch, đổi ngay những thứ nguy hiểm nhất, bắt đầu từ tài khoản nhà cung cấp lưu trữ và tài khoản nhà cung cấp VPS.

Bước 2: xác định bạn đang đối mặt với gì

• Đọc lời nhắn đòi tiền nhưng chưa liên hệ kẻ tấn công. Ghi lại đuôi file, tên file lời nhắn và địa chỉ liên hệ.
• Tìm công cụ giải mã miễn phí. Tải lời nhắn hoặc một file bị mã hoá lên Crypto Sheriff của No More Ransom. Một số biến thể trên Linux đã từng được giải mã, như trường hợp PSAUX.
• Liệt kê thứ bị ảnh hưởng: file website, database, email, backup tại chỗ, cấu hình panel. Kiểm tra xem còn gì nguyên vẹn, ví dụ database mà script chưa chạm tới.
• Báo cáo sự cố. Ở Mỹ, FBI nhận báo cáo qua IC3; ở nơi khác, liên hệ CERT quốc gia hoặc đơn vị cảnh sát phòng chống tội phạm mạng. Nếu dữ liệu cá nhân của người ở EU bị lộ, GDPR yêu cầu thông báo cho cơ quan giám sát trong vòng 72 giờ kể từ khi biết về sự cố (Điều 33). Hãy kiểm tra quy định áp dụng cho bạn.

Bước 3: tìm xem kẻ tấn công vào bằng đường nào

Khôi phục khi chưa biết lối vào thường là khôi phục vào đúng lỗ hổng cũ. Hãy xem lần lượt:

1. Control panel và phiên bản của nó. So với các thông báo bảo mật và danh mục lỗ hổng đang bị khai thác (KEV) của CISA. Panel mở ra internet có lỗi chạy mã từ xa đã biết là lời giải thích thường gặp cho các vụ tấn công hàng loạt.
2. Đăng nhập SSH: last -F, lastb và journalctl -u ssh (hoặc /var/log/auth.log). Tìm đăng nhập từ IP lạ và vào giờ bất thường.
3. Log web quanh thời điểm file đầu tiên bị mã hoá: request POST tới file PHP lạ, endpoint của panel hoặc chỗ upload.
4. Cơ chế bám trụ: user mới, ~/.ssh/authorized_keys, cron job, unit và timer của systemd. Các lệnh cụ thể có trong bài kiểm tra VPS có bị hack không.

Ghi lại bạn tìm thấy gì và vào lúc nào. Điều đó quyết định backup nào an toàn và cần sửa gì trước khi chạy lại.

Bước 4: dựng lại, đừng dọn dẹp

Một khi kẻ tấn công đã có root, bạn không thể chứng minh hệ thống còn sạch: chương trình, thư viện, thậm chí kernel có thể đã bị sửa. Câu trả lời an toàn là một server mới:

• tạo VPS mới, tốt nhất với IP mới;
• cài hệ điều hành hiện hành còn được hỗ trợ và bản panel đã vá;
• giới hạn SSH và cổng panel cho IP của bạn ngay từ phút đầu;
• chỉ sau đó mới khôi phục dữ liệu, không bao giờ khôi phục file hệ thống, từ server cũ.

Giữ snapshot của server cũ để điều tra, nhưng đừng chép chương trình, cron job hay file cấu hình từ đó sang trừ khi bạn đã đọc từng dòng.

Bước 5: khôi phục từ backup được tạo trước khi bị xâm nhập

Chọn điểm khôi phục cẩn thận. Backup đúng là bản cuối cùng trước khi kẻ tấn công vào được, không phải bản cuối cùng trước khi bị mã hoá. Kẻ tấn công có thể chờ nhiều ngày giữa lúc xâm nhập và lúc chạy ransomware, và backup trong khoảng đó có thể chứa backdoor của họ.

Kiểm tra bản backup có sạch và đầy đủ không: mở thử vài file, kiểm tra database nhập được, và quét mã độc trên file đã khôi phục trước khi đổi DNS.

Khôi phục một server ZoPanel

Quy trình khôi phục thảm hoạ của ZoPanel được làm cho đúng tình huống này. Bạn cần thông tin S3, khoá khôi phục (recovery key) và một server mới cùng họ hệ điều hành:

1. Cài ZoPanel lên server mới.
2. Ở Settings → Remote backups, kết nối đúng bucket và tiền tố thư mục cũ. Dùng access key mới nếu key cũ từng nằm trên server bị xâm nhập.
3. Ở Backups → Disaster recovery → Browse S3, mở thư mục của server cũ, rồi _panel, và Restore configuration từ file .zpb có ngày trước khi bị xâm nhập. Nhập khoá khôi phục.
4. Khôi phục từng tài khoản từ backup của nó trong cùng màn hình. Tài khoản chưa có sẽ được tạo lại cùng website, database, hộp thư và DNS.
5. Đặt tên miền panel, đổi DNS sang server mới, để chứng chỉ được cấp lại.

Hai giới hạn cần biết trước. Dữ liệu ứng dụng App Store và bucket S3 storage không nằm trong backup tài khoản hay backup từ xa: chúng được backup vào /var/backups/zopanel-apps trên server, nên nếu bạn chưa chép thư mục đó ra nơi khác, nó mất cùng server. Và nếu không có khoá khôi phục, không ai đọc được các bản mã hoá trên S3, nên khoá phải được cất ngoài server. Tài liệu backup giải thích từng loại backup và thời gian lưu giữ.

Bước 6: đổi mọi khoá bí mật rồi mở lại

Hãy coi mọi thứ đọc được trên server cũ đã nằm trong tay kẻ tấn công:

• SSH key và mật khẩu của mọi quản trị viên, key mới tạo trên máy sạch;
• mật khẩu panel và 2FA (đăng ký lại), API token và token của hệ thống billing;
• mật khẩu database, rồi cập nhật cấu hình ứng dụng;
• security key và mật khẩu admin WordPress, để mọi phiên đăng nhập kết thúc;
• thông tin đăng nhập S3, SMTP relay, nhà cung cấp DNS và cổng thanh toán;
• khoá DKIM nếu muốn kỹ lưỡng.

Sau đó đổi DNS, theo dõi log sát sao trong một tuần, và thông báo cho khách hàng chuyện gì đã xảy ra và họ cần làm gì, chẳng hạn đổi mật khẩu của chính họ. Với khách Việt Nam, một tin nhắn Zalo hoặc email ngắn gọn, rõ ràng thường được đón nhận tốt hơn im lặng.

Để lần ransomware sau không thành thảm hoạ

Lỗ hổng	Cách khắc phục
Backup chỉ nằm trên cùng server	Bản sao ngoài server, xem chiến lược backup website 3-2-1
Backup ngoài server xoá được bằng khoá lưu trên server	Bật versioning hoặc S3 Object Lock phía lưu trữ, để các phiên bản đã tải lên không xoá được trong thời gian lưu giữ
Panel mở ra internet	Danh sách IP cho phép, VPN hoặc SSH tunnel
Panel chạy bằng root	Panel có tách quyền, để một lỗi web không bằng quyền root
SSH đăng nhập bằng mật khẩu	Chỉ dùng key, có Fail2ban
Chưa từng thử khôi phục	Mỗi quý khôi phục thử một tài khoản lên server phụ
Khoá khôi phục chỉ nằm trên server	Lưu trong trình quản lý mật khẩu hoặc giấy, ngoài server

Bảo vệ phía lưu trữ quan trọng vì chính server tải backup lên cũng giữ khoá để xoá chúng. Object Lock ở chế độ compliance, theo AWS, nghĩa là một phiên bản bị khoá không thể bị ghi đè hay xoá bởi bất kỳ ai, kể cả tài khoản root, cho đến hết thời gian lưu giữ. Tài liệu ZoPanel chưa đề cập Object Lock, nên nếu bật ở nhà cung cấp, hãy kiểm tra việc tải lên và dọn bản cũ vẫn chạy như bạn mong đợi.

Kết luận

Khôi phục khi server bị mã hoá ransomware phần lớn được quyết định trước khi bị tấn công: bạn có backup mà kẻ tấn công không với tới không, có giữ khoá khôi phục không, và đã tập khôi phục chưa. Đến ngày xảy ra sự cố, hãy cô lập trước, tìm lối vào, dựng server sạch, khôi phục từ trước thời điểm xâm nhập và đổi mọi khoá bí mật.

Nếu bạn muốn quy trình khôi phục này có sẵn, gói Free của ZoPanel cho bạn dùng thử với 3 tài khoản hosting và 10 website, không giới hạn thời gian; backup từ xa có mã hoá và luồng khôi phục từ S3 đi kèm gói Pro. Xem tính năng backup để biết những gì được bảo vệ.

Câu hỏi thường gặp

Có nên trả tiền chuộc để lấy lại website không?

Cơ quan thực thi pháp luật và No More Ransom khuyên không nên: tiền chuộc nuôi các vụ tấn công tiếp theo và không có gì đảm bảo bạn nhận được khoá dùng được. Hãy tìm công cụ giải mã miễn phí trước và khôi phục từ backup nếu có.

Có thể khôi phục backup ngay trên server cũ không?

Không an toàn. Nếu kẻ tấn công đã có root, họ có thể để lại backdoor, sửa chương trình hệ thống hoặc thêm SSH key, và có thể mã hoá lại file bạn vừa khôi phục. Hãy dựng server mới và chỉ khôi phục dữ liệu.

Kẻ tấn công đưa ransomware vào web server Linux bằng cách nào?

Các đường phổ biến là một ứng dụng mở ra internet chưa vá, như control panel hoặc plugin CMS có lỗi chạy mã từ xa, hoặc mật khẩu SSH và panel bị lộ, bị đoán. Khi đã có root, bản thân việc mã hoá chỉ mất vài phút.

Ransomware có mã hoá cả backup trên S3 không?

Nó có thể xoá hoặc ghi đè nếu server giữ khoá có quyền làm việc đó. Hãy dùng khoá chỉ giới hạn trong một bucket, và bật versioning hoặc object lock ở nhà cung cấp lưu trữ để các phiên bản cũ còn sống sót.

Khôi phục web server sau ransomware mất bao lâu?

Có backup ngoài server và quy trình đã tập, một server nhỏ có thể chạy lại sau vài giờ. Không có chúng, có thể mất nhiều ngày và một phần dữ liệu không bao giờ lấy lại được. Phần điều tra tìm lối vào thường là phần lâu nhất.