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 !





Centos / Redhat Remove old kernel versions

Hello again

So today I started installing a few updates on one of my servers (centos 7) and had the following issue , I could not install the new kernel version because there was not enough disk space in /boot to accommodate the new kernel , so I went about removing the old files, and solving this problem permanently , so first I installed yum-utils

#yum install yum-utils

Then I used the package-cleanup utility (handy python script , yay python!!! )  that allows us to remove duplicate or orphaned packages.

Here is an example

#package-cleanup –oldkernels –count=2

so what this does is that it removes old kernels and keeps only the last 2 .

So this does what we want , which is to remove the older version of the kernel , however we might have this problem again in the future . Looking for a solution I have checked /etc/yum.conf and there we have the option


according to Red Hat and their deployment guide present here


…where value is an integer representing the maximum number of versions that can be installed simultaneously for any single package listed in the installonlypkgs directive.
The defaults for the installonlypkgs directive include several different kernel packages, so be aware that changing the value of installonly_limit will also affect the maximum number of installed versions of any single kernel package. The default value listed in /etc/yum.conf is installonly_limit=3, and it is not recommended to decrease this value, particularly below 2.


So , I changed the yum.conf to read


There , we have avoided this problem.

Of course that this has an impact on how many old versions of the kernel you wish to keep , and I do recommend that you set this value taking into account your needs … but for me at this point I feel that 2 is enough .





Dell Latitude E7440 Review

So , the company I work for has assigned me a laptop. The Dell Latitude E7440 which I am reviewing now. One of the requisites for me is that the device is fully compatible with any Linux OS , and this one is. I have loaded it with Fedora 21 and so far it has served me well . Although there are a few issues that have more to do with the laptop itself then the linux distro of choice.

One of the things that sort of disappointed me initially was the keyboard , it bends down when you press the keys in the middle (near the g and h keys) and the whole feel to it is not very nice overall . However the whole laptop is nice, the cpu is more than capable (I7 vpro) capable of good performance even when running a few vms  (which I do ) the model I got has 8GB of ram and a 128G Samsung PM851 SSD , fast and energy efficient as expected.

The camera is very good and the laptop is a very good buy apart from the keyboard issue I have already mentioned.

The Intel® Integrated HD Graphics 4400 works perfectly with Linux and the current version of Gnome (3.14.4) runs very well indeed.

I am still benchmarking the battery life , as I tend to use the device more attached to the docking station (did I mention it has a docking station)  .

More on this matter soon.

To wrap up , the device is a good buy if you are looking for a good Linux laptop, however the keyboard is not very good and Dell should improve this design failure.

You can check the full specs at Dell’s website here



Simpana … stop and disable

Hello World

So recently I was working on a automation project and, as a part of a scheduled work I needed to stop the commvault client Simpana, reboot a server and then safely restart the client, I wanted to make sure that the service was only started when I told it to, if you use one of the following

– Simpana stop

– Galaxy stop

when the service is restarted the simpana services are started back up ( as expected), the way to achieve this is simple :

Disable the services at boot

chkconfig Galaxy off

reboot , do what you need to do  and then

chkconfig Galaxy on

service Galaxy start

That is all 🙂