Khi nghi VPS bị hack, việc cần ưu tiên là ngăn hoạt động trái phép tiếp diễn và giữ lại dữ liệu phục vụ điều tra. Tài liệu ứng phó của AWS đặt mục tiêu cô lập tài nguyên nhưng bảo toàn bằng chứng; hướng dẫn khắc phục EC2 yêu cầu tìm nguồn hoạt động đáng ngờ. Vì vậy, hãy coi xử lý ban đầu là quá trình kiểm soát sự cố, thay vì chỉ tìm một tệp lạ rồi xóa.
Dấu hiệu nào đáng điều tra?
Một dấu hiệu đáng chú ý là VPS phát ra lưu lượng tấn công. DigitalOcean cho biết thông báo máy gửi outgoing flood hoặc DDoS thường liên quan đến việc máy bị chiếm dụng để gửi thư rác hay lưu lượng độc hại. AWS GuardDuty cũng có nhóm phát hiện EC2 liên quan đến hoạt động từ chối dịch vụ và spam. Cần phân biệt máy đang phát tán tấn công với máy đang nhận lưu lượng tấn công: hướng truyền dữ liệu là chi tiết phải xác minh khi đọc cảnh báo.
Một cảnh báo đăng nhập bất thường cũng cần đối chiếu với công việc thực tế. Trong hướng dẫn bảo vệ cơ sở dữ liệu, AWS nêu rằng người dùng lâu ngày mới đăng nhập hoặc chỉ truy cập định kỳ có thể tạo ra hành vi khác thường nhưng hợp lệ. GuardDuty cũng yêu cầu kiểm tra hành vi gây cảnh báo EC2 có được dự kiến hay không. Hãy xác nhận tài khoản, thời điểm và hoạt động với người phụ trách trước khi kết luận đã có kẻ xâm nhập.
Để xác minh, nên ghép các dấu vết thành dòng thời gian: hoạt động nào xảy ra, tài nguyên nào liên quan và ai thực hiện. AWS mô tả dữ liệu điều tra gồm nhật ký API, luồng mạng, truy vấn DNS và thông tin cấu hình. Với sự kiện đăng nhập cơ sở dữ liệu ngoài dự kiến, hãng khuyến nghị xem nhật ký kiểm toán để xác định thông tin đã bị truy cập hoặc sửa đổi. Cách tiếp cận này giúp tách nghi vấn truy cập khỏi bằng chứng về tác động dữ liệu.

Cô lập máy và giữ nguyên bằng chứng cần thiết
Khi đã có căn cứ về hoạt động trái phép, hãy hạn chế kết nối của máy nghi nhiễm. Với EC2, AWS hướng dẫn dùng nhóm bảo mật cách ly, chỉ cho phép các địa chỉ IP cụ thể và gỡ những nhóm bảo mật khác khỏi máy. Đây là ví dụ dành riêng cho AWS; khi dùng nhà cung cấp VPS khác, cần xác nhận cơ chế cô lập tương ứng. Trước thao tác, hãy ghi lại cấu hình mạng hiện tại và đường truy cập quản trị cần duy trì để phục vụ điều tra.
Sau khi đổi chính sách mạng, phải kiểm tra việc cô lập có thực sự chặn hoạt động đáng ngờ hay chưa. AWS lưu ý rằng thay security group không chấm dứt các kết nối đang được theo dõi; thay đổi chỉ chặn lưu lượng mới theo quy tắc áp dụng. Do đó, trên EC2, không nên lấy việc đã gắn nhóm cách ly làm bằng chứng duy nhất rằng mọi liên lạc đã dừng. Cần xử lý cả kết nối tồn tại theo hướng dẫn phù hợp của nền tảng.
Tiếp theo là giữ dữ liệu điều tra trước khi làm sạch hoặc cài lại. Akamai khuyến nghị lưu bản sao đầy đủ của đĩa bị xâm nhập, hoặc ít nhất giữ nhật ký hệ thống để xem lại. Quy trình điều tra tự động của AWS cũng có bước thu thập bộ nhớ và đĩa. Với VPS của mình, hãy yêu cầu nhà cung cấp hoặc người xử lý xác nhận loại dữ liệu đã thu thập, nơi lưu và khả năng đọc lại trước khi chuyển sang thao tác phá hủy dữ liệu.
Thông tin xác thực cần được xử lý song song nếu có dấu hiệu bị lộ. AWS khuyến nghị thay ngay access key nghi bị chiếm dụng; với tài khoản cơ sở dữ liệu liên quan đến hoạt động bất thường, hướng dẫn GuardDuty nêu việc thu hồi quyền hoặc đổi mật khẩu. Hãy lập danh sách ứng dụng phụ thuộc vào từng bí mật, cập nhật thông tin thay thế và xác nhận quyền truy cập cũ đã bị thu hồi. Chỉ đổi mật khẩu quản trị VPS chưa bao quát được những khóa truy cập khác đang bị nghi ngờ.

Phục hồi dịch vụ mà không mang theo nguyên nhân cũ
Nếu không xác định và chặn được hoạt động trái phép, AWS khuyến nghị thay EC2 bị xâm nhập bằng máy mới khi cần. Akamai cũng cảnh báo khó xác định đầy đủ phạm vi can thiệp của kẻ tấn công và không nên tiếp tục tin cậy máy đã bị chiếm quyền để chạy dịch vụ thực tế. Với người vận hành VPS, điều này đặt ra một quyết định rõ ràng: khi chưa kiểm soát được sự cố, cần chuẩn bị môi trường sạch để phục hồi.
Cài lại trực tiếp có rủi ro mất dữ liệu. DigitalOcean giải thích thao tác rebuild xóa đĩa và thay bằng ảnh hệ điều hành được chọn; nếu không có bản sao, dữ liệu không thể được nhà cung cấp khôi phục. Hướng dẫn Akamai cũng mô tả rebuild là lựa chọn phá hủy dữ liệu. Vì vậy, trước khi xác nhận cài lại, phải kiểm tra bản sao cần giữ đã tồn tại và sử dụng được. Nếu bước kiểm tra chưa hoàn tất, hãy dừng thao tác xóa hoặc rebuild.
Dữ liệu mang sang máy mới phải được rà soát. Akamai yêu cầu kiểm tra nội dung từ hệ thống bị xâm nhập để tránh chuyển cả thành phần độc hại; DigitalOcean cũng yêu cầu kiểm tra máy mới nhằm bảo đảm không sao chép thứ đáng ngờ sang. Hãy tách quyết định giữ dữ liệu kinh doanh khỏi quyết định giữ chương trình và cấu hình cũ. Mỗi phần đưa trở lại cần được xem xét trong bối cảnh điểm xâm nhập đang điều tra.
Trước khi mở lại dịch vụ, cần xử lý đường vào đã xác định. AWS nêu các biện pháp như đóng cổng không cần thiết, sửa chính sách truy cập và nâng cấp ứng dụng để khắc phục lỗ hổng. DigitalOcean khuyến nghị cập nhật phần mềm, dùng khóa SSH và siết tường lửa khi dựng máy thay thế. Sau phục hồi, hãy đối chiếu lại các cảnh báo ban đầu và nhật ký liên quan; nếu chưa giải thích được hoạt động trái phép hoặc nó tái diễn, cần tiếp tục điều tra thay vì coi việc website chạy lại là kết thúc sự cố.

Nguồn tham khảo
aws.amazon.com (7 tài liệu)
- /security-ir/latest/userguide/contain.html
- /guardduty/latest/ug/compromised-ec2.html
- /guardduty/latest/ug/guardduty_finding-types-ec2.html
- /guardduty/latest/ug/guardduty-remediate-compromised-database-rds.html
- /security-ir/latest/userguide/case-investigation-data.html
- /prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html
- /blogs/security/practical-steps-to-minimize-key-exposure-using-aws-security-services

