[BlueOnyx:19764] Re: Enabling the rewrite module in Apache config

Fri Jun 24 15:16:19 -05 2016

This is a complex topic. I thought I would provide some details to help people to decide how they want to configure their boxes.

These settings enable a number of tweaks at an Apache level globally across all vSites. I did talk to Michael about possibly making them configurable at a site level. If I remember correctly, Michael advised they can only be set at an IP address level, not a vsite level.

Firstly, the “All” setting. I won’t discuss this… Turning on All is the same as ticking all boxes in that category. I will focus the discussion instead on the other settings that are not enabled by default.

1. Options: SymLinksIfOwnerMatch: This setting is not enabled by default. BUT, FollowSymLinks is enabled. If you were to turn on this setting, there is a zero additional security exposure or risk if FollowSymLinks is already turned on. In my opinion, it is smarter to turn this on - and disable FollowSymLinks… but thats another story.

2. AllowOverride: Options: This is more complex… Lets deep dive.

AllowOverride settings determine what stuff can be changed in a .htaccess file. What is a best practice setting? The Apache documentation says:

In general, you should never use .htaccess files unless you don't have access to the main server configuration file. There is, for example, a prevailing misconception that user authentication should always be done in .htaccess files. This is simply not the case. You can put user authentication configurations in the main server configuration, and this is, in fact, the preferred way to do things."

".htaccess files should be used in a case where the content providers need to make configuration changes to the server on a per-directory basis, but do not have root access on the server system. In the event that the server administrator is not willing to make frequent configuration changes, it might be desirable to permit individual users to make these changes in .htaccess files for themselves."

If all of your websites are under your control, leave it off and go do your settings in include files as suggested by michael /etc/httpd/conf/vhosts/siteX.include. What about web hosting providers? What is the risk? What does the Options directive in .htaccess allow you to do anyway?

The Apache documentation is here…

https://httpd.apache.org/docs/current/mod/core.html#allowoverride <https://httpd.apache.org/docs/current/mod/core.html#allowoverride>

In simple terms, this setting will allow changing options like the ones that are all enabled by default. Eg FollowSymLinks, Includes, Indexes, MultiViews, SymLinksIfOwnerMatch. Looking at all of the above, AllowOverride options sounds reasonably safe. Providing this access allows your clients flexibility without having to open tech support cases to do weird stuff… but there is one more thing that is not covered above

http://php.net/manual/en/configuration.changes.php <http://php.net/manual/en/configuration.changes.php>

These changes allow your customers to change in .htaccess files settings relating to PHP. Sometimes, their web applications need settings to be tweaked.

http://php.net/manual/en/ini.list.php <http://php.net/manual/en/ini.list.php>

The above is a list of all current PHP settings that can be changed. If you have AllowOverride Options enabled, your clients can change everything that is not listed as PHP_INI_SYSTEM in the list above. The biggest risk in my opinion relates to open_basedir. If you have set a restriction in your gui that prevents a user from going to stuff outside their home directory, they can bypass this setting in .htaccess. The good news is that this setting was invented to protect websites that don’t run without suphp or similar. If you use suphp, mod_ruid2, or FPM, there is another layer of protection that prevents access or modification to files based on file system permissions.

What is the ultimate recommendation? What do I do myself? The most important setting is to use suphp, mod_ruid2 or FPM for all PHP enabled sites. By doing that, the worst case scenario in that case is they can create an exposure that will affect their own site… but the rest of your server is still protected. All of my client sites are protected in this way. Therefore, I am comfortable to enable AllowOverride Options. It makes my life easier, allowing clients to do the tweaks they need without hassling me.

Regards,
Greg.

> On 25 Jun 2016, at 4:20 AM, Chuck Tetlow <chuck at tetlow.net> wrote:
> 
> That's what I'm afraid of Michael. 
> 
> That "AllowOverride - ALL" is a server-wide setting.  And wouldn't that open it up to possible vulnerabilities, maybe in other older-software sites on the server?  We've got some customers who are running 10 year old PHP sites on our newer BlueOnyx servers - and having problems already.  
> 
> Not to mention...  At least three or four times a year - someone finds & exploits a vulnerability in one of our customer's sites or users accounts.  Then the server is sending out tons of SPAM, getting blacklisted, and the other users on it are bitching that they can't send e-mail. 
> 
> So I'm VERY leery of activating any abilities that might allow a exploit in the future.  And I'd read that the AllowOverride option could do exactly that. 
> 
> 
> Chuck 
> 
> 
> 
> ---------- Original Message ----------- 
> From: Michael Stauber <mstauber at blueonyx.it> 
> To: BlueOnyx General Mailing List <blueonyx at mail.blueonyx.it> 
> Sent: Fri, 24 Jun 2016 12:55:31 -0500 
> Subject: [BlueOnyx:19762] Re: Enabling the rewrite module in Apache config 
> 
> > Hi Chuck, 
> > 
> > > Does anyone have any experience with, or recommendations on enabling the rewrite 
> > > module in the Apache config? 
> > 
> > It's enabled by default on all BlueOnyx versions. You can verify it this 
> > way: 
> > 
> > [root at 5209r ~]# /usr/sbin/httpd -M|grep rewrite 
> > rewrite_module (shared) 
> > 
> > So you (or your site developer) should be able to use it. 
> > 
> > If you want to create your own rewrite rules, they can either go into 
> > the Vsites include config file: 
> > 
> > /etc/httpd/conf/vhosts/siteX.include 
> > 
> > ... where they won't be overwritten by any changes. Or they could go 
> > into .htaccess files in /web or subdirectories of your actual Vsite. 
> > 
> > For some of these functions to work in .htaccess files you need to allow 
> > them first via the GUI. For that see "Server Management" / "Network 
> > Services" / "Web" and see under "Options" and "Allow Override". You may 
> > have to tick both "All" checkboxes. 
> > 
> > -- 
> > With best regards 
> > 
> > Michael Stauber 
> > _______________________________________________ 
> > Blueonyx mailing list 
> > Blueonyx at mail.blueonyx.it 
> > http://mail.blueonyx.it/mailman/listinfo/blueonyx <http://mail.blueonyx.it/mailman/listinfo/blueonyx> 
> ------- End of Original Message ------- 
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20160625/0854a711/attachment.html>