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.