Be updated, subscribe to the OpenKM news

Definitive security guide for Joomla

Written by Josep Llort on 13 february

Joomla is a content management system – CMS - that allows you to develop dynamic and interactive websites. In recent years it has become very popular to create websites, as other tools such as WordPress. These tools allow the creation of personal and professional web, online stores and facilitate maintenance of web contents to non-technical users.

We can find solutions at very competitive prices that offer PHP support and PHP scripts where you can install your Joomla-based website, as well as pre-configured online stores based on Joomla.

Its undeniable success has made it enormously attractive for "black hackers" to exploit vulnerabilities for more than dubious purposes.

For years there has been an open debate in the open source community, about whether access to the source code of applications should be limited; because of that free access allows these guys with more than dubious interests to spend time locating security holes in the source for their own benefit. From the beginning, the spirit of the "open source" community has been to share the code under the premise that users of the community are active collaborators in the applications; improving them, cooperating in the solution of errors and making them more robust each day. But let us not fool ourselves, this well-intentioned idealism clashes head-on with reality. Not all humans are well-intentioned not all are altruistic; we do not live in UTOPIA. From my point of view both positions; "share versus close" the source code of the applications, are partly right in the discussion. So I don’t think that this open debate could be considered closed.

Nowadays we find the speed of the network has increased to unsuspected limits. I remember in those years when I connected to the Internet through my modem; the beginnings of mp3 file download and when the first 600MB DVDRIP appeared, I thought that was totally destined to fail. 600MB files at that time were unthinkable for home networks and only from centers such as universities could be achieved acceptable speeds for this type of downloads. I was wrong and nowadays the bandwidth is more than enough for this type of files and for other types of activities.

Among these "other types of activities" we find the "BOTS", automated malicious programs whose only mission is to track the Internet at high speeds looking for "Joomla websites with vulnerabilities". Unlike the marine ecosystems, on the Internet the small fish goes more easily unnoticed and can eat the big fish. We can find different types of attacks; those destined to the DDOS (denial of service), brute force attacks that try to login with the user "admin" or those that exploit vulnerabilities of the Joomla web content manager to get access at the OS level , installing ROOT KITS, sending SPAM, etc.
All those who at some point have managed a Joomla website and who periodically review the server's log files, can verify that malicious attempts to access them, almost daily and in a totally automated way.

Common problems in content management with Joomla

Maintenance over time

With Joomla I have encountered several problems; one of the most bleeding may be the difficulty of updating somewhat older versions. I will expose the case; a user acquired in time a commercial template for a certain version of Joomla. The large number of Joomla templates, the ease of installation and Joomla extensions are some of the features that allow a very affordable way to build a website based on Joomla with a really low cost.

We can easily apply a web design to our Joomla by acquiring a template at a very low cost; obtaining a final result on professional web pages. The costs of a custom-made web design for a website are high, both in time and money, so Joomla is proved as a highly attractive solution, hence the success of it.

The problem appears when the version of the Joomla website goes forward in time but the template is no longer compatible and we cannot upload the version so easily. Here it is the first crossroads; changing design is not an easy task, more if some features of this template are based on Joomla extensions, that eventually end up being deprecated. Here we have few options and none is really nice. Try to upgrade to a higher version and apply the necessary corrections at the level of source code, renouncing to those deprecated Joomla extensions and features or to put up with an application that has been definitively obsolete and that will not be able to be updated. Nobody said that the decisions were easy, that fantastic, fast and economic website that was set up 3 years ago has become a prison. As Joomla has progressed in its development; the updating processes have been friendlier although if we follow the support forums, we will see that they are not exempt from problems.

Joomla extensions

There are thousands of Joomla extensions; this offers the CMS great versatility and power but at the same time, it is one of their Achilles heels. By default Joomla comes with a lot of extensions that you probably do not need at all. You also have to be careful when installing some old versions that have not been updated. In short, the Joomla extensions are fertile ground for "black hackers" to find security holes. In all the security guides that prides itself, one of the first things that is indicated is to eliminate or deactivate as many extensions as are not necessary. Here we have another small inconvenience; one has to know what turns off; because moved by the unstoppable impulse to secure our website, we can easily leave the website inoperative by removing any extension.

Security breach

It is more than possible that even if you have followed all the recommendations of security and good practices someone end up accessing your server. Personally, this has happened to me once and it left a bad taste in the mouth. In my case, the website that I managed at that time was committed for 2 hours. In 2 hours many things can happen and none good. Several PHP pages were modified adding malicious code and the attacker used the server to send 150,000 emails. This was more than 10 years ago; I remember perfectly having contacted the computer crime brigade and I prefer not to go into details, I want to think that things have improved. I cannot say that I was more bitter due to the intrusion or use of the server during those 2 hours. I would have liked to speak with the "comrade of the communist bloc", and tell them that no matter how much talent exists in an intrusion; everyone knows that it is easier to destroy than to build. Preaching in the desert can only comfort one's spirit.

After an attack in which the system has been compromised one has to reinstall the operating system and the backup. And the worst thing is that the tool they have cast has left you with a feeling of distrust , that will no longer disappear.

Good practices

In many websites you will find a lot of good practices. Some are mandatory for any software ecosystem, others are more specific:

• Read calmly a few installation guides of Joomla and master the installation process.
• Make backup copies of database as of the files of the website.
• Be permanently updated to the latest version.
• Periodically check the logs of your website.
• Delete the admin user
• Establish some extension that provides greater security to Joomla websites; such as those that block a user when after more than 10 login attemps from the IP address. In short, install countermeasures against attacks based on brute force. We can find different extensions focused on solving this type of problems.
• Install the minimum number of possible extensions.
• Always use strong passwords.
• Use SSL certificates
• Install tools at the OS level to control the changes that take place in the filesystem (traceability of changes in the filesystem).
• Try to follow the news regarding security holes of both Joomla and its extensions.
• Allow access to the features that your users really need.

Having done all this, Can we be sure that our content management system is not going to be attacked? From my experience, as more powerful is the server on the Internet where we have our Joomla website, worse. The reason is simple; "black hackers" want to access powerful servers as long as possible for their interests. The powerful servers are definitely a sweet candy for these guys. We have improved our security; it will not be so easy, but be sure that you are your target. It's all about time.

The solution

This definitive guide aims to offer a proposal for all those who are looking for a security guide to apply to Joomla websites beyond conventional best practices.

My proposal is simple; part of the premise is that any website based on Joomla is vulnerable de facto and therefore the objective is to eliminate this possibility from the base. That is, that the Joomla website is not accessible directly from the Internet. What is not accessed will hardly be able to be hacked.

And someone will say; Have I had to read all this dissertation that I already knew, so that now they tell me that I can not have Joomla online? And then, What are you telling me? that I shouldn’t have it installed?

No, what I'm saying is that if we want to secure a Joomla website, the best option is not to provide direct access to it through the Internet.

But, if we do not provide direct access to Joomla from the Internet What good does it do to ? My proposal is to create a static image of the website and periodically update it.

Let's imagine that we have a Joomla base website; with the domain www.sample.com we can perform the following approach:

• A group of users will access the website through private.sample.com
• We will have a public image of the website at www.sample.com

Although there is some attempt to create some extension in Joomla to publish static content, at the time of publication of this article, I have not located anything that reasonably works well or does not go beyond being an experimental solution.

I firmly believe that any self-respecting CMS should allow the publication of web content in a static way. Based on my current knowledge, this is a crucial point when evaluating the implementation of a solution of this type and should be part of the selection process. In OpenKM for example, after evaluating different solutions we decided to "create our own static content publishing system" (in a future article we will talk in detail on this topic). From our document management system and "through the KCenter" (Knowledge Center) we created a tool that allows us to publish and maintain the web in a static way. In fact, his blog article is hosted in one of our enterprise content management systems and through an application that intermediates between the document management system and the website, we periodically update our website. In our particular case, the fact of having a powerful API in the document management system and the KCenter platform - that already offered us a large part of the features that we needed for the solution - allowed us to develop our own static content publishing system in less than a week.

We have not been exempt from receiving attacks ( our log proves it ), but at least we know that we will not allow access due to a security failure in the content management system that is beyond our control.

Configuration proposal

Apache configuration for the Joomla website:

<VirtualHost *:80>
  ServerName private.sample.com
  DocumentRoot /home/sample
  AcceptPathInfo On

  # security change from apache 2.4
  <Directory /home/sample>
	Options Indexes FollowSymLinks
	AllowOverride All
	Require all granted
  </Directory>

  CustomLog /var/log/apache2/private-sample-access.log combined
  ErrorLog /var/log/apache2/private-sample-error.log
  ErrorDocument 404 /messages/404.php
</VirtualHost>

We can define the subdomain private.sample.com in our DNS or simply add the entry in the hosts file, for those users who are really going to manage the contents of the Joomla website.
Synchronization script (joomla website mirror):

#!/bin/bash
#
echo -e "CLONE WEBSITE SAMPLE\n"
httrack http://private.sample.com -O /home/static/sample +*.sample.com -v --updatehack --update

echo -e "REMOVE local. from the url\n"
cd /home/static/sample/private.sample.com
rpl -x .html -x .html -x .js -x .txt -R private.sample.com sample.com *

echo -e "CHANGE PERMISSIONS\n"
chown static:www-data * -R /home/static/sample/private.sample.com
find . -type f -exec chmod 0460 {} \;
find . -type d -exec chmod 2570 {} \;
echo -e "DONE SAME !!!\n"

• The "httrack" utility allows us to create an image of the website (the first time that we use the command, we have to remove the parameters --updatehack --update).
• The "rpl" utility allows us to rename url's private.sample.com to sample.com.

We can schedule a task with the crontab so that it runs daily, for example every day at 11 o'clock at night:

# Edit this file to introduce tasks to be run by cron.
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
0 23 * * * /root/clone-static-sample.sh | tee /root/logs/clone-sample.$(date +\%Y.\%m.\%d_\%H.\%M.\%S).log

Finally the apache configuration for the website image:

<VirtualHost *:80>
  ServerName www.sample.com
  ServerAlias sample.com
  DocumentRoot /home/static/sample/private.sample.com
  AcceptPathInfo On

  # security change from apache 2.4
  <Directory /home/static/sample/private.sample.com>
	Options Indexes FollowSymLinks
	AllowOverride All
	Require all granted
  </Directory>

  CustomLog /var/log/apache2/sample-access.log combined
  ErrorLog /var/log/apache2/sample-error.log
  ErrorDocument 404 /messages/404.html
</VirtualHost>

Problems of the solution

This solution has at least one small drawback, the web form. If we have web forms these are going to stop working on an image of the website. We have to give up the web forms ?  Or apply a patch to the image of the website so that the forms work? My advice is to disable the web forms and not allow the execution of PHP scripts from the image website, that we have created.

Conclusion

In this article I have tried to provide a different approach to the security of websites based on content management systems. Especially all those that do not allow the publication in static way. It is a starting point that can be applied to both Joomla-based websites and other cms. The previous example and the tools used are based on the Linux operating system, while is possible use other operating systems and tools to obtain the same result.