Announcing NGINX Plus R10 - NGINX

Original: https://www.nginx.com/blog/nginx-plus-r10-released/

We are excited to announce NGINX Plus Release 10 (R10), our most significant release yet. NGINX Plus extends the open source NGINX software with advanced functionality and award‑winning support, providing customers with a complete application delivery solution. With this release we are providing a number of new features to dramatically improve the security and performance of applications delivered by NGINX Plus, along with additional features for improved network integration and support for customization of NGINX Plus through scripting.

Editor – For more details about key new features in NGINX Plus R10, see these related resources:

NGINX Plus R10 features the initial release of our web application firewall (WAF), powered by ModSecurity and fully supported by NGINX, Inc. Web application attacks increased by 50% in the past year and DDoS attacks more than doubled, according to Akamai. Every application is now at risk of being attacked. NGINX Plus with ModSecurity WAF helps protect web applications from malicious users and gives customers a versatile tool to help keep their apps and data safe.

Request a demo of the NGINX Plus with ModSecurity WAF.

NGINX Plus with ModSecurity WAF protects your applications from a broad range of attacks
NGINX Plus with ModSecurity WAF protects applications from a broad range of attacks

The ModSecurity WAF is based on the new ModSecurity 3 that runs natively within NGINX Plus. It is supported by NGINX, Inc. and has been tested thoroughly with NGINX Plus. We are working with Trustwave and will maintain tested updates as we add features, improve performance, and address any issues. The ModSecurity WAF is an additional‑cost option in our dynamic modules repository.

Two additional new features further enhance the security capabilities of NGINX Plus:

In addition to security features, NGINX Plus R10 includes:

NGINX Plus R10 in Detail

ModSecurity Web Application Firewall

The headline feature in NGINX Plus R10 is the initial release of our web application firewall (WAF), built on the well‑known and trusted ModSecurity technology. Since its initial open source release in 2002, ModSecurity has been helping to protect some of the world’s largest web properties against malicious users. It’s commonly called the “Swiss Army® knife” of security. NGINX Plus with ModSecurity WAF is an additional‑cost option, and is provided to subscribers through our dynamic modules repository.

NGINX Plus with ModSecurity WAF is a must‑have solution to help secure critical applications. It provides a cost‑effective alternative to inflexible and costly hardware appliances, such as those provided by F5, Citrix, and Imperva, while also exceeding their capabilities with the flexibility of software. NGINX Plus with ModSecurity WAF can be deployed in any environment – on-premises servers, and public, private, and hybrid clouds.

NGINX Plus with ModSecurity WAF protects your websites and applications from DDoS attacks
NGINX Plus with ModSecurity WAF helps protect against DDoS attacks

A WAF operates on a database of “rules” that define malicious behaviors to be blocked and/or logged. The OWASP ModSecurity core rule set (CRS) is one of the most widely used rule sets with ModSecurity. NGINX Plus with ModSecurity WAF uses the OWASP CRS to identify and block a broad range of application attacks, with features such as:

Additional rule sets are also available from different vendors, such as TrustWave, at varying cost levels. In addition, you can use the powerful ModSecurity rules language to define your own custom rules that augment whatever rule sets you are using.

Support for the ModSecurity WAF for NGINX Plus is provided directly by NGINX, Inc. Our support team will help install, configure, and debug issues with the ModSecurity WAF and the OWASP core rule set.

The ModSecurity WAF is available as a dynamic module in the NGINX Plus repository that you install using standard package management tools. These commands are for Debian‑based operating systems:

# apt-get update
# apt-get install nginx-plus
# apt-get install nginx-plus-module-modsecurity

Note that only subscribers who have purchased the ModSecurity WAF add-on, and subscribers and evaluators who have requested access will be able to download the nginx-plus-module-modsecurity package.

To load the WAF module, include the load_module directive in the top‑level “main” context of the NGINX Plus configuration file:

load_module modules/ngx_http_modsecurity.so;

To enable the ModSecurity WAF for NGINX Plus, include the modsecurity directive along with the modsecurity_rules_file directive to specify the rule set:

upstream backend {
    server server-hostname;
}

server {
    listen 80;
    status_zone backend;

    modsecurity on;
    location / {
        proxy_pass http://backend;
        modsecurity_rules_file rule-set-file;

     }
}

Then reload the NGINX Plus configuration:

# nginx -t && nginx -s reload

Request a demo of the NGINX Plus with ModSecurity WAF.

Native JWT Support for OAuth 2.0 and OpenID Connect

With native support for the JSON Web Token (JWT) authentication standard, NGINX Plus R10 makes it easy to add sophisticated authentication solutions to your applications and APIs.

JWT (pronounced “jot”) tokens, defined in RFC 7519, are the underlying data format for user information in the OpenID Connect standard, which is the standard identity layer on top of the OAuth 2.0 protocol. Deployers of APIs and microservices are also turning to the JWT standard for its simplicity and flexibility.

Editor – For use cases that leverage the native JWT support, see these blogs:

To provide authentication services for APIs, NGINX Plus validates JSON Web Tokens (JWTs) in its new r10 release
NGINX Plus validates the JWT before allowing clients access

As a reverse proxy and load balancer, NGINX Plus sits in front of applications, making it ideally positioned to simplify application development by offloading the validation of the JWT supplied in each HTTP request. This provides two benefits. First, NGINX Plus can help stop unauthenticated, malformed, and malicious requests from reaching the application, protecting it from the effort and risk involved in handling such requests.

The second benefit is that NGINX Plus has access to all of the fields in the validated JWT (after signature verification) and can use the inherent power and flexibility of its configuration syntax to provide sophisticated authentication solutions for both microservices and APIs:

The following sample NGINX Plus configuration snippet shows how to use JWTs to protect a website.

The auth_jwt directive tells NGINX Plus to use JWT to authenticate users making requests for a domain, in this case myrealm. The auth_jwt_key_file directive indicates which JSON Web Key (JWK) to use to validate the token signature; it functions like the public key in SSL/TLS encryption. The file location must be accessible to NGINX Plus.

As NGINX Plus validates and parses the token, it automatically creates NGINX variables for the “claims” in the JWT, which represent entities associated with it (its issuer, the user to whom it was issued, and the intended recipient, for example). The variable names all begin with $jwt_claim_. You can then use the add_header directive to have NGINX Plus pass a claim to the backend servers in the form of an HTTP header set to the value of the $jwt_claim_ variable. In our example, NGINX Plus passes the user identity to the backend application in the $jwt_claim_sub variable, which corresponds to the user ID (sub claim) in the JWT.

server {
    listen 80;
    location / {
        auth_jwt "myrealm";
        auth_jwt_key_file /etc/nginx/jwt_keyfiles/secret.jwk;
 
        proxy_pass http://backend_app;
        add_header Authenticated-User $jwt_claim_sub
    }
}

In NGINX Plus R8 we released a technology preview of OAuth2 support. In the NGINX Plus R10 implementation we’ve taken in feedback from our customers to deliver a production‑ready implementation that reaches the most valuable use cases in the complex world of authenticating users and computers.

“Dual‑Stack” RSA and ECC Certificate Support

There are plenty of reasons now to start SSL/TLS encrypting all application traffic. Google rewards SSL/TLS‑encrypted sites with higher search engine rankings. In addition, modern web standards, such as HTTP/2, are mandating SSL/TLS encryption for all websites.

With NGINX Plus R10, you can publish SSL/TLS services using both RSA and ECC certificates. In our testing, ECC certificates were up to 3x quicker than equivalent‑strength RSA certificates; this translates to more SSL/TLS connections per server and faster SSL/TLS handshakes. NGINX Plus selects the optimal certificate based on each client’s capabilities, allowing modern clients to use higher‑speed ECC certificates while still supporting legacy RSA‑only clients.

To support both RSA and ECC certificates, in the configuration for a virtual server simply include a pair of ssl_certificate and ssl_certificate_key directives for each certificate type, as shown in the following example.

server {
    listen              443 ssl;
    server_name         example.com;

    ssl_certificate     example.com.rsa.crt;
    ssl_certificate_key example.com.rsa.key;

    ssl_certificate     example.com.ecdsa.crt;
    ssl_certificate_key example.com.ecdsa.key;
}

Transparent Proxy

We are continuously adding features to NGINX Plus, such as TCP and UDP load balancing, to support a broader range of applications and deployment models. With NGINX Plus R10 we have added a transparent‑proxy capability that allows NGINX Plus to send packets to upstream servers using any source IP address and port. This enables configurations such as IP Transparency and Direct Server Return.

IP Transparency is a configuration where the load balancer (NGINX Plus) uses the remote client’s IP address as the source IP address in packets it sends to upstream servers. This means that upstream servers see packets as originating from the remote client’s IP address, rather than from a local IP address on the load balancer. This is significant when applications refer to the source IP address for logging, security, rate‑limiting, or authentication purposes.

IP Transparency is also a building block for a network load‑balancing technique called Direct Server Return (DSR). NGINX Plus can perform DSR for UDP‑based protocols (but not TCP or HTTP), allowing the return packets to completely bypass the load balancer and go directly to the remote client.

NGINX Plus supports Direct Server Return in its r10 release, where servers reply directly to clients
In Direct Server Return (DSR) mode, the server responds directly to the client

IP Transparency and DSR are configured with the new transparent parameter to the proxy_bind, fastcgi_bind, memcached_bind, scgi_bind, and uwsgi_bind directives. The following example shows how to set up DSR for a DNS backend. The proxy_responses directive specifies that NGINX Plus does not need to see any server responses (zero is the appropriate value for DSR).

stream {
    upstream dns {
        server dns1.example.com:53;
        server dns2.example.com:53;
    }

    server {
        listen 53 udp;
        proxy_bind $remote_addr:$remote_port transparent;
        proxy_responses 0; # Don’t expect to see any responses from upstream
        proxy_pass dns;
    }
}

Note that passive health checks are not effective when DSR is enabled, because they involve NGINX Plus verifying that the server sent a response to the client. Configuring active application‑aware health checks is mandatory for a DSR configuration. For an example, please see our detailed instructions for configuring them for load-balanced DNS servers.

IP Transparency and DSR configurations are complex, with additional routing and packet‑rewriting requirements that fall outside the scope of the NGINX Plus software. For complete instructions, see IP Transparency and Direct Server Return with NGINX and NGINX Plus as Transparent Proxy on our blog.

nginScript for HTTP‑, TCP‑, and UDP‑Based Applications

Editor – nginScript became generally available in NGINX Plus R12 (and NGINX 1.11.10). For details and links to use cases, see Introduction to nginScript.

NGINX Plus R10 includes a preview release of our new nginScript configuration language. It’s not yet feature complete, and we welcome any feedback on the work so far. nginScript enables you to use JavaScript code to perform complex and custom actions on HTTP, TCP, and UDP traffic. It provides a powerful new way for controlling how your applications are delivered and secured. With nginScript you can:

The nginScript preview is available in our dynamic modules repository. You can install it using standard package management tools. These commands are for Debian‑based operating systems:

# apt-get update
# apt-get install nginx-plus
# apt-get install nginx-plus-module-njs

To load the nginScript modules for HTTP and TCP/UDP, include the load_module directive in the top‑level “main” context of the NGINX Plus configuration file:

load_module modules/ngx_http_js_module.so;
load_module modules/ngx_stream_js_module.so;

Then reload the NGINX Plus configuration to load the nginScript modules:

# nginx -t && nginx -s reload

Open source NGINX users can obtain nginScript from our open source code repository.

JavaScript code is not included directly in the NGINX Plus configuration. Instead, it is read in with the js_include directive. In this example, the JavaScript code for a simple “serverless” function is read in from /etc/nginx/conf.d/functions.js. The js_content directive instructs NGINX Plus to call the JavaScript function and return the results to the client.

js_include conf.d/functions.js;

server {
    listen 80;
    location /functions/leftpad {
        js_content leftpad;
     }
}

The JavaScript code in /etc/nginx/conf.d/functions.js pads a character string with a specified set of characters:

function leftpad(r) {
  // Pull function arguments from the query string
  var str, len, ch;
  for (a in r.args) {
      if (a == "str") str = String(r.args[a]);
      if (a == "len") len = r.args[a];
      if (a == "ch") ch = r.args[a];
  }

  // Do the padding
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }

  // Construct complete HTTP response
  var res = r.response;
  res.headers.rpc-method = "leftpad";
  res.status = 200;
  res.contentType = 'text/plain; charset=utf-8';
  res.contentLength = str.length + 1; // Plus newline
  res.sendHeader();
  res.send(str + '\n');
  res.finish();
}

Editor – For links to detailed explorations of other nginScript use cases, see Introduction to nginScript on our blog.

Additional Features

NGINX Plus R10 introduces a number of additional improvements to aid you in flawless application delivery, including:

NGINX Plus Extras Package Is Deprecated

As we preannounced at the release of NGINX Plus R9, R10 is the last release that will include the NGINX Plus Extras package.

We strongly recommend that you modify your installation and configuration procedures now to use the nginx-plus package and dynamically load the modules in the nginx-plus-extras package that you actually use. Starting in NGINX Plus R11, this will be the only possible way to use modules that are not built into the nginx-plus package.

To switch to the nginx-plus package and dynamic modules, perform these steps:

  1. Remove the nginx-plus-extras package and install nginx-plus and the dynamic modules you want to use. For Debian‑based systems, the appropriate set of commands is:

    # apt-get update
    # apt-get remove nginx-plus-extras
    # apt-get install nginx-plus
    # apt-get install module-name
  2. In the main (top‑level) context in /etc/nginx/nginx.conf, add a load_module directive for each dynamically loaded module:

    load_module modules/module-name.so;
  3. Check the new configuration for syntactic validity and reload it:

    # nginx -t && nginx -s reload

Upgrade or Try NGINX Plus

If you’re running NGINX Plus, we strongly encourage you to upgrade to Release 10 as soon as possible. You’ll pick up a number of fixes and improvements, and it will help us to help you if you need to raise a support ticket. Installation and upgrade instructions can be found at the NGINX Plus customer portal.

NOTE: NGINX Plus R10 is the last release that will include the nginx-plus-extras package. See NGINX Plus Extras Package Is Deprecated, above.

If you’ve not tried NGINX Plus, we encourage you to try it out for web acceleration, load balancing, and application delivery, or as a fully supported web server with enhanced monitoring and management APIs. You can get started for free today with a 30‑day evaluation and see for yourself how NGINX Plus can help you deliver and scale out your applications.

More Information about NGINX Plus R10

For more details about key new features in NGINX Plus R10, see these related resources:

Retrieved by Nick Shadrin from nginx.com website.