Mình quản lý hơn 30 site WordPress cho khách hàng, và nếu có một thứ mình thấy trong log server mỗi ngày, đó là bot cố gắng đăng nhập wp-login.php. Không phải 10-20 lần, mà hàng nghìn lần mỗi ngày. Brute force login là cuộc tấn công phổ biến nhất mà mọi site WordPress phải đối mặt, và nhiều người chỉ cài plugin “Limit Login Attempts” rồi tưởng đã an toàn. Bài viết này là toàn bộ cách mình bảo vệ login WordPress từ A đến Z, áp dụng cho cả Nginx và OpenLiteSpeed.
Sau khi triển khai đầy đủ stack bảo vệ 5 lớp dưới đây, số lượng bot reach đến wp-login.php trên server mình giảm 99.2%. Không còn CPU spike vì PHP xử lý login request, không còn log đầy rác. Mình sẽ hướng dẫn từng bước, từ server-level đến application-level.
Brute force login WordPress là gì và tại sao nguy hiểm?
Brute force login là cuộc tấn công mà bot tự động thử hàng nghìn комбинации username/password để đoán mật khẩu admin WordPress.Theo thống kê từ WPScan, có hơn 50.000 cuộc tấn công brute force mỗi giờ nhắm vào các site WordPress trên toàn cầu. Nếu mật khẩu yếu hoặc không có bảo vệ, tài khoản admin có thể bị chiếm trong vài phút, dẫn đến malware injection, defacement, hoặc mất dữ liệu hoàn toàn.
Lớp 1: Rate limiting wp-login.php bằng Nginx
Lớp đầu tiên và hiệu quả nhất là chặn ngay ở web server, không cho request đến PHP. Nếu bạn chạy Nginx, mình khuyến nghị dùng limit_req directive. Mở file Nginx config của site (thường ở /etc/nginx/sites-available/yoursite.conf):
# Định nghĩa zone rate limiting cho login
# Cho phép 5 request/phút từ mỗi IP
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;
server {
# ... config khác ...
location = /wp-login.php {
limit_req zone=login_limit burst=3 nodelay;
limit_req_status 429;
include fastcgi_params;
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location = /xmlrpc.php {
limit_req zone=login_limit burst=2 nodelay;
limit_req_status 429;
include fastcgi_params;
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}Cấu hình này cho phép tối đa 5 request/phút từ một IP đến wp-login.php, burst thêm 3 request nếu server không quá tải. Mọi request vượt quá sẽ nhận HTTP 429 Too Many Requests. Bot thông thường gửi 100-500 request/phút, nên lớp này đã loại bỏ 95% bot traffic.
Kiểm tra config hợp lệ rồi reload:
sudo nginx -t
sudo systemctl reload nginxNếu bạn chạy OpenLiteSpeed, cấu hình tương tự qua WebAdmin console: Virtual Hosts -> Context -> thêm /wp-login.php với Rate Limit setting. Hoặc dùng .htaccess:
# .htaccess cho OpenLiteSpeed/Apache
<Files wp-login.php>
Require all granted
# Giới hạn 5 request/phút
RewriteCond %{REMOTE_ADDR} !^127\.0\.0\.1$
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^https://yoursite\.com/
RewriteRule .* - [F]
</Files>Lớp 2: fail2ban tự động block IP sau nhiều lần thất bại
fail2ban là công cụ monitor log và tự động ban IP. Mình dùng nó trên mọi VPS WordPress. Cài đặt trên Ubuntu/Debian:
sudo apt update
sudo apt install fail2ban -yTạo jail cho WordPress. Mình viết custom filter nhận diện login thất bại từ WordPress error log:
# /etc/fail2ban/filter.d/wp-login.conf
[Definition]
failregex = ^ .* "(GET|POST) /wp-login\.php .* 200 .*$
^ .* "POST /xmlrpc\.php .* 200 .*$
ignoreregex =Tiếp theo, tạo jail config:
# /etc/fail2ban/jail.d/wp-login.conf
[wp-login]
enabled = true
port = http,https
filter = wp-login
logpath = /var/www/thienlv.com/logs/*access*.log
/var/www/*/logs/access.log
maxretry = 5
findtime = 600
bantime = 3600
action = iptables-multiport[name=wp-login, port="http,https", protocol=tcp]Cấu hình này: nếu một IP gửi 5 request đến wp-login.php hoặc xmlrpc.php trong vòng 10 phút (findtime = 600), IP đó sẽ bị block 1 giờ (bantime = 3600). Với server mình đang chạy, mình set bantime = 86400 (24 giờ) chorepeat offenders.
Kích hoạt và kiểm tra:
sudo systemctl restart fail2ban
sudo fail2ban-client status wp-loginOutput sẽ hiển thị số IP đã bị ban. Trên server mình, con số này luôn ở mức 50-200 IP bị ban bất kỳ lúc nào.
Lớp 3: Cloudflare WAF rules bảo vệ login page
Nếu site của bạn đã qua Cloudflare (nên dùng, kể cả gói free), đây là lớp bảo vệ cực kỳ hiệu quả vì bot bị chặn trước khi reach server. Mình tạo hai WAF rules trong Cloudflare dashboard: Security -> WAF -> Custom rules.
Rule 1: Rate limit wp-login.php
Expression:
(http.request.uri.path eq "/wp-login.php" or http.request.uri.path eq "/xmlrpc.php") and (http.request.method eq "POST")
Action: Rate limit
Characteristics: IP Address
Period: 10 seconds
Requests: 5
Action on exceed: BlockRule 2: Challenge cho traffic đáng ngờ đến wp-admin
Expression:
(http.request.uri.path contains "/wp-admin/" and not cf.client.bot eq "verified_bot" and not ip.src in {YOUR_IP_LIST})
Action: Managed ChallengeRule 2 đặt Managed Challenge cho mọi request đến /wp-admin/ trừ IP của bạn. Bot không thể solve challenge, người thật thì chỉ mất 1-2 giây. Mình dùng rule này cho tất cả khách hàng và chưa bao giờ thấy false positive.
Ngoài ra, bật Cloudflare Bot Fight Mode (free) trong Security -> Bots. Layer này một mình đã chặn được 60-70% bot traffic đến login page.
Lớp 4: Thay đổi URL wp-login.php bằng WPS Hide Login
Mặc định, ai cũng biết WordPress login ở /wp-admin/ hoặc /wp-login.php. Thay đổi URL này loại bỏ phần lớn automated scanner. Mình dùng plugin miễn phí WPS Hide Login:
- Cài đặt:
wp plugin install wps-hide-login --activate --path=/var/www/yoursite.com/ - Vào Settings -> WPS Hide Login
- Đặt login URL mới, ví dụ:
/quan-ly-he-thong - Đặt Admin URL (redirect khi chưa login):
/404
Sau khi lưu, /wp-login.php sẽ trả 404, bot scanner không còn biết cửa vào đâu. Cảnh báo: nếu bạn dùng Nginx cache hoặc Cloudflare page rule cache wp-login.php, phải purge cache sau khi đổi URL.
Mình thấy số lượng hit đến /wp-login.php giảm từ 3.000+/ngày xuống còn 0 sau khi đổi URL. Bot không biết đường vào, tự bỏ cuộc.
Lớp 5: Hai yếu tố xác thực (2FA) cho admin account
Dù bot có đoán được mật khẩu, 2FA là lớp phòng thủ cuối cùng. Mình dùng plugin Wordfence Login Security (miễn phí, nhẹ) hoặc Two Factor plugin chính thức từ WordPress.org:
# Cài đặt Two Factor plugin
wp plugin install two-factor --activate --path=/var/www/yoursite.com/Sau khi kích hoạt, mỗi user cần vào Users -> Profile -> bật 2FA qua app (Google Authenticator, Authy, hoặc 1Password). Mình bắt buộc 2FA cho mọi user có role Administrator hoặc Editor bằng cách thêm code sau vào functions.php:
add_filter('two_factor_enabled_providers_for_user', function($providers, $user_id) {
$user = get_userdata($user_id);
if ($user && in_array('administrator', $user->roles)) {
if (empty($providers)) {
// Force redirect đến setup page nếu chưa bật 2FA
if (!is_admin() || !isset($_GET['profile'])) {
wp_safe_redirect(admin_url('profile.php?setup_2fa=1'));
exit;
}
}
}
return $providers;
}, 10, 2);Lưu ý: code trên là ví dụ cơ bản. Nếu bạn không thoải mái với PHP, chỉ cần yêu cầu team tự bật 2FA thủ công và kiểm tra định kỳ.
Vô hiệu hóa XML-RPC khi không cần thiết
XML-RPC là vector tấn công brute force phổ biến thứ hai sau wp-login.php. Bot dùng XML-RPC để thử hàng nghìn password trong một request duy nhất (system.multicall). Nếu bạn không dùng Jetpack hoặc WordPress mobile app, vô hiệu hóa hoàn toàn:
# Nginx: block XML-RPC hoàn toàn
location = /xmlrpc.php {
deny all;
return 403;
}
# Hoặc chỉ cho phép từ IP của bạn
location = /xmlrpc.php {
allow YOUR_IP;
deny all;
include fastcgi_params;
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}Kiểm tra XML-RPC đã bị chặn:
curl -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>' https://yoursite.com/xmlrpc.phpNếu trả 403 hoặc “XML-RPC is disabled”, đã thành công.
Monitor brute force attempts như thế nào?
Sau khi triển khai các lớp bảo vệ trên, bạn cần monitor để đảm bảo chúng hoạt động. Mình dùng 3 cách:
1. fail2ban status:
sudo fail2ban-client status wp-login
# Xem số IP bị ban và log gần nhất2. Nginx access log:
# Đếm số request đến wp-login.php trong 24h qua
awk '/wp-login.php/' /var/www/yoursite.com/logs/access.log | wc -l
# Top 10 IP gửi nhiều request login nhất
awk '/wp-login.php/{print $1}' /var/www/yoursite.com/logs/access.log | sort | uniq -c | sort -rn | head -103. Cloudflare Analytics: Vào Cloudflare dashboard -> Analytics -> Security, xem số request bị blocked hoặc challenged. Nếu số này đột nhiên tăng gấp 3-5 lần, có thể đang bị coordinated attack.
Mình cũng thiết lập alert qua Discord webhook khi fail2ban ban quá 500 IP trong 1 giờ, tín hiệu của cuộc tấn công có quy mô lớn.
Bảng tổng kết: Lớp bảo vệ nào chặn được gì?
| Lớp bảo vệ | Bot blocked | Server load giảm | Độ khó |
|---|---|---|---|
| Nginx rate limiting | 95% | 70% | Trung bình |
| fail2ban | 99% | 85% | Trung bình |
| Cloudflare WAF | 99.5% | 95% | Dễ |
| Đổi login URL | 99.9% | 98% | Rất dễ |
| 2FA | 100% (nếu pass leak) | 0% | Dễ |
Bảng trên là ước lượng từ thực tế 6 tháng trên 30 site WordPress production mà mình quản lý. Con số thực tế sẽ khác tùy thuộc vào quy mô site và lưu lượng.
Các sai lầm phổ biến khi bảo vệ WordPress login
Mình đã thấy nhiều setup sai, liệt kê ở đây để bạn tránh:
1. Chỉ dùng plugin, không có server-level protection. Plugin “Limit Login Attempts” vẫn phải load PHP để xử lý. 1.000 bot request/phút vẫn tiêu tốn CPU, RAM, database connection. Server-level (Nginx/fail2ban/Cloudflare) chặn trước khi PHP được gọi.
2. Block XML-RPC mà không kiểm tra dependency. Jetpack, WordPress mobile app, một số SEO plugin cần XML-RPC. Nếu chặn hoàn toàn, các tính năng này ngừng hoạt động. Kiểm tra trước.
3. CAPTCHA quá khó. hCaptcha invisible hoặc Cloudflare Turnstile tốt hơn reCAPTCHA v2 vì không annoy người thật. Mình đã thấy khách hàng phàn nàn không login được vì CAPTCHA quá khó.
4. Đổi login URL rồi quên purge cache. Sau khi đổi URL bằng WPS Hide Login, nhớ purge Cloudflare cache, Nginx cache, và LSCache nếu có. Nếu không, /wp-login.php vẫn cache 200 OK.
Lời kết
Bảo vệ WordPress login không phải cài một plugin rồi xong. Mình áp dụng 5 lớp bảo vệ trên cho mọi site WordPress mà mình quản lý, và kết quả là trong 12 tháng qua, không một site nào bị chiếm quyền admin. Stack này tốn khoảng 2 giờ để thiết lập ban đầu, nhưng tiết kiệm hàng chục giờ xử lý sự cố sau này.
Nếu bạn chỉ có thời gian làm 2 việc hôm nay, hãy bắt đầu với: (1) đổi login URL bằng WPS Hide Login, và (2) bật Cloudflare Bot Fight Mode. Hai bước đơn giản này đã chặn được 90% bot traffic đến login page mà không cần động đến server config. Sau đó, quay lại bổ sung fail2ban và Nginx rate limiting khi có thời gian.
Nếu bạn đang chạy WordPress trên VPS, đừng quên đọc thêm bài hướng dẫn cấu hình Security Headers cho WordPress mà mình đã viết. Bảo vệ login chỉ là một phần, toàn site cần được hardening đồng bộ.
