Apache Performance: Disable .htaccess here's why(haydenjames.io)
haydenjames.io
Apache Performance: Disable .htaccess here's why
https://haydenjames.io/disable-htaccess-apache-performance/
5 comments
I wrote a small script a while back to collect all the rules from various .htaccess files into one file you can then just include in your main config - might be useful for some. https://github.com/JMB-Technology-Limited/ApacheHtaccessIn Can then work with .htaccess files (a lot of third party apps use them) but automatically rewrite them into your main config for performance on production.
Isn't the support for htaccess basically one of the only reasons one would use apache in favor of nginx? I.e. that you can provide users some configuration possibilities on a multiuser system?
I run some servers with an apache/php/mysql configuration, we looked multiple times into nginx and that was always the problem: A user wouldn't be able to install any standard CMS without asking the admins for changes to the server config.
I run some servers with an apache/php/mysql configuration, we looked multiple times into nginx and that was always the problem: A user wouldn't be able to install any standard CMS without asking the admins for changes to the server config.
Did you look at the 'include' directive in Nginx?
I'm not sure about the security implications as I use this just for servers I control, but you can use a (just example naming) nginx.conf file in the website root, and use the 'include' directive in the main config file to read from that.
That's how I use Wordpress with Nginx to automatically write things like Yoast's Wordpress SEO or iThemes Security rules.
Something like:
I'm not sure about the security implications as I use this just for servers I control, but you can use a (just example naming) nginx.conf file in the website root, and use the 'include' directive in the main config file to read from that.
That's how I use Wordpress with Nginx to automatically write things like Yoast's Wordpress SEO or iThemes Security rules.
Something like:
include /var/www/domain/htdocs/nginx.conf;
If the included file is writable by the PHP user then I would say that poses a reasonably high security risk; potential privesc, information disclosure, RCE. Of course an attacker would need the ability to manipulate local files as the PHP user, but that isn't much of a stretch.
Under a typical install, e.g. Debian, Ubuntu, etc, nginx parses the configuration files as root thus any exploit of the config parser gains full root access as the nginx master process doesn't drop caps.
Depending on where the include line is placed it may be possible for an attacker to create server blocks allowing them to execute arbitrary PHP by permitting PHP execution from a directory with PHP write access, e.g. `wp-upload`. Assisting exfiltration of data by allowing easy remote access to the filesystem. Possibly proxy all traffic through an attacker controlled script or host. Exposing local services to the outside world.
I'm sure there's plenty of other interesting little attacks possible if given enough time to play around with it.
If at all possible I would avoid permitting unprivileged r|w access to nginx configuration files.
Under a typical install, e.g. Debian, Ubuntu, etc, nginx parses the configuration files as root thus any exploit of the config parser gains full root access as the nginx master process doesn't drop caps.
Depending on where the include line is placed it may be possible for an attacker to create server blocks allowing them to execute arbitrary PHP by permitting PHP execution from a directory with PHP write access, e.g. `wp-upload`. Assisting exfiltration of data by allowing easy remote access to the filesystem. Possibly proxy all traffic through an attacker controlled script or host. Exposing local services to the outside world.
I'm sure there's plenty of other interesting little attacks possible if given enough time to play around with it.
If at all possible I would avoid permitting unprivileged r|w access to nginx configuration files.
> If the included file is writable by the PHP user then I would say that poses a reasonably high security risk
It wouldn't be, just writable by the ordinary user. That pretty much negates the rest of what you said except for...
> Of course an attacker would need the ability to manipulate local files as the PHP user, but that isn't much of a stretch.
If that's happening you've got far worse things going on than having a nginx.conf file around.
It wouldn't be, just writable by the ordinary user. That pretty much negates the rest of what you said except for...
> Of course an attacker would need the ability to manipulate local files as the PHP user, but that isn't much of a stretch.
If that's happening you've got far worse things going on than having a nginx.conf file around.
Not the only one; in my case the nginx "rewrite rules" aren't as powerful as Apache's, and it'd be a huge PITA to migrate them over… :|
we have containers for that now right?
If you are hosting many small apache/php/mysql based sites, you most certainly do not want to run a seperate server instance for each...
Unfortunate the parent was downvoted, it's a valid conjecture, and a consequence of "containerize all the things" not a lot of people think through.
Simply answer the question; how many containers can any particular machine host? Ten's or hundreds? Depends on the hardware obviously, but there is a limit. So if each container is a paying customer, and you're in the busines of hosting containers (ie hyper.sh), that dictates your hardware/profit ratio.
Then consider a single multi-tenant server (ie apache hosting 10,000 low to medium use shared sites on the same hardware). Vastly more potential users (paying customers) on the same hardware.
Obviously this story has already played out and shared hosting has been in decline for years due to problems with the model; resource starvation (more active sites hogging cpu etc) and flexibility (cpanel). With containers you get so many benefits; infinite customizable, easy provisioning and deployment, tool support, etc.
But the value proposition remains. Multi tenant servers make so much sense (and potentially a lot more money per hardware unit), but resource limiting (cpu, heap, disk, io) at the application level has never been implemented to really make a a viable option. OS level limiting (ie cpulimit) is available, and that's what container hosts use for resource limiting.
My conjecture is that a suitable multi tenant server that can limit heap, cpu, and io at the account level should lower hosting costs by at least an order of magnitude. WHy pay $5 a month for a small container when you can pay $5 a year?
Simply answer the question; how many containers can any particular machine host? Ten's or hundreds? Depends on the hardware obviously, but there is a limit. So if each container is a paying customer, and you're in the busines of hosting containers (ie hyper.sh), that dictates your hardware/profit ratio.
Then consider a single multi-tenant server (ie apache hosting 10,000 low to medium use shared sites on the same hardware). Vastly more potential users (paying customers) on the same hardware.
Obviously this story has already played out and shared hosting has been in decline for years due to problems with the model; resource starvation (more active sites hogging cpu etc) and flexibility (cpanel). With containers you get so many benefits; infinite customizable, easy provisioning and deployment, tool support, etc.
But the value proposition remains. Multi tenant servers make so much sense (and potentially a lot more money per hardware unit), but resource limiting (cpu, heap, disk, io) at the application level has never been implemented to really make a a viable option. OS level limiting (ie cpulimit) is available, and that's what container hosts use for resource limiting.
My conjecture is that a suitable multi tenant server that can limit heap, cpu, and io at the account level should lower hosting costs by at least an order of magnitude. WHy pay $5 a month for a small container when you can pay $5 a year?
Anyone profiled a before/after for this?
Yes. The difference is pretty minor; it's a difference of a couple 'stat' calls per request, all of which are guaranteed to be cached in the kernel. If you're serving a lot of static content, it might start to be noticeable, but at that point you're probably better off using a different web server for that content. (Or putting it on a CDN.)
I was thinking the same about OS caching, but since the author didn't actually try that out it's still uncertain and a fairly useless article...
This is what I expected the author to have done. A bit of a disappointing article.
Same approach, just done ten years ago:
http://colin.mollenhour.com/2010/06/30/the-right-way-to-opti...
This has stats, again for whatever version Apache was up to decade ago (there was a while between releases).
> For my benchmark I ran “ab” (apache bench) since it is quick and easy but admittedly not the best for benchmarking overall site performance. In this case apache bench is going to under state the value of this tweak since one page load in a browser will result in repeated hits on the webserver, all of which will be affected by this optimization. So, I benchmarked on /errors/503.php so that the database is not factored but PHP code is still run. Specifically, I used $ ab -n 1000 -c 20 .../errors/503.php.
> Before: ~3000 requests per second (3018 max)
> After: ~4600 requests per second (5030 max)
> That’s a pretty nice improvement. Unfortunately it is only substantial with fast requests such as the error pages and static files but it should definitely reduce disk contention on a busy server and increase scalability, but probably not do a whole lot for user-experience on a low-contention server.
http://colin.mollenhour.com/2010/06/30/the-right-way-to-opti...
This has stats, again for whatever version Apache was up to decade ago (there was a while between releases).
> For my benchmark I ran “ab” (apache bench) since it is quick and easy but admittedly not the best for benchmarking overall site performance. In this case apache bench is going to under state the value of this tweak since one page load in a browser will result in repeated hits on the webserver, all of which will be affected by this optimization. So, I benchmarked on /errors/503.php so that the database is not factored but PHP code is still run. Specifically, I used $ ab -n 1000 -c 20 .../errors/503.php.
> Before: ~3000 requests per second (3018 max)
> After: ~4600 requests per second (5030 max)
> That’s a pretty nice improvement. Unfortunately it is only substantial with fast requests such as the error pages and static files but it should definitely reduce disk contention on a busy server and increase scalability, but probably not do a whole lot for user-experience on a low-contention server.
[deleted]
[deleted]
Found this:
https://thomaslohner.github.io/slides/Performance-Myths/
...looks to be at least +10% performance difference without .htaccess with basic static html. Probably more with many lines of rewrite rules.
...looks to be at least +10% performance difference without .htaccess with basic static html. Probably more with many lines of rewrite rules.
A little inaccurate, .htaccess is disabled by default (2.3.9 and later), so you do not need "AllowOverride None" unless it's enabled somewhere else.
Also some of the reasons why nginx doesn't support .htaccess files to begin with.