The Road Ahead for NGINX in Ubuntu

 nginx, NGINX, Server Packages, Ubuntu  Comments Off on The Road Ahead for NGINX in Ubuntu
Jul 112016
 

Hello, everyone! Two blog posts and a flurry of tweets in a day, what the heck has gotten into me?

Some fun things have happened in the last development cycle leading up to Xenial for nginx! Let’s recap a couple of the big things that’re ‘great’ happenings:

  • NGINX 1.9.x was accepted into Xenial during the development process.
  • Later in the dev cycle, we were given the ACK by the Security Team to enable the HTTP/2 module (yay, HTTP/2 support!)
  • Close to the end, that was also updated to 1.10.x post-release to get us onto a Stable version for the duration of the LTS! Yay, an LTS with a Stable version!

All in all, a good dev cycle for getting NGINX into the Ubuntu repositories! Now, we look ahead to the future.


First, a note about Wily. The NGINX PPAs will no longer get any Wily updates, as of today. This close to the End of Life date of Wily, I can’t guarantee there’ll be any updates beyond security-critical ones prompting such updates, given the EOL date of Wily being in a couple weeks.

This means, for the most part, that bugs which are against the Wily package in Ubuntu also get less scrutiny as we focus on the future. Any such Wily-filed bugs will need to be confirmed in another release of an equal or newer version (basically, Xenial or later) before I poke at them or another person pokes at them (this doesn’t prevent the community from submitting patches though). This also means people on Wily boxes who want to get continued NGINX support should upgrade to Xenial because I can’t guarantee they’ll get updates as they wish. And once Wily goes EOL, they get nothing.


Secondly, the road ahead. Up in Debian, they’re starting to test builds against the next OpenSSL version (1.1.0). Unfortunately, NGINX Stable 1.10.x doesn’t build. After poking upstream, I’ve learned there is a fix for this… but for NGINX Mainline… and it won’t be backported to 1.10.x. This is a little bit of a headache, for a couple reasons.

  1. NGINX Stable 1.10.x is not going to be able to be supported at some point in the future in Ubuntu, because it won’t have OpenSSL support.
  2. To get NGINX Mainline as the version in NGINX, I need to merge in the quite-evil Debian ‘dynamic modules’ support.
  3. Further, to get NGINX Mainline into Ubuntu during a development cycle, I need to go and pull in from Debian Experimental, and then build test against the older OpenSSL to make sure nothing dies off.

The big issues of this are mostly that we don’t know the full timeline of OpenSSL 1.1.0 being released in Debian. I have assurances from the Ubuntu Security Team, however, that OpenSSL 1.1.0 will not be included until packages don’t Fail to Build from Source (FTBFS) against it. Which means that I don’t have to act on this immediately.

The additional headache added to this list though is that, while I merge in Dynamic Module Support, it is not 100% ‘supported’ yet in Debian, and it won’t be totally supported in a sane way for packages which ship third-party modules. There has been discussion threads on some third-party modules packaging their modules to work as a dynamic module for Ubuntu Universe / Debian. This is a double-edged sword. Not only do I have to worry about NGINX updates, but I will have to start making sure all the dynamic modules get rebuilt for each upload. I’ll be working to try and find a better solution to this, but this will preclude updates to things getting done at times, given the signature-based approach to dynamic modules that exists currently. We’ll work through this, though, at some point, and make it more supportable in the future.

——

Just wanted to give you all some insights into the future of NGINX, and the headaches I will have to work through, for Ubuntu’s packages going forward.

Apr 122016
 

Hello again! NGINX 1.9.14 is now available in Ubuntu Xenial. There’s quite a few things we should make known to everyone who uses nginx in Ubuntu, with php5-fpm currently!


HTTP/2 is now enabled

Yes, HTTP/2 is now enabled for nginx-core, nginx-full, and nginx-extras in Ubuntu Xenial. Add http2 to your SSL listener line in your server blocks, and HTTP/2 will be enabled for that port and site.

For HTTP/2 on non-Xenial Ubuntu releases, you can use the Mainline PPA for Wily and later. Anything before Wily does not have full HTTP/2 support, and very likely will not be usable to get HTTP/2 working as intended.


Ubuntu Xenial ships php7.0-fpm, and not php5-fpm, and this will break existing site configurations

The Ubuntu Xenial packages for nginx have already been updated for this change, pointing to php7.0-fpm instead of php5-fpm.

However, users who have existing site configurations will not benefit from these changes. They must manually apply the changes.

Effectively, this is what a default setup uses to interface with the default php5-fpm setup on Ubuntu versions before Xenial, passing all PHP processing to the php5-fpm backend. This is from the default configuration file, but it’s still similar for all PHP passing:

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
    
        # With php5-cgi alone:
        #fastcgi_pass 127.0.0.1:9000;
        # With php5-fpm:
        fastcgi_pass unix:/var/run/php5-fpm.sock;
    }

In Ubuntu Xenial, the TCP listener for php7.0-cgi will be unchanged, however for php7.0-fpm, it will be necessary to update the configuration to look like this for existing site configurations:

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
    
        # With php7.0-cgi alone:
        #fastcgi_pass 127.0.0.1:9000;
        # With php7.0-fpm:
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }

This will prevent HTTP 502 Bad Gateway errors, and will use the updated php7.0-fpm instead of the php5-fpm packages.

(If for some reason you still want to have php5-fpm under Xenial, you will not be able to get support from Ubuntu for this; you will need to use a PPA. I explain this on a different post on my blog.)

Changes for NGINX Mainline 1.9.6+ Packages in PPAs

 nginx, NGINX Mainline PPA, NGINX PPA, Server Packages, Ubuntu  Comments Off on Changes for NGINX Mainline 1.9.6+ Packages in PPAs
Nov 022015
 

Good day to everyone!

This post is to announce that there are some changes being introduced in the NGINX 1.9.6 packages maintained by Thomas Ward in the Mainline PPA.

1.9.5: SPDY module removed, replaced with HTTP/2 module
The SPDY module was dropped as of nginx 1.9.5. It was replaced with the HTTP/2 module which is considered ‘experimental’. This is reflected in the packages, however 1.9.5 was ever uploaded to the PPAs due to issues in the package which made it less secure.

1.9.6: HTTP/2 bugfixes and other changes
1.9.6 introduced a bunch of bugfixes, and even more bugfixes to HTTP/2. HTTP/2 had multiple issues, but is still considered an “experimental” module. The issues resolved so far make this one OK to upload and use.

Flavor Changes
As a result of the changes to modules, there will be a few changes to the flavors shipped in the PPAs.

Firstly, the SPDY module is no longer included in either nginx-full or nginx-extras.

Secondly, the HTTP/2 module is only loaded in nginx-extras, due to its experimental nature. If you need HTTP/2 you will need to use the nginx-extras version.

NGINX: Mixing and Matching Ubuntu Repositories (and NGINX team PPAs on Launchpad) or Debian Repositories with Upstream Repositories will result in problems.

 Debian, nginx, NGINX, NGINX PPA, Server Packages, Ubuntu  Comments Off on NGINX: Mixing and Matching Ubuntu Repositories (and NGINX team PPAs on Launchpad) or Debian Repositories with Upstream Repositories will result in problems.
Apr 042015
 

We’ve seen this before, but we see it too frequently. People want the latest NGINX version. So they use the upstream nginx.org repository to get it. They try and install, and you immediately get conflicts.

In Ubuntu, people then file bugs on this thinking it’s an Ubuntu issue (such as this bug here). Problem is, it’s not an Ubuntu bug. Nor is it a bug in the PPAs I maintain. Nor is it a bug in Debian. It’s a problem that arises when you mix the upstream repositories and either Ubuntu, Debian, or the Ubuntu PPAs, and assuming you can ‘upgrade’ cleanly with the upstream repositories.

Basically, this is what it comes down to:

For Debian, if you’re depending on third party modules, you should stick to Debian’s packaging and wait. For Ubuntu, you should use the PPAs which I maintain (under the nginx team on Launchpad) if you want latest software and features, based off of Debian’s packaging decisions.

If you want/depend on NAXSI though, you have no choice but to recompile NGINX with NAXSI yourself, in order to get it working in a sane way. Neither Debian, nor Ubuntu, nor the PPAs have naxsi in the builds anymore.

If none of those apply to you, you will have to purge all nginx binaries from your computer, and all nginx packages and configuration files with this command before installing from the upstream repository: sudo apt-get purge nginx nginx-doc nginx-common (This should also purge the other dependent packages as well)

But, if you’re curious why you can’t mix the repositories, this post explains it from my perspective. Here’s a breakdown of why you cannot mix repositories such as this, and the problems you run into.


Problem 1: Debian / Ubuntu / NGINX PPAs (maintained by yours truly) have flavors; nginx upstream does not.

And by flavors, I mean nginx-light, nginx-full, nginx-extras, nginx-naxsi (up until 1.6.2-2), and nginx-core (Ubuntu only, since Ubuntu 14.04). Each of these flavors contains a different set of modules, based on demand originating in Debian or the community (and ultimately implemented in Debian). I will not go into the differences here, however you can go to here and read my answer to the question for more details.

As a result of how NGINX modules are currently incorporated into the program’s binaries, it is absolutely critical to separate out the configuration files and default sample files and locations so that you can switch between flavors (and upgrade between versions between Ubuntu/Debian/PPAs) without issues and conflict between configuration files. This requires the introduction of a package called nginx-common – a package which contains files and other items that are common to all versions of the nginx flavors in those versions of the source package. This nginx-common is wholly the brainchild of Debian’s work, and inherited in Ubuntu and the PPAs I maintain.

The problem is: NGINX upstream does not ship ‘flavors’. They enable all the default modules that are shipped in the nginx upstream ‘core’ code, and do not include any third party modules, nor do they discriminate the modules to enable (to make ‘light’ builds, or ‘full’ builds). As such, the nginx upstream package is a single solitary ‘nginx’ package. It does not separate out configuration files, nor does it separate out the binaries.


Problem 2: NGINX upstream doesn’t have third party modules.

Now, I know what you’re thinking: “Why would Debian/Ubuntu include third-party modules in the packaging?” Turns out, in Debian, the demand for such ‘third party extensions’ was so high, that they decided to include the modules. Such modules include the nginx-lua module, the nginx-perl module, and even the NAXSI modules for NGINX (which were in nginx-naxsi up until 1.6.2-2).

The problem: These are third party modules, maintained separately from the NGINX code base itself. They’re shipped as part of some of Debian’s packages due to demand, but they in and of themselves can cause packaging issues and conflicts, to the point where it requires updating the modules’ code with each new release to fix issues in those modules. This in and of itself lends to ‘maintainability’ problems. This is why the nginx-naxsi flavor was dropped from NGINX in Debian and Ubuntu as of package version/revision 1.6.2-2. To fix even simple bugs in the nginx-naxsi flavor (and its related packages), the entire NAXSI module needed to be removed and replaced with the latest upstream revisions of the code and plugin. This means that to even fix bugs in how the NAXSI rules were handled (in order to match the actual rule formats that needed to be in place for whitelists and such), you’d have to do a replace of the entire NAXSI module in the nginx-naxsi flavor. In Ubuntu, this would break the ‘Stable Release Update’ in that new features would be added to the package that could break things, old features could be removed, and it would go beyond the ‘nitpick fix’ that’d be needed for a Stable Release Update, such that the system would never be fixed.

As a result, third party modules have to be maintained and updated with almost every code update from NGINX upstream. For NGINX Mainline, the Lua module needed to be updated three times for build failure fixes in the PPAs. Since a lot of these third party modules (such as NAXSI or Lua) are in demand by the community, but not available in the NGINX Upstream repository (or in the case of the NAXSI release, even the PPAs nowadays), you should not mix repositories, as you will lose those modules, or lose some of the modules and gain others.


NGINX in Ubuntu Vivid: If upgrading to Vivid on a 32bit i386 platform, consider upgrading to 64bit amd64 platform in the process!

 nginx, NGINX Mainline PPA, NGINX PPA, NGINX Stable PPA, Server Packages, Ubuntu  Comments Off on NGINX in Ubuntu Vivid: If upgrading to Vivid on a 32bit i386 platform, consider upgrading to 64bit amd64 platform in the process!
Apr 042015
 

The latest in updates done to Debian and Ubuntu’s nginx packaging has changed slightly the compilation of the nginx package, namely that two new hardening features have been enabled in the compiling: making the executables Position Independent, and activating immediate binding.

There’s a small problem, here, however. In amd64 (64-bit), Position Independent Executables work fine. However, there is a performance impact that will be noticeable in higher-performance-requiring uses of the nginx executables in 32-bit i386 platforms.

As such, it is highly recommended that if you are planning on upgrading a 32-bit i386 server running nginx with Ubuntu Utopic to Ubuntu Vivid, and your applications that are running via nginx require much higher performance demands (small, static sites don’t necessarily count), then you should strongly consider upgrading to a 64bit amd64 platform, rather than sticking with a 32bit i386 platform due to the performance hit that will be caused as a result of the Position Independent Executable compilation option.

This will affect Ubuntu Vivid (all nginx flavors) and will in future also affect the nginx PPAs. (It has not yet been implemented in the PPAs as of yet, however it will likely end up there in the future.).

NGINX 1.7.11 Now Available in PPA

 nginx, NGINX Mainline PPA, NGINX PPA, Server Packages, Ubuntu  Comments Off on NGINX 1.7.11 Now Available in PPA
Mar 252015
 

The NGINX Mainline PPA has been updated with NGINX Mainline version 1.7.11. It includes builds for Ubuntu Precise, Ubuntu Trusty, Ubuntu Utopic, and Ubuntu Vivid, and the i386, amd64, and armhf architectures.

The following is the list of changes from NGINX upstream:

Changes with nginx 1.7.11                                        24 Mar 2015

    *) Change: the "sendfile" parameter of the "aio" directive is
       deprecated; now nginx automatically uses AIO to pre-load data for
       sendfile if both "aio" and "sendfile" directives are used.

    *) Feature: experimental thread pools support.

    *) Feature: the "proxy_request_buffering", "fastcgi_request_buffering",
       "scgi_request_buffering", and "uwsgi_request_buffering" directives.

    *) Feature: request body filters experimental API.

    *) Feature: client SSL certificates support in mail proxy.
       Thanks to Sven Peter, Franck Levionnois, and Filipe Da Silva.

    *) Feature: startup speedup when using the "hash ... consistent"
       directive in the upstream block.
       Thanks to Wai Keen Woon.

    *) Feature: debug logging into a cyclic memory buffer.

    *) Bugfix: in hash table handling.
       Thanks to Chris West.

    *) Bugfix: in the "proxy_cache_revalidate" directive.

    *) Bugfix: SSL connections might hang if deferred accept or the
       "proxy_protocol" parameter of the "listen" directive were used.
       Thanks to James Hamlin.

    *) Bugfix: the $upstream_response_time variable might contain a wrong
       value if the "image_filter" directive was used.

    *) Bugfix: in integer overflow handling.
       Thanks to Régis Leroy.

    *) Bugfix: it was not possible to enable SSLv3 with LibreSSL.

    *) Bugfix: the "ignoring stale global SSL error ... called a function
       you should not call" alerts appeared in logs when using LibreSSL.

    *) Bugfix: certificates specified by the "ssl_client_certificate" and
       "ssl_trusted_certificate" directives were inadvertently used to
       automatically construct certificate chains.
Jan 162015
 

After an eon of fighting the code, I managed to get this to build. It’s been since December 23, 2014 that the PPAs have needed updating, and it turns out I made a failure during updates which caused things to not build. That’s resolved, so now it’s updated.

The NGINX Mainline PPAs are now updated with NGINX 1.7.9. The nginx-lua and nginx-cache-purge modules were updated in order to address build failures. The remaining set of packaging remains the same.

Below are the changes which come with NGINX 1.7.9 (from the upstream NGINX changelog):

Changes with nginx 1.7.9                                         23 Dec 2014

    *) Feature: variables support in the "proxy_cache", "fastcgi_cache",
       "scgi_cache", and "uwsgi_cache" directives.

    *) Feature: variables support in the "expires" directive.

    *) Feature: loading of secret keys from hardware tokens with OpenSSL
       engines.
       Thanks to Dmitrii Pichulin.

    *) Feature: the "autoindex_format" directive.

    *) Bugfix: cache revalidation is now only used for responses with 200
       and 206 status codes.
       Thanks to Piotr Sikora.

    *) Bugfix: the "TE" client request header line was passed to backends
       while proxying.

    *) Bugfix: the "proxy_pass", "fastcgi_pass", "scgi_pass", and
       "uwsgi_pass" directives might not work correctly inside the "if" and
       "limit_except" blocks.

    *) Bugfix: the "proxy_store" directive with the "on" parameter was
       ignored if the "proxy_store" directive with an explicitly specified
       file path was used on a previous level.

    *) Bugfix: nginx could not be built with BoringSSL.
       Thanks to Lukas Tribus.
Dec 182014
 

This post serves as a notice regarding the BREACH vulnerability and NGINX.

For Ubuntu, Debian, and the PPA users: If you are on 1.6.2-5 (or 1.7.8 from the PPAs), the default configuration has GZIP compression enabled, which means it does not mitigate BREACH on your sites by default. You need to look into whether you are actually impacted by BREACH, and if you are consider mitigation steps.


What is it?

Unlke CRIME, which attacks TLS/SPDY compression and is mitigated by disabling SSL compression, BREACH attacks HTTP responses. These are compressed using the common HTTP compression, which is much more common than TLS-level compression. This allows essentially the same attack demonstrated by Duong and Rizzo, but without relying on TLS-level compression (as they anticipated).

BREACH is a category of vulnerabilities and not a specific instance affecting a specific piece of software. To be vulnerable, a web application must:

  • Be served from a server that uses HTTP-level compression
  • Reflect user-input in HTTP response bodies
  • Reflect a secret (such as a CSRF token) in HTTP response bodies

Additionally, while not strictly a requirement, the attack is helped greatly by responses that remain mostly the same (modulo the attacker’s guess). This is because the difference in size of the responses measured by the attacker can be quite small. Any noise in the side-channel makes the attack more difficult (though not impossible).

It is important to note that the attack is agnostic to the version of TLS/SSL, and does not require TLS-layer compression. Additionally, the attack works against any cipher suite. Against a stream cipher, the attack is simpler; the difference in sizes across response bodies is much more granular in this case. If a block cipher is used, additional work must be done to align the output to the cipher text blocks.

How practical is it?

The BREACH attack can be exploited with just a few thousand requests, and can be executed in under a minute. The number of requests required will depend on the secret size. The power of the attack comes from the fact that it allows guessing a secret one character at a time.

Am I affected?

If you have an HTTP response body that meets all the following conditions, you might be vulnerable:

  • Compression – Your page is served with HTTP compression enabled (GZIP / DEFLATE)
  • User Data – Your page reflects user data via query string parameters, POST …
  • A Secret – Your application page serves Personally Identifiable Information (PII), a CSRF token, sensitive data …

Mitigations

NOTE: The Breach Attack Information Site offers several tactics for mitigating the attack. Unfortunately, they are unaware of a clean, effective, practical solution to the problem. Some of these mitigations are more practical and a single change can cover entire apps, while others are page specific.

The mitigations are ordered by effectiveness (not by their practicality – as this may differ from one application to another).

  1. Disabling HTTP compression
  2. Separating secrets from user input
  3. Randomizing secrets per request
  4. Masking secrets (effectively randomizing by XORing with a random secret per request)
  5. Protecting vulnerable pages with CSRF
  6. Length hiding (by adding random number of bytes to the responses)
  7. Rate-limiting the requests.

Whichever mitigation you choose, it is strongly recommended you also monitor your traffic to detect attempted attacks.


Mitigation Tactics and Practicality

Unfortunately, the practicality of the listed mitigation tactics is widely varied. Practicality is determined by the application you are working with, and in a lot of cases it is not possible to just disable GZIP compression outright due to the size of what’s being served.

This blog post will cover and describe in varying detail three mitigation methods: Disabling HTTP Compression, Randomizing secrets per request, and Length Hiding (using this site as a reference for the descriptions here).

Disabling HTTP Compression

This is the simplest and most effective mitigation tactic, but is ultimately not the most wieldy mitigation tactic, as there is a chance your application actually requires GZIP compression. If this is the case, then you should not use this mitigation option, when GZIP compression is needed in your environment. However, if your application and use case does not necessitate the requirement of GZIP compression, this is easily fixed.

To disable GZIP globally on your NGINX instances, in nginx.conf, add this code to the http block: gzip off;.

To disable GZIP specifically in your sites and not globally, follow the same instructions for globally disabling GZIP, but add it to your server block in your sites’ specific configurations instead.

If you are using NGINX from the Ubuntu or Debian repositories, or the NGINX PPAs, you should check your /etc/nginx.conf file to see if it has gzip on; and you should comment this out or change it to gzip off;.

However, if disabling GZIP compression is not an option for your sites, then consider looking into other mitigation methods.

Randomizing secrets per request or masking secrets

Unfortunately, this one is the least descriptive here. Secret handling is handled on an application level and not an NGINX level. If you have the capability to modify your application, you should modify it to randomize the secrets with each request, or mask the secrets. If this is not an option, then consider using another method of mitigation.

Length hiding

Length hiding can be done by nginx, however it is not currently available in the NGINX packages in Ubuntu, Debian, or the PPAs.

It can be done on the application side, but it is easier to update an nginx configuration than to modify and deploy an application when you need to enable or disable this in a production environment. A Length Hiding Filter Module has been made by Nulab, and it adds randomly generated HTML comments to the end of an HTML response to hide correct length and make it difficult for attackers to guess secret information.

An example of such a comment added by the module is as follows:

<!-- random-length HTML comment: E9pigGJlQjh2gyuwkn1TbRI974ct3ba5bFe7LngZKERr29banTtCizBftbMk0mgRq8N1ltPtxgY -->

NOTE: To use this method, until there is any packaging available that uses this module or includes it, you will need to compile NGINX from the source tarballs.

To enable this module, you will need to compile NGINX from source and add the module. Then, add the length_hiding directive to the server,http, or location blocks in your configuration with this line: length_hiding on;


Special Packaging of NGINX PPA with Length Hiding Enabled

I am currently working on building NGINX stable and mainline with the Length Hiding module included in all variants of the package which have SSL enabled. This will eventually be available in separate PPAs for the stable and mainline PPAs.

Until then, I strongly suggest that you look into whether you can operate without GZIP compression enabled, or look into one of the other methods of mitigating this issue.

NGINX and Ubuntu: Using Flavors Other than `nginx-core`

 nginx, Server Packages, Ubuntu  Comments Off on NGINX and Ubuntu: Using Flavors Other than `nginx-core`
Dec 132014
 

Today, a bug was filed reporting that nginx-full and nginx-common were different versions.  Naturally I went hunting, and found this not to be the case.  (The bug is here)

It looks like unless you enable Universe, you won’t be able to see the updated versions for nginx-common and nginx-full, and there will be version mismatch errors. You’ll see the older version(s) in Main, though, because Main ships with nginx-core and nginx-common specifically, and not the other flavors

So, here’s a little tidbit for NGINX users on Ubuntu: Make sure you have the following repositories enabled if you want to use a specific flavor of nginx:

  • nginx-core: Main
  • nginx-full: Universe
  • nginx-light: Universe
  • nginx-extras: Universe
  • nginx-naxsi (Obsolete, removed with Ubuntu 15.04): Universe

NGINX in Ubuntu, PPAs, and Debian: naxsi packages dropped as of September 26, 2014 (repost)

 nginx, NGINX Mainline PPA, NGINX Stable PPA  Comments Off on NGINX in Ubuntu, PPAs, and Debian: naxsi packages dropped as of September 26, 2014 (repost)
Dec 092014
 

Back in April, I upstreamed (that is, reported a bug to Debian) regarding the `nginx-naxsi` packages. The initial bug I upstreamed was about the outdated naxsi version in the naxsi packages. (see this bug in Ubuntu and the related bug in Debian)

The last update on the Debian bug is on September 10, 2014. That update says the following, and was made by Christos Trochalakis:

After discussing it with the fellow maintainers we have decided that it is
better to remove the nginx-naxsi package before jessie is freezed.

Packaging naxsi is not trivial and, unfortunately, none of the maintainers uses
it. That’s the reason nginx-naxsi is not in a good shape and we are not feeling
comfortable to release and support it.

We are sorry for any inconvenience caused.

I asked what the expected timeline was for the packages being dropped. In a response from Christos today, September 15, 2014, it was said:

It ‘ll get merged and released (1.6.1-3) by the end of the month.


Update (December 9, 2014): In Ubuntu, these changes will not make it into 14.10, but are now included in 15.04 as part of nginx 1.6.2-4ubuntu1.  As such, the naxsi variant of nginx is no longer included starting with 15.04.  Community support for the naxsi variant is also limited as well.

In the PPAs, the naxsi packages will be dropped with stable 1.6.2-2+precise0 +trusty0 +utopic0 and mainline 1.7.5-2+precise0 +trusty0 +utopic0.

In Debian, these changes have been applied as 1.6.2-2.

 

(Originally published on September 26, 2014 @ 12:34)