Support

Admin Tools

#10241 The Great and Impossibe Task of Server Protection

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by nicholas on Monday, 23 January 2012 15:30 CST

skonnie
Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes (most pages, briefly).
Have I searched the forum before posting? Yes (also briefly)
Have I read the documentation before posting (which pages?)? Admin Tools User's Guide (.htaccess maker - Server Protection)
Joomla! version: 1.7.3
PHP version: 5.2.17
MySQL version: 5.0.83
Host: blacknight.com
Admin Tools version: 2.2.a2


Description of my issue:
I've been contentedly playing around with Admin Tools on four websites for quite a while...but only today did I attempt to create and implement .htaccess using Admin Tool’s maker. All appeared to be going swimmingly - I'd allowed direct access to files as necessary, and things seemed to be behaving themselves across the five most common browsers (latest versions in each case). Then I happened to test one site on IE8 - it turned out that a handful more exceptions were necessary. This was also the case for IE7 - different exceptions again. Admittedly, I shouldn't have been surprised. It makes sense that different browsers behave independently for a given website.....I'm sorry to draw out the question, but I'm simply wondering if, from your experience, this is likely to be a never-ending set of traps set by browser variations and major changes to site modules and templates? A single 404 error can render a site practically unusable. Surely this leaves Server Protection with nowhere to go...for me anyway. If I'm overlooking some glaring facts in the pursuit of stability, I would be interested to know, and offer apologies for my lack of knowledge. I realise I don’t have to use it if I don’t want to…..but I want to!

Regards and thanks,

John Collins

nicholas
Akeeba Staff
Manager
Great it is, impossible is anything but! Properly written Joomla! software should NEVER, EVER require you to put any exceptions in the server protection. In fact, properly written Joomla! software should only access everything through the index.php/index2.php files in Joomla!'s front- and back-end directories. Anything else means that the software is deliberately bypassing Joomla! and exposes your site to unknown threats – remember, bypassing Joomla! bypasses all automatic protection offered by Joomla! and Admin Tools' WAF as well. Just to give you an idea of how rare you need to bypass Joomla!, I've written four major components and only had to bypass Joomla! twice:
1. In Akeeba Backup Professional, in the integrated restoration feature as we are overwriting Joomla! with the backup. In this case, Joomla! files may be left in a "confused" state while we are extracting the backup, breaking the site. Therefore, we have to bypass Joomla! or we run the risk of the extraction failing.
2. In Admin Tools Core and Professional, the Joomla! update feature. Like a restoration, it replaces core Joomla! files with those from the update package and we have to bypass Joomla! for the same reason.
And that's the final list. Unless you are overwriting Joomla! core files, there is NEVER, EVER the need to bypass Joomla!. Every develop who doesn't understand that is a dangerous idiot (or he has ported non-Joomla! software to Joomla!, as is the case with eXtplorer and Virtuemart 1.x - not 2.x, that one's written from scratch). Unfortunately, there are hundreds of dangerous idiots with software listed on the Joomla! Extensions Directory.

But even in such a case of software bypassing Joomla!, the files which need to be accessed directly should be stored in a single directory or, at the very list, be a definitive list. This makes it relatively easy to figure out which ones they are and create the exceptions as per the documentation instructions you followed. If you run into new files all the times, it means one thing only: you are using RokGZipper or a similar CSS/JS aggregator and compressor.

Regarding RokGZipper, Andy Miller (the owner of RocketTheme) contacted me a few months ago after I said on Twitter that it's dangerous. I told him that the way it works, it places randomly named PHP files all over the site's directories. This means that the site owner has to allow any arbitrary PHP file anywhere on the site to run, which means that he can not guard against rogue PHP scripts planted by attackers. He didn't look very convinced that it can be done otherwise. I gave him some Proof of Concept code and told him they could use it (it's GPL). They seem to have chosen to ignore me. Their bad. I took my PoC code and put it to the latest dev release of Admin Tools. You can aggregate, minimise and compress CSS and JS files WITHOUT compromising the tiniest bit of your site's security. I really like RocketTheme's templates, but in my humble oppinion RokGZipper is a security nightmare and they don't seem to have the slightest intention to do anything about it. Huge shame :(

Oh, RokGZipper isn't the only plugin doing that. There are plenty of them on the JED. That's how I came to write my Proof of Concept code, tweak it and decided to ultimately include it in Admin Tools ;)

For the record, I had a similar conversation with JoomlArt over a year and a half ago, regarding the relative insecurity of rogue PHP file access. The difference with RocketTheme is that after I talked with Hung, he passed on our conversation to his developers and they had a valid workaround (putting such files in a dedicated, CDN-friendly directory) within 18 hours.

So, back to your site. Do you use a CSS/JS aggregator like RokGZipper? Or, do you use a template which automatically compresses its CSS/JS using PHP? This is the only way you can have the issue you're describing. And if you send me a Personal Message with a few affected URLs on your site I can certainly give you a workaround.

BTW, using PHP to compress CSS and JS is the single most inefficient thing you can do. If you enable the static media file compression option in .htaccess Maker you can have your webserver (Apache) do that for you, which is MUCH faster (about 2x-3x faster, according to my benchmarks).

I wonder if I should put all of this in the documentation :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

skonnie
Well, it's back to playing around wth non-website related toys...I'm a dangerous idiot, ye see!

Many thanks,

John Collins

nicholas
Akeeba Staff
Manager
Curiosity makes the world go round. Keep on being very curious :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

skonnie
Nicholas, may I compliment you on your previous post. It was greatly informative...made me sound like the victim and not the perpetrator...which is fairly reassuring. And yes, I DO have RokGZipper installed. But static media whatyemaycallit sounds like a plan.

I may have read the documentation for the first time again!

p.s...I have Modulus (Rockettheme) template installed with all the trimmings.

nicholas
Akeeba Staff
Manager
You're welcome :) My goal is to help you guys become security conscious and even "get" the whole security mentality. The truth is that software alone can't protect your sites. Software is tools. You have to know how to use it. Just like body armour. The good thing about software is that you can experiment and know that nobody will die if you screw up. At worst, your site might get hacked, but that's what backups are for. If only everything else in life was as forgiving as computers :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!