Brute force thử nhiều mật khẩu cho một tài khoản; credential stuffing thử các cặp tài khoản–mật khẩu đã rò rỉ từ nơi khác. Cả hai có thể nhắm vào wp-login.php, XML-RPC, REST route hoặc form đăng nhập của plugin, nhưng cách phát hiện cần nhìn cả tốc độ, phân tán IP và kết quả đăng nhập.
Dấu hiệu trong access và authentication log
- Nhiều lần POST tới login từ một hoặc nhiều IP.
- Một IP thử nhiều username, hoặc một username bị thử từ nhiều mạng.
- Đăng nhập thành công từ thiết bị, quốc gia hoặc giờ bất thường.
- Lượng request XML-RPC tăng dù website không sử dụng.
- CPU tăng, PHP worker đầy hoặc website chậm đồng thời.
Phân biệt bot với người dùng quên mật khẩu
Người thật thường thử ít lần, cùng thiết bị rồi dùng reset password. Bot có nhịp đều, user-agent lặp, danh sách username và phân bố nguồn rộng. Không nên khóa tài khoản chỉ dựa vào vài lỗi vì attacker có thể lợi dụng để gây từ chối dịch vụ.
Rate limit tại tầng phù hợp
Ưu tiên chặn hoặc làm chậm trước khi request chạy sâu vào WordPress: CDN, WAF, reverse proxy hoặc web server. Đặt ngưỡng riêng cho login, reset password và XML-RPC; luôn kiểm thử với IP thật phía sau proxy để tránh khóa nhầm toàn bộ khách.
MFA và mật khẩu duy nhất
MFA giảm rủi ro khi password đã lộ, nhưng cần bảo vệ recovery code và quy trình reset MFA. Tài khoản quản trị không dùng chung; mật khẩu phải riêng cho từng hệ thống và được lưu trong password manager.
Giảm lộ username nhưng không phụ thuộc che giấu
Không hiển thị lỗi khác nhau cho username đúng và sai, đồng thời hạn chế endpoint liệt kê user khi không cần. Tuy vậy, username có thể xuất hiện trong nội dung hoặc API; biện pháp chính vẫn là xác thực mạnh và rate limit.
Cảnh báo chuỗi hành vi nguy hiểm
Ưu tiên cao khi có nhiều thất bại rồi thành công, sau đó đổi email, tạo admin, cài plugin hoặc mở phiên mới. Gắn các sự kiện theo user và thời gian sẽ hữu ích hơn cảnh báo từng request riêng lẻ.
Ứng phó khi nghi tài khoản đã bị chiếm
Khóa hoặc giảm quyền tài khoản, thu hồi session, đổi credential liên quan và rà thay đổi sau thời điểm đăng nhập. Kiểm tra thiết bị của quản trị viên và email khôi phục; nếu chỉ đổi password trên WordPress, điểm rò ban đầu có thể vẫn tồn tại.
Đo false positive sau khi triển khai
Theo dõi số khách thật bị CAPTCHA, khóa hoặc chậm đăng nhập. Tuning theo vai trò và route, dùng allowlist có thời hạn cho hệ thống quản trị đáng tin cậy, không mở ngoại lệ vĩnh viễn.
Tấn công đăng nhập không còn đến từ một IP duy nhất
Credential stuffing phân tán có thể thử mỗi IP rất ít lần nhưng nhắm cùng tài khoản bằng mật khẩu đã rò rỉ. Chặn theo IP đơn lẻ bỏ sót pattern và dễ biến thành danh sách blacklist không thể quản lý.
Tín hiệu nguy hiểm nhất là thành công sau nhiều thất bại
Nối login thành công với thiết bị, quốc gia, session và hành động tiếp theo. Nếu sau đó user đổi email, tạo admin hoặc cài plugin, hãy nâng cấp ngay thay vì coi đó là “đã đăng nhập đúng”.
Bảo vệ mà không làm khách hàng phát cáu
Rate limit ở tầng trước WordPress, CAPTCHA theo rủi ro, MFA cho quyền cao và thông báo login mới. Đo false positive, nhất là khi chạy chiến dịch hoặc nhân viên di chuyển. Không khóa vĩnh viễn một tài khoản chỉ vì attacker cố tình thử sai để gây từ chối dịch vụ.
Sau khi chặn bot, vẫn phải hỏi mật khẩu có lộ không
Nếu cùng tài khoản bị thử bằng mật khẩu đúng trên dịch vụ khác, rate limit chỉ làm chậm. Kiểm tra nguồn rò, yêu cầu mật khẩu duy nhất, thu hồi session và rà hành động sau login.
Thông báo cho người dùng đúng cách
Không gửi password hoặc link đáng ngờ. Nêu thời gian, thiết bị, cách kiểm tra từ trang chính thức và kênh báo cáo nếu không phải họ.
WordPress Hardening, OWASP Logging Cheat Sheet và WordPress Backups. WebAnToan chuyển hóa thành quy trình vận hành phù hợp website WordPress doanh nghiệp.
Cụm giám sát bảo mật WordPress chủ động
Đi từ tín hiệu thô đến cảnh báo có thể hành động và khả năng phục hồi đã được kiểm thử.
Câu hỏi thường gặp
Đổi URL wp-login có chặn brute force không?
Chỉ giảm một phần bot đơn giản; không thay thế rate limit, MFA và mật khẩu duy nhất.
Chặn IP có đủ không?
Không với tấn công phân tán; cần rule theo tài khoản, thiết bị, tốc độ và kết quả đăng nhập.
CAPTCHA nên bật cho mọi người không?
Nên kích hoạt theo rủi ro hoặc sau một số lần thất bại để giảm ảnh hưởng khách thật.
Muốn biết website đang thiếu lớp giám sát nào?
WebAnToan có thể rà baseline, nguồn log, cảnh báo và khả năng khôi phục để đề xuất lộ trình theo rủi ro thực tế.
