Site icon 지락문화예술공작단

Announcing NGINX Plus R10

KENNETH

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 applications from a broad range of attacks

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

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

<!-- For more details about ModSecurity, please see this documentation. -->

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.

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:

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.

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:

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;

     }

}

<!-- For more details, please see this documentation. -->

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 native to 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.

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

Exit mobile version