Skip to main content

Application Protection

The Application Protection category contains patterns to set up reverse proxy and WAF features.

Core Patterns​

The following diagram shows important patterns in this category. The diagram does not include most add-on patterns. See Standard Patterns Reference for a complete list.

Application Protection patterns

nevisProxy Instance Pattern​

The nevisProxy Instance pattern sets up an empty instance of nevisProxy.

You have to use the Virtual Host pattern to add a web.xml file and the required connector configuration.

Additionally, you can assign the Generic nevisProxy Settings add-on pattern to adapt low-level settings in the navajo.xml file.

Additional add-on patterns are planned for future releases (for example, for nevisProxy sizing).

Service Patterns​

Patterns that implement the Service interface are used to make content accessible via nevisProxy.

The Hosting Service pattern facilitates the deployment of static pages on nevisProxy over a certain path.

Service access patterns support the integration of backend applications. nevisAdmin 4 provides the following service access patterns:

  • Web Application: Used for classic web applications (e.g., form-based) and hybrid applications. CSRF protection and ModSecurity are enabled by default.
  • REST Service: Used for REST APIs. Basic JSON validation is enabled by default.
  • SOAP Service: Used for SOAP APIs. Schema validation using WSDL is in development for nevisAdmin 4.2.

See First Steps on how to use these patterns to integrate an application.

Add-On Patterns​

Several add-on patterns facilitate application protection. You can assign these add-on patterns to the following patterns:

  • Virtual Host pattern - Assign an add-on to this pattern to change the behavior of the root location. This affects all services.
  • Service patterns - Assign an add-on to a service pattern if you want to configure a feature for this service only. Service patterns are, for example, REST Service and SOAP Service.

Technically, assigning an add-on to a pattern is possible under the following conditions:

  • The add-on pattern implements the PathLocationAddon interface, and
  • the pattern supports the PathLocation interface.
  • See also the figure: Application Protection patterns above.

The add-ons are mostly used to enable WAF features. Example add-ons are:

  • Access Restriction: Use this add-on to white- or blacklist IPs.
  • ICAP Scanning: Use this add-on to perform a virus scan of uploaded files.
  • Request Validation Settings: Use this add-on to fine-tune the request validation by changing the configuration of ModSecurity.

See: Standard Patterns Reference for a complete list of the add-on patterns.

What if my Use Case is not Covered by the Standard?​

If your use case is not covered by the standard patterns, contact Nevis Support and explain your case. The nevisProxy patterns are in active development and we are interested in your requirements.

In the meantime you have several options:

  • Customize the settings in the navajo.xml file with the Generic nevisProxy Settings pattern. The Help page of this pattern explains which cases are supported.
  • Adapt the configuration in the web.xml file with the Generic Virtual Host Settings pattern or the Generic Application Settings pattern.
  • Solve complex use cases with the Lua script, by means of the Lua HTTP Processing pattern.

How to configure the nevisProxy examples with nevisAdmin 4?​

The examples provided in the nevisProxy documentation and in the installed package under /opt/nevisproxy/examples/ cover several aspects of a typical nevisProxy configuration. They fall into three broad categories:

Examples for low-level integrations​

Several examples illustrate the technical details when configuring nevisProxy manually. They cover use cases such as integrating an application or enabling user authentication, and they focus on the nevisProxy side of the configuration. These tasks are better covered by dedicated patterns, that include the full use case instead of having to configure each component separately. See for example the patterns in the categories Applications and Realms for the aforementioned use cases. Before copying an example in a generic pattern, check whether there is an existing pattern, or group of patterns, for this task. Using existing patterns is also easier to maintain, since we update them when we modify the underlying Nevis components.

Examples for filters or servlets having their own Pattern​

Some examples illustrate a self-contained feature that is available in a dedicated pattern. For example the MaintenanceFilter can be configured with a Maintenance Page pattern, or the CountryIpFilter is part of the Access Restriction pattern. Similarly to the low-level integration examples, we recommend using the dedicated patterns whenever possible.

Examples with LuaFilters​

Several examples show how to configure one or several LuaFilters to perform certain tasks. The reason for using a LuaFilter can be that the use case is too specific to have its own filter, or that the process has to be fine-tuned for the target installation. Let us know if you use one of the LuaFilter examples in your configuration. We may create a dedicated filter or pattern for the widespread ones.

Proceed as follows to configure a Lua HTTP Processing pattern from an existing LuaFilter:

  • Add a Lua HTTP Processing pattern to your configuration;
  • Copy the content of the Script parameter from the LuaFilter in the Lua Script setting;
  • Check that the names of the functions to be invoked for the requests and responses match the list in the description of the Lua Script setting;
  • If the LuaFilter includes parameters, rename them in the script with the prefix param_ and list them in the Script Parameters setting;
  • Replace the placeholders as described in Placeholders in the examples and default values, generally:
    • @PKG_HOME@ → /opt/nevisproxy
    • @PKG_VAR@ → /var/opt/nevisproxy
    • @PKG_INSTANCE@ → name of the nevisProxy instance
  • Set the Filter Phase if your filter should be invoked during a specific processing step;
  • Link the pattern to the Additional Settings of the target Application or Virtual Host pattern(s).