Resolved Keep changes in nginx.conf

[garcue]

Hi all,

I need to keep some configuration parameters in the nginx.conf file of a particular domain. But with some update the file is overwritten or modified by deleting my rules. Do you know how to make them last in the face of modifications?

a greeting

 

[Monty]

Where did you apply the custom nginx config?
If you do it at Domains => <domain> => "Apache & nginx settings" then the settings should persist across updates...

 

[garcue]

Where did you apply the custom nginx config?
If you do it at Domains => <domain> => "Apache & nginx settings" then the settings should persist across updates...

Hello Monty,

What you mention I already use it for some configurations and goes to the file "vhost_nginx.conf". These parameters that I have implemented do not load if I put them in the vhost file, they must be in the nginx.conf of the domain in question.

Hence my big problem

 

[G J Piper]

Hello Monty,

What you mention I already use it for some configurations and goes to the file "vhost_nginx.conf". These parameters that I have implemented do not load if I put them in the vhost file, they must be in the nginx.conf of the domain in question.

/var/www/vhosts/system/domain.ext/conf/nginx.conf

contains:

include "/var/www/vhosts/system/domain.ext/conf/vhost_nginx.conf";

so entries in Domains => <domain> => Apache & nginx settings should work for you in most cases.

 

[Monty]

@garcue Just to make sure: Did you already try plesk repair web ?

 

[trialotto]

@garcue

I suppose that there is some misunderstanding in this topic thread.

On the one hand, you are asking about persistent nginx config that cannot be placed in the regular server or location blocks.

On the other hand, there are responses in this topic thread that are pointing in the direction of location block related customization of Nginx config for specific domains.

There is a huge difference between the two.

So, returning to your original post and question

Hi all,

I need to keep some configuration parameters in the nginx.conf file of a particular domain. But with some update the file is overwritten or modified by deleting my rules. Do you know how to make them last in the face of modifications?

a greeting

I have the following answer and solution for you:

- create a file called <name>.conf in the /etc/nginx/conf.d directory
- place your custom directives in that file <name>.conf: make sure that you only use directives that are allowed to be used in http blocks
- run a Nginx config test with the command: nginx -t
- reload Nginx with the command: service nginx reload (which command is the same as: nginx -s reload)

and (without restarting Nginx) you should have a Nginx instance with some custom directives that are persistent across upgrades of Plesk and/or Nginx.

Hope the above helps a bit.

Regards!

 

[garcue]

@garcue

I suppose that there is some misunderstanding in this topic thread.

On the one hand, you are asking about persistent nginx config that cannot be placed in the regular server or location blocks.

On the other hand, there are responses in this topic thread that are pointing in the direction of location block related customization of Nginx config for specific domains.

There is a huge difference between the two.

So, returning to your original post and question



I have the following answer and solution for you:

- create a file called <name>.conf in the /etc/nginx/conf.d directory
- place your custom directives in that file <name>.conf: make sure that you only use directives that are allowed to be used in http blocks
- run a Nginx config test with the command: nginx -t
- reload Nginx with the command: service nginx reload (which command is the same as: nginx -s reload)

and (without restarting Nginx) you should have a Nginx instance with some custom directives that are persistent across upgrades of Plesk and/or Nginx.

Hope the above helps a bit.

Regards!

That's trilotto,

Effectively there are shots, create a file of additional configuration to add these parameters and works halfway (these are my problem) but that is the right way.

Thanks for the suggestion

 

[Ovi]

@garcue
On the one hand, you are asking about persistent nginx config that cannot be placed in the regular server or location blocks.

Hi @trialotto
I'm trying to permanently load the following "include" directives in nginx config, but the nginx -t fails every time if I paste them in --> Apache & nginx Settings for [domain.tld] --> Additional nginx directives:

include /etc/nginx/bots.d/blockbots.conf;

include /etc/nginx/bots.d/ddos.conf;

These includes MUST be added within a server {} block of a vhost and I can't seem to find a way to save them in a vhost file which is not generated by plesk. I already saved permanent configs in /etc/nginx/conf.d and in /etc/nginx/bots.d/ where I saved all the bot blacklist files. But they're not loading from my domains because my domains are missing the 2 include directives in their server block.

I followed all the instructions from: mitchellkrogza/nginx-ultimate-bad-bot-blocker and everything went well. I saved the configs, tested and restarted nginx. However I can't find a way to load the 2 conf files in my domains vhost to protect them from bad bots and other malicious crawlers/malware etc.
Your help would be much appreciated.
Thank you.

 

[trialotto]

Hi @trialotto
I'm trying to permanently load the following "include" directives in nginx config, but the nginx -t fails every time if I paste them in --> Apache & nginx Settings for [domain.tld] --> Additional nginx directives:

include /etc/nginx/bots.d/blockbots.conf;

include /etc/nginx/bots.d/ddos.conf;

These includes MUST be added within a server {} block of a vhost and I can't seem to find a way to save them in a vhost file which is not generated by plesk. I already saved permanent configs in /etc/nginx/conf.d and in /etc/nginx/bots.d/ where I saved all the bot blacklist files. But they're not loading from my domains because my domains are missing the 2 include directives in their server block.

I followed all the instructions from: mitchellkrogza/nginx-ultimate-bad-bot-blocker and everything went well. I saved the configs, tested and restarted nginx. However I can't find a way to load the 2 conf files in my domains vhost to protect them from bad bots and other malicious crawlers/malware etc.
Your help would be much appreciated.
Thank you.

@Ovi

In essence, all custom config files - read: not the ones generated by plesk - in the directories

- /etc/nginx/conf.d
- /etc/nginx/plesk.conf.d

should be read by nginx when either reloading the Nginx config or starting/restarting Nginx.

At least, that is the theory, since in practice it is not very safe to put custom config files in the directory /etc/nginx/plesk.conf.d : use /etc/nginx/conf.d instead!

In general, your blockbots.conf and ddos.conf files can be safely put in the /etc/nginx/conf.d directory - that should work like a charm, without any adjustments.

These two custom config files should still apply on every domain, when being put in the /etc/nginx/conf.d directory - meaning: wherever you place your blockbots.conf and ddos.conf files, as long as the include directives are proper and all general Nginx configuration is properly set up, you should be fine.

However, you still have a problem somewhere in your configuration - I cannot put my finger on it, in the absence of all configuration I can only make an educated guess!

Nevertheless, I am pretty sure that your zone configuration is improper or simply missing - just have a look at limit_req_zone and limit_conn_zone : check their existence!

By the way, any run of nginx -t should give you an indication what the problem with the Nginx config is : just provide the output (and some config!).

Hope the above helps a bit..........a tiny bit.

Regards........

 

[Ovi]

@Ovi

In essence, all custom config files - read: not the ones generated by plesk - in the directories

- /etc/nginx/conf.d
- /etc/nginx/plesk.conf.d

should be read by nginx when either reloading the Nginx config or starting/restarting Nginx.

At least, that is the theory, since in practice it is not very safe to put custom config files in the directory /etc/nginx/plesk.conf.d : use /etc/nginx/conf.d instead!

In general, your blockbots.conf and ddos.conf files can be safely put in the /etc/nginx/conf.d directory - that should work like a charm, without any adjustments.

These two custom config files should still apply on every domain, when being put in the /etc/nginx/conf.d directory - meaning: wherever you place your blockbots.conf and ddos.conf files, as long as the include directives are proper and all general Nginx configuration is properly set up, you should be fine.

However, you still have a problem somewhere in your configuration - I cannot put my finger on it, in the absence of all configuration I can only make an educated guess!

Nevertheless, I am pretty sure that your zone configuration is improper or simply missing - just have a look at limit_req_zone and limit_conn_zone : check their existence!

By the way, any run of nginx -t should give you an indication what the problem with the Nginx config is : just provide the output (and some config!).

Hope the above helps a bit..........a tiny bit.

Regards........

Thanks for your reply @trialotto
First of all, my nginx -t gives me no errors, unless I try to add the 2 "include" directives I mentioned. Therefore at the moment my nginx runs and reloads OK but my domains don't load the malware blocklists. So to answer your questions:

As per Mitchell's instructions, in /etc/nginx/conf.d I have these 2 [unmodified] files:
mitchellkrogza/nginx-ultimate-bad-bot-blocker

And in etc/nginx/bots.d I have these [unmodified] files:
mitchellkrogza/nginx-ultimate-bad-bot-blocker

Now the blockbots.conf from bots.d includes the following code:

# Include this in a vhost file within a server {} block using and include statement like below

# server {
#            #Config stuff here
#            include /etc/nginx/bots.d/blockbots.conf
#            include /etc/nginx/bots.d/ddos.conf
#            #Other config stuff here
#         }

#######################################################################

# BOTS
# ****
#limit_conn bot1_connlimit 100;
limit_conn bot2_connlimit 10;
#limit_req  zone=bot1_reqlimitip burst=50;
limit_req  zone=bot2_reqlimitip burst=10;
if ($bad_bot = '3') {
  return 444;
  }

# BAD REFER WORDS
# ***************
if ($bad_words) {
  return 444;
}


# REFERERS
# ********
if ($bad_referer) {
  return 444;
}

# IP BLOCKS
# *********
if ($validate_client) {
  return 444;
}

And ddos.conf:

# Include this in a vhost file within a server {} block using and include statement like below

# server {
#            #Config stuff here
#            include /etc/nginx/bots.d/blockbots.conf
#            include /etc/nginx/bots.d/ddos.conf
#            #Other config stuff here
#         }

#######################################################################

limit_conn addr 200;
limit_req zone=flood burst=200 nodelay;

But apart from these 2 conf files, Mitchell's malware blocklists includes a few other confs (please see the links above to his github).

Do you still think its a good idea to move these 2 conf files in /etc/nginx/conf.d ?
And if you don't mind me asking, how do you load malware blocklists in your nginx?

PS: Thanks for answering my security post in the other thread. I agree with you, proper cybersecurity is done through secrecy, encryption, obscurity and other means. However, if we don't share educational info with each other, how are we going to learn to stay one step ahead of malware, APTs and other cyberthreats?

If you have any further advice how to secure & protect nginx and Plesk, please do share it.
Thanks a lot!

 

[trialotto]

@Ovi,

In response to your post and your statement

Do you still think its a good idea to move these 2 conf files in /etc/nginx/conf.d ?

I can suggest that you

1 - add a file in /etc/nginx with the name of (for example) bbb.conf,

2 - edit the contents of bbb.conf to contain

include /etc/nginx/bots.d/blockbots.conf
include /etc/nginx/bots.d/ddos.conf

and save the file,

3 - do a nginx -t command, followd by a Nginx stop/start sequence.

Now, with respect to your other question

And if you don't mind me asking, how do you load malware blocklists in your nginx?

I must emphasize that we run a (huge) number of solutions in production environments to block bad traffic.

Nginx is just a simple part of that set of solutions, with Nginx being used to gather information and to block traffic at the proxy level.

To be honest, one of the most simple, efficient and cost-effective solutions for a server is : Nginx + custom Fail2Ban actions (+ 1 cronjob to reload Nginx config).

In essence, this (combined) solution uses (custom) Fail2Ban actions to :

- identify offenders and block them for a short period of time via Nginx deny directives,
- identify repeat offenders and block them for a period of one year via Nginx deny directives,
- identify notorious offenders - read: bad IPs that return even after a ban period of one year - via firewall rulesets,

and note that "identification" is simply based on log entries in various relevant log files.

The main advantages of this approach are that

- script based bypassing of Fail2Ban is less likely,
- false positives are not penalized to a too high degree,
- offenders are penalized according to the degree and/or persistence of offending traffic,
- offenders are permanently blocked via the firewall, only if there is a reason to do so : the firewall is kept relatively clean
- attacks based on firewall overloads are less effective,
- Nginx blocklists are both dynamic and relatively clean,
- Nginx can do what it can do best : handle a lot of request per second, including rejection of bad requests,
- Fail2Ban becomes less intrusive to server performance if the Nginx blocklists are getting bigger,
- Apache is not involved - with the exception of ModSecurity on the Apache level (as reliable input to identify offenders)

and there is two associated advantages that can be mentioned : (on the one hand) the entire setup is simple and can be easily copied across systems and (on the other hand) it seems to be the case that Nginx blocklists decrease in terms of numbers of offending IPs over time, which is a rather unexpected result.

Please note that there is a close balance to be found between the various tools to use when trying to block bad traffic.

For instance, ModSecurity is not very reliable when used at the Nginx level (which also requires a custom Nginx binary or a commercial Nginx Plus license) and/or firewalls can become very big (and as such, firewalls ironically become part of the attack surface - firewall overloading is one way to hack a system) and/or Fail2Ban is not always very efficient (and it also using iptables/the firewall by default) and/or Nginx will start slowly in the case that a lot of config has to be loaded........ a complex interaction!

Simply stated, any overkill in the usage of one of the "tools" to fight bad traffic can make the entire system a bit more vulnerable.

To be honest, this is also the reason why I do not use the "Krogza" solution - it is Krogzilla for any system : it is just including a whole lot of solutions to problems that often will not even occur on a Plesk system, hence making Nginx less effective than it could be - and that is not a good starting point.

Anyway, you can always send me a private message on this forum, if you want to continue this conversation - I suggest that you do so and that we keep this post "resolved".

Regards........

 

[cmaurand]

I have the same trouble. we have a joomla site that google has crawled and has cached urls with a query string on them. Nothing worked in the custom directives file for rewrites/redirects. I ended up having to create a map above any server blocks and adding references to that map in the server blocks so that these query's could be rewritten before the handoff to anything. Those references had to go above any "location /something" or even "location /" This going to get broken every time there's an update and I'm going to have to copy this config back in every time. This is madness. Custom changes need to stick.

 

[cmaurand]

I have the same trouble. we have a joomla site that google has crawled and has cached urls with a query string on them. Nothing worked in the custom directives file for rewrites/redirects. I ended up having to create a map above any server blocks and adding references to that map in the server blocks so that these query's could be rewritten before the handoff to anything. Those references had to go above any "location /something" or even "location /" This going to get broken every time there's an update and I'm going to have to copy this config back in every time. This is madness. Custom changes need to stick.

I've written a script to copy my modified file back into /var/www/vhosts/system/site.com/conf/

I see no reason for plesk to be overwriting the file constantly. for whatever changes it should be possible to parse the file for the lines plesk needs to change and change only those lines.

Thanks,
Curtis

 

[trialotto]

I've written a script to copy my modified file back into /var/www/vhosts/system/site.com/conf/

I see no reason for plesk to be overwriting the file constantly. for whatever changes it should be possible to parse the file for the lines plesk needs to change and change only those lines.

Thanks,
Curtis

@cmaurand

You can use Nginx custom templates that will stick across updates.

There is only one downside : you will get all kinds of annoying error notifications with updates and/or when using plesk repair command and/or when using or running httpdmng in general ............ but in most cases, these error notifications can safely be ignored.


You should use the following steps or commands :

1 - run : cd /opt/psa/admin/conf/templates

2 - cd into the default directory and have a look at the subdirectories and the nginx[..].php files : these files are used to (re-)generate Nginx config files

3 - REMINDER : NEVER change the files / directories in /opt/psa/admin/conf/templates/default directory !!!

4 - if you need to have a custom Nginx config at the [z] level (with z being one of "domain", "server", "service" and "webmail"), then :

4.1 - run : cd /opt/psa/admin/conf/templates/default
4.2 - traverse through the config generation files (in the default directory) and select the one that you need
4.3 - set config file var - run : file="string" (with string being the config file name, only the name)
4.4 - set base directory file var - run : level="string" (with the string being one of "domain", "domain/service", "server", "service" and "webmail")
NOTE : one should - in general - not have any need to customize the php files in the default directory, so it is assumed that you need the var $level
4.5 - run : cd /opt/psa/admin/conf/templates && mkdir custom
NOTE : it is recommended to first use a test directory first and move the finished contents of the test directory to the custom directory afterwards!!
4.6 - run : cd custom && mkdir -p $level
4.7 - run : cd ../
4.8 - copy default file to custom directory - run : cp "default/$level/$file" "custom/$level/$file"
4.9 - run : cd "custom/$level/"
4.10 - change the file as desired, but ADD the custom contents to the file : do not remove the original contents and/or minimize the changes thereof
NOTE : in some cases, it is necessary to remove the original contents or a huge part of it, but that is not safe in Plesk environments - think of other solutions!
NOTE : one should - in theory - be able to save the customized files under any name, but it is easier to keep the default name - this facilitates comparison!

5 - REMINDER : thoroughly TEST the customization and

5.1 - do a PHP validity check - run : php -l <file-name> (to test whether the custom config file is a valid PHP file)
5.2 - run a test of auto-regeneration on ONE domain - run : httpdmng --reconfigure-domain <test domain>

and run the new test domain in a test environment, so you can tweak the config customization if and where necessary.

6 - REMINDER : ONLY customize one file at a time, otherwise the Plesk behavior can become fairly unpredictable.

7 - check the GENERATED custom config in the test domain : have a look at the contents of /etc/nginx/plesk.conf.d/vhosts/<test domain>.conf
NOTE : only move the custom configuration to production environments if they are working properly and tested properly


Sure, the above contains a number of steps that can be shortened, but it is just an illustration that aims to make "foolish errors" less likely.

Everybody should take the steps required and as they seem fit and comfortable.


As a general remark, it should be duly noted that

a) Nginx config customization will apply to ALL domains that are hosted on the server and that are using the config generation templates

b) some domains hosted will require custom adjustments, so please do not use custom templates for that purpose

c) some adjustments should be kept simple ....... a simple Nginx rewrite on the domain level often will suffice!


It might be the case that point c) applies to your scenario, since you essentially want to remove the strings added to the URL - or am I mistaken?


In short, there is no need for a script, there is only a possibility of a persistent change in config regeneration with customized templates.

Have a look at :

- Changing Virtual Hosts Settings Using Configuration Templates
- Appendix A: Configuration Templates Structure

and I hope the above helps a bit to replace your script!


Kind regards....


PS As usual, one can even add php ini files to the customized config - quite handy when requiring some fixed variables, but in practice it is often more easy to hard-code value (not variables) in the config generation templates!