Server của mình từng bị brute-force SSH lúc nửa đêm — nhìn vào auth.log thấy hàng chục nghìn lần thử login từ các IP nước ngoài, tim đập loạn cả lên. May mà attacker chưa vào được vì mình đã đổi port và dùng key authentication. Từ hôm đó, mình mới nghiêm túc học cách phát hiện xâm nhập thay vì chỉ ngồi phòng thủ bị động.
Bài này đi thẳng vào thực tế: làm thế nào để biết server đang bị tấn công, dùng tool nào để điều tra, và khi đã bị hack rồi thì xử lý như thế nào cho đúng thứ tự.
So sánh các phương pháp phát hiện server bị xâm nhập
Có 3 hướng tiếp cận chính, từ đơn giản đến phức tạp:
Phương pháp 1: Kiểm tra thủ công
Chạy tay các lệnh Linux để xem log hệ thống, tiến trình đang chạy, kết nối mạng hiện tại. Không cần cài thêm gì, có thể làm ngay khi nghi ngờ. Điểm mấu chốt: bạn phải biết trạng thái “bình thường” của server mới nhận ra được bất thường.
Phương pháp 2: Rootkit scanner và audit tool
rkhunter, chkrootkit, Lynis — những tool này tự động quét hệ thống theo danh sách mẫu độc hại đã biết. Quét được nhiều thứ hơn hẳn khi làm tay, nhưng có thể sinh false positive gây nhiễu.
Phương pháp 3: IDS/monitoring realtime
Fail2ban, OSSEC, Wazuh đi theo hướng khác hẳn: giám sát liên tục 24/7 và phản ứng tự động — block IP, gửi alert ngay khi có sự kiện. Tốt nhất cho production, nhưng cần effort để cài đặt và tune rules.
Phân tích ưu nhược điểm
Kiểm tra thủ công
- Ưu: Không cần cài thêm, hiểu chính xác chuyện gì đang xảy ra, không bị false negative của tool
- Nhược: Tốn thời gian, cần kinh nghiệm để đọc output, dễ bỏ sót nếu attacker đã xóa log hoặc dùng rootkit ẩn tiến trình
Rootkit scanner
- Ưu: Tự động hóa, bắt được nhiều loại rootkit phổ biến, có thể lên lịch chạy định kỳ
- Nhược: Không bắt được zero-day, database cần cập nhật thường xuyên, sau khi cài thêm package kiểu lwp-request hay Perl module mới là false positive nổi lên liên tục
IDS/monitoring realtime
- Ưu: Phát hiện ngay lập tức, tự động block, lưu audit trail đầy đủ để điều tra sau
- Nhược: Setup và maintain phức tạp, tốn tài nguyên server, phải tune rules để tránh false positive quá nhiều
Chọn phương pháp phù hợp với từng tình huống
Ba tình huống hay gặp nhất — mỗi cái cần cách tiếp cận khác:
- Server đang bị nghi ngờ tấn công ngay lúc này: Kiểm tra thủ công trước — nhanh nhất để có cái nhìn tổng quan trong vòng 5 phút
- Muốn audit định kỳ hàng tuần: Setup rkhunter hoặc Lynis chạy qua cron, gửi kết quả qua email
- Production server quan trọng: Deploy Fail2ban tối thiểu ngay hôm nay, xem xét thêm OSSEC/Wazuh nếu có nguồn lực vận hành
Thực tế mình kết hợp cả ba: kiểm tra thủ công khi có alert bất thường, rkhunter quét hàng tuần qua cron, Fail2ban chạy 24/7. Đơn giản nhưng đủ dùng cho server cá nhân và SMB.
Hướng dẫn triển khai từng bước
Bước 1: Checklist kiểm tra nhanh khi nghi ngờ bị hack
Chạy ngay các lệnh này để nắm tình hình trong vài phút:
# Ai đang login vào server lúc này?
who
w
# Lịch sử login gần đây — cả thành công lẫn thất bại
last -n 20
lastb -n 20
# Tiến trình ăn CPU/RAM cao bất thường
ps aux --sort=-%cpu | head -20
ps aux --sort=-%mem | head -20
# Kết nối mạng hiện tại — tìm IP lạ
ss -tnp
# File nào bị thay đổi trong 7 ngày gần đây ở thư mục hệ thống
find /etc /bin /usr/bin /sbin /usr/sbin -mtime -7 -type f 2>/dev/nullDấu hiệu đáng lo: tiến trình tên lạ không nhận ra, kết nối đến IP nước ngoài trên port không phải 80/443/22, hoặc có user lạ đang login.
# Kiểm tra log SSH — xem brute force và login thành công
grep "Failed password" /var/log/auth.log | tail -50
grep "Accepted" /var/log/auth.log | tail -20
# Crontab của tất cả user — malware hay cài cron backdoor
for user in $(cut -f1 -d: /etc/passwd); do
echo "=== $user ==="
crontab -u $user -l 2>/dev/null
done
# Authorized_keys lạ — attacker hay cài key của họ vào
find /home /root -name "authorized_keys" -exec echo "--- {} ---" \; -exec cat {} \;Bước 2: Quét rootkit bằng rkhunter và chkrootkit
# Cài đặt
apt install rkhunter chkrootkit -y # Ubuntu/Debian
yum install rkhunter chkrootkit -y # CentOS/RHEL
# Cập nhật database trước khi quét
rkhunter --update
# Quét toàn bộ hệ thống, bỏ qua confirm từng bước
rkhunter --check --sk
# Cross-check bằng chkrootkit
chkrootkitĐọc kỹ phần output có chữ Warning — nhưng đừng hoảng ngay. rkhunter hay false positive về Perl modules hoặc /usr/bin/lwp-request. Google cụ thể từng warning trước khi kết luận bị hack.
Bước 3: Audit toàn diện với Lynis
apt install lynis -y
# Chạy audit toàn hệ thống
lynis audit system
# Output có 3 phần quan trọng:
# - Hardening index: điểm bảo mật tổng thể (càng cao càng tốt)
# - Warnings: vấn đề cần xử lý ngay
# - Suggestions: khuyến nghị để tăng điểmBước 4: Cô lập và xử lý sau khi xác nhận bị hack
Đã xác nhận bị xâm nhập? Làm theo thứ tự này — đừng bỏ bước nào:
4.1. Cô lập server ngay:
# Chặn tất cả inbound ngoại trừ IP của bạn (thay YOUR_IP)
iptables -I INPUT -s YOUR_IP -j ACCEPT
iptables -I INPUT -j DROP
# Hoặc dùng ufw
ufw default deny incoming
ufw allow from YOUR_IP
ufw enable4.2. Thu thập bằng chứng trước khi dọn dẹp:
TIMESTAMP=$(date +%s)
ps aux > /tmp/evidence-ps-$TIMESTAMP.txt
ss -tnp > /tmp/evidence-ss-$TIMESTAMP.txt
cp /var/log/auth.log /tmp/evidence-auth-$TIMESTAMP.log
crontab -l > /tmp/evidence-cron-root-$TIMESTAMP.txt4.3. Kill tiến trình độc hại và dọn backdoor:
# Kill theo PID (lấy PID từ ps aux ở trên)
kill -9 PID_CUA_TIEN_TRINH_LA
# Đổi mật khẩu tất cả user có shell login
grep -v '/nologin\|/false' /etc/passwd
passwd root
passwd ten_user_khac
# Khóa user không dùng đến
usermod -L username_khong_dung
# Xóa SSH key lạ — mở từng file và xóa dòng không nhận ra
nano /root/.ssh/authorized_keys
nano /home/your_user/.ssh/authorized_keysBước 5: Setup Fail2ban để phòng thủ về sau
apt install fail2ban -y
# Tạo config local (không chỉnh file .conf gốc để tránh bị ghi đè khi update)
cat > /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
[sshd]
enabled = true
port = ssh
EOF
systemctl enable fail2ban
systemctl start fail2ban
# Kiểm tra IP đang bị ban
fail2ban-client status sshdServer mình sau khi bật Fail2ban, mỗi ngày thấy khoảng 50–150 IP bị auto-ban chỉ vì brute-force SSH — toàn bot, không có người dùng thật nào bị ảnh hưởng. Ngoài Fail2ban, mình luôn làm thêm 2 việc này ngay sau khi dựng server mới:
# Tắt SSH password login — chỉ cho phép key authentication
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd
# Đổi SSH port mặc định (giảm được 90% noise từ auto-scanner)
sed -i 's/^#*Port.*/Port 2222/' /etc/ssh/sshd_config
systemctl restart sshdKết luận thực tế
Hacker không nhắm vào server cụ thể của bạn — họ dùng scanner tự động quét cả triệu IP một lúc. Server bị vào chủ yếu vì chưa được hardening, không phải vì bị chọn mặt gửi vàng. Cái đêm ngồi xử lý brute-force SSH lúc 2 giờ sáng dạy mình một bài rất thực tế: setup bảo mật từ đầu tốn 30 phút, chữa cháy sau sự cố có thể mất cả ngày và mất dữ liệu.
Quy trình mình đang dùng: Fail2ban chạy nền 24/7, rkhunter quét hàng tuần qua cron. Khi nhận alert bất thường thì chạy ngay checklist Bước 1 trước khi làm gì khác. Đủ dùng cho hầu hết server cá nhân và doanh nghiệp nhỏ mà không cần infrastructure phức tạp.
