SSH brute force thường bắt đầu bằng hàng loạt lần đăng nhập thất bại, nhưng rủi ro thật sự xuất hiện khi một credential yếu hoặc bị lộ cho phép attacker đăng nhập thành công vào server. Khi đó vấn đề không còn là “nhiều login fail” mà là một security incident cần xác minh phạm vi truy cập, persistence và các thay đổi đã xảy ra sau khi account bị chiếm.
CISA hiện khuyến nghị dùng public-key authentication cho administrative roles, tắt password authentication khi khả thi, giảm số lần thử xác thực và cô lập management plane. OpenSSH cũng cung cấp các control trực tiếp như PasswordAuthentication, MaxAuthTries, MaxStartups, AllowUsers và AllowGroups để giảm attack surface của SSH. Nguồn: CISA — Hardening management access và OpenSSH sshd_config.
Bối cảnh và dấu hiệu ban đầu
Giả sử một Linux web server mở SSH ra Internet để phục vụ quản trị. Trong nhiều ngày, auth log liên tục ghi nhận login failure từ nhiều IP. Sau đó xuất hiện một lần login thành công vào account có quyền sudo từ một IP hoặc ASN chưa từng thấy trước đó.
Nếu chỉ cấu hình Fail2ban sau sự kiện và bỏ qua successful login, đội vận hành có thể xử lý phần “ồn” nhưng bỏ sót compromise thật sự.
Những tín hiệu cần điều tra ngay
- Nhiều failed login nối tiếp bằng một successful login cùng account.
- Login thành công từ IP, ASN, quốc gia hoặc khung giờ ngoài baseline.
- Account có quyền sudo/root nhưng không có maintenance window tương ứng.
authorized_keys, shell profile hoặc SSH config bị thay đổi.- Có user mới, sudoers change, cron/systemd service hoặc process lạ sau login.
- Outbound connection hoặc file modification xuất hiện ngay sau phiên SSH đáng ngờ.
Investigation: từ brute-force signal đến xác nhận truy cập trái phép
Bước 1: phân biệt failed attempts với successful access
Failed login chỉ cho biết server đang bị thử credential. Investigation phải tìm được successful authentication tương ứng: account, source IP, timestamp, authentication method và session duration. Trên Linux, cần đọc auth journal/log cùng SSH daemon log thay vì chỉ đếm số lần fail.
OpenSSH cho phép giới hạn số lần thử bằng MaxAuthTries và số kết nối chưa xác thực đồng thời bằng MaxStartups. Các control này giúp giảm abuse nhưng không thay thế việc điều tra một phiên đăng nhập đã thành công. Nguồn: OpenSSH sshd_config.
Bước 2: kiểm tra persistence sau khi attacker đăng nhập
Một attacker có SSH access có thể thêm SSH public key mới, tạo account, sửa sudoers, đặt cron job, systemd unit hoặc shell startup file để quay lại sau khi password bị đổi. Vì vậy cần kiểm tra cả account state và filesystem/config changes trong cùng timeline.
CISA từng ghi nhận kỹ thuật Account Manipulation: SSH Authorized Keys như một cách giúp threat actor regain entry vào môi trường sau khi đã có quyền truy cập. Nguồn: CISA advisory.
Bước 3: xác định blast radius của account bị chiếm
Không phải SSH account nào cũng có cùng impact. Cần xác định account có sudo không, có đọc secret không, có quyền ghi vào web root, backup, database credential hoặc deployment key không. Nếu account có quyền tới nhiều asset, incident có thể vượt xa chính server đang điều tra.
Đối chiếu thêm Server Audit Logging và Root Cause Analysis sau Security Incident để dựng timeline theo authentication, sudo, file/config change và process execution.
Khi nào có thể xác nhận SSH account đã bị compromise?
Không nên kết luận chỉ vì có nhiều brute-force attempts. Mức độ tin cậy tăng lên khi các bằng chứng độc lập cùng khớp.
- Có successful login từ nguồn không được owner xác nhận.
- Authentication method hoặc credential không phù hợp baseline của account.
- Sau login xuất hiện sudo, file/config change hoặc persistence artifact bất thường.
- Account/session tiếp tục hoạt động ngoài maintenance window.
- Sau khi revoke access và loại persistence, các hành vi bất thường dừng lại.
Remediation: containment trước, hardening sau
Containment khi đã có dấu hiệu successful compromise
- Khóa hoặc disable account bị compromise sau khi bảo toàn log/evidence cần thiết.
- Revoke SSH keys, sessions, tokens và credential liên quan.
- Rotate secret mà account có khả năng đọc được.
- Kiểm tra
authorized_keys, sudoers, cron, systemd, shell profile và user mới. - Hạn chế SSH bằng firewall/VPN/bastion nếu server đang expose trực tiếp ra Internet.
Nếu account có quyền rộng, cần xem compromise như một server incident thay vì chỉ “đổi password SSH”. Việc đổi credential mà không hunt persistence có thể để attacker quay lại bằng key, account hoặc service đã cài trước đó.
Hardening để giảm brute force và credential risk
- Ưu tiên public-key authentication; tắt password authentication khi workflow cho phép.
- Không cho root login trực tiếp; dùng account riêng + sudo theo least privilege.
- Dùng
AllowUsers/AllowGroupsvà hạn chế source network bằng firewall/VPN. - Giảm
MaxAuthTriesvà kiểm soátMaxStartupsphù hợp với môi trường. - Dùng Fail2ban hoặc control tương đương để phản ứng với pattern brute force trong log.
- Áp MFA/phishing-resistant authentication ở lớp remote-access/bastion hoặc hệ thống hỗ trợ MFA.
CISA khuyến nghị public-key authentication cho administrative access và disable password auth khi khả thi; CISA cũng coi MFA là control quan trọng để giảm brute force, credential stuffing và account takeover. Nguồn: CISA và CISA IAM Best Practices.
Chi tiết cấu hình xem SSH Hardening, Fail2ban cho Linux Server và Linux Firewall cho Web Server.
Validation sau remediation
| Kiểm tra | Kết quả mong đợi |
|---|---|
| SSH password auth | Tắt nếu policy cho phép |
| Root login | Không cho login trực tiếp |
| Authorized keys | Chỉ còn key có owner hợp lệ |
| Users / sudoers | Không còn account hoặc privilege lạ |
| Cron / systemd / shell profile | Không còn persistence artifact đáng ngờ |
| Firewall / source access | SSH chỉ mở cho source được phê duyệt |
| Audit logging | Login, sudo và config change tiếp tục được ghi nhận |
Bài học vận hành và bước tiếp theo
- Brute-force noise không quan trọng bằng việc xác định có successful access hay không.
- Đổi password không đủ nếu attacker đã thêm SSH key hoặc persistence khác.
- SSH public-key authentication giảm đáng kể rủi ro password guessing.
- Firewall/VPN/bastion nên giảm exposure trước khi dựa vào rate limiting.
- Server audit log phải đủ để dựng timeline authentication → privilege → change.
- Credential rotation cần bao gồm secret mà account compromised có thể truy cập.