Support

Admin Tools

#30359 security questions with nginx

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 toonetcreation on Thursday, 18 October 2018 04:47 CDT

toonetcreation
Hello,

I have read nginx configuration documentation and I have some questions:

1) I see that Password protect administrator feature/button is not enabled/displayed anymore. So how to add .htpasswd protection as previously? what is your advice ?

Add a directive like this to every nginx vhost?

location / {

try_files $uri $uri/ =404;

auth_basic "Authentification needed";

auth_basic_user_file /var/www/my_website/administrator/.htpasswd;

}


2) As nginx does not use .htaccess files, I have added this directive into my nginx configuration :

# deny running scripts inside writable directories

location ~* /(images|cache|media|logs|tmp)/.*\.(php|pl|py|jsp|asp|sh|cgi)$ {

return 403;

error_page 403 /403_error.html;

}


Previously, every directory tmp, logs, images had an .htaccess file to do that..like this :

<Files *.php>

Deny from all

</Files>


So now, this .htaccess file is not necessary ?

3) About nginx configuration maker : I don't want to add custom file to website root directory and I prefer using the second option you described : adding Security Enhanced & Highly Optimized NginX Configuration File for Joomla to nginx website vhost.

So this is correct (include security conf line) ?

server {

listen 80;

listen [::]:80;

server_name my_website.com;

return 301 https://www.$host$request_uri;

}



server {

listen 443 ssl http2;

listen [::]:443 ssl http2;

server_name www.my_website.com my_website.com;

root /var/www/my_website;

index index.html index.htm index.php;



access_log /var/log/nginx/my_website.access_log;

error_log /var/log/nginx/my_website.error_log info;



include /etc/nginx/conf/security.conf; #custom file generated by admin tools nginx configuration maker



ssl_certificate /etc/letsencrypt/live/my_website.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/my_website.com/privkey.pem;

ssl_trusted_certificate /etc/letsencrypt/live/my_website.com/chain.pem;



include /etc/nginx/conf/ssl.conf;

}


4) I have added modsecurity to nginx with owasp-modsecurity-crs-3.0.0 rules.
Do you think these rules are useful/necessary if I use admin tools custom file generated by admin tools nginx configuration maker ?

Many thanks for your help
L.

nicholas
Akeeba Staff
Manager
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.

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!

toonetcreation
1) Ok I will try

2) Ok thx.

3) Perfect ;-)

4) Yes this is "the big problem"...devote a lot of time to make "security tuning"

Last question : I'm using joomlart template. based on your experience, do you know if this is mandatory/needed to add templates/template_name on section Allow direct access, including .php files, to these directories ?

thanks

nicholas
Akeeba Staff
Manager
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.

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!

toonetcreation
Hi,

Many thanks for your detailed explication, that was pretty much what I thought.

Today I'm not using LESS feature provided by joomalrt templates.

But regarding css + Js compression, this means I don't need to use default template option as described in attached file?

nicholas
Akeeba Staff
Manager
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.

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!

toonetcreation
Ok I will perform some tests ;-)

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

Because I'm facing issues to enable this feature and I know I can handle it with apache conf, but as I am using nginx, I don't know if I can do that with directives generated by admin tools?

what is your advice about that?

nicholas
Akeeba Staff
Manager
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.

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!

toonetcreation
Yes I understand perfectly.

So that means If I host for exemple 10 websites on my server, the best way should be to add 10 files into /etc/php/7.2/fpm/pool.d (1 file per website) looking like this (to do fine tuning) ?

[site1]

user = site1

group = site1

listen = listen = /run/php/php7.2-fpm-site1.sock or 127.0.0.1:9000

listen.owner = www-data

listen.group = www-data

php_admin_value[disable_functions] = exec,passthru,shell_exec,system (applied globaly?)

php_admin_flag[allow_url_fopen] = off (applied globaly?)

pm = dynamic

pm.max_children = 5

pm.start_servers = 2

pm.min_spare_servers = 1

pm.max_spare_servers = 3

chdir = /


If yes, there is no impact on websites and server performance to run 1 specific user and group per website ?

nicholas
Akeeba Staff
Manager
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.

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!

toonetcreation
many many many thanks for all your advice and confirmation, I know this is out of your scope and I promiss I stop now :-)

I will make some tests to get a more accurate configuration, thank you again ;)

L.

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!