Ứng phó Sự cố Linux: Chiến thuật Sinh tồn Thực chiến trong 6 Tháng

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Vượt xa Tường lửa: Khi Môi trường Production Gặp Sự cố

Sáu tháng trước, ly cà phê sáng của tôi đã nguội ngắt khi tôi thấy CPU tăng vọt 98% trên một máy chủ web vốn đang ‘yên tĩnh’. Một tiến trình kswapd0 lạ đang chạy dưới một tài khoản dịch vụ chưa từng được đụng đến trong ba năm. Cơn hoảng loạn đó là một bài học thực tế đắt giá. Tường lửaIDS rất tuyệt, nhưng chúng không phải phép màu. Khi các lớp phòng thủ tự động thất bại, bạn cần một quy trình ứng phó sự cố (IR) thủ công, đã qua thực chiến để giành lại quyền kiểm soát.

30 phút đầu tiên sau khi bị xâm nhập là một cuộc đua đầy kịch tính. Kẻ tấn công muốn xóa dấu vết log và đặt backdoor. Bạn thì muốn thu thập bằng chứng. Nếu di chuyển quá chậm, chúng sẽ biến mất. Nếu di chuyển quá nhanh với sai công cụ, bạn có thể ghi đè lên dữ liệu pháp y hoặc đánh động kẻ xâm nhập. Bài viết này sẽ phân tích chi tiết quy trình mà tôi đã dành nửa năm qua để tinh chỉnh trong thực tế.

Bộ Công cụ Pháp y: Đừng Tin tưởng vào các File Nhị phân của Hệ thống

Dựa dẫm vào ls, ps, hay netstat trong khi đang bị xâm nhập là một sai lầm của ‘lính mới’. Một rootkit tinh vi sẽ thay thế những lệnh này đầu tiên. Nó sẽ vá ps để bỏ qua các PID độc hại và ẩn các file khỏi ls. Về cơ bản, bạn đang đi hỏi tên trộm xem chúng có đang ở trong nhà hay không.

Để chống lại điều này, tôi giữ một ‘Bộ công cụ pháp y’ (Forensic Toolbox) trên mọi node production. Đây là các file nhị phân tĩnh (static binaries) và các công cụ kiểm toán không phụ thuộc vào các thư viện hệ thống đã bị xâm nhập. chúng sẽ cho bạn biết sự thật khách quan.

Bộ Công cụ Thiết yếu

Tôi ưu tiên busybox-static. Nó là một file nhị phân duy nhất, độc lập. Nó không dựa vào các thư viện cục bộ mà kẻ tấn công có thể đã tiêm mã độc. Tôi cũng triển khai auditd để log sâu và lynis để kiểm tra độ an toàn tự động.

# Triển khai các công cụ điều tra cốt lõi trên Debian/Ubuntu
sudo apt update
sudo apt install busybox-static auditd lynis debsums -y

debsums là vũ khí bí mật của tôi. Nó so sánh mã băm MD5 của các file cục bộ với hồ sơ gốc từ repository. Nếu hacker thay đổi file nhị phân /bin/login của bạn bằng một phiên bản độc hại, debsums sẽ phát hiện ra chỉ trong vài giây.

Sẵn sàng Pháp y: Cấu hình cho Tình huống Xấu nhất

Hardening (gia cố hệ thống) không chỉ là đóng các cổng; đó còn là đảm bảo dữ liệu tồn tại khi mọi thứ đổ vỡ. Các bản log mặc định của Linux quá sơ sài. Trong 6 tháng qua, tôi đã điều chỉnh auditd để hoạt động quyết liệt hơn đáng kể.

Bật Tính năng Kiểm toán Liên tục

Tôi buộc auditd phải giám sát các file nhạy cảm. Nếu ai đó chạm vào /etc/passwd hoặc chèn một key mới vào authorized_keys, tôi cần một dòng log cho biết chính xác ai đã làm việc đó. Thêm những dòng sau vào /etc/audit/rules.d/audit.rules:

# Theo dõi việc thay đổi tài khoản người dùng
-w /etc/passwd -p wa -k user_changes
-w /etc/shadow -p wa -k user_changes

# Giám sát việc chèn SSH key
-w /root/.ssh/authorized_keys -p wa -k ssh_key_changes

# Đánh dấu việc sử dụng công cụ khả nghi
-w /usr/bin/wget -p x -k suspicious_download
-w /usr/bin/curl -p x -k suspicious_download

Áp dụng các thay đổi ngay lập tức: sudo systemctl restart auditd.

Thông tin đăng nhập là một điều không thể thương lượng khác. Nếu tôi nghi ngờ bị xâm nhập, tôi sẽ cô lập máy chủ và xoay vòng (rotate) mọi mật khẩu admin. Tôi sử dụng công cụ tạo mật khẩu tại toolcraft.app/vi/tools/security/password-generator. Nó chạy hoàn toàn trong trình duyệt của bạn, vì vậy không có chuỗi ký tự nhạy cảm nào được gửi qua mạng. Điều này đảm bảo mật khẩu khôi phục của tôi luôn nằm ngoài mạng lưới cho đến khi tôi sẵn sàng.

Cuộc Điều tra: 5 Bước Săn lùng Kẻ xâm nhập

Khi chuông báo động vang lên, tôi tuân theo một quy trình xác minh nghiêm ngặt. Đây chưa phải là lúc để sửa lỗi, mà là để lập bản đồ vùng bị nhiễm độc.

1. Phân tích các Phiên hoạt động

Ai đang ở trên máy chủ ngay lúc này? Sử dụng w cho các người dùng đang hoạt động và last để phát hiện các lần đăng nhập lúc 3 giờ sáng từ các dải IP lạ.

# Các phiên hoạt động hiện tại
w

# Xem lại 20 lần đăng nhập gần nhất
last -n 20

2. Lập bản đồ Lưu lượng Mạng

Tìm kiếm các kết nối outbound tới các IP lạ. Hacker rất thích các cổng cao (như 4444 hoặc 31337) để tạo reverse shell. Sử dụng ss—nó nhanh và hiện đại hơn netstat.

# Liệt kê tất cả các kết nối đang hoạt động và đang lắng nghe
sudo ss -tulpn

3. Săn lùng các Tiến trình Lạ

Tìm kiếm các tiến trình mồ côi (không có tiến trình cha) hoặc các file nhị phân đã tự xóa mình khỏi ổ đĩa để chỉ chạy thuần túy trong bộ nhớ. Luôn sử dụng busybox tĩnh tại đây.

# Sử dụng file nhị phân tĩnh đáng tin cậy để xem tất cả
busybox ps auxf

Hãy chú ý thẻ (deleted) trong /proc/<pid>/exe. Đó gần như luôn là dấu hiệu của một payload chỉ chạy trong bộ nhớ.

4. Phát hiện các Cơ chế Duy trì (Persistence Hooks)

Kẻ xâm nhập muốn tồn tại sau khi máy chủ reboot. Chúng ẩn các script trong /etc/cron.d/ hoặc /etc/update-motd.d/. Tôi quét mọi thứ đã được sửa đổi trong một giờ qua.

# Kiểm tra crontab của tất cả người dùng
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done

# Tìm các file đã thay đổi trong 60 phút qua
find /etc /usr/bin /usr/sbin -mmin -60

5. Xác nhận Tính toàn vẹn của File Nhị phân

Cuối cùng, hãy để debsums xác minh các thành phần cốt lõi của OS. Nếu debsums -c trả về kết quả khớp, các file nhị phân của bạn đã bị xâm nhập. Tại thời điểm đó, hãy dừng lại. Cài đặt lại toàn bộ từ một image sạch là con đường an toàn duy nhất.

# Kiểm tra các file nhị phân hệ thống bị thay đổi
sudo debsums -c

Lời kết

Chuẩn bị chiếm 90% chiến thắng. Các công cụ như busybox-staticauditd biến một tình huống khẩn cấp hỗn loạn giữa đêm thành một cuộc săn lùng có hệ thống. Nếu bạn đợi đến khi bị xâm nhập mới bắt đầu học những lệnh này, cuộc đua đã kết thúc rồi. Hãy thiết lập môi trường pháp y của bạn ngay hôm nay. Hãy tin tưởng vào log, sử dụng các file nhị phân tĩnh và luôn xác minh tính toàn vẹn từ gốc rễ.

Share: