Nginx

Disable Unwanted Modules

When you install nginx, it automatically includes many modules. Currently, you cannot choose modules at runtime. To disable certain modules, you need to recompile nginx. We recommend that you disable any modules that are not required as this will minimize the risk of potential attacks by limiting allowed operations.

To do this, use the configure option during installation. In the example below, we disable the autoindex module, which generates automatic directory listings, and then recompile nginx.

# ./configure --without-http_autoindex_module
# make
# make install

Disable nginx server_tokens

By default, the server_tokens directive in nginx displays the nginx version number. It is directly visible in all automatically generated error pages but also present in all HTTP responses in the Server header.

This could lead to information disclosure – an unauthorized user could gain knowledge about the version of nginx that you use. You should disable the server_tokens directive in the nginx configuration file by setting server_tokens off.

Exclude Server Headers

The default state of a Nginx server returns something like Server: nginx/1.12.1 in the server response or error pages. The best method is to remove the header completely. For that, we require the installation of nginx-extras.

For Debian/Ubuntu

sudo apt-get install nginx-extras

   

For RHEL

 
    yum install nginx-plus-module-headers-more

   

After installing and restarting the Nginx service, add the following lines to your nginx.conf file.

 
        # /etc/nginx/nginx.conf
        http {
            # Basic Settings
            more_set_headers 'Server: ';

   

If no value is specified, the header will be displayed empty. We can also create custom headers as given below.

 
        # /etc/nginx/nginx.conf
        http {
            # Basic Settings
            more_set_headers 'Server: Custom Header';

   

To completely disable the server header, find server_token in the Nginx configuration file and set it to server_tokens off (by removing # in the nginx.conf file).

Control Resources and Limits

To prevent potential DoS attacks on nginx, you can set buffer size limitations for all clients. You can do this in the nginx configuration file using the following directives:

• client_body_buffer_size – use this directive to specify the client request body buffer size. The default value is 8k or 16k but it is recommended to set this as low as 1k: client_body_buffer_size 1k.

• client_header_buffer_size – use this directive to specify the header buffer size for the client request header. A buffer size of 1k is adequate for most requests.

• client_max_body_size – use this directive to specify the maximum accepted body size for a client request. A 1k directive should be sufficient but you need to increase it if you are receiving file uploads via the POST method.

• large_client_header_buffers – use this directive to specify the maximum number and size of buffers to be used to read large client request headers. A large_client_header_buffers 2 1k directive sets the maximum number of buffers to 2, each with a maximum size of 1k. This directive will accept 2 kB data URI.

Some sources suggest that setting such limits may prevent potential buffer overflow if such vulnerabilities are found in nginx.

Disable Any Unwanted HTTP methods We suggest that you disable any HTTP methods, which are not going to be utilized and which are not required to be implemented on the web server. If you add the following condition in the location block of the nginx virtual host configuration file, the server will only allow GET, HEAD, and POST methods and will filter out methods such as DELETE and TRACE.

location / {
limit_except GET HEAD POST { deny all; }
}

Another approach is to add the following condition to the server section (or server block). It can be regarded as more universal but you should be careful with if statements in the location context.

if ($request_method !~ ^(GET|HEAD|POST)$ ) {
    return 444; }

Note that if ModSecurity does not meet your needs, you can also use other free WAF solutions.

Set Up Access and Error Logs

The nginx access and error logs are enabled by default and are located in logs/error.log and logs/access.log respectively. If you want to change the location, you can use the error_log directive in the nginx configuration file. You can also use this directive to specify the logs that will be recorded according to their severity level. For example, a crit severity level will cause nginx to log critical issues and all issues that have a higher severity level than crit. To set the severity level to crit, set the error_log directive as follows:

error_log logs/error.log crit;

You can find a complete list of error_log severity levels in official nginx documentation.

You can also modify the access_log directive in the nginx configuration file to specify a non-default location for access logs. Finally, you can use the log_format directive to configure the format of the logged messages as explained in nginx documentation.

Monitor Access and Error Logs

If you continuously monitor and manage nginx log files you can better understand requests made to your web server and also notice any encountered errors. This will help you discover any attack attempts as well as identify what can you do to optimize the server performance.

You can use log management tools, such as logrotate, to rotate and compress old logs and free up disk space. Also, the ngx_http_stub_status_module module provides access to basic status information. You can also invest in nginx Plus, the commercial version of nginx, which provides real-time activity monitoring of traffic, load, and other performance metrics.

Include Security Headers

To additionally harden your nginx web server, you can add several different HTTP headers. Here are some of the options that we recommend.

X-Frame-Options

You use the X-Frame-Options HTTP response header to indicate if a browser should be allowed to render a page in a or an . This could prevent clickjacking attacks. Therefore, we recommend that you enable this option for your nginx server.

To do this, add the following parameter to the nginx configuration file in the server section:

add_header X-Frame-Options "SAMEORIGIN";

Strict-Transport-Security

HTTP Strict Transport Security (HSTS) is a method used by websites to declare that they should only be accessed using a secure connection (HTTPS). If a website declares an HSTS policy, the browser must refuse all HTTP connections and prevent users from accepting insecure SSL certificates. To add an HSTS header to your nginx server, you can add the following directive to your server section:

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";

CSP and X-XSS-Protection

Content Security Policy (CSP) protects your web server against certain types of attacks, including Cross-site Scripting attacks (XSS) and data injection attacks. You can implement CSP by adding the following example Content-Security-Policy header (note that the actual header should be configured to match your unique requirements):

add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

The HTTP X-XSS-Protection header is supported by IE and Safari and is not necessary for modern browsers if you have a strong Content Security Policy. However, to help prevent XSS in the case of older browsers (that don’t support CSP yet), you can add the X-XSS Protection header to your server section:

add_header X-XSS-Protection "1; mode=block";

Configure SSL and Cipher Suites

The default configuration of nginx allows you to use insecure old versions of the TLS protocol (according to the official documentation: ssl_protocols TLSv1 TLSv1.1 TLSv1.2). This may lead to attacks such as the BEAST attack. Therefore, we recommend that you do not use old TLS protocols and change your configuration to support only newer, secure TLS versions.

To do this, add the following directive in the server section of the nginx configuration file:

ssl_protocols TLSv1.2 TLSv1.3;

Additionally, you should specify cipher suites to make sure that no vulnerable suites are supported. To select the best cipher suites, read our article on TLS cipher hardening and add a ssl_ciphers directive to the server section to select the ciphers (as suggested in the article on cipher hardening). We also recommend that you add the following directive to the server section:

ssl_prefer_server_ciphers on;

This directive will let the decision on which ciphers to use be made server-side not client-side.

Check Configurations with Gixy

Gixy is an open-source tool that lets you check your nginx web server for typical misconfigurations. After you prepare your nginx configuration, it is always a good idea to check it with Gixy.

You can find Gixy here.