Linux Incident Response: Quy Trình Điều Tra Sự Cố Server Từ Log Đến Root Cause

Linux incident response là kỹ năng sống còn của sysadmin khi server production bất ngờ CPU 100%, bị nghi compromise, service restart liên tục hoặc traffic outbound tăng bất thường. Bài này đi theo cách làm thực chiến: không vội “restart cho xong”, mà khoanh vùng, bảo toàn chứng cứ, dựng timeline, tìm root cause và khôi phục có kiểm soát.

Bối cảnh lab/production giả định: một máy Linux chạy Ubuntu/RHEL làm web/API server, dùng systemd, Nginx, SSH, có log journald và log ứng dụng. Quy trình dưới đây dùng được cho cloud VM, bare metal hoặc VPS, miễn là bạn có quyền sudo và biết rõ phạm vi được phép điều tra.

1. Nguyên tắc đầu tiên: đừng phá mất hiện trường

Khi sự cố xảy ra, bản năng thường là kill process, reboot hoặc update package ngay. Với incident nghiêm trọng, các hành động đó có thể xóa dấu vết trong RAM, làm mất process tree, rotate log hoặc khiến attacker thay đổi chiến thuật.

Nếu service đang gây ảnh hưởng lớn: cô lập network hoặc đưa instance ra khỏi load balancer trước.
Nếu nghi bị xâm nhập: ưu tiên snapshot disk/RAM nếu nền tảng hỗ trợ.
Ghi lại thời điểm, người thao tác, lệnh đã chạy.
Không chạy script dọn dẹp khi chưa hiểu nó làm gì.

2. Checklist khoanh vùng nhanh trong 10 phút đầu

date -Is
hostnamectl
uptime
who
last -a | head -30
systemctl --failed
journalctl -p warning..alert --since "2 hours ago" --no-pager | tail -200

Các lệnh này trả lời nhanh: server nào đang bị ảnh hưởng, thời gian hệ thống có đúng không, tải hiện tại ra sao, ai đang đăng nhập, lần login gần đây có bất thường không, unit systemd nào lỗi và log cảnh báo nổi bật là gì.

3. Kiểm tra CPU, RAM, disk I/O và filesystem

top -o %CPU
ps aux --sort=-%cpu | head -20
free -h
df -hT
du -xh /var/log 2>/dev/null | sort -h | tail -20
iostat -xz 1 5

Nếu CPU cao, hãy nhìn process name, user chạy process và command line. Nếu disk đầy, kiểm tra log tăng bất thường, file upload, core dump hoặc backup lỗi. Nếu I/O wait cao, service có thể chậm dù CPU không cao.

Output mẫu đáng chú ý:

PID  USER   %CPU COMMAND
8421 www-data 390.0 /usr/bin/php /tmp/.cache/update.php

Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1  ext4  40G  39G  200M 100% /

Process PHP chạy từ /tmp và filesystem 100% là tín hiệu cần điều tra ngay, không nên chỉ xóa file cho trống.

4. Điều tra process đáng ngờ

PID=8421
ps -fp $PID
pstree -aps $PID
readlink -f /proc/$PID/exe
tr '\0' ' ' < /proc/$PID/cmdline; echo
ls -l /proc/$PID/cwd /proc/$PID/root
lsof -p $PID | head -80

Giải thích: pstree cho biết process được sinh ra từ đâu; /proc/$PID/exe chỉ binary thật; cmdline cho tham số; cwd cho thư mục làm việc; lsof cho file/socket đang mở. Nếu process chạy từ /tmp, /dev/shm hoặc thư mục upload web, cần kiểm tra nguồn gốc.

5. Kiểm tra network connection

ss -tunap
ss -tunap | grep ESTAB
lsof -i -P -n | head -100
ip route
resolvectl status 2>/dev/null || cat /etc/resolv.conf

Tìm kết nối outbound tới IP lạ, port mining, reverse shell hoặc DNS bất thường. Với server web, outbound thường nên có pattern rõ: database nội bộ, object storage, API đối tác, update repository. Mọi kết nối không giải thích được cần ghi lại trước khi chặn.

6. Log systemd, SSH và ứng dụng

journalctl --since "24 hours ago" --no-pager > /root/journal-24h.log
grep -Ei "failed|invalid|accepted|session opened|sudo" /var/log/auth.log 2>/dev/null | tail -200
grep -Ei "error|critical|panic|segfault|oom" /var/log/syslog 2>/dev/null | tail -200
tail -200 /var/log/nginx/access.log
tail -200 /var/log/nginx/error.log

Với RHEL/CentOS, thay /var/log/auth.log bằng /var/log/secure. Đừng chỉ đọc dòng cuối; hãy tìm mốc thời gian bắt đầu bất thường rồi mở rộng cửa sổ trước/sau 15–30 phút.

7. Dựng timeline sự cố

find /etc /var/www /tmp /dev/shm -xdev -type f -printf '%TY-%Tm-%Td %TH:%TM %u %p
' 2>/dev/null | sort | tail -300
last -Fai | head -50
journalctl --since "2026-06-08 18:00" --until "2026-06-08 19:00" --no-pager

Timeline giúp trả lời: file nào mới xuất hiện, user nào login, service nào restart, lỗi đầu tiên xảy ra khi nào. Root cause thường nằm trước thời điểm alert bùng lên, không phải sau đó.

8. Kiểm tra persistence: cron, systemd, SSH key

crontab -l
ls -la /etc/cron.* /var/spool/cron/crontabs 2>/dev/null
systemctl list-unit-files --type=service | grep enabled
find /etc/systemd/system -type f -mtime -14 -ls
find /home /root -path '*/.ssh/authorized_keys' -type f -print -exec sed -n '1,120p' {} \;

Nếu attacker đã vào server, họ thường để lại cơ chế chạy lại: cron lạ, service systemd giả tên, SSH key thêm vào user hợp lệ hoặc binary đặt trong thư mục ít ai để ý.

9. Dùng auditd khi có sẵn

ausearch -m USER_LOGIN,USER_AUTH -ts recent
ausearch -x /usr/bin/sudo -ts today
aureport -x --summary | head

auditd rất hữu ích để truy vết login, sudo, thay đổi file nhạy cảm. Nếu chưa bật auditd, hãy xem đây là việc cần bổ sung sau incident, không phải trong lúc đang cháy.

10. Containment: cô lập mà vẫn giữ chứng cứ

Tùy mức độ ảnh hưởng, containment có thể là:

Gỡ instance khỏi load balancer.
Chặn egress bằng security group/firewall.
Disable credential nghi bị lộ.
Khóa user hoặc SSH key bất thường.
Snapshot disk trước khi rebuild.

# Ví dụ chặn outbound tạm thời bằng ufw, cần hiểu tác động trước khi chạy
ufw default deny outgoing
ufw allow out to 10.0.0.0/8
ufw allow out 53
ufw status verbose

Trong production, containment nên có approval/change ticket để tránh làm gián đoạn hệ thống phụ thuộc.

11. Khôi phục và hardening sau root cause

Nếu chỉ xóa process và restart, incident có thể quay lại. Sau khi xác định root cause, cần vá nguồn gốc:

Vá CVE/package hoặc plugin gây khai thác.
Rotate mật khẩu, token, SSH key liên quan.
Rebuild server từ image sạch nếu nghi compromise sâu.
Bật MFA/SSO cho admin panel.
Siết firewall và outbound allowlist.
Thêm alert cho dấu hiệu đã phát hiện.

12. Lỗi thường gặp khi xử lý incident Linux

Reboot quá sớm

Reboot có thể làm mất process, connection và RAM artifact. Chỉ reboot khi đã ghi nhận đủ dữ liệu hoặc cần phục hồi dịch vụ khẩn cấp.

Chỉ nhìn một loại log

Auth log, system log, application log và network log phải được ghép lại. Một log riêng lẻ dễ dẫn đến kết luận sai.

Không ghi lại thao tác

Khi nhiều người cùng xử lý, thiếu nhật ký thao tác sẽ làm timeline bị nhiễu. Hãy ghi command, thời điểm và người chạy.

13. Checklist nghiệm thu sau sự cố

Đã xác định phạm vi ảnh hưởng: host, user, dữ liệu, service.
Đã lưu log/timeline/snapshot cần thiết.
Root cause có bằng chứng, không chỉ phỏng đoán.
Credential liên quan đã rotate.
Lỗ hổng hoặc cấu hình sai đã được vá.
Monitoring có alert mới để phát hiện lặp lại.
Postmortem có action item, owner và deadline.

14. Bài tập lab

Tạo VM Ubuntu, chạy Nginx và một script CPU cao giả lập.
Dùng journalctl, ps, ss, lsof để tìm process và connection.
Thêm một cron giả trong /etc/cron.d, luyện tìm persistence.
Viết timeline 10 dòng: alert, login, file mới, process, containment, recovery.
Viết postmortem ngắn gồm impact, root cause, fix và preventive action.

Kết luận: Linux incident response tốt không phải là thuộc nhiều lệnh nhất, mà là biết đặt câu hỏi đúng, giữ chứng cứ, chứng minh root cause và khôi phục an toàn. Hãy luyện quy trình này trong lab trước khi production thật sự cần bạn bình tĩnh.