Announcing NGINX Plus R10

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.

To learn more about NGINX Plus R10, join our webinar on August 31, 2016 at 10:00 AM PDT.

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.

The ModSecurity WAF is based on the new ModSecurity 3, supported by NGINX, Inc. and 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.

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

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

JSON Web Tokens – Many of our customers use NGINX Plus as an API gateway, and have asked us for a common and standard way of authenticating access to APIs at the NGINX Plus layer. To address that need, with this release we are adding support for authentication using JSON Web Tokens (JWTs).

NGINX Plus can now validate a JWT before allowing clients access to APIs. This feature enables application administrators to secure access to their APIs with an open standard, avoiding vendor lock‑in to a proprietary standard. Native JWT support also reduces complexity for application administrators by offloading authentication operations – such as the validation of OAuth 2.0‑compliant OpenID Connect tokens – from application servers to NGINX Plus.
“Dual‑stack” support for ECC and RSA certificates – With NGINX Plus R10, you can publish SSL/TLS services using both RSA and ECC certificates. 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. ECC certificates can be up to 3x quicker than equivalent‑strength RSA certificates; this translates to more SSL/TLS connections per server and faster SSL/TLS handshakes.

In addition to security features, NGINX Plus R10 includes:

Transparent proxy support – Although many modern HTTP applications can be configured to rely on an X‑Forwarded‑For header, some legacy applications and other TCP or UDP services refer to the source IP address of the transaction for logging, security, or authentication purposes.

NGINX Plus can now ‘spoof’ the source IP address and port of HTTP and TCP connections and UDP datagrams that it forwards to upstream servers. This can be used to provide IP transparency, a configuration where NGINX Plus sends packets with the remote client’s IP address so that the upstream server sees the packets as originating from that address rather than a local IP address on the NGINX Plus server. This feature can also be used to enable Direct Server Return for UDP‑based protocols.
nginScript support – nginScript is the next‑generation configuration and control language for NGINX and NGINX Plus, giving users deep and fine‑grained control over how their applications are delivered and secured. In this preview release, the nginScript module increases your control over HTTP, TCP, and UDP traffic, generating responses and making precise decisions to route requests to the optimal servers.
Further improvements to TCP and UDP load balancing – Extensions to the Stream module add support for more NGINX variables, calculations using the map directive, support for A/B testing with the split_clients directive, Geo and GeoIP operations, and selective routing (variable parameter to the proxy_pass directive). These extensions enable you to create more sophisticated TCP and UDP load‑balancing policies, driven by the NGINX configuration language and the new nginScript integration.

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. The 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 — 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:

Layer 7 attack protection – Protect your applications from a broad range of attacks, such as SQL injection, XSS, RFI, and LFI attacks, HTTP violations, and more.
DDoS mitigation – Maintain continuous uptime by mitigating and lessening the effect of sophisticated application‑level DDoS attacks and botnets.
Real‑time blacklists – Automatically block known malicious users by denying traffic from IP addresses that are known to be malicious based on reputation.
Sensitive data protection – Prevent leakages of sensitive data, such as credit card numbers, by monitoring all data leaving your data center.
PCI-DSS 6.6 Compliance – Start complying with PCI-DSS 6.6 requirements for safe online transactions.
Audit logging – Respond more quickly to attacks and other anomalous application traffic using the information in detailed logs.

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 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

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

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. APIs and microservices are also turning to the JWT for its simplicity and flexibility.

To provide authentication services for APIs, NGINX Plus validates JSON Web Tokens (JWTs) — NGINX Plus validates the JWT before granting 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:

A typical use case for microservices is to have NGINX Plus validate the JWT and provide the identity of the authenticated user to the backend application as an HTTP header. This eliminates the need to implement the same authentication functionality over and over, in every microservice.
For APIs, NGINX Plus can rate limit access on a true per‑user basis instead of relying on the approximate mapping of IP addresses to end users.

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. It needs to be installed in a location 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, 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 example below 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;

    }

}

IP transparency and DSR configurations are complex, with additional routing and packet‑rewriting requirements that fall outside the scope of the NGINX Plus software. A follow‑up blog post will describe these configurations in more detail.

Note that passive health checks don’t work when DSR is enabled, because they involve NGINX Plus verifying that the server sent a response. Configuring active application‑aware health checks is mandatory when in DSR mode. Please see this blog for more information on setting up active health checks for DNS servers.

nginScript for TCP‑ and UDP‑Based Applications

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:

Write “serverless” functions directly in NGINX Plus using the powerful JavaScript programming language
Format, manipulate, and transform API data
Provide simple TCP services, such as a time server
Use JavaScript to set NGINX variables, create custom load‑balancing decisions, cache keys, and more

The nginScript preview is available in our dynamic modules repository. You can install it using standard package management tools. The example below is 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.

As an example of using nginScript to implement a simple “serverless” function, this sample JavaScript file, /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();

}

All JavaScript code must be in separate files and read into the NGINX Plus configuration with the js_include directive, as in this example. 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;

     }

}

Additional Features

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

TCP/UDP load balancing, implemented in the Stream module, now has greater feature parity with HTTP load balancing. Newly supported modules and directives include split_clients for A/B testing, geoip to take actions based on the geographical location of clients, and geo to define variables based on IP address. More information is available through additional NGINX variables, and you can perform routing decisions using a variable as the parameter to the proxy_pass directive.
A common problem for high‑traffic applications is ephemeral port exhaustion where new connections to upstream servers can’t be created because the OS has run out of available port numbers. To overcome this, NGINX Plus now uses the IP_BIND_ADDRESS_NO_PORT socket option when available. This option allows source ports to be reused for outgoing connections to upstream servers, provided the standard “4‑tuple” (source IP address, destination IP address, source port, destination port) is unique. It is available on systems with Linux kernel version 4.2 and later, and glibc 2.22 and later.
NGINX Plus generates the new variable $request_id automatically for each new HTTP request, effectively assigning the request a unique “transaction ID”. This facilitates application tracing and brings APM capabilities to log‑analysis tools. The transaction ID is proxied to backend applications and microservices so that all parts of the system can log a consistent identifier for each transaction.
The proxy_request_buffering, fastcgi_request_buffering, scgi_request_buffering, and uwsgi_request_buffering directives now work with HTTP/2 and can be used to toggle request buffering.
The new http2_body_preread_size directive allows HTTP/2 clients to start sending the request body immediately. The directive controls the size of the buffer used before NGINX Plus starts reading the client request body.

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 native to the nginx‑plus package.

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

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
```
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;
```
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.

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.

The post Announcing NGINX Plus R10 appeared first on NGINX.

Source: Announcing NGINX Plus R10