WordPress Ultimate Security Post Part 2: Back up practices & Linux security settings

Welcome to the 2nd post in this series of WordPress security articles. The first, if you missed it, covers SSL and Firewalls and can be read here.

Today’s post deals with 2 topics of no less importance – back ups and server level security.

Let’s get started.

1. Back Ups

As with all the topics I discuss, half a post (or even an entire post) cannot hope to cover all the ins and outs associated with the subject – so I attempt to give an overview that will hopefully prompt further investigation and actions on the part of the reader.

i) Hosting Provider – Firstly, the best place to check regarding back ups is your hosting provider.

Many hosts will include daily back ups as part of the hosting service you pay for.

This back up is all well and good, but you should always check the policy regarding restores. In many cases, the hosting provider will tell you that daily back ups are included only for you to discover that should you need to restore the data, additional charges are incurred.

This assumes that the back ups themselves are successful (I have come across many situations where the client has sat back assuming back ups were being made, until the first time they visited the hosting control panel to see that none of the back ups had been successful and had failed due to one reason or another).

In addition, many hosting companies allow you to download a back up of the site and database, but only manually and not scheduled on an automatic schedule.

DO NOT rely on such an option, as reliance on a manually triggered process could find you with a 5 month old back up next time you need to restore…

ii) WordPress plugins and 3rd party back up services

Although WordPress itself doesn’t have any built in options for back ups, there are plenty of 3rd party plugins that can do the job for you.

Good options are UpdraftPlusVaultPress and BackupBuddy

These are all commercial plugins/services that support both on server and offsite back ups.

The offsite back ups will require you to have an account with an external storage provider such as Google Drive, Dropbox, Amazon S3 or custom FTP.

If the service offers the option, it is often a good idea to configure the back ups to store the latest 3 or 4 daily back ups on the server itself and store 7-10 days worth offsite on the cloud.

This should help strike a balance between ability to restore recent data whilst reducing the storage space required.

Of course, each website will have its own requirements for back ups, but the example guidelines above are recommended for a standard corporate website.

iii) Good old SFTP/MySQL client

This one is only for the very technical ones among you.

With SFTP access, you can download the site or updated files on a regular basis, manually or with a scheduled batch script. Likewise, the database can be downloaded using a SQL dump with a MySQL client.

These options are probably best for back ups before site migrations and less useful for regular back ups.

Finally, whichever option you go for (ideally a few of them combined), check you can successfully restore the back ups at least once every 2-3 months to make sure the data you are backing up is not corrupted.

You’ll be glad you did.

2. Linux security options

This section is quite technical, and your DevOps team will already be aware of everything listed here – but it should at least give you the basic info to be able to ask if these things have been implemented for your site/server.

i) UFW

In the previous post, we looked at how external services such as Cloudflare can protect your site before a hacker can even get to your server.

Now, either as additional protection or in the case where the hacker has got past your WAF, lets examine what can be done at the server level.

For this, I am assuming that you are running WordPress on a Linux distro as opposed to a Windows server (whilst its entirely possible to run Apache on Windows – its certainly not the preferred option).

If you are using Debian, Ubuntu or Arch Linux, you can implement something called UFW.

This stands for Uncomplicated Firewall, and is strongly recommended as a robust option to control access to your server from the outside world.

I am not going to start explaining the command line options for implementing this as much as I will just recommend that you block all incoming access by default and then add the following ports for overriding that block.

443 – If your site is secure and is using SSL, then this is the port that should be open to the outside world and will allow visitors to access your website. The standard http port, port 80, should be blocked since there should be no reason your site is running insecurely.

22 – You or your developer will still need to be able to access a terminal to perform configurations, file transfers and other server related tasks, and port 22 will allow you to do that. However, if possible, the port should only be given access to whitelisted IPs and blocked to all other (for example, allow access to your office IP and/or Home IP address).

All other ports such as 21 for FTP, 3306 for MySQL etc, should not be opened up to remote access at all.

ii) Apache basic authentication using htpasswd

Your WordPress admin is protected by the WordPress login. It is a very good idea to supplement that with an additional server level login.

Apache provides us with the ability to do so. The entire directory of your wp-admin can be protected using a combination of something called .htaccess and .htpasswd files.

The .htaccess file is placed in the wp-admin directory and references the .htpasswd file, which contains a list of the users that can access the directory.

The result is that when a user tries to access the WordPress admin, they will now get a pop up login box which is generated by the web server – and only once they have logged in here, will they then get the regular WordPress admin login screen.

This added layer of security makes a HUGE difference in helping to stop bots trying to brute force guess your login credentials.

As with all security, this obviously comes at the expense of convenience.

Nobody really wants to login twice to get into the admin, but the debate of convenience vs security is a never-ending one and the balance will vary from user to user.


I’ll conclude this current series next week, when we will be looking at WordPress specific application level security steps such as obfuscating your admin URL, logging accesses to the WordPress admin and much more.

As always, for more information and advice on how to protect your online content investments, contact us at [email protected] or visit our website at https://www.leadmetrix.net

Leave a comment