Question can't block *.php while blocking other extensions

[seabiscuit]

Hi,
I'm playing around with .htaccess. I'm in a weird situation.

"https://www.mydomain.com/wp-content/uploads/test.png" returns 403 with the following .htaccess:

<Files *.png>
deny from all
</Files>

However, I cannot block "...../test.php" with the following .htaccess:

<Files *.php>
deny from all
</Files>

 

[seabiscuit]

Hi,

I've figured finally ...

The reason is "FPM application served by nginx" in PHP Settings. I've changed it to "FPM application served by Apache" .... and bingo.

But why?
This affects only the php files as far as I figured. No problem with the other extensions.

 

[ChristophRo]

.htaccess files are an Apache feature
All requests served by nginx, will ignore any .htaccess directives you have

If you enable the "Serve static files directly by nginx" option, your blocking will also no longer work for png and other image files.

 

[seabiscuit]

Thanks Christoph ...
I found this and followed it: How to disable XML-RPC in WordPress?

It works on domain basis very well. I also tried it at the service level with no luck so far.

How can I apply this as a server-wide nginx configuration for multiple domains in one go by adding directives in "zzmy_nginx.conf" which will be parsed by the nginx.conf. I walked thru regex and grabbed the basics but still not so confident to make such generalization.

 

[ChristophRo]

You can't (easily)
nginx does not support a lot of the stuff on a per server level that you could do with apache2.

And since you're now stuck with adding this to every single vhost, the only way is to modify the default template that Plesk uses to build the nginx configuration.
These templates can be found in /opt/psa/admin/conf/templates/ and you're looking for the file default/domain/nginxDomainVirtualHost.php
This can be copied into custom/domain/nginxDomainVirtualHost.php and edited to your liking - i.e. adding an "include zzmy_nginx.conf;" at the appropriate place, that then contains your desired custom configuration.
After that you can regenerate all nginx serverconfigurations and that's it.

BUT, beware - you need to check and most often redo these steps on every Plesk update, because the base template file has changed.
And as these updates happen every couple weeks now, you really need to think twice before going down that rabbit hole...

 

[seabiscuit]

Christoph, thank you so much for directing me to the right path. Since I'm pretty new to this stuff, I've overlooked the point you made.

Now nginx is at the front and it cannot work with .htaccess (I solved xmlrpc.php issue with nginx directives).

The next puzzle for me is the SQL injection prevention. Where can I put the SQL injection prevention directives that I've gathered from various sources. Those directives normally take place in the .htaccess file in the root.

 

[pleskpanel]

SQL injection prevention should take place at the application layer; htaccess and nginix were never intended as effective defenses against injection attacks.

 

[ChristophRo]

Using the Web Application Firewall (mod_security) 3.x would be the way to go.
Works with nginx and is designed to prevent SQL injections and other attacks on a server level scale.

But according to Plesk, this WAF 3.0 is very fresh and may not be ready for production yet.
Though if you only enable the SQL incections rules for now, I'm quite sure you will not run into any troubles. (as these rules are very generic)

 

[seabiscuit]

Thank you Gentlemen.... picture is getting clearer for me.

I've made a lot of reading recently only to find mixed messages. Some say turn mod_security off , some say it is indispensable. People from the first group is suggesting using .htaccess for SQLi directives. I've totally ditched this alternative... thank you pleskpanel.

I'll give it a try and install it. I'll go with baby steps by using only the SQLi rules for now as you suggested Christoph. Great advice...