Top Nav

Archive | WordPress

Block wp-login.php On Single Site In WordPress Multi-Site

In the recent rash of wp-login.php brute force attacks, I needed a way to block access to wp-login.php on a single domain in a WordPress multi-site with many domains. The impact on customers of blocking all domains was too great so I needed a more targeted solution. Here’s what I came up with for the .htaccess file:

0

WordPress Multi-site On Plesk

It’s easy to setup WordPress in multi-site mode on Plesk.

Let’s assume you want to map:

to your multi-site installed on “acme.com”.

From an SSH login on the server, just edit the file:

If the file does not exist then create a new empty file.

Add the following line to the top of the file:

Save the file and tell plesk to reconfigure:

Now restart Apache:

Now you’re ready to go with multi-site.

There’s an article here that addresses subdomain and webmail issues:

https://codex.wordpress.org/Configuring_Wildcard_Subdomains_for_multi_site_under_Plesk_Control_Panel

0

WordPress xmlrpc.php (pingback) Vulnerability

We’ve seen many WordPress sites being abused recently via the Pingback function in xmlrpc.php. Here are some good articles on the topic:

http://www.incapsula.com/the-incapsula-blog/item/715-wordpress-security-alert-pingback-ddos

http://perishablepress.com/wordpress-xmlrpc-pingback-vulnerability/

If you don’t need xmlrpc.php or Pinkbacks then we recommend that you block xmlrpc.php in your .htaccess file by adding code like this:

Or you could rename or remove the xmlrpc.php file.

Here’s the config to block xmlrpc.php from Nginx:

3

Distributed Brute Force Attack On WordPress wp-login.php

Over the last few days many WordPress websites have encountered problems due to a massive distribute brute force attack on the wp-login.php script. The hackers are using a network (botnet) of compromised servers (bots) to repeatedly attempt to login to WordPress using common usernames and weak passwords. The botnet may contain as many as 90,000 unique IP addresses.

The scale of the attacks has created problems at some hosting companies:

IX Web Hosting
http://status.ixwebhosting.com/2013/04/11/global-server-wordpress-issues/

Hostgator
http://blog.hostgator.com/2013/04/11/global-wordpress-brute-force-flood/

Daniel Cid at Sucuri Blog discusses how these attacks have increased over the last few days:

http://blog.sucuri.net/2013/04/mass-wordpress-brute-force-attacks-myth-or-reality.html

There are a number of ways to mitigate the attacks including:

Password Protect wp-login.php

This is a good solution if you have a limited number of people who have to login to WordPress. Here are instructions from Hostgator on how to add password protection:

http://support.hostgator.com/articles/specialized-help/technical/wordpress/wordpress-login-brute-force-attack

Other hosts and control panels should be similar.

Rename wp-login.php

This solution is technically more difficult but it will defeat the attack without inteferring with user logins. See the discussion here:

http://wordpress.org/support/topic/how-to-change-from-wp-loginphp-to-login

Block failed logins with mod_security

Here’s a article from Liquid Web on this approach:

http://kb.liquidweb.com/wordpress-modsecurity-rules/

This may not be effective due to the large number of IP addresses in the botnet. If there are 90K addresses with up to 5 failed logins then you could have 450K login attempts. Also if you’re behind a load balancer or proxy then this approach will have to be modified to look at the X-Forwarded-For HTTP header.

Add Login Security Plugins

There are a few good plugins that you can add that will reject login attempts after a number of failed logins. Here’s an example:

http://wordpress.org/extend/plugins/limit-login-attempts/

Of course as with the mod_security solution, due to the size of the botnet this approach may not be effective.

1