Cách xử lý VPS bị hack an toàn và hiệu quả nhất

Đừng cố làm sạch VPS đã bị hack

Nếu VPS của bạn bị hack, quyết định quan trọng nhất cần đưa ra trước khi bạn chạy bất kỳ lệnh nào. Đừng cố làm sạch máy chủ đó. Hãy cô lập nó tại nhà cung cấp, snapshot ổ đĩa để làm bằng chứng, thay đổi mọi thông tin xác thực mà nó từng lưu trữ, sau đó rebuild trên một máy chủ mới từ các nguồn mà bạn tin tưởng.

Bạn không thể chứng minh một rootkit đã bị loại bỏ, vì các công cụ dùng để chứng minh điều đó chính là những công cụ mà kẻ tấn công đang kiểm soát.

Đó là toàn bộ lập luận. Đây là cơ chế đằng sau nó. Một kẻ tấn công đã chiếm được quyền root có thể thay thế ps để một ID tiến trình không bao giờ xuất hiện trong kết quả đầu ra. Một dòng trong /etc/ld.so.preload sẽ nạp mã độc của kẻ tấn công vào mọi chương trình liên kết động trên máy, vì vậy ls, ss và find đều báo cáo sai lệch một cách nhất quán. Một module kernel có thể tải được (loadable kernel module) có thể ẩn các file ngay dưới tầng system call, nên ngay cả một binary mới tải về cũng thấy ổ đĩa sạch sẽ. Bạn xóa trình đào coin, biểu đồ CPU giảm xuống và máy chủ trở nên yên tĩnh. Yên tĩnh cũng chính là trạng thái của một backdoor đang hoạt động.

Việc rebuild tốn ít chi phí hơn bạn nghĩ. Một VPS thông thường chỉ gồm một vài gói phần mềm, một thư mục cấu hình và một tập dữ liệu, vì vậy rebuild là một công việc hữu hạn và có điểm kết thúc. Việc truy tìm mọi thay đổi mà kẻ tấn công đã thực hiện là một công việc không có hồi kết và không bao giờ đạt được sự chắc chắn.

Xác nhận máy chủ thực sự bị xâm nhập

Nhiều máy chủ được báo cáo là bị hack thực tế không phải vậy. Hàng ngàn lần đăng nhập SSH thất bại mỗi ngày chỉ là nhiễu nền của Internet, vì mọi địa chỉ IPv4 công cộng đều bị quét liên tục. Một đầu ra lastb đầy rẫy các nỗ lực root và admin chỉ có nghĩa là các trình quét đã tìm thấy cổng của bạn. Nó không có nghĩa là có ai đó đã truy cập được vào máy.

Những dấu hiệu sau đây mới thực sự đáng lo ngại:

• Một lần đăng nhập thành công mà bạn không thực hiện, ví dụ như Accepted password for root from 203.0.113.7.
• Một key trong authorized_keys mà bạn không hề thêm vào.
• Thông báo lạm dụng từ nhà cung cấp VPS về lưu lượng truy cập đi ra từ máy chủ của bạn.
• Một tiến trình chiếm 100% CPU mang tên giống với một kernel thread. Các trình đào tiền ảo được cài qua các socket Redis và Docker bị lộ thường xuất hiện dưới các tên như kdevtmpfsi và kinsing.
• Các kết nối đi ra ngoài đến những địa chỉ mà không dịch vụ nào của bạn sử dụng.

Việc giả dạng kernel thread có một bài kiểm tra nhanh. Các kernel thread thực sự sẽ hiển thị trong dấu ngoặc vuông và không có file thực thi đằng sau chúng, vì vậy sudo ls -l /proc/<pid>/exe sẽ thất bại với chúng kèm theo No such file or directory. Nếu một tiến trình hiển thị là [kworker/0:2] có liên kết exe trỏ đến một vị trí trong /tmp, đó là một chương trình người dùng bình thường đang mạo danh tên kernel.

Hãy thực hiện các kiểm tra này với ý thức rằng hệ thống có thể đang đánh lừa bạn. Chúng đủ để xác định có điều gì đó không ổn. Chúng không đủ để khẳng định rằng hệ thống hoàn toàn an toàn.

Ngắt mạng tại nhà cung cấp, không phải từ bên trong máy chủ

Cách ly là ưu tiên hàng đầu, vì mọi bước sau đó đều vô nghĩa khi kẻ khác vẫn đang nắm quyền truy cập shell. Việc đọc log, thay đổi key và khôi phục dữ liệu đều vô ích khi một kẻ tấn công vẫn đang theo dõi trực tiếp.

Hãy thực hiện việc này trong bảng điều khiển của nhà cung cấp, tại firewall mạng chạy bên ngoài hệ điều hành của bạn. Chặn toàn bộ lưu lượng inbound và outbound, và chỉ giữ lại web console làm lối vào. Các quy tắc được áp dụng tại đó sẽ không bị ảnh hưởng bởi bất kỳ sự cố nào trên ổ đĩa.

Có hai lý do không nên thực hiện việc này từ bên trong máy chủ. Một firewall bạn cấu hình bên trong kernel đã bị xâm nhập sẽ bị chính kernel đó thực thi, và root có thể xóa sạch nftables dễ dàng như cách bạn viết nó. Ngoài ra, sudo ip link set enp1s0 down qua SSH sẽ ngắt phiên làm việc của chính bạn trước, khiến bạn bị khóa khỏi máy chủ ngay khi đang kiểm tra.

Hãy chặn cả outbound lẫn inbound. Một reverse shell sẽ kết nối từ máy của bạn ra ngoài tới kẻ tấn công, vì vậy nếu chỉ chặn inbound thì kết nối đã thiết lập vẫn hoạt động bình thường. Nếu nhà cung cấp của bạn chỉ cung cấp quy tắc inbound, các lựa chọn còn lại là ngắt kết nối network interface hoặc tắt nguồn instance.

Đừng reboot vội. Hãy kiểm tra xem /var/log/journal có tồn tại hay không trước. Nếu thư mục đó không có, journald đang ghi vào /run/log/journal, vốn nằm trên bộ nhớ RAM, nên reboot sẽ xóa sạch hồ sơ về vụ xâm nhập. Các tiến trình đang chạy cũng sẽ biến mất khi reboot, và dòng lệnh khởi chạy của chúng thường là bằng chứng rõ ràng nhất mà bạn có thể thu thập được.

Snapshot ổ đĩa trước khi thực hiện bất kỳ thao tác nào

Snapshot và backup có vai trò khác nhau trong trường hợp này. Snapshot bạn thực hiện ngay bây giờ là bản sao của ổ đĩa đã bị xâm nhập: đây là bằng chứng của bạn, và là thứ duy nhất cho phép bạn quay lại trạng thái cũ nếu lỡ tay ghi đè dữ liệu. Các bản backup cũ hơn mới là lộ trình khôi phục chính. Nếu bảng điều khiển của nhà cung cấp dùng hai từ này một cách tùy tiện, hãy đọc cách snapshot VPS khác với backup thực sự trước, vì quy tắc lưu trữ và hành vi khôi phục của chúng không giống nhau.

Hãy thực hiện snapshot từ bảng điều khiển của nhà cung cấp trước khi bạn đăng nhập lại. Một snapshot trực tiếp (live snapshot) có tính nhất quán khi crash (crash consistent): nó ghi lại ổ đĩa tại đúng thời điểm đó, giống như việc rút nguồn điện đột ngột. Điều này hoàn toàn ổn để làm bằng chứng. Hãy đặt tên để không ai khôi phục nhầm nó. Một cái tên trực diện như COMPROMISED-do-not-restore-2026-08-12 là mức độ rõ ràng cần thiết. Hãy giữ nó cho đến khi quá trình điều tra kết thúc và mọi ticket khiếu nại với nhà cung cấp dịch vụ của bạn đã được đóng.

Cách truy cập khi mất kết nối SSH

Có hai hướng xử lý, cả hai đều thực hiện trong bảng điều khiển của nhà cung cấp. Web console (VNC hoặc serial) kết nối vào máy chủ như thể bạn đang cắm trực tiếp bàn phím. Nó hoạt động ngay cả khi sshd bị chết, firewall cấu hình sai hoặc kẻ tấn công đã đổi cổng SSH. Nó xác thực bằng mật khẩu cục bộ, vì vậy nếu máy chủ chỉ dùng key, bạn có thể cần reset mật khẩu root trước khi console có tác dụng.

Rescue mode là lựa chọn tốt hơn. Nó khởi động một hệ thống live nhỏ với ổ đĩa của bạn được gắn vào nhưng không chạy, vì vậy các lệnh của bạn đáng tin cậy: kernel và các binary bị xâm nhập không được thực thi. Hãy mount ổ đĩa ở chế độ chỉ đọc (read-only).

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

Nếu lsblk hiển thị các volume LVM (logical volume manager) thay vì phân vùng thông thường, hãy kích hoạt chúng bằng sudo vgchange -ay trước, sau đó mount thiết bị xuất hiện dưới /dev/mapper/.

Đừng chroot vào ổ đĩa đã mount để kiểm tra. Một lệnh chroot sẽ thực thi các binary của kẻ tấn công với quyền của bạn, điều này làm mất đi toàn bộ mục đích của việc khởi động vào rescue mode.

Thu thập bằng chứng vẫn còn đáng tin cậy

Chạy các lệnh này từ chế độ rescue, với đĩa được mount ở chế độ chỉ đọc tại /mnt/victim. Bắt đầu với các thông tin đăng nhập, vì chúng xác định thời điểm xâm nhập, và mọi thứ khác sẽ dễ dàng hơn khi bạn đã có một khoảng thời gian cụ thể.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

Việc thiếu /var/log/auth.log không hẳn là đáng ngờ. Một số image Ubuntu hiện tại được phát hành mà không có rsyslog, nên sshd chỉ ghi log vào journal, đó là lý do dòng journalctl -D đọc dữ liệu này. Điều đáng lưu ý là khoảng trống trong các log vốn liên tục, hoặc file log bị cắt về 0 byte. Việc xóa log rất phổ biến và thường để lại dấu vết vụng về.

Tiếp theo là các tài khoản và khóa.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

Dòng awk in ra mọi tài khoản có user ID là 0. Bất kỳ kết quả nào khác ngoài root trong đầu ra đó đều là một tài khoản root thứ hai. Mẫu find cố tình khớp với cả authorized_keys2, vì OpenSSH mặc định đọc cả hai tên file này và file thứ hai rất dễ bị bỏ qua. Nếu lsattr in ra i trong danh sách thuộc tính, file đó là bất biến (immutable): kẻ tấn công đặt flag này để lệnh xóa khóa của bạn thất bại với thông báo Operation not permitted, và một quản trị viên mệt mỏi sẽ lầm tưởng rằng việc chỉnh sửa đã thành công.

Sự tồn tại dai dẳng (persistence) thường ẩn nấp ở một số ít vị trí, vì vậy hãy kiểm tra tất cả chúng.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

/etc/ld.so.preload không tồn tại trên một hệ thống Ubuntu hoặc Debian bình thường, vì vậy No such file or directory là kết quả bình thường và bất kỳ nội dung nào ở đó cũng xứng đáng để bạn chú ý. Một file login mà pipe đầu ra của base64 -d vào một shell cũng tương tự: cấu hình hợp lệ không cần phải ẩn giấu nội dung của chính nó.

Xây dựng dòng thời gian dựa trên thời gian thay đổi (change time) thay vì thời gian sửa đổi (modification time).

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch đặt thời gian sửa đổi thành bất kỳ giá trị nào kẻ tấn công muốn, vì vậy mtime là thông tin không đáng tin. Thời gian thay đổi (ctime) cập nhật mỗi khi inode thay đổi, và touch không thể đẩy lùi nó, vì vậy -newerct cung cấp danh sách trung thực hơn về những gì đã được ghi gần đây. Đây vẫn chưa phải là bằng chứng tuyệt đối, vì root có thể thay đổi đồng hồ hệ thống hoặc ghi trực tiếp vào block device.

Tính toàn vẹn của gói phần mềm chỉ cần một lệnh và một lưu ý. Trên một hệ thống đang chạy, sudo dpkg --verify in ra một dòng cho mỗi file đã đóng gói có checksum không còn khớp, với ký hiệu 5 ở cột checksum, và sudo debsums -ac thực hiện công việc tương tự bao gồm cả các file cấu hình khi gói debsums được cài đặt. Chỉ đọc kết quả theo một hướng. Một file /usr/sbin/sshd bị thay đổi là bằng chứng thực sự. Một báo cáo sạch không chứng minh được gì, vì chính tài khoản root đã thay thế binary đó cũng có thể ghi đè lên các danh sách checksum nằm dưới /var/lib/dpkg/info/. Các trình quét rootkit như rkhunter và chkrootkit cũng tuân theo quy tắc tương tự: nếu phát hiện ra gì đó thì đó là thông tin, còn nếu chạy xong mà không thấy gì thì không có nghĩa là hệ thống an toàn.

Sao chép những gì bạn đã thu thập ra khỏi máy trước khi thực hiện bất kỳ thao tác phá hủy nào.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

Ghi lại hash đó ở một nơi nào đó bên ngoài server. Nếu việc này trở thành một yêu cầu bảo hiểm hoặc báo cáo cảnh sát, khả năng chứng minh archive không bị thay đổi kể từ khi thu thập chính là sự khác biệt giữa bằng chứng và một thư mục chứa các file thông thường. Việc vô tình xóa mất dữ liệu trong quá trình điều tra là chuyện bình thường, và bản snapshot cùng với archive này là thứ giúp bạn sống sót. Việc hoàn tác một lệnh rm sai lầm sau đó khó hơn nhiều so với mọi người tưởng, như bài khôi phục file bị xóa bằng rm -rf đã giải thích.

Tìm lối vào mà kẻ tấn công đã sử dụng

Việc cài đặt lại hệ thống mà không đóng lối vào sẽ khiến bạn bị tấn công lần nữa, thường là trong vài ngày, vì các trình quét tìm lỗ hổng vẫn luôn hoạt động. Bốn lối vào dưới đây chiếm đa số các vụ xâm nhập máy chủ đơn lẻ.

Đăng nhập SSH bằng mật khẩu. Một dòng Accepted password for root từ một địa chỉ IP lạ là câu trả lời rõ ràng nhất. Hãy kiểm tra PasswordAuthentication trong /etc/ssh/sshd_config và trong mọi file nằm dưới thư mục /etc/ssh/sshd_config.d/. sshd sử dụng giá trị đầu tiên mà nó nhận được cho một từ khóa, và dòng Include nằm ở đầu file cấu hình chính trên Ubuntu, vì vậy một file cấu hình được thêm vào sẽ ghi đè lên thiết lập mà bạn đã chỉnh sửa ở phía dưới.

Dịch vụ được công khai mà không có xác thực. Redis trên cổng 6379, Docker API trên cổng 2375, hoặc database bind vào 0.0.0.0 thay vì 127.0.0.1. Docker thường là nguyên nhân gây bất ngờ. Việc publish một cổng container sẽ chèn các quy tắc DNAT (destination network address translation) được đánh giá trước cả các chain của ufw, vì vậy ufw status có thể báo cáo một cổng là đã bị chặn trong khi container phía sau nó vẫn phản hồi toàn bộ Internet. Hãy hiểu rõ điều này trước khi cài đặt lại: tại sao các cổng được publish bởi Docker lại bỏ qua ufw giải thích về thứ tự quy tắc và cách khắc phục.

Ứng dụng web chưa được vá lỗi. Hãy tìm trong access log của web server xung quanh mốc thời gian đáng ngờ sớm nhất của bạn để xem có yêu cầu POST nào gửi đến đường dẫn upload hoặc đường dẫn quản trị hay không, sau đó tìm các file nằm dưới web root có thời gian thay đổi tương ứng. Một file PHP lạ nằm trong thư mục uploads là kết quả điển hình.

Thông tin xác thực bị lộ. Một key bị commit vào repository, một token bị dán vào khung chat, hoặc một file .env bị web server cấu hình sai phục vụ như một file tĩnh. Tự động hóa khiến việc này dễ xảy ra ngoài ý muốn, đó là lý do tại sao cần giữ các bí mật tránh xa các AI agent và file cấu hình của chúng.

Nếu bạn không thể xác định được lối vào sau khi đã kiểm tra tất cả những điều trên, hãy giả định rằng thông tin xác thực đã bị lộ và coi mọi bí mật mà máy chủ đó lưu giữ đều đã bị công khai.

Thay đổi toàn bộ thông tin xác thực mà máy chủ có thể truy cập

Chỉ thực hiện thay đổi sau khi đã ngắt kết nối mạng, tuyệt đối không làm trước đó. Việc thay đổi khi kẻ tấn công vẫn còn kết nối chỉ đơn thuần là cung cấp cho chúng các bí mật mới.

• Mọi SSH private key được lưu trên máy chủ, cùng với mọi tài khoản ở nơi khác tin tưởng public key tương ứng.
• Bất kỳ key nào bạn đã forward vào máy thông qua ssh -A. Agent forwarding để lại một socket tại /tmp, và quyền root trên máy đó có thể sử dụng nó để xác thực dưới danh nghĩa của bạn ở bất cứ đâu chấp nhận key của bạn, miễn là phiên làm việc của bạn vẫn còn mở.
• API token trong các file .env, trong các dòng Environment= của systemd, trong cấu hình CI và trong thông tin xác thực của nhà cung cấp.
• Mật khẩu cơ sở dữ liệu và các tài khoản ứng dụng sử dụng chúng.
• Các TLS (transport layer security) private key mà máy chủ đang giữ. Hãy cấp lại chứng chỉ và thu hồi chứng chỉ cũ.
• Mật khẩu tài khoản hosting của bạn, kèm theo việc bật xác thực hai yếu tố. Bảng điều khiển đó có thể rebuild, snapshot và truy cập console vào mọi máy chủ bạn sở hữu, vì vậy đó mới là vành đai bảo mật thực sự.
• Bất kỳ mật khẩu nào đã được nhập vào shell session trên máy chủ đó trong khi nó bị xâm nhập, vì quyền root có thể ghi lại phiên terminal ngay khi nó diễn ra.

Nếu một mật khẩu trên máy đó được sử dụng ở bất kỳ nơi nào khác, hãy thay đổi nó ở cả những nơi đó. Việc tái sử dụng mật khẩu là cách một VPS bị xâm nhập trở thành một tài khoản email bị xâm nhập.

Danh sách kiểm tra khi xây dựng lại hệ thống

1. Tạo một server mới từ image phân phối sạch. Không dùng snapshot của máy chủ đã bị xâm nhập, và không khôi phục từ bản sao lưu toàn bộ root filesystem.
2. Cài đặt các gói phần mềm từ kho lưu trữ của bản phân phối. Tuyệt đối không sao chép file binary từ ổ đĩa cũ sang.
3. Chỉ khôi phục dữ liệu từ bản sao lưu có ngày trước thời điểm sớm nhất xuất hiện trong dòng thời gian sự cố của bạn. Các bản dump cơ sở dữ liệu, file tải lên, trạng thái ứng dụng. Hãy bỏ lại /etc, /usr và các file unit cũ.
4. Nhập thủ công các secret đã được xoay vòng. Không sao chép .env cũ sang.
5. Kiểm tra nội dung web đã khôi phục để tìm các file được thêm vào trong khoảng thời gian bị xâm nhập trước khi cho phép truy cập lại.
6. Củng cố bảo mật trước khi đưa ra public: chỉ dùng SSH key, tạo một tài khoản làm việc không phải root, thiết lập firewall chặn tất cả kết nối đến theo mặc định, và không công khai dịch vụ rộng hơn mức cần thiết. Hãy thực hiện theo mười phút đầu tiên trên VPS mới, sau đó cấu hình SSH an toàn, rồi thêm fail2ban trên Ubuntu 24.04 để giảm nhiễu đăng nhập. Cấp cho mỗi dịch vụ tài khoản với quyền hạn tối thiểu riêng để nếu bị chiếm quyền lần sau, kẻ tấn công cũng không thể chiếm được quyền root.
7. Tắt server cũ và giữ lại snapshot của nó cho đến khi quá trình điều tra và mọi ticket về lạm dụng hệ thống được đóng lại.
8. Sửa lại quy trình sao lưu. Nếu bước 3 chỉ là phỏng đoán, bài học thực sự là lịch sử sao lưu của bạn quá ngắn để quay ngược về trước thời điểm bị xâm nhập. Các bản sao lưu có phiên bản, lưu trữ ngoài server với thời gian giữ lại dài là thứ giúp bạn có điểm khôi phục sạch cho lần sau: sao lưu bằng restic trên VPS cung cấp cho bạn cả hai yếu tố đó.

Nếu bạn không xác định được thời điểm bị xâm nhập, bạn không thể chọn bản sao lưu an toàn. Trong trường hợp đó, chỉ khôi phục dữ liệu mà bạn có thể kiểm tra bằng mắt thường: một bản dump SQL bạn có thể đọc được, một thư mục chứa ảnh bạn có thể liệt kê. Hãy coi mọi thứ có thể thực thi là đáng ngờ và cài đặt lại chúng từ các kho lưu trữ.

Ý nghĩa của thông báo lạm dụng từ nhà cung cấp dịch vụ

Hầu hết mọi người biết máy chủ của mình bị xâm nhập từ nhà cung cấp, không phải từ hệ thống giám sát của chính họ. Các nhà cung cấp nhìn thấy lưu lượng outbound: tấn công SSH brute force vào các mạng khác, spam trên cổng 25, hoặc tham gia vào một cuộc tấn công phản xạ (reflection attack). Ticket thường chứa dấu thời gian, các cổng và mẫu lưu lượng, kèm theo thời hạn tính bằng giờ.

Hãy phản hồi lại, ngay cả khi câu trả lời duy nhất của bạn là máy chủ đã bị cô lập và đang được xây dựng lại. Các nhà cung cấp sẽ null-route hoặc tạm ngưng máy chủ khi ticket không được phản hồi, điều này biến sự cố của bạn thành một tình trạng ngừng hoạt động (outage). Sau đó, hãy yêu cầu các dòng log thô đằng sau báo cáo đó. Những dấu thời gian đó được ghi lại bên ngoài máy của bạn, vì vậy chúng là phần duy nhất của dòng thời gian mà kẻ tấn công không thể chỉnh sửa, và chúng thường xác định thời điểm xâm nhập chính xác hơn bất kỳ thứ gì trên ổ đĩa.

Một máy chủ khách hàng bị xâm nhập là công việc thường ngày đối với nhà cung cấp, và việc xử lý tốt sự cố sẽ không gây bất lợi cho bạn. Câu hỏi rộng hơn về liệu VPS hosting có an toàn không chủ yếu phụ thuộc vào cách khách hàng cấu hình, đó chính xác là phần bạn sẽ phải thực hiện lại từ đầu.

Khi nào cần gọi chuyên gia

• Máy chủ chứa dữ liệu cá nhân của người khác. Theo GDPR (Quy định chung về bảo vệ dữ liệu), vi phạm dữ liệu cá nhân phải được báo cáo cho cơ quan giám sát mà không được chậm trễ, và trong vòng 72 giờ kể từ khi phát hiện nếu khả thi. Việc xác định thời điểm bắt đầu tính giờ là công việc pháp lý, không phải việc của sysadmin.
• Dữ liệu thẻ thanh toán nằm trong phạm vi bị ảnh hưởng. Các tổ chức thẻ yêu cầu điều tra viên pháp y được phê duyệt, và việc bạn tự ý can thiệp có thể làm hỏng bằng chứng.
• Có yêu cầu tống tiền, hoặc dữ liệu của bạn đã bị mã hóa.
• Máy chủ có thể kết nối với các máy khác: mạng nội bộ, hypervisor, hoặc CI runner đang giữ credential môi trường production. Một host bị xâm nhập trong nhóm được coi là sự cố toàn hệ thống cho đến khi có bằng chứng ngược lại.
• Bạn cần bằng chứng để làm việc với bảo hiểm hoặc cơ quan thực thi pháp luật. Hãy dừng lại ở bước snapshot, tạo bản sao toàn bộ ổ đĩa (disk image), và ghi lại ai đã xử lý nó và vào thời điểm nào.

Đối với một VPS đơn lẻ chạy các dịch vụ của riêng bạn, không chứa dữ liệu của người khác, quy trình trên là toàn bộ công việc cần làm. Cô lập tại nhà cung cấp. Snapshot để lấy bằng chứng. Thu thập những gì vẫn còn tin cậy được. Thay đổi toàn bộ credential. Cài đặt lại từ đầu.

FAQ

Tôi có thể làm sạch một VPS bị hack thay vì cài lại từ đầu không?

Không thể làm điều đó với sự tin tưởng tuyệt đối, vì bạn đang yêu cầu một hệ thống đã bị xâm nhập tự báo cáo về chính nó. Một ps bị thay thế có thể ẩn tiến trình, một dòng trong /etc/ld.so.preload có thể chèn mã độc vào mọi công cụ liên kết động mà bạn chạy, và một kernel module có thể ẩn file khỏi mọi chương trình cùng lúc. Bạn có thể tìm thấy các dấu vết, nên nếu thấy kết quả dương tính thì đó là bằng chứng xác thực. Bạn không thể chứng minh sự vắng mặt của mã độc, nên kết quả "sạch" không có ý nghĩa gì cả. Việc làm sạch chỉ có thể chấp nhận được khi máy chủ không chứa dữ liệu quan trọng và bạn chấp nhận rủi ro nó có thể bị xâm nhập lại.

Tôi nên tắt nguồn máy chủ bị xâm nhập hay để nó tiếp tục chạy?

Trước tiên hãy ngắt kết nối mạng tại nhà cung cấp, sau đó để nó chạy đủ lâu để chụp snapshot và kiểm tra các tiến trình đang chạy. Việc tắt nguồn sẽ làm mất danh sách tiến trình và xóa sạch journal nếu /var/log/journal không tồn tại, vì khi đó journald sẽ ghi log vào bộ nhớ dưới /run. Tuy nhiên, hãy tắt nguồn ngay nếu nó đang chủ động tấn công các mạng khác và bạn không có cách nào chặn lưu lượng outbound của nó. Việc ngăn chặn thiệt hại quan trọng hơn việc giữ lại bằng chứng.

Làm thế nào để xác định thời điểm kẻ tấn công xâm nhập?

Tìm dòng Accepted password hoặc Accepted publickey sớm nhất mà bạn không thể giải thích được trong /var/log/auth.log hoặc trong journal. Đối chiếu nó với danh sách thời gian thay đổi, find / -xdev -newerct 'YYYY-MM-DD' -type f, vì ctime khó làm giả hơn mtime. Sau đó so sánh cả hai với các mốc thời gian trong thông báo lạm dụng (abuse ticket) từ nhà cung cấp của bạn, vì chúng được ghi lại bên ngoài máy chủ và không thể bị chỉnh sửa. Chọn một bản backup cũ hơn thời điểm sớm nhất trong ba nguồn trên. Nếu không có gì khớp, hãy giả định rằng vụ xâm nhập đã xảy ra trước cả lịch sử backup của bạn và chỉ khôi phục dữ liệu mà bạn có thể kiểm tra được.

Các bản backup của tôi có an toàn để khôi phục sau khi bị xâm nhập không?

Dữ liệu thường là an toàn nếu được kiểm tra kỹ. Các file hệ thống thì không. Một bản backup được thực hiện sau khi bị xâm nhập sẽ chứa backdoor, vì vậy việc khôi phục toàn bộ root filesystem cũng đồng nghĩa với việc khôi phục lại kẻ tấn công. Hãy kiểm tra cả kho lưu trữ backup: nếu thông tin đăng nhập cho kho lưu trữ đó được lưu trên máy chủ bị xâm nhập, lịch sử có thể đã bị xóa hoặc thay đổi. Đây là lý do tại sao nên dùng các đích backup chỉ cho phép ghi (append-only) hoặc theo cơ chế kéo (pull-based). Hãy khôi phục dữ liệu ứng dụng, sau đó cài đặt lại phần mềm từ các kho lưu trữ của bản phân phối.

Tôi có bắt buộc phải thông báo cho ai đó rằng VPS của tôi bị xâm nhập không?

Luôn phản hồi thông báo lạm dụng từ nhà cung cấp của bạn. Ngoài ra, việc này phụ thuộc vào dữ liệu của ai đang nằm trên máy chủ. Dữ liệu cá nhân của người khác có thể kích hoạt nghĩa vụ báo cáo pháp lý, ví dụ như quy định thông báo trong 72 giờ cho cơ quan quản lý theo GDPR. Nếu thông tin đăng nhập của người dùng được lưu trên máy chủ, hãy thông báo cho họ để họ thay đổi mật khẩu ở những nơi khác. Nếu các key trên máy chủ cho phép truy cập vào các hệ thống bên thứ ba, chẳng hạn như code host hoặc tài khoản cloud, hãy thông báo cho các nhà cung cấp đó để họ kiểm tra xem có dấu hiệu lạm dụng hay không. Một máy chủ thuần túy cá nhân không chứa dữ liệu của người khác thì không có nghĩa vụ nào ngoài việc phản hồi abuse ticket.