Top Nav

Archive | WordPress

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

Find TimThumb Versions

Versions of the TimThumb script prior to 1.34 have a serious security vulnerability. Here’s a one liner to find the versions of all TimThumb installs on a server:

0

Discourage HTTPS On WordPress

Recently we had a WordPress site where that used HTTPS (SSL) on the login/admin areas. But we wanted to discourage HTTPS for non-admin URL. Here are the rewrite rules that ended up using in a .htaccess file:

0