Support

1. I believe that should be correct. I have not tried it myself.

2. This is not required since the NginX Conf Maker's Frontend and Backend Protection features take care of that for you.

3. Yup. That's exactly what I had in mind when I was writing about the second possibility in the documentation.

4. Yes, they are useful. Since mod_security2 is used on most servers we didn't try to replicate its functionality (not to mention reinventing the wheel rarely results in a rounder wheel...). You will have to do a bit of gardening, though. They are very broad in their scope and will most definitely cause you trouble using your site. Scan your error logs for the rule number which is being triggered and review the rule. This process may take weeks until you have blacklisted the rules which do interfere with your site's operation.

4. "I believe in the old and sound rule that an ounce of sweat will save a gallon of blood." -- General George S. Patton

Regarding JoomlArt templates, I haven't used one in many years. To the best of my knowledge as long as you stay away from any compress / combine CSS and JavaScript option (which are a massively terrible idea* anyway) you are safe. You should also stay away from dynamically compiling CSS files from LESS / SCSS sources, something which is also a terrible idea** anyway. So, if you ask me, if you end up having to use the allow direct access feature you are doing something fundamentally wrong which screws up the real world performance of your site and opens it to security risks. Don't do it. Use common sense and critical thinking over blind trust in automated tools.

* So, it's almost 2019 now and there's absolutely zero need to combine and compress CSS and JS files using PHP code. Servers are more than an order of magnitude faster at compressing static resources than by using PHP code. Combining is largely unnecessary since browsers don't do a separate HTTP connection for each resource like they used to in 2010 but instead keep up to 8 connections to the server open at the same time and reuse them to request more files. These compress & combine tricks only exist to make automatic site analyzers give better scores at the expense of real world performance. People don't understand that analyzers (like YSlow) are geared towards application sites where the development team is in control of every bit of the site and they can and do combine CSS and JS during deployment (not on the fly) in a way they can test is not breaking the site. This is impossible for CMS-based sites with software from a dozen or more vendors installed on it. Trying to automatically combining and compressing static media on the fly is both far slower than delivering separate files and less likely to work without breaking your site.

** Recompiling SCSS / LESS files into CSS is a process which takes several seconds. In comparison, transferring the compiled, minified and compresses CSS from a server at the other end of the world to your browser would take less than 0.5 seconds. Therefore the benefit of dynamically updated CSS is completely nullified by your site taking forever to display correctly, driving people away. Compiling CSS as needed (either directly on the site or locally and uploading to the site) is the best way from a performance point of view.

No, I strongly recommend against it. In fact you can try them and see how your site's speed is negatively affected (and how you quickly get problems with third party plugins, modules and components). I think that is the best way to understand why these options are there to make automated tools happy, not to solve any real world issues.

About open_basedir php value, is there any way to include/manage it with admin tools?

No. This is set either in your php.ini or a .user.ini file. The latter only works for tightening the open_basedir.

I am against using open_basedir. It's an architecturally incorrect way of ensuring permissions. If a script finds a way to escape the not-so-robust PHP jail (e.g. you can somehow trigger an external command or feed parameters to a script unencumbered by open_basedir restrictions) you get a nice, fat security issue.

The correct way to enforce filesystem permissions is... well... filesystem permissions. At the operating system level :) This is trivial since NginX uses FastCGI to run PHP which means that every site you are hosting can (and should!!!!!) run as its own user.

open_basedir is a dinosaur, a leftover from the days when PHP could only run as an Apache module, therefore all sites hosted on a single server had to run under the same user. This led to open_basedir and Safe Mode which were bad "solutions" to a real problem which could not be addressed otherwise. Nowadays we have at the very least FastCGI, typically also virtualization and containerization, i.e. solutions which let us put hard borders around each site hosted on a physical server.

OK, this is getting waaaaaay out of scope. This will be my last post on server config :)

Yes, create a new FPM pool per site. For performance reasons it's advisable to use a socket instead of TCP/IP.

The PHP configuration should be applied globally, in your php.ini file. Don't set it up per pool, it makes no sense.

You MUST NOT disable allow_url_fopen. If you read that as good advice somewhere, the person who wrote it has not kept up to date with PHP security for over a decade. I bet it's the same place where you read about open_basedir...

For well over a decade the flag you MUST disable is allow_url_include. This flag was added in PHP 5.2.0, released on November 2nd, 2006. Not a typo. Two thousand six, almost twelve years ago. Check the PHP documentation to understand the difference between them.

Disabling URL fopen may have the opposite effects in security since many web applications will fail to retrieve updates and / or fail to communicate with third party services. What you want to disable is including arbitrary executable code over the Internet which is exactly what allow_url_include = false does.