2 Simple Tips To Secure Your WordPress Installation And Uploads Directory

Lately, I’ve seen a flurry of WordPress attacks that uploads files or alters the WordPress core files to make your sites do things that they really shouldn’t do.

This nefarious tasks can range from using your site to email spam to making your site a billboard for online drugs sales and injecting visitors’ browsers with malware. You can imagine that it can be quite tricky to hunt these things down – or even be aware that they are happening if you’re not careful.

So here’s a few steps that you can take to ensure that your WordPress site is secure from these attacks. If you manage the server, then you might want to update your httpd.conf and add the following configuration.

<locationmatch "wp-content/uploads/.*\.(php\d?|phtml)$">
 AllowOverride None
 Order Deny,Allow
 Deny from All

What this does is prevent PHP files from being accessed from a browser. Our server is configured to allow PHP extensions with .php2 through to .php5 as well as .phtml. To prevent this from being accessed – I’m using a regular expression to find all of these file types. The AllowOverride directive will prevent any .htaccess files being used as well. If a script has managed to upload files to your server, there’s nothing to stop them allowing access back to the php files so this is necessary to prevent this.

This configuration applies to any location that is matched, which applies to all of your websites, rather than using the Directory method, which is based on the local file system.

Another security measure to consider is making the WordPress site read-only. I know that it’s a chore to manually update your site and plugins – but I have seen WordPress core files modified to inject headers and redirect certain requests. This is a complete pain to find, so save yourself the bother.

If you do find that your site is hacked – the first thing that you should try is to reinstall the WordPress core files. If you haven’t made the files read-only, then you can do this by clicking on the Dashboard > Updates link in WordPress and then click ‘Re-install Now’. This downloads and installs a fresh version of WordPress over your current core files with no configuration changes.

If you’re still noticing unusual behaviour, then you should try removing unnecessary plugins and themes and check the wp-config.php file in in your site.

If you at least use the above two tips, then the chances of your site being exploited are greatly reduced.

XMLDom::Save() Permission Problem

I had been hitting my head against the wall when I couldn’t get an edited XML file to save due to file permissions, even though I know that it was OK.

For some odd reason, when I went to save the XML file, it would try to write the file to the root directory, instead of the current working directory (where the file is read from).

As such, using realpath() to keep the complete system path to the XML file when you load it will make sure that DOM isn’t trying to save to the incorrect directory:

$myfile = 'myxml.xml';
$myfile = realpath($myfile);
$doc = new DOMDocument('1.0');

// Let's just add a couple of elements for good measure
$root = $doc->documentElement;

$title = $doc->createElement('title');
$title = $root->appendChild($title);

$text = $doc->createTextNode('This is a title');
$text = $title->appendChild($text);


Getting Started With Amazon As a CDN – Part 1


Content delivery networks are all the rage now, so I’m looking at creating a CDN that will work nicely with my WordPress installation.

Rather than just blindly use a plugin, I want to make the code trustworthy and reusable among other blogs that I manage. Certainly the easiest way to get a CDN working on your blog is to use the Jetpack plugin from Automattic. This transparently turns the content on your blog into a CDN-delivered bowl of web content.

Some people might not want the full weight of the Jetpack plugin or to use the WordPress CDN so here we go. I’m going to step through the process that I used to get a CDN working myself. Continue reading Getting Started With Amazon As a CDN – Part 1

Ugly Font In NetBeans on Ubuntu

NetBeans Logo

A couple of times I’ve hit an issue whenever I install NetBeans on Ubuntu.

The fonts in the menu and explorers become bold. This is mostly not an issue, but when you are editing files the font changes from normal to bold so that you know that you have unsaved changes.

This appears to be a bug with the Oracle JDK, but it’s Ubuntu’s fonts that are triggering it. The easiest way to fix this until there is some proper resolution is to run the the following command to remove the fonts.

sudo apt-get remove fonts-unfonts-core

This will remove the fonts causing the issues. Restart NetBeans for the changes to take effect.

See the bug report at NetBeans for more information