How to protect WordPress from brute-force attacks

Quick answer: Limit login attempts (plugin), enable 2FA for all admins, block or restrict xmlrpc.php, and add server-side rate limiting with fail2ban reading the WordPress auth log. Together these turn endless bot password-guessing from a threat into background noise.

Overview

Every public WordPress site gets brute-forced daily — bots hammer wp-login.php and xmlrpc.php around the clock. The risk isn’t only a guessed password: unthrottled login floods also burn CPU. Defense has an application layer (limit, 2FA) and a server layer (fail2ban, web-server rules); use both.

Before you start

• Admin access to wp-admin and SSH.
• A firewall already active (UFW guide) — fail2ban plugs into it.

Step-by-step guide

1. Limit attempts: install “Limit Login Attempts Reloaded” (or Wordfence’s built-in limiter): lock out after 4–5 failures, increasing lockout times.
2. 2FA: add a TOTP plugin (WP 2FA, Two-Factor) and enforce it for administrator and editor roles.
3. xmlrpc.php: if you don’t use the mobile app/Jetpack, deny it at the web server (see the Nginx server block); otherwise restrict by IP.
4. fail2ban: install the “WP fail2ban” plugin (logs auth events to syslog), then:

   sudo apt install fail2ban
   # /etc/fail2ban/jail.d/wordpress.conf
   [wordpress-hard]
   enabled = true
   filter = wordpress-hard
   logpath = /var/log/auth.log
   maxretry = 3
   bantime = 3600
   port = http,https

   The plugin ships matching filter files; copy them to /etc/fail2ban/filter.d/ and restart fail2ban.
5. Verify: fail a few logins from a VPN IP and check sudo fail2ban-client status wordpress-hard.

Common issues

• You lock yourself out: whitelist your own IP in the limiter and in fail2ban’s ignoreip.
• Attacks continue via xmlrpc: login limiters often don’t cover it — that’s why the explicit block matters.
• Renaming wp-login breaks integrations: hiding the login page is cosmetic; rate limiting + 2FA is the real protection.

When to contact support

If a login flood is saturating the server despite bans (unusual), open a ticket with timestamps and sample IPs — DDoS-scale events can be assessed at the network level, and DDoS protection is available as a service option.

Frequently asked questions

Is renaming the login page enough to stop brute force?

No — it only hides wp-login.php from lazy bots and breaks some integrations. Attempt limiting, 2FA and fail2ban stop attacks regardless of whether the login URL is known.

Why do attackers target xmlrpc.php?

xmlrpc.php accepts authentication and can multiplex many login guesses into one request, bypassing simple limiters — so block it entirely if you do not use remote publishing or Jetpack.

What does fail2ban add over a login-limiter plugin?

fail2ban bans abusive IPs at the firewall, so repeat offenders never reach PHP at all — saving CPU during floods and covering SSH and other services with the same mechanism.

Related articles

• How to secure WordPress on a VPS
• WordPress security checklist
• How to configure UFW firewall
• How to secure your VPS after deployment

Need a hand? Contact Cloud2Y support →