WordPress Security and Selinux

Hello all,

Here we are again, today I am going to address WordPress, and the security of said platform, and how it could relate to Selinux, and SELinux in general.

Many have claimed that wordpress is in itself a flawed plattform and inherently insecure, I could not disagree more. Of course as with every web application there are a lot of security aspects to be taken into account and this should not be taken lightly. In my opinion there are a few things we could do to increase the security of our wordpress install and our website’s reputation intact or at least not at permanent risk. As most of you know I have in the past worked for one of the most famous hosting companies in the world, the Birthplace of Openstack and overal an awesome place to work at, and during my carreer there I have seen a lot of nonsense around wordpress installs, well the same could be said about several other CMS plattforms but I have to admit that WordPress is one of the most famous, amongst other things I have seen the following errors, but however there are others, these are just the most common :

1 – apache user owning the document root

2 – chmod 777 on the document root

3 – features developed that prevent wordpress or php from being updated

4 – outdated or exploitable plugins

5 – Selinux disabled

Let’s look at each one of them indivudually ,

1 – apache user owning the document root

This is very dangerous and will allow an attacker to exploit possible failures in wordpress to write to the document root of your website, the attacker will then use the file he or she uploads (usually a malicious script) to eventually download some sort of php shell (a piece of software that mimics the functions a shell would implement) and try to take control of your web server and website.

While installing wordpress take into attention the file permissions and the recommendations in the WordPress codex (https://codex.wordpress.org) regarding file permissions. Basically apache needs to be able to write to wp-content/uploads and not much more. If you plan on updating wordpress via the ftp feature, please create a user for that process that user could own the entire document root with apache only to read the files. Also if you are doing this please resctict the ftp process to localhost, as ftp is somewhat insecure.

2 – chmod 777 on the document root

This one is a big no … if your website has chmod 777 in the document root I would suggest that you place it under maintenance and review all the file permissions to what they should be. again the wordpress codex is a good place to start.

3 – features developed that prevent wordpress or php from being updated

This one is my pet peeve, it should never happen your developer should test if his code will still work in the case of a upgrade on wordpress at least. We could argue that if some function gets deprecated in a php version upgrade and that breaks your code, you should in my opinion pay your developer to perform the correct fixes. This might sound like I am parcial to developers, however I do insist that they should not work for free (nobody should really) and if your website’s reputation is important for you then you need to agree with him on  how to proceed. But the wordpress version upgrade should be starting point even before your website goes to production .

4 – outdated or exploitable plugins

This one is really a must, as I have said keeping wordpress and it’s pluggins updated is vital for the security of your website.

5 – Selinux disabled

In my opinion we should never have SELinux disabled, there are always ways to make it work and with the tools we have available (audit2allow, audit2why , etc ) there is no reason why you should have it disabled, instead learn how to use it, embrace it, at least if you are serious about security and about the website you are hosting. If you are not then you have no business hosting a website in the first place .

On my next post I will talk about ways you can improve the performance and perform some basic hardening of your wordpress instance.

Until then … stay safe !

 

Cheers

Rui