Bài này là detection/triage owner cho brute force và login spike đang xảy ra. Dùng khi bạn đã thấy failed login tăng, credential spraying, successful login đáng ngờ hoặc cần runbook xử lý theo account/route/time. Nếu mục tiêu là dựng baseline phòng ngừa trước khi có sự cố, chuyển sang chống brute-force WordPress: checklist bảo vệ login.
Phạm vi của bài
Bài này trả lời câu hỏi “đang có login spike hoặc dấu hiệu brute force, tôi phải xác minh và triage thế nào?”. Nó không phải checklist hardening phòng ngừa dài hạn. Kết quả mong muốn là xác định route/account bị nhắm tới, phân biệt failure với successful compromise, áp dụng containment có kiểm soát và biết khi nào phải mở rộng sang incident.
Chống brute force vào wp-login.php và wp-admin cần giải quyết hai vấn đề khác nhau: giảm khả năng thử credential hàng loạt và hạn chế tác động vận hành do traffic đăng nhập bất thường. Đổi URL đăng nhập có thể giảm một phần noise trong một số môi trường nhưng không thay thế authentication mạnh, rate control, WAF và monitoring.
Brute force WordPress là gì?
Brute force là việc thử nhiều credential để tìm tổ hợp đăng nhập hợp lệ. Credential stuffing là biến thể sử dụng username/password đã lộ từ dịch vụ khác. Cả hai đều khiến password reuse và account đặc quyền trở thành rủi ro đáng kể.
Các lớp phòng vệ trước brute force và login abuse
Đầu tiên: giảm giá trị của một mật khẩu bị lộ
Dùng mật khẩu riêng cho từng account và bật MFA cho privileged users khi phù hợp. Nếu mật khẩu bị lộ nhưng vẫn cần yếu tố thứ hai, khả năng đăng nhập thành công giảm đáng kể. Xem MFA/2FA WordPress.
Giảm số account có quyền cao
Không để nhiều Administrator hơn nhu cầu. Account cũ, test hoặc của nhân sự đã rời dự án cần được xử lý theo quy trình. Least privilege giảm impact nếu một credential bị compromise.
Rate limiting và throttling
Rate control có thể đặt ở application, reverse proxy, CDN/WAF hoặc identity layer tùy kiến trúc. Threshold cần dựa trên baseline; quá chặt có thể khóa người dùng hợp lệ, quá lỏng không giảm được abuse. Không dùng một con số cố định cho mọi website.
Đừng chỉ đếm request theo một IP
Brute force hiện đại có thể phân tán qua nhiều nguồn, khiến mỗi IP chỉ tạo ít request nhưng tổng số lần thử trên một account hoặc một route vẫn bất thường. Khi công cụ hỗ trợ, nên nhìn nhiều chiều như account, route, thời gian, ASN/network reputation và tỷ lệ failure/success thay vì chỉ một threshold theo IP.
WAF/CDN có thể hỗ trợ thế nào?
WAF có thể áp rule theo route, IP reputation, rate hoặc tín hiệu khác. Nên pilot và quan sát false positive trước khi block mạnh. Xem WAF WordPress an toàn.
Đổi URL đăng nhập có đủ không?
Không. Nó có thể giảm bot noise biết đường dẫn mặc định nhưng endpoint vẫn có thể bị phát hiện qua nhiều cách và credential compromise vẫn còn. Không coi obscurity là control chính.
wp-admin và wp-login.php không hoàn toàn giống nhau
wp-login.php xử lý flow đăng nhập, còn wp-admin là khu vực quản trị sau authentication với một số route/behavior riêng. Khi đặt rule ở proxy/WAF, phải test login, logout, password reset, AJAX và integration liên quan để tránh block nhầm.
XML-RPC và API authentication
Một số site có thể nhận authentication traffic qua XML-RPC hoặc API/integration. Không chỉ nhìn wp-login.php. Inventory endpoint thực tế trước khi thiết kế control. Xem XML-RPC WordPress và REST API WordPress.
Detection và runbook khi login traffic bất thường
Decision tree khi thấy login spike
| Quan sát | Diễn giải ban đầu | Bước tiếp theo |
|---|---|---|
| Nhiều failure, không có success lạ | Abuse/noise có thể đang diễn ra | Rate control, monitor, kiểm tra account mục tiêu |
| Failure rồi success trên privileged account | Rủi ro cao hơn | Review session, source, audit event ngay |
| Nhiều account bị thử từ nhiều nguồn | Có thể là distributed spraying | Correlate theo account/route/time |
| Traffic tăng sau WAF rule mới | Có thể là telemetry/false-positive issue | So baseline và change timeline |
Monitoring login
Theo dõi failed/successful login, account, source và thời gian. Một IP tạo nhiều failure là tín hiệu, không tự động là bằng chứng compromise. Correlate với successful login, session mới, role change và audit log.
Metrics hữu ích hơn “đã chặn bao nhiêu bot”
- Tỷ lệ failed/successful login theo baseline.
- Số privileged account bị nhắm tới.
- Số successful login từ context chưa từng thấy cần review.
- False-positive rate của rate/WAF rule.
- Thời gian từ alert tới triage.
Runbook khi login traffic tăng bất thường
- Ghi baseline và thời điểm spike.
- Xác định route bị nhắm tới.
- Kiểm tra successful login bất thường.
- Review privileged account/session.
- Điều chỉnh rate/WAF có kiểm soát nếu cần.
- Revoke session hoặc rotate credential khi có evidence.
- Theo dõi false positive và rollback rule nếu ảnh hưởng user thật.
Không nên làm gì?
- Không block cả quốc gia chỉ dựa trên một đợt failed login nếu chưa đánh giá business impact.
- Không khóa vĩnh viễn user sau vài lần nhập sai.
- Không dùng CAPTCHA như control duy nhất.
- Không bỏ MFA vì đã có WAF.
- Không log password hoặc secret để điều tra.
Validation
PASS khi privileged account có authentication mạnh, rate control hoạt động theo baseline, login flow hợp lệ không bị phá, event có thể audit và đội vận hành biết cách xử lý khi có successful login đáng ngờ.
Nguồn kỹ thuật
Kết luận
Khi login spike đã xuất hiện, ưu tiên triage theo account, route và timeline, tìm successful authentication đáng ngờ và chỉ áp mitigation có rollback. Phần phòng ngừa dài hạn nên quay về checklist owner riêng thay vì trộn detection với hardening trong cùng một search task.