If you have ever been a regular of the Joomla! forums you have most certainly come across some frustrated post of a paniced user whose site has been hacked. The truth is all web applications suffer from the same phenomenon, not because they are insecure by nature, but because most people don't have the slightest clue on what they are supposed to do to protect their site. Security isn't all that hard, but isn't all that straightforward, either. It's a bit like contraception. It's necessary, but no method is bulletproof. As a result, this article is not meant to be a complete guide to Joomla! security, but - very much like the Joomla! Security Checklist - it is just a set of guidelines you can easily follow, for that extra peace of mind.

This article was originally written in December with the intent of being volunteered to the Joomla Community Magazine. Three months down the road and things are still stagnating for JCM, mostly due to the unavailability of volunteers. I decided to post this article on my site for two reasons. First being, it would become irrelevant by the time JCM would finally be online. The second - and most important - being a call for volunteers. Joomla! needs you. Please, give some of your time to be part of this. Thank you!

Backup

Murphy's Law dictates that a catastrophy will strike when you don't have the means to revert to the last known good condition. Don't get caught without a backup! Major companies have failed because they didn't have a backup, or only a partial one. When talking about Joomla! sites, you need a complete backup of your files and database. The easiest way to produce a full site backup is Akeeba Backup, a popular free backup component in active development. Of course, I am a little biased - I'm its lead developer - but you can always trust the JED reviews and judge for yourself.

One important factor is how many backups you must keep and how you keep them. Keep at least a full month of daily backups, or 6 months of weekly backups. This way you can roll back to a safe known good position in time even if your site becomes compromised. Do not just keep your backups on the same server as your site! Download them to your hard drive and keep at least two copies on different removable media, e.g CD-ROM, flash disk or external hard drive, optimally each copy being stored in a different physical location. Even better, use a cloud storage service - such as Amazon S3 - to securely store one copy of your backup archive. You can never be too paranoid about securing your backup files!

Upgrade, yesterday

The best time to upgrade your core Joomla! installation and extensions is yesterday, not tomorrow! Of course you can't move backwards in time and that's why it's of paramount importance to stay up-to-date with security releases. You must subscribe to the JSST news feed, if you haven't done already, as well as keep a keen eye on the Vulnerable Extensions List. It goes without saying that you must also subscribe to the news feed of all extensions you have installed of your site. Upgrade immediately whenever a new release is out. Indolence is a deadly sin on the cruel world of the world wide web.

You may want to test the upgrades before applying them to your live site. Akeeba Backup is again your friend, as you can use your backup - you did take a backup, right? - to produce a "clone" of your site on a subdomain, or a local server, apply the upgrades and make sure everything's in working order.

Block user 62

You don't know what user 62 is? To cut a long story short, when you install Joomla! on your site it creates a Super Administrator account with a known username (admin) and a known user ID (62). This has been exploited in the past by crackers to gain access to unsuspecting sites. The best approach is to create a new Super Administrator user and block or demote the default admin user all the way down to Registered level.

Introduce multiple factor back-end authentication

All Joomla! sites have one thing in common: the back-end URL. It's always something in the like of http://example.com/administrator. You know what bothers me? This is susceptible to brute force attacks, i.e. somone trying arbitrary usernames and password until they can successfully log-in as Super Administrators. The best way to mitigate this problem is to introduce more obstacles in their unholy path to cracking your site.

One easy way to do that is using jSecure Authentication. This genius plug-in lets you define a secret word you have to know in order to access the back-end login page. If your secret word is "foobar" you must type something like http://example.com/administrator?foobar in your browser in order to log-in to the site, otherwise you are redirected to the front-page.

The other very effective means of protection is securing the administrator directory with a password. Most, if not all, hosting control panels allow you to password protect a directory. Well, do it! Password protect your administrator directory, so that you need to enter a username and password in order to see the back-end login page. When combined with jSecure Authentication you have a very strong back-end protection setup.

Obscurity is sometimes a good thing

Even though I am not a proponent of security through obscurity, sometimes it's a good way to deter script kiddies or make a semi-serious cracker's life difficult, urging them to seek an easier target. To this end, it's a good idea to make everything not required for your site's smooth operation inaccessible to the world. I've written an article about it in October you should read. Do note, if you choose to implement those rules, that they are purposedly overprotective. You might have to add exceptions for PHP files which are called directly, for example VirtueMart's payment gateway callback scripts.

ACL for the back-end

Trust me when I tell you that the default Joomla! back-end roles are not as secure as you might think. Especially the Administrator role, which is inherently very permissive, doesn't provide adequate isolation from potential breach from the inside. I can't further comment on that without opening a can of worms, but I have positively managed to escalate Administrator's permissions to the Super Administrator role. I suggest you to use a third party ACL solution to limit back-end users' access to specific core and third part components only, depending on the user's role in the site's management workflow.

File and directory permissions

We're touching a sore spot with this one, especially considering the widespread use of substandard hosts for hosting Joomla! powered websites. If your host doesn't make use of suPHP - which effectively takes cares of permissions - it's worth employing a strong set of permissions for your files and folders. If you have no idea what permissions, ownership, users, etc are all about, you might want to read my concise Introduction to web server administration first.

First, make sure that each and every file on your site has been uploaded through FTP, effectively making your account's user the owner of the file. Then, make sure that all directories have 0755 permissions and all regular files 0644 permissions. Finally, turn on the FTP layer in Joomla!'s Global Configuration. This ensures that most known cracking scripts, which require PHP being able to modify arbitrary files on your server, will fail.

Log grepping

This is an oft debated technique, but I find it useful. It is also essential post-mortem, i.e. if your site ever gets cracked, in order to backtrace the problem. Anyway, the whole idea is to download your site's access log and analyze it using an appropriate tool, searching for everything which shouldn't be there. Examples of "what shouldn't be there" are:

• Base64 encoded data
• SQL commands
• Script tags
• Unprintable Unicode characters

There are abundant resources on the web about log grepping. Don't get your head spinning a lot with that because, as I said, it's just another tool to monitor your site's health. Most of the times you can't do anything about the attacks on your site, but you can at least run them against a local copy of it so as to understand their impact - and detect potential breaches.

Modified files can be game over for your site

This is the final step. It's not meant to protect you, but act as an early warning system instead. Putting restrictions and controls is essential, but only if they don't fail. As Einstein bluntly put it "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former". An ingenius cracker, or a stupid script kiddie, might stumble upon a way to bypass your security controls and gain unauthorized access to your site. They can even hack you yesterday and exploit their back door today.

Even in this case, you need to know when you have been cracked so that you can act upon it. A very easy (conceptually!) way is to compare the state of your site to the last known good state. I have written a utility to help you with that, operating on two backup files, and an article on how to use it and interprete its results. The software is now stable, it's called Akeeba SiteDiff and is available for free from Akeeba Backup's download section.

Debriefing

Unfortunately, we have ran out of space! Security is a vast topic, one which won't even fit inside a well-sized book. All of the above are mere hints, a few good pointers to the right direction. Each one needs a bit of reading and some trial and error to implement. Remember that Rome wasn't built overnight. Try implementing one security checkpoint at a time and work through perfecting your security policy. It takes time but it's worth it, especially if you're making money out of your site, either directly (e-commerce, ads) or indirectly (driving potential clients to your business).

As a final thought, you might be wondering if you really need all of this security. The answer is, yes, you do! Don't think that only sites with a huge audience are susceptible to getting cracked. I've seen sites with a mere 30 visitors per month getting hacked. Why? I guess we'll never know, for the motives of the cracker can be diverse, obscure or beyond our reasoning. Your site can be a prospective cracker's shot at an andrenaline spike. Are you sure you want to be waiting for him as a sitting duck? I didn't think so.