Topic: Joomla! 3 on SME 9

[DanB35]

This is somewhat a combination of how-to (or perhaps "how-did") and request for help.  I have installed Joomla! 3.3.6 on my SME 9 server, and it seems to be running fine.  The request for help is wondering whether I'm missing anything, or other recent write-ups.  I found some contributed RPMs, but they were for Joomla! 1.5 on SME 7.  I didn't see anything else on the wiki, though there were a few more recent posts on the forums here.

With that intro, here's a summary of my installation of Joomla! 3.3.6 on my SME 9 server.  At the outset, the 3.3 branch of Joomla! requires a newer version of PHP than ships with SME 9.  You can install Joomla! 3.2.7 on a stock SME 9 server, or upgrade PHP using the REMI repository (which I'd already done to support Owncloud).

To start, I created an ibay for the Joomla! installation, using the following settings:

Note that I'm the only user on my LAN--in an office environment, it would probably be better to set more restrictive permissions.

Then logged in to the server as root and created a database user:

Code: [Select]

# mysql
mysql> grant all on joomla.* to joomla@localhost identified by 'somepassword';
mysql> flush privileges;
mysql> quit
Then, as an unprivileged user, downloaded and extracted the Joomla! package:

Code: [Select]

$ cd ~ibay/../html/
$ wget https://github.com/joomla/joomla-cms/releases/download/3.3.6/Joomla_3.3.6-Stable-Full_Package.zip
$ unzip Joomla_3.3.6-Stable-Full_Package.zip
Next, I browsed to www.mydomain.com/ibay and used the web-based installer for Joomla!.  Set the admin username and password to something secure, and the database password to whatever you'd specified above.

At this point, you're done--you should have a working Joomla! 3 installation on your SME 9 server.  For an additional layer of security, I added a .htaccess file in the /administrator/ directory to allow access only within my LAN:

Code: [Select]

Order Deny,Allow
Deny from all
Allow from 192.168.x.0/24

I tried to set up two-factor authentication using Google Authenticator, but wasn't successful with that.  With the .htaccess locking down access to the backend, though, I feel I should be OK.

[stephdl]

Thanks....could you set up a wiki page

[DanB35]

http://wiki.contribs.org/Joomla_3

[stephdl]

At this point, you're done--you should have a working Joomla! 3 installation on your SME 9 server.  For an additional layer of security, I added a .htaccess file in the /administrator/ directory to allow access only within my LAN:

Code: [Select]

Order Deny,Allow
Deny from all
Allow from 192.168.x.0/24


Hi dan

why you haven't simply used the setting of ibay for restricting to your local network ?

[DanB35]

This configuration has the Joomla site accessible to the Internet, but the administration backend restricted to the LAN.  I didn't see a way in the server-manager to restrict just a subdirectory of an ibay.

[DanB35]

My wiki write-up does call for the ibay to be admin-writable, rather than world-writable, and to download and unpack the package as root.  Is there recommended ownership for the files, though?  Horde seems to be owned by root:root, while files in primary/html are admin:shared.  My steps in the wiki result in root:www ownership for everything except the configuration.php file, which is created by the web installer and is apache:www.

I'm leaning toward suggesting apache:www for everything.  Thoughts?

[guest22]

Nice work DanB35,

AFAIK, ownership of www:www to all files in the /html directory is recommended. Leaving html itself to admin:shared

guest



edit: typo

[stephdl]

Indeed Dan I misunderstood...nice work

[janet]

DanB35
 
A more secure way of implementing htaccess is detailed here
http://wiki.contribs.org/Htaccess

Also you can control access to sub folders using this
http://wiki.contribs.org/Https_redirection

[guest22]

A more secure way of implementing htaccess is detailed...

A new category has been added to the wiki, and htaccess is listed in this category.

http://wiki.contribs.org/Category:Security

[DanB35]

Janet,

What I'm seeing on the first link is a few ways to enforce password authentication for one or more directories (which may or may not comprise ibays).  The second provides a way to enforce https on one or more directories (which, again, may or may not comprise ibays).  I don't immediately see how either of those adds security or usability to what I've written up, though I may have a touch of tunnel vision to my own use case.

My application of Joomla is to build a "brochure" web site.  It will have a few pages of information about my business and a contact form--most likely, using Joomla for something this basic is gross overkill, but there it is.  The only user will be the admin, who is me.  The public web site will have no login page.  In the event I want or need to make any changes to the site while I'm away from my LAN, I can just VPN in.  Thus, for my use case, it seems that restricting the administration backend to only LAN IP addresses is both the simplest and the most secure option.

Now, if any administration will be done remotely by users who don't have VPN access, the https redirection may be a good idea (though in that case, it might be better to just enable it for the whole ibay--I think I'll edit the wiki entry to suggest this).  I don't see that adding a second layer of user/password really adds a lot, though--enter a username and password so you can get to the screen to enter a username and password?

The other security feature that seems worth pursuing is two-factor authentication, at least for the administrator.  It didn't work off the bat for me, but I haven't spent much time tracking down the problem yet.

[DanB35]

With a little bit of further investigation, the problems with two factor authentication resulted from a lack of the php-mcrypt extension.  I've edited the wiki page to discuss installing this.

[janet]

DanB35

Unfortunately you have totally missed the point of the first article, which is to demonstrate how to use custom templates instead of .htaccess files to achieve the same result (in a secure way, rather than an insecure way).

While commonly & widely used, .htaccess files are a weak implementation of a security function & SHOULD NOT  be used if you believe in the high security model of SME server. Hackers can get at your .htaccess files but they cannot get at your custom templates.

You should read again section
1.2 Solution
where the dangers in using .htaccess files is explained ie a security file that is publicly exposed.

This article gives a generic example in section
1.2.1 Determining the contents ..........
& this is what you would put into the appropriate custom template instead of into a .htaccess file.

Further sections 1.2.2, 1.2.3, 1.2.4 give specific cases of different auth methods that a user may commonly want to implement.

In your case just put the three lines you have determined for your .htaccess file into a custom template, following the method given in the examples, & DO NOT  use a .htaccess file.

Hope that now all makes sense.

While the article does show 3 detailed ways to create auth access, that is not the only thing you can do with custom templates/htaccess files.

[DanB35]

Of course there is a lot that can be done with custom template fragments, but if "the point" of the htaccess article was to explain why using a .htaccess file was a bad idea, I'm afraid it doesn't accomplish its goal very well.  The only indication of security issues with .htaccess is the following text:

Htaccess is not enabled by default and .htaccess files are inherently exposed to the Internet and require the correct permissions to be applied to ensure that unauthorised access is not allowed, therefore creating a security risk.
The recommended way to implement .htaccess on a SME server, is to use custom templates, which are only under the control of the administrator and cannot be tampered with by anonymous Internet users.

I disagree with the statement that .htaccess files are exposed to the Internet, as Apache appears to block them.  Try it--create a .htaccess file (doesn't matter what's in it) in primary/html, change its permissions to 666, and then try to browse to yourserver/.htaccess. You'll get a 403-Forbidden message (it will do the same even if there's no .htaccess file).  I also disagree that this fact, even if it were true, poses a security threat--at least in the use case we're discussing, the only thing an attacker would see is the IP range with access to the directory.  Perhaps in a situation where the .htaccess file contained specific usernames with access (as one of the examples in that wiki page), this would be a greater threat.

I further question how "anonymous Internet users" can "tamper[] with" the .htaccess file.  Even if it is world-writable (which it shouldn't be, though I'll admit I haven't said anything in my wiki page about permissions), an attacker would need to be logged into the server, or have found a remote code execution vulnerability in Apache, to be able to modify the file.  In such a case, an attacker could just as easily create a new .htaccess file as modify an existing one, so I again doubt that the existence (as opposed to the contents) of an .htaccess file could cause a security issue.

So, respectfully, I'm unconvinced that the use of .htaccess in this way is a significant security issue, or that moving its contents into a template fragment significantly improves security.  The Apache docs (specifically, http://httpd.apache.org/docs/current/howto/htaccess.html) do discourage use of .htaccess files, but primarily for reasons of performance, not security.

My reason for preferring to use .htaccess over a template fragment was simply that I wanted to keep the Joomla! installation as self-contained as possible, with minimal changes anywhere else in the system.  The database is unavoidable, and of course the software needs a place to live (the ibay), but I didn't want to leave any unnecessary cruft in the system if/when I later decided to remove Joomla!.

What's much more important out of that article, and what I'd missed until I started writing this reply, is that by default in SME Server, AllowOverride is set to None for all ibays, which disables .htaccess files.  This is the issue that's a showstopper for my use of .htaccess.  To make this work, I need to set a database configuration key, and if I need to muck about with that, I might as well do a custom template fragment.  I'll update the wiki page to reflect that.

[janet]

DanB35

Well you can argue the case for .htaccess files as much as you want with Charlie Brady, but I doubt he will be convinced. Hackers under the right circumstances could change the .htaccess file contents & allow undesirable access.

Using custom templates is inherently more secure, full stop.

What's much more important out of that article, and what I'd missed until I started writing this reply, is that by default in SME Server, AllowOverride is set to None for all ibays, which disables .htaccess files.  This is the issue that's a showstopper for my use of .htaccess.  To make this work, I need to set a database configuration key, and if I need to muck about with that, I might as well do a custom template fragment.  I'll update the wiki page to reflect that.

You could say that's part of the strict SME security model I was referring to.

[DanB35]

I guess I could take the matter up with Charlie, but he's not the one who's telling me that there's a security problem with my original design choice; you are.  This seems to be getting more confrontational than I expect either of us really intends, so let me try to back up a bit.

Maybe it's the way you're phrasing things, and maybe it's just me, but when you wrote, "Unfortunately you have totally missed the point of the first article", it set me off a bit, largely because it's simply factually incorrect.  The point of the first article, by its terms, was how to password-protect a subdirectory of an ibay--that was the stated "problem" to which it provided a solution.  What "how-to" was in that article, I didn't need--I know how to make a custom template fragment, and I know how to incorporate the appropriate directives in httpd.conf.  Yes, there were two sentences identifying purported security issues with using .htaccess, and one phrase (part of those two sentences) stating that .htaccess was disabled by default in SME Server.  Perhaps those two sentences were your point in providing the link, and if so, I did miss that.  Certainly if I'd read more carefully, I might have noticed that information the first time.  If you'd posted, ".htaccess is disabled by default in SME Server for security reasons, see http://wiki.contribs.org/Htaccess for another way to implement it", that likely would have helped as well.  I've since made some edits to that page that I think clarify the fact that .htaccess is disabled, and discuss some of the broader applications of the page.

I can accept that there's a marginal security gain in disabling .htaccess files system-wide.  I haven't yet found evidence that it's a significant gain--my web searching hasn't found much at all discussing security problems related to enabling .htaccess files--but since it can remove some control over Apache security from the admin, and give it to users who may not know what they're doing, it's reasonable to believe it would be more secure to disable them, and retain security control with the admin (who hopefully knows what he or she is doing).

But at the end of the day, whether I believe it's a security issue or not, it comes down to the fact that .htaccess is disabled by default.  To do the kind of access control I want to do, I need to either add a config database entry or create a custom template fragment, and either of those would need to be (or, at least, should be) manually removed if/when Joomla is removed.

[janet]

DanB35

You asked for improvements or better ways of doing your Joomla install, so I pointed something out to you.
Whether you agree/disagree technically & sematically is your choice & needs no further discussion.
If you search the forums (years ago) you will find supporting info & I note the original article was written in 2005, so using custom templates to implement htaccess requirements has been the recommendation for many years now.