10 tips for ensuring nginx security

Nginx is one of the most popular Web servers today. It serves 7% of the world's web traffic and is growing at an alarming rate. It's a surprising server and I'm willing to deploy it.
The following is a list of common security traps and solutions that can be assisted to ensure that your Nginx deployment is secure.

1. Use the "if" in the configuration file carefully
It is part of the rewrite module and should not be used anywhere.
An "if" declaration is a mandatory part of the Rewrite module evaluation directive. In other words, nginx configuration is generally declarative. In some cases, because of the user's needs, they try to use "if" within some non-rewrite instructions, which leads us to the situation we are experiencing. In most cases, it works, but ... Look at the above mentioned.

It seems that the only correct solution is to completely disable the "if" within a non-overridden instruction. This will change many of the existing configurations, so it's not done yet. Ifisevil:http://wiki.nginx.org/ifisevil

2. Forward each ~. php$ Request to PHP
We released a description of the potential security breaches of this popular directive last week. Even if the file name is Hello.php.jpeg it will match ~. Php$ this regular and executes the file.
There are now two good ways to solve these problems. I think it is necessary to ensure that you do not easily execute arbitrary code blending methods.
2.1 If the file is not found, use try_files and only (should be noted in all dynamic execution cases) to forward it to the fcgi process running PHP.
2.2 Confirm that Cgi.fix_pathinfo is set to 0 (cgi.fix_pathinfo=0) in the php.ini file. This ensures that PHP checks the full file name (when it is not found at the end of the file. PHP it will ignore)
2.3 Fix an issue where regular expressions match incorrect files. Now the regular expression thinks that any file contains ". php". Add "If" after the site to ensure that only the correct files are available to run. Will/location ~. php$ and location ~. */.*.php$ are set to return 403;

3. Disabling the AutoIndex module
This may have changed in the Nginx version you used, and if not, simply add autoindex off in the location block of the configuration file.

4. Disable SSI (server-side reference) on the server
This can be done by adding SSI off in the location block;.

5. Turn off server tagging
If turned on (by default) all error pages will display the server's version and information. Add the server_tokens off; the declaration is added to the Nginx configuration file to resolve this issue.

6. Setting custom caches in configuration files to limit the likelihood of buffer overflow attacks

 

1 2 3 4

client_body_buffer _size 1k client_header_buffer _size 1k client_max_body_ Size 1k large_client_header_buffers 2 1k

7. Set the timeout low to prevent Dos attacks
All of these declarations can be placed in the master configuration file.

 

1 2 3 4

client_body_timeout ; client_header_timeout ; keepalive_timeout 5 5; send_timeout ten;

8. Limit the number of user connections to prevent Dos attacks

 

1 2	limit_zone slimits $binary_remote_addr 5m; limit_conn slimits 5;

9. Try to avoid using HTTP authentication
HTTP authentication uses crypt by default, and its hash is not secure. Use MD5 if you want to use it (this is not a good choice but the load is better than crypt).

10. Keep up with the latest Nginx security updates
Transferred from: Http://www.levigross.com/post/4488812448/10-tips-for-securing-nginx

Personally feel that in the prevention of DDoS attacks, the above mentioned seventh eighth is not very useful, especially the 8th, very disruptive user experience.

10 tips for ensuring nginx security