When dealing with login attacks against wp-login.php and xmlrpc.php, consider using an application firewall such as ModSecurity rather than a WordPress plugin. Why? ModSecurity runs before the request hits PHP. Thus, WordPress is not even run on these known to be bad requests.

Some Numbers

Prior to enabling ModSecurity rules protecting wp-login.php and xmlrpc.php, these were the most popular files hit across all Weblogs.us WordPress installs. In December of 2016, wp-login.php was 23.48% of all hits, xmlrpc.php was 19.75%—A total of 43.23% all hits for what are really non-user facing pages. Similar behavior had been seen for the months prior as well.

After enabling ModSecurity rules punishing multiple bad login attempts for wp-login.php and xmlrpc.php, their total hits plummeted. In February, they accounted for only 3.78% of all hits. Did the robots go away? No, they were getting 403 errors, nearly 20% of hits resulted in a 403 error.

Caveat Emptor

Implementing successive failed login attack mitigation rules is quite easy on Apache. Rather than repeat how to do this, see Mika’s post WordPress login protection using ModSecurity. Unfortunately, Nginx is a different story. While ModSecurity is available for Nginx, any rule that requires a locationmatch parameter will not work (locationmatch is Apache specific). Instead, a custom location rule for wp-login.php and xmlrpc.php can be generated with ModSecurity enabled and the extra rules applied. It isn’t terribly elegant, but appears to work.

Ease of implementation aside, the performance benefits from blocking malicious login traffic earlier makes using a ModSecurity based implementation worthwhile. At Weblog.us, we dramatically cut down on resource usage by implementing ModSecurity rules for blocking malicious wp-login.php and xmlrpc.php accesses.

-John Havlik

[end of transmission, stay tuned]