Securing WordPress: Lessons from a Brute Force Attack

Last month, a client called in a panic. Their WordPress site was crawling, the server CPU was pegged at 100%, and the access logs showed thousands of login attempts per minute from rotating IP addresses. It was a textbook brute force attack, and it exposed several security gaps I should have closed from the start.

The Immediate Response

First, I blocked the attack at the server level. Fail2Ban was not configured for WordPress, so I added a quick Nginx rate limit on wp-login.php:

# In nginx.conf
limit_req_zone $binary_remote_addr zone=login:10m rate=3r/m;

location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    include fastcgi_params;
    fastcgi_pass php-fpm;
}

This limits login page requests to 3 per minute per IP. The server load dropped immediately.

Hardening After the Attack

Once the immediate threat was neutralized, I implemented a proper security baseline:

1. Disable XML-RPC. It is another authentication endpoint that attackers love to brute force:

// In functions.php
add_filter("xmlrpc_enabled", "__return_false");

2. Hide the login URL. Moving wp-login.php to a custom URL eliminates most automated attacks. I use a simple rewrite rule rather than a plugin.

3. Enforce strong passwords and 2FA. Application passwords for API access, and a TOTP plugin for wp-admin logins.

4. Disable user enumeration. Attackers can discover usernames via ?author=1 or the REST API:

// Block author enumeration
if (!is_admin() && isset($_GET["author"])) {
    wp_redirect(home_url(), 301);
    exit;
}

Monitoring Going Forward

I set up a simple cron job that emails me when failed login attempts exceed a threshold. Prevention is important, but detection is equally critical. You cannot fix what you do not know about.

The lesson: security is not a plugin you install and forget. It is a set of practices — rate limiting, strong authentication, monitoring, and keeping everything updated.