Je vous promets, cet article n'a rien à voir avec la religion, il traite de la sécurité des sites web. Le démon que je mentionne se refaire au fait d'ouvrir une éventuelle porte pour permettre aux pirates de compromettre votre site. Cet article est long mais je vous promets que vous allez apprendre des choses que vous n'avez jamais imaginées. Faisons la lumière sur le mystère du numéro 777 et tuons le démon !

Joomla!’s temporary off-line mode is a very handy option to temporarily take your site down while performing maintenance —e.g. updating the Joomla! core or an extension— and is even suggested by the official documentation for the unfortunate time that your site has been compromised. However, is this really off-line, or are there any pitfalls you should be aware of?

I promise you, this article doesn't have to do anything with religion. It talks about site security. The beast I am referring to is unwittingly opening a back door to your site to potential hackers. You may not know it, but you could be a sitting duck. It all lies in the dark world of ownership, users, groups and permissions. This is a long article, but I promise you to learn things you would have never imagined. Let us shed some light to the mystery of the 777 number and kill the evil beast!

As you all know, every new Joomla! installation comes with a Super Administrator account with a well-known user ID: 62. Nobody really knows for sure why 62 was chosen, but this can lead to your site's security being compromised. Why? It is a very well known value and potential hackers can take advantage of it in conjunction with another vulnerability to take control of your site. Known constants are a security nightmare as made clear in the case of the attack against Joomla! 1.5.5 which caused a lot of sites to be compromised as the researcher who found the vulnerability released it to the general public before the Joomla! team had a chance to fix it.

One easy workaround is to demote this well-known user account down to the Registered level and block it, hanging potential hackers to dry. However, in order to complete our security modification we do need another Super Administrator. The problem is that if you just create a new user his ID will be 63, which is not secure at all; it's a hacker's next best bet. So, we need a way to create a Super Administrator with a random ID, preferably in the 1-61 range which is otherwise unused in Joomla!. This is what we are going to do, folks, without even using phpMyAdmin for the task.

Note: You will be modifying your site's database. Even though the following procedure is well-tested, it's best to practice it on a local testing server first.

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!

We live in a potentially hostile world. Spammers, scammers, hackers and - alas! - script kiddies are after our site, for all we know. It's bad if - like most people - your site is your personal page. It's humiliating if - like many - it's the internet presence of your company. It's devastating if you are one of those people whose site is their business. Having regular, automated full site backups is a good first step, but they're only good at fixing a disaster after it has happened. Putting restrictions and controls (such as firewalls and tough passwords) 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 hacker, 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 eploit their back door today.

So, what can we do? Sit around, act casual until disaster strikes? No, not at all. What we need is a proactive check of our site files. If anything unusual is added, removed or modified the equivalent of a red alert should go off in our head and force us to take measures to contain and fix the problem before it's too late. It all boils down to an easy way to get a difference between the current state of our site and the last (and also known good) state of our site. This is the question I tried to answer with JoomlaPack SiteDiff.

Today I was reading Brian Teeman's blog post "Help my Joomla web site has been hacked!!". It outlines a pretty much scary story of site hacking. As we all know, security is a speed race. We have to upgrade our site software before a potential hacker gets wind of our outdated scripts, otherwise we run the risk of having our site compromised before we can react. What's more, the compromise might be exploited to the attacker's benefit long after we have upgraded the vulnerable site software, adding to our confusion. Quite a nightmare. But the hidden gem of this story, is a link back to Brian's "Are you a Dork?" post. He implies that attackers can easily guess the version of our site's extension, before breaking in our site. How can they? And what can we do to stop them? Read on for the full disclosure.

As a webmaster of several sites running on complex Content Management System solutions, I have regularly came accross the same issue: most CMS systems have some library directories which should be out of the reach of the random web visitor, yet they have to be on the same web-accessible location as the rest of the CMS. To top that, I also have the need to include some other private directories under the web server root, for example a downloads repository, just because PHP open_basedir restrictions won't let me do othewise. Is all lost, then? Is there no way to keep private directories really private?