Things to do before your site gets hacked

Joomla! is often bashed by unknowledgeable people as insecure. How little they know! The fact is that no system is airtight, unless you do your part to secure it. Most people coward away hearing as much as the word “security” itself. You don’t have to! Securing your site is rather easy, if you know what, where, and how it needs to be completed. This article may only scratch the surface, but will provide you with enough advice to perform a major upgrade in your site’s security in a few, easy steps.

If you have ever been a regular of the Joomla! forums you have most certainly come across some frustrated post of a panicked 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 do not have the slightest clue on what they are supposed to do to protect their site. Security is not very hard, but is not very straightforward, either. It is a bit like contraception. It is 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.

Backup

Murphy’s Law dictates that a catastrophe will strike when you do not have the means to revert to the last known good condition. Do not get caught without a backup! Major companies have failed because they did not 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, DropBox, Wuala, or Ubuntu One – 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 cannot move backwards in time and that is why it is of paramount importance to stay up-to-date with security releases. You must subscribe to the JSST news feed, if you have not 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 sub-domain, 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 user-name (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 is always something in the like of http://example.com/administrator. You know what bothers me? This is susceptible to brute force attacks, i.e. someone trying arbitrary user names and password until they can successfully log-in as Super Administrator. The best way to mitigate this problem is to introduce more obstacles in their unholy path to cracking your site.

The genius jSecure Authentication 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 user name and password in order to see the back-end login page. When combined with jSecure Authentication you have a very strong back-end protection set-up.

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 is 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, which you should read. Do note, if you choose to implement those rules, that they are purposely overprotective. You might have to add exceptions for PHP files which are called directly, for example VirtueMart’s payment gateway callback scripts, or eXtplorer’s fetchscript.php file.

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, does not 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 work flow. Thanks to the efforts of the core developers, Joomla! 1.6 will make it possible to define such ACLs using no third party extensions.

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 is 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 back-trace the problem. Anyway, the whole idea is to download your site’s access log and analyse it using an appropriate tool, searching for everything that should not 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 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 ingenious 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 interpret its results. The software is now stable; it is called Akeeba SiteDiff and is available for free from Akeeba Backup's download section.

Debriefing

Unfortunately, we have run out of space! Security is a vast topic, one that 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). In the following issues of the Joomla! Community Magazine I will introduce even more security ideas and practical ways of enforcing them on your own site.

As a final thought, you might be wondering if you really need all of this security. The answer is, yes, you do! Do not 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 adrenaline spike. Are you sure you want to be waiting for him as a sitting duck? I didn’t think so.